[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACVXFVP-3gwmKkmATBUa=P-Tp1h1sZbZypfLkuOwDk60+E0PKQ@mail.gmail.com>
Date: Tue, 1 Aug 2017 20:39:13 +0800
From: Ming Lei <tom.leiming@...il.com>
To: Anton Volkov <avolkov@...ras.ru>
Cc: Jens Axboe <axboe@...com>, Omar Sandoval <osandov@...com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
ldv-project@...uxtesting.org,
Alexey Khoroshilov <khoroshilov@...ras.ru>
Subject: Re: Possible race in loop.ko
On Fri, Jul 28, 2017 at 11:55 PM, Anton Volkov <avolkov@...ras.ru> wrote:
> Hello.
> While searching for races in Linux kernel I've come across
> drivers/block/loop.ko module. Here is the question that I came up with while
> analyzing results. Lines are given using the info from Linux v4.12.
>
> In loop_init function additional initialization happens after a successful
> call to misc_register() (loop.c: line 1961). Consider the following case:
>
> Thread 1: Thread 2:
> loop_init()
> misc_register() loop_control_ioctl
> part_shift = 0 -> loop_add
> if (max_part > 0) { alloc_disk(1 << part_shift)
> part_shift =
> <greater than 0>
> ...
> }
>
> In this case alloc_disk() will be called with 1 as a parameter although
> part_shift should have been greater than 0. Maybe it would be better to move
> the call to a misc_register() function a bit further down (at least so it
> could be after the part_shift initialization)?
That looks a good idea, could you cook a patch to do it?
--
Ming Lei
Powered by blists - more mailing lists