From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E90AA3769FD for ; Thu, 21 May 2026 09:17:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779355051; cv=none; b=sGMdmNKce2c1FwvtS2Rl4r/PtML/KKqK0H4ryvbMnUSZ9LjzGm3X023Tb+Yr7Y0tQd1jIM1vsIPuH8uIZzrfd4VTmLk/Ungmk8p2zv3tbJXNk3xJUj1Amirj+UnV71WkX84HtE6eV8/LoKAVZ8paewrwEF/aAsMXoexnuHTcv8U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779355051; c=relaxed/simple; bh=cTV6KZ/1JoTdkUE4/yXHzPrvXTvrzpKHCSCuJvrjN/g=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=f0bcOWeK8c3lQ765JL9tvmmT/PHoVx0DaQWRonuL5EASEcQjjfqyCfGy66raDwJ9wY0kZwAKFZLBJmgox8xBds9bT1RYXJLC8JpOMwZ0y4fSKacvV93JQXpie8r1LmwGpU4qE+Q91GkrNQ+zZhV5/tsnV5GrgQBYLCuIw1yQ4gE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=l0Z6Fkph; arc=none smtp.client-ip=209.85.128.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="l0Z6Fkph" Received: by mail-wm1-f45.google.com with SMTP id 5b1f17b1804b1-48e6db3ff7eso30268285e9.0 for ; Thu, 21 May 2026 02:17:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779355039; x=1779959839; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=WLFRyz/pQr7d26L5ScuODNohLQeaWaPTqLQEGYdho9w=; b=l0Z6FkphivWF3GiKvr7jH+FplSzHIb81/nMc0t8SlSHJix+FdQppvv891IeECWaDR8 4P56QGuNqGFGwL8WORty+1Vd0Hjg9L53OEHWj9VzcYiXDzCxMudRaZvOGhCcc+QKjU60 tjAtYs4S9zEuIHjCE7Ky0mmz2b8OxdKG2F/m8v1MBC3MgFvGSvD2L+Yh/p94ZBtC4HIC R6bDj0q+wYrqnrd2LH05n8B2PlceN5bnpu55t/GD4o5tqg2ZJaw5s5wChRqb+Msz/rJW txpF7YCMPlgTwPw/qstsYEsVWjXr5AqDlLqCYNZ8QUGNjnvkcvMvwdFpYUV84sw4OAxc mFHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779355039; x=1779959839; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=WLFRyz/pQr7d26L5ScuODNohLQeaWaPTqLQEGYdho9w=; b=AJMCq3HIolAgcyX46sLB9buHyhX2a0+4F3YfjJb+pp6/43dEQif7IcE/FE8uU41FoY RsKKjj0kdn8wgn+p2IRmxJcoRO6M2gEBHbjp/n6Snw7PBlusjIFPB+dMRZd2OqIDYZPQ vhUc7z+T1u93ZJRD8LMxuUGP9YGBc006aIGAY3qTzrt9bfefUZK3VCddixwQCIkyRIIh X2m/kdtRcK+LwmmTEwf6aYZ6ADgamenw5ftQTEweEUrLAZFWiRaO8qe361mSDcZztZ/2 JRcVi/+gFsS2RyVWXCxynu3kGrtDNIy0cJMgCeieoPvXLTGIYG0YcmSdNyIlR8RpgoHJ T40A== X-Forwarded-Encrypted: i=1; AFNElJ983HrR0yf6J9/3TjvnsTvyEeNxvC0qC+CLdmfnAzLZPVxMzzZOsjNcWVYSmuCESKxPQ9453EHaCpCl0Ug=@vger.kernel.org X-Gm-Message-State: AOJu0YxjpzH+oC6K9jSBqcc2jD2XTRGtkY0ose+MJkoTyHxgFv3P+ZjV 8/vD2l4Dk0v41i2J/yJvmx6fsvv6nEs3EbYUMlKGXC7AN60u2Un6gXRW X-Gm-Gg: Acq92OFKUz94zo6tmpGmV/vB3Jv23lgyMexgRqivYt2t7jBUW5W6R0Rwkyub2TLwFBP Jize/MbtNgLM5JgUWz47UafFTk/nTg7POsQlZHcSjcAZ1EzwfJxkaprY3SbcWxqYAGiZ5e9E3dE UBDkvTWwVcRXC6Ry1go5SozUuqoLim9558MxrooF24S2X34n76JP9LxZmLoRtGkEAyjLEzfInZF QWCnJ5FYNYIVEdpDimDvRKZfuDfirYEsoO3z/dod7b7jPRu6iwMWZMssKmRwrf0WYk5Y7phSqfc akPqLn87FZTDSVIvG3y++16lEh9IXeNCqR8ihQ7PfCaET3y1suIudAkd/OZytw+SJrlbkHe/M04 K3EO1oUPzuzG4ip6luSKshcf15TqOn4qbQts/rzddRyB0/Vy577IDni3ah/f6oXiRE5J8Uci43N 30oITUskuwkAFTgTlIsfkkX0bTnEoZJq5UW+o57LmSL3f0LPWXoH2P/EcQpjLWC1ib+C7rRSkVl y0= X-Received: by 2002:a05:600c:37c4:b0:489:1f08:91b with SMTP id 5b1f17b1804b1-490360a87a0mr30144575e9.16.1779355038541; Thu, 21 May 2026 02:17:18 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45eaa9366besm1539255f8f.31.2026.05.21.02.17.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 May 2026 02:17:18 -0700 (PDT) Date: Thu, 21 May 2026 10:17:16 +0100 From: David Laight To: Greg Kroah-Hartman Cc: driver-core@lists.linux.dev, linux-kernel@vger.kernel.org, "Rafael J. Wysocki" , Danilo Krummrich , NeilBrown , Tejun Heo Subject: Re: [PATCH] sysfs: clamp show() return value in sysfs_kf_read() Message-ID: <20260521101716.6e460242@pumpkin> In-Reply-To: <2026052148-glamorous-hassle-2cc8@gregkh> References: <2026052000-drove-unicycle-d61b@gregkh> <20260520231158.407ebf0b@pumpkin> <2026052148-glamorous-hassle-2cc8@gregkh> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 21 May 2026 08:19:16 +0200 Greg Kroah-Hartman wrote: > On Wed, May 20, 2026 at 11:11:58PM +0100, David Laight wrote: > > On Wed, 20 May 2026 15:07:01 +0200 > > Greg Kroah-Hartman wrote: > > > > > sysfs_kf_seq_show() defends against buggy show() callbacks that return > > > larger than PAGE_SIZE by clamping the value and printing a warning. > > > sysfs_kf_read(), the prealloc variant, has no such defense. > > > > > > The only current in-tree user of __ATTR_PREALLOC is drivers/md/md.c, > > > whose show() callbacks are well-behaved, so this is hardening against > > > future drivers doing foolish things and out-of-tree code doing even more > > > foolish things. > > > > What is the rational for it using PREALLOC? > > No idea, you might want to dig to find the commit that did this. This one: commit 750f199ee8b578062341e6ddfe36c59ac8ff2dcb Author: NeilBrown Date: Tue Sep 30 08:53:05 2014 +1000 md: mark some attributes as pre-alloc Since __ATTR_PREALLOC was introduced in v3.19-rc1~78^2~18 it can now be used by md. This ensure that writing to these sysfs attributes will never block due to a memory allocation. Such blocking could become a deadlock if mdmon is trying to reconfigure an array after a failure prior to re-enabling writes. That might be better handled with a flag that changes the kmalloc() to NOIO and falls back onto a global preallocated page in the normal path. It would certainly let a lot of code be deleted (always good). The atomic_write_len would then just be a max_write_len (and maybe renamed). The only real use is the 'cgroup' code that wants to support writes that are larger than 4k. Currently, if atomic_write_len is zero writes are truncated to PAGE_SIZE, if non-zero overlong writes are rejected. AFAICT the file offset is never checked - so all writes are (sort of) appends. I'm not at all sure that makes sense. Possibly all overlong writes should be rejected. -- David > > thanks, > > greg k-h