From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kara Subject: Re: [PATCH 01/32] block: Provide blkdev_get_handle_* functions Date: Tue, 4 Jul 2023 15:03:56 +0200 Message-ID: <20230704130356.xwdlxvgvi4l6sruc@quack3> References: <20230629165206.383-1-jack@suse.cz> <20230704122224.16257-1-jack@suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1688475837; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=rY6MxLY5e9SVa1+4BCCd7ntNwV9Px5uEGT5nvi2Xw9M=; b=ejRwbAIwZQbMrOxksN9aG/ZDDESpKoHA5R/d85WHYyhF32Si43PFRfl6mcCR9WYB3Qv5Xb bFzVFYQ3692eypLdUzJN5qIXY9S2kweTJplS9sF53SAyJ7HvtNyhlweUs2wFtrS+zKSTOj TegqbmWrWk4Vs0DZGSAEKRmheCwdTpE= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1688475837; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=rY6MxLY5e9SVa1+4BCCd7ntNwV9Px5uEGT5nvi2Xw9M=; b=T7VmytPRSDJUviPwV6lejrGCKn7KjlWBXNR5Weqcyul/51HqsbD9tiSRFlJo/bbQX+dGnV 08LOGAmrpvM1ddAQ== Content-Disposition: inline In-Reply-To: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: drbd-dev-bounces-cunTk1MwBs8qoQakbn7OcQ@public.gmane.org Errors-To: drbd-dev-bounces-cunTk1MwBs8qoQakbn7OcQ@public.gmane.org To: Matthew Wilcox Cc: Dave Kleikamp , jfs-discussion-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org, Jan Kara , "Darrick J. Wong" , linux-nvme-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Joseph Qi , dm-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, target-devel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Jack Wang , Alasdair Kergon , drbd-dev-cunTk1MwBs8qoQakbn7OcQ@public.gmane.org, linux-s390-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-scsi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Sergey Senozhatsky , Christoph Hellwig , xen-devel-GuqFBffKawtpuQazS67q72D2FQJk+8+b@public.gmane.org, Gao Xiang , Christian Borntraeger , Kent Overstreet , Sven Schnelle , linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Mike Snitzer , Chao Yu , Joern Engel , re 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 SUSE Labs, CR