linux-bcache.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Yu Kuai <yukuai1@huaweicloud.com>
Cc: axboe@kernel.dk, roger.pau@citrix.com, colyli@suse.de,
	kent.overstreet@gmail.com, joern@lazybastard.org,
	miquel.raynal@bootlin.com, richard@nod.at, vigneshr@ti.com,
	sth@linux.ibm.com, hoeppner@linux.ibm.com, hca@linux.ibm.com,
	gor@linux.ibm.com, agordeev@linux.ibm.com, jejb@linux.ibm.com,
	martin.petersen@oracle.com, clm@fb.com, josef@toxicpanda.com,
	dsterba@suse.com, nico@fluxnic.net, xiang@kernel.org,
	chao@kernel.org, tytso@mit.edu, adilger.kernel@dilger.ca,
	agruenba@redhat.com, jack@suse.com, konishi.ryusuke@gmail.com,
	willy@infradead.org, akpm@linux-foundation.org, hare@suse.de,
	p.raghav@samsung.com, linux-block@vger.kernel.org,
	linux-kernel@vger.kernel.org, xen-devel@lists.xenproject.org,
	linux-bcache@vger.kernel.org, linux-mtd@lists.infradead.org,
	linux-s390@vger.kernel.org, linux-scsi@vger.kernel.org,
	linux-bcachefs@vger.kernel.org, linux-btrfs@vger.kernel.org,
	linux-erofs@lists.ozlabs.org, linux-ext4@vger.kernel.org,
	gfs2@lists.linux.dev, linux-nilfs@vger.kernel.org,
	yukuai3@huawei.com, yi.zhang@huawei.com, yangerkun@huawei.com
Subject: Re: [PATCH -next RFC 01/14] block: add some bdev apis
Date: Tue, 5 Dec 2023 22:14:00 -0800	[thread overview]
Message-ID: <ZXARKD0OmjLrvHmU@infradead.org> (raw)
In-Reply-To: <20231205123728.1866699-2-yukuai1@huaweicloud.com>

> +void invalidate_bdev_range(struct block_device *bdev, pgoff_t start,
> +			   pgoff_t end)
> +{
> +	invalidate_mapping_pages(bdev->bd_inode->i_mapping, start, end);
> +}
> +EXPORT_SYMBOL_GPL(invalidate_bdev_range);

All these could probably use kerneldoc comments.

For this one I really don't like it existing at all, but we'll have to
discuss that in the btrfs patch.

> +loff_t bdev_size(struct block_device *bdev)
> +{
> +	loff_t size;
> +
> +	spin_lock(&bdev->bd_size_lock);
> +	size = i_size_read(bdev->bd_inode);
> +	spin_unlock(&bdev->bd_size_lock);
> +
> +	return size;
> +}
> +EXPORT_SYMBOL_GPL(bdev_size);

No need for this one.  The callers can simply use bdev_nr_bytes.

> +struct folio *bdev_read_folio(struct block_device *bdev, pgoff_t index)
> +{
> +	return read_mapping_folio(bdev->bd_inode->i_mapping, index, NULL);
> +}
> +EXPORT_SYMBOL_GPL(bdev_read_folio);
> +
> +struct folio *bdev_read_folio_gfp(struct block_device *bdev, pgoff_t index,
> +				  gfp_t gfp)
> +{
> +	return mapping_read_folio_gfp(bdev->bd_inode->i_mapping, index, gfp);
> +}
> +EXPORT_SYMBOL_GPL(bdev_read_folio_gfp);

I think we can just drop bdev_read_folio_gfp. Half of the callers simply
pass GPK_KERNEL, and the other half passes GFP_NOFS and could just use
memalloc_nofs_save().

> +void bdev_balance_dirty_pages_ratelimited(struct block_device *bdev)
> +{
> +	return balance_dirty_pages_ratelimited(bdev->bd_inode->i_mapping);
> +}
> +EXPORT_SYMBOL_GPL(bdev_balance_dirty_pages_ratelimited);

Hmm, this is just used for block2mtd, and feels a little too low-level
to me, as block2mtd really should be using the normal fileread/write
APIs.  I guess we'll have to live with it for now if we want to expedite
killing off bd_inode.

> +void bdev_correlate_mapping(struct block_device *bdev,
> +			    struct address_space *mapping)
> +{
> +	mapping->host = bdev->bd_inode;
> +}
> +EXPORT_SYMBOL_GPL(bdev_correlate_mapping);

Maybe associated insted of correlate?  Either way this basically
fully exposes the bdev inode again :(

> +gfp_t bdev_gfp_constraint(struct block_device *bdev, gfp_t gfp)
> +{
> +	return mapping_gfp_constraint(bdev->bd_inode->i_mapping, gfp);
> +}
> +EXPORT_SYMBOL_GPL(bdev_gfp_constraint);

The right fix here is to:

 - use memalloc_nofs_save in extet instead of using
   mapping_gfp_constraint to clear it from the mapping flags
 - remove __ext4_sb_bread_gfp and just have buffer.c helper that does
   the right thing (either by changing the calling conventions of an
   existing one, or adding a new one).

> +/*
> + * The del_gendisk() function uninitializes the disk-specific data
> + * structures, including the bdi structure, without telling anyone
> + * else.  Once this happens, any attempt to call mark_buffer_dirty()
> + * (for example, by ext4_commit_super), will cause a kernel OOPS.
> + * This is a kludge to prevent these oops until we can put in a proper
> + * hook in del_gendisk() to inform the VFS and file system layers.
> + */
> +int bdev_ejected(struct block_device *bdev)
> +{
> +	struct backing_dev_info *bdi = inode_to_bdi(bdev->bd_inode);
> +
> +	return bdi->dev == NULL;
> +}
> +EXPORT_SYMBOL_GPL(bdev_ejected);

And this code in ext4 should just go away entirely.  The bdi should
always be valid for a live bdev for years.

> --- a/block/bio.c
> +++ b/block/bio.c
> @@ -1119,6 +1119,7 @@ void bio_add_folio_nofail(struct bio *bio, struct folio *folio, size_t len,
>  	WARN_ON_ONCE(off > UINT_MAX);
>  	__bio_add_page(bio, &folio->page, len, off);
>  }
> +EXPORT_SYMBOL_GPL(bio_add_folio_nofail);

How is this realted?  The export is fine, but really should be a
separate, well-documented commit.

>  
> +static inline u8 block_bits(struct block_device *bdev)
> +{
> +	return bdev->bd_inode->i_blkbits;
> +}

Not sure we should need this.  i_blkbits comes from the blocksize
the fs set, so it should have other ways to get at it.

  parent reply	other threads:[~2023-12-06  6:14 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-05 12:37 [PATCH -next RFC 00/14] block: don't access bd_inode directly from other modules Yu Kuai
2023-12-05 12:37 ` [PATCH -next RFC 01/14] block: add some bdev apis Yu Kuai
2023-12-05 17:03   ` Bart Van Assche
2023-12-06  6:14   ` Christoph Hellwig [this message]
2023-12-06  6:50     ` Yu Kuai
2023-12-06  7:20       ` Christoph Hellwig
2023-12-06 17:50     ` Theodore Ts'o
2023-12-06 17:57       ` Christoph Hellwig
2023-12-06 14:58   ` Matthew Wilcox
2023-12-07  2:45     ` Yu Kuai
2023-12-05 12:37 ` [PATCH -next RFC 02/14] xen/blkback: use bdev api in xen_update_blkif_status() Yu Kuai
2023-12-06  5:55   ` Christoph Hellwig
2023-12-06  6:56     ` Yu Kuai
2023-12-06  7:21       ` Christoph Hellwig
2023-12-05 12:37 ` [PATCH -next RFC 03/14] bcache: use bdev api in read_super() Yu Kuai
2023-12-05 12:37 ` [PATCH -next RFC 04/14] mtd: block2mtd: use bdev apis Yu Kuai
2023-12-05 12:37 ` [PATCH -next RFC 05/14] s390/dasd: use bdev api in dasd_format() Yu Kuai
2023-12-05 12:37 ` [PATCH -next RFC 06/14] scsicam: use bdev api in scsi_bios_ptable() Yu Kuai
2023-12-05 12:37 ` [PATCH -next RFC 07/14] bcachefs: remove dead function bdev_sectors() Yu Kuai
2023-12-05 12:37 ` [PATCH -next RFC 08/14] btrfs: use bdev apis Yu Kuai
2023-12-05 12:37 ` [PATCH -next RFC 09/14] cramfs: use bdev apis in cramfs_blkdev_read() Yu Kuai
2023-12-05 12:37 ` [PATCH -next RFC 10/14] erofs: use bdev api Yu Kuai
2023-12-05 12:37 ` [PATCH -next RFC 11/14] ext4: use bdev apis Yu Kuai
2023-12-05 12:38 ` [PATCH -next RFC 12/14] jbd2: " Yu Kuai
2023-12-05 12:39 ` [PATCH -next RFC 13/14] gfs2: use bdev api Yu Kuai
2023-12-05 12:39 ` [PATCH -next RFC 14/14] nilfs2: use bdev api in nilfs_attach_log_writer() Yu Kuai
2023-12-06  5:54 ` [PATCH -next RFC 00/14] block: don't access bd_inode directly from other modules Christoph Hellwig
2023-12-06  6:06   ` Yu Kuai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZXARKD0OmjLrvHmU@infradead.org \
    --to=hch@infradead.org \
    --cc=adilger.kernel@dilger.ca \
    --cc=agordeev@linux.ibm.com \
    --cc=agruenba@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=chao@kernel.org \
    --cc=clm@fb.com \
    --cc=colyli@suse.de \
    --cc=dsterba@suse.com \
    --cc=gfs2@lists.linux.dev \
    --cc=gor@linux.ibm.com \
    --cc=hare@suse.de \
    --cc=hca@linux.ibm.com \
    --cc=hoeppner@linux.ibm.com \
    --cc=jack@suse.com \
    --cc=jejb@linux.ibm.com \
    --cc=joern@lazybastard.org \
    --cc=josef@toxicpanda.com \
    --cc=kent.overstreet@gmail.com \
    --cc=konishi.ryusuke@gmail.com \
    --cc=linux-bcache@vger.kernel.org \
    --cc=linux-bcachefs@vger.kernel.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-erofs@lists.ozlabs.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-nilfs@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=miquel.raynal@bootlin.com \
    --cc=nico@fluxnic.net \
    --cc=p.raghav@samsung.com \
    --cc=richard@nod.at \
    --cc=roger.pau@citrix.com \
    --cc=sth@linux.ibm.com \
    --cc=tytso@mit.edu \
    --cc=vigneshr@ti.com \
    --cc=willy@infradead.org \
    --cc=xen-devel@lists.xenproject.org \
    --cc=xiang@kernel.org \
    --cc=yangerkun@huawei.com \
    --cc=yi.zhang@huawei.com \
    --cc=yukuai1@huaweicloud.com \
    --cc=yukuai3@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).