kernel/fork.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
This patch fixes the warning about directly dereferencing a pointer
tagged with __rcu annotation.
Dereferencing the pointers tagged with __rcu directly should
always be avoided according to the docs. There is a rcu helper
functions rcu_dereference(...) to use when dereferencing a __rcu
pointer. This functions returns the non __rcu tagged pointer.
Like normal pointer there should be a check for null case when
further dereferencing the returned dereferenced __rcu pointer.
Signed-off-by: Abhinav Singh <singhabhinav9051571833@gmail.com>
---
kernel/fork.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index 10917c3e1f03..5afb1b389a66 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -2369,7 +2369,9 @@ __latent_entropy struct task_struct *copy_process(
retval = -EAGAIN;
if (is_rlimit_overlimit(task_ucounts(p), UCOUNT_RLIMIT_NPROC, rlimit(RLIMIT_NPROC))) {
- if (p->real_cred->user != INIT_USER &&
+ const struct cred *real_cred = rcu_dereference(p->real_cred);
+
+ if (real_cred && real_cred->user != INIT_USER &&
!capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN))
goto bad_fork_cleanup_count;
}
--
2.39.2On Thu, 26 Oct 2023 03:58:11 +0530 Abhinav Singh <singhabhinav9051571833@gmail.com> wrote:
> This patch fixes the warning about directly dereferencing a pointer
> tagged with __rcu annotation.
>
> Dereferencing the pointers tagged with __rcu directly should
> always be avoided according to the docs. There is a rcu helper
> functions rcu_dereference(...) to use when dereferencing a __rcu
> pointer. This functions returns the non __rcu tagged pointer.
Seems sensible.
> Like normal pointer there should be a check for null case when
> further dereferencing the returned dereferenced __rcu pointer.
Why is this?
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -2369,7 +2369,9 @@ __latent_entropy struct task_struct *copy_process(
>
> retval = -EAGAIN;
> if (is_rlimit_overlimit(task_ucounts(p), UCOUNT_RLIMIT_NPROC, rlimit(RLIMIT_NPROC))) {
> - if (p->real_cred->user != INIT_USER &&
> + const struct cred *real_cred = rcu_dereference(p->real_cred);
> +
> + if (real_cred && real_cred->user != INIT_USER &&
> !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN))
> goto bad_fork_cleanup_count;
The old code assumes that p->read_cred cannot be NULL and the new code
does nothing to make it possible that `real_cred' can be NULL?
In other words, I see no reason to add this new check for NULL?
On 10/26/23 04:08, Andrew Morton wrote:
> On Thu, 26 Oct 2023 03:58:11 +0530 Abhinav Singh <singhabhinav9051571833@gmail.com> wrote:
>
>> This patch fixes the warning about directly dereferencing a pointer
>> tagged with __rcu annotation.
>>
>> Dereferencing the pointers tagged with __rcu directly should
>> always be avoided according to the docs. There is a rcu helper
>> functions rcu_dereference(...) to use when dereferencing a __rcu
>> pointer. This functions returns the non __rcu tagged pointer.
>
> Seems sensible.
>
>> Like normal pointer there should be a check for null case when
>> further dereferencing the returned dereferenced __rcu pointer.
>
> Why is this?
>
>> --- a/kernel/fork.c
>> +++ b/kernel/fork.c
>> @@ -2369,7 +2369,9 @@ __latent_entropy struct task_struct *copy_process(
>>
>> retval = -EAGAIN;
>> if (is_rlimit_overlimit(task_ucounts(p), UCOUNT_RLIMIT_NPROC, rlimit(RLIMIT_NPROC))) {
>> - if (p->real_cred->user != INIT_USER &&
>> + const struct cred *real_cred = rcu_dereference(p->real_cred);
>> +
>> + if (real_cred && real_cred->user != INIT_USER &&
>> !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN))
>> goto bad_fork_cleanup_count;
>
> The old code assumes that p->read_cred cannot be NULL and the new code
> does nothing to make it possible that `real_cred' can be NULL?
>
> In other words, I see no reason to add this new check for NULL?
Thank you for the response!
I thought it will be better to have check before accessing it, just so
we dont have any segmentation fault in future.
Also I just noticed there are two more places where direct dereferencing
of __rcu pointer is done in this same file. Should I do those changes in
this patch ?
On Thu, 26 Oct 2023 04:57:42 +0530 Abhinav Singh <singhabhinav9051571833@gmail.com> wrote:
> On 10/26/23 04:08, Andrew Morton wrote:
> >> +++ b/kernel/fork.c
> >> @@ -2369,7 +2369,9 @@ __latent_entropy struct task_struct *copy_process(
> >>
> >> retval = -EAGAIN;
> >> if (is_rlimit_overlimit(task_ucounts(p), UCOUNT_RLIMIT_NPROC, rlimit(RLIMIT_NPROC))) {
> >> - if (p->real_cred->user != INIT_USER &&
> >> + const struct cred *real_cred = rcu_dereference(p->real_cred);
> >> +
> >> + if (real_cred && real_cred->user != INIT_USER &&
> >> !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN))
> >> goto bad_fork_cleanup_count;
> >
> > The old code assumes that p->read_cred cannot be NULL and the new code
> > does nothing to make it possible that `real_cred' can be NULL?
> >
> > In other words, I see no reason to add this new check for NULL?
>
> Thank you for the response!
>
> I thought it will be better to have check before accessing it, just so
> we dont have any segmentation fault in future.
That would be adding code which has no effect?
> Also I just noticed there are two more places where direct dereferencing
> of __rcu pointer is done in this same file. Should I do those changes in
> this patch ?
I don't see why. rcu_dereference(p) cannot return NULL if `p' is non-NULL?
On 10/26/23 05:20, Andrew Morton wrote:
> On Thu, 26 Oct 2023 04:57:42 +0530 Abhinav Singh <singhabhinav9051571833@gmail.com> wrote:
>
>> On 10/26/23 04:08, Andrew Morton wrote:
>>>> +++ b/kernel/fork.c
>>>> @@ -2369,7 +2369,9 @@ __latent_entropy struct task_struct *copy_process(
>>>>
>>>> retval = -EAGAIN;
>>>> if (is_rlimit_overlimit(task_ucounts(p), UCOUNT_RLIMIT_NPROC, rlimit(RLIMIT_NPROC))) {
>>>> - if (p->real_cred->user != INIT_USER &&
>>>> + const struct cred *real_cred = rcu_dereference(p->real_cred);
>>>> +
>>>> + if (real_cred && real_cred->user != INIT_USER &&
>>>> !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN))
>>>> goto bad_fork_cleanup_count;
>>>
>>> The old code assumes that p->read_cred cannot be NULL and the new code
>>> does nothing to make it possible that `real_cred' can be NULL?
>>>
>>> In other words, I see no reason to add this new check for NULL?
>>
>> Thank you for the response!
>>
>> I thought it will be better to have check before accessing it, just so
>> we dont have any segmentation fault in future.
>
> That would be adding code which has no effect?
>
>> Also I just noticed there are two more places where direct dereferencing
>> of __rcu pointer is done in this same file. Should I do those changes in
>> this patch ?
>
> I don't see why. rcu_dereference(p) cannot return NULL if `p' is non-NULL?
This patch fixes the warning about directly dereferencing a pointer
tagged with __rcu annotation.
Dereferencing the pointers tagged with __rcu directly should
always be avoided according to the docs. There is a rcu helper
functions rcu_dereference(...) to use when dereferencing a __rcu
pointer. This functions returns the non __rcu tagged pointer which
can be dereferenced just like a normal pointers.
Signed-off-by: Abhinav Singh <singhabhinav9051571833@gmail.com>
---
kernel/fork.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index 10917c3e1f03..802b7bbe3d92 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -2369,7 +2369,7 @@ __latent_entropy struct task_struct *copy_process(
retval = -EAGAIN;
if (is_rlimit_overlimit(task_ucounts(p), UCOUNT_RLIMIT_NPROC, rlimit(RLIMIT_NPROC))) {
- if (p->real_cred->user != INIT_USER &&
+ if (rcu_dereference(p->real_cred)->user != INIT_USER &&
!capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN))
goto bad_fork_cleanup_count;
}
@@ -2692,7 +2692,7 @@ __latent_entropy struct task_struct *copy_process(
*/
p->signal->has_child_subreaper = p->real_parent->signal->has_child_subreaper ||
p->real_parent->signal->is_child_subreaper;
- list_add_tail(&p->sibling, &p->real_parent->children);
+ list_add_tail(&p->sibling, &(rcu_dereference(p->real_parent)->children));
list_add_tail_rcu(&p->tasks, &init_task.tasks);
attach_pid(p, PIDTYPE_TGID);
attach_pid(p, PIDTYPE_PGID);
--
2.39.2
$Subject should indicate a subsystem, also you seem to have a somewhat
random collection of Cc. It looks like dhowells is the cred guy and he's
not on.
On Thu, Oct 26, 2023 at 05:57:48PM +0530, Abhinav Singh wrote:
> This patch fixes the warning about directly dereferencing a pointer
> tagged with __rcu annotation.
>
> Dereferencing the pointers tagged with __rcu directly should
> always be avoided according to the docs. There is a rcu helper
> functions rcu_dereference(...) to use when dereferencing a __rcu
> pointer. This functions returns the non __rcu tagged pointer which
> can be dereferenced just like a normal pointers.
>
> Signed-off-by: Abhinav Singh <singhabhinav9051571833@gmail.com>
> ---
> kernel/fork.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 10917c3e1f03..802b7bbe3d92 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -2369,7 +2369,7 @@ __latent_entropy struct task_struct *copy_process(
>
> retval = -EAGAIN;
> if (is_rlimit_overlimit(task_ucounts(p), UCOUNT_RLIMIT_NPROC, rlimit(RLIMIT_NPROC))) {
> - if (p->real_cred->user != INIT_USER &&
> + if (rcu_dereference(p->real_cred)->user != INIT_USER &&
> !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN))
> goto bad_fork_cleanup_count;
> }
This seems entirely misguided and only makes the code more confusing.
AFAICT at this point @p is not life, we're constructing the new task,
but it's not yet published, therefore no concurrency possible.
Additionally we're not actually in an RCU critical section afaict.
> @@ -2692,7 +2692,7 @@ __latent_entropy struct task_struct *copy_process(
> */
> p->signal->has_child_subreaper = p->real_parent->signal->has_child_subreaper ||
> p->real_parent->signal->is_child_subreaper;
> - list_add_tail(&p->sibling, &p->real_parent->children);
> + list_add_tail(&p->sibling, &(rcu_dereference(p->real_parent)->children));
> list_add_tail_rcu(&p->tasks, &init_task.tasks);
> attach_pid(p, PIDTYPE_TGID);
> attach_pid(p, PIDTYPE_PGID);
As to the real_parent, we hold the tasklist lock, which is the write
side lock for parent stuff, so rcu dereference is pointless here.
On 10/26, Peter Zijlstra wrote:
>
> > kernel/fork.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/kernel/fork.c b/kernel/fork.c
> > index 10917c3e1f03..802b7bbe3d92 100644
> > --- a/kernel/fork.c
> > +++ b/kernel/fork.c
> > @@ -2369,7 +2369,7 @@ __latent_entropy struct task_struct *copy_process(
> >
> > retval = -EAGAIN;
> > if (is_rlimit_overlimit(task_ucounts(p), UCOUNT_RLIMIT_NPROC, rlimit(RLIMIT_NPROC))) {
> > - if (p->real_cred->user != INIT_USER &&
> > + if (rcu_dereference(p->real_cred)->user != INIT_USER &&
> > !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN))
> > goto bad_fork_cleanup_count;
> > }
>
> This seems entirely misguided and only makes the code more confusing.
>
> AFAICT at this point @p is not life, we're constructing the new task,
> but it's not yet published, therefore no concurrency possible.
> Additionally we're not actually in an RCU critical section afaict.
>
> > @@ -2692,7 +2692,7 @@ __latent_entropy struct task_struct *copy_process(
> > */
> > p->signal->has_child_subreaper = p->real_parent->signal->has_child_subreaper ||
> > p->real_parent->signal->is_child_subreaper;
> > - list_add_tail(&p->sibling, &p->real_parent->children);
> > + list_add_tail(&p->sibling, &(rcu_dereference(p->real_parent)->children));
> > list_add_tail_rcu(&p->tasks, &init_task.tasks);
> > attach_pid(p, PIDTYPE_TGID);
> > attach_pid(p, PIDTYPE_PGID);
>
> As to the real_parent, we hold the tasklist lock, which is the write
> side lock for parent stuff, so rcu dereference is pointless here.
Agreed.
Plus I don't think this change is correct, iiuc rcu_dereference() will trigger
the run-time "suspicious rcu_dereference_check() usage" warning, it is called
without rcu_read_lock().
Oleg.
This patch fixes the warning about directly dereferencing a pointer
tagged with __rcu annotation.
Dereferencing the pointers tagged with __rcu directly should
always be avoided according to the docs. There is a rcu helper
function rcu_dereference(...) to use when dereferencing a __rcu
pointer. This function returns the non __rcu tagged pointer which
can be dereferenced just like a normal pointer.
Signed-off-by: Abhinav Singh <singhabhinav9051571833@gmail.com>
---
v1 -> v2 : added rcu_dereference(...) at line 2694
v2 -> v3 : added rcu_dereference(...) at line 2695
kernel/fork.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index 10917c3e1f03..e78649974669 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -2369,7 +2369,7 @@ __latent_entropy struct task_struct *copy_process(
retval = -EAGAIN;
if (is_rlimit_overlimit(task_ucounts(p), UCOUNT_RLIMIT_NPROC, rlimit(RLIMIT_NPROC))) {
- if (p->real_cred->user != INIT_USER &&
+ if (rcu_dereference(p->real_cred)->user != INIT_USER &&
!capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN))
goto bad_fork_cleanup_count;
}
@@ -2690,9 +2690,9 @@ __latent_entropy struct task_struct *copy_process(
* tasklist_lock with adding child to the process tree
* for propagate_has_child_subreaper optimization.
*/
- p->signal->has_child_subreaper = p->real_parent->signal->has_child_subreaper ||
- p->real_parent->signal->is_child_subreaper;
- list_add_tail(&p->sibling, &p->real_parent->children);
+ p->signal->has_child_subreaper = rcu_dereference(p->real_parent)->signal->has_child_subreaper ||
+ rcu_dereference(p->real_parent)->signal->is_child_subreaper;
+ list_add_tail(&p->sibling, &rcu_dereference(p->real_parent)->children);
list_add_tail_rcu(&p->tasks, &init_task.tasks);
attach_pid(p, PIDTYPE_TGID);
attach_pid(p, PIDTYPE_PGID);
--
2.39.2On Sat, Oct 28, 2023 at 03:52:47PM +0530, Abhinav Singh wrote:
> This patch fixes the warning about directly dereferencing a pointer
> tagged with __rcu annotation.
>
> Dereferencing the pointers tagged with __rcu directly should
> always be avoided according to the docs. There is a rcu helper
> function rcu_dereference(...) to use when dereferencing a __rcu
> pointer. This function returns the non __rcu tagged pointer which
> can be dereferenced just like a normal pointer.
>
> Signed-off-by: Abhinav Singh <singhabhinav9051571833@gmail.com>
> ---
> v1 -> v2 : added rcu_dereference(...) at line 2694
> v2 -> v3 : added rcu_dereference(...) at line 2695
>
> kernel/fork.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 10917c3e1f03..e78649974669 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -2369,7 +2369,7 @@ __latent_entropy struct task_struct *copy_process(
>
> retval = -EAGAIN;
> if (is_rlimit_overlimit(task_ucounts(p), UCOUNT_RLIMIT_NPROC, rlimit(RLIMIT_NPROC))) {
> - if (p->real_cred->user != INIT_USER &&
> + if (rcu_dereference(p->real_cred)->user != INIT_USER &&
> !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN))
> goto bad_fork_cleanup_count;
> }
> @@ -2690,9 +2690,9 @@ __latent_entropy struct task_struct *copy_process(
> * tasklist_lock with adding child to the process tree
> * for propagate_has_child_subreaper optimization.
> */
> - p->signal->has_child_subreaper = p->real_parent->signal->has_child_subreaper ||
> - p->real_parent->signal->is_child_subreaper;
> - list_add_tail(&p->sibling, &p->real_parent->children);
> + p->signal->has_child_subreaper = rcu_dereference(p->real_parent)->signal->has_child_subreaper ||
> + rcu_dereference(p->real_parent)->signal->is_child_subreaper;
> + list_add_tail(&p->sibling, &rcu_dereference(p->real_parent)->children);
> list_add_tail_rcu(&p->tasks, &init_task.tasks);
> attach_pid(p, PIDTYPE_TGID);
> attach_pid(p, PIDTYPE_PGID);
> --
> 2.39.2
You seem to just ignore review comments. NAK. I'm not going to review this anymore.
--
MST
On 10/28/23 17:50, Michael S. Tsirkin wrote:
> On Sat, Oct 28, 2023 at 03:52:47PM +0530, Abhinav Singh wrote:
>> This patch fixes the warning about directly dereferencing a pointer
>> tagged with __rcu annotation.
>>
>> Dereferencing the pointers tagged with __rcu directly should
>> always be avoided according to the docs. There is a rcu helper
>> function rcu_dereference(...) to use when dereferencing a __rcu
>> pointer. This function returns the non __rcu tagged pointer which
>> can be dereferenced just like a normal pointer.
>>
>> Signed-off-by: Abhinav Singh <singhabhinav9051571833@gmail.com>
>> ---
>> v1 -> v2 : added rcu_dereference(...) at line 2694
>> v2 -> v3 : added rcu_dereference(...) at line 2695
>>
>> kernel/fork.c | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/kernel/fork.c b/kernel/fork.c
>> index 10917c3e1f03..e78649974669 100644
>> --- a/kernel/fork.c
>> +++ b/kernel/fork.c
>> @@ -2369,7 +2369,7 @@ __latent_entropy struct task_struct *copy_process(
>>
>> retval = -EAGAIN;
>> if (is_rlimit_overlimit(task_ucounts(p), UCOUNT_RLIMIT_NPROC, rlimit(RLIMIT_NPROC))) {
>> - if (p->real_cred->user != INIT_USER &&
>> + if (rcu_dereference(p->real_cred)->user != INIT_USER &&
>> !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN))
>> goto bad_fork_cleanup_count;
>> }
>> @@ -2690,9 +2690,9 @@ __latent_entropy struct task_struct *copy_process(
>> * tasklist_lock with adding child to the process tree
>> * for propagate_has_child_subreaper optimization.
>> */
>> - p->signal->has_child_subreaper = p->real_parent->signal->has_child_subreaper ||
>> - p->real_parent->signal->is_child_subreaper;
>> - list_add_tail(&p->sibling, &p->real_parent->children);
>> + p->signal->has_child_subreaper = rcu_dereference(p->real_parent)->signal->has_child_subreaper ||
>> + rcu_dereference(p->real_parent)->signal->is_child_subreaper;
>> + list_add_tail(&p->sibling, &rcu_dereference(p->real_parent)->children);
>> list_add_tail_rcu(&p->tasks, &init_task.tasks);
>> attach_pid(p, PIDTYPE_TGID);
>> attach_pid(p, PIDTYPE_PGID);
>> --
>> 2.39.2
>
>
> You seem to just ignore review comments. NAK. I'm not going to review this anymore.
>
>
I m really sorry for ignorance and careless behaviour. This is
completely my fault, a maintainer has to do a lot of work and he cant
correct me all the times. On my defense I will only say that I was
really confused about a thing, instead of asking you question, I thought
of sending in another patch with some more information is a better
choice then a clearing my confusion by sending in a extra mail. You were
very concise and clear about your comments but MY stupidity was on
another level today. I m sorry for ignorant behaviour. And also thanks
and appreciate a lot for reviewing this patch till now to all the
maintainers.
Not sure if this patch will be reviewed again or not, but I think I
should answer the queries.
The last patch I sent, I tested with `lockdep` on (I hope "test with
`lockdep on`" means booting the kernel with lockdep enabled),
with these config options `CONFIG_PROVE_RCU` and `CONFIG_PROVE_LOCKING`
enabled and it booted just fine. To confirm if lockdep was really
enabled I found these paths inside the qemu virtual envirnoment
/proc/lockdep
/proc/lockdep_chains
/proc/lockdep_stat
/proc/locks
/proc/lock_stats
I tested the above kernel using qemu with this command
qemu-system-x86_64 \
-m 2G \
-smp 2 \
-kernel /home/abhinav/linux_work/linux/arch/x86/boot/bzImage \
-append "console=ttyS0 root=/dev/sda earlyprintk=serial net.ifnames=0" \
-drive file=/home/abhinav/linux_work/boot_images/bullseye.img,format=raw \
-net user,host=10.0.2.10,hostfwd=tcp:127.0.0.1:10021-:22 \
-net nic,model=e1000 \
-enable-kvm \
-nographic \
-pidfile vm.pid \
2>&1 | tee vm.log
I did not get warning `the run-time "suspicious rcu_dereference_check()
usage"` as mentioned by Oleg Nesterov, which mean rcu_dereference(...)
it called inside of rcu read side critical sections.
This patch fixes the warning about directly dereferencing a pointer
tagged with __rcu annotation.
Dereferencing the pointers tagged with __rcu directly should
always be avoided according to the docs. There is a rcu helper
function rcu_dereference(...) to use when dereferencing a __rcu
pointer inside rcu read side critical sections. This function
returns the non __rcu tagged pointer which can be dereferenced
just like a normal pointer.
Signed-off-by: Abhinav Singh <singhabhinav9051571833@gmail.com>
---
Link to original patch
https://lore.kernel.org/all/20231025222811.855336-1-singhabhinav9051571833@gmail.com/
Change from original -> v2 :
1. removed the null check before dereferencing the dereferenced rcu
pointer at line 2372.
2. added rcu_dereference(...) at line 2694
Changes from v2 -> v3
1. added rcu_dereference(...) at line 2693
kernel/fork.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index 10917c3e1f03..e78649974669 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -2369,7 +2369,7 @@ __latent_entropy struct task_struct *copy_process(
retval = -EAGAIN;
if (is_rlimit_overlimit(task_ucounts(p), UCOUNT_RLIMIT_NPROC, rlimit(RLIMIT_NPROC))) {
- if (p->real_cred->user != INIT_USER &&
+ if (rcu_dereference(p->real_cred)->user != INIT_USER &&
!capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN))
goto bad_fork_cleanup_count;
}
@@ -2690,9 +2690,9 @@ __latent_entropy struct task_struct *copy_process(
* tasklist_lock with adding child to the process tree
* for propagate_has_child_subreaper optimization.
*/
- p->signal->has_child_subreaper = p->real_parent->signal->has_child_subreaper ||
- p->real_parent->signal->is_child_subreaper;
- list_add_tail(&p->sibling, &p->real_parent->children);
+ p->signal->has_child_subreaper = rcu_dereference(p->real_parent)->signal->has_child_subreaper ||
+ rcu_dereference(p->real_parent)->signal->is_child_subreaper;
+ list_add_tail(&p->sibling, &rcu_dereference(p->real_parent)->children);
list_add_tail_rcu(&p->tasks, &init_task.tasks);
attach_pid(p, PIDTYPE_TGID);
attach_pid(p, PIDTYPE_PGID);
--
2.39.2On 10/28/23 15:52, Abhinav Singh wrote:
> This patch fixes the warning about directly dereferencing a pointer
> tagged with __rcu annotation.
>
> Dereferencing the pointers tagged with __rcu directly should
> always be avoided according to the docs. There is a rcu helper
> function rcu_dereference(...) to use when dereferencing a __rcu
> pointer. This function returns the non __rcu tagged pointer which
> can be dereferenced just like a normal pointer.
>
> Signed-off-by: Abhinav Singh <singhabhinav9051571833@gmail.com>
> ---
> v1 -> v2 : added rcu_dereference(...) at line 2694
> v2 -> v3 : added rcu_dereference(...) at line 2695
>
> kernel/fork.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 10917c3e1f03..e78649974669 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -2369,7 +2369,7 @@ __latent_entropy struct task_struct *copy_process(
>
> retval = -EAGAIN;
> if (is_rlimit_overlimit(task_ucounts(p), UCOUNT_RLIMIT_NPROC, rlimit(RLIMIT_NPROC))) {
> - if (p->real_cred->user != INIT_USER &&
> + if (rcu_dereference(p->real_cred)->user != INIT_USER &&
> !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN))
> goto bad_fork_cleanup_count;
> }
> @@ -2690,9 +2690,9 @@ __latent_entropy struct task_struct *copy_process(
> * tasklist_lock with adding child to the process tree
> * for propagate_has_child_subreaper optimization.
> */
> - p->signal->has_child_subreaper = p->real_parent->signal->has_child_subreaper ||
> - p->real_parent->signal->is_child_subreaper;
> - list_add_tail(&p->sibling, &p->real_parent->children);
> + p->signal->has_child_subreaper = rcu_dereference(p->real_parent)->signal->has_child_subreaper ||
> + rcu_dereference(p->real_parent)->signal->is_child_subreaper;
> + list_add_tail(&p->sibling, &rcu_dereference(p->real_parent)->children);
> list_add_tail_rcu(&p->tasks, &init_task.tasks);
> attach_pid(p, PIDTYPE_TGID);
> attach_pid(p, PIDTYPE_PGID);
I tested the above with these two config enabled, CONFIG_PROVE_LOCKING
and CONFIG_PROVE_RCU. In qemu it booted fine without any issues. I then
checked dmesg log (inside booted qemu envirnoment) for any issues with
rcu, but didnt get any error or warning.
I didnt receive any warning message "suspicious rcu_dereference_check()
usage" atleast from sparse tool or in the dmesg log as suggested by Oleg
Nesterov.
This patch fixes the warning about directly dereferencing a pointer
tagged with __rcu annotation.
Dereferencing the pointers tagged with __rcu directly should
always be avoided according to the docs. There is a rcu helper
functions rcu_dereference(...) to use when dereferencing a __rcu
pointer. This functions returns the non __rcu tagged pointer which
can be dereferenced just like a normal pointers.
Signed-off-by: Abhinav Singh <singhabhinav9051571833@gmail.com>
---
kernel/fork.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index 10917c3e1f03..802b7bbe3d92 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -2369,7 +2369,7 @@ __latent_entropy struct task_struct *copy_process(
retval = -EAGAIN;
if (is_rlimit_overlimit(task_ucounts(p), UCOUNT_RLIMIT_NPROC, rlimit(RLIMIT_NPROC))) {
- if (p->real_cred->user != INIT_USER &&
+ if (rcu_dereference(p->real_cred)->user != INIT_USER &&
!capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN))
goto bad_fork_cleanup_count;
}
@@ -2692,7 +2692,7 @@ __latent_entropy struct task_struct *copy_process(
*/
p->signal->has_child_subreaper = p->real_parent->signal->has_child_subreaper ||
p->real_parent->signal->is_child_subreaper;
- list_add_tail(&p->sibling, &p->real_parent->children);
+ list_add_tail(&p->sibling, &(rcu_dereference(p->real_parent)->children));
list_add_tail_rcu(&p->tasks, &init_task.tasks);
attach_pid(p, PIDTYPE_TGID);
attach_pid(p, PIDTYPE_PGID);
--
2.39.2On Thu, Oct 26, 2023 at 05:46:21PM +0530, Abhinav Singh wrote:
> This patch fixes the warning about directly dereferencing a pointer
> tagged with __rcu annotation.
>
> Dereferencing the pointers tagged with __rcu directly should
> always be avoided according to the docs. There is a rcu helper
> functions rcu_dereference(...) to use when dereferencing a __rcu
> pointer. This functions returns the non __rcu tagged pointer which
> can be dereferenced just like a normal pointers.
>
> Signed-off-by: Abhinav Singh <singhabhinav9051571833@gmail.com>
Well yes but these need to be called under rcu_read_lock.
Who does it here?
If no one then maybe you found an actual bug and we need to
fix it not paper over it.
> ---
> kernel/fork.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 10917c3e1f03..802b7bbe3d92 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -2369,7 +2369,7 @@ __latent_entropy struct task_struct *copy_process(
>
> retval = -EAGAIN;
> if (is_rlimit_overlimit(task_ucounts(p), UCOUNT_RLIMIT_NPROC, rlimit(RLIMIT_NPROC))) {
> - if (p->real_cred->user != INIT_USER &&
> + if (rcu_dereference(p->real_cred)->user != INIT_USER &&
> !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN))
> goto bad_fork_cleanup_count;
> }
> @@ -2692,7 +2692,7 @@ __latent_entropy struct task_struct *copy_process(
> */
> p->signal->has_child_subreaper = p->real_parent->signal->has_child_subreaper ||
> p->real_parent->signal->is_child_subreaper;
> - list_add_tail(&p->sibling, &p->real_parent->children);
> + list_add_tail(&p->sibling, &(rcu_dereference(p->real_parent)->children));
> list_add_tail_rcu(&p->tasks, &init_task.tasks);
> attach_pid(p, PIDTYPE_TGID);
> attach_pid(p, PIDTYPE_PGID);
> --
> 2.39.2
On 10/26/23, Michael S. Tsirkin <mst@redhat.com> wrote: > On Thu, Oct 26, 2023 at 05:46:21PM +0530, Abhinav Singh wrote: >> This patch fixes the warning about directly dereferencing a pointer >> tagged with __rcu annotation. >> >> Dereferencing the pointers tagged with __rcu directly should >> always be avoided according to the docs. There is a rcu helper >> functions rcu_dereference(...) to use when dereferencing a __rcu >> pointer. This functions returns the non __rcu tagged pointer which >> can be dereferenced just like a normal pointers. >> >> Signed-off-by: Abhinav Singh <singhabhinav9051571833@gmail.com> > > Well yes but these need to be called under rcu_read_lock. > Who does it here? > If no one then maybe you found an actual bug and we need to > fix it not paper over it. > There is no bug here. p is the newly created thread, ->real_cred was initialized just prior to this code and there is nobody to whack the creds from under it. Second bit in the patch changes one real_parent deref, but leaves 2 others just above it. Once more no bug since the entire thing happens under tasklist_lock, but the patch should either sort all these cases or none. I think it would help if the submitter had shown warnings they see. -- Mateusz Guzik <mjguzik gmail.com>
On Thu, Oct 26, 2023 at 04:06:24PM +0200, Mateusz Guzik wrote: > On 10/26/23, Michael S. Tsirkin <mst@redhat.com> wrote: > > On Thu, Oct 26, 2023 at 05:46:21PM +0530, Abhinav Singh wrote: > >> This patch fixes the warning about directly dereferencing a pointer > >> tagged with __rcu annotation. > >> > >> Dereferencing the pointers tagged with __rcu directly should > >> always be avoided according to the docs. There is a rcu helper > >> functions rcu_dereference(...) to use when dereferencing a __rcu > >> pointer. This functions returns the non __rcu tagged pointer which > >> can be dereferenced just like a normal pointers. > >> > >> Signed-off-by: Abhinav Singh <singhabhinav9051571833@gmail.com> > > > > Well yes but these need to be called under rcu_read_lock. > > Who does it here? > > If no one then maybe you found an actual bug and we need to > > fix it not paper over it. > > > > There is no bug here. > > p is the newly created thread, ->real_cred was initialized just prior > to this code and there is nobody to whack the creds from under it. > > Second bit in the patch changes one real_parent deref, but leaves 2 > others just above it. Once more no bug since the entire thing happens > under tasklist_lock, but the patch should either sort all these cases > or none. > > I think it would help if the submitter had shown warnings they see. Yes, and this must be tested under lockdep, which I think would spit out warnings for this patch. What should be used here I'm not sure. IIUC rcu_dereference_protected(p, 1) is discouraged now? -- MST
On 10/26/23 20:47, Michael S. Tsirkin wrote: > On Thu, Oct 26, 2023 at 04:06:24PM +0200, Mateusz Guzik wrote: >> On 10/26/23, Michael S. Tsirkin <mst@redhat.com> wrote: >>> On Thu, Oct 26, 2023 at 05:46:21PM +0530, Abhinav Singh wrote: >>>> This patch fixes the warning about directly dereferencing a pointer >>>> tagged with __rcu annotation. >>>> >>>> Dereferencing the pointers tagged with __rcu directly should >>>> always be avoided according to the docs. There is a rcu helper >>>> functions rcu_dereference(...) to use when dereferencing a __rcu >>>> pointer. This functions returns the non __rcu tagged pointer which >>>> can be dereferenced just like a normal pointers. >>>> >>>> Signed-off-by: Abhinav Singh <singhabhinav9051571833@gmail.com> >>> >>> Well yes but these need to be called under rcu_read_lock. >>> Who does it here? >>> If no one then maybe you found an actual bug and we need to >>> fix it not paper over it. >>> >> >> There is no bug here. >> >> p is the newly created thread, ->real_cred was initialized just prior >> to this code and there is nobody to whack the creds from under it. >> >> Second bit in the patch changes one real_parent deref, but leaves 2 >> others just above it. Once more no bug since the entire thing happens >> under tasklist_lock, but the patch should either sort all these cases >> or none. Sparse reported 3 similar dereferencing warning this patch contains 2 fixes for 2, but yeah I should fixed all 3 of them. >> >> I think it would help if the submitter had shown warnings they see. The warning message :- warning: dereference of noderef expression > > Yes, and this must be tested under lockdep, which I think would > spit out warnings for this patch. Not sure, but I tested this with sparse (make C=2) and after the above changes I dont get the warning. > > What should be used here I'm not sure. IIUC rcu_dereference_protected(p, 1) > is discouraged now? > Not sure but I read that, rcu_dereference should be prefered when reading and rcu_dereference_protected should when writing.
On Thu, Oct 26, 2023 at 09:07:46PM +0530, Abhinav Singh wrote: > On 10/26/23 20:47, Michael S. Tsirkin wrote: > > On Thu, Oct 26, 2023 at 04:06:24PM +0200, Mateusz Guzik wrote: > > > On 10/26/23, Michael S. Tsirkin <mst@redhat.com> wrote: > > > > On Thu, Oct 26, 2023 at 05:46:21PM +0530, Abhinav Singh wrote: > > > > > This patch fixes the warning about directly dereferencing a pointer > > > > > tagged with __rcu annotation. > > > > > > > > > > Dereferencing the pointers tagged with __rcu directly should > > > > > always be avoided according to the docs. There is a rcu helper > > > > > functions rcu_dereference(...) to use when dereferencing a __rcu > > > > > pointer. This functions returns the non __rcu tagged pointer which > > > > > can be dereferenced just like a normal pointers. > > > > > > > > > > Signed-off-by: Abhinav Singh <singhabhinav9051571833@gmail.com> > > > > > > > > Well yes but these need to be called under rcu_read_lock. > > > > Who does it here? > > > > If no one then maybe you found an actual bug and we need to > > > > fix it not paper over it. > > > > > > > > > > There is no bug here. > > > > > > p is the newly created thread, ->real_cred was initialized just prior > > > to this code and there is nobody to whack the creds from under it. > > > > > > Second bit in the patch changes one real_parent deref, but leaves 2 > > > others just above it. Once more no bug since the entire thing happens > > > under tasklist_lock, but the patch should either sort all these cases > > > or none. > Sparse reported 3 similar dereferencing warning this patch contains 2 fixes > for 2, but yeah I should fixed all 3 of them. > > > > > > I think it would help if the submitter had shown warnings they see. > The warning message :- warning: dereference of noderef expression > > > > Yes, and this must be tested under lockdep, which I think would > > spit out warnings for this patch. > Not sure, but I tested this with sparse (make C=2) and after the above > changes I dont get the warning. sparse is a static analysis tool. You should also actually test your patch. > > > > What should be used here I'm not sure. IIUC rcu_dereference_protected(p, 1) > > is discouraged now? > > > Not sure but I read that, rcu_dereference should be prefered when reading > and rcu_dereference_protected should when writing.
This patch fixes the warning about directly dereferencing a pointer
tagged with __rcu annotation.
Dereferencing the pointers tagged with __rcu directly should
always be avoided according to the docs. There is a rcu helper
functions rcu_dereference(...) to use when dereferencing a __rcu
pointer. This functions returns the non __rcu tagged pointer which
can be dereferenced just like a normal pointers.
Signed-off-by: Abhinav Singh <singhabhinav9051571833@gmail.com>
---
kernel/fork.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index 10917c3e1f03..e78649974669 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -2369,7 +2369,7 @@ __latent_entropy struct task_struct *copy_process(
retval = -EAGAIN;
if (is_rlimit_overlimit(task_ucounts(p), UCOUNT_RLIMIT_NPROC, rlimit(RLIMIT_NPROC))) {
- if (p->real_cred->user != INIT_USER &&
+ if (rcu_dereference(p->real_cred)->user != INIT_USER &&
!capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN))
goto bad_fork_cleanup_count;
}
@@ -2690,9 +2690,9 @@ __latent_entropy struct task_struct *copy_process(
* tasklist_lock with adding child to the process tree
* for propagate_has_child_subreaper optimization.
*/
- p->signal->has_child_subreaper = p->real_parent->signal->has_child_subreaper ||
- p->real_parent->signal->is_child_subreaper;
- list_add_tail(&p->sibling, &p->real_parent->children);
+ p->signal->has_child_subreaper = rcu_dereference(p->real_parent)->signal->has_child_subreaper ||
+ rcu_dereference(p->real_parent)->signal->is_child_subreaper;
+ list_add_tail(&p->sibling, &rcu_dereference(p->real_parent)->children);
list_add_tail_rcu(&p->tasks, &init_task.tasks);
attach_pid(p, PIDTYPE_TGID);
attach_pid(p, PIDTYPE_PGID);
--
2.39.2On Fri, Oct 27, 2023 at 12:07:13PM +0530, Abhinav Singh wrote:
> This patch fixes the warning about directly dereferencing a pointer
> tagged with __rcu annotation.
>
> Dereferencing the pointers tagged with __rcu directly should
> always be avoided according to the docs. There is a rcu helper
> functions
function
> rcu_dereference(...) to use when dereferencing a __rcu
> pointer.
... inside rcu read side critical sections.
> This functions
function
> returns the non __rcu tagged pointer which
> can be dereferenced just like a normal pointers.
pointer
>
>
Extra empty line here.
Did you test this with lockdep on or did you just build it?
Include info on how the patch was tested pls.
> Signed-off-by: Abhinav Singh <singhabhinav9051571833@gmail.com>
> ---
Changelog?
> kernel/fork.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 10917c3e1f03..e78649974669 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -2369,7 +2369,7 @@ __latent_entropy struct task_struct *copy_process(
>
> retval = -EAGAIN;
> if (is_rlimit_overlimit(task_ucounts(p), UCOUNT_RLIMIT_NPROC, rlimit(RLIMIT_NPROC))) {
> - if (p->real_cred->user != INIT_USER &&
> + if (rcu_dereference(p->real_cred)->user != INIT_USER &&
> !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN))
> goto bad_fork_cleanup_count;
> }
> @@ -2690,9 +2690,9 @@ __latent_entropy struct task_struct *copy_process(
> * tasklist_lock with adding child to the process tree
> * for propagate_has_child_subreaper optimization.
> */
> - p->signal->has_child_subreaper = p->real_parent->signal->has_child_subreaper ||
> - p->real_parent->signal->is_child_subreaper;
> - list_add_tail(&p->sibling, &p->real_parent->children);
> + p->signal->has_child_subreaper = rcu_dereference(p->real_parent)->signal->has_child_subreaper ||
> + rcu_dereference(p->real_parent)->signal->is_child_subreaper;
> + list_add_tail(&p->sibling, &rcu_dereference(p->real_parent)->children);
> list_add_tail_rcu(&p->tasks, &init_task.tasks);
> attach_pid(p, PIDTYPE_TGID);
> attach_pid(p, PIDTYPE_PGID);
It looks like you are calling rcu_dereference outside of
read side critical section and that does not look right to me.
Test with lockdep on.
> --
> 2.39.2
On 10/27/23 12:07, Abhinav Singh wrote:
> This patch fixes the warning about directly dereferencing a pointer
> tagged with __rcu annotation.
>
> Dereferencing the pointers tagged with __rcu directly should
> always be avoided according to the docs. There is a rcu helper
> functions rcu_dereference(...) to use when dereferencing a __rcu
> pointer. This functions returns the non __rcu tagged pointer which
> can be dereferenced just like a normal pointers.
>
>
> Signed-off-by: Abhinav Singh <singhabhinav9051571833@gmail.com>
> ---
> kernel/fork.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 10917c3e1f03..e78649974669 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -2369,7 +2369,7 @@ __latent_entropy struct task_struct *copy_process(
>
> retval = -EAGAIN;
> if (is_rlimit_overlimit(task_ucounts(p), UCOUNT_RLIMIT_NPROC, rlimit(RLIMIT_NPROC))) {
> - if (p->real_cred->user != INIT_USER &&
> + if (rcu_dereference(p->real_cred)->user != INIT_USER &&
> !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN))
> goto bad_fork_cleanup_count;
> }
> @@ -2690,9 +2690,9 @@ __latent_entropy struct task_struct *copy_process(
> * tasklist_lock with adding child to the process tree
> * for propagate_has_child_subreaper optimization.
> */
> - p->signal->has_child_subreaper = p->real_parent->signal->has_child_subreaper ||
> - p->real_parent->signal->is_child_subreaper;
> - list_add_tail(&p->sibling, &p->real_parent->children);
> + p->signal->has_child_subreaper = rcu_dereference(p->real_parent)->signal->has_child_subreaper ||
> + rcu_dereference(p->real_parent)->signal->is_child_subreaper;
> + list_add_tail(&p->sibling, &rcu_dereference(p->real_parent)->children);
> list_add_tail_rcu(&p->tasks, &init_task.tasks);
> attach_pid(p, PIDTYPE_TGID);
> attach_pid(p, PIDTYPE_PGID);
For this particular file I have resolved the rcu pointer dereferencing
issue and I have tested the above by using qemu using this command
qemu-system-x86_64 \
-m 2G \
-smp 2 \
-kernel /home/abhinav/linux_work/linux/arch/x86/boot/bzImage \
-append "console=ttyS0 root=/dev/sda earlyprintk=serial net.ifnames=0" \
-drive file=/home/abhinav/linux_work/boot_images/bullseye.img,format=raw \
-net user,host=10.0.2.10,hostfwd=tcp:127.0.0.1:10021-:22 \
-net nic,model=e1000 \
-enable-kvm \
-nographic \
-pidfile vm.pid \
2>&1 | tee vm.log
it booted without any issues.
On Fri, Oct 27, 2023 at 12:11:47PM +0530, Abhinav Singh wrote:
> On 10/27/23 12:07, Abhinav Singh wrote:
> > This patch fixes the warning about directly dereferencing a pointer
> > tagged with __rcu annotation.
> >
> > Dereferencing the pointers tagged with __rcu directly should
> > always be avoided according to the docs.
> There is a rcu helper
> > functions rcu_dereference(...) to use when dereferencing a __rcu
> > pointer. This functions returns the non __rcu tagged pointer which
> > can be dereferenced just like a normal pointers.
> >
> >
> > Signed-off-by: Abhinav Singh <singhabhinav9051571833@gmail.com>
> > ---
> > kernel/fork.c | 8 ++++----
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/kernel/fork.c b/kernel/fork.c
> > index 10917c3e1f03..e78649974669 100644
> > --- a/kernel/fork.c
> > +++ b/kernel/fork.c
> > @@ -2369,7 +2369,7 @@ __latent_entropy struct task_struct *copy_process(
> > retval = -EAGAIN;
> > if (is_rlimit_overlimit(task_ucounts(p), UCOUNT_RLIMIT_NPROC, rlimit(RLIMIT_NPROC))) {
> > - if (p->real_cred->user != INIT_USER &&
> > + if (rcu_dereference(p->real_cred)->user != INIT_USER &&
> > !capable(CAP_SYS_RESOURCE) && !capable(CAP_SYS_ADMIN))
> > goto bad_fork_cleanup_count;
> > }
> > @@ -2690,9 +2690,9 @@ __latent_entropy struct task_struct *copy_process(
> > * tasklist_lock with adding child to the process tree
> > * for propagate_has_child_subreaper optimization.
> > */
> > - p->signal->has_child_subreaper = p->real_parent->signal->has_child_subreaper ||
> > - p->real_parent->signal->is_child_subreaper;
> > - list_add_tail(&p->sibling, &p->real_parent->children);
> > + p->signal->has_child_subreaper = rcu_dereference(p->real_parent)->signal->has_child_subreaper ||
> > + rcu_dereference(p->real_parent)->signal->is_child_subreaper;
> > + list_add_tail(&p->sibling, &rcu_dereference(p->real_parent)->children);
> > list_add_tail_rcu(&p->tasks, &init_task.tasks);
> > attach_pid(p, PIDTYPE_TGID);
> > attach_pid(p, PIDTYPE_PGID);
>
> For this particular file I have resolved the rcu pointer dereferencing issue
> and I have tested the above by using qemu using this command
> qemu-system-x86_64 \
> -m 2G \
> -smp 2 \
> -kernel /home/abhinav/linux_work/linux/arch/x86/boot/bzImage \
> -append "console=ttyS0 root=/dev/sda earlyprintk=serial net.ifnames=0" \
> -drive file=/home/abhinav/linux_work/boot_images/bullseye.img,format=raw \
> -net user,host=10.0.2.10,hostfwd=tcp:127.0.0.1:10021-:22 \
> -net nic,model=e1000 \
> -enable-kvm \
> -nographic \
> -pidfile vm.pid \
> 2>&1 | tee vm.log
> it booted without any issues.
Did you enable lockdep in your kernel?
CONFIG_PROVE_LOCKING and CONFIG_PROVE_RCU in particular.
--
MST
On 2023-10-26 10:06, Mateusz Guzik wrote: > On 10/26/23, Michael S. Tsirkin <mst@redhat.com> wrote: >> On Thu, Oct 26, 2023 at 05:46:21PM +0530, Abhinav Singh wrote: >>> This patch fixes the warning about directly dereferencing a pointer >>> tagged with __rcu annotation. >>> >>> Dereferencing the pointers tagged with __rcu directly should >>> always be avoided according to the docs. There is a rcu helper >>> functions rcu_dereference(...) to use when dereferencing a __rcu >>> pointer. This functions returns the non __rcu tagged pointer which >>> can be dereferenced just like a normal pointers. >>> >>> Signed-off-by: Abhinav Singh <singhabhinav9051571833@gmail.com> >> >> Well yes but these need to be called under rcu_read_lock. >> Who does it here? >> If no one then maybe you found an actual bug and we need to >> fix it not paper over it. >> > > There is no bug here. > > p is the newly created thread, ->real_cred was initialized just prior > to this code and there is nobody to whack the creds from under it. > > Second bit in the patch changes one real_parent deref, but leaves 2 > others just above it. Once more no bug since the entire thing happens > under tasklist_lock, but the patch should either sort all these cases > or none. Drive-by comment: perhaps use rcu_dereference_protected() ? Thanks, Mathieu > > I think it would help if the submitter had shown warnings they see. > -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com
On 10/26/23, Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote: > Drive-by comment: perhaps use rcu_dereference_protected() ? > Definitely. But as I mentioned even after applying the patch there are uses which should have been reported (and consequently sorted out). If one is to bother with any of this at least the entire file should be covered. -- Mateusz Guzik <mjguzik gmail.com>
© 2016 - 2025 Red Hat, Inc.