linux-ext4 - Re: [PATCH 01/32] block: Provide blkdev_get_handle

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230704130356.xwdlxvgvi4l6sruc@quack3>
Date:   Tue, 4 Jul 2023 15:03:56 +0200
From:   Jan Kara <jack@...e.cz>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Jan Kara <jack@...e.cz>, linux-block@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, Jens Axboe <axboe@...nel.dk>,
        Christoph Hellwig <hch@...radead.org>,
        Alasdair Kergon <agk@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Anna Schumaker <anna@...nel.org>, Chao Yu <chao@...nel.org>,
        Christian Borntraeger <borntraeger@...ux.ibm.com>,
        "Darrick J. Wong" <djwong@...nel.org>,
        Dave Kleikamp <shaggy@...nel.org>,
        David Sterba <dsterba@...e.com>, dm-devel@...hat.com,
        drbd-dev@...ts.linbit.com, Gao Xiang <xiang@...nel.org>,
        Jack Wang <jinpu.wang@...os.com>,
        Jaegeuk Kim <jaegeuk@...nel.org>,
        jfs-discussion@...ts.sourceforge.net,
        Joern Engel <joern@...ybastard.org>,
        Joseph Qi <joseph.qi@...ux.alibaba.com>,
        Kent Overstreet <kent.overstreet@...il.com>,
        linux-bcache@...r.kernel.org, linux-btrfs@...r.kernel.org,
        linux-erofs@...ts.ozlabs.org, linux-ext4@...r.kernel.org,
        linux-f2fs-devel@...ts.sourceforge.net, linux-mm@...ck.org,
        linux-mtd@...ts.infradead.org, linux-nfs@...r.kernel.org,
        linux-nilfs@...r.kernel.org, linux-nvme@...ts.infradead.org,
        linux-pm@...r.kernel.org, linux-raid@...r.kernel.org,
        linux-s390@...r.kernel.org, linux-scsi@...r.kernel.org,
        linux-xfs@...r.kernel.org,
        "Md. Haris Iqbal" <haris.iqbal@...os.com>,
        Mike Snitzer <snitzer@...nel.org>,
        Minchan Kim <minchan@...nel.org>, ocfs2-devel@....oracle.com,
        reiserfs-devel@...r.kernel.org,
        Sergey Senozhatsky <senozhatsky@...omium.org>,
        Song Liu <song@...nel.org>,
        Sven Schnelle <svens@...ux.ibm.com>,
        target-devel@...r.kernel.org, Ted Tso <tytso@....edu>,
        Trond Myklebust <trond.myklebust@...merspace.com>,
        xen-devel@...ts.xenproject.org
Subject: Re: [PATCH 01/32] block: Provide blkdev_get_handle_* functions

On Tue 04-07-23 13:43:51, Matthew Wilcox wrote:
> On Tue, Jul 04, 2023 at 02:21:28PM +0200, Jan Kara wrote:
> > +struct bdev_handle *blkdev_get_handle_by_dev(dev_t dev, blk_mode_t mode,
> > +		void *holder, const struct blk_holder_ops *hops)
> > +{
> > +	struct bdev_handle *handle = kmalloc(sizeof(struct bdev_handle),
> > +					     GFP_KERNEL);
> > +	struct block_device *bdev;
> > +
> > +	if (!handle)
> > +		return ERR_PTR(-ENOMEM);
> > +	bdev = blkdev_get_by_dev(dev, mode, holder, hops);
> > +	if (IS_ERR(bdev))
> > +		return ERR_CAST(bdev);
> 
> Would we be better off with a handle->error (and a NULL return from this
> function means "we couldn't allocate a handle")?  I have no objection
> to what you've done here, just wondering if it might end up nicer for
> the users.

Hum, I've checked a couple of users and it seems it would be more
complicated for the users to handle this convention than the one I've
chosen. And that one is also pretty standard so I think by the principle of
least surprise it is also better.

								Honza

> 
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR