From mboxrd@z Thu Jan 1 00:00:00 1970 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 C6EA52459D0; Wed, 12 Mar 2025 13:59:18 +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=1741787960; cv=none; b=FwjSiHcnvri1dwa/ddxJaH8V2B0VvUxMMxfhhEBTK5pxPlOGRWxX5ZdVirp/yOzemgAdfvUWVqHhHotFLKo+4DvJgZ8NPZRzZ3C4YQ5g0TGga+RJkwUrLg1juNRDzqVyw7Q/U7UueoK/SX3uA5yBG4SZDG32guQ1OCe6dQQmJ7E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741787960; c=relaxed/simple; bh=I+ZggbW2AQWliXHPSHrqQCZgq7RM16Z511PBjh6KULs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LnwfkDrkWjJFDOJI5V1uDaobKXxARQPF+LdkyXqbxaBJbW/xZNJWYCs/IukPU3APxrDpar4xG25bbw4QsjEKo/n1otUonWsUHqwrd2Eeaa+S9gn8yUqdpaJ7shgm8KKPQ62SBIQ5NzInHYfwwncdwsorJlx+vcPORfv9nxSg//s= 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 EF23C68BFE; Wed, 12 Mar 2025 14:59:12 +0100 (CET) Date: Wed, 12 Mar 2025 14:59:12 +0100 From: Christoph Hellwig To: Li Wang Cc: Luis Chamberlain , Christoph Hellwig , brauner@kernel.org, hare@suse.de, willy@infradead.org, david@fromorbit.com, djwong@kernel.org, kbusch@kernel.org, john.g.garry@oracle.com, ritesh.list@gmail.com, linux-fsdevel@vger.kernel.org, linux-block@vger.kernel.org, ltp@lists.linux.it, lkp@intel.com, oliver.sang@intel.com, oe-lkp@lists.linux.dev, gost.dev@samsung.com, p.raghav@samsung.com, da.gomez@samsung.com, kernel@pankajraghav.com Subject: Re: [PATCH] block: add BLK_FEAT_LBS to check for PAGE_SIZE limit Message-ID: <20250312135912.GB12488@lst.de> References: <20250312050028.1784117-1-mcgrof@kernel.org> <20250312052155.GA11864@lst.de> <20250312054053.GA12234@lst.de> Precedence: bulk X-Mailing-List: linux-block@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 Wed, Mar 12, 2025 at 05:19:36PM +0800, Li Wang wrote: > Well, does that patch for ioctl_loop06 still make sense? > Or any other workaround? > https://lists.linux.it/pipermail/ltp/2025-March/042599.html The real question is what block sizes we want to support for the loop driver. Because if it is larger than the physical block size it can lead to torn writes. But I guess no one cared about those on loop so far, so why care about this now.. But if we don't want any limit on the block size that patch looks right. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from picard.linux.it (picard.linux.it [213.254.12.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 89467C28B2F for ; Wed, 12 Mar 2025 13:59:35 +0000 (UTC) Received: from picard.linux.it (localhost [IPv6:::1]) by picard.linux.it (Postfix) with ESMTP id 5B3A33CA46E for ; Wed, 12 Mar 2025 14:59:33 +0100 (CET) Received: from in-3.smtp.seeweb.it (in-3.smtp.seeweb.it [IPv6:2001:4b78:1:20::3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1)) (No client certificate requested) by picard.linux.it (Postfix) with ESMTPS id 464483CA2DB for ; Wed, 12 Mar 2025 14:59:18 +0100 (CET) Authentication-Results: in-3.smtp.seeweb.it; spf=pass (sender SPF authorized) smtp.mailfrom=lst.de (client-ip=213.95.11.211; helo=verein.lst.de; envelope-from=hch@lst.de; receiver=lists.linux.it) Received: from verein.lst.de (verein.lst.de [213.95.11.211]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by in-3.smtp.seeweb.it (Postfix) with ESMTPS id 345DE1A004A4 for ; Wed, 12 Mar 2025 14:59:16 +0100 (CET) Received: by verein.lst.de (Postfix, from userid 2407) id EF23C68BFE; Wed, 12 Mar 2025 14:59:12 +0100 (CET) Date: Wed, 12 Mar 2025 14:59:12 +0100 From: Christoph Hellwig To: Li Wang Message-ID: <20250312135912.GB12488@lst.de> References: <20250312050028.1784117-1-mcgrof@kernel.org> <20250312052155.GA11864@lst.de> <20250312054053.GA12234@lst.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: clamav-milter 1.0.3 at in-3.smtp.seeweb.it X-Virus-Status: Clean Subject: Re: [LTP] [PATCH] block: add BLK_FEAT_LBS to check for PAGE_SIZE limit X-BeenThere: ltp@lists.linux.it X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux Test Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: p.raghav@samsung.com, ritesh.list@gmail.com, brauner@kernel.org, lkp@intel.com, john.g.garry@oracle.com, da.gomez@samsung.com, djwong@kernel.org, david@fromorbit.com, oe-lkp@lists.linux.dev, willy@infradead.org, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, Luis Chamberlain , oliver.sang@intel.com, hare@suse.de, gost.dev@samsung.com, kbusch@kernel.org, kernel@pankajraghav.com, Christoph Hellwig , ltp@lists.linux.it Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ltp-bounces+ltp=archiver.kernel.org@lists.linux.it Sender: "ltp" On Wed, Mar 12, 2025 at 05:19:36PM +0800, Li Wang wrote: > Well, does that patch for ioctl_loop06 still make sense? > Or any other workaround? > https://lists.linux.it/pipermail/ltp/2025-March/042599.html The real question is what block sizes we want to support for the loop driver. Because if it is larger than the physical block size it can lead to torn writes. But I guess no one cared about those on loop so far, so why care about this now.. But if we don't want any limit on the block size that patch looks right. -- Mailing list info: https://lists.linux.it/listinfo/ltp