[PATCH 2/2] block: skip the fsync_bdev call in del_gendisk for surprise removals

[Hannes Reinecke]

On 2/16/22 16:09, Christoph Hellwig wrote:
> For surprise removals that have already marked the disk dead, there is
> no point in calling fsync_bdev as all I/O will fail anyway, so skip it.
> 
> Signed-off-by: Christoph Hellwig <hch at lst.de>
> ---
>   block/genhd.c | 9 ++++++++-
>   1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/block/genhd.c b/block/genhd.c
> index 626c8406f21a6..f68bdfe4f883b 100644
> --- a/block/genhd.c
> +++ b/block/genhd.c
> @@ -584,7 +584,14 @@ void del_gendisk(struct gendisk *disk)
>   	blk_drop_partitions(disk);
>   	mutex_unlock(&disk->open_mutex);
>   
> -	fsync_bdev(disk->part0);
> +	/*
> +	 * If this is not a surprise removal see if there is a file system
> +	 * mounted on this device and sync it (although this won't work for
> +	 * partitions).  For surprise removals that have already marked the
> +	 * disk dead skip this call as no I/O is possible anyway.
> +	 */
> +	if (!test_bit(GD_DEAD, &disk->state))
> +		fsync_bdev(disk->part0);
>   	__invalidate_device(disk->part0, true);
>   
>   	/*
My turn to be picky:
In the previous patch you use 'set_bit()' for GD_DEAD, which to my 
knowledge doesn't imply a memory barrier.
Yet here you rely on that for the 'test_bit()' to return the 
correct/most recent value.
Don't we need a memory barrier here somewhere?

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare at suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer