Huh. I am relying on virt_addr_valid() rejecting NULL pointers and
things like ZERO_SIZE_PTR, which is defined as ((void *)16). It looks
like your configuration rejects NULL as an invalid virtual address,
but does not reject ZERO_SIZE_PTR. Is this the intent, given that you
are not allowed to dereference a ZERO_SIZE_PTR?
Adding the ARM64 guys on CC for their thoughts.
It is easy enough for me to make kmem_valid_obj() return false for any
address less than (say) PAGE_SIZE for the upcoming merge window, but I
figured I should check for the longer term.
Thanx, Paul
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Will Deacon <will@kernel.org> Date: 2021-01-21 21:40:29
On Thu, Jan 21, 2021 at 10:55:21AM -0800, Paul E. McKenney wrote:
On Thu, Jan 21, 2021 at 10:37:21PM +0530, Naresh Kamboju wrote:
quoted
While running rcu-torture test on qemu_arm64 and arm64 Juno-r2 device
the following kernel crash noticed. This started happening from Linux next
next-20210111 tag to next-20210121.
metadata:
git branch: master
git repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next
git describe: next-20210111
kernel-config: https://builds.tuxbuild.com/1muTTn7AfqcWvH5x2Alxifn7EUH/config
output log:
[ 621.538050] mem_dump_obj() slab test: rcu_torture_stats =
ffff0000c0a3ac40, &rhp = ffff800012debe40, rhp = ffff0000c8cba000, &z
= ffff8000091ab8e0
[ 621.546662] mem_dump_obj(ZERO_SIZE_PTR):
[ 621.546696] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000008
[...]
Huh. I am relying on virt_addr_valid() rejecting NULL pointers and
things like ZERO_SIZE_PTR, which is defined as ((void *)16). It looks
like your configuration rejects NULL as an invalid virtual address,
but does not reject ZERO_SIZE_PTR. Is this the intent, given that you
are not allowed to dereference a ZERO_SIZE_PTR?
Adding the ARM64 guys on CC for their thoughts.
From: "Paul E. McKenney" <paulmck@kernel.org> Date: 2021-01-21 21:46:54
On Thu, Jan 21, 2021 at 09:31:10PM +0000, Will Deacon wrote:
On Thu, Jan 21, 2021 at 10:55:21AM -0800, Paul E. McKenney wrote:
quoted
On Thu, Jan 21, 2021 at 10:37:21PM +0530, Naresh Kamboju wrote:
quoted
While running rcu-torture test on qemu_arm64 and arm64 Juno-r2 device
the following kernel crash noticed. This started happening from Linux next
next-20210111 tag to next-20210121.
metadata:
git branch: master
git repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next
git describe: next-20210111
kernel-config: https://builds.tuxbuild.com/1muTTn7AfqcWvH5x2Alxifn7EUH/config
output log:
[ 621.538050] mem_dump_obj() slab test: rcu_torture_stats =
ffff0000c0a3ac40, &rhp = ffff800012debe40, rhp = ffff0000c8cba000, &z
= ffff8000091ab8e0
[ 621.546662] mem_dump_obj(ZERO_SIZE_PTR):
[ 621.546696] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000008
[...]
quoted
Huh. I am relying on virt_addr_valid() rejecting NULL pointers and
things like ZERO_SIZE_PTR, which is defined as ((void *)16). It looks
like your configuration rejects NULL as an invalid virtual address,
but does not reject ZERO_SIZE_PTR. Is this the intent, given that you
are not allowed to dereference a ZERO_SIZE_PTR?
Adding the ARM64 guys on CC for their thoughts.
Very good, then my workaround (shown below for Naresh's ease of testing)
is only a short-term workaround. Yay! ;-)
Thanx, Paul
------------------------------------------------------------------------
@@ -550,7 +550,8 @@ bool kmem_valid_obj(void *object){structpage*page;-if(!virt_addr_valid(object))+/* Some arches consider ZERO_SIZE_PTR to be a valid address. */+if(object<(void*)PAGE_SIZE||!virt_addr_valid(object))returnfalse;page=virt_to_head_page(object);returnPageSlab(page);
On Fri, 22 Jan 2021 at 03:13, Paul E. McKenney [off-list ref] wrote:
On Thu, Jan 21, 2021 at 09:31:10PM +0000, Will Deacon wrote:
quoted
On Thu, Jan 21, 2021 at 10:55:21AM -0800, Paul E. McKenney wrote:
quoted
On Thu, Jan 21, 2021 at 10:37:21PM +0530, Naresh Kamboju wrote:
quoted
While running rcu-torture test on qemu_arm64 and arm64 Juno-r2 device
the following kernel crash noticed. This started happening from Linux next
next-20210111 tag to next-20210121.
metadata:
git branch: master
git repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next
git describe: next-20210111
kernel-config: https://builds.tuxbuild.com/1muTTn7AfqcWvH5x2Alxifn7EUH/config
output log:
[ 621.538050] mem_dump_obj() slab test: rcu_torture_stats =
ffff0000c0a3ac40, &rhp = ffff800012debe40, rhp = ffff0000c8cba000, &z
= ffff8000091ab8e0
[ 621.546662] mem_dump_obj(ZERO_SIZE_PTR):
[ 621.546696] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000008
[...]
quoted
Huh. I am relying on virt_addr_valid() rejecting NULL pointers and
things like ZERO_SIZE_PTR, which is defined as ((void *)16). It looks
like your configuration rejects NULL as an invalid virtual address,
but does not reject ZERO_SIZE_PTR. Is this the intent, given that you
are not allowed to dereference a ZERO_SIZE_PTR?
Adding the ARM64 guys on CC for their thoughts.
Very good, then my workaround (shown below for Naresh's ease of testing)
is only a short-term workaround. Yay! ;-)
Paul, thanks for your (short-term workaround) patch.
I have applied your patch and tested rcu-torture test on qemu_arm64 and
the reported issues has been fixed.
- Naresh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Mark Rutland <mark.rutland@arm.com> Date: 2021-01-22 10:25:21
On Thu, Jan 21, 2021 at 01:43:14PM -0800, Paul E. McKenney wrote:
On Thu, Jan 21, 2021 at 09:31:10PM +0000, Will Deacon wrote:
quoted
On Thu, Jan 21, 2021 at 10:55:21AM -0800, Paul E. McKenney wrote:
quoted
On Thu, Jan 21, 2021 at 10:37:21PM +0530, Naresh Kamboju wrote:
quoted
While running rcu-torture test on qemu_arm64 and arm64 Juno-r2 device
the following kernel crash noticed. This started happening from Linux next
next-20210111 tag to next-20210121.
metadata:
git branch: master
git repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next
git describe: next-20210111
kernel-config: https://builds.tuxbuild.com/1muTTn7AfqcWvH5x2Alxifn7EUH/config
output log:
[ 621.538050] mem_dump_obj() slab test: rcu_torture_stats =
ffff0000c0a3ac40, &rhp = ffff800012debe40, rhp = ffff0000c8cba000, &z
= ffff8000091ab8e0
[ 621.546662] mem_dump_obj(ZERO_SIZE_PTR):
[ 621.546696] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000008
[...]
quoted
Huh. I am relying on virt_addr_valid() rejecting NULL pointers and
things like ZERO_SIZE_PTR, which is defined as ((void *)16). It looks
like your configuration rejects NULL as an invalid virtual address,
but does not reject ZERO_SIZE_PTR. Is this the intent, given that you
are not allowed to dereference a ZERO_SIZE_PTR?
Adding the ARM64 guys on CC for their thoughts.
Very good, then my workaround (shown below for Naresh's ease of testing)
is only a short-term workaround. Yay! ;-)
Hopefully, though we might need to check other architectures beyond
arm64, ppc, and x86, to be certain!
Is there any other latent use of virt_addr_valid() that needs this
semantic? If so we'll probably want to backport the changes to arm64's
implementation, at least for v5.10.
Vincenzo, would you mind taking a look?
Thanks,
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Thu, Jan 21, 2021 at 01:43:14PM -0800, Paul E. McKenney wrote:
quoted
On Thu, Jan 21, 2021 at 09:31:10PM +0000, Will Deacon wrote:
quoted
On Thu, Jan 21, 2021 at 10:55:21AM -0800, Paul E. McKenney wrote:
quoted
On Thu, Jan 21, 2021 at 10:37:21PM +0530, Naresh Kamboju wrote:
quoted
While running rcu-torture test on qemu_arm64 and arm64 Juno-r2 device
the following kernel crash noticed. This started happening from Linux next
next-20210111 tag to next-20210121.
metadata:
git branch: master
git repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next
git describe: next-20210111
kernel-config: https://builds.tuxbuild.com/1muTTn7AfqcWvH5x2Alxifn7EUH/config
output log:
[ 621.538050] mem_dump_obj() slab test: rcu_torture_stats =
ffff0000c0a3ac40, &rhp = ffff800012debe40, rhp = ffff0000c8cba000, &z
= ffff8000091ab8e0
[ 621.546662] mem_dump_obj(ZERO_SIZE_PTR):
[ 621.546696] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000008
[...]
quoted
Huh. I am relying on virt_addr_valid() rejecting NULL pointers and
things like ZERO_SIZE_PTR, which is defined as ((void *)16). It looks
like your configuration rejects NULL as an invalid virtual address,
but does not reject ZERO_SIZE_PTR. Is this the intent, given that you
are not allowed to dereference a ZERO_SIZE_PTR?
Adding the ARM64 guys on CC for their thoughts.
Very good, then my workaround (shown below for Naresh's ease of testing)
is only a short-term workaround. Yay! ;-)
Hopefully, though we might need to check other architectures beyond
arm64, ppc, and x86, to be certain!
Which other architectures do you propose to verify?
Is there any other latent use of virt_addr_valid() that needs this
semantic? If so we'll probably want to backport the changes to arm64's
implementation, at least for v5.10.
Vincenzo, would you mind taking a look?
I am happy to have a look at it, but due to previous commitments I will be able
to get at it after -rc1. A quick grep shows that there are ~32 cases that might
be affected by the same semantic in the common code (left out arch/ and
drivers/). I will post the improvement for arm64 in the meantime though.
From: "Paul E. McKenney" <paulmck@kernel.org> Date: 2021-01-22 15:39:42
On Fri, Jan 22, 2021 at 03:21:07PM +0530, Naresh Kamboju wrote:
On Fri, 22 Jan 2021 at 03:13, Paul E. McKenney [off-list ref] wrote:
quoted
On Thu, Jan 21, 2021 at 09:31:10PM +0000, Will Deacon wrote:
quoted
On Thu, Jan 21, 2021 at 10:55:21AM -0800, Paul E. McKenney wrote:
quoted
On Thu, Jan 21, 2021 at 10:37:21PM +0530, Naresh Kamboju wrote:
quoted
While running rcu-torture test on qemu_arm64 and arm64 Juno-r2 device
the following kernel crash noticed. This started happening from Linux next
next-20210111 tag to next-20210121.
metadata:
git branch: master
git repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next
git describe: next-20210111
kernel-config: https://builds.tuxbuild.com/1muTTn7AfqcWvH5x2Alxifn7EUH/config
output log:
[ 621.538050] mem_dump_obj() slab test: rcu_torture_stats =
ffff0000c0a3ac40, &rhp = ffff800012debe40, rhp = ffff0000c8cba000, &z
= ffff8000091ab8e0
[ 621.546662] mem_dump_obj(ZERO_SIZE_PTR):
[ 621.546696] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000008
[...]
quoted
Huh. I am relying on virt_addr_valid() rejecting NULL pointers and
things like ZERO_SIZE_PTR, which is defined as ((void *)16). It looks
like your configuration rejects NULL as an invalid virtual address,
but does not reject ZERO_SIZE_PTR. Is this the intent, given that you
are not allowed to dereference a ZERO_SIZE_PTR?
Adding the ARM64 guys on CC for their thoughts.
Very good, then my workaround (shown below for Naresh's ease of testing)
is only a short-term workaround. Yay! ;-)
Paul, thanks for your (short-term workaround) patch.
I have applied your patch and tested rcu-torture test on qemu_arm64 and
the reported issues has been fixed.
May I add your Tested-by?
And before I forget again, good to see the rcutorture testing on a
non-x86 platform!
Thanx, Paul
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Fri, 22 Jan 2021 at 21:07, Paul E. McKenney [off-list ref] wrote:
On Fri, Jan 22, 2021 at 03:21:07PM +0530, Naresh Kamboju wrote:
quoted
On Fri, 22 Jan 2021 at 03:13, Paul E. McKenney [off-list ref] wrote:
quoted
On Thu, Jan 21, 2021 at 09:31:10PM +0000, Will Deacon wrote:
quoted
On Thu, Jan 21, 2021 at 10:55:21AM -0800, Paul E. McKenney wrote:
quoted
On Thu, Jan 21, 2021 at 10:37:21PM +0530, Naresh Kamboju wrote:
quoted
While running rcu-torture test on qemu_arm64 and arm64 Juno-r2 device
the following kernel crash noticed. This started happening from Linux next
next-20210111 tag to next-20210121.
metadata:
git branch: master
git repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next
git describe: next-20210111
kernel-config: https://builds.tuxbuild.com/1muTTn7AfqcWvH5x2Alxifn7EUH/config
output log:
[ 621.538050] mem_dump_obj() slab test: rcu_torture_stats =
ffff0000c0a3ac40, &rhp = ffff800012debe40, rhp = ffff0000c8cba000, &z
= ffff8000091ab8e0
[ 621.546662] mem_dump_obj(ZERO_SIZE_PTR):
[ 621.546696] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000008
[...]
quoted
Huh. I am relying on virt_addr_valid() rejecting NULL pointers and
things like ZERO_SIZE_PTR, which is defined as ((void *)16). It looks
like your configuration rejects NULL as an invalid virtual address,
but does not reject ZERO_SIZE_PTR. Is this the intent, given that you
are not allowed to dereference a ZERO_SIZE_PTR?
Adding the ARM64 guys on CC for their thoughts.
Very good, then my workaround (shown below for Naresh's ease of testing)
is only a short-term workaround. Yay! ;-)
Paul, thanks for your (short-term workaround) patch.
I have applied your patch and tested rcu-torture test on qemu_arm64 and
the reported issues has been fixed.
May I add your Tested-by?
Yes. Please add Reported-by and Tested-by.
And before I forget again, good to see the rcutorture testing on a
non-x86 platform!
We are running rcutorture tests on arm, arm64, i386 and x86_64.
Happy to test !
- Naresh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: "Paul E. McKenney" <paulmck@kernel.org> Date: 2021-01-22 23:24:44
On Fri, Jan 22, 2021 at 09:16:38PM +0530, Naresh Kamboju wrote:
On Fri, 22 Jan 2021 at 21:07, Paul E. McKenney [off-list ref] wrote:
quoted
On Fri, Jan 22, 2021 at 03:21:07PM +0530, Naresh Kamboju wrote:
quoted
On Fri, 22 Jan 2021 at 03:13, Paul E. McKenney [off-list ref] wrote:
quoted
On Thu, Jan 21, 2021 at 09:31:10PM +0000, Will Deacon wrote:
quoted
On Thu, Jan 21, 2021 at 10:55:21AM -0800, Paul E. McKenney wrote:
quoted
On Thu, Jan 21, 2021 at 10:37:21PM +0530, Naresh Kamboju wrote:
quoted
While running rcu-torture test on qemu_arm64 and arm64 Juno-r2 device
the following kernel crash noticed. This started happening from Linux next
next-20210111 tag to next-20210121.
metadata:
git branch: master
git repo: https://gitlab.com/Linaro/lkft/mirrors/next/linux-next
git describe: next-20210111
kernel-config: https://builds.tuxbuild.com/1muTTn7AfqcWvH5x2Alxifn7EUH/config
output log:
[ 621.538050] mem_dump_obj() slab test: rcu_torture_stats =
ffff0000c0a3ac40, &rhp = ffff800012debe40, rhp = ffff0000c8cba000, &z
= ffff8000091ab8e0
[ 621.546662] mem_dump_obj(ZERO_SIZE_PTR):
[ 621.546696] Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000008
[...]
quoted
Huh. I am relying on virt_addr_valid() rejecting NULL pointers and
things like ZERO_SIZE_PTR, which is defined as ((void *)16). It looks
like your configuration rejects NULL as an invalid virtual address,
but does not reject ZERO_SIZE_PTR. Is this the intent, given that you
are not allowed to dereference a ZERO_SIZE_PTR?
Adding the ARM64 guys on CC for their thoughts.
Very good, then my workaround (shown below for Naresh's ease of testing)
is only a short-term workaround. Yay! ;-)
Paul, thanks for your (short-term workaround) patch.
I have applied your patch and tested rcu-torture test on qemu_arm64 and
the reported issues has been fixed.
May I add your Tested-by?
Yes. Please add Reported-by and Tested-by.
Very good! I have added:
Tested-by: Naresh Kamboju <redacted>
Because I folded the workaround into the first commit in the series,
instead of adding your Reported-by, I added the following to that commit:
[ paulmck: Explicitly check for small pointers per Naresh Kamboju. ]
quoted
And before I forget again, good to see the rcutorture testing on a
non-x86 platform!
We are running rcutorture tests on arm, arm64, i386 and x86_64.
Nice!!!
Some ARMv8 people are getting bogus (but harmless) error messages
because parts of rcutorture think that all the world is an x86.
I am looking at a fix, but need to work out what the system is.
To that end, coul you please run the following on the arm, arm64,
and i386 systems and tell me what the output is?
gcc -dumpmachine