DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] [Bug 561] EAL: secondary dpdk application fails to come up in 5.4.35 kernel due to memzone_init failure
@ 2020-10-20 12:21 bugzilla
  0 siblings, 0 replies; only message in thread
From: bugzilla @ 2020-10-20 12:21 UTC (permalink / raw)
  To: dev


            Bug ID: 561
           Summary: EAL: secondary dpdk application fails to come up in
                    5.4.35 kernel due to memzone_init failure
           Product: DPDK
           Version: 18.11
          Hardware: x86
                OS: Linux
            Status: UNCONFIRMED
          Severity: critical
          Priority: Normal
         Component: core
          Assignee: dev@dpdk.org
          Reporter: amohakud@rbbn.com
  Target Milestone: ---

Created attachment 126
  --> https://bugs.dpdk.org/attachment.cgi?id=126&action=edit
EAL: secondary dpdk application fails to come up in 5.4.35 kernel due to
memzone_init failure

DPDK version: 18.11.6
Kernel version: 5.4.35

Secondary DPDK process fails to come up in 5.4.35 kernel, throwing below error

 EAL: Probing VFIO support...
 EAL: VFIO support initialized
 EAL: Cannot attach to memzone list
 EAL: Cannot init memzone
 EAL: Error - exiting with code: 1

From the code analysis, I could notice that in 5.4.35 kernel, the behavior of
the rte_eal_init() in the context of primary process is different than that of
4.19 or 4.15 kernel.
In 5.4.35 kernel, the primary process cleans up the dpdk run time directory in
eal_clean_runtime_dir() function, as a result the file
/var/run/dpdk/rte/fbarray_memzone gets deleted. so the secondary process while
coming up fails to attach to memzone and exits. Basically the flock system call
in eal_clean_runtime_dir() function succeeds in primary process, due to which
the file gets deleted.

But in 4.19/4.15 kernel, the flock system call always fails in primary process
and secondary process is able to attach to the already created memzone.

       DIR *dir;
       struct dirent *dirent;
       int dir_fd, fd, lck_result;
       static const char * const filters[] = {
       /* open directory */
       dir = opendir(runtime_dir);
       if (!dir) {
              RTE_LOG(ERR, EAL, "Unable to open runtime directory %s\n",
              goto error;
       dir_fd = dirfd(dir);

       /* lock the directory before doing anything, to avoid races */
       if (flock(dir_fd, LOCK_EX) < 0) {
              RTE_LOG(ERR, EAL, "Unable to lock runtime directory %s\n",
              goto error;

       dirent = readdir(dir);
       if (!dirent) {
              RTE_LOG(ERR, EAL, "Unable to read runtime directory %s\n",
              goto error;

       while (dirent != NULL) {
              unsigned int f_idx;
              bool skip = true;

              /* skip files that don't match the patterns */
              for (f_idx = 0; f_idx < RTE_DIM(filters); f_idx++) {
                     const char *filter = filters[f_idx];

                     if (fnmatch(filter, dirent->d_name, 0) == 0) {
                           skip = false;
              if (skip) {
                     dirent = readdir(dir);

              /* try and lock the file */
              fd = openat(dir_fd, dirent->d_name, O_RDONLY);

              /* skip to next file */
              if (fd == -1) {
                     dirent = readdir(dir);

              /* non-blocking lock */
              lck_result = flock(fd, LOCK_EX | LOCK_NB);

              /* if lock succeeds, remove the file */
              if (lck_result != -1)
                     unlinkat(dir_fd, dirent->d_name, 0);
              dirent = readdir(dir);

       /* closedir closes dir_fd and drops the lock */
       return 0;

       if (dir)
       RTE_LOG(ERR, EAL, "Error while clearing runtime dir: %s\n",

       return -1;

You are receiving this mail because:
You are the assignee for the bug.

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2020-10-20 12:21 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-20 12:21 [dpdk-dev] [Bug 561] EAL: secondary dpdk application fails to come up in 5.4.35 kernel due to memzone_init failure bugzilla

DPDK patches and discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.dpdk.org/dev/0 dev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 dev dev/ https://inbox.dpdk.org/dev \
	public-inbox-index dev

Example config snippet for mirrors.
Newsgroup available over NNTP:

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git