All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Snitzer <snitzer@kernel.org>
To: Christoph Hellwig <hch@lst.de>, Theodore Ts'o <tytso@mit.edu>
Cc: dm-devel@lists.linux.dev, fstests@vger.kernel.org,
	linux-ext4@vger.kernel.org, regressions@lists.linux.dev,
	linux-block@vger.kernel.org
Subject: Re: dm: use queue_limits_set
Date: Mon, 20 May 2024 18:03:11 -0400	[thread overview]
Message-ID: <ZkvIn73jAqz94LjI@kernel.org> (raw)
In-Reply-To: <20240520201237.GA6235@lst.de>

On Mon, May 20, 2024 at 10:12:37PM +0200, Christoph Hellwig wrote:
> On Mon, May 20, 2024 at 01:17:46PM -0400, Mike Snitzer wrote:
> > Doubt there was anything in fstests setting max discard user limit
> > (max_user_discard_sectors) in Ted's case. blk_set_stacking_limits()
> > sets max_user_discard_sectors to UINT_MAX, so given the use of
> > min(lim->max_hw_discard_sectors, lim->max_user_discard_sectors) I
> > suspect blk_stack_limits() stacks up max_discard_sectors to match the
> > underlying storage's max_hw_discard_sectors.
> > 
> > And max_hw_discard_sectors exceeds BIO_PRISON_MAX_RANGE, resulting in
> > dm_cell_key_has_valid_range() triggering on:
> > WARN_ON_ONCE(key->block_end - key->block_begin > BIO_PRISON_MAX_RANGE)
> 
> Oh, that makes more sense.
> 
> I think you just want to set the max_hw_discard_sectors limit before
> stacking in the lower device limits so that they can only lower it.
> 
> (and in the long run we should just stop stacking the limits except
> for request based dm which really needs it)

This is what I staged, I cannot send a patch out right now.. 

Ted if you need the patch in email (rather than from linux-dm.git) I
can send it later tonight.  Please see:

https://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-6.10&id=825d8bbd2f32cb229c3b6653bd454832c3c20acb

  reply	other threads:[~2024-05-20 22:03 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-18  2:26 [REGRESSION] dm: use queue_limits_set Theodore Ts'o
2024-05-19  5:05 ` Mike Snitzer
2024-05-19  5:42   ` Mike Snitzer
2024-05-20 15:06     ` Christoph Hellwig
2024-05-20 15:39       ` Mike Snitzer
2024-05-20 15:44         ` Christoph Hellwig
2024-05-20 15:54           ` Mike Snitzer
2024-05-20 17:17             ` Mike Snitzer
2024-05-20 20:12               ` Christoph Hellwig
2024-05-20 22:03                 ` Mike Snitzer [this message]
2024-05-21  0:45                   ` Mike Snitzer
2024-05-21 15:29                     ` Mike Snitzer
2024-05-20 15:47         ` Mike Snitzer
2024-05-20 15:50           ` Christoph Hellwig

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=ZkvIn73jAqz94LjI@kernel.org \
    --to=snitzer@kernel.org \
    --cc=dm-devel@lists.linux.dev \
    --cc=fstests@vger.kernel.org \
    --cc=hch@lst.de \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=regressions@lists.linux.dev \
    --cc=tytso@mit.edu \
    /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.