lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 16 Feb 2013 05:26:25 +0000 From: "Liu, Chuansheng" <chuansheng.liu@...el.com> To: "mingo@...nel.org" <mingo@...nel.org>, "hpa@...or.com" <hpa@...or.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>, "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>, "a.p.zijlstra@...llo.nl" <a.p.zijlstra@...llo.nl>, "tglx@...utronix.de" <tglx@...utronix.de>, "Wu, Fengguang" <fengguang.wu@...el.com>, "Liu, Chuansheng" <chuansheng.liu@...el.com> Subject: RE: [tip:core/locking] Revert "smp: Give WARN()ing if in_interrupt() when calling smp_call_function_many()/single()" > -----Original Message----- > From: tip tree robot [mailto:tipbot@...or.com] On Behalf Of tip-bot for Ingo > Molnar > Sent: Monday, February 11, 2013 8:20 PM > To: linux-tip-commits@...r.kernel.org > Cc: linux-kernel@...r.kernel.org; hpa@...or.com; mingo@...nel.org; > a.p.zijlstra@...llo.nl; torvalds@...ux-foundation.org; > akpm@...ux-foundation.org; tglx@...utronix.de; Wu, Fengguang; Liu, > Chuansheng > Subject: [tip:core/locking] Revert "smp: Give WARN()ing if in_interrupt() when > calling smp_call_function_many()/single()" > > Commit-ID: 56624143151fdb84c32a43463864e6c12a5ebcfc > Gitweb: > http://git.kernel.org/tip/56624143151fdb84c32a43463864e6c12a5ebcfc > Author: Ingo Molnar <mingo@...nel.org> > AuthorDate: Mon, 11 Feb 2013 10:03:29 +0100 > Committer: Ingo Molnar <mingo@...nel.org> > CommitDate: Mon, 11 Feb 2013 10:03:29 +0100 > > Revert "smp: Give WARN()ing if in_interrupt() when calling > smp_call_function_many()/single()" > > This reverts commit b29f39c7c3e75a741a7da88244ec707f293ec04c. > > Fengguang Wu reported that the commit triggers a bogus warning > on the current networking tree: > > [ 229.339945] Call Trace: > [ 229.341176] [<ffffffff810353b4>] warn_slowpath_common+0x83/0x9c > [ 229.343091] [<ffffffff817089d6>] ? flow_cache_new_hashrnd+0x98/0x98 > [ 229.345105] [<ffffffff810353e7>] warn_slowpath_null+0x1a/0x1c > [ 229.346978] [<ffffffff81090793>] smp_call_function_single+0xbd/0x1c7 > [ 229.349017] [<ffffffff81090afe>] smp_call_function_many+0x121/0x23e > [ 229.350996] [<ffffffff817089d6>] ? flow_cache_new_hashrnd+0x98/0x98 > [ 229.353005] [<ffffffff81090e09>] smp_call_function+0x37/0x40 > [ 229.354860] [<ffffffff8170907e>] flow_cache_flush+0x72/0xa0 > [ 229.356735] [<ffffffff81759e33>] xfrm_dev_event+0x14/0x20 > [ 229.358545] [<ffffffff817ff8b0>] notifier_call_chain+0x65/0x95 > [ 229.360469] [<ffffffff8105ce16>] __raw_notifier_call_chain+0xe/0x10 > [ 229.362453] [<ffffffff8105ce2c>] raw_notifier_call_chain+0x14/0x16 > [ 229.364453] [<ffffffff816f63d6>] call_netdevice_notifiers+0x4a/0x4f > [ 229.366434] [<ffffffff816fa2ab>] __dev_notify_flags+0x37/0x5b > [ 229.368342] [<ffffffff816fa318>] dev_change_flags+0x49/0x54 > [ 229.370184] [<ffffffff8174574a>] devinet_ioctl+0x24f/0x542 > [ 229.372036] [<ffffffff81746975>] inet_ioctl+0x97/0xb1 > [ 229.373774] [<ffffffff816e5042>] sock_do_ioctl.constprop.42+0x18/0x37 > [ 229.375791] [<ffffffff816e5480>] sock_ioctl+0x1fd/0x20a > [ 229.377648] [<ffffffff810bb9cd>] ? > trace_buffer_lock_reserve+0x41/0x56 > [ 229.379701] [<ffffffff8112b7c6>] vfs_ioctl+0x26/0x39 > [ 229.381459] [<ffffffff8112c0d2>] do_vfs_ioctl+0x41b/0x45e > [ 229.383269] [<ffffffff8100bc3a>] ? > ftrace_raw_event_sys_enter+0x10b/0x11a > [ 229.385404] [<ffffffff817fc118>] ? retint_swapgs+0x13/0x1b > [ 229.387227] [<ffffffff8112c15a>] sys_ioctl+0x45/0x73 > [ 229.388975] [<ffffffff818034be>] tracesys+0xd0/0xd5 > > The intention of the warning is to warn about IPIs generated from > hardirq contexts. But in_interrupt() will also warn from > softirq-disabled contexts. Thanks Ingo and Fengguang's pointing out. I have written a new patch https://lkml.org/lkml/2013/2/16/1 which use the below macro to know if nmi/hard/soft irq is handling. +#define in_serving_irq() (in_nmi() || in_irq() || in_serving_softirq())
Powered by blists - more mailing lists