On Mon, Mar 27, 2023 at 02:10:52PM +0530, Anuj Gupta wrote:
> From: Nitesh Shetty
>
> For direct block device opened with O_DIRECT, use copy_file_range to
> issue device copy offload, and fallback to generic_copy_file_range incase
> device copy offload capability is absent.
> Modify checks to all
On Wed, Mar 29, 2023 at 06:12:36PM +0530, Nitesh Shetty wrote:
> On Wed, Mar 29, 2023 at 02:14:40PM +0200, Christian Brauner wrote:
> > On Mon, Mar 27, 2023 at 02:10:52PM +0530, Anuj Gupta wrote:
> > > From: Nitesh Shetty
> > >
> > > For direct bl
On Tue, Jun 06, 2023 at 09:39:19AM +0200, Christoph Hellwig wrote:
> Hi all,
>
> this series adds a new blk_mode_t for block open flags instead of abusing
Trying to look at this series applied but doesn't apply cleanly for
anything v6.4-rc* related. What tree is this on?
--
dm-devel mailing list
On Tue, Jun 06, 2023 at 09:39:36AM +0200, Christoph Hellwig wrote:
> Add a helper to return the open flags for blkdev_get_by* for passed in
> super block flags instead of open coding the logic in many places.
>
> Signed-off-by: Christoph Hellwig
> ---
Looks good to me,
Acke
On Tue, Jun 06, 2023 at 09:39:21AM +0200, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig
> ---
lgtm,
Acked-by: Christian Brauner
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
good to me,
Acked-by: Christian Brauner
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
good to me,
Acked-by: Christian Brauner
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
On Tue, Jun 06, 2023 at 09:39:37AM +0200, Christoph Hellwig wrote:
> There is no real need to store the open mode in the super_block now.
> It is only used by f2fs, which can easily recalculate it.
>
> Signed-off-by: Christoph Hellwig
> ---
Looks good to me,
Acked-by: Christian
On Tue, Jun 06, 2023 at 09:39:30AM +0200, Christoph Hellwig wrote:
> Make the function name match the method name.
>
> Signed-off-by: Christoph Hellwig
> ---
Looks good to me,
Acked-by: Christian Brauner
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mail
t; void (*release) (struct gendisk *, fmode_t);
> int (*ioctl) (struct block_device *, fmode_t, unsigned, unsigned long);
> int (*compat_ioctl) (struct block_device *, fmode_t, unsigned, unsigned
> long);
Looks good to me,
Acked-by: Christian Brauner
(I didn't bother go
gt; ---
Under the assumption it did only in fact ever only get called on the
whole device so far,
Acked-by: Christian Brauner
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
On Tue, Jun 06, 2023 at 10:40:42AM +0200, Christoph Hellwig wrote:
> On Tue, Jun 06, 2023 at 10:27:14AM +0200, Christian Brauner wrote:
> > On Tue, Jun 06, 2023 at 09:39:19AM +0200, Christoph Hellwig wrote:
> > > Hi all,
> > >
> > > this series adds a new blk
v_get_by_path calls.
>
> Signed-off-by: Christoph Hellwig
> ---
Looks good to me,
Acked-by: Christian Brauner
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
On Tue, Jun 06, 2023 at 09:39:50AM +0200, Christoph Hellwig wrote:
> FMODE_NDELAY, FMODE_EXCL and FMODE_WRITE_IOCTL were only used for
> block internal purposed and are now entirely unused, so remove them.
>
> Signed-off-by: Christoph Hellwig
> ---
Love it,
Reviewed-by: Ch
On Tue, Jun 06, 2023 at 09:39:45AM +0200, Christoph Hellwig wrote:
> All these helpers are only used in core block code, so move them out of
> the public header.
>
> Signed-off-by: Christoph Hellwig
> ---
Looks good to me,
Acked-by: Christian Brauner
--
dm-devel mailin
On Tue, Jun 06, 2023 at 09:39:27AM +0200, Christoph Hellwig wrote:
> Factor the common logic between disk_check_media_change and
> disk_force_media_change into a helper.
>
> Signed-off-by: Christoph Hellwig
> ---
Looks good to me,
Acked-by: Christian Brauner
--
dm-devel mailin
On Tue, Jun 06, 2023 at 09:39:44AM +0200, Christoph Hellwig wrote:
> This code has been dead forever, make sure it doesn't show up in code
> searches.
>
> Signed-off-by: Christoph Hellwig
> ---
Looks good to me,
Acked-by: Christian Brauner
--
dm-devel mailing list
dm-de
On Tue, Jun 06, 2023 at 09:39:47AM +0200, Christoph Hellwig wrote:
> The only overlap between the block open flags mapped into the fmode_t and
> other uses of fmode_t are FMODE_READ and FMODE_WRITE. Define a new
and FMODE_EXCL afaict
> blk_mode_t instead for use in blkdev_get_by_*, ->open and ->
>
> For blkdev_put this requires adding the holder argument, which provides
> better debug checking that only the holder actually releases the hold,
> but at the same time allows removing the now superfluous mode argument.
>
> Signed-off-by: Christoph Hellwig
> ---
Looks g
On Tue, Jun 06, 2023 at 09:39:25AM +0200, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig
> ---
Looks good to me,
Acked-by: Christian Brauner
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
> for ioctl only or NDELAY opens.
>
> Signed-off-by: Christoph Hellwig
> ---
This assumes that all drivers deal with additional ->open() calls for
each partition correctly which I assumed you checked so,
Acked-by: Christian Brauner
--
dm-devel mailing list
dm-devel@redhat.com
> ---
Feels a bit odd to store the object itself but anyway,
Acked-by: Christian Brauner
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
On Tue, Jun 06, 2023 at 09:39:29AM +0200, Christoph Hellwig wrote:
> The mode argument to the ->release block_device_operation is never used,
> so remove it.
>
> Signed-off-by: Christoph Hellwig
> ---
Good cleanup. Looks good to me,
Acked-by: Christian Brauner
--
dm-dev
good to me,
Acked-by: Christian Brauner
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
On Tue, Jun 06, 2023 at 09:39:48AM +0200, Christoph Hellwig wrote:
> Always use I_BDEV(file->f_mapping->host) to find the bdev for a file to
> free up file->private_data for other uses.
>
> Signed-off-by: Christoph Hellwig
> ---
Looks good to me,
Acked-by: Christi
On Wed, Jun 07, 2023 at 11:21:24AM +0200, Christian Brauner wrote:
> On Tue, Jun 06, 2023 at 09:39:47AM +0200, Christoph Hellwig wrote:
> > The only overlap between the block open flags mapped into the fmode_t and
> > other uses of fmode_t are FMODE_READ and FMODE_WRITE. Define
On Tue, Jun 06, 2023 at 09:39:33AM +0200, Christoph Hellwig wrote:
> Passing a holder to blkdev_get_by_path when FMODE_EXCL isn't set doesn't
> make sense, so pass NULL instead.
>
> Signed-off-by: Christoph Hellwig
> ---
Looks good to me,
Acked-by: Christian Brauner
On Tue, Jun 06, 2023 at 09:39:22AM +0200, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig
> ---
Looks good to me,
Acked-by: Christian Brauner
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
On Tue, Jun 06, 2023 at 09:39:43AM +0200, Christoph Hellwig wrote:
> Stop passing the fmode_t around and just use a simple bool to track if
> an export is read-only.
>
> Signed-off-by: Christoph Hellwig
> ---
Looks good to me,
Acked-by: Christian Brauner
--
dm-devel mailin
On Tue, Jun 06, 2023 at 09:39:42AM +0200, Christoph Hellwig wrote:
> Instead of propagating the fmode_t, just use a bool to track if a mtd
> block device was opened for writing.
>
> Signed-off-by: Christoph Hellwig
> ---
Looks good to me,
Acked-by: Christian Brauner
--
dm-dev
On Tue, Jun 06, 2023 at 09:39:23AM +0200, Christoph Hellwig wrote:
> cdrom_close_write is empty, and the for_data flag it is keyed off is
> never set. Remove all this clutter.
>
> Signed-off-by: Christoph Hellwig
> ---
Looks good to me,
Acked-by: Christian Brauner
--
dm-devel
good to me,
Acked-by: Christian Brauner
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
On Tue, Jun 06, 2023 at 09:39:46AM +0200, Christoph Hellwig wrote:
> A few ioctl handlers have fmode_t arguments that are entirely unused,
> remove them.
>
> Signed-off-by: Christoph Hellwig
> ---
Looks good to me,
Acked-by: Christian Brauner
--
dm-devel mailing list
dm-devel@r
gt; nothing but the CDROM drivers uses that argument.
>
> Signed-off-by: Christoph Hellwig
> ---
Looks good to me,
Acked-by: Christian Brauner
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
off_t lend);
> +blk_mode_t file_to_blk_mode(struct file *file);
> +int truncate_bdev_range(struct block_device *bdev, blk_mode_t mode,
> + loff_t lstart, loff_t lend);
> long blkdev_ioctl(struct file *file, unsigned cmd, unsigned long arg);
> long compat_blkdev_ioctl(struct file *file, unsigned cmd, unsigned long arg);
>
> diff --git a/block/fops.c b/block/fops.c
> index 9f26e25bafa172..086612103b9dd9 100644
> --- a/block/fops.c
> +++ b/block/fops.c
> @@ -470,6 +470,30 @@ static int blkdev_fsync(struct file *filp, loff_t start,
> loff_t end,
> return error;
> }
>
> +blk_mode_t file_to_blk_mode(struct file *file)
> +{
> + blk_mode_t mode = 0;
> +
> + if (file->f_mode & FMODE_READ)
> + mode |= BLK_OPEN_READ;
> + if (file->f_mode & FMODE_WRITE)
> + mode |= BLK_OPEN_WRITE;
> + if (file->f_mode & FMODE_EXCL)
> + mode |= BLK_OPEN_EXCL;
> + if (file->f_flags & O_NDELAY)
> + mode |= BLK_OPEN_NDELAY;
> +
> + /*
> + * If all bits in O_ACCMODE set (aka O_RDWR | O_WRONLY), the floppy
> + * driver has historically allowed ioctls as if the file was opened for
> + * writing, but does not allow and actual reads or writes.
> + */
> + if ((file->f_flags & O_ACCMODE) == (O_RDWR | O_WRONLY))
> + mode |= BLK_OPEN_WRITE_IOCTL;
Thanks for that!
Reviewed-by: Christian Brauner
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
--
Looks good to me,
Acked-by: Christian Brauner
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
On Wed, Aug 23, 2023 at 12:48:11PM +0200, Jan Kara wrote:
> Hello,
>
> this is a v3 of the patch series which implements the idea of
> blkdev_get_by_*()
> calls returning bdev_handle which is then passed to blkdev_put() [1]. This
> makes the get and put calls for bdevs more obviously matching and
> So besides my last fput() worry about I think this could work and would be
> probably a bit nicer than what I have. But before going and redoing the whole
> series let me gather some more feedback so that we don't go back and forth.
> Christoph, Christian, Jens, any opinion?
I'll be a bit under
> replacement) I think we can go ahead with the series as is. As you said
> there will be some conflicts in btrfs and I've learned about f2fs conflicts
> as well so I can rebase & repost the series on top of rc1 to make life
> easier for you.
That is be much appreciated. Thank you!
--
dm-devel ma
On Wed, Sep 06, 2023 at 06:01:06PM +0200, Mikulas Patocka wrote:
>
>
> On Wed, 6 Sep 2023, Christian Brauner wrote:
>
> > > > IOW, you'd also hang on any umount of a bind-mount. IOW, every
> > > > single container making use of this filesystems via bin
> Currently, if we freeze a filesystem with "fsfreeze" and unmount it, the
> mount point is removed, but the filesystem stays active and it is leaked.
> You can't unfreeze it with "fsfreeze --unfreeze" because the mount point
> is gone. (the only way how to recover it is "echo j>/proc/sysrq-trig
On Wed, Sep 06, 2023 at 08:22:45AM -0700, Darrick J. Wong wrote:
> On Wed, Sep 06, 2023 at 03:26:21PM +0200, Mikulas Patocka wrote:
> > lvm may suspend any logical volume anytime. If lvm suspend races with
> > unmount, it may be possible that the kernel writes to the filesystem after
> > unmount su
On Wed, Sep 06, 2023 at 03:26:21PM +0200, Mikulas Patocka wrote:
> lvm may suspend any logical volume anytime. If lvm suspend races with
> unmount, it may be possible that the kernel writes to the filesystem after
> unmount successfully returned. The problem can be demonstrated with this
> script:
On Wed, Sep 06, 2023 at 05:33:32PM +0200, Christian Brauner wrote:
> > Currently, if we freeze a filesystem with "fsfreeze" and unmount it, the
> > mount point is removed, but the filesystem stays active and it is leaked.
> > You can't unfreeze it with "
> I think we've got too deep down into "how to fix things" but I'm not 100%
We did.
> sure what the "bug" actually is. In the initial posting Mikulas writes "the
> kernel writes to the filesystem after unmount successfully returned" - is
> that really such a big issue? Anybody else can open the d
> Well, currently you click some "Eject / safely remove / whatever" button
> and then you get a "wait" dialog until everything is done after which
> you're told the stick is safe to remove. What I imagine is that the "wait"
> dialog needs to be there while there are any (or exclusive at minimum) op
> So can you please elaborate which new risks are we going to introduce by
> fixing this resource hole ?
I'm not quite sure why you need a personal summary of the various
reasons different people brought together in the thread.
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.c
> I'd say there are several options and we should aim towards the variant
> which is most usable by normal users.
None of the options is sufficiently satisfying to risk intricate
behavioral changes with unknown consequences for existing workloads as
far as I'm concerned.
--
dm-devel mailing list
On Wed, 27 Sep 2023 11:34:07 +0200, Jan Kara wrote:
> Create struct bdev_handle that contains all parameters that need to be
> passed to blkdev_put() and provide bdev_open_* functions that return
> this structure instead of plain bdev pointer. This will eventually allow
> us to pass one more argume
49 matches
Mail list logo
