drivers/gpu/drm/nouveau/nv04_fence.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
This patch fixes a sparse warning with this message
"warning:dereference of noderef expression". In this context it means we
are dereferencing a __rcu tagged pointer directly.
We should not be directly dereferencing a rcu pointer. To get a normal
(non __rcu tagged pointer) from a __rcu tagged pointer we are using the
function unrcu_pointer(...). The non __rcu tagged pointer then can be
dereferenced just like a normal pointer.
I tested with qemu with this command
qemu-system-x86_64 \
-m 2G \
-smp 2 \
-kernel bzImage \
-append "console=ttyS0 root=/dev/sda earlyprintk=serial net.ifnames=0" \
-drive file=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
with lockdep enabled.
Signed-off-by: Abhinav Singh <singhabhinav9051571833@gmail.com>
---
v1 -> v2 : Replaced the rcu_dereference(...) with unrcu_pointer(...) and
also removed the rcu locking and unlocking function call.
v2 -> v3 : Changed the description of the patch to match it with the actual
implementation.
drivers/gpu/drm/nouveau/nv04_fence.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nv04_fence.c b/drivers/gpu/drm/nouveau/nv04_fence.c
index 5b71a5a5cd85..cdbc75e3d1f6 100644
--- a/drivers/gpu/drm/nouveau/nv04_fence.c
+++ b/drivers/gpu/drm/nouveau/nv04_fence.c
@@ -39,7 +39,7 @@ struct nv04_fence_priv {
static int
nv04_fence_emit(struct nouveau_fence *fence)
{
- struct nvif_push *push = fence->channel->chan.push;
+ struct nvif_push *push = unrcu_pointer(fence->channel)->chan.push;
int ret = PUSH_WAIT(push, 2);
if (ret == 0) {
PUSH_NVSQ(push, NV_SW, 0x0150, fence->base.seqno);
--
2.39.2
On 11/13/23 20:13, Abhinav Singh wrote:
> This patch fixes a sparse warning with this message
> "warning:dereference of noderef expression". In this context it means we
> are dereferencing a __rcu tagged pointer directly.
>
> We should not be directly dereferencing a rcu pointer. To get a normal
> (non __rcu tagged pointer) from a __rcu tagged pointer we are using the
> function unrcu_pointer(...). The non __rcu tagged pointer then can be
> dereferenced just like a normal pointer.
>
> I tested with qemu with this command
> qemu-system-x86_64 \
> -m 2G \
> -smp 2 \
> -kernel bzImage \
> -append "console=ttyS0 root=/dev/sda earlyprintk=serial net.ifnames=0" \
> -drive file=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
> with lockdep enabled.
>
> Signed-off-by: Abhinav Singh <singhabhinav9051571833@gmail.com>
Applied, thanks!
There are a few more such occurrences. [1][2] Plan to fix them as well?
[1] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/nouveau/nv10_fence.c#L35
[2] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/nouveau/nv84_fence.c#L88
> ---
> v1 -> v2 : Replaced the rcu_dereference(...) with unrcu_pointer(...) and
> also removed the rcu locking and unlocking function call.
> v2 -> v3 : Changed the description of the patch to match it with the actual
> implementation.
>
> drivers/gpu/drm/nouveau/nv04_fence.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nv04_fence.c b/drivers/gpu/drm/nouveau/nv04_fence.c
> index 5b71a5a5cd85..cdbc75e3d1f6 100644
> --- a/drivers/gpu/drm/nouveau/nv04_fence.c
> +++ b/drivers/gpu/drm/nouveau/nv04_fence.c
> @@ -39,7 +39,7 @@ struct nv04_fence_priv {
> static int
> nv04_fence_emit(struct nouveau_fence *fence)
> {
> - struct nvif_push *push = fence->channel->chan.push;
> + struct nvif_push *push = unrcu_pointer(fence->channel)->chan.push;
> int ret = PUSH_WAIT(push, 2);
> if (ret == 0) {
> PUSH_NVSQ(push, NV_SW, 0x0150, fence->base.seqno);
On 11/21/23 06:50, Danilo Krummrich wrote:
> On 11/13/23 20:13, Abhinav Singh wrote:
>> This patch fixes a sparse warning with this message
>> "warning:dereference of noderef expression". In this context it means we
>> are dereferencing a __rcu tagged pointer directly.
>>
>> We should not be directly dereferencing a rcu pointer. To get a normal
>> (non __rcu tagged pointer) from a __rcu tagged pointer we are using the
>> function unrcu_pointer(...). The non __rcu tagged pointer then can be
>> dereferenced just like a normal pointer.
>>
>> I tested with qemu with this command
>> qemu-system-x86_64 \
>> -m 2G \
>> -smp 2 \
>> -kernel bzImage \
>> -append "console=ttyS0 root=/dev/sda earlyprintk=serial
>> net.ifnames=0" \
>> -drive file=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
>> with lockdep enabled.
>>
>> Signed-off-by: Abhinav Singh <singhabhinav9051571833@gmail.com>
>
> Applied, thanks!
>
> There are a few more such occurrences. [1][2] Plan to fix them as well?
>
> [1]
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/nouveau/nv10_fence.c#L35
> [2]
> https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/nouveau/nv84_fence.c#L88
>
>> ---
>> v1 -> v2 : Replaced the rcu_dereference(...) with unrcu_pointer(...) and
>> also removed the rcu locking and unlocking function call.
>> v2 -> v3 : Changed the description of the patch to match it with the
>> actual
>> implementation.
>>
>> drivers/gpu/drm/nouveau/nv04_fence.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/nouveau/nv04_fence.c
>> b/drivers/gpu/drm/nouveau/nv04_fence.c
>> index 5b71a5a5cd85..cdbc75e3d1f6 100644
>> --- a/drivers/gpu/drm/nouveau/nv04_fence.c
>> +++ b/drivers/gpu/drm/nouveau/nv04_fence.c
>> @@ -39,7 +39,7 @@ struct nv04_fence_priv {
>> static int
>> nv04_fence_emit(struct nouveau_fence *fence)
>> {
>> - struct nvif_push *push = fence->channel->chan.push;
>> + struct nvif_push *push = unrcu_pointer(fence->channel)->chan.push;
>> int ret = PUSH_WAIT(push, 2);
>> if (ret == 0) {
>> PUSH_NVSQ(push, NV_SW, 0x0150, fence->base.seqno);
>
Thanks a lot for merging this.
Yeah sure I will submit the patch for the issues soon.
Regards,
Abhinav Singh
On 11/14/23 00:43, Abhinav Singh wrote:
> This patch fixes a sparse warning with this message
> "warning:dereference of noderef expression". In this context it means we
> are dereferencing a __rcu tagged pointer directly.
>
> We should not be directly dereferencing a rcu pointer. To get a normal
> (non __rcu tagged pointer) from a __rcu tagged pointer we are using the
> function unrcu_pointer(...). The non __rcu tagged pointer then can be
> dereferenced just like a normal pointer.
>
> I tested with qemu with this command
> qemu-system-x86_64 \
> -m 2G \
> -smp 2 \
> -kernel bzImage \
> -append "console=ttyS0 root=/dev/sda earlyprintk=serial net.ifnames=0" \
> -drive file=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
> with lockdep enabled.
>
> Signed-off-by: Abhinav Singh <singhabhinav9051571833@gmail.com>
> ---
> v1 -> v2 : Replaced the rcu_dereference(...) with unrcu_pointer(...) and
> also removed the rcu locking and unlocking function call.
> v2 -> v3 : Changed the description of the patch to match it with the actual
> implementation.
>
> drivers/gpu/drm/nouveau/nv04_fence.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nv04_fence.c b/drivers/gpu/drm/nouveau/nv04_fence.c
> index 5b71a5a5cd85..cdbc75e3d1f6 100644
> --- a/drivers/gpu/drm/nouveau/nv04_fence.c
> +++ b/drivers/gpu/drm/nouveau/nv04_fence.c
> @@ -39,7 +39,7 @@ struct nv04_fence_priv {
> static int
> nv04_fence_emit(struct nouveau_fence *fence)
> {
> - struct nvif_push *push = fence->channel->chan.push;
> + struct nvif_push *push = unrcu_pointer(fence->channel)->chan.push;
> int ret = PUSH_WAIT(push, 2);
> if (ret == 0) {
> PUSH_NVSQ(push, NV_SW, 0x0150, fence->base.seqno);
Hi, just for the sake of my own confirmation, the patch is merge ready
right? once the CI runs successfully it will be merged right?
Thank You,
Abhinav Singh
© 2016 - 2025 Red Hat, Inc.