Hello, Mike.
On Fri, Jul 07, 2023 at 02:37:38PM -0400, Mike Snitzer wrote:
> I certainly would like the ability to allow control over the
> workqueues using WQ_SYSFS. But with Tejun's latest WQ_UNBOUND changes
> (just merged during 6.5 merge window) I think we'd do well to audit
That part
On Mon, May 08, 2023 at 03:50:22PM -1000, Tejun Heo wrote:
...
> Signed-off-by: Tejun Heo
> Cc: Alasdair Kergon
> Cc: Mike Snitzer
> Cc: dm-devel@redhat.com
> Cc: linux-ker...@vger.kernel.org
Hey, I'm going to apply this to wq/for-6.5-cleanup-ordered. As it's an
iden
ays
reconsider later.
As there are follow-up workqueue core changes, I'd really appreciate if the
patch can be routed through the workqueue tree w/ your acks. Thanks.
Signed-off-by: Tejun Heo
Cc: Alasdair Kergon
Cc: Mike Snitzer
Cc: dm-devel@redhat.com
Cc: linux-ker...@vger.kernel.or
ays
reconsider later.
As there are follow-up workqueue core changes, I'd really appreciate if the
patch can be routed through the workqueue tree w/ your acks. Thanks.
Signed-off-by: Tejun Heo
Cc: Alasdair Kergon
Cc: Mike Snitzer
Cc: dm-devel@redhat.com
Cc: linux-ker...@vger.kernel.or
On Thu, Dec 03, 2020 at 05:21:39PM +0100, Christoph Hellwig wrote:
> The request_queue can trivially be derived from the request.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Damien Le Moal
> Reviewed-by: Hannes Reinecke
Acked-by: Tejun Heo
Thanks!
--
tejun
--
d
On Thu, Dec 03, 2020 at 05:21:38PM +0100, Christoph Hellwig wrote:
> The request_queue can trivially be derived from the bio.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Damien Le Moal
> Reviewed-by: Hannes Reinecke
Acked-by: Tejun Heo
--
tejun
--
dm-devel mailin
On Thu, Dec 03, 2020 at 05:21:37PM +0100, Christoph Hellwig wrote:
> The request_queue can trivially be derived from the bio.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Damien Le Moal
> Reviewed-by: Hannes Reinecke
Acked-by: Tejun Heo
--
tejun
--
dm-devel mailin
by: Damien Le Moal
> Reviewed-by: Hannes Reinecke
Acked-by: Tejun Heo
Thanks.
--
tejun
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
y: Hannes Reinecke
Acked-by: Tejun Heo
Thanks.
--
tejun
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
On Thu, Dec 03, 2020 at 09:25:59AM +0100, Christoph Hellwig wrote:
> Whom can I trick into reviewing this fairly simple series now that
> the one dependig on it got fully reviewed?
Care to resend? I'd be happy to take a look later today.
Thanks.
--
tejun
--
dm-devel mailing list
On Tue, Dec 01, 2020 at 05:54:24PM +0100, Christoph Hellwig wrote:
> Now that no fast path lookups in the partition table are left, there is
> no point in micro-optimizing the data structure for it. Just use a bog
> standard xarray.
>
> Signed-off-by: Christoph Hellwig
Acke
order. Can't find any explicit
explanation why it was that way. The reverse iteration there goes back to
the initial git import. But yeah, I can't think of any meaningful difference
which can come out of it.
Acked-by: Tejun Heo
Thanks.
--
tejun
--
dm-devel mailing list
dm-devel@redh
On Tue, Dec 01, 2020 at 05:54:22PM +0100, Christoph Hellwig wrote:
> Add a helper to call kobject_uevent for the disk and all partitions, and
> unexport the disk_part_iter_* helpers that are now only used in the core
> block code.
>
> Signed-off-by: Christoph Hellwig
Acke
On Tue, Dec 01, 2020 at 05:54:21PM +0100, Christoph Hellwig wrote:
> Remove the reverse map from a sector to a partition for I/O accounting by
> simply using ->bi_bdev.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Tejun Heo
--
tejun
--
dm-devel mailing list
dm-devel@r
end I/O account either bio_end_io_acct can be used if the driver never
> remaps I/O to a different device, or bio_end_io_acct_remapped if the
> driver did remap the I/O.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Tejun Heo
--
tejun
--
dm-devel mailing list
dm-devel@redhat
On Tue, Dec 01, 2020 at 05:54:19PM +0100, Christoph Hellwig wrote:
> Merge a few checks for whole devices vs partitions to streamline the
> sanity checks.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Tejun Heo
--
tejun
--
dm-devel mailing list
dm-devel@redhat.com
https://ww
look up all information related to partition remapping.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Tejun Heo
Thanks.
--
tejun
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
On Tue, Dec 01, 2020 at 05:54:17PM +0100, Christoph Hellwig wrote:
> The block layer already checks for this conditions in bio_check_eod
> before calling the driver.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Tejun Heo
Thanks.
--
tejun
--
dm-devel mailing list
dm-devel@redh
On Tue, Dec 01, 2020 at 05:54:16PM +0100, Christoph Hellwig wrote:
> The block layer already checks for this conditions in bio_check_eod
> before calling the driver.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Tejun Heo
Thanks.
--
tejun
--
dm-devel mailing list
dm-devel@redh
On Wed, Dec 02, 2020 at 05:35:21PM -0500, Tejun Heo wrote:
> On Tue, Dec 01, 2020 at 05:54:15PM +0100, Christoph Hellwig wrote:
> > Hi Jens,
> >
> > this series switches back from storing the gendisk + partno to storing
> > a block_device pointer in struct bio. The r
On Tue, Dec 01, 2020 at 05:54:15PM +0100, Christoph Hellwig wrote:
> Hi Jens,
>
> this series switches back from storing the gendisk + partno to storing
> a block_device pointer in struct bio. The reason is two fold: for one
> the new struct block_device actually is always available, removing
On Sat, Nov 28, 2020 at 05:14:50PM +0100, Christoph Hellwig wrote:
> To simplify block device lookup and a few other upcoming areas, make sure
> that we always have a struct block_device available for each disk and
> each partition, and only find existing block devices in bdget. The only
>
Hello,
On Wed, Nov 25, 2020 at 05:45:15PM +0100, Christoph Hellwig wrote:
> On Tue, Nov 24, 2020 at 04:18:49PM -0500, Tejun Heo wrote:
> > Hello,
> >
> > Please see lkml.kernel.org/r/x708btj5njtbc...@mtj.duckdns.org for a few nits
> > on the previous version.
Hello,
On Wed, Nov 25, 2020 at 05:29:26PM +0100, Christoph Hellwig wrote:
> > I was wondering whether losing the stale bdev flushing in bd_acquire() would
> > cause user-visible behavior changes but can't see how it would given that
> > userland has no way of holding onto a specific instance of
Hey, Jan,
On Wed, Nov 25, 2020 at 12:40:44PM +0100, Jan Kara wrote:
> > I don't think this is necessary now that the bdev and inode lifetimes are
> > one. Before, punching out the association early was necessary because we
> > could be in a situation where we can successfully look up a part from
On Tue, Nov 24, 2020 at 02:27:35PM +0100, Christoph Hellwig wrote:
> Don't play tricks with slab constructors as bdev structures tends to not
> get reused very much, and this makes the code a lot less error prone.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Tejun Heo
--
tejun
On Tue, Nov 24, 2020 at 02:27:34PM +0100, Christoph Hellwig wrote:
> Now that struct hd_struct has a block_device pointer use that to
> find the disk.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Tejun Heo
--
tejun
--
dm-devel mailing list
dm-devel@redhat.com
https://ww
iewed-by: Jan Kara
Acked-by: Tejun Heo
--
tejun
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
;
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Greg Kroah-Hartman
> Reviewed-by: Jan Kara
Acked-by: Tejun Heo
--
tejun
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
Hello,
Please see lkml.kernel.org/r/x708btj5njtbc...@mtj.duckdns.org for a few nits
on the previous version.
On Tue, Nov 24, 2020 at 02:27:31PM +0100, Christoph Hellwig wrote:
> To simplify block device lookup and a few other upcoming areas, make sure
> that we always have a struct block_device
On Tue, Nov 24, 2020 at 02:27:30PM +0100, Christoph Hellwig wrote:
> Properly open the device instead of relying on deep internals by
> using get_gendisk. Note that this uses FMODE_NDELAY without either
> FMODE_READ or FMODE_WRITE, which is a special open mode to allow
> for opening without media
ev, filp->f_mode, filp);
> + return 0;
> }
I was wondering whether losing the stale bdev flushing in bd_acquire() would
cause user-visible behavior changes but can't see how it would given that
userland has no way of holding onto a specific instance of block inode.
Maybe it's somet
On Tue, Nov 24, 2020 at 02:27:28PM +0100, Christoph Hellwig wrote:
> Just call devcgroup_check_permission to avoid various superflous checks
> and a double conversion of the access flags.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Tejun Heo
--
tejun
--
dm-devel mailing l
ows to simplify the disk and module refcounting so that one
> reference is held for each open, similar to what we do with normal
> file operations.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Tejun Heo
Thanks.
--
tejun
--
dm-devel mailing list
dm-devel@redhat.com
https://www.red
On Tue, Nov 24, 2020 at 02:27:26PM +0100, Christoph Hellwig wrote:
> Reorder the code to have one big section for the last close, and to use
> bdev_is_partition.
>
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Greg Kroah-Hartman
> Reviewed-by: Jan Kara
Acked-by: Tej
y: Johannes Thumshirn
Acked-by: Tejun Heo
--
tejun
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
: Jan Kara
Acked-by: Tejun Heo
--
tejun
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
f-by: Christoph Hellwig
> Reviewed-by: Greg Kroah-Hartman
> Reviewed-by: Jan Kara
> Reviewed-by: Johannes Thumshirn
Acked-by: Tejun Heo
--
tejun
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
y: Johannes Thumshirn
Acked-by: Tejun Heo
--
tejun
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
Greg Kroah-Hartman
> Reviewed-by: Jan Kara
Acked-by: Tejun Heo
--
tejun
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
On Tue, Nov 24, 2020 at 02:27:20PM +0100, Christoph Hellwig wrote:
> Call disk_part_iter_exit in disk_part_iter_next instead of duplicating
> the functionality.
Acked-by: Tejun Heo
--
tejun
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
On Tue, Nov 24, 2020 at 02:27:19PM +0100, Christoph Hellwig wrote:
> Add a little helper to find the kobject for a struct block_device.
Acked-by: Tejun Heo
--
tejun
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
On Tue, Nov 24, 2020 at 02:27:17PM +0100, Christoph Hellwig wrote:
> Signed-off-by: Christoph Hellwig
> Reviewed-by: Greg Kroah-Hartman
> Reviewed-by: Jan Kara
> Reviewed-by: Johannes Thumshirn
Acked-by: Tejun Heo
--
tejun
--
dm-devel mailing list
dm-devel@redh
On Tue, Nov 24, 2020 at 02:27:18PM +0100, Christoph Hellwig wrote:
> sector_t is now always a u64, so this check is not needed.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Tejun Heo
--
tejun
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
Hello,
This is great. So much simpler & better. Some nits below.
> diff --git a/block/partitions/core.c b/block/partitions/core.c
> index a02e224115943d..0ba0bf44b88af3 100644
> --- a/block/partitions/core.c
> +++ b/block/partitions/core.c
> @@ -340,12 +340,11 @@ void delete_partition(struct
On Wed, Nov 18, 2020 at 09:47:41AM +0100, Christoph Hellwig wrote:
> disk_get_part needs to be paired with a disk_put_part.
>
> Fixes: ef45fe470e1 ("blk-cgroup: show global disk stats in root cgroup
> io.stat")
> Signed-off-by: Christoph Hellwig
Acked-by: Tejun Heo
On Wed, Jul 01, 2020 at 11:06:18AM +0200, Christoph Hellwig wrote:
> Hi Jens,
>
> we have a lot of bdi congestion related code that is left around without
> any use. This series removes it in preparation of sorting out the bdi
> lifetime rules properly.
Acked-by: Tejun Heo
whole series looks great to me.
Acked-by: Tejun Heo
Thanks.
--
tejun
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
aktipriya Shridhar <bhaktipriy...@gmail.com>
Acked-by: Tejun Heo <t...@kernel.org>
Thanks.
--
tejun
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
Hello,
On Thu, Feb 25, 2016 at 09:53:14AM -0500, Mike Snitzer wrote:
> Right, LVM created devices are bio-based DM devices in the kernel.
> bio-based block devices do _not_ have an IO scheduler. Their underlying
> request-based device does.
dm devices are not the actual resource source, so I
50 matches
Mail list logo