* Re: limits->max_sectors is getting set to 0, why/where? [was: Re: dm: kernel oops by divide error on v4.16+]
@ 2018-04-09 21:56 ` Jens Axboe
0 siblings, 0 replies; 29+ messages in thread
From: Jens Axboe @ 2018-04-09 21:56 UTC (permalink / raw)
To: Mike Snitzer, Ming Lei
Cc: dm-devel, linux-block, Kees Cook, Linus Torvalds, Chris Mason
[-- Attachment #1: Type: text/plain, Size: 3183 bytes --]
On 4/9/18 3:26 PM, Jens Axboe wrote:
> On 4/9/18 1:32 PM, Jens Axboe wrote:
>> On 4/9/18 12:38 PM, Mike Snitzer wrote:
>>> On Mon, Apr 09 2018 at 11:51am -0400,
>>> Mike Snitzer <snitzer@redhat.com> wrote:
>>>
>>>> On Sun, Apr 08 2018 at 12:00am -0400,
>>>> Ming Lei <ming.lei@redhat.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> The following kernel oops(divide error) is triggered when running
>>>>> xfstest(generic/347) on ext4.
>>>>>
>>>>> [ 442.632954] run fstests generic/347 at 2018-04-07 18:06:44
>>>>> [ 443.839480] divide error: 0000 [#1] PREEMPT SMP PTI
>>>>> [ 443.840201] Dumping ftrace buffer:
>>>>> [ 443.840692] (ftrace buffer empty)
>>> ...
>>>>> [ 443.845756] CPU: 1 PID: 29607 Comm: dmsetup Not tainted 4.16.0_f605ba97fb80_master+ #1
>>>>> [ 443.846968] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.10.2-2.fc27 04/01/2014
>>>>> [ 443.848147] RIP: 0010:pool_io_hints+0x77/0x153 [dm_thin_pool]
>>>
>>> ...
>>>
>>>> I was able to reproduce (in my case RIP was pool_io_hints+0x45)
>>>>
>>>> Which on my kernel, is:
>>>>
>>>> crash> dis -l pool_io_hints+0x45
>>>> /root/snitm/git/linux/drivers/md/dm-thin.c: 2748
>>>> 0xffffffffc0765165 <pool_io_hints+69>: div %rdi
>>>>
>>>> Which is drivers/md/dm-thin.c:is_factor()'s return
>>>> !sector_div(block_size, n);
>>>>
>>>> SO looking at pool_io_hints() it would seem limits->max_sectors is 0 for
>>>> this xfstests device... why would that be!?
>>>>
>>>> Clearly pool_io_hints() could stand to be more defensive with a
>>>> !limits->max_sectors negative check but is it ever really valid for
>>>> max_sectors to be 0?
>>>>
>>>> Pretty sure the ultimate bug is outside DM (but not seeing an obvious
>>>> place where block core would set max_sectors to 0, all blk-settings.c
>>>> uses min_not_zero(), etc).
>>>
>>> I successfully ran this test against the linux-dm.git
>>> "for-4.17/dm-changes" tag that Linus merged after the block changes:
>>> git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git tags/for-4.17/dm-changes
>>>
>>> # ./check tests/generic/347
>>> FSTYP -- ext4
>>> PLATFORM -- Linux/x86_64 thegoat 4.16.0-rc5.snitm
>>> MKFS_OPTIONS -- /dev/mapper/test-xfstests_scratch
>>> MOUNT_OPTIONS -- -o acl,user_xattr /dev/mapper/test-xfstests_scratch /scratch
>>>
>>> generic/347 65s
>>> Ran: generic/347
>>> Passed all 1 tests
>>>
>>> SO this would seem to implicate some regression in the 4.17 block layer
>>> changes.
>>
>> No immediate ideas come to mind, we didn't have a lot of changes and I
>> don't see anything that looks problematic. Maybe you can try and
>> bisect it and see what you come up with?
>
> I ran it, problematic commit is:
>
> commit 3c8ba0d61d04ced9f8d9ff93977995a9e4e96e91
> Author: Kees Cook <keescook@chromium.org>
> Date: Fri Mar 30 18:52:36 2018 -0700
>
> kernel.h: Retain constant expression output for max()/min()
>
The fun continues. Thinking I'd try a userspace repro and thinking it
would be difficult to reproduce, try the attached min.c that just copies
all the bits from include/linux/kernel.h
axboe@x1:~ $ gcc -Wall -O2 -o min min.c
axboe@x1:~ $ ./min 128 256
min_not_zero(128, 256) = 0
--
Jens Axboe
[-- Attachment #2: min.c --]
[-- Type: text/x-csrc, Size: 1112 bytes --]
#include <stdio.h>
#include <stdlib.h>
#define __is_constexpr(x) \
(sizeof(int) == sizeof(*(8 ? ((void *)((long)(x) * 0l)) : (int *)8)))
#define __no_side_effects(x, y) \
(__is_constexpr(x) && __is_constexpr(y))
#define __typecheck(x, y) \
(!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
#define __safe_cmp(x, y) \
(__typecheck(x, y) && __no_side_effects(x, y))
#define __cmp(x, y, op) ((x) op (y) ? (x) : (y))
#define __cmp_once(x, y, op) ({ \
typeof(x) __x = (x); \
typeof(y) __y = (y); \
__cmp(__x, __y, op); })
#define __careful_cmp(x, y, op) \
__builtin_choose_expr(__safe_cmp(x, y), \
__cmp(x, y, op), __cmp_once(x, y, op))
#define min(x, y) __careful_cmp(x, y, <)
#define min_not_zero(x, y) ({ \
typeof(x) __x = (x); \
typeof(y) __y = (y); \
__x == 0 ? __y : ((__y == 0) ? __x : min(__x, __y)); })
int main(int argc, char *argv[])
{
int val1, val2;
if (argc < 3) {
printf("%s val1 val2\n", argv[0]);
return 1;
}
val1 = atoi(argv[1]);
val2 = atoi(argv[2]);
printf("min_not_zero(%d, %d) = %d\n", val1, val2, min_not_zero(val1, val2));
return 0;
}
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: limits->max_sectors is getting set to 0, why/where? [was: Re: dm: kernel oops by divide error on v4.16+]
2018-04-09 21:56 ` Jens Axboe
@ 2018-04-09 22:05 ` Kees Cook
-1 siblings, 0 replies; 29+ messages in thread
From: Kees Cook @ 2018-04-09 22:05 UTC (permalink / raw)
To: Jens Axboe
Cc: Mike Snitzer, Ming Lei, linux-block, Chris Mason, dm-devel,
Linus Torvalds
On Mon, Apr 9, 2018 at 2:56 PM, Jens Axboe <axboe@kernel.dk> wrote:
> On 4/9/18 3:26 PM, Jens Axboe wrote:
>> On 4/9/18 1:32 PM, Jens Axboe wrote:
>>> On 4/9/18 12:38 PM, Mike Snitzer wrote:
>>>> On Mon, Apr 09 2018 at 11:51am -0400,
>>>> Mike Snitzer <snitzer@redhat.com> wrote:
>>>>
>>>>> On Sun, Apr 08 2018 at 12:00am -0400,
>>>>> Ming Lei <ming.lei@redhat.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> The following kernel oops(divide error) is triggered when running
>>>>>> xfstest(generic/347) on ext4.
>>>>>>
>>>>>> [ 442.632954] run fstests generic/347 at 2018-04-07 18:06:44
>>>>>> [ 443.839480] divide error: 0000 [#1] PREEMPT SMP PTI
>>>>>> [ 443.840201] Dumping ftrace buffer:
>>>>>> [ 443.840692] (ftrace buffer empty)
>>>> ...
>>>>>> [ 443.845756] CPU: 1 PID: 29607 Comm: dmsetup Not tainted 4.16.0_f605ba97fb80_master+ #1
>>>>>> [ 443.846968] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.10.2-2.fc27 04/01/2014
>>>>>> [ 443.848147] RIP: 0010:pool_io_hints+0x77/0x153 [dm_thin_pool]
>>>>
>>>> ...
>>>>
>>>>> I was able to reproduce (in my case RIP was pool_io_hints+0x45)
>>>>>
>>>>> Which on my kernel, is:
>>>>>
>>>>> crash> dis -l pool_io_hints+0x45
>>>>> /root/snitm/git/linux/drivers/md/dm-thin.c: 2748
>>>>> 0xffffffffc0765165 <pool_io_hints+69>: div %rdi
>>>>>
>>>>> Which is drivers/md/dm-thin.c:is_factor()'s return
>>>>> !sector_div(block_size, n);
>>>>>
>>>>> SO looking at pool_io_hints() it would seem limits->max_sectors is 0 for
>>>>> this xfstests device... why would that be!?
>>>>>
>>>>> Clearly pool_io_hints() could stand to be more defensive with a
>>>>> !limits->max_sectors negative check but is it ever really valid for
>>>>> max_sectors to be 0?
>>>>>
>>>>> Pretty sure the ultimate bug is outside DM (but not seeing an obvious
>>>>> place where block core would set max_sectors to 0, all blk-settings.c
>>>>> uses min_not_zero(), etc).
>>>>
>>>> I successfully ran this test against the linux-dm.git
>>>> "for-4.17/dm-changes" tag that Linus merged after the block changes:
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git tags/for-4.17/dm-changes
>>>>
>>>> # ./check tests/generic/347
>>>> FSTYP -- ext4
>>>> PLATFORM -- Linux/x86_64 thegoat 4.16.0-rc5.snitm
>>>> MKFS_OPTIONS -- /dev/mapper/test-xfstests_scratch
>>>> MOUNT_OPTIONS -- -o acl,user_xattr /dev/mapper/test-xfstests_scratch /scratch
>>>>
>>>> generic/347 65s
>>>> Ran: generic/347
>>>> Passed all 1 tests
>>>>
>>>> SO this would seem to implicate some regression in the 4.17 block layer
>>>> changes.
>>>
>>> No immediate ideas come to mind, we didn't have a lot of changes and I
>>> don't see anything that looks problematic. Maybe you can try and
>>> bisect it and see what you come up with?
>>
>> I ran it, problematic commit is:
>>
>> commit 3c8ba0d61d04ced9f8d9ff93977995a9e4e96e91
>> Author: Kees Cook <keescook@chromium.org>
>> Date: Fri Mar 30 18:52:36 2018 -0700
>>
>> kernel.h: Retain constant expression output for max()/min()
>>
>
> The fun continues. Thinking I'd try a userspace repro and thinking it
> would be difficult to reproduce, try the attached min.c that just copies
> all the bits from include/linux/kernel.h
>
> axboe@x1:~ $ gcc -Wall -O2 -o min min.c
> axboe@x1:~ $ ./min 128 256
> min_not_zero(128, 256) = 0
This should be fixed with e9092d0d9796 ("Fix subtle macro variable
shadowing in min_not_zero()").
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: limits->max_sectors is getting set to 0, why/where? [was: Re: dm: kernel oops by divide error on v4.16+]
@ 2018-04-09 22:05 ` Kees Cook
0 siblings, 0 replies; 29+ messages in thread
From: Kees Cook @ 2018-04-09 22:05 UTC (permalink / raw)
To: Jens Axboe
Cc: Mike Snitzer, Ming Lei, dm-devel, linux-block, Linus Torvalds,
Chris Mason
On Mon, Apr 9, 2018 at 2:56 PM, Jens Axboe <axboe@kernel.dk> wrote:
> On 4/9/18 3:26 PM, Jens Axboe wrote:
>> On 4/9/18 1:32 PM, Jens Axboe wrote:
>>> On 4/9/18 12:38 PM, Mike Snitzer wrote:
>>>> On Mon, Apr 09 2018 at 11:51am -0400,
>>>> Mike Snitzer <snitzer@redhat.com> wrote:
>>>>
>>>>> On Sun, Apr 08 2018 at 12:00am -0400,
>>>>> Ming Lei <ming.lei@redhat.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> The following kernel oops(divide error) is triggered when running
>>>>>> xfstest(generic/347) on ext4.
>>>>>>
>>>>>> [ 442.632954] run fstests generic/347 at 2018-04-07 18:06:44
>>>>>> [ 443.839480] divide error: 0000 [#1] PREEMPT SMP PTI
>>>>>> [ 443.840201] Dumping ftrace buffer:
>>>>>> [ 443.840692] (ftrace buffer empty)
>>>> ...
>>>>>> [ 443.845756] CPU: 1 PID: 29607 Comm: dmsetup Not tainted 4.16.0_f605ba97fb80_master+ #1
>>>>>> [ 443.846968] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.10.2-2.fc27 04/01/2014
>>>>>> [ 443.848147] RIP: 0010:pool_io_hints+0x77/0x153 [dm_thin_pool]
>>>>
>>>> ...
>>>>
>>>>> I was able to reproduce (in my case RIP was pool_io_hints+0x45)
>>>>>
>>>>> Which on my kernel, is:
>>>>>
>>>>> crash> dis -l pool_io_hints+0x45
>>>>> /root/snitm/git/linux/drivers/md/dm-thin.c: 2748
>>>>> 0xffffffffc0765165 <pool_io_hints+69>: div %rdi
>>>>>
>>>>> Which is drivers/md/dm-thin.c:is_factor()'s return
>>>>> !sector_div(block_size, n);
>>>>>
>>>>> SO looking at pool_io_hints() it would seem limits->max_sectors is 0 for
>>>>> this xfstests device... why would that be!?
>>>>>
>>>>> Clearly pool_io_hints() could stand to be more defensive with a
>>>>> !limits->max_sectors negative check but is it ever really valid for
>>>>> max_sectors to be 0?
>>>>>
>>>>> Pretty sure the ultimate bug is outside DM (but not seeing an obvious
>>>>> place where block core would set max_sectors to 0, all blk-settings.c
>>>>> uses min_not_zero(), etc).
>>>>
>>>> I successfully ran this test against the linux-dm.git
>>>> "for-4.17/dm-changes" tag that Linus merged after the block changes:
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git tags/for-4.17/dm-changes
>>>>
>>>> # ./check tests/generic/347
>>>> FSTYP -- ext4
>>>> PLATFORM -- Linux/x86_64 thegoat 4.16.0-rc5.snitm
>>>> MKFS_OPTIONS -- /dev/mapper/test-xfstests_scratch
>>>> MOUNT_OPTIONS -- -o acl,user_xattr /dev/mapper/test-xfstests_scratch /scratch
>>>>
>>>> generic/347 65s
>>>> Ran: generic/347
>>>> Passed all 1 tests
>>>>
>>>> SO this would seem to implicate some regression in the 4.17 block layer
>>>> changes.
>>>
>>> No immediate ideas come to mind, we didn't have a lot of changes and I
>>> don't see anything that looks problematic. Maybe you can try and
>>> bisect it and see what you come up with?
>>
>> I ran it, problematic commit is:
>>
>> commit 3c8ba0d61d04ced9f8d9ff93977995a9e4e96e91
>> Author: Kees Cook <keescook@chromium.org>
>> Date: Fri Mar 30 18:52:36 2018 -0700
>>
>> kernel.h: Retain constant expression output for max()/min()
>>
>
> The fun continues. Thinking I'd try a userspace repro and thinking it
> would be difficult to reproduce, try the attached min.c that just copies
> all the bits from include/linux/kernel.h
>
> axboe@x1:~ $ gcc -Wall -O2 -o min min.c
> axboe@x1:~ $ ./min 128 256
> min_not_zero(128, 256) = 0
This should be fixed with e9092d0d9796 ("Fix subtle macro variable
shadowing in min_not_zero()").
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: limits->max_sectors is getting set to 0, why/where? [was: Re: dm: kernel oops by divide error on v4.16+]
2018-04-09 22:05 ` Kees Cook
@ 2018-04-09 22:10 ` Jens Axboe
-1 siblings, 0 replies; 29+ messages in thread
From: Jens Axboe @ 2018-04-09 22:10 UTC (permalink / raw)
To: Kees Cook
Cc: Mike Snitzer, Ming Lei, linux-block, Chris Mason, dm-devel,
Linus Torvalds
On 4/9/18 4:05 PM, Kees Cook wrote:
> On Mon, Apr 9, 2018 at 2:56 PM, Jens Axboe <axboe@kernel.dk> wrote:
>> On 4/9/18 3:26 PM, Jens Axboe wrote:
>>> On 4/9/18 1:32 PM, Jens Axboe wrote:
>>>> On 4/9/18 12:38 PM, Mike Snitzer wrote:
>>>>> On Mon, Apr 09 2018 at 11:51am -0400,
>>>>> Mike Snitzer <snitzer@redhat.com> wrote:
>>>>>
>>>>>> On Sun, Apr 08 2018 at 12:00am -0400,
>>>>>> Ming Lei <ming.lei@redhat.com> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> The following kernel oops(divide error) is triggered when running
>>>>>>> xfstest(generic/347) on ext4.
>>>>>>>
>>>>>>> [ 442.632954] run fstests generic/347 at 2018-04-07 18:06:44
>>>>>>> [ 443.839480] divide error: 0000 [#1] PREEMPT SMP PTI
>>>>>>> [ 443.840201] Dumping ftrace buffer:
>>>>>>> [ 443.840692] (ftrace buffer empty)
>>>>> ...
>>>>>>> [ 443.845756] CPU: 1 PID: 29607 Comm: dmsetup Not tainted 4.16.0_f605ba97fb80_master+ #1
>>>>>>> [ 443.846968] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.10.2-2.fc27 04/01/2014
>>>>>>> [ 443.848147] RIP: 0010:pool_io_hints+0x77/0x153 [dm_thin_pool]
>>>>>
>>>>> ...
>>>>>
>>>>>> I was able to reproduce (in my case RIP was pool_io_hints+0x45)
>>>>>>
>>>>>> Which on my kernel, is:
>>>>>>
>>>>>> crash> dis -l pool_io_hints+0x45
>>>>>> /root/snitm/git/linux/drivers/md/dm-thin.c: 2748
>>>>>> 0xffffffffc0765165 <pool_io_hints+69>: div %rdi
>>>>>>
>>>>>> Which is drivers/md/dm-thin.c:is_factor()'s return
>>>>>> !sector_div(block_size, n);
>>>>>>
>>>>>> SO looking at pool_io_hints() it would seem limits->max_sectors is 0 for
>>>>>> this xfstests device... why would that be!?
>>>>>>
>>>>>> Clearly pool_io_hints() could stand to be more defensive with a
>>>>>> !limits->max_sectors negative check but is it ever really valid for
>>>>>> max_sectors to be 0?
>>>>>>
>>>>>> Pretty sure the ultimate bug is outside DM (but not seeing an obvious
>>>>>> place where block core would set max_sectors to 0, all blk-settings.c
>>>>>> uses min_not_zero(), etc).
>>>>>
>>>>> I successfully ran this test against the linux-dm.git
>>>>> "for-4.17/dm-changes" tag that Linus merged after the block changes:
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git tags/for-4.17/dm-changes
>>>>>
>>>>> # ./check tests/generic/347
>>>>> FSTYP -- ext4
>>>>> PLATFORM -- Linux/x86_64 thegoat 4.16.0-rc5.snitm
>>>>> MKFS_OPTIONS -- /dev/mapper/test-xfstests_scratch
>>>>> MOUNT_OPTIONS -- -o acl,user_xattr /dev/mapper/test-xfstests_scratch /scratch
>>>>>
>>>>> generic/347 65s
>>>>> Ran: generic/347
>>>>> Passed all 1 tests
>>>>>
>>>>> SO this would seem to implicate some regression in the 4.17 block layer
>>>>> changes.
>>>>
>>>> No immediate ideas come to mind, we didn't have a lot of changes and I
>>>> don't see anything that looks problematic. Maybe you can try and
>>>> bisect it and see what you come up with?
>>>
>>> I ran it, problematic commit is:
>>>
>>> commit 3c8ba0d61d04ced9f8d9ff93977995a9e4e96e91
>>> Author: Kees Cook <keescook@chromium.org>
>>> Date: Fri Mar 30 18:52:36 2018 -0700
>>>
>>> kernel.h: Retain constant expression output for max()/min()
>>>
>>
>> The fun continues. Thinking I'd try a userspace repro and thinking it
>> would be difficult to reproduce, try the attached min.c that just copies
>> all the bits from include/linux/kernel.h
>>
>> axboe@x1:~ $ gcc -Wall -O2 -o min min.c
>> axboe@x1:~ $ ./min 128 256
>> min_not_zero(128, 256) = 0
>
> This should be fixed with e9092d0d9796 ("Fix subtle macro variable
> shadowing in min_not_zero()").
Yep that works, which is a relief. Some basic unit testing would have
been very appropriate in this case, given how fundamentally broken it
was... It's amazing nothing catastrophic happened.
--
Jens Axboe
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: limits->max_sectors is getting set to 0, why/where? [was: Re: dm: kernel oops by divide error on v4.16+]
@ 2018-04-09 22:10 ` Jens Axboe
0 siblings, 0 replies; 29+ messages in thread
From: Jens Axboe @ 2018-04-09 22:10 UTC (permalink / raw)
To: Kees Cook
Cc: Mike Snitzer, Ming Lei, dm-devel, linux-block, Linus Torvalds,
Chris Mason
On 4/9/18 4:05 PM, Kees Cook wrote:
> On Mon, Apr 9, 2018 at 2:56 PM, Jens Axboe <axboe@kernel.dk> wrote:
>> On 4/9/18 3:26 PM, Jens Axboe wrote:
>>> On 4/9/18 1:32 PM, Jens Axboe wrote:
>>>> On 4/9/18 12:38 PM, Mike Snitzer wrote:
>>>>> On Mon, Apr 09 2018 at 11:51am -0400,
>>>>> Mike Snitzer <snitzer@redhat.com> wrote:
>>>>>
>>>>>> On Sun, Apr 08 2018 at 12:00am -0400,
>>>>>> Ming Lei <ming.lei@redhat.com> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> The following kernel oops(divide error) is triggered when running
>>>>>>> xfstest(generic/347) on ext4.
>>>>>>>
>>>>>>> [ 442.632954] run fstests generic/347 at 2018-04-07 18:06:44
>>>>>>> [ 443.839480] divide error: 0000 [#1] PREEMPT SMP PTI
>>>>>>> [ 443.840201] Dumping ftrace buffer:
>>>>>>> [ 443.840692] (ftrace buffer empty)
>>>>> ...
>>>>>>> [ 443.845756] CPU: 1 PID: 29607 Comm: dmsetup Not tainted 4.16.0_f605ba97fb80_master+ #1
>>>>>>> [ 443.846968] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.10.2-2.fc27 04/01/2014
>>>>>>> [ 443.848147] RIP: 0010:pool_io_hints+0x77/0x153 [dm_thin_pool]
>>>>>
>>>>> ...
>>>>>
>>>>>> I was able to reproduce (in my case RIP was pool_io_hints+0x45)
>>>>>>
>>>>>> Which on my kernel, is:
>>>>>>
>>>>>> crash> dis -l pool_io_hints+0x45
>>>>>> /root/snitm/git/linux/drivers/md/dm-thin.c: 2748
>>>>>> 0xffffffffc0765165 <pool_io_hints+69>: div %rdi
>>>>>>
>>>>>> Which is drivers/md/dm-thin.c:is_factor()'s return
>>>>>> !sector_div(block_size, n);
>>>>>>
>>>>>> SO looking at pool_io_hints() it would seem limits->max_sectors is 0 for
>>>>>> this xfstests device... why would that be!?
>>>>>>
>>>>>> Clearly pool_io_hints() could stand to be more defensive with a
>>>>>> !limits->max_sectors negative check but is it ever really valid for
>>>>>> max_sectors to be 0?
>>>>>>
>>>>>> Pretty sure the ultimate bug is outside DM (but not seeing an obvious
>>>>>> place where block core would set max_sectors to 0, all blk-settings.c
>>>>>> uses min_not_zero(), etc).
>>>>>
>>>>> I successfully ran this test against the linux-dm.git
>>>>> "for-4.17/dm-changes" tag that Linus merged after the block changes:
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git tags/for-4.17/dm-changes
>>>>>
>>>>> # ./check tests/generic/347
>>>>> FSTYP -- ext4
>>>>> PLATFORM -- Linux/x86_64 thegoat 4.16.0-rc5.snitm
>>>>> MKFS_OPTIONS -- /dev/mapper/test-xfstests_scratch
>>>>> MOUNT_OPTIONS -- -o acl,user_xattr /dev/mapper/test-xfstests_scratch /scratch
>>>>>
>>>>> generic/347 65s
>>>>> Ran: generic/347
>>>>> Passed all 1 tests
>>>>>
>>>>> SO this would seem to implicate some regression in the 4.17 block layer
>>>>> changes.
>>>>
>>>> No immediate ideas come to mind, we didn't have a lot of changes and I
>>>> don't see anything that looks problematic. Maybe you can try and
>>>> bisect it and see what you come up with?
>>>
>>> I ran it, problematic commit is:
>>>
>>> commit 3c8ba0d61d04ced9f8d9ff93977995a9e4e96e91
>>> Author: Kees Cook <keescook@chromium.org>
>>> Date: Fri Mar 30 18:52:36 2018 -0700
>>>
>>> kernel.h: Retain constant expression output for max()/min()
>>>
>>
>> The fun continues. Thinking I'd try a userspace repro and thinking it
>> would be difficult to reproduce, try the attached min.c that just copies
>> all the bits from include/linux/kernel.h
>>
>> axboe@x1:~ $ gcc -Wall -O2 -o min min.c
>> axboe@x1:~ $ ./min 128 256
>> min_not_zero(128, 256) = 0
>
> This should be fixed with e9092d0d9796 ("Fix subtle macro variable
> shadowing in min_not_zero()").
Yep that works, which is a relief. Some basic unit testing would have
been very appropriate in this case, given how fundamentally broken it
was... It's amazing nothing catastrophic happened.
--
Jens Axboe
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: limits->max_sectors is getting set to 0, why/where? [was: Re: dm: kernel oops by divide error on v4.16+]
2018-04-09 22:10 ` Jens Axboe
@ 2018-04-09 22:27 ` Ming Lei
-1 siblings, 0 replies; 29+ messages in thread
From: Ming Lei @ 2018-04-09 22:27 UTC (permalink / raw)
To: Jens Axboe
Cc: Kees Cook, Mike Snitzer, linux-block, Chris Mason, dm-devel,
Linus Torvalds
On Mon, Apr 09, 2018 at 04:10:17PM -0600, Jens Axboe wrote:
> On 4/9/18 4:05 PM, Kees Cook wrote:
> > On Mon, Apr 9, 2018 at 2:56 PM, Jens Axboe <axboe@kernel.dk> wrote:
> >> On 4/9/18 3:26 PM, Jens Axboe wrote:
> >>> On 4/9/18 1:32 PM, Jens Axboe wrote:
> >>>> On 4/9/18 12:38 PM, Mike Snitzer wrote:
> >>>>> On Mon, Apr 09 2018 at 11:51am -0400,
> >>>>> Mike Snitzer <snitzer@redhat.com> wrote:
> >>>>>
> >>>>>> On Sun, Apr 08 2018 at 12:00am -0400,
> >>>>>> Ming Lei <ming.lei@redhat.com> wrote:
> >>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> The following kernel oops(divide error) is triggered when running
> >>>>>>> xfstest(generic/347) on ext4.
> >>>>>>>
> >>>>>>> [ 442.632954] run fstests generic/347 at 2018-04-07 18:06:44
> >>>>>>> [ 443.839480] divide error: 0000 [#1] PREEMPT SMP PTI
> >>>>>>> [ 443.840201] Dumping ftrace buffer:
> >>>>>>> [ 443.840692] (ftrace buffer empty)
> >>>>> ...
> >>>>>>> [ 443.845756] CPU: 1 PID: 29607 Comm: dmsetup Not tainted 4.16.0_f605ba97fb80_master+ #1
> >>>>>>> [ 443.846968] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.10.2-2.fc27 04/01/2014
> >>>>>>> [ 443.848147] RIP: 0010:pool_io_hints+0x77/0x153 [dm_thin_pool]
> >>>>>
> >>>>> ...
> >>>>>
> >>>>>> I was able to reproduce (in my case RIP was pool_io_hints+0x45)
> >>>>>>
> >>>>>> Which on my kernel, is:
> >>>>>>
> >>>>>> crash> dis -l pool_io_hints+0x45
> >>>>>> /root/snitm/git/linux/drivers/md/dm-thin.c: 2748
> >>>>>> 0xffffffffc0765165 <pool_io_hints+69>: div %rdi
> >>>>>>
> >>>>>> Which is drivers/md/dm-thin.c:is_factor()'s return
> >>>>>> !sector_div(block_size, n);
> >>>>>>
> >>>>>> SO looking at pool_io_hints() it would seem limits->max_sectors is 0 for
> >>>>>> this xfstests device... why would that be!?
> >>>>>>
> >>>>>> Clearly pool_io_hints() could stand to be more defensive with a
> >>>>>> !limits->max_sectors negative check but is it ever really valid for
> >>>>>> max_sectors to be 0?
> >>>>>>
> >>>>>> Pretty sure the ultimate bug is outside DM (but not seeing an obvious
> >>>>>> place where block core would set max_sectors to 0, all blk-settings.c
> >>>>>> uses min_not_zero(), etc).
> >>>>>
> >>>>> I successfully ran this test against the linux-dm.git
> >>>>> "for-4.17/dm-changes" tag that Linus merged after the block changes:
> >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git tags/for-4.17/dm-changes
> >>>>>
> >>>>> # ./check tests/generic/347
> >>>>> FSTYP -- ext4
> >>>>> PLATFORM -- Linux/x86_64 thegoat 4.16.0-rc5.snitm
> >>>>> MKFS_OPTIONS -- /dev/mapper/test-xfstests_scratch
> >>>>> MOUNT_OPTIONS -- -o acl,user_xattr /dev/mapper/test-xfstests_scratch /scratch
> >>>>>
> >>>>> generic/347 65s
> >>>>> Ran: generic/347
> >>>>> Passed all 1 tests
> >>>>>
> >>>>> SO this would seem to implicate some regression in the 4.17 block layer
> >>>>> changes.
> >>>>
> >>>> No immediate ideas come to mind, we didn't have a lot of changes and I
> >>>> don't see anything that looks problematic. Maybe you can try and
> >>>> bisect it and see what you come up with?
> >>>
> >>> I ran it, problematic commit is:
> >>>
> >>> commit 3c8ba0d61d04ced9f8d9ff93977995a9e4e96e91
> >>> Author: Kees Cook <keescook@chromium.org>
> >>> Date: Fri Mar 30 18:52:36 2018 -0700
> >>>
> >>> kernel.h: Retain constant expression output for max()/min()
> >>>
> >>
> >> The fun continues. Thinking I'd try a userspace repro and thinking it
> >> would be difficult to reproduce, try the attached min.c that just copies
> >> all the bits from include/linux/kernel.h
> >>
> >> axboe@x1:~ $ gcc -Wall -O2 -o min min.c
> >> axboe@x1:~ $ ./min 128 256
> >> min_not_zero(128, 256) = 0
> >
> > This should be fixed with e9092d0d9796 ("Fix subtle macro variable
> > shadowing in min_not_zero()").
>
> Yep that works, which is a relief. Some basic unit testing would have
> been very appropriate in this case, given how fundamentally broken it
> was... It's amazing nothing catastrophic happened.
Actually, there was, :-)
https://lkml.org/lkml/2018/4/9/355
--
Ming
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: limits->max_sectors is getting set to 0, why/where? [was: Re: dm: kernel oops by divide error on v4.16+]
@ 2018-04-09 22:27 ` Ming Lei
0 siblings, 0 replies; 29+ messages in thread
From: Ming Lei @ 2018-04-09 22:27 UTC (permalink / raw)
To: Jens Axboe
Cc: Kees Cook, Mike Snitzer, dm-devel, linux-block, Linus Torvalds,
Chris Mason
On Mon, Apr 09, 2018 at 04:10:17PM -0600, Jens Axboe wrote:
> On 4/9/18 4:05 PM, Kees Cook wrote:
> > On Mon, Apr 9, 2018 at 2:56 PM, Jens Axboe <axboe@kernel.dk> wrote:
> >> On 4/9/18 3:26 PM, Jens Axboe wrote:
> >>> On 4/9/18 1:32 PM, Jens Axboe wrote:
> >>>> On 4/9/18 12:38 PM, Mike Snitzer wrote:
> >>>>> On Mon, Apr 09 2018 at 11:51am -0400,
> >>>>> Mike Snitzer <snitzer@redhat.com> wrote:
> >>>>>
> >>>>>> On Sun, Apr 08 2018 at 12:00am -0400,
> >>>>>> Ming Lei <ming.lei@redhat.com> wrote:
> >>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> The following kernel oops(divide error) is triggered when running
> >>>>>>> xfstest(generic/347) on ext4.
> >>>>>>>
> >>>>>>> [ 442.632954] run fstests generic/347 at 2018-04-07 18:06:44
> >>>>>>> [ 443.839480] divide error: 0000 [#1] PREEMPT SMP PTI
> >>>>>>> [ 443.840201] Dumping ftrace buffer:
> >>>>>>> [ 443.840692] (ftrace buffer empty)
> >>>>> ...
> >>>>>>> [ 443.845756] CPU: 1 PID: 29607 Comm: dmsetup Not tainted 4.16.0_f605ba97fb80_master+ #1
> >>>>>>> [ 443.846968] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.10.2-2.fc27 04/01/2014
> >>>>>>> [ 443.848147] RIP: 0010:pool_io_hints+0x77/0x153 [dm_thin_pool]
> >>>>>
> >>>>> ...
> >>>>>
> >>>>>> I was able to reproduce (in my case RIP was pool_io_hints+0x45)
> >>>>>>
> >>>>>> Which on my kernel, is:
> >>>>>>
> >>>>>> crash> dis -l pool_io_hints+0x45
> >>>>>> /root/snitm/git/linux/drivers/md/dm-thin.c: 2748
> >>>>>> 0xffffffffc0765165 <pool_io_hints+69>: div %rdi
> >>>>>>
> >>>>>> Which is drivers/md/dm-thin.c:is_factor()'s return
> >>>>>> !sector_div(block_size, n);
> >>>>>>
> >>>>>> SO looking at pool_io_hints() it would seem limits->max_sectors is 0 for
> >>>>>> this xfstests device... why would that be!?
> >>>>>>
> >>>>>> Clearly pool_io_hints() could stand to be more defensive with a
> >>>>>> !limits->max_sectors negative check but is it ever really valid for
> >>>>>> max_sectors to be 0?
> >>>>>>
> >>>>>> Pretty sure the ultimate bug is outside DM (but not seeing an obvious
> >>>>>> place where block core would set max_sectors to 0, all blk-settings.c
> >>>>>> uses min_not_zero(), etc).
> >>>>>
> >>>>> I successfully ran this test against the linux-dm.git
> >>>>> "for-4.17/dm-changes" tag that Linus merged after the block changes:
> >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git tags/for-4.17/dm-changes
> >>>>>
> >>>>> # ./check tests/generic/347
> >>>>> FSTYP -- ext4
> >>>>> PLATFORM -- Linux/x86_64 thegoat 4.16.0-rc5.snitm
> >>>>> MKFS_OPTIONS -- /dev/mapper/test-xfstests_scratch
> >>>>> MOUNT_OPTIONS -- -o acl,user_xattr /dev/mapper/test-xfstests_scratch /scratch
> >>>>>
> >>>>> generic/347 65s
> >>>>> Ran: generic/347
> >>>>> Passed all 1 tests
> >>>>>
> >>>>> SO this would seem to implicate some regression in the 4.17 block layer
> >>>>> changes.
> >>>>
> >>>> No immediate ideas come to mind, we didn't have a lot of changes and I
> >>>> don't see anything that looks problematic. Maybe you can try and
> >>>> bisect it and see what you come up with?
> >>>
> >>> I ran it, problematic commit is:
> >>>
> >>> commit 3c8ba0d61d04ced9f8d9ff93977995a9e4e96e91
> >>> Author: Kees Cook <keescook@chromium.org>
> >>> Date: Fri Mar 30 18:52:36 2018 -0700
> >>>
> >>> kernel.h: Retain constant expression output for max()/min()
> >>>
> >>
> >> The fun continues. Thinking I'd try a userspace repro and thinking it
> >> would be difficult to reproduce, try the attached min.c that just copies
> >> all the bits from include/linux/kernel.h
> >>
> >> axboe@x1:~ $ gcc -Wall -O2 -o min min.c
> >> axboe@x1:~ $ ./min 128 256
> >> min_not_zero(128, 256) = 0
> >
> > This should be fixed with e9092d0d9796 ("Fix subtle macro variable
> > shadowing in min_not_zero()").
>
> Yep that works, which is a relief. Some basic unit testing would have
> been very appropriate in this case, given how fundamentally broken it
> was... It's amazing nothing catastrophic happened.
Actually, there was, :-)
https://lkml.org/lkml/2018/4/9/355
--
Ming
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: limits->max_sectors is getting set to 0, why/where? [was: Re: dm: kernel oops by divide error on v4.16+]
2018-04-09 22:27 ` Ming Lei
@ 2018-04-09 22:32 ` Jens Axboe
-1 siblings, 0 replies; 29+ messages in thread
From: Jens Axboe @ 2018-04-09 22:32 UTC (permalink / raw)
To: Ming Lei
Cc: Kees Cook, Mike Snitzer, linux-block, Chris Mason, dm-devel,
Linus Torvalds
On 4/9/18 4:27 PM, Ming Lei wrote:
> On Mon, Apr 09, 2018 at 04:10:17PM -0600, Jens Axboe wrote:
>> On 4/9/18 4:05 PM, Kees Cook wrote:
>>> On Mon, Apr 9, 2018 at 2:56 PM, Jens Axboe <axboe@kernel.dk> wrote:
>>>> On 4/9/18 3:26 PM, Jens Axboe wrote:
>>>>> On 4/9/18 1:32 PM, Jens Axboe wrote:
>>>>>> On 4/9/18 12:38 PM, Mike Snitzer wrote:
>>>>>>> On Mon, Apr 09 2018 at 11:51am -0400,
>>>>>>> Mike Snitzer <snitzer@redhat.com> wrote:
>>>>>>>
>>>>>>>> On Sun, Apr 08 2018 at 12:00am -0400,
>>>>>>>> Ming Lei <ming.lei@redhat.com> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> The following kernel oops(divide error) is triggered when running
>>>>>>>>> xfstest(generic/347) on ext4.
>>>>>>>>>
>>>>>>>>> [ 442.632954] run fstests generic/347 at 2018-04-07 18:06:44
>>>>>>>>> [ 443.839480] divide error: 0000 [#1] PREEMPT SMP PTI
>>>>>>>>> [ 443.840201] Dumping ftrace buffer:
>>>>>>>>> [ 443.840692] (ftrace buffer empty)
>>>>>>> ...
>>>>>>>>> [ 443.845756] CPU: 1 PID: 29607 Comm: dmsetup Not tainted 4.16.0_f605ba97fb80_master+ #1
>>>>>>>>> [ 443.846968] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.10.2-2.fc27 04/01/2014
>>>>>>>>> [ 443.848147] RIP: 0010:pool_io_hints+0x77/0x153 [dm_thin_pool]
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>>>> I was able to reproduce (in my case RIP was pool_io_hints+0x45)
>>>>>>>>
>>>>>>>> Which on my kernel, is:
>>>>>>>>
>>>>>>>> crash> dis -l pool_io_hints+0x45
>>>>>>>> /root/snitm/git/linux/drivers/md/dm-thin.c: 2748
>>>>>>>> 0xffffffffc0765165 <pool_io_hints+69>: div %rdi
>>>>>>>>
>>>>>>>> Which is drivers/md/dm-thin.c:is_factor()'s return
>>>>>>>> !sector_div(block_size, n);
>>>>>>>>
>>>>>>>> SO looking at pool_io_hints() it would seem limits->max_sectors is 0 for
>>>>>>>> this xfstests device... why would that be!?
>>>>>>>>
>>>>>>>> Clearly pool_io_hints() could stand to be more defensive with a
>>>>>>>> !limits->max_sectors negative check but is it ever really valid for
>>>>>>>> max_sectors to be 0?
>>>>>>>>
>>>>>>>> Pretty sure the ultimate bug is outside DM (but not seeing an obvious
>>>>>>>> place where block core would set max_sectors to 0, all blk-settings.c
>>>>>>>> uses min_not_zero(), etc).
>>>>>>>
>>>>>>> I successfully ran this test against the linux-dm.git
>>>>>>> "for-4.17/dm-changes" tag that Linus merged after the block changes:
>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git tags/for-4.17/dm-changes
>>>>>>>
>>>>>>> # ./check tests/generic/347
>>>>>>> FSTYP -- ext4
>>>>>>> PLATFORM -- Linux/x86_64 thegoat 4.16.0-rc5.snitm
>>>>>>> MKFS_OPTIONS -- /dev/mapper/test-xfstests_scratch
>>>>>>> MOUNT_OPTIONS -- -o acl,user_xattr /dev/mapper/test-xfstests_scratch /scratch
>>>>>>>
>>>>>>> generic/347 65s
>>>>>>> Ran: generic/347
>>>>>>> Passed all 1 tests
>>>>>>>
>>>>>>> SO this would seem to implicate some regression in the 4.17 block layer
>>>>>>> changes.
>>>>>>
>>>>>> No immediate ideas come to mind, we didn't have a lot of changes and I
>>>>>> don't see anything that looks problematic. Maybe you can try and
>>>>>> bisect it and see what you come up with?
>>>>>
>>>>> I ran it, problematic commit is:
>>>>>
>>>>> commit 3c8ba0d61d04ced9f8d9ff93977995a9e4e96e91
>>>>> Author: Kees Cook <keescook@chromium.org>
>>>>> Date: Fri Mar 30 18:52:36 2018 -0700
>>>>>
>>>>> kernel.h: Retain constant expression output for max()/min()
>>>>>
>>>>
>>>> The fun continues. Thinking I'd try a userspace repro and thinking it
>>>> would be difficult to reproduce, try the attached min.c that just copies
>>>> all the bits from include/linux/kernel.h
>>>>
>>>> axboe@x1:~ $ gcc -Wall -O2 -o min min.c
>>>> axboe@x1:~ $ ./min 128 256
>>>> min_not_zero(128, 256) = 0
>>>
>>> This should be fixed with e9092d0d9796 ("Fix subtle macro variable
>>> shadowing in min_not_zero()").
>>
>> Yep that works, which is a relief. Some basic unit testing would have
>> been very appropriate in this case, given how fundamentally broken it
>> was... It's amazing nothing catastrophic happened.
>
> Actually, there was, :-)
>
> https://lkml.org/lkml/2018/4/9/355
That's bad, for sure, but my worry was bigger than an oops or crash,
we could have had corruption due to this.
The resulting min/max and friends would have been trivial to test, but
clearly they weren't.
--
Jens Axboe
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: limits->max_sectors is getting set to 0, why/where? [was: Re: dm: kernel oops by divide error on v4.16+]
@ 2018-04-09 22:32 ` Jens Axboe
0 siblings, 0 replies; 29+ messages in thread
From: Jens Axboe @ 2018-04-09 22:32 UTC (permalink / raw)
To: Ming Lei
Cc: Kees Cook, Mike Snitzer, dm-devel, linux-block, Linus Torvalds,
Chris Mason
On 4/9/18 4:27 PM, Ming Lei wrote:
> On Mon, Apr 09, 2018 at 04:10:17PM -0600, Jens Axboe wrote:
>> On 4/9/18 4:05 PM, Kees Cook wrote:
>>> On Mon, Apr 9, 2018 at 2:56 PM, Jens Axboe <axboe@kernel.dk> wrote:
>>>> On 4/9/18 3:26 PM, Jens Axboe wrote:
>>>>> On 4/9/18 1:32 PM, Jens Axboe wrote:
>>>>>> On 4/9/18 12:38 PM, Mike Snitzer wrote:
>>>>>>> On Mon, Apr 09 2018 at 11:51am -0400,
>>>>>>> Mike Snitzer <snitzer@redhat.com> wrote:
>>>>>>>
>>>>>>>> On Sun, Apr 08 2018 at 12:00am -0400,
>>>>>>>> Ming Lei <ming.lei@redhat.com> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> The following kernel oops(divide error) is triggered when running
>>>>>>>>> xfstest(generic/347) on ext4.
>>>>>>>>>
>>>>>>>>> [ 442.632954] run fstests generic/347 at 2018-04-07 18:06:44
>>>>>>>>> [ 443.839480] divide error: 0000 [#1] PREEMPT SMP PTI
>>>>>>>>> [ 443.840201] Dumping ftrace buffer:
>>>>>>>>> [ 443.840692] (ftrace buffer empty)
>>>>>>> ...
>>>>>>>>> [ 443.845756] CPU: 1 PID: 29607 Comm: dmsetup Not tainted 4.16.0_f605ba97fb80_master+ #1
>>>>>>>>> [ 443.846968] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.10.2-2.fc27 04/01/2014
>>>>>>>>> [ 443.848147] RIP: 0010:pool_io_hints+0x77/0x153 [dm_thin_pool]
>>>>>>>
>>>>>>> ...
>>>>>>>
>>>>>>>> I was able to reproduce (in my case RIP was pool_io_hints+0x45)
>>>>>>>>
>>>>>>>> Which on my kernel, is:
>>>>>>>>
>>>>>>>> crash> dis -l pool_io_hints+0x45
>>>>>>>> /root/snitm/git/linux/drivers/md/dm-thin.c: 2748
>>>>>>>> 0xffffffffc0765165 <pool_io_hints+69>: div %rdi
>>>>>>>>
>>>>>>>> Which is drivers/md/dm-thin.c:is_factor()'s return
>>>>>>>> !sector_div(block_size, n);
>>>>>>>>
>>>>>>>> SO looking at pool_io_hints() it would seem limits->max_sectors is 0 for
>>>>>>>> this xfstests device... why would that be!?
>>>>>>>>
>>>>>>>> Clearly pool_io_hints() could stand to be more defensive with a
>>>>>>>> !limits->max_sectors negative check but is it ever really valid for
>>>>>>>> max_sectors to be 0?
>>>>>>>>
>>>>>>>> Pretty sure the ultimate bug is outside DM (but not seeing an obvious
>>>>>>>> place where block core would set max_sectors to 0, all blk-settings.c
>>>>>>>> uses min_not_zero(), etc).
>>>>>>>
>>>>>>> I successfully ran this test against the linux-dm.git
>>>>>>> "for-4.17/dm-changes" tag that Linus merged after the block changes:
>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git tags/for-4.17/dm-changes
>>>>>>>
>>>>>>> # ./check tests/generic/347
>>>>>>> FSTYP -- ext4
>>>>>>> PLATFORM -- Linux/x86_64 thegoat 4.16.0-rc5.snitm
>>>>>>> MKFS_OPTIONS -- /dev/mapper/test-xfstests_scratch
>>>>>>> MOUNT_OPTIONS -- -o acl,user_xattr /dev/mapper/test-xfstests_scratch /scratch
>>>>>>>
>>>>>>> generic/347 65s
>>>>>>> Ran: generic/347
>>>>>>> Passed all 1 tests
>>>>>>>
>>>>>>> SO this would seem to implicate some regression in the 4.17 block layer
>>>>>>> changes.
>>>>>>
>>>>>> No immediate ideas come to mind, we didn't have a lot of changes and I
>>>>>> don't see anything that looks problematic. Maybe you can try and
>>>>>> bisect it and see what you come up with?
>>>>>
>>>>> I ran it, problematic commit is:
>>>>>
>>>>> commit 3c8ba0d61d04ced9f8d9ff93977995a9e4e96e91
>>>>> Author: Kees Cook <keescook@chromium.org>
>>>>> Date: Fri Mar 30 18:52:36 2018 -0700
>>>>>
>>>>> kernel.h: Retain constant expression output for max()/min()
>>>>>
>>>>
>>>> The fun continues. Thinking I'd try a userspace repro and thinking it
>>>> would be difficult to reproduce, try the attached min.c that just copies
>>>> all the bits from include/linux/kernel.h
>>>>
>>>> axboe@x1:~ $ gcc -Wall -O2 -o min min.c
>>>> axboe@x1:~ $ ./min 128 256
>>>> min_not_zero(128, 256) = 0
>>>
>>> This should be fixed with e9092d0d9796 ("Fix subtle macro variable
>>> shadowing in min_not_zero()").
>>
>> Yep that works, which is a relief. Some basic unit testing would have
>> been very appropriate in this case, given how fundamentally broken it
>> was... It's amazing nothing catastrophic happened.
>
> Actually, there was, :-)
>
> https://lkml.org/lkml/2018/4/9/355
That's bad, for sure, but my worry was bigger than an oops or crash,
we could have had corruption due to this.
The resulting min/max and friends would have been trivial to test, but
clearly they weren't.
--
Jens Axboe
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: limits->max_sectors is getting set to 0, why/where? [was: Re: dm: kernel oops by divide error on v4.16+]
2018-04-09 22:32 ` Jens Axboe
@ 2018-04-09 22:38 ` Kees Cook
-1 siblings, 0 replies; 29+ messages in thread
From: Kees Cook @ 2018-04-09 22:38 UTC (permalink / raw)
To: Jens Axboe, Linus Torvalds
Cc: linux-block, Chris Mason, dm-devel, Mike Snitzer, Ming Lei
On Mon, Apr 9, 2018 at 3:32 PM, Jens Axboe <axboe@kernel.dk> wrote:
> That's bad, for sure, but my worry was bigger than an oops or crash,
> we could have had corruption due to this.
>
> The resulting min/max and friends would have been trivial to test, but
> clearly they weren't.
Yeah, that was bad luck and my fault: I tested min(), max(), min_t(),
and max_t(). My assumption was that since the others were built from
them, they'd be fine. Not true in this shadow variable case, though.
:( We could do something like this, which would have caught it:
diff --git a/init/main.c b/init/main.c
index e4a3160991ea..ce46afc53b8b 100644
--- a/init/main.c
+++ b/init/main.c
@@ -993,10 +993,32 @@ static inline void mark_readonly(void)
}
#endif
+static inline void compiletime_sanity_checks(void)
+{
+ /* Sanity-check min()/max() family of macros. */
+ BUILD_BUG_ON(min(5, 50) != 5);
+ BUILD_BUG_ON(max(5, 50) != 50);
+ BUILD_BUG_ON(min_t(int, (size_t)-1 , 50) != -1);
+ BUILD_BUG_ON(max_t(size_t, -1 , 50) != (size_t)-1);
+ BUILD_BUG_ON(min3(-50, 0, 1000) != -50);
+ BUILD_BUG_ON(max3(-50, 0, 1000) != 1000);
+ BUILD_BUG_ON(min_not_zero(0, 20) != 20);
+ BUILD_BUG_ON(min_not_zero(30, 0) != 30);
+ BUILD_BUG_ON(min_not_zero(150, 40) != 40);
+ BUILD_BUG_ON(clamp(20, 1, 7) != 7);
+ BUILD_BUG_ON(clamp(40, 20, 100) != 40);
+ BUILD_BUG_ON(clamp(1, 20, 100) != 20);
+ BUILD_BUG_ON(clamp_t(int, -5, (size_t)-1, 100) != -1);
+ BUILD_BUG_ON(clamp_t(int, -1, (size_t)-5, 100) != -1);
+ BUILD_BUG_ON(clamp_t(size_t, -10, 1, -50) != -50);
+}
+
static int __ref kernel_init(void *unused)
{
int ret;
+ compiletime_sanity_checks();
+
kernel_init_freeable();
/* need to finish all async __init code before freeing the memory */
async_synchronize_full();
--
Kees Cook
Pixel Security
^ permalink raw reply related [flat|nested] 29+ messages in thread* Re: limits->max_sectors is getting set to 0, why/where? [was: Re: dm: kernel oops by divide error on v4.16+]
@ 2018-04-09 22:38 ` Kees Cook
0 siblings, 0 replies; 29+ messages in thread
From: Kees Cook @ 2018-04-09 22:38 UTC (permalink / raw)
To: Jens Axboe, Linus Torvalds
Cc: Ming Lei, Mike Snitzer, dm-devel, linux-block, Chris Mason
On Mon, Apr 9, 2018 at 3:32 PM, Jens Axboe <axboe@kernel.dk> wrote:
> That's bad, for sure, but my worry was bigger than an oops or crash,
> we could have had corruption due to this.
>
> The resulting min/max and friends would have been trivial to test, but
> clearly they weren't.
Yeah, that was bad luck and my fault: I tested min(), max(), min_t(),
and max_t(). My assumption was that since the others were built from
them, they'd be fine. Not true in this shadow variable case, though.
:( We could do something like this, which would have caught it:
diff --git a/init/main.c b/init/main.c
index e4a3160991ea..ce46afc53b8b 100644
--- a/init/main.c
+++ b/init/main.c
@@ -993,10 +993,32 @@ static inline void mark_readonly(void)
}
#endif
+static inline void compiletime_sanity_checks(void)
+{
+ /* Sanity-check min()/max() family of macros. */
+ BUILD_BUG_ON(min(5, 50) != 5);
+ BUILD_BUG_ON(max(5, 50) != 50);
+ BUILD_BUG_ON(min_t(int, (size_t)-1 , 50) != -1);
+ BUILD_BUG_ON(max_t(size_t, -1 , 50) != (size_t)-1);
+ BUILD_BUG_ON(min3(-50, 0, 1000) != -50);
+ BUILD_BUG_ON(max3(-50, 0, 1000) != 1000);
+ BUILD_BUG_ON(min_not_zero(0, 20) != 20);
+ BUILD_BUG_ON(min_not_zero(30, 0) != 30);
+ BUILD_BUG_ON(min_not_zero(150, 40) != 40);
+ BUILD_BUG_ON(clamp(20, 1, 7) != 7);
+ BUILD_BUG_ON(clamp(40, 20, 100) != 40);
+ BUILD_BUG_ON(clamp(1, 20, 100) != 20);
+ BUILD_BUG_ON(clamp_t(int, -5, (size_t)-1, 100) != -1);
+ BUILD_BUG_ON(clamp_t(int, -1, (size_t)-5, 100) != -1);
+ BUILD_BUG_ON(clamp_t(size_t, -10, 1, -50) != -50);
+}
+
static int __ref kernel_init(void *unused)
{
int ret;
+ compiletime_sanity_checks();
+
kernel_init_freeable();
/* need to finish all async __init code before freeing the memory */
async_synchronize_full();
--
Kees Cook
Pixel Security
^ permalink raw reply related [flat|nested] 29+ messages in thread* Re: limits->max_sectors is getting set to 0, why/where? [was: Re: dm: kernel oops by divide error on v4.16+]
2018-04-09 22:38 ` Kees Cook
@ 2018-04-09 23:01 ` Jens Axboe
-1 siblings, 0 replies; 29+ messages in thread
From: Jens Axboe @ 2018-04-09 23:01 UTC (permalink / raw)
To: Kees Cook, Linus Torvalds
Cc: linux-block, Chris Mason, dm-devel, Mike Snitzer, Ming Lei
On 4/9/18 4:38 PM, Kees Cook wrote:
> On Mon, Apr 9, 2018 at 3:32 PM, Jens Axboe <axboe@kernel.dk> wrote:
>> That's bad, for sure, but my worry was bigger than an oops or crash,
>> we could have had corruption due to this.
>>
>> The resulting min/max and friends would have been trivial to test, but
>> clearly they weren't.
>
> Yeah, that was bad luck and my fault: I tested min(), max(), min_t(),
It's only bad luck if it was tested :-)
> and max_t(). My assumption was that since the others were built from
> them, they'd be fine. Not true in this shadow variable case, though.
> :( We could do something like this, which would have caught it:
Might not hurt to do.
--
Jens Axboe
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: limits->max_sectors is getting set to 0, why/where? [was: Re: dm: kernel oops by divide error on v4.16+]
@ 2018-04-09 23:01 ` Jens Axboe
0 siblings, 0 replies; 29+ messages in thread
From: Jens Axboe @ 2018-04-09 23:01 UTC (permalink / raw)
To: Kees Cook, Linus Torvalds
Cc: Ming Lei, Mike Snitzer, dm-devel, linux-block, Chris Mason
On 4/9/18 4:38 PM, Kees Cook wrote:
> On Mon, Apr 9, 2018 at 3:32 PM, Jens Axboe <axboe@kernel.dk> wrote:
>> That's bad, for sure, but my worry was bigger than an oops or crash,
>> we could have had corruption due to this.
>>
>> The resulting min/max and friends would have been trivial to test, but
>> clearly they weren't.
>
> Yeah, that was bad luck and my fault: I tested min(), max(), min_t(),
It's only bad luck if it was tested :-)
> and max_t(). My assumption was that since the others were built from
> them, they'd be fine. Not true in this shadow variable case, though.
> :( We could do something like this, which would have caught it:
Might not hurt to do.
--
Jens Axboe
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: limits->max_sectors is getting set to 0, why/where? [was: Re: dm: kernel oops by divide error on v4.16+]
2018-04-09 22:32 ` Jens Axboe
@ 2018-04-09 23:54 ` Linus Torvalds
-1 siblings, 0 replies; 29+ messages in thread
From: Linus Torvalds @ 2018-04-09 23:54 UTC (permalink / raw)
To: Jens Axboe
Cc: Kees Cook, Mike Snitzer, Ming Lei, linux-block, Chris Mason,
dm-devel
On Mon, Apr 9, 2018 at 3:32 PM, Jens Axboe <axboe@kernel.dk> wrote:
>
> The resulting min/max and friends would have been trivial to test, but
> clearly they weren't.
Well, the min/max macros themselves actually were tested in user space by me.
It was the interaction with the unrelated "min_not_zero()" that wasn't ;)
It's easy in hind-sight to say "that's not at all unrelated", but
within the context of doing min/max, it was.
Linus
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: limits->max_sectors is getting set to 0, why/where? [was: Re: dm: kernel oops by divide error on v4.16+]
@ 2018-04-09 23:54 ` Linus Torvalds
0 siblings, 0 replies; 29+ messages in thread
From: Linus Torvalds @ 2018-04-09 23:54 UTC (permalink / raw)
To: Jens Axboe
Cc: Ming Lei, Kees Cook, Mike Snitzer, dm-devel, linux-block,
Chris Mason
On Mon, Apr 9, 2018 at 3:32 PM, Jens Axboe <axboe@kernel.dk> wrote:
>
> The resulting min/max and friends would have been trivial to test, but
> clearly they weren't.
Well, the min/max macros themselves actually were tested in user space by me.
It was the interaction with the unrelated "min_not_zero()" that wasn't ;)
It's easy in hind-sight to say "that's not at all unrelated", but
within the context of doing min/max, it was.
Linus
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: limits->max_sectors is getting set to 0, why/where? [was: Re: dm: kernel oops by divide error on v4.16+]
2018-04-09 23:54 ` Linus Torvalds
@ 2018-04-10 0:31 ` Jens Axboe
-1 siblings, 0 replies; 29+ messages in thread
From: Jens Axboe @ 2018-04-10 0:31 UTC (permalink / raw)
To: Linus Torvalds
Cc: Kees Cook, Mike Snitzer, Ming Lei, linux-block, Chris Mason,
dm-devel
On 4/9/18 5:54 PM, Linus Torvalds wrote:
> On Mon, Apr 9, 2018 at 3:32 PM, Jens Axboe <axboe@kernel.dk> wrote:
>>
>> The resulting min/max and friends would have been trivial to test, but
>> clearly they weren't.
>
> Well, the min/max macros themselves actually were tested in user space by me.
>
> It was the interaction with the unrelated "min_not_zero()" that wasn't ;)
>
> It's easy in hind-sight to say "that's not at all unrelated", but
> within the context of doing min/max, it was.
I guess we should just be thankful that it didn't cause bigger issues
than an oops.
--
Jens Axboe
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: limits->max_sectors is getting set to 0, why/where? [was: Re: dm: kernel oops by divide error on v4.16+]
@ 2018-04-10 0:31 ` Jens Axboe
0 siblings, 0 replies; 29+ messages in thread
From: Jens Axboe @ 2018-04-10 0:31 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ming Lei, Kees Cook, Mike Snitzer, dm-devel, linux-block,
Chris Mason
On 4/9/18 5:54 PM, Linus Torvalds wrote:
> On Mon, Apr 9, 2018 at 3:32 PM, Jens Axboe <axboe@kernel.dk> wrote:
>>
>> The resulting min/max and friends would have been trivial to test, but
>> clearly they weren't.
>
> Well, the min/max macros themselves actually were tested in user space by me.
>
> It was the interaction with the unrelated "min_not_zero()" that wasn't ;)
>
> It's easy in hind-sight to say "that's not at all unrelated", but
> within the context of doing min/max, it was.
I guess we should just be thankful that it didn't cause bigger issues
than an oops.
--
Jens Axboe
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: limits->max_sectors is getting set to 0, why/where? [was: Re: dm: kernel oops by divide error on v4.16+]
2018-04-09 21:56 ` Jens Axboe
@ 2018-04-09 22:11 ` Linus Torvalds
-1 siblings, 0 replies; 29+ messages in thread
From: Linus Torvalds @ 2018-04-09 22:11 UTC (permalink / raw)
To: Jens Axboe
Cc: Kees Cook, Mike Snitzer, Ming Lei, linux-block, Chris Mason,
dm-devel
[-- Attachment #1.1: Type: text/plain, Size: 3640 bytes --]
On mobile, sorry for html crud and top posting, but here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e9092d0d97961146655ce51f43850907d95f68c3
Should fix it.
Linus
On Mon, Apr 9, 2018, 14:56 Jens Axboe <axboe@kernel.dk> wrote:
> On 4/9/18 3:26 PM, Jens Axboe wrote:
> > On 4/9/18 1:32 PM, Jens Axboe wrote:
> >> On 4/9/18 12:38 PM, Mike Snitzer wrote:
> >>> On Mon, Apr 09 2018 at 11:51am -0400,
> >>> Mike Snitzer <snitzer@redhat.com> wrote:
> >>>
> >>>> On Sun, Apr 08 2018 at 12:00am -0400,
> >>>> Ming Lei <ming.lei@redhat.com> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> The following kernel oops(divide error) is triggered when running
> >>>>> xfstest(generic/347) on ext4.
> >>>>>
> >>>>> [ 442.632954] run fstests generic/347 at 2018-04-07 18:06:44
> >>>>> [ 443.839480] divide error: 0000 [#1] PREEMPT SMP PTI
> >>>>> [ 443.840201] Dumping ftrace buffer:
> >>>>> [ 443.840692] (ftrace buffer empty)
> >>> ...
> >>>>> [ 443.845756] CPU: 1 PID: 29607 Comm: dmsetup Not tainted
> 4.16.0_f605ba97fb80_master+ #1
> >>>>> [ 443.846968] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),
> BIOS 1.10.2-2.fc27 04/01/2014
> >>>>> [ 443.848147] RIP: 0010:pool_io_hints+0x77/0x153 [dm_thin_pool]
> >>>
> >>> ...
> >>>
> >>>> I was able to reproduce (in my case RIP was pool_io_hints+0x45)
> >>>>
> >>>> Which on my kernel, is:
> >>>>
> >>>> crash> dis -l pool_io_hints+0x45
> >>>> /root/snitm/git/linux/drivers/md/dm-thin.c: 2748
> >>>> 0xffffffffc0765165 <pool_io_hints+69>: div %rdi
> >>>>
> >>>> Which is drivers/md/dm-thin.c:is_factor()'s return
> >>>> !sector_div(block_size, n);
> >>>>
> >>>> SO looking at pool_io_hints() it would seem limits->max_sectors is 0
> for
> >>>> this xfstests device... why would that be!?
> >>>>
> >>>> Clearly pool_io_hints() could stand to be more defensive with a
> >>>> !limits->max_sectors negative check but is it ever really valid for
> >>>> max_sectors to be 0?
> >>>>
> >>>> Pretty sure the ultimate bug is outside DM (but not seeing an obvious
> >>>> place where block core would set max_sectors to 0, all blk-settings.c
> >>>> uses min_not_zero(), etc).
> >>>
> >>> I successfully ran this test against the linux-dm.git
> >>> "for-4.17/dm-changes" tag that Linus merged after the block changes:
> >>> git://
> git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git
> tags/for-4.17/dm-changes
> >>>
> >>> # ./check tests/generic/347
> >>> FSTYP -- ext4
> >>> PLATFORM -- Linux/x86_64 thegoat 4.16.0-rc5.snitm
> >>> MKFS_OPTIONS -- /dev/mapper/test-xfstests_scratch
> >>> MOUNT_OPTIONS -- -o acl,user_xattr /dev/mapper/test-xfstests_scratch
> /scratch
> >>>
> >>> generic/347 65s
> >>> Ran: generic/347
> >>> Passed all 1 tests
> >>>
> >>> SO this would seem to implicate some regression in the 4.17 block layer
> >>> changes.
> >>
> >> No immediate ideas come to mind, we didn't have a lot of changes and I
> >> don't see anything that looks problematic. Maybe you can try and
> >> bisect it and see what you come up with?
> >
> > I ran it, problematic commit is:
> >
> > commit 3c8ba0d61d04ced9f8d9ff93977995a9e4e96e91
> > Author: Kees Cook <keescook@chromium.org>
> > Date: Fri Mar 30 18:52:36 2018 -0700
> >
> > kernel.h: Retain constant expression output for max()/min()
> >
>
> The fun continues. Thinking I'd try a userspace repro and thinking it
> would be difficult to reproduce, try the attached min.c that just copies
> all the bits from include/linux/kernel.h
>
> axboe@x1:~ $ gcc -Wall -O2 -o min min.c
> axboe@x1:~ $ ./min 128 256
> min_not_zero(128, 256) = 0
>
> --
> Jens Axboe
>
>
[-- Attachment #1.2: Type: text/html, Size: 5662 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: limits->max_sectors is getting set to 0, why/where? [was: Re: dm: kernel oops by divide error on v4.16+]
@ 2018-04-09 22:11 ` Linus Torvalds
0 siblings, 0 replies; 29+ messages in thread
From: Linus Torvalds @ 2018-04-09 22:11 UTC (permalink / raw)
To: Jens Axboe
Cc: Mike Snitzer, Ming Lei, dm-devel, linux-block, Kees Cook,
Chris Mason
[-- Attachment #1: Type: text/plain, Size: 3640 bytes --]
On mobile, sorry for html crud and top posting, but here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e9092d0d97961146655ce51f43850907d95f68c3
Should fix it.
Linus
On Mon, Apr 9, 2018, 14:56 Jens Axboe <axboe@kernel.dk> wrote:
> On 4/9/18 3:26 PM, Jens Axboe wrote:
> > On 4/9/18 1:32 PM, Jens Axboe wrote:
> >> On 4/9/18 12:38 PM, Mike Snitzer wrote:
> >>> On Mon, Apr 09 2018 at 11:51am -0400,
> >>> Mike Snitzer <snitzer@redhat.com> wrote:
> >>>
> >>>> On Sun, Apr 08 2018 at 12:00am -0400,
> >>>> Ming Lei <ming.lei@redhat.com> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> The following kernel oops(divide error) is triggered when running
> >>>>> xfstest(generic/347) on ext4.
> >>>>>
> >>>>> [ 442.632954] run fstests generic/347 at 2018-04-07 18:06:44
> >>>>> [ 443.839480] divide error: 0000 [#1] PREEMPT SMP PTI
> >>>>> [ 443.840201] Dumping ftrace buffer:
> >>>>> [ 443.840692] (ftrace buffer empty)
> >>> ...
> >>>>> [ 443.845756] CPU: 1 PID: 29607 Comm: dmsetup Not tainted
> 4.16.0_f605ba97fb80_master+ #1
> >>>>> [ 443.846968] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),
> BIOS 1.10.2-2.fc27 04/01/2014
> >>>>> [ 443.848147] RIP: 0010:pool_io_hints+0x77/0x153 [dm_thin_pool]
> >>>
> >>> ...
> >>>
> >>>> I was able to reproduce (in my case RIP was pool_io_hints+0x45)
> >>>>
> >>>> Which on my kernel, is:
> >>>>
> >>>> crash> dis -l pool_io_hints+0x45
> >>>> /root/snitm/git/linux/drivers/md/dm-thin.c: 2748
> >>>> 0xffffffffc0765165 <pool_io_hints+69>: div %rdi
> >>>>
> >>>> Which is drivers/md/dm-thin.c:is_factor()'s return
> >>>> !sector_div(block_size, n);
> >>>>
> >>>> SO looking at pool_io_hints() it would seem limits->max_sectors is 0
> for
> >>>> this xfstests device... why would that be!?
> >>>>
> >>>> Clearly pool_io_hints() could stand to be more defensive with a
> >>>> !limits->max_sectors negative check but is it ever really valid for
> >>>> max_sectors to be 0?
> >>>>
> >>>> Pretty sure the ultimate bug is outside DM (but not seeing an obvious
> >>>> place where block core would set max_sectors to 0, all blk-settings.c
> >>>> uses min_not_zero(), etc).
> >>>
> >>> I successfully ran this test against the linux-dm.git
> >>> "for-4.17/dm-changes" tag that Linus merged after the block changes:
> >>> git://
> git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git
> tags/for-4.17/dm-changes
> >>>
> >>> # ./check tests/generic/347
> >>> FSTYP -- ext4
> >>> PLATFORM -- Linux/x86_64 thegoat 4.16.0-rc5.snitm
> >>> MKFS_OPTIONS -- /dev/mapper/test-xfstests_scratch
> >>> MOUNT_OPTIONS -- -o acl,user_xattr /dev/mapper/test-xfstests_scratch
> /scratch
> >>>
> >>> generic/347 65s
> >>> Ran: generic/347
> >>> Passed all 1 tests
> >>>
> >>> SO this would seem to implicate some regression in the 4.17 block layer
> >>> changes.
> >>
> >> No immediate ideas come to mind, we didn't have a lot of changes and I
> >> don't see anything that looks problematic. Maybe you can try and
> >> bisect it and see what you come up with?
> >
> > I ran it, problematic commit is:
> >
> > commit 3c8ba0d61d04ced9f8d9ff93977995a9e4e96e91
> > Author: Kees Cook <keescook@chromium.org>
> > Date: Fri Mar 30 18:52:36 2018 -0700
> >
> > kernel.h: Retain constant expression output for max()/min()
> >
>
> The fun continues. Thinking I'd try a userspace repro and thinking it
> would be difficult to reproduce, try the attached min.c that just copies
> all the bits from include/linux/kernel.h
>
> axboe@x1:~ $ gcc -Wall -O2 -o min min.c
> axboe@x1:~ $ ./min 128 256
> min_not_zero(128, 256) = 0
>
> --
> Jens Axboe
>
>
[-- Attachment #2: Type: text/html, Size: 5662 bytes --]
^ permalink raw reply [flat|nested] 29+ messages in thread