Re: [PATCH] ext2/super: Fix a possible sleep-in-atomic bug in parse_options

On Sat 07-10-17 03:02:17, Al Viro wrote: > On Fri, Oct 06, 2017 at 06:37:11PM -0700, Linus Torvalds wrote: > > On Fri, Oct 6, 2017 at 6:20 PM, Jia-Ju Bai wrote: > > > > > > To fix it, GFP_KERNEL is replaced with GFP_ATOMIC. > > > This bug is found by my static analysis tool

Re: [PATCH] ext2/super: Fix a possible sleep-in-atomic bug in parse_options

On Sat 07-10-17 03:02:17, Al Viro wrote: > On Fri, Oct 06, 2017 at 06:37:11PM -0700, Linus Torvalds wrote: > > On Fri, Oct 6, 2017 at 6:20 PM, Jia-Ju Bai wrote: > > > > > > To fix it, GFP_KERNEL is replaced with GFP_ATOMIC. > > > This bug is found by my static analysis tool and my code review. >

Re: [PATCH] ext2/super: Fix a possible sleep-in-atomic bug in parse_options

On Sat, Oct 07, 2017 at 09:20:46AM +0800, Jia-Ju Bai wrote: > The kernel may sleep under a spinlock, and the function call path is: > ext2_remount > parse_options > match_int > match_number (lib/parser.c) > kmalloc(GFP_KERNEL) --> may sleep > > To fix it, GFP_KERNEL is

Re: [PATCH] ext2/super: Fix a possible sleep-in-atomic bug in parse_options

On Sat, Oct 07, 2017 at 09:20:46AM +0800, Jia-Ju Bai wrote: > The kernel may sleep under a spinlock, and the function call path is: > ext2_remount > parse_options > match_int > match_number (lib/parser.c) > kmalloc(GFP_KERNEL) --> may sleep > > To fix it, GFP_KERNEL is

Re: [PATCH] ext2/super: Fix a possible sleep-in-atomic bug in parse_options

On Sat, Oct 07, 2017 at 03:02:17AM +0100, Al Viro wrote: > > I do wonder if we shouldn't just use something like > > > > "skip leading zeroes, copy to size-limited stack location instead" > > > > because the input length really *is* limited once you skip leading > > zeroes (and whatever base

Re: [PATCH] ext2/super: Fix a possible sleep-in-atomic bug in parse_options

On Sat, Oct 07, 2017 at 03:02:17AM +0100, Al Viro wrote: > > I do wonder if we shouldn't just use something like > > > > "skip leading zeroes, copy to size-limited stack location instead" > > > > because the input length really *is* limited once you skip leading > > zeroes (and whatever base

Re: [PATCH] ext2/super: Fix a possible sleep-in-atomic bug in parse_options

On Fri, Oct 06, 2017 at 06:37:11PM -0700, Linus Torvalds wrote: > On Fri, Oct 6, 2017 at 6:20 PM, Jia-Ju Bai wrote: > > > > To fix it, GFP_KERNEL is replaced with GFP_ATOMIC. > > This bug is found by my static analysis tool and my code review. > > I'm not saying your patch

Re: [PATCH] ext2/super: Fix a possible sleep-in-atomic bug in parse_options

On Fri, Oct 06, 2017 at 06:37:11PM -0700, Linus Torvalds wrote: > On Fri, Oct 6, 2017 at 6:20 PM, Jia-Ju Bai wrote: > > > > To fix it, GFP_KERNEL is replaced with GFP_ATOMIC. > > This bug is found by my static analysis tool and my code review. > > I'm not saying your patch is wrong, but it's a

Re: [PATCH] ext2/super: Fix a possible sleep-in-atomic bug in parse_options

Thanks for your reply. I agree that extra allocation in match_number() and match_u64int() may be unnecessary. Thanks, Jia-Ju Bai On 2017/10/7 9:37, Linus Torvalds wrote: On Fri, Oct 6, 2017 at 6:20 PM, Jia-Ju Bai wrote: To fix it, GFP_KERNEL is replaced with

Re: [PATCH] ext2/super: Fix a possible sleep-in-atomic bug in parse_options

Thanks for your reply. I agree that extra allocation in match_number() and match_u64int() may be unnecessary. Thanks, Jia-Ju Bai On 2017/10/7 9:37, Linus Torvalds wrote: On Fri, Oct 6, 2017 at 6:20 PM, Jia-Ju Bai wrote: To fix it, GFP_KERNEL is replaced with GFP_ATOMIC. This bug is found

Re: [PATCH] ext2/super: Fix a possible sleep-in-atomic bug in parse_options

On Fri, Oct 6, 2017 at 6:20 PM, Jia-Ju Bai wrote: > > To fix it, GFP_KERNEL is replaced with GFP_ATOMIC. > This bug is found by my static analysis tool and my code review. I'm not saying your patch is wrong, but it's a shame that we do that extra allocation in

Re: [PATCH] ext2/super: Fix a possible sleep-in-atomic bug in parse_options

On Fri, Oct 6, 2017 at 6:20 PM, Jia-Ju Bai wrote: > > To fix it, GFP_KERNEL is replaced with GFP_ATOMIC. > This bug is found by my static analysis tool and my code review. I'm not saying your patch is wrong, but it's a shame that we do that extra allocation in match_number() and match_u64int(),

[PATCH] ext2/super: Fix a possible sleep-in-atomic bug in parse_options

The kernel may sleep under a spinlock, and the function call path is: ext2_remount parse_options match_int match_number (lib/parser.c) kmalloc(GFP_KERNEL) --> may sleep To fix it, GFP_KERNEL is replaced with GFP_ATOMIC. This bug is found by my static analysis tool and my code

[PATCH] ext2/super: Fix a possible sleep-in-atomic bug in parse_options

The kernel may sleep under a spinlock, and the function call path is: ext2_remount parse_options match_int match_number (lib/parser.c) kmalloc(GFP_KERNEL) --> may sleep To fix it, GFP_KERNEL is replaced with GFP_ATOMIC. This bug is found by my static analysis tool and my code