Re: [LKP] [PATCH v2] fsnotify: fix unlink performance regression
by Jan Kara
On Tue 07-05-19 22:12:57, Amir Goldstein wrote:
> On Tue, May 7, 2019 at 7:19 PM Jan Kara <jack(a)suse.cz> wrote:
> > So I'd rather move the fsnotify call to vfs_unlink(),
> > vfs_rmdir(), simple_unlink(), simple_rmdir(), and then those few callers of
> > d_delete() that remain as you suggest elsewhere in this thread. And then we
> > get more consistent context for fsnotify_nameremove() and could just use
> > fsnotify_dirent().
> >
>
> Yes, I much prefer this solution myself and I will follow up with it,
> but it would not be honest to suggest said solution as a stable fix
> to the performance regression that was introduced in v5.1.
> I think is it better if you choose between lesser evil:
> v1 with ifdef CONFIG_FSNOTIFY to fix build issue
> v2 as subtle as it is
> OR another obviously safe stable fix that you can think of
OK, fair enough. I'll go with v1 + build fix for current merge window +
stable as it's local to fsnotify_nameremove().
> The change of cleansing d_delete() from fsnotify_nameremove()
> requires more research and is anyway not stable tree material -
> if not for the level of complexity, then because all the users of
> FS_DELETE from pseudo and clustered filesystems need more time
> to find regressions (we do not have test coverage for those in LTP).
Agreed.
Honza
--
Jan Kara <jack(a)suse.com>
SUSE Labs, CR
1 year, 5 months
Re: [LKP] [PATCH v2] fsnotify: fix unlink performance regression
by Jan Kara
On Sun 05-05-19 23:07:28, Amir Goldstein wrote:
> __fsnotify_parent() has an optimization in place to avoid unneeded
> take_dentry_name_snapshot(). When fsnotify_nameremove() was changed
> not to call __fsnotify_parent(), we left out the optimization.
> Kernel test robot reported a 5% performance regression in concurrent
> unlink() workload.
>
> Modify __fsnotify_parent() so that it can be called also to report
> directory modififcation events and use it from fsnotify_nameremove().
>
> Reported-by: kernel test robot <rong.a.chen(a)intel.com>
> Link: https://lore.kernel.org/lkml/20190505062153.GG29809@shao2-debian/
> Link: https://lore.kernel.org/linux-fsdevel/20190104090357.GD22409@quack2.suse.cz/
> Fixes: 5f02a8776384 ("fsnotify: annotate directory entry modification events")
> Signed-off-by: Amir Goldstein <amir73il(a)gmail.com>
> ---
>
> Jan,
>
> A nicer approach reusing __fsnotify_parent() instead of copying code
> from it.
>
> This version does not apply cleanly to Al's for-next branch (there are
> some fsnotify changes in work.dcache). The conflict is trivial and
> resolved on my fsnotify branch [1].
Hum, let me check if I understand the situation right. We've changed
fsnotify_nameremove() to not use fsnotify_parent() as we don't want to
report FS_EVENT_ON_CHILD with it anymore. We should use fsnotify_dirent()
as for all other directory event notification handlers but that's
problematic due to different locking context and possible instability of
parent.
Honestly I don't like the patch below much. How we are notifying parent
without sending FS_EVENT_ON_CHILD and modify behavior based on that flag
just looks subtle. So I'd rather move the fsnotify call to vfs_unlink(),
vfs_rmdir(), simple_unlink(), simple_rmdir(), and then those few callers of
d_delete() that remain as you suggest elsewhere in this thread. And then we
get more consistent context for fsnotify_nameremove() and could just use
fsnotify_dirent().
Honza
> diff --git a/fs/notify/fsnotify.c b/fs/notify/fsnotify.c
> index df06f3da166c..265b726d6e8d 100644
> --- a/fs/notify/fsnotify.c
> +++ b/fs/notify/fsnotify.c
> @@ -151,31 +151,31 @@ void __fsnotify_update_child_dentry_flags(struct inode *inode)
> spin_unlock(&inode->i_lock);
> }
>
> -/* Notify this dentry's parent about a child's events. */
> +/*
> + * Notify this dentry's parent about an event and make sure that name is stable.
> + * Events "on child" are only reported if parent is watching.
> + * Directory modification events are also reported if super block is watching.
> + */
> int __fsnotify_parent(const struct path *path, struct dentry *dentry, __u32 mask)
> {
> struct dentry *parent;
> struct inode *p_inode;
> int ret = 0;
> + bool on_child = (mask & FS_EVENT_ON_CHILD);
> + __u32 test_mask = (mask & ALL_FSNOTIFY_EVENTS);
>
> - if (!dentry)
> - dentry = path->dentry;
> -
> - if (!(dentry->d_flags & DCACHE_FSNOTIFY_PARENT_WATCHED))
> + if (on_child && !(dentry->d_flags & DCACHE_FSNOTIFY_PARENT_WATCHED))
> return 0;
>
> parent = dget_parent(dentry);
> p_inode = parent->d_inode;
>
> - if (unlikely(!fsnotify_inode_watches_children(p_inode))) {
> + if (on_child && unlikely(!fsnotify_inode_watches_children(p_inode))) {
> __fsnotify_update_child_dentry_flags(p_inode);
> - } else if (p_inode->i_fsnotify_mask & mask & ALL_FSNOTIFY_EVENTS) {
> + } else if ((p_inode->i_fsnotify_mask & test_mask) ||
> + (!on_child && (dentry->d_sb->s_fsnotify_mask & test_mask))) {
> struct name_snapshot name;
>
> - /* we are notifying a parent so come up with the new mask which
> - * specifies these are events which came from a child. */
> - mask |= FS_EVENT_ON_CHILD;
> -
> take_dentry_name_snapshot(&name, dentry);
> if (path)
> ret = fsnotify(p_inode, mask, path, FSNOTIFY_EVENT_PATH,
> diff --git a/include/linux/fsnotify.h b/include/linux/fsnotify.h
> index 09587e2860b5..8641bf9a1eda 100644
> --- a/include/linux/fsnotify.h
> +++ b/include/linux/fsnotify.h
> @@ -37,7 +37,7 @@ static inline int fsnotify_parent(const struct path *path,
> if (!dentry)
> dentry = path->dentry;
>
> - return __fsnotify_parent(path, dentry, mask);
> + return __fsnotify_parent(path, dentry, mask | FS_EVENT_ON_CHILD);
> }
>
> /*
> @@ -158,13 +158,11 @@ static inline void fsnotify_vfsmount_delete(struct vfsmount *mnt)
> * dentry->d_parent should be stable. However there are some corner cases where
> * inode lock is not held. So to be on the safe side and be reselient to future
> * callers and out of tree users of d_delete(), we do not assume that d_parent
> - * and d_name are stable and we use dget_parent() and
> + * and d_name are stable and we use __fsnotify_parent() to
> * take_dentry_name_snapshot() to grab stable references.
> */
> static inline void fsnotify_nameremove(struct dentry *dentry, int isdir)
> {
> - struct dentry *parent;
> - struct name_snapshot name;
> __u32 mask = FS_DELETE;
>
> /* d_delete() of pseudo inode? (e.g. __ns_get_path() playing tricks) */
> @@ -174,14 +172,7 @@ static inline void fsnotify_nameremove(struct dentry *dentry, int isdir)
> if (isdir)
> mask |= FS_ISDIR;
>
> - parent = dget_parent(dentry);
> - take_dentry_name_snapshot(&name, dentry);
> -
> - fsnotify(d_inode(parent), mask, d_inode(dentry), FSNOTIFY_EVENT_INODE,
> - name.name, 0);
> -
> - release_dentry_name_snapshot(&name);
> - dput(parent);
> + __fsnotify_parent(NULL, dentry, mask);
> }
>
> /*
> --
> 2.17.1
>
--
Jan Kara <jack(a)suse.com>
SUSE Labs, CR
1 year, 5 months
d01f449c00 ("of_net: add NVMEM support to of_get_mac_address"): BUG: unable to handle kernel paging request at fffffffe
by kernel test robot
Greetings,
0day kernel testing robot got the below dmesg and the first bad commit is
git://internal_merge_and_test_tree devel-catchup-201905061421
commit d01f449c008a3f41fa44c603e28a7452ab8f8e68
Author: Petr Štetiar <ynezz(a)true.cz>
AuthorDate: Fri May 3 16:27:06 2019 +0200
Commit: David S. Miller <davem(a)davemloft.net>
CommitDate: Sun May 5 21:47:07 2019 -0700
of_net: add NVMEM support to of_get_mac_address
Many embedded devices have information such as MAC addresses stored
inside NVMEMs like EEPROMs and so on. Currently there are only two
drivers in the tree which benefit from NVMEM bindings.
Adding support for NVMEM into every other driver would mean adding a lot
of repetitive code. This patch allows us to configure MAC addresses in
various devices like ethernet and wireless adapters directly from
of_get_mac_address, which is already used by almost every driver in the
tree.
Predecessor of this patch which used directly MTD layer has originated
in OpenWrt some time ago and supports already about 497 use cases in 357
device tree files.
Cc: Alban Bedel <albeu(a)free.fr>
Signed-off-by: Felix Fietkau <nbd(a)nbd.name>
Signed-off-by: John Crispin <john(a)phrozen.org>
Signed-off-by: Petr Štetiar <ynezz(a)true.cz>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
8ef5cc4f3c Merge branch 'bnxt_en-Driver-updates'
d01f449c00 of_net: add NVMEM support to of_get_mac_address
0b60bd2503 0day head guard for 'devel-catchup-201905061421'
+------------------------------------------+------------+------------+------------+
| | 8ef5cc4f3c | d01f449c00 | 0b60bd2503 |
+------------------------------------------+------------+------------+------------+
| boot_successes | 41 | 0 | 0 |
| boot_failures | 0 | 22 | 17 |
| BUG:unable_to_handle_kernel | 0 | 22 | 17 |
| Oops:#[##] | 0 | 22 | 17 |
| EIP:dsa_slave_create | 0 | 22 | 17 |
| Kernel_panic-not_syncing:Fatal_exception | 0 | 22 | 17 |
+------------------------------------------+------------+------------+------------+
If you fix the issue, kindly add following tag
Reported-by: kernel test robot <lkp(a)intel.com>
[ 3.500564] kAFS: Red Hat AFS client v0.1 registering.
[ 3.549119] kAFS: failed to register: -97
[ 3.551144] Key type encrypted registered
[ 3.552945] dsa-loop fixed-0:1f: DSA mockup driver: 0x1f
[ 3.555289] libphy: dsa slave smi: probed
[ 3.556864] BUG: unable to handle kernel paging request at fffffffe
[ 3.558805] #PF error: [normal kernel read fault]
[ 3.560448] *pde = 02079063 *pte = 00000000
[ 3.561990] Oops: 0000 [#1] SMP
[ 3.563338] CPU: 0 PID: 22 Comm: kworker/0:1 Tainted: G T 5.1.0-rc7-01945-gd01f449c #34
[ 3.566611] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
[ 3.569598] Workqueue: events deferred_probe_work_func
[ 3.571358] EIP: dsa_slave_create+0x9b/0x3f0
[ 3.572975] Code: 00 00 00 81 4b 7c 00 00 01 00 89 45 e8 0d 00 00 01 00 89 43 74 b8 e0 17 cd c1 89 83 24 01 00 00 8b 45 f0 8b 40 24 85 c0 74 0b <8b> 08 f6 c1 01 0f 84 ca 01 00 00 8b 75 ec 0f b6 86 7a 01 00 00 88
[ 3.578695] EAX: fffffffe EBX: d8bca000 ECX: c21cf3a0 EDX: df841848
[ 3.580611] ESI: d8aca000 EDI: d8bc7394 EBP: ddcfdd98 ESP: ddcfdd6c
[ 3.582526] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 EFLAGS: 00210282
[ 3.599178] CR0: 80050033 CR2: fffffffe CR3: 0207a000 CR4: 00000690
[ 3.600901] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[ 3.602610] DR6: fffe0ff0 DR7: 00000400
[ 3.603912] Call Trace:
[ 3.604992] ? eth_header+0xd0/0xd0
[ 3.606253] dsa_register_switch+0x887/0x980
[ 3.607609] ? dev_get_by_name_rcu+0x5a/0x70
[ 3.608994] dsa_loop_drv_probe+0xb8/0xe0
[ 3.610324] mdio_probe+0x29/0x70
[ 3.611529] really_probe+0xd4/0x2b0
[ 3.612801] driver_probe_device+0x49/0x150
[ 3.614195] __device_attach_driver+0x69/0x90
[ 3.615644] ? driver_allows_async_probing+0x60/0x60
[ 3.617188] bus_for_each_drv+0x52/0x90
[ 3.618540] __device_attach+0xc1/0x120
[ 3.619852] ? driver_allows_async_probing+0x60/0x60
[ 3.621388] device_initial_probe+0xd/0x10
[ 3.622837] bus_probe_device+0x77/0x80
[ 3.624188] deferred_probe_work_func+0x62/0x90
[ 3.625624] process_one_work+0x169/0x2d0
[ 3.627021] worker_thread+0x1bd/0x410
[ 3.628361] kthread+0xf0/0x110
[ 3.629558] ? process_one_work+0x2d0/0x2d0
[ 3.630945] ? kthread_create_worker_on_cpu+0x20/0x20
[ 3.632536] ret_from_fork+0x2e/0x38
[ 3.633901] Modules linked in:
[ 3.635151] CR2: 00000000fffffffe
[ 3.636399] ---[ end trace 5657bdc477915e61 ]---
[ 3.637916] EIP: dsa_slave_create+0x9b/0x3f0
# HH:MM RESULT GOOD BAD GOOD_BUT_DIRTY DIRTY_NOT_BAD
git bisect start 0b60bd2503e98ee3fad7b90437080909c734266b 37624b58542fb9f2d9a70e6ea006ef8a5f66c30b --
git bisect good b90f1a013cbf6434f4604001752fcc15835dc5ce # 15:06 G 11 0 0 0 Merge 'shenki/dev-5.1' into devel-catchup-201905061421
git bisect bad c30b7d576676a88d075b489cde75e2383252c618 # 15:32 B 0 11 26 0 Merge 'jpirko-mlxsw/net_next_queue' into devel-catchup-201905061421
git bisect good 16111991dbd72407566ac29acf7892cd15c85bd9 # 15:48 G 10 0 0 0 Merge branch '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue
git bisect good 1d2a8a138c2a1462099ba45d1c5bcd9a576ced2a # 15:55 G 10 0 0 0 net: aquantia: link interrupt handling function
git bisect good f9b628d61faef9b6d411f13cf4be41470b7a7adb # 16:14 G 10 0 0 0 rtw88: add license for Makefile
git bisect good c0b14a0854fab0a0164aabfe49a76aae9216fe97 # 16:22 G 10 0 0 0 tipc: fix missing Name entries due to half-failover
git bisect good ba6223fc2f59a0a507e7a03203ab007042e13a4f # 17:13 G 11 0 0 0 Merge branch '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue
git bisect bad c8f8207ca6311be99ac855691490cd8764a9e31d # 17:36 B 0 11 26 0 Merge branch 'of_net-Add-NVMEM-support-to-of_get_mac_address'
git bisect good 55e4398d4ee578094fb38f25af175629a24675d5 # 17:53 G 10 0 0 0 bnxt_en: Add support for PCIe statistics
git bisect good 8ef5cc4f3c12dfb2fde74762feaff13c0d6b685c # 18:01 G 11 0 0 0 Merge branch 'bnxt_en-Driver-updates'
git bisect bad adfb3cb2c52e7bf215ac5d97344e4ed57ab9ce9f # 18:17 B 0 8 28 5 net: usb: support of_get_mac_address new ERR_PTR error
git bisect bad 687e3d5550c7b0e4dca0179103741a44cd3f7864 # 18:37 B 0 7 22 0 dt-bindings: doc: reflect new NVMEM of_get_mac_address behaviour
git bisect bad d01f449c008a3f41fa44c603e28a7452ab8f8e68 # 18:46 B 0 4 19 0 of_net: add NVMEM support to of_get_mac_address
# first bad commit: [d01f449c008a3f41fa44c603e28a7452ab8f8e68] of_net: add NVMEM support to of_get_mac_address
git bisect good 8ef5cc4f3c12dfb2fde74762feaff13c0d6b685c # 18:57 G 30 0 0 0 Merge branch 'bnxt_en-Driver-updates'
# extra tests with debug options
git bisect bad d01f449c008a3f41fa44c603e28a7452ab8f8e68 # 19:13 B 0 8 23 0 of_net: add NVMEM support to of_get_mac_address
# extra tests on HEAD of linux-devel/devel-catchup-201905061421
git bisect bad 0b60bd2503e98ee3fad7b90437080909c734266b # 19:14 B 0 17 35 0 0day head guard for 'devel-catchup-201905061421'
# extra tests on tree/branch linux-devel/devel-catchup-201905061421
git bisect bad 0b60bd2503e98ee3fad7b90437080909c734266b # 00:40 B 0 17 35 0 0day head guard for 'devel-catchup-201905061421'
# extra tests with first bad commit reverted
git bisect good 9179687eb52dfdf1d21fc45023cfbe429c813a86 # 00:56 G 11 0 0 0 Revert "of_net: add NVMEM support to of_get_mac_address"
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/lkp Intel Corporation
1 year, 5 months
Re: [LKP] [PATCH] fsnotify: fix unlink performance regression
by Al Viro
On Mon, May 06, 2019 at 03:43:24PM +0300, Amir Goldstein wrote:
> OK. What do you have to say about this statement?
>
> Because fsnotify_nameremove() is called from d_delete() with negative
> or unhashed dentry, d_move() is not expected on this dentry, so it is
> safe to use d_parent/d_name without take_dentry_name_snapshot().
>
> I assume it is not correct, but cannot figure out why.
> Under what circumstances is d_move() expected to move an unhashed
> dentry and hash it?
For starters, d_splice_alias() picking an exising alias for given directory
inode.
> My other thought is why is fsnotify_nameremove() in d_delete() and
> not in vfs_unlink()/vfs_rmdir() under parent inode lock like the rest
> of the fsnotify_create/fsnotify_move hooks?
>
> In what case would we need the fsnotify event that is not coming
> from vfs_unlink()/vfs_rmdir()?
*snort*
You can thank those who whine about notifications on sysfs/devpts/whatnot.
Go talk to them if you wish, but don't ask me to translate what you'll get
into something coherent - I'd never been able to.
1 year, 5 months
[rcutorture] ba26c41d98: WARNING:at_kernel/rcu/rcutorture.c:#rcu_torture_writer[rcutorture]
by kernel test robot
FYI, we noticed the following commit (built with gcc-7):
commit: ba26c41d985d7c66c6198e0e22cd287434d83a3e ("rcutorture: Fix stutter_wait() return value and freelist checks")
https://git.kernel.org/cgit/linux/kernel/git/paulmck/linux-rcu.git dev.2019.04.28a
in testcase: rcutorture
with following parameters:
runtime: 300s
test: default
torture_type: srcu
test-description: rcutorture is rcutorture kernel module load/unload test.
test-url: https://www.kernel.org/doc/Documentation/RCU/torture.txt
on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 4G
caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
+--------------------------------------------------------------------+------------+------------+
| | fe661764bc | ba26c41d98 |
+--------------------------------------------------------------------+------------+------------+
| boot_successes | 314 | 278 |
| boot_failures | 18 | 38 |
| BUG:kernel_reboot-without-warning_in_test_stage | 5 | 12 |
| WARNING:at_net/sched/sch_generic.c:#dev_watchdog | 13 | 12 |
| RIP:dev_watchdog | 13 | 12 |
| RIP:ring_buffer_lock_reserve | 1 | |
| WARNING:at_kernel/rcu/rcutorture.c:#rcu_torture_writer[rcutorture] | 0 | 14 |
| RIP:rcu_torture_writer[rcutorture] | 0 | 14 |
| calltrace:irq_exit | 0 | 8 |
| calltrace:rcu_torture_free | 0 | 1 |
| RIP:__rb_reserve_next | 0 | 1 |
| RIP:lock_release | 0 | 1 |
+--------------------------------------------------------------------+------------+------------+
If you fix the issue, kindly add following tag
Reported-by: kernel test robot <rong.a.chen(a)intel.com>
[ 348.855994] WARNING: CPU: 1 PID: 605 at kernel/rcu/rcutorture.c:1019 rcu_torture_writer+0x5e5/0x820 [rcutorture]
[ 348.858990] Modules linked in: rcutorture(-) torture ppdev parport_pc crct10dif_pclmul crc32c_intel parport rtc_cmos qemu_fw_cfg
[ 348.862052] CPU: 1 PID: 605 Comm: rcu_torture_wri Not tainted 5.1.0-rc1-00106-gba26c41 #1
[ 348.864209] RIP: 0010:rcu_torture_writer+0x5e5/0x820 [rcutorture]
[ 348.866629] Code: 08 a0 49 8b 06 49 39 c6 75 22 48 8b 55 00 49 8d 46 e8 48 39 c2 74 15 41 8b 56 f8 4c 89 ee 48 c7 c7 d1 83 05 a0 e8 cb 11 0c e1 <0f> 0b 49 83 c6 30 4c 39 f3 75 cd e8 9b 68 ff ff 84 c0 0f 84 97 fc
[ 348.871198] RSP: 0018:ffff8881185c3eb8 EFLAGS: 00010296
[ 348.872442] RAX: 0000000000000027 RBX: ffffffffa0085f78 RCX: 0000000000000006
[ 348.874957] RDX: 0000000000000007 RSI: 0000000000000006 RDI: ffff88813bbd1880
[ 348.876675] RBP: ffffffffa0085f68 R08: 0000005dd95e1368 R09: 0000000000000000
[ 348.878449] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffa005a670
[ 348.880333] R13: ffffffffa0058800 R14: ffffffffa0084dd8 R15: ffffffffa0085750
[ 348.882924] FS: 0000000000000000(0000) GS:ffff88813ba00000(0000) knlGS:0000000000000000
[ 348.885859] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 348.887797] CR2: 00007f89476dc030 CR3: 000000011d91e000 CR4: 00000000000406a0
[ 348.889811] Call Trace:
[ 348.890529] ? rcu_torture_pipe_update+0x100/0x100 [rcutorture]
[ 348.892393] kthread+0x11c/0x130
[ 348.893012] ? kthread_stop+0x210/0x210
[ 348.893792] ret_from_fork+0x24/0x30
[ 348.894627] irq event stamp: 570574
[ 348.895346] hardirqs last enabled at (570573): [<ffffffff8117d893>] console_unlock+0x533/0x5c0
[ 348.897770] hardirqs last disabled at (570574): [<ffffffff81003417>] trace_hardirqs_off_thunk+0x1a/0x1c
[ 348.900200] softirqs last enabled at (570562): [<ffffffff81c00414>] __do_softirq+0x414/0x450
[ 348.902187] softirqs last disabled at (570549): [<ffffffff8111d557>] irq_exit+0x67/0xd0
[ 348.904076] ---[ end trace 497e668e1ed2342a ]---
To reproduce:
# build kernel
cd linux
cp config-5.1.0-rc1-00106-gba26c41 .config
make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 olddefconfig
make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 prepare
make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 modules_prepare
make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 SHELL=/bin/bash
make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 bzImage
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k <bzImage> job-script # job-script is attached in this email
Thanks,
Rong Chen
1 year, 5 months
7d172b8be5 ("devlink: add warning in case driver does not set .."): WARNING: CPU: 1 PID: 22 at net/core/devlink.c:5396 devlink_port_type_warn
by kernel test robot
Greetings,
0day kernel testing robot got the below dmesg and the first bad commit is
https://github.com/0day-ci/linux/commits/Jiri-Pirko/devlink-add-warning-i...
commit 7d172b8be57c2150fa5ce9642b677859aba7aec0
Author: Jiri Pirko <jiri(a)mellanox.com>
AuthorDate: Fri May 3 13:31:53 2019 +0200
Commit: 0day robot <lkp(a)intel.com>
CommitDate: Sat May 4 08:20:50 2019 +0800
devlink: add warning in case driver does not set port type
Prevent misbehavior of drivers who would not set port type for longer
period of time. Drivers should always set port type. Do WARN if that
happens.
Note that it is perfectly fine to temporarily not have the type set,
during initialization and port type change.
Signed-off-by: Jiri Pirko <jiri(a)mellanox.com>
8ef988b914 Merge branch 'NXP-SJA1105-DSA-driver'
7d172b8be5 devlink: add warning in case driver does not set port type
+-------------------------------------------------------+------------+------------+
| | 8ef988b914 | 7d172b8be5 |
+-------------------------------------------------------+------------+------------+
| boot_successes | 208 | 52 |
| boot_failures | 0 | 22 |
| WARNING:at_net/core/devlink.c:#devlink_port_type_warn | 0 | 22 |
| EIP:devlink_port_type_warn | 0 | 22 |
+-------------------------------------------------------+------------+------------+
If you fix the issue, kindly add following tag
Reported-by: kernel test robot <lkp(a)intel.com>
[ 1362.653807] random: get_random_u32 called from arch_rnd+0x43/0x70 with crng_init=0
[ 1362.712594] random: get_random_u32 called from load_elf_binary+0x5d5/0x1bb0 with crng_init=0
[ 1362.737961] random: get_random_u32 called from arch_align_stack+0x3b/0x50 with crng_init=0
[ 1363.554081] ------------[ cut here ]------------
[ 1363.591666] Type was not set for devlink port.
[ 1363.592092] WARNING: CPU: 1 PID: 22 at net/core/devlink.c:5396 devlink_port_type_warn+0x35/0x60
[ 1363.655098] CPU: 1 PID: 22 Comm: kworker/1:1 Not tainted 5.1.0-rc7-01593-g7d172b8 #1
[ 1363.685204] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
[ 1363.717647] Workqueue: events devlink_port_type_warn
[ 1363.737700] EIP: devlink_port_type_warn+0x35/0x60
[ 1363.756594] Code: 31 c9 ba 01 00 00 00 b8 68 fe 21 c4 c7 04 24 01 00 00 00 e8 5d 2f 80 fe ff 05 34 fe 77 c4 c7 04 24 2c cb ec c3 e8 ab 1a 6a fe <0f> 0b 31 c9 ba 01 00 00 00 c7 04 24 01 00 00 00 b8 50 fe 21 c4 e8
[ 1363.825423] EAX: 00000022 EBX: 00000000 ECX: 00000000 EDX: 00000000
[ 1363.849565] ESI: db5656d0 EDI: de836780 EBP: de859eec ESP: de859ee8
[ 1363.873774] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 EFLAGS: 00010286
[ 1363.899799] CR0: 80050033 CR2: b7ff5000 CR3: 1ac75000 CR4: 00000690
[ 1363.924128] Call Trace:
[ 1363.935408] process_one_work+0x547/0xb10
[ 1363.952142] ? process_one_work+0x300/0xb10
[ 1363.969801] worker_thread+0x41b/0x790
[ 1363.989184] ? process_one_work+0xb10/0xb10
[ 1364.010823] kthread+0x19d/0x1b0
[ 1364.028625] ? process_one_work+0xb10/0xb10
[ 1364.048304] ? kthread_insert_work_sanity_check+0x190/0x190
[ 1364.071889] ret_from_fork+0x19/0x24
[ 1364.088193] irq event stamp: 29212
[ 1364.103590] hardirqs last enabled at (29211): [<c113b1d5>] vprintk_emit+0x155/0x430
[ 1364.135574] hardirqs last disabled at (29212): [<c1001d3f>] trace_hardirqs_off_thunk+0xc/0x10
[ 1364.170605] softirqs last enabled at (29204): [<c308257f>] __do_softirq+0x68f/0x7f0
[ 1364.204483] softirqs last disabled at (29191): [<c1032cc7>] do_softirq_own_stack+0x37/0x50
[ 1364.240453] ---[ end trace 96d738dd7cfa4d7d ]---
[ 1364.326527] _warn_unseeded_randomness: 51 callbacks suppressed
# HH:MM RESULT GOOD BAD GOOD_BUT_DIRTY DIRTY_NOT_BAD
git bisect start 17edcb408b8dbef56f640771325d0657c5a59835 37624b58542fb9f2d9a70e6ea006ef8a5f66c30b --
git bisect bad 4d53ea7240d8051ed8a91f453af1e50e154ffc82 # 13:04 B 0 3 19 2 Merge 'linux-review/Bj-rn-T-pel/libbpf-fix-invalid-munmap-call/20190503-030514' into devel-hourly-2019050416
git bisect good a9587113c61e451a8b589da564b6802f90fa835c # 14:29 G 66 0 3 3 Merge 'linux-review/Kai-Huang/kvm-x86-Fix-L1TF-mitigation-for-shadow-MMU/20190504-020125' into devel-hourly-2019050416
git bisect bad a970f83bfc7769eb219ee7e38ac6956c43798fbe # 15:20 B 0 2 16 0 Merge 'linux-review/UPDATE-20190430-160954/YueHaibing/net-ethernet-ti-cpsw-Fix-inconsistent-IS_ERR-and-PTR_ERR-in-cpsw_probe/20190430-102018' into devel-hourly-2019050416
git bisect good 267e87a16af4e68f47cc51041cebc72e0f464388 # 16:47 G 67 0 0 0 Merge 'xfs-linux/for-next' into devel-hourly-2019050416
git bisect bad 194059aff9168c8e00d96bb599b19908bacc1d0f # 17:42 B 0 3 17 0 Merge 'pinctrl/for-next' into devel-hourly-2019050416
git bisect good 516463b981fe67f7a00c4106413aeea6ba93731d # 19:05 G 66 0 0 0 Merge 'linux-review/Dan-Carpenter/net-ll_temac-Fix-an-NULL-vs-IS_ERR-check-in-temac_open/20190504-074417' into devel-hourly-2019050416
git bisect good 9c115b5c8ffe49a1375ebc1a0fd1b8a590ebdbda # 20:21 G 67 0 0 0 Merge 'linux-review/Jorge-E-Moreira/vsock-virtio-Initialize-core-virtio-vsock-before-registering-the-driver/20190501-123012' into devel-hourly-2019050416
git bisect good 09fef901ae142362d28d81f6c2f65f89a741d0f5 # 22:54 G 72 0 0 0 Merge 'soc/samsung/dt-2' into devel-hourly-2019050416
git bisect bad b974f5969b18723dfdb66ef8c682cb819e11b844 # 23:41 B 0 1 15 0 Merge 'linux-review/Jiri-Pirko/devlink-add-warning-in-case-driver-does-not-set-port-type/20190504-082048' into devel-hourly-2019050416
git bisect bad 7d172b8be57c2150fa5ce9642b677859aba7aec0 # 00:25 B 0 2 16 0 devlink: add warning in case driver does not set port type
# first bad commit: [7d172b8be57c2150fa5ce9642b677859aba7aec0] devlink: add warning in case driver does not set port type
git bisect good 8ef988b914bd449458eb2174febb67b0f137b33c # 02:43 G 200 0 0 0 Merge branch 'NXP-SJA1105-DSA-driver'
# extra tests with debug options
git bisect bad 7d172b8be57c2150fa5ce9642b677859aba7aec0 # 03:35 B 0 1 16 1 devlink: add warning in case driver does not set port type
# extra tests on HEAD of linux-devel/devel-hourly-2019050416
git bisect bad 17edcb408b8dbef56f640771325d0657c5a59835 # 03:35 B 43 7 0 0 0day head guard for 'devel-hourly-2019050416'
# extra tests on tree/branch linux-review/Jiri-Pirko/devlink-add-warning-in-case-driver-does-not-set-port-type/20190504-082048
git bisect bad 7d172b8be57c2150fa5ce9642b677859aba7aec0 # 03:44 B 52 20 0 0 devlink: add warning in case driver does not set port type
# extra tests with first bad commit reverted
git bisect good f89d0170d51bb86414c84c46a0572e12323b74fc # 05:16 G 82 0 1 1 Revert "devlink: add warning in case driver does not set port type"
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/lkp Intel Corporation
1 year, 5 months
Re: [LKP] [PATCH] fsnotify: fix unlink performance regression
by kbuild test robot
Hi Amir,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.1-rc7 next-20190503]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Amir-Goldstein/fsnotify-fix-unli...
config: riscv-tinyconfig (attached as .config)
compiler: riscv64-linux-gcc (GCC) 8.1.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=8.1.0 make.cross ARCH=riscv
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp(a)intel.com>
All errors (new ones prefixed by >>):
In file included from fs///attr.c:15:
include/linux/fsnotify.h: In function 'fsnotify_nameremove':
>> include/linux/fsnotify.h:179:23: error: 'struct inode' has no member named 'i_fsnotify_mask'
if (!(d_inode(parent)->i_fsnotify_mask & FS_DELETE) &&
^~
>> include/linux/fsnotify.h:180:20: error: 'struct super_block' has no member named 's_fsnotify_mask'
!(dentry->d_sb->s_fsnotify_mask & FS_DELETE))
^~
vim +179 include/linux/fsnotify.h
153
154 /*
155 * fsnotify_nameremove - a filename was removed from a directory
156 *
157 * This is mostly called under parent vfs inode lock so name and
158 * dentry->d_parent should be stable. However there are some corner cases where
159 * inode lock is not held. So to be on the safe side and be reselient to future
160 * callers and out of tree users of d_delete(), we do not assume that d_parent
161 * and d_name are stable and we use dget_parent() and
162 * take_dentry_name_snapshot() to grab stable references.
163 */
164 static inline void fsnotify_nameremove(struct dentry *dentry, int isdir)
165 {
166 struct dentry *parent;
167 struct name_snapshot name;
168 __u32 mask = FS_DELETE;
169
170 /* d_delete() of pseudo inode? (e.g. __ns_get_path() playing tricks) */
171 if (IS_ROOT(dentry))
172 return;
173
174 if (isdir)
175 mask |= FS_ISDIR;
176
177 parent = dget_parent(dentry);
178 /* Avoid unneeded take_dentry_name_snapshot() */
> 179 if (!(d_inode(parent)->i_fsnotify_mask & FS_DELETE) &&
> 180 !(dentry->d_sb->s_fsnotify_mask & FS_DELETE))
181 goto out_dput;
182
183 take_dentry_name_snapshot(&name, dentry);
184
185 fsnotify(d_inode(parent), mask, d_inode(dentry), FSNOTIFY_EVENT_INODE,
186 name.name, 0);
187
188 release_dentry_name_snapshot(&name);
189
190 out_dput:
191 dput(parent);
192 }
193
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
1 year, 5 months
[devlink] 7d172b8be5: WARNING:at_net/core/devlink.c:#devlink_port_type_warn
by kernel test robot
FYI, we noticed the following commit (built with gcc-7):
commit: 7d172b8be57c2150fa5ce9642b677859aba7aec0 ("devlink: add warning in case driver does not set port type")
bash: warning:
in testcase: trinity
with following parameters:
runtime: 300s
test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/
on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 2G
caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
+-------------------------------------------------------+------------+------------+
| | 8ef988b914 | 7d172b8be5 |
+-------------------------------------------------------+------------+------------+
| boot_successes | 4 | 0 |
| boot_failures | 0 | 4 |
| WARNING:at_net/core/devlink.c:#devlink_port_type_warn | 0 | 4 |
| RIP:devlink_port_type_warn | 0 | 4 |
+-------------------------------------------------------+------------+------------+
If you fix the issue, kindly add following tag
Reported-by: kernel test robot <lkp(a)intel.com>
[ 44.924626] WARNING: CPU: 0 PID: 223 at net/core/devlink.c:5396 devlink_port_type_warn+0xc/0x10
[ 44.928075] CPU: 0 PID: 223 Comm: kworker/0:3 Tainted: G T 5.1.0-rc7-01593-g7d172b8 #1
[ 44.930382] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
[ 44.932317] Workqueue: events devlink_port_type_warn
[ 44.933858] RIP: 0010:devlink_port_type_warn+0xc/0x10
[ 44.935285] Code: eb 91 ba a6 ff ff ff eb b1 ba f4 ff ff ff eb aa 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 c7 c7 50 3d 6a 82 e8 94 e3 74 ff <0f> 0b c3 90 41 55 41 54 41 89 f5 55 53 48 89 fb 49 89 d4 80 7b 2c
[ 44.940208] RSP: 0000:ffffc9000043fe68 EFLAGS: 00010292
[ 44.941632] RAX: 0000000000000022 RBX: ffff88806506aaa0 RCX: 0000000000000006
[ 44.943516] RDX: 0000000000000006 RSI: ffff88807fbe6ca0 RDI: ffff88807fbe6a40
[ 44.945078] RBP: ffffc9000043fec8 R08: 0000000000000000 R09: 0000000000000000
[ 44.946714] R10: ffffc9000043fd88 R11: 0000000000000000 R12: ffffffff8285f3a0
[ 44.948410] R13: ffff88807b8c2600 R14: 0000000000000000 R15: ffff88806506aaa8
[ 44.950069] FS: 0000000000000000(0000) GS:ffffffff82848000(0000) knlGS:0000000000000000
[ 44.951940] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 44.953245] CR2: 0000565234e78030 CR3: 000000007e7af000 CR4: 00000000000006f0
[ 44.954870] DR0: 00007f5493f29000 DR1: 0000000000000000 DR2: 0000000000000000
[ 44.956508] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
[ 44.958168] Call Trace:
[ 44.958772] ? process_one_work+0x252/0x570
[ 44.959820] ? worker_thread+0x37/0x380
[ 44.960650] ? process_one_work+0x570/0x570
[ 44.961666] ? kthread+0x117/0x130
[ 44.962435] ? __kthread_create_on_node+0x180/0x180
[ 44.963626] ? ret_from_fork+0x24/0x30
[ 44.964455] irq event stamp: 5984
[ 44.965271] hardirqs last enabled at (5983): [<ffffffff8114d088>] vprintk_emit+0xf8/0x270
[ 44.967144] hardirqs last disabled at (5984): [<ffffffff81002e55>] trace_hardirqs_off_thunk+0x1a/0x1c
[ 44.969511] softirqs last enabled at (5902): [<ffffffff81306cb8>] nfs_write_completion+0x138/0x140
[ 44.971664] softirqs last disabled at (5898): [<ffffffff8121a419>] wb_wakeup_delayed+0x29/0x60
[ 44.973677] ---[ end trace 5f94219778cf162c ]---
To reproduce:
# build kernel
cd linux
cp config-5.1.0-rc7-01593-g7d172b8 .config
make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 olddefconfig
make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 prepare
make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 modules_prepare
make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 SHELL=/bin/bash
make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 bzImage
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k <bzImage> job-script # job-script is attached in this email
Thanks,
lkp
1 year, 5 months
Re: [LKP] [PATCH] fsnotify: fix unlink performance regression
by Al Viro
On Sun, May 05, 2019 at 04:19:02PM +0300, Amir Goldstein wrote:
> I have made an analysis of callers to d_delete() and found that all callers
> either hold parent inode lock or name is stable for another reason:
> https://lore.kernel.org/linux-fsdevel/20190104090357.GD22409@quack2.suse.cz/
>
> But Jan preferred to keep take_dentry_name_snapshot() to be safe.
> I think the right thing to do is assert that parent inode is locked or
> no rename op in d_delete() and take the lock in ceph/ocfs2 to conform
> to the standard.
Any messing with the locking in ceph_fill_trace() would have to come
with very detailed proof of correctness, convincingly stable wrt
future changes in ceph...
1 year, 5 months
Re: [LKP] [PATCH] fsnotify: fix unlink performance regression
by Al Viro
On Sun, May 05, 2019 at 12:15:49PM +0300, Amir Goldstein wrote:
> __fsnotify_parent() has an optimization in place to avoid unneeded
> take_dentry_name_snapshot(). When fsnotify_nameremove() was changed
> not to call __fsnotify_parent(), we left out the optimization.
> Kernel test robot reported a 5% performance regression in concurrent
> unlink() workload.
>
> Reported-by: kernel test robot <rong.a.chen(a)intel.com>
> Link: https://lore.kernel.org/lkml/20190505062153.GG29809@shao2-debian/
> Link: https://lore.kernel.org/linux-fsdevel/20190104090357.GD22409@quack2.suse.cz/
> Fixes: 5f02a8776384 ("fsnotify: annotate directory entry modification events")
> Signed-off-by: Amir Goldstein <amir73il(a)gmail.com>
> ---
>
> Jan,
>
> The linked 5.1-rc1 performance regression report came with bad timing.
> Not sure if Linus is planning an rc8. If not, you will probably not
> see this before the 5.1 release and we shall have to queue it for 5.2
> and backport to stable 5.1.
>
> I crafted the patch so it applies cleanly both to master and Al's
> for-next branch (there are some fsnotify changes in work.dcache).
Charming... What about rename() and matching regressions there?
1 year, 5 months