All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla@dpdk.org
To: dev@dpdk.org
Subject: [dpdk-dev] [Bug 561] EAL: secondary dpdk application fails to come up in 5.4.35 kernel due to memzone_init failure
Date: Tue, 20 Oct 2020 12:21:10 +0000	[thread overview]
Message-ID: <bug-561-3@http.bugs.dpdk.org/> (raw)

https://bugs.dpdk.org/show_bug.cgi?id=561

            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
messages

 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.




int
eal_clean_runtime_dir(void)
{
       DIR *dir;
       struct dirent *dirent;
       int dir_fd, fd, lck_result;
       static const char * const filters[] = {
              "fbarray_*",
              "mp_socket_*"
       };
       /* open directory */
       dir = opendir(runtime_dir);
       if (!dir) {
              RTE_LOG(ERR, EAL, "Unable to open runtime directory %s\n",
                           runtime_dir);
              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",
                     runtime_dir);
              goto error;
       }

       dirent = readdir(dir);
       if (!dirent) {
              RTE_LOG(ERR, EAL, "Unable to read runtime directory %s\n",
                           runtime_dir);
              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;
                           break;
                     }
              }
              if (skip) {
                     dirent = readdir(dir);
                     continue;
              }

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

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

              /* 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);
              close(fd);
              dirent = readdir(dir);
       }

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

error:
       if (dir)
              closedir(dir);
       RTE_LOG(ERR, EAL, "Error while clearing runtime dir: %s\n",
              strerror(errno));

       return -1;
}

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

                 reply	other threads:[~2020-10-20 12:21 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-561-3@http.bugs.dpdk.org/ \
    --to=bugzilla@dpdk.org \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.