Re: [PATCH 1/3 RESEND] sched: Remove __rcu annotation from cred pointer
On Mon, May 25, 2020 at 09:17:41AM -0400, Richard Guy Briggs wrote: > On 2020-05-24 13:41, Amol Grover wrote: > > On Thu, Apr 02, 2020 at 11:26:38AM +0530, Amol Grover wrote: > > > task_struct::cred (subjective credentials) is *always* used > > > task-synchronously, hence, does not require RCU semantics. > > > > > > task_struct::real_cred (objective credentials) can be used in > > > RCU context and its __rcu annotation is retained. > > > > > > However, task_struct::cred and task_struct::real_cred *may* > > > point to the same object, hence, the object pointed to by > > > task_struct::cred *may* have RCU delayed freeing. > > > > > > Suggested-by: Jann Horn > > > Co-developed-by: Joel Fernandes (Google) > > > Signed-off-by: Joel Fernandes (Google) > > > Signed-off-by: Amol Grover > > > > Hello everyone, > > > > Could you please go through patches 1/3 and 2/3 and if deemed OK, give > > your acks. I sent the original patch in beginning of February (~4 months > > back) and resent the patches again in beginning of April due to lack of > > traffic. Paul Moore was kind enough to ack twice - the 3/3 and its > > resend patch. However these 2 patches still remain. I'd really > > appreciate if someone reviewed them. > > I asked on April 3 which upstream tree you expect this patchset to go > through and I did not see a reply. Do you have a specific target or is > the large addressee list assuming someone else is taking this set? All > we have seen is that it is not intended to go through the audit tree. > Apologies for it. As Paul Moore replied, initially I assumed this patchset to not go through the audit tree as the audit specific changes were secondary to the main change (though certainly I did not think which upstream tree the patchset would go through). But now I am okay with the patchset making it to upstream via audit tree if it is fine by the maintainers. Thanks Amol > > Thanks > > Amol > > - RGB > > -- > Richard Guy Briggs > Sr. S/W Engineer, Kernel Security, Base Operating Systems > Remote, Ottawa, Red Hat Canada > IRC: rgb, SunRaycer > Voice: +1.647.777.2635, Internal: (81) 32635 >
Re: [PATCH 1/3 RESEND] sched: Remove __rcu annotation from cred pointer
On Thu, Apr 02, 2020 at 11:26:38AM +0530, Amol Grover wrote: > task_struct::cred (subjective credentials) is *always* used > task-synchronously, hence, does not require RCU semantics. > > task_struct::real_cred (objective credentials) can be used in > RCU context and its __rcu annotation is retained. > > However, task_struct::cred and task_struct::real_cred *may* > point to the same object, hence, the object pointed to by > task_struct::cred *may* have RCU delayed freeing. > > Suggested-by: Jann Horn > Co-developed-by: Joel Fernandes (Google) > Signed-off-by: Joel Fernandes (Google) > Signed-off-by: Amol Grover Hello everyone, Could you please go through patches 1/3 and 2/3 and if deemed OK, give your acks. I sent the original patch in beginning of February (~4 months back) and resent the patches again in beginning of April due to lack of traffic. Paul Moore was kind enough to ack twice - the 3/3 and its resend patch. However these 2 patches still remain. I'd really appreciate if someone reviewed them. Thanks Amol
Re: f410328e93 ("Default enable RCU list lockdep debugging with .."): WARNING: suspicious RCU usage
On Sat, May 23, 2020 at 02:28:36PM -0400, j...@joelfernandes.org wrote: > Madhu, > Did the creds patches make it upstream? If not, could you or Amol revive them? > Hi Joel, I was myself thinking of reviving the cred patches (but it slipped my mind). Thanks for the reminder, I'll do it. Thanks Amol > Thanks. > > > On May 23, 2020 1:44:37 PM EDT, kernel test robot wrote: > >Greetings, > > > >0day kernel testing robot got the below dmesg and the first bad commit > >is > > > >https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git > >dev.2020.05.14b > > > >commit f410328e93834f1d9c7e2f707ac05fd9e6417c27 > >Author: Madhuparna Bhowmik > >AuthorDate: Fri Feb 28 14:54:51 2020 +0530 > >Commit: Paul E. McKenney > >CommitDate: Thu May 14 10:11:39 2020 -0700 > > > >Default enable RCU list lockdep debugging with PROVE_RCU > > > >This patch default enables CONFIG_PROVE_RCU_LIST option with > >CONFIG_PROVE_RCU for RCU list lockdep debugging. > > > >With this change, RCU list lockdep debugging will be default > >enabled in CONFIG_PROVE_RCU=y kernels. > > > >Most of the RCU users (in core kernel/, drivers/, and net/ > >subsystem) have already been modified to include lockdep > >expressions hence RCU list debugging can be enabled by > >default. > > > >However, there are still chances of enountering > >false-positive lockdep splats because not everything is converted, > >in case RCU list primitives are used in non-RCU read-side critical > >section but under the protection of a lock. It would be okay to > > have a few false-positives, as long as bugs are identified, since this > >patch only affects debugging kernels. > > > >Co-developed-by: Amol Grover > >Signed-off-by: Amol Grover > >Signed-off-by: Madhuparna Bhowmik > >Acked-by: Joel Fernandes (Google) > >Signed-off-by: Paul E. McKenney > > > >df2e4807c8 torture: Add --allcpus argument to the kvm.sh script > >f410328e93 Default enable RCU list lockdep debugging with PROVE_RCU > >c1628f71b9 ubsan, kcsan: Don't combine sanitizer with kcov on clang > >+-++++ > >| > > | df2e4807c8 | f410328e93 | c1628f71b9 | > >+-++++ > >| boot_successes > > | 2 | 0 | 0 | > >| boot_failures > > | 37 | 17 | 23 | > >| Assertion_failed > > | 33 | 13 | 13 | > >| Kernel_panic-not_syncing:Attempted_to_kill_init!exitcode= > > | 35 | 15 | 21 | > >| BUG:kernel_hang_in_test_stage > > | 2 | 1 || > >| WARNING:suspicious_RCU_usage > > | 0 | 17 | 23 | > >| security/smack/smack_lsm.c:#RCU-list_traversed_in_non-reader_section > > | 0 | 17 | 23 | > >| > >security/smack/smack_access.c:#RCU-list_traversed_in_non-reader_section > >| 0 | 17 | 23 | > >+-++++ > > > >If you fix the issue, kindly add following tag > >Reported-by: kernel test robot > > > >[0.347631] . CPU clock speed is 2893.0023 MHz. > >[0.347631] . host bus clock speed is 1000.0027 MHz. > >[0.347677] smpboot: CPU0: Intel Common KVM processor (family: 0xf, > >model: 0x6, stepping: 0x1) > >[0.348602] > >[0.348635] = > >[0.348962] WARNING: suspicious RCU usage > >[0.349295] 5.7.0-rc2-00236-gf410328e93834 #1 Not tainted > >[0.349634] - > >[0.349962] security/smack/smack_lsm.c:354 RCU-list traversed in > >non-reader section!! > >[0.350634] > >[0.350634] other info that might help us debug this: > >[0.350634] > >[0.351278] > >[0.351278] rcu_scheduler_active = 1, debug_locks = 1 > >[0.351675] no locks held by kthre
Re: WARNING: suspicious RCU usage with PROVE_RCU_LIST=y
On Mon, Apr 06, 2020 at 05:11:34PM +0530, Amol Grover wrote:
> Hello,
>
> With respect to the patch https://lore.kernel.org/patchwork/patch/1202512/
> I boot tested with CONFIG_PROVE_RCU_LIST=y and encountered a susppicious RCU
> usage warning in "security/apparmor/include/lib.h". I thought of going forward
> and fix it myself, however, while going through the stack trace and the actual
> code, I found that the function (__lookupn_profile) is required to be called
> with rcu_read_locK() but the splat proves it otherwise.
>
> [ 12.727582] =
> [ 12.727599] WARNING: suspicious RCU usage
> [ 12.727601] 5.5.4-stable #17 Tainted: GE
> [ 12.727602] -
> [ 12.727604] security/apparmor/include/lib.h:191 RCU-list traversed in
> non-reader section!!
> [ 12.727605]
>other info that might help us debug this:
>
> [ 12.727606]
>rcu_scheduler_active = 2, debug_locks = 1
> [ 12.727608] 2 locks held by apparmor_parser/506:
> [ 12.727609] #0: 9f0687562490 (sb_writers#10){.+.+}, at:
> vfs_write+0x140/0x1a0
> [ 12.727614] #1: 9f0687f09ca8 (>lock){+.+.}, at:
> aa_replace_profiles+0x17a/0xdd0
> [ 12.727619]
>stack backtrace:
> [ 12.727621] CPU: 3 PID: 506 Comm: apparmor_parser Tainted: GE
>5.5.4-stable #17
> [ 12.727622] Hardware name: Gigabyte Technology Co., Ltd.
> Z170-D3H/Z170-D3H-CF, BIOS F21 03/06/2017
> [ 12.727623] Call Trace:
> [ 12.727627] dump_stack+0x8f/0xd0
> [ 12.727630] __lookupn_profile+0x19c/0x1a0
> [ 12.727632] ? aa_unpack+0x51b/0x580
> [ 12.727636] __lookup_replace+0x34/0xc0
> [ 12.727640] aa_replace_profiles+0x2a0/0xdd0
> [ 12.727649] policy_update+0x106/0x370
> [ 12.727653] profile_replace+0xa3/0x110
> [ 12.727657] vfs_write+0xb9/0x1a0
> [ 12.727661] ksys_write+0x68/0xe0
> [ 12.727666] do_syscall_64+0x5c/0xe0
> [ 12.727669] entry_SYSCALL_64_after_hwframe+0x49/0xbe
> [ 12.727671] RIP: 0033:0x7ff83fec7f93
> [ 12.727673] Code: 75 05 48 83 c4 58 c3 e8 eb 41 ff ff 66 2e 0f 1f 84 00 00
> 00 00 00 90 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 01 00 00 00 0f 05 <48> 3d
> 00 f0 ff ff 77 55 c3 0f 1f 40 00 48 83 ec 28 48 89 54 24 18
> [ 12.727674] RSP: 002b:7ffcebb5c398 EFLAGS: 0246 ORIG_RAX:
> 0001
> [ 12.727676] RAX: ffda RBX: 7131 RCX:
> 7ff83fec7f93
> [ 12.727677] RDX: 7131 RSI: 5610fd804a40 RDI:
> 0006
> [ 12.727678] RBP: 5610fd804a40 R08: 7131 R09:
> 5610fd802f38
> [ 12.727680] R10: fa8a R11: 0246 R12:
> 0000
> [ 12.727681] R13: 0006 R14: 5610fd7dd490 R15:
> 7131
>
> Thanks
> Amol
Hello,
Just a friendly request to please go through the above _bug_.
Thanks
Amol
Re: linux-next boot error: WARNING: suspicious RCU usage in bpq_device_event
On Thu, May 14, 2020 at 08:24:54AM -0400, Qian Cai wrote:
>
>
> > On May 14, 2020, at 7:37 AM, syzbot
> > wrote:
> >
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:c9529331 Add linux-next specific files for 20200514
> > git tree: linux-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=17119f4810
> > kernel config: https://syzkaller.appspot.com/x/.config?x=404a80e135048067
> > dashboard link: https://syzkaller.appspot.com/bug?extid=bb82cafc737c002d11ca
> > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+bb82cafc737c002d1...@syzkaller.appspotmail.com
> >
> > =
> > WARNING: suspicious RCU usage
> > 5.7.0-rc5-next-20200514-syzkaller #0 Not tainted
> > -
> > drivers/net/hamradio/bpqether.c:149 RCU-list traversed in non-reader
> > section!!
>
> How about teaching the bot to always CC Madhuparna and Amol for those
> RCU-list bug reports?
>
Sounds good to me if this indeed is possible.
> >
> > other info that might help us debug this:
> >
> >
> > rcu_scheduler_active = 2, debug_locks = 1
> > 1 lock held by ip/3967:
> > #0: 8a7bad88 (rtnl_mutex){+.+.}-{3:3}, at: rtnl_lock
> > net/core/rtnetlink.c:72 [inline]
> > #0: 8a7bad88 (rtnl_mutex){+.+.}-{3:3}, at:
> > rtnetlink_rcv_msg+0x3f9/0xad0 net/core/rtnetlink.c:5458
> >
> > stack backtrace:
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > Call Trace:
> > __dump_stack lib/dump_stack.c:77 [inline]
> > dump_stack+0x18f/0x20d lib/dump_stack.c:118
> > bpq_get_ax25_dev drivers/net/hamradio/bpqether.c:149 [inline]
> > bpq_device_event+0x796/0x8ee drivers/net/hamradio/bpqether.c:538
> > notifier_call_chain+0xc0/0x230 kernel/notifier.c:83
> > call_netdevice_notifiers_info net/core/dev.c:2016 [inline]
> > call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:2001
> > call_netdevice_notifiers_extack net/core/dev.c:2028 [inline]
> > call_netdevice_notifiers net/core/dev.c:2042 [inline]
> > __dev_notify_flags+0x121/0x2c0 net/core/dev.c:8279
> > dev_change_flags+0x100/0x160 net/core/dev.c:8317
> > do_setlink+0xa1c/0x35d0 net/core/rtnetlink.c:2605
> > __rtnl_newlink+0xad0/0x1590 net/core/rtnetlink.c:3273
> > rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3398
> > rtnetlink_rcv_msg+0x44e/0xad0 net/core/rtnetlink.c:5461
> > netlink_rcv_skb+0x15a/0x430 net/netlink/af_netlink.c:2469
> > netlink_unicast_kernel net/netlink/af_netlink.c:1303 [inline]
> > netlink_unicast+0x537/0x740 net/netlink/af_netlink.c:1329
> > netlink_sendmsg+0x882/0xe10 net/netlink/af_netlink.c:1918
> > sock_sendmsg_nosec net/socket.c:652 [inline]
> > sock_sendmsg+0xcf/0x120 net/socket.c:672
> > sys_sendmsg+0x6e6/0x810 net/socket.c:2352
> > ___sys_sendmsg+0x100/0x170 net/socket.c:2406
> > __sys_sendmsg+0xe5/0x1b0 net/socket.c:2439
> > do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
> > entry_SYSCALL_64_after_hwframe+0x49/0xb3
> > RIP: 0033:0x7f76dcdfcdc7
> > Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb cd 66 0f 1f 44 00 00 8b 05 4a 49
> > 2b 00 85 c0 75 2e 48 63 ff 48 63 d2 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff
> > ff 77 01 c3 48 8b 15 a1 f0 2a 00 f7 d8 64 89 02 48
> > RSP: 002b:7ffd45eccf28 EFLAGS: 0246 ORIG_RAX: 002e
> > RAX: ffda RBX: 5ebd27cd RCX: 7f76dcdfcdc7
> > RDX: RSI: 7ffd45eccf70 RDI: 0003
> > RBP: 7ffd45eccf70 R08: 1000 R09: fefefeff77686d74
> > R10: 05e9 R11: 0246 R12: 7ffd45eccfb0
> > R13: 561a2ddea3c0 R14: 7ffd45ed5030 R15:
> > ip (3967) used greatest stack depth: 23144 bytes left
> >
> >
> > ---
> > This bug is generated by a bot. It may contain errors.
> > See https://goo.gl/tpsmEJ for more information about syzbot.
> > syzbot engineers can be reached at syzkal...@googlegroups.com.
> >
> > syzbot will keep track of this bug report. See:
> > https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
>
[PATCH net v2 1/2] ipmr: Fix RCU list debugging warning
ipmr_for_each_table() macro uses list_for_each_entry_rcu()
for traversing outside of an RCU read side critical section
but under the protection of rtnl_mutex. Hence, add the
corresponding lockdep expression to silence the following
false-positive warning at boot:
[4.319347] =
[4.319349] WARNING: suspicious RCU usage
[4.319351] 5.5.4-stable #17 Tainted: GE
[4.319352] -
[4.319354] net/ipv4/ipmr.c:1757 RCU-list traversed in non-reader section!!
Fixes: f0ad0860d01e ("ipv4: ipmr: support multiple tables")
Signed-off-by: Amol Grover
---
v2:
- Add appropriate Fixes tag
net/ipv4/ipmr.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index 9cf83cc85e4a..4897f7420c8f 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -110,7 +110,8 @@ static void ipmr_expire_process(struct timer_list *t);
#ifdef CONFIG_IP_MROUTE_MULTIPLE_TABLES
#define ipmr_for_each_table(mrt, net) \
- list_for_each_entry_rcu(mrt, >ipv4.mr_tables, list)
+ list_for_each_entry_rcu(mrt, >ipv4.mr_tables, list, \
+ lockdep_rtnl_is_held())
static struct mr_table *ipmr_mr_table_iter(struct net *net,
struct mr_table *mrt)
--
2.24.1
[PATCH net v2 2/2] ipmr: Add lockdep expression to ipmr_for_each_table macro
During the initialization process, ipmr_new_table() is called
to create new tables which in turn calls ipmr_get_table() which
traverses net->ipv4.mr_tables without holding the writer lock.
However, this is safe to do so as no tables exist at this time.
Hence add a suitable lockdep expression to silence the following
false-positive warning:
=
WARNING: suspicious RCU usage
5.7.0-rc3-next-20200428-syzkaller #0 Not tainted
-
net/ipv4/ipmr.c:136 RCU-list traversed in non-reader section!!
ipmr_get_table+0x130/0x160 net/ipv4/ipmr.c:136
ipmr_new_table net/ipv4/ipmr.c:403 [inline]
ipmr_rules_init net/ipv4/ipmr.c:248 [inline]
ipmr_net_init+0x133/0x430 net/ipv4/ipmr.c:3089
Fixes: f0ad0860d01e ("ipv4: ipmr: support multiple tables")
Reported-by: syzbot+1519f497f2f9f0818...@syzkaller.appspotmail.com
Suggested-by: Jakub Kicinski
Signed-off-by: Amol Grover
---
v2:
- Change the lockdep expression to check for list emptiness at init
- Add Fixes tag
- Add Reported-by tag for syzbot report
net/ipv4/ipmr.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index 4897f7420c8f..5c218db2dede 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -109,9 +109,10 @@ static void mroute_clean_tables(struct mr_table *mrt, int
flags);
static void ipmr_expire_process(struct timer_list *t);
#ifdef CONFIG_IP_MROUTE_MULTIPLE_TABLES
-#define ipmr_for_each_table(mrt, net) \
- list_for_each_entry_rcu(mrt, >ipv4.mr_tables, list, \
- lockdep_rtnl_is_held())
+#define ipmr_for_each_table(mrt, net) \
+ list_for_each_entry_rcu(mrt, >ipv4.mr_tables, list,\
+ lockdep_rtnl_is_held() || \
+ list_empty(>ipv4.mr_tables))
static struct mr_table *ipmr_mr_table_iter(struct net *net,
struct mr_table *mrt)
--
2.24.1
Re: [PATCH net 2/2 RESEND] ipmr: Add lockdep expression to ipmr_for_each_table macro
On Tue, May 12, 2020 at 10:47:05AM +0530, Madhuparna Bhowmik wrote:
> On Sat, May 09, 2020 at 02:19:38PM -0700, Jakub Kicinski wrote:
> > On Sat, 9 May 2020 12:52:44 +0530 Amol Grover wrote:
> > > ipmr_for_each_table() uses list_for_each_entry_rcu() for
> > > traversing outside of an RCU read-side critical section but
> > > under the protection of pernet_ops_rwsem. Hence add the
> > > corresponding lockdep expression to silence the following
> > > false-positive warning at boot:
> >
> > Thanks for the fix, the warning has been annoying me as well!
> >
> > > [0.645292] =
> > > [0.645294] WARNING: suspicious RCU usage
> > > [0.645296] 5.5.4-stable #17 Not tainted
> > > [0.645297] -
> > > [0.645299] net/ipv4/ipmr.c:136 RCU-list traversed in non-reader
> > > section!!
> >
> > please provide a fuller stack trace, it would have helped the review
> >
> > > Signed-off-by: Amol Grover
> > > ---
> > > net/ipv4/ipmr.c | 7 ---
> > > 1 file changed, 4 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
> > > index 99c864eb6e34..950ffe9943da 100644
> > > --- a/net/ipv4/ipmr.c
> > > +++ b/net/ipv4/ipmr.c
> > > @@ -109,9 +109,10 @@ static void mroute_clean_tables(struct mr_table
> > > *mrt, int flags);
> > > static void ipmr_expire_process(struct timer_list *t);
> > >
> > > #ifdef CONFIG_IP_MROUTE_MULTIPLE_TABLES
> > > -#define ipmr_for_each_table(mrt, net) \
> > > - list_for_each_entry_rcu(mrt, >ipv4.mr_tables, list, \
> > > - lockdep_rtnl_is_held())
> > > +#define ipmr_for_each_table(mrt, net)
> > > \
> > > + list_for_each_entry_rcu(mrt, >ipv4.mr_tables, list,\
> > > + lockdep_rtnl_is_held() || \
> > > + lockdep_is_held(_ops_rwsem))
> >
> > This is a strange condition, IMHO. How can we be fine with either
> > lock.. This is supposed to be the writer side lock, one can't have
> > two writer side locks..
> >
> > I think what is happening is this:
> >
> > ipmr_net_init() -> ipmr_rules_init() -> ipmr_new_table()
> >
> > ipmr_new_table() returns an existing table if there is one, but
> > obviously none can exist at init. So a better fix would be:
> >
> > #define ipmr_for_each_table(mrt, net)
> > \
> > list_for_each_entry_rcu(mrt, >ipv4.mr_tables, list,\
> > lockdep_rtnl_is_held() || \
> > list_empty(>ipv4.mr_tables))
> >
Jakub, I agree, this condition looks better (and correct) than the one I
proposed. I'll do the changes as necessary. Also, do you want me to add
the full trace to the git commit body as well? I omitted it on purpose
to not make it messy.
> (adding Stephen)
>
> Hi Jakub,
>
> Thank you for your suggestion about this patch.
> Here is a stack trace for ipmr.c:
>
> [1.515015] TCP: Hash tables configured (established 8192 bind 8192)
> [1.516790] UDP hash table entries: 512 (order: 3, 49152 bytes, linear)
> [1.518177] UDP-Lite hash table entries: 512 (order: 3, 49152 bytes,
> linear)
> [1.519805]
> [1.520178] =
> [1.520982] WARNING: suspicious RCU usage
> [1.521798] 5.7.0-rc2-6-gb35af6a26b7c6f #1 Not tainted
> [1.522910] -
> [1.523671] net/ipv4/ipmr.c:136 RCU-list traversed in non-reader section!!
> [1.525218]
> [1.525218] other info that might help us debug this:
> [1.525218]
> [1.526731]
> [1.526731] rcu_scheduler_active = 2, debug_locks = 1
> [1.528004] 1 lock held by swapper/1:
> [1.528714] #0: c20be1d8 (pernet_ops_rwsem){+.+.}-{3:3}, at:
> register_pernet_subsys+0xd/0x30
> [1.530433]
> [1.530433] stack backtrace:
> [1.531262] CPU: 0 PID: 1 Comm: swapper Not tainted
> 5.7.0-rc2-6-gb35af6a26b7c6f #1
> [1.532729] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> 1.12.0-1 04/01/2014
> [1.534305] Call Trace:
> [1.534758] ? ipmr_get_table+0x3c/0x70
> [1.535430] ? ipmr_new_table+0x1c/0x60
> [1.536173] ? ipmr_net_init+0x7b/0x170
> [1.536923] ? register_pernet_subsys+0xd/0x30
> [1.537810] ? ops_init+0x1a0/0x1e0
> [1.538518] ? kmem_cache_create_usercopy+0x28a/0x350
>
Re: linux-next boot error: WARNING: suspicious RCU usage in ipmr_get_table
On Tue, Apr 28, 2020 at 10:28:41AM -0400, Qian Cai wrote:
>
>
> > On Apr 28, 2020, at 10:11 AM, Madhuparna Bhowmik
> > wrote:
> >
> > On Tue, Apr 28, 2020 at 09:56:59AM -0400, Qian Cai wrote:
> >>
> >>
> >>> On Apr 28, 2020, at 4:57 AM, Dmitry Vyukov wrote:
> >>>> net/ipv4/ipmr.c:136 RCU-list traversed in non-reader section!!
> >>
> >> https://lore.kernel.org/netdev/20200222063835.14328-2-frextr...@gmail.com/
> >>
> >> Never been picked up for a few months due to some reasons. You could
> >> probably
> >> need to convince David, Paul, Steven or Linus to unblock the bot or carry
> >> patches
> >> on your own?
> >>
> >>>> net/ipv6/ip6mr.c:124 RCU-list traversed in non-reader section!!
> >>
> >> Not sure about this if anyone is working on it. Adding a few people...
> >>
> > I will have a look at this one.
> >
> >>>>
> >>>> other info that might help us debug this:
> >>>>
> >>>>
> >>>> rcu_scheduler_active = 2, debug_locks = 1
> >>>> 1 lock held by swapper/0/1:
> >>>> #0: 8a5a6330 (pernet_ops_rwsem){+.+.}-{3:3}, at:
> >>>> register_pernet_subsys+0x16/0x40 net/core/net_namespace.c:1257
> >>>>
> >>>> stack backtrace:
> >>>> CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> >>>> 5.7.0-rc3-next-20200428-syzkaller #0
> >>>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> >>>> Google 01/01/2011
> >>>> Call Trace:
> >>>> __dump_stack lib/dump_stack.c:77 [inline]
> >>>> dump_stack+0x18f/0x20d lib/dump_stack.c:118
> >>>> ip6mr_get_table+0x153/0x180 net/ipv6/ip6mr.c:124
> >>>> ip6mr_new_table+0x1b/0x70 net/ipv6/ip6mr.c:382
> >>>> ip6mr_rules_init net/ipv6/ip6mr.c:236 [inline]
> >>>> ip6mr_net_init+0x133/0x3f0 net/ipv6/ip6mr.c:1310
> >>>> ops_init+0xaf/0x420 net/core/net_namespace.c:151
> >>>> __register_pernet_operations net/core/net_namespace.c:1140 [inline]
> >>>> register_pernet_operations+0x346/0x840 net/core/net_namespace.c:1217
> >>>> register_pernet_subsys+0x25/0x40 net/core/net_namespace.c:1258
> >>>> ip6_mr_init+0x49/0x152 net/ipv6/ip6mr.c:1363
> >>>> inet6_init+0x1d7/0x6dc net/ipv6/af_inet6.c:1032
> >>>> do_one_initcall+0x10a/0x7d0 init/main.c:1159
> >>>> do_initcall_level init/main.c:1232 [inline]
> >>>> do_initcalls init/main.c:1248 [inline]
> >>>> do_basic_setup init/main.c:1268 [inline]
> >>>> kernel_init_freeable+0x501/0x5ae init/main.c:1454
> >>>> kernel_init+0xd/0x1bb init/main.c:1359
> >>>> ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:351
> >>>>
> >>>> =
> >>>> WARNING: suspicious RCU usage
> >>>> 5.7.0-rc3-next-20200428-syzkaller #0 Not tainted
> >>>> -
> >>>> security/integrity/evm/evm_main.c:231 RCU-list traversed in non-reader
> >>>> section!!
> >>
> >> Ditto.
> >>
> > I am working on this one(evm_main.c). I am in touch with the maintaners
> > and I will fix this one soon.
>
> It would be great if you guys could test under KVM as well. Here are
> quite a few false positives that I personally may never found enough
> time to silence them.
>
Hey Madhuparna,
Do you want me to take a look at these if you're not already working
on them?
Thanks
Amol
> [ 9403.765413][T61744] =
> [ 9403.786541][T61744] WARNING: suspicious RCU usage
> [ 9403.807865][T61744] 5.7.0-rc1-next-20200417 #4 Tainted: G L
> [ 9403.838945][T61744] -
> [ 9403.860099][T61744] arch/x86/kvm/mmu/page_track.c:257 RCU-list traversed
> in non-reader section!!
> [ 9403.901270][T61744]
> [ 9403.901270][T61744] other info that might help us debug this:
> [ 9403.901270][T61744]
> [ 9403.951032][T61744]
> [ 9403.951032][T61744] rcu_scheduler_active = 2, debug_locks = 1
> [ 9403.986890][T61744] 2 locks held by qemu-kvm/61744:
> [ 9404.008862][T61744] #0: c90008a390a8 (>slots_lock){+.+.}-{3:3},
> at: kvm_set_memory_region+0x22/0x60 [kvm]
> [ 9404.055627][T61744] #1: c90008a429e8 (>track_srcu){}-{0:0},
> at: kvm_page_track_flush_slot+0x46/0x149 [kvm]
> [ 9404.104997][T61744]
> [ 9404.104997][T61744] stack backtrace:
&
[PATCH net 2/2 RESEND] ipmr: Add lockdep expression to ipmr_for_each_table macro
ipmr_for_each_table() uses list_for_each_entry_rcu() for traversing outside of an RCU read-side critical section but under the protection of pernet_ops_rwsem. Hence add the corresponding lockdep expression to silence the following false-positive warning at boot: [0.645292] = [0.645294] WARNING: suspicious RCU usage [0.645296] 5.5.4-stable #17 Not tainted [0.645297] - [0.645299] net/ipv4/ipmr.c:136 RCU-list traversed in non-reader section!! Signed-off-by: Amol Grover --- net/ipv4/ipmr.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c index 99c864eb6e34..950ffe9943da 100644 --- a/net/ipv4/ipmr.c +++ b/net/ipv4/ipmr.c @@ -109,9 +109,10 @@ static void mroute_clean_tables(struct mr_table *mrt, int flags); static void ipmr_expire_process(struct timer_list *t); #ifdef CONFIG_IP_MROUTE_MULTIPLE_TABLES -#define ipmr_for_each_table(mrt, net) \ - list_for_each_entry_rcu(mrt, >ipv4.mr_tables, list, \ - lockdep_rtnl_is_held()) +#define ipmr_for_each_table(mrt, net) \ + list_for_each_entry_rcu(mrt, >ipv4.mr_tables, list,\ + lockdep_rtnl_is_held() || \ + lockdep_is_held(_ops_rwsem)) static struct mr_table *ipmr_mr_table_iter(struct net *net, struct mr_table *mrt) -- 2.24.1
[PATCH net 1/2 RESEND] ipmr: Fix RCU list debugging warning
ipmr_for_each_table() macro uses list_for_each_entry_rcu() for traversing outside of an RCU read side critical section but under the protection of rtnl_mutex. Hence, add the corresponding lockdep expression to silence the following false-positive warning at boot: [4.319347] = [4.319349] WARNING: suspicious RCU usage [4.319351] 5.5.4-stable #17 Tainted: GE [4.319352] - [4.319354] net/ipv4/ipmr.c:1757 RCU-list traversed in non-reader section!! Signed-off-by: Amol Grover --- net/ipv4/ipmr.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c index 6e68def66822..99c864eb6e34 100644 --- a/net/ipv4/ipmr.c +++ b/net/ipv4/ipmr.c @@ -110,7 +110,8 @@ static void ipmr_expire_process(struct timer_list *t); #ifdef CONFIG_IP_MROUTE_MULTIPLE_TABLES #define ipmr_for_each_table(mrt, net) \ - list_for_each_entry_rcu(mrt, >ipv4.mr_tables, list) + list_for_each_entry_rcu(mrt, >ipv4.mr_tables, list, \ + lockdep_rtnl_is_held()) static struct mr_table *ipmr_mr_table_iter(struct net *net, struct mr_table *mrt) -- 2.24.1
Re: linux-next boot error: WARNING: suspicious RCU usage in ipmr_get_table
On Thu, May 07, 2020 at 06:26:01AM +1000, Stephen Rothwell wrote: > Hi all, > > On Thu, 7 May 2020 06:16:35 +1000 Stephen Rothwell > wrote: > > > > Hi Qian, > > > > On Tue, 28 Apr 2020 09:56:59 -0400 Qian Cai wrote: > > > > > > > On Apr 28, 2020, at 4:57 AM, Dmitry Vyukov wrote: > > > > > > > >> net/ipv4/ipmr.c:136 RCU-list traversed in non-reader section!! > > > > > > https://lore.kernel.org/netdev/20200222063835.14328-2-frextr...@gmail.com/ > > > > > > Never been picked up for a few months due to some reasons. You could > > > probably > > > need to convince David, Paul, Steven or Linus to unblock the bot or carry > > > patches > > > on your own? > > > > Did you resubmit the patch series as Dave Miller asked you to (now that > > net-next is based on v5.7-rc1+)? > > In any case, I have added the 2 commits in this series to my fixes tree > from today - I will remove them when some other tree has a solution > applied. > Hi Stephen I'll follow up with David regarding this patch series. Thanks Amol > -- > Cheers, > Stephen Rothwell
Re: linux-next boot error: WARNING: suspicious RCU usage in ipmr_get_table
On Tue, Apr 28, 2020 at 09:56:59AM -0400, Qian Cai wrote:
>
>
> > On Apr 28, 2020, at 4:57 AM, Dmitry Vyukov wrote:
> >> net/ipv4/ipmr.c:136 RCU-list traversed in non-reader section!!
>
> https://lore.kernel.org/netdev/20200222063835.14328-2-frextr...@gmail.com/
>
> Never been picked up for a few months due to some reasons. You could probably
> need to convince David, Paul, Steven or Linus to unblock the bot or carry
> patches
> on your own?
>
> >> net/ipv6/ip6mr.c:124 RCU-list traversed in non-reader section!!
>
> Not sure about this if anyone is working on it. Adding a few people...
>
> >>
> >> other info that might help us debug this:
> >>
> >>
> >> rcu_scheduler_active = 2, debug_locks = 1
> >> 1 lock held by swapper/0/1:
> >> #0: 8a5a6330 (pernet_ops_rwsem){+.+.}-{3:3}, at:
> >> register_pernet_subsys+0x16/0x40 net/core/net_namespace.c:1257
> >>
> >> stack backtrace:
> >> CPU: 0 PID: 1 Comm: swapper/0 Not tainted
> >> 5.7.0-rc3-next-20200428-syzkaller #0
> >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> >> Google 01/01/2011
> >> Call Trace:
> >> __dump_stack lib/dump_stack.c:77 [inline]
> >> dump_stack+0x18f/0x20d lib/dump_stack.c:118
> >> ip6mr_get_table+0x153/0x180 net/ipv6/ip6mr.c:124
> >> ip6mr_new_table+0x1b/0x70 net/ipv6/ip6mr.c:382
> >> ip6mr_rules_init net/ipv6/ip6mr.c:236 [inline]
> >> ip6mr_net_init+0x133/0x3f0 net/ipv6/ip6mr.c:1310
> >> ops_init+0xaf/0x420 net/core/net_namespace.c:151
> >> __register_pernet_operations net/core/net_namespace.c:1140 [inline]
> >> register_pernet_operations+0x346/0x840 net/core/net_namespace.c:1217
> >> register_pernet_subsys+0x25/0x40 net/core/net_namespace.c:1258
> >> ip6_mr_init+0x49/0x152 net/ipv6/ip6mr.c:1363
> >> inet6_init+0x1d7/0x6dc net/ipv6/af_inet6.c:1032
> >> do_one_initcall+0x10a/0x7d0 init/main.c:1159
> >> do_initcall_level init/main.c:1232 [inline]
> >> do_initcalls init/main.c:1248 [inline]
> >> do_basic_setup init/main.c:1268 [inline]
> >> kernel_init_freeable+0x501/0x5ae init/main.c:1454
> >> kernel_init+0xd/0x1bb init/main.c:1359
> >> ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:351
> >>
> >> =
> >> WARNING: suspicious RCU usage
> >> 5.7.0-rc3-next-20200428-syzkaller #0 Not tainted
> >> -
> >> security/integrity/evm/evm_main.c:231 RCU-list traversed in non-reader
> >> section!!
>
> Ditto.
>
> >>
> >> other info that might help us debug this:
> >>
> >>
> >> rcu_scheduler_active = 2, debug_locks = 1
> >> 2 locks held by systemd/1:
> >> #0: 888098dfa450 (sb_writers#8){.+.+}-{0:0}, at: sb_start_write
> >> include/linux/fs.h:1659 [inline]
> >> #0: 888098dfa450 (sb_writers#8){.+.+}-{0:0}, at:
> >> mnt_want_write+0x3a/0xb0 fs/namespace.c:354
> >> #1: 8880988e8310 (>i_mutex_dir_key#6){}-{3:3}, at:
> >> inode_lock include/linux/fs.h:799 [inline]
> >> #1: 8880988e8310 (>i_mutex_dir_key#6){}-{3:3}, at:
> >> vfs_setxattr+0x92/0xf0 fs/xattr.c:219
> >>
> >> stack backtrace:
> >> CPU: 0 PID: 1 Comm: systemd Not tainted 5.7.0-rc3-next-20200428-syzkaller
> >> #0
> >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> >> Google 01/01/2011
> >> Call Trace:
> >> __dump_stack lib/dump_stack.c:77 [inline]
> >> dump_stack+0x18f/0x20d lib/dump_stack.c:118
> >> evm_protected_xattr+0x1c2/0x210 security/integrity/evm/evm_main.c:231
> >> evm_protect_xattr.isra.0+0xb6/0x3d0 security/integrity/evm/evm_main.c:318
> >> evm_inode_setxattr+0xc4/0xf0 security/integrity/evm/evm_main.c:387
> >> security_inode_setxattr+0x18f/0x200 security/security.c:1297
> >> vfs_setxattr+0xa7/0xf0 fs/xattr.c:220
> >> setxattr+0x23d/0x330 fs/xattr.c:451
> >> path_setxattr+0x170/0x190 fs/xattr.c:470
> >> __do_sys_setxattr fs/xattr.c:485 [inline]
> >> __se_sys_setxattr fs/xattr.c:481 [inline]
> >> __x64_sys_setxattr+0xc0/0x160 fs/xattr.c:481
> >> do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:295
> >> entry_SYSCALL_64_after_hwframe+0x49/0xb3
> >> RIP: 0033:0x7fe46005e67a
> >> Code: 48 8b 0d 21 18 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00
> >> 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 bc 00 00 00 0f 05 <48> 3d 01 f0 ff
> >> ff 73 01 c3 48 8b 0d ee 17 2b 00 f7 d8 64 89 01 48
> >> RSP: 002b:7fffef423568 EFLAGS: 0246 ORIG_RAX: 00bc
> >> RAX: ffda RBX: RCX: 7fe46005e67a
> >> RDX: 7fffef4235e0 RSI: 556ea53ddf9b RDI: 556ea6766760
> >> RBP: 556ea53ddf9b R08: R09: 0030
> >> R10: 0020 R11: 0246 R12: 7fffef4235e0
> >> R13: 0020 R14: R15: 556ea6751700
> >>
> >> security/device_cgroup.c:357 RCU-list traversed in non-reader section!!
>
> https://lore.kernel.org/lkml/20200406105950.GA2285@workstation-kernel-dev/
>
> The same story. The patch had been ignored for a while.
>
Thank you for reminding! I will resend the patches and try to get them
merged ASAP.
>
>
[PATCH] staging: media: Fix alignment to match open parenthesis
CHECK: Alignment should match open parenthesis Signed-off-by: Amol Grover --- drivers/staging/media/imx/imx-media-csi.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/media/imx/imx-media-csi.c b/drivers/staging/media/imx/imx-media-csi.c index 367e39f5b382..773b3d6964cf 100644 --- a/drivers/staging/media/imx/imx-media-csi.c +++ b/drivers/staging/media/imx/imx-media-csi.c @@ -627,8 +627,8 @@ static int csi_idmac_start(struct csi_priv *priv) } priv->nfb4eof_irq = ipu_idmac_channel_irq(priv->ipu, -priv->idmac_ch, -IPU_IRQ_NFB4EOF); + priv->idmac_ch, + IPU_IRQ_NFB4EOF); ret = devm_request_irq(priv->dev, priv->nfb4eof_irq, csi_idmac_nfb4eof_interrupt, 0, "imx-smfc-nfb4eof", priv); @@ -1472,7 +1472,7 @@ static void csi_try_fmt(struct csi_priv *priv, imx_media_enum_mbus_format(, 0, CS_SEL_ANY, false); *cc = imx_media_find_mbus_format(code, - CS_SEL_ANY, false); +CS_SEL_ANY, false); sdformat->format.code = (*cc)->codes[0]; } -- 2.20.1
Re: [PATCH 4.19 00/90] 4.19.58-stable review
On Mon, Jul 08, 2019 at 05:12:27PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.19.58 release. > There are 90 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed 10 Jul 2019 03:03:52 PM UTC. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.58-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-4.19.y > and the diffstat can be found below. > > thanks, > > greg k-h x86_64 compiled and booted; no regressions between 4.19.57 and 4.19.58-rc1 among dmesg and kselftests. Thanks, -amol
Re: [PATCH 5.1 00/96] 5.1.17-stable review
On Mon, Jul 08, 2019 at 05:12:32PM +0200, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 5.1.17 release. > There are 96 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Wed 10 Jul 2019 03:03:52 PM UTC. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.1.17-rc1.gz > or in the git tree and branch at: > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > linux-5.1.y > and the diffstat can be found below. > > thanks, > > greg k-h Compiled, booted; no regressions between 5.1.16 and 5.1.17-rc1 for dmesg, and kselftests (at least those that did run in my environment).
Re: [PATCH 3.16 000/129] 3.16.70-rc1 review
On Sun, Jul 07, 2019 at 05:54:16PM +0100, Ben Hutchings wrote: > This is the start of the stable review cycle for the 3.16.70 release. > There are 129 patches in this series, which will be posted as responses > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Tue Jul 09 20:00:00 UTC 2019. > Anything received after that time might be too late. > > All the patches have also been committed to the linux-3.16.y-rc branch of > https://git.kernel.org/pub/scm/linux/kernel/git/bwh/linux-stable-rc.git . > A shortlog and diffstat can be found below. > > Ben. x86_64 (on debian-8.11.1), compiled and booted successfully. No regressions (between 3.16.69 and 3.16.70-rc1). Thanks, -amol
[PATCH] ide: use BIT() macro for defining bit-flags
The BIT() macro is available for defining the required bit-flags.
Since it operates on an unsigned value and expands to an unsigned result,
using it, instead of an expression like (1 << x), also fixes the problem
of shifting a signed 32-bit value by 31 bits (e.g. 1 << 31).
Signed-off-by: Amol Surati
---
include/linux/ide.h | 272 ++--
1 file changed, 136 insertions(+), 136 deletions(-)
diff --git a/include/linux/ide.h b/include/linux/ide.h
index 971cf76a78a0..46b771d6999e 100644
--- a/include/linux/ide.h
+++ b/include/linux/ide.h
@@ -253,9 +253,9 @@ static inline void ide_std_init_ports(struct ide_hw *hw,
* Special Driver Flags
*/
enum {
- IDE_SFLAG_SET_GEOMETRY = (1 << 0),
- IDE_SFLAG_RECALIBRATE = (1 << 1),
- IDE_SFLAG_SET_MULTMODE = (1 << 2),
+ IDE_SFLAG_SET_GEOMETRY = BIT(0),
+ IDE_SFLAG_RECALIBRATE = BIT(1),
+ IDE_SFLAG_SET_MULTMODE = BIT(2),
};
/*
@@ -267,13 +267,13 @@ typedef enum {
} ide_startstop_t;
enum {
- IDE_VALID_ERROR = (1 << 1),
+ IDE_VALID_ERROR = BIT(1),
IDE_VALID_FEATURE = IDE_VALID_ERROR,
- IDE_VALID_NSECT = (1 << 2),
- IDE_VALID_LBAL = (1 << 3),
- IDE_VALID_LBAM = (1 << 4),
- IDE_VALID_LBAH = (1 << 5),
- IDE_VALID_DEVICE= (1 << 6),
+ IDE_VALID_NSECT = BIT(2),
+ IDE_VALID_LBAL = BIT(3),
+ IDE_VALID_LBAM = BIT(4),
+ IDE_VALID_LBAH = BIT(5),
+ IDE_VALID_DEVICE= BIT(6),
IDE_VALID_LBA = IDE_VALID_LBAL |
IDE_VALID_LBAM |
IDE_VALID_LBAH,
@@ -289,24 +289,24 @@ enum {
};
enum {
- IDE_TFLAG_LBA48 = (1 << 0),
- IDE_TFLAG_WRITE = (1 << 1),
- IDE_TFLAG_CUSTOM_HANDLER= (1 << 2),
- IDE_TFLAG_DMA_PIO_FALLBACK = (1 << 3),
+ IDE_TFLAG_LBA48 = BIT(0),
+ IDE_TFLAG_WRITE = BIT(1),
+ IDE_TFLAG_CUSTOM_HANDLER= BIT(2),
+ IDE_TFLAG_DMA_PIO_FALLBACK = BIT(3),
/* force 16-bit I/O operations */
- IDE_TFLAG_IO_16BIT = (1 << 4),
+ IDE_TFLAG_IO_16BIT = BIT(4),
/* struct ide_cmd was allocated using kmalloc() */
- IDE_TFLAG_DYN = (1 << 5),
- IDE_TFLAG_FS= (1 << 6),
- IDE_TFLAG_MULTI_PIO = (1 << 7),
- IDE_TFLAG_SET_XFER = (1 << 8),
+ IDE_TFLAG_DYN = BIT(5),
+ IDE_TFLAG_FS= BIT(6),
+ IDE_TFLAG_MULTI_PIO = BIT(7),
+ IDE_TFLAG_SET_XFER = BIT(8),
};
enum {
- IDE_FTFLAG_FLAGGED = (1 << 0),
- IDE_FTFLAG_SET_IN_FLAGS = (1 << 1),
- IDE_FTFLAG_OUT_DATA = (1 << 2),
- IDE_FTFLAG_IN_DATA = (1 << 3),
+ IDE_FTFLAG_FLAGGED = BIT(0),
+ IDE_FTFLAG_SET_IN_FLAGS = BIT(1),
+ IDE_FTFLAG_OUT_DATA = BIT(2),
+ IDE_FTFLAG_IN_DATA = BIT(3),
};
struct ide_taskfile {
@@ -357,13 +357,13 @@ struct ide_cmd {
/* ATAPI packet command flags */
enum {
/* set when an error is considered normal - no retry (ide-tape) */
- PC_FLAG_ABORT = (1 << 0),
- PC_FLAG_SUPPRESS_ERROR = (1 << 1),
- PC_FLAG_WAIT_FOR_DSC= (1 << 2),
- PC_FLAG_DMA_OK = (1 << 3),
- PC_FLAG_DMA_IN_PROGRESS = (1 << 4),
- PC_FLAG_DMA_ERROR = (1 << 5),
- PC_FLAG_WRITING = (1 << 6),
+ PC_FLAG_ABORT = BIT(0),
+ PC_FLAG_SUPPRESS_ERROR = BIT(1),
+ PC_FLAG_WAIT_FOR_DSC= BIT(2),
+ PC_FLAG_DMA_OK = BIT(3),
+ PC_FLAG_DMA_IN_PROGRESS = BIT(4),
+ PC_FLAG_DMA_ERROR = BIT(5),
+ PC_FLAG_WRITING = BIT(6),
};
#define ATAPI_WAIT_PC (60 * HZ)
@@ -417,111 +417,111 @@ struct ide_disk_ops {
/* ATAPI device flags */
enum {
- IDE_AFLAG_DRQ_INTERRUPT = (1 << 0),
+ IDE_AFLAG_DRQ_INTERRUPT = BIT(0),
/* ide-cd */
/* Drive cannot eject the disc. */
- IDE_AFLAG_NO_EJECT = (1 << 1),
+ IDE_AFLAG_NO_EJECT = BIT(1),
/* Drive is a pre ATAPI 1.2 drive. */
- IDE_AFLAG_PRE_ATAPI12 = (
Initrd and Initramfs
Hi, For an embedded developers perspective, Is there any other advantage of using initramfs over initrd apart from RAMFS benefits over RAMDISK ? Please CC me Thanks Amol - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Initrd and Initramfs
Hi, For an embedded developers perspective, Is there any other advantage of using initramfs over initrd apart from RAMFS benefits over RAMDISK ? Please CC me Thanks Amol - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
