All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Jan Kara <jack@suse.cz>
Cc: Christoph Hellwig <hch@infradead.org>,
	Jens Axboe <axboe@kernel.dk>,
	linux-block@vger.kernel.org, Dmitry Vyukov <dvyukov@google.com>,
	Ted Tso <tytso@mit.edu>, yebin <yebin@huaweicloud.com>,
	linux-fsdevel@vger.kernel.org, Kees Cook <keescook@google.com>,
	Alexander Popov <alex.popov@linux.com>,
	Eric Biggers <ebiggers@google.com>
Subject: Re: [PATCH] block: Add config option to not allow writing to mounted devices
Date: Tue, 20 Jun 2023 04:29:53 -0700	[thread overview]
Message-ID: <ZJGNsVDhZx0Xgs2H@infradead.org> (raw)
In-Reply-To: <20230620104111.pnjoouegp2dx6pcp@quack3>

On Tue, Jun 20, 2023 at 12:41:11PM +0200, Jan Kara wrote:
> I can see several solutions but since you've just reworked the code and I'm
> not 100% certain about the motivation, I figured I'll ask you first before
> spending significant time on something you won't like:
> 
> 1) Just return the mode argument to blkdev_put().
> 
> 2) Only pass to blkdev_put() whether we have write access or not as a
> separate argument.
> 
> 3) Don't track number of opens for writing, instead check whether writes
> are blocked on each write access. I think this has a number of downsides
> but I mention it for completeness. One problem is we have to add checks to
> multiple places (buffered IO, direct IO) and existing mmap in particular
> will be very hard to deal with (need to add page_mkwrite() handler). All
> these checks add performance overhead. It is practically impossible
> (without significant performance overhead or new percpu datastructures) to
> properly synchronize open that wants to block writers against already
> running writes.

I think 3 is out for the reasons you mention.  2 feels a bit ugly,
but so does 1 given that we only really need the write flag.  One thing
I through about earlier but decided was overkill at that time is to
return a cookie from blkdev_get_* that needs to be passed back to
blkdev_put.  That could either be opaque to the caller, or replace the
bdev ala:

struct bdev_handle {
	struct block_device *bdev;
	void *holder;
	bool for_write;
};

Given that fixups we needed to pass the right holder back in, it feels
like that would be the least error prone API, even if it is a fair
amount of churn.


  reply	other threads:[~2023-06-20 11:29 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-12 16:16 [PATCH] block: Add config option to not allow writing to mounted devices Jan Kara
2023-06-12 16:25 ` Jan Kara
2023-06-12 17:39   ` Bart Van Assche
2023-06-12 17:47     ` Theodore Ts'o
2023-06-12 18:52     ` Colin Walters
2023-06-13 11:34       ` Jan Kara
2023-06-14  1:55         ` Darrick J. Wong
2023-06-14  7:14           ` Christoph Hellwig
2023-06-14  7:05         ` Christian Brauner
2023-06-14  7:07           ` Christoph Hellwig
2023-06-14  7:10         ` Christoph Hellwig
2023-06-14 10:12           ` Jan Kara
2023-06-14 14:30             ` Christoph Hellwig
2023-06-14 14:46             ` Matthew Wilcox
2023-06-13  4:56 ` kernel test robot
2023-06-13  5:10 ` Christoph Hellwig
2023-06-13  6:09   ` Dmitry Vyukov
2023-06-14  7:17     ` Christoph Hellwig
2023-06-14  8:18       ` Christian Brauner
2023-06-14 10:36         ` Jan Kara
2023-06-14 12:48           ` Christian Brauner
2023-06-15 14:39             ` Jan Kara
2023-06-14 14:31         ` Christoph Hellwig
2023-06-13 20:56   ` Jan Kara
2023-06-14  7:20     ` Christoph Hellwig
2023-06-20 10:41       ` Jan Kara
2023-06-20 11:29         ` Christoph Hellwig [this message]
2023-06-14  7:35     ` Christian Brauner
2023-06-13  6:49 ` Dmitry Vyukov
2023-06-13 19:22   ` Theodore Ts'o
2023-06-14  0:26   ` Dave Chinner
2023-06-14  2:04   ` Darrick J. Wong
2023-06-14  2:57     ` Theodore Ts'o
2023-06-14 12:27     ` Dmitry Vyukov
2023-06-14 23:38       ` Dave Chinner
2023-06-15  9:14         ` Dmitry Vyukov
2023-06-18 23:35           ` Dave Chinner

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=ZJGNsVDhZx0Xgs2H@infradead.org \
    --to=hch@infradead.org \
    --cc=alex.popov@linux.com \
    --cc=axboe@kernel.dk \
    --cc=dvyukov@google.com \
    --cc=ebiggers@google.com \
    --cc=jack@suse.cz \
    --cc=keescook@google.com \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=tytso@mit.edu \
    --cc=yebin@huaweicloud.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.