From: Christoph Hellwig <hch@lst.de>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Vignesh Raghavendra <vigneshr@ti.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
linux-nvme@lists.infradead.org,
Phillip Potter <phil@philpotter.co.uk>, Chris Mason <clm@fb.com>,
dm-devel@redhat.com, "Md. Haris Iqbal" <haris.iqbal@ionos.com>,
Pavel Machek <pavel@ucw.cz>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Jack Wang <jinpu.wang@ionos.com>, Christoph Hellwig <hch@lst.de>,
linux-nilfs@vger.kernel.org, linux-scsi@vger.kernel.org,
Richard Weinberger <richard@nod.at>,
linux-pm@vger.kernel.org, linux-um@lists.infradead.org,
Josef Bacik <josef@toxicpanda.com>, Coly Li <colyli@suse.de>,
linux-block@vger.kernel.org, linux-bcache@vger.kernel.org,
David Sterba <dsterba@suse.com>, Jens Axboe <axboe@kernel.dk>,
Christian Brauner <brauner@kernel.org>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
linux-f2fs-devel@lists.sourceforge.net,
linux-fsdevel@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-btrfs@vger.kernel.org
Subject: Re: [dm-devel] [PATCH 01/30] block: also call ->open for incremental partition opens
Date: Mon, 28 Aug 2023 14:09:40 +0200 [thread overview]
Message-ID: <20230828120940.GB10552@lst.de> (raw)
In-Reply-To: <20230825024457.GD95084@ZenIV>
On Fri, Aug 25, 2023 at 03:44:57AM +0100, Al Viro wrote:
> That got me curious about the ->bd_openers - do we need it atomic?
> Most of the users (and all places that do modifications) are
> under ->open_mutex; the only exceptions are
> * early sync logics in blkdev_put(); it's explicitly racy -
> see the comment there.
> * callers of disk_openers() in loop and nbd (the ones in
> zram are under ->open_mutex). There's driver-private exclusion
> around those, but in any case - READ_ONCE() is no worse than
> atomic_read() in those cases.
>
> Is there something subtle I'm missing here?
No. When I had to add unlocked readers I did the READ_ONCE initially,
but reviewers though the atomic_t would be better. I didn't really feel
like arguing so went with this version.
--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
Richard Weinberger <richard@nod.at>,
Josef Bacik <josef@toxicpanda.com>,
"Md. Haris Iqbal" <haris.iqbal@ionos.com>,
Jack Wang <jinpu.wang@ionos.com>,
Phillip Potter <phil@philpotter.co.uk>, Coly Li <colyli@suse.de>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Vignesh Raghavendra <vigneshr@ti.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Chris Mason <clm@fb.com>, David Sterba <dsterba@suse.com>,
Christian Brauner <brauner@kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Pavel Machek <pavel@ucw.cz>,
dm-devel@redhat.com, linux-block@vger.kernel.org,
linux-um@lists.infradead.org, linux-scsi@vger.kernel.org,
linux-bcache@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-nvme@lists.infradead.org, linux-btrfs@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-nilfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-pm@vger.kernel.org, Hannes Reinecke <hare@suse.de>
Subject: Re: [PATCH 01/30] block: also call ->open for incremental partition opens
Date: Mon, 28 Aug 2023 14:09:40 +0200 [thread overview]
Message-ID: <20230828120940.GB10552@lst.de> (raw)
In-Reply-To: <20230825024457.GD95084@ZenIV>
On Fri, Aug 25, 2023 at 03:44:57AM +0100, Al Viro wrote:
> That got me curious about the ->bd_openers - do we need it atomic?
> Most of the users (and all places that do modifications) are
> under ->open_mutex; the only exceptions are
> * early sync logics in blkdev_put(); it's explicitly racy -
> see the comment there.
> * callers of disk_openers() in loop and nbd (the ones in
> zram are under ->open_mutex). There's driver-private exclusion
> around those, but in any case - READ_ONCE() is no worse than
> atomic_read() in those cases.
>
> Is there something subtle I'm missing here?
No. When I had to add unlocked readers I did the READ_ONCE initially,
but reviewers though the atomic_t would be better. I didn't really feel
like arguing so went with this version.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Vignesh Raghavendra <vigneshr@ti.com>,
"Rafael J. Wysocki" <rafael@kernel.org>,
linux-nvme@lists.infradead.org,
Phillip Potter <phil@philpotter.co.uk>, Chris Mason <clm@fb.com>,
dm-devel@redhat.com, "Md. Haris Iqbal" <haris.iqbal@ionos.com>,
Pavel Machek <pavel@ucw.cz>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Jack Wang <jinpu.wang@ionos.com>, Christoph Hellwig <hch@lst.de>,
linux-nilfs@vger.kernel.org, linux-scsi@vger.kernel.org,
Richard Weinberger <richard@nod.at>,
linux-pm@vger.kernel.org, linux-um@lists.infradead.org,
Josef Bacik <josef@toxicpanda.com>, Coly Li <colyli@suse.de>,
linux-block@vger.kernel.org, linux-bcache@vger.kernel.org,
Hannes Reinecke <hare@suse.de>, David Sterba <dsterba@suse.com>,
Jens Axboe <axboe@kernel.dk>,
Christian Brauner <brauner@kernel.org>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
linux-f2fs-devel@lists.sourceforge.net,
linux-fsdevel@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-btrfs@vger.kernel.org
Subject: Re: [f2fs-dev] [PATCH 01/30] block: also call ->open for incremental partition opens
Date: Mon, 28 Aug 2023 14:09:40 +0200 [thread overview]
Message-ID: <20230828120940.GB10552@lst.de> (raw)
In-Reply-To: <20230825024457.GD95084@ZenIV>
On Fri, Aug 25, 2023 at 03:44:57AM +0100, Al Viro wrote:
> That got me curious about the ->bd_openers - do we need it atomic?
> Most of the users (and all places that do modifications) are
> under ->open_mutex; the only exceptions are
> * early sync logics in blkdev_put(); it's explicitly racy -
> see the comment there.
> * callers of disk_openers() in loop and nbd (the ones in
> zram are under ->open_mutex). There's driver-private exclusion
> around those, but in any case - READ_ONCE() is no worse than
> atomic_read() in those cases.
>
> Is there something subtle I'm missing here?
No. When I had to add unlocked readers I did the READ_ONCE initially,
but reviewers though the atomic_t would be better. I didn't really feel
like arguing so went with this version.
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
Richard Weinberger <richard@nod.at>,
Josef Bacik <josef@toxicpanda.com>,
"Md. Haris Iqbal" <haris.iqbal@ionos.com>,
Jack Wang <jinpu.wang@ionos.com>,
Phillip Potter <phil@philpotter.co.uk>, Coly Li <colyli@suse.de>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Vignesh Raghavendra <vigneshr@ti.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Chris Mason <clm@fb.com>, David Sterba <dsterba@suse.com>,
Christian Brauner <brauner@kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Pavel Machek <pavel@ucw.cz>,
dm-devel@redhat.com, linux-block@vger.kernel.org,
linux-um@lists.infradead.org, linux-scsi@vger.kernel.org,
linux-bcache@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-nvme@lists.infradead.org, linux-btrfs@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-nilfs@vger.kernel.org
Subject: Re: [PATCH 01/30] block: also call ->open for incremental partition opens
Date: Mon, 28 Aug 2023 14:09:40 +0200 [thread overview]
Message-ID: <20230828120940.GB10552@lst.de> (raw)
In-Reply-To: <20230825024457.GD95084@ZenIV>
On Fri, Aug 25, 2023 at 03:44:57AM +0100, Al Viro wrote:
> That got me curious about the ->bd_openers - do we need it atomic?
> Most of the users (and all places that do modifications) are
> under ->open_mutex; the only exceptions are
> * early sync logics in blkdev_put(); it's explicitly racy -
> see the comment there.
> * callers of disk_openers() in loop and nbd (the ones in
> zram are under ->open_mutex). There's driver-private exclusion
> around those, but in any case - READ_ONCE() is no worse than
> atomic_read() in those cases.
>
> Is there something subtle I'm missing here?
No. When I had to add unlocked readers I did the READ_ONCE initially,
but reviewers though the atomic_t would be better. I didn't really feel
like arguing so went with this version.
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
Richard Weinberger <richard@nod.at>,
Josef Bacik <josef@toxicpanda.com>,
"Md. Haris Iqbal" <haris.iqbal@ionos.com>,
Jack Wang <jinpu.wang@ionos.com>,
Phillip Potter <phil@philpotter.co.uk>, Coly Li <colyli@suse.de>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Vignesh Raghavendra <vigneshr@ti.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Chris Mason <clm@fb.com>, David Sterba <dsterba@suse.com>,
Christian Brauner <brauner@kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Pavel Machek <pavel@ucw.cz>,
dm-devel@redhat.com, linux-block@vger.kernel.org,
linux-um@lists.infradead.org, linux-scsi@vger.kernel.org,
linux-bcache@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-nvme@lists.infradead.org, linux-btrfs@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-nilfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-pm@vger.kernel.org, Hannes Reinecke <hare@suse.de>
Subject: Re: [PATCH 01/30] block: also call ->open for incremental partition opens
Date: Mon, 28 Aug 2023 14:09:40 +0200 [thread overview]
Message-ID: <20230828120940.GB10552@lst.de> (raw)
In-Reply-To: <20230825024457.GD95084@ZenIV>
On Fri, Aug 25, 2023 at 03:44:57AM +0100, Al Viro wrote:
> That got me curious about the ->bd_openers - do we need it atomic?
> Most of the users (and all places that do modifications) are
> under ->open_mutex; the only exceptions are
> * early sync logics in blkdev_put(); it's explicitly racy -
> see the comment there.
> * callers of disk_openers() in loop and nbd (the ones in
> zram are under ->open_mutex). There's driver-private exclusion
> around those, but in any case - READ_ONCE() is no worse than
> atomic_read() in those cases.
>
> Is there something subtle I'm missing here?
No. When I had to add unlocked readers I did the READ_ONCE initially,
but reviewers though the atomic_t would be better. I didn't really feel
like arguing so went with this version.
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Christoph Hellwig <hch@lst.de>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>, Jens Axboe <axboe@kernel.dk>,
Richard Weinberger <richard@nod.at>,
Josef Bacik <josef@toxicpanda.com>,
"Md. Haris Iqbal" <haris.iqbal@ionos.com>,
Jack Wang <jinpu.wang@ionos.com>,
Phillip Potter <phil@philpotter.co.uk>, Coly Li <colyli@suse.de>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Vignesh Raghavendra <vigneshr@ti.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Chris Mason <clm@fb.com>, David Sterba <dsterba@suse.com>,
Christian Brauner <brauner@kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Pavel Machek <pavel@ucw.cz>,
dm-devel@redhat.com, linux-block@vger.kernel.org,
linux-um@lists.infradead.org, linux-scsi@vger.kernel.org,
linux-bcache@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-nvme@lists.infradead.org, linux-btrfs@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net,
linux-nilfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-pm@vger.kernel.org, Hannes Reinecke <hare@suse.de>
Subject: Re: [PATCH 01/30] block: also call ->open for incremental partition opens
Date: Mon, 28 Aug 2023 14:09:40 +0200 [thread overview]
Message-ID: <20230828120940.GB10552@lst.de> (raw)
In-Reply-To: <20230825024457.GD95084@ZenIV>
On Fri, Aug 25, 2023 at 03:44:57AM +0100, Al Viro wrote:
> That got me curious about the ->bd_openers - do we need it atomic?
> Most of the users (and all places that do modifications) are
> under ->open_mutex; the only exceptions are
> * early sync logics in blkdev_put(); it's explicitly racy -
> see the comment there.
> * callers of disk_openers() in loop and nbd (the ones in
> zram are under ->open_mutex). There's driver-private exclusion
> around those, but in any case - READ_ONCE() is no worse than
> atomic_read() in those cases.
>
> Is there something subtle I'm missing here?
No. When I had to add unlocked readers I did the READ_ONCE initially,
but reviewers though the atomic_t would be better. I didn't really feel
like arguing so went with this version.
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
next prev parent reply other threads:[~2023-08-28 12:10 UTC|newest]
Thread overview: 247+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-08 11:02 [dm-devel] decouple block open flags from fmode_t v2 Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [f2fs-dev] " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [dm-devel] [PATCH 01/30] block: also call ->open for incremental partition opens Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [f2fs-dev] " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-07-06 0:18 ` [dm-devel] [f2fs-dev] " patchwork-bot+f2fs
2023-07-06 0:18 ` patchwork-bot+f2fs
2023-07-06 0:18 ` patchwork-bot+f2fs
2023-07-06 0:18 ` patchwork-bot+f2fs-DgEjT+Ai2ygdnm+yROfE0A
2023-07-06 0:18 ` patchwork-bot+f2fs
2023-07-06 0:18 ` patchwork-bot+f2fs
2023-08-25 2:44 ` [dm-devel] " Al Viro
2023-08-25 2:44 ` Al Viro
2023-08-25 2:44 ` Al Viro
2023-08-25 2:44 ` Al Viro
2023-08-25 2:44 ` [f2fs-dev] " Al Viro
2023-08-25 2:44 ` Al Viro
2023-08-28 12:09 ` Christoph Hellwig [this message]
2023-08-28 12:09 ` Christoph Hellwig
2023-08-28 12:09 ` Christoph Hellwig
2023-08-28 12:09 ` Christoph Hellwig
2023-08-28 12:09 ` [f2fs-dev] " Christoph Hellwig
2023-08-28 12:09 ` Christoph Hellwig
2023-06-08 11:02 ` [dm-devel] [PATCH 02/30] cdrom: remove the unused bdev argument to cdrom_open Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [f2fs-dev] " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [dm-devel] [PATCH 03/30] cdrom: remove the unused mode argument to cdrom_ioctl Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [f2fs-dev] " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [dm-devel] [PATCH 04/30] cdrom: remove the unused cdrom_close_write release code Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [f2fs-dev] " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [dm-devel] [PATCH 05/30] cdrom: track if a cdrom_device_info was opened for data Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [f2fs-dev] " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-09 6:37 ` [dm-devel] " Hannes Reinecke
2023-06-09 6:37 ` Hannes Reinecke
2023-06-09 6:37 ` Hannes Reinecke
2023-06-09 6:37 ` Hannes Reinecke
2023-06-09 6:37 ` [f2fs-dev] " Hannes Reinecke
2023-06-09 6:37 ` Hannes Reinecke
2023-06-08 11:02 ` [dm-devel] [PATCH 06/30] cdrom: remove the unused mode argument to cdrom_release Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [f2fs-dev] " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [dm-devel] [PATCH 07/30] block: pass a gendisk on bdev_check_media_change Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [f2fs-dev] " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [dm-devel] [PATCH 08/30] block: pass a gendisk to ->open Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [f2fs-dev] " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [dm-devel] [PATCH 09/30] block: remove the unused mode argument to ->release Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [f2fs-dev] " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [dm-devel] [PATCH 10/30] block: rename blkdev_close to blkdev_release Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [f2fs-dev] " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [dm-devel] [PATCH 11/30] swsusp: don't pass a stack address to blkdev_get_by_path Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [f2fs-dev] " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-09 18:13 ` [dm-devel] " Rafael J. Wysocki
2023-06-09 18:13 ` Rafael J. Wysocki
2023-06-09 18:13 ` Rafael J. Wysocki
2023-06-09 18:13 ` Rafael J. Wysocki
2023-06-09 18:13 ` [f2fs-dev] " Rafael J. Wysocki
2023-06-09 18:13 ` Rafael J. Wysocki
2023-06-08 11:02 ` [dm-devel] [PATCH 12/30] bcache: " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [f2fs-dev] " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [dm-devel] [PATCH 13/30] rnbd-srv: don't pass a holder for non-exclusive blkdev_get_by_path Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [f2fs-dev] " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [dm-devel] [PATCH 14/30] btrfs: " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [f2fs-dev] " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [dm-devel] [PATCH 15/30] block: use the holder as indication for exclusive opens Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [f2fs-dev] " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [dm-devel] [PATCH 16/30] block: add a sb_open_mode helper Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [f2fs-dev] " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [dm-devel] [PATCH 17/30] fs: remove sb->s_mode Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [f2fs-dev] " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [dm-devel] [PATCH 18/30] scsi: replace the fmode_t argument to scsi_cmd_allowed with a simple bool Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [f2fs-dev] " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [dm-devel] [PATCH 19/30] scsi: replace the fmode_t argument to scsi_ioctl " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [f2fs-dev] " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [dm-devel] [PATCH 20/30] scsi: replace the fmode_t argument to ->sg_io_fn " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [f2fs-dev] " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [dm-devel] [PATCH 21/30] nvme: replace the fmode_t argument to the nvme ioctl handlers " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [f2fs-dev] " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-09 15:49 ` [dm-devel] " Keith Busch
2023-06-09 15:49 ` Keith Busch
2023-06-09 15:49 ` Keith Busch
2023-06-09 15:49 ` Keith Busch
2023-06-09 15:49 ` [f2fs-dev] " Keith Busch
2023-06-09 15:49 ` Keith Busch
2023-06-08 11:02 ` [dm-devel] [PATCH 22/30] mtd: block: use a simple bool to track open for write Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [f2fs-dev] " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [dm-devel] [PATCH 23/30] rnbd-srv: replace sess->open_flags with a "bool readonly" Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [f2fs-dev] " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [dm-devel] [PATCH 24/30] ubd: remove commented out code in ubd_open Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [f2fs-dev] " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [dm-devel] [PATCH 25/30] block: move a few internal definitions out of blkdev.h Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [f2fs-dev] " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [dm-devel] [PATCH 26/30] block: remove unused fmode_t arguments from ioctl handlers Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [f2fs-dev] " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [dm-devel] [PATCH 27/30] block: replace fmode_t with a block-specific type for block open flags Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [f2fs-dev] " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:45 ` [dm-devel] " Christian Brauner
2023-06-08 11:45 ` Christian Brauner
2023-06-08 11:45 ` Christian Brauner
2023-06-08 11:45 ` Christian Brauner
2023-06-08 11:45 ` [f2fs-dev] " Christian Brauner
2023-06-08 11:45 ` Christian Brauner
2023-06-09 6:39 ` [dm-devel] " Hannes Reinecke
2023-06-09 6:40 ` Hannes Reinecke
2023-06-09 6:40 ` Hannes Reinecke
2023-06-09 6:40 ` Hannes Reinecke
2023-06-09 6:40 ` Hannes Reinecke
2023-06-09 6:40 ` [f2fs-dev] " Hannes Reinecke
2023-06-09 6:40 ` Hannes Reinecke
2023-06-08 11:02 ` [dm-devel] [PATCH 28/30] block: always use I_BDEV on file->f_mapping->host to find the bdev Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [f2fs-dev] " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [dm-devel] [PATCH 29/30] block: store the holder in file->private_data Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [f2fs-dev] " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-09 6:41 ` [dm-devel] " Hannes Reinecke
2023-06-09 6:41 ` Hannes Reinecke
2023-06-09 6:41 ` Hannes Reinecke
2023-06-09 6:41 ` Hannes Reinecke
2023-06-09 6:41 ` [f2fs-dev] " Hannes Reinecke
2023-06-09 6:41 ` Hannes Reinecke
2023-06-08 11:02 ` [dm-devel] [PATCH 30/30] fs: remove the now unused FMODE_* flags Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-08 11:02 ` [f2fs-dev] " Christoph Hellwig
2023-06-08 11:02 ` Christoph Hellwig
2023-06-12 14:11 ` [dm-devel] decouple block open flags from fmode_t v2 Jens Axboe
2023-06-12 14:11 ` Jens Axboe
2023-06-12 14:11 ` Jens Axboe
2023-06-12 14:11 ` Jens Axboe
2023-06-12 14:11 ` [f2fs-dev] " Jens Axboe
2023-06-12 14:11 ` Jens Axboe
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=20230828120940.GB10552@lst.de \
--to=hch@lst.de \
--cc=axboe@kernel.dk \
--cc=brauner@kernel.org \
--cc=clm@fb.com \
--cc=colyli@suse.de \
--cc=dm-devel@redhat.com \
--cc=dsterba@suse.com \
--cc=haris.iqbal@ionos.com \
--cc=jinpu.wang@ionos.com \
--cc=josef@toxicpanda.com \
--cc=linux-bcache@vger.kernel.org \
--cc=linux-block@vger.kernel.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-nilfs@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linux-um@lists.infradead.org \
--cc=martin.petersen@oracle.com \
--cc=miquel.raynal@bootlin.com \
--cc=pavel@ucw.cz \
--cc=phil@philpotter.co.uk \
--cc=rafael@kernel.org \
--cc=richard@nod.at \
--cc=vigneshr@ti.com \
--cc=viro@zeniv.linux.org.uk \
/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.