Received-SPF: pass (google.com: domain of linux-kernel+bounces-211944-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Message-ID: <795edef9-2bd7-413f-bba2-04d569da63b6@kernel.dk>
Date: Wed, 12 Jun 2024 10:54:29 -0600
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH] aoe: consolidate flags update to prevent race condition
To: Gui-Dong Han <hanguidong02@outlook.com>, justin@coraid.com
Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org,
 baijiaju1990@gmail.com
References: <ME3P282MB3617DAD141ACDD21170355E0C0C72@ME3P282MB3617.AUSP282.PROD.OUTLOOK.COM>
Content-Language: en-US
From: Jens Axboe <axboe@kernel.dk>
In-Reply-To: <ME3P282MB3617DAD141ACDD21170355E0C0C72@ME3P282MB3617.AUSP282.PROD.OUTLOOK.COM>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 6/10/24 9:52 PM, Gui-Dong Han wrote:
> In aoecmd_sleepwork, there is a race condition caused by two consecutive
> writes to the 'flags' variable within a critical section. If a read 
> operation occurs between these writes, an intermediate state may be 
> read, potentially causing bugs.
> 
> To address this issue, the 'flags' variable should be updated in a 
> single operation to ensure atomicity and prevent any intermediate state
> from being read.
> 
> Fixes: 3ae1c24e395b ("[PATCH] aoe [2/8]: support dynamic resizing of AoE devices")
> Signed-off-by: Gui-Dong Han <hanguidong02@outlook.com>
> ---
>  drivers/block/aoe/aoecmd.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/block/aoe/aoecmd.c b/drivers/block/aoe/aoecmd.c
> index cc9077b588d7..37d556f019c0 100644
> --- a/drivers/block/aoe/aoecmd.c
> +++ b/drivers/block/aoe/aoecmd.c
> @@ -897,8 +897,7 @@ aoecmd_sleepwork(struct work_struct *work)
>  		set_capacity_and_notify(d->gd, d->ssize);
>  
>  		spin_lock_irq(&d->lock);
> -		d->flags |= DEVFL_UP;
> -		d->flags &= ~DEVFL_NEWSIZE;
> +		d->flags = (d->flags | DEVFL_UP) & ~DEVFL_NEWSIZE;
>  		spin_unlock_irq(&d->lock);
>  	}

It's modified under the lock, and any reader should do so as well. If
not, there's a race regardless of your change or not.

-- 
Jens Axboe