From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 24582A04DC; Tue, 20 Oct 2020 14:21:16 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B7A61BAD4; Tue, 20 Oct 2020 14:21:13 +0200 (CEST) Received: from inbox.dpdk.org (xvm-172-178.dc0.ghst.net [95.142.172.178]) by dpdk.org (Postfix) with ESMTP id C2FD6A9AD for ; Tue, 20 Oct 2020 14:21:12 +0200 (CEST) Received: by inbox.dpdk.org (Postfix, from userid 33) id A318EA04DD; Tue, 20 Oct 2020 14:21:11 +0200 (CEST) From: bugzilla@dpdk.org To: dev@dpdk.org Date: Tue, 20 Oct 2020 12:21:10 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: DPDK X-Bugzilla-Component: core X-Bugzilla-Version: 18.11 X-Bugzilla-Keywords: X-Bugzilla-Severity: critical X-Bugzilla-Who: amohakud@rbbn.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: dev@dpdk.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter target_milestone attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All MIME-Version: 1.0 Subject: [dpdk-dev] [Bug 561] EAL: secondary dpdk application fails to come up in 5.4.35 kernel due to memzone_init failure X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" https://bugs.dpdk.org/show_bug.cgi?id=3D561 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=3D126&action=3Dedit 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 er= ror 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 wh= ile 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 whi= ch the file gets deleted. But in 4.19/4.15 kernel, the flock system call always fails in primary proc= ess 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[] =3D { "fbarray_*", "mp_socket_*" }; /* open directory */ dir =3D opendir(runtime_dir); if (!dir) { RTE_LOG(ERR, EAL, "Unable to open runtime directory %s\n", runtime_dir); goto error; } dir_fd =3D 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 =3D readdir(dir); if (!dirent) { RTE_LOG(ERR, EAL, "Unable to read runtime directory %s\n", runtime_dir); goto error; } while (dirent !=3D NULL) { unsigned int f_idx; bool skip =3D true; /* skip files that don't match the patterns */ for (f_idx =3D 0; f_idx < RTE_DIM(filters); f_idx++) { const char *filter =3D filters[f_idx]; if (fnmatch(filter, dirent->d_name, 0) =3D=3D 0) { skip =3D false; break; } } if (skip) { dirent =3D readdir(dir); continue; } /* try and lock the file */ fd =3D openat(dir_fd, dirent->d_name, O_RDONLY); /* skip to next file */ if (fd =3D=3D -1) { dirent =3D readdir(dir); continue; } /* non-blocking lock */ lck_result =3D flock(fd, LOCK_EX | LOCK_NB); /* if lock succeeds, remove the file */ if (lck_result !=3D -1) unlinkat(dir_fd, dirent->d_name, 0); close(fd); dirent =3D 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; } --=20 You are receiving this mail because: You are the assignee for the bug.=