Received: by 2002:ab2:6816:0:b0:1f9:5764:f03e with SMTP id t22csp2684220lqo; Mon, 20 May 2024 13:12:53 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCWGDtckG9iO4HatvNNbgcrNwkTO4po/Gk88xPjCITOx4RXmNspFHEL3KJEfAB+hi0psKox0XQ1F4bLMd2Q4w6+IPjKIabKhtlAb9VZAJg== X-Google-Smtp-Source: AGHT+IFa02AHMUQ7fYnupXhSTXW07A8ezhkzKYWcJxzyYp1zlVkIsZzCbU+0hZagTe5M5CuaApyE X-Received: by 2002:a05:6214:138e:b0:6ab:7067:6f6c with SMTP id 6a1803df08f44-6ab70677b0fmr9986066d6.52.1716235973051; Mon, 20 May 2024 13:12:53 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1716235973; cv=pass; d=google.com; s=arc-20160816; b=JEsGnaKpDzgLD/carHI472Tq+8OSRl5JVB7/7WSGibwnJ78s5DXWi2pU3rAwOXdRjq LDFIucwiYYkKqz9aXZdGvlUpm2yBH9kCNgHDPTmqkJCDtdVpr+xIkU+FrRs2tmroNxMi 7aiTSWjsRqy5k9/A4aPJpkoeZ5ArEovRvTNNF1ktw2JVddo5UYhf+faanGU/RlZHFx17 4t+mGdQ67XvJMchgTXn+bxIn9FpaPKO9x3mv54mrkqdHDgjtUSffa37cS8fkQoCmQDIJ 6ZvMsf+Dxc9FFPjN3KAkk9gozE9O6UJFDunmpqQSNo/1wJnZgW/qlqPRgAAUUHFET5bK hjHg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version :list-unsubscribe:list-subscribe:list-id:precedence:references :message-id:subject:cc:to:from:date; bh=GlZwvH8SikVW1KoEWsLf+g2bcAjK4kWzFYbjR2ASwiA=; fh=vDwh9eUywtCNfeEB0rWNrxt0d7b2eCCILtNFIUdFvC8=; b=wwrfVGYEm4zNLtJiVlNY2wyTn0cuC++IKpujxaJ4mpEBTwOVbRSsjPrAIbvLY4Zn7D mrD50DFeqWH8avdGukKmsLJb4ezmyAiGH6AGm8hBiN30CkFb2AEjtpM3SzO1tzoZyF5s M9BM5U77XrqY+mf2N/KnKuurXXWBcrngZUu6g4JlNVbO/zaeaX9JvkCuVhOF7Tsi6Y0o VneJPOohjwq+TmznebR9L1z0KSiXdes5oyrKt0TRH1wtpIl1lfZaJmN6L0Dkf29MbLSr 9Fo6SlB4vOlGgecMuYWBZd5/XpYYw4+K7ctKnZcBdfJEbmKxQbULQevQr4QFYTQPVgLQ CbTQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=lst.de); spf=pass (google.com: domain of linux-ext4+bounces-2612-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-ext4+bounces-2612-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [147.75.199.223]) by mx.google.com with ESMTPS id d75a77b69052e-43e393577ffsi122707321cf.525.2024.05.20.13.12.52 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 May 2024 13:12:53 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-ext4+bounces-2612-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=lst.de); spf=pass (google.com: domain of linux-ext4+bounces-2612-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) smtp.mailfrom="linux-ext4+bounces-2612-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id C22121C210F5 for ; Mon, 20 May 2024 20:12:52 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 7C5A31386D6; Mon, 20 May 2024 20:12:44 +0000 (UTC) X-Original-To: linux-ext4@vger.kernel.org Received: from verein.lst.de (verein.lst.de [213.95.11.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 12548138497; Mon, 20 May 2024 20:12:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.95.11.211 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716235964; cv=none; b=B+l+xEORNRsugkpQEWc1V1bijhnLl6ldxvHTKgfNZo7+aeV+zm3ZcaNg9eivtGi0fm7xfrx4+sWXOOkizgTAJ39Ux2Jr8haHuE7t8jOh5TGi/xDW1HBVfZyjvgZ3fkwIYfyy3sDwenZRIRQLEDTX3eG/RPruB/2SQY6EHuuHAm4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716235964; c=relaxed/simple; bh=j6UZ3hL6JZ0QfhbLrz2gBFof0KSATisW8jSnUWUDDvU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=sGU2B91VZU5ERyulFTrT/JQu6buc44vSRnVULIOTdpLGYG6QzA7KpRmcGhDZQl1JsVHZSeBUok3rJbzDaORjEKyiFlq8pDMsISj+5MHDu/Gx4AGECQwzZyoVCfAfXf7olymEbbI6Kn0ePJZ5tQpYd9ilpXgyeu2t7MABFpg7yIY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de; spf=pass smtp.mailfrom=lst.de; arc=none smtp.client-ip=213.95.11.211 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=lst.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=lst.de Received: by verein.lst.de (Postfix, from userid 2407) id F41A268AFE; Mon, 20 May 2024 22:12:37 +0200 (CEST) Date: Mon, 20 May 2024 22:12:37 +0200 From: Christoph Hellwig To: Mike Snitzer Cc: Christoph Hellwig , Theodore Ts'o , 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 Message-ID: <20240520201237.GA6235@lst.de> References: <20240518022646.GA450709@mit.edu> <20240520150653.GA32461@lst.de> <20240520154425.GB1104@lst.de> Precedence: bulk X-Mailing-List: linux-ext4@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) 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)