linux-kernel - Issue with rcu_read_lock and CONFIG_PREEMPT

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CH0PR01MB71536FB1BD5ECF16E65CB3BFF26F9@CH0PR01MB7153.prod.exchangelabs.com>
Date:   Wed, 8 Dec 2021 11:35:20 +0000
From:   "Marciniszyn, Mike" <mike.marciniszyn@...nelisnetworks.com>
To:     Jason Gunthorpe <jgg@...dia.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        "Dalessandro, Dennis" <dennis.dalessandro@...nelisnetworks.com>
Subject: Issue with rcu_read_lock and CONFIG_PREEMPT_RCU

As part of testing the 5.16 rc series we noticed a new BUG message originating from check_preemption_disabled().

We submitted a patch to move a call to smp_processor_id() into an rcu critical section within the same function.

See https://lore.kernel.org/linux-rdma/20211129191958.101968.87329.stgit@awfm-01.cornelisnetworks.com/T/#u.

Much to my surprise, additional testing still sees the BUG!

Additional testing has shown that an explicit preempt_disable()/preempt_enable() silences the warning when placed around the RCU critical section.

The RCU config is:

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
CONFIG_PREEMPT_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TREE_SRCU=y
CONFIG_TASKS_RCU_GENERIC=y
CONFIG_TASKS_RCU=y
CONFIG_TASKS_RUDE_RCU=y
CONFIG_TASKS_TRACE_RCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_NEED_SEGCBLIST=y
CONFIG_RCU_NOCB_CPU=y
# end of RCU Subsystem

It looks like there is a difference between the checking in check_preemption_disabled() and the implicit preemption disabling in __rcu_read_lock().

The implicit disable looks like:

static void rcu_preempt_read_enter(void)
{
        WRITE_ONCE(current->rcu_read_lock_nesting, READ_ONCE(current->rcu_read_lock_nesting) + 1);
}

The checking code uses the x86 define preempt_count():

static __always_inline void __preempt_count_add(int val)
{
        raw_cpu_add_4(__preempt_count, val);
}

An explicit disable uses this x86 code:

static __always_inline void __preempt_count_add(int val)
{
        raw_cpu_add_4(__preempt_count, val);
}

The difference seems to be the use of __preempt_count vs. rcu_read_lock_nesting.

This can't be good...

Mike