Re: [PATCH v2 0/29] block: Make blkdev_get_by_*() return handle

Christoph Hellwig <[email protected]>
Newsgroups gmane.linux.kernel.drbd.devel,gmane.linux.kernel.device-mapper.devel,gmane.linux.scsi.target.devel,gmane.linux.drivers.mtd,gmane.comp.file-systems.nilfs.user,gmane.linux.scsi,gmane.comp.emulators.xen.devel,gmane.linux.power-management.general,gmane.comp.file-systems.reiserfs.general,gmane.linux.block,gmane.linux.kernel.bcache.devel,gmane.linux.raid,gmane.linux.nfs,gmane.comp.file-systems.ext4,gmane.linux.kernel.mm,gmane.linux.file-systems.f2fs,gmane.comp.file-systems.ocfs2.devel,gmane.linux.file-systems,gmane.comp.file-systems.btrfs
Message-ID <[email protected]>
On Sat, Aug 26, 2023 at 03:28:52AM +0100, Al Viro wrote:
> I mean, look at claim_swapfile() for example:
>                 p->bdev = blkdev_get_by_dev(inode->i_rdev,
>                                    FMODE_READ | FMODE_WRITE | FMODE_EXCL, p);
>                 if (IS_ERR(p->bdev)) {
>                         error = PTR_ERR(p->bdev);
>                         p->bdev = NULL;
>                         return error;
>                 }
>                 p->old_block_size = block_size(p->bdev);
>                 error = set_blocksize(p->bdev, PAGE_SIZE);
>                 if (error < 0)
>                         return error;
> we already have the file opened, and we keep it opened all the way until
> the swapoff(2); here we have noticed that it's a block device and we
> 	* open the fucker again (by device number), this time claiming
> it with our swap_info_struct as holder, to be closed at swapoff(2) time
> (just before we close the file)

Note that some drivers look at FMODE_EXCL/BLK_OPEN_EXCL in ->open.
These are probably bogus and maybe we want to kill them, but that will
need an audit first.

> BTW, what happens if two threads call ioctl(fd, BLKBSZSET, &n)
> for the same descriptor that happens to have been opened O_EXCL?
> Without O_EXCL they would've been unable to claim the sucker at the same
> time - the holder we are using is the address of a function argument,
> i.e. something that points to kernel stack of the caller.  Those would
> conflict and we either get set_blocksize() calls fully serialized, or
> one of the callers would eat -EBUSY.  Not so in "opened with O_EXCL"
> case - they can very well overlap and IIRC set_blocksize() does *not*
> expect that kind of crap...  It's all under CAP_SYS_ADMIN, so it's not
> as if it was a meaningful security hole anyway, but it does look fishy.

The user get to keep the pieces..  BLKBSZSET is kinda bogus anyway
as the soft blocksize only matters for buffer_head-like I/O, and
there only for file systems.  Not idea why anyone would set it manually.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.