From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from embla.dev.snart.me (embla.dev.snart.me [54.252.183.203]) (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 DC10529D291 for ; Sun, 22 Mar 2026 11:52:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=54.252.183.203 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774180376; cv=none; b=Ai95qvUCGNe9KlGcCP1676+6WxNNnd63XHVOWaFmgS1946x+AD/q+3hLtwnG8TSh5m4ikSlfrxEcadnLmyt9LdvpDluzOdVS6YkNC+tZ4cNgCols1lnmS97r7bFBzL92lt7WI3YxLoKrnfY2YymgngJaC3teda2Wi+G9krKAuOg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774180376; c=relaxed/simple; bh=1E3HfYa8iMGkUZuWOFOC1KJPQqzZxTGSgO5Ie3S1TmM=; h=Message-ID:Date:MIME-Version:From:Subject:To:Cc:References: In-Reply-To:Content-Type; b=VgIh/tJkuyQSXxD9T2u6UmmhqlYLndc7FEOyh2M7YYxj/J/Wl7nnNaoFforPnkjUewC625pdFwjqmZazZrIA/2gF2xzg3bbCmhZvnI7NIUQiscNtxNoajqiTBjKBbYXG2uQisFXJ5t+7djghj96PE7Agsl0Metp35tuPrHdZEq4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=dev.snart.me; spf=pass smtp.mailfrom=dev.snart.me; dkim=pass (1024-bit key) header.d=dev.snart.me header.i=@dev.snart.me header.b=w/6ImI+/; arc=none smtp.client-ip=54.252.183.203 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=dev.snart.me Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=dev.snart.me Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=dev.snart.me header.i=@dev.snart.me header.b="w/6ImI+/" Received: from embla.dev.snart.me (localhost [IPv6:::1]) by embla.dev.snart.me (Postfix) with ESMTP id 0424D1D490; Sun, 22 Mar 2026 11:52:52 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 embla.dev.snart.me 0424D1D490 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dev.snart.me; s=00; t=1774180373; bh=1E3HfYa8iMGkUZuWOFOC1KJPQqzZxTGSgO5Ie3S1TmM=; h=Date:From:Subject:To:Cc:References:In-Reply-To:From; b=w/6ImI+/SW09agMqqbjgLhsKEgI0nM7+LlbkQhYSdUEa0ioXe2wNoKP4AePo0pltg EcwgDvHRMA8vNdm6++uDRF3+SkQJ6XeuHzCZ9hteGIFPFskw9OHvimOdV4PYm0NkNx mn+sRNkUoYEYAybXdO8XvXW/52oG6EAHK21kla80= Received: from [192.168.1.18] ([182.226.25.243]) by embla.dev.snart.me with ESMTPSA id DKI8KxTYv2nuvggA8KYfjw (envelope-from ); Sun, 22 Mar 2026 11:52:52 +0000 Message-ID: <559131c2-99da-4f3f-9243-0d027de398f8@dev.snart.me> Date: Sun, 22 Mar 2026 20:52:51 +0900 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: David Timber Subject: Re: [PATCH] drivers/char/mem.c: fix null and zero dev lseek To: Greg KH Cc: arnd@arndb.de, linux-kernel@vger.kernel.org References: <20260320041722.196759-1-dxdt@dev.snart.me> <2026032005-porcupine-nursery-9611@gregkh> Content-Language: en-US, ko Autocrypt: addr=dxdt@dev.snart.me; keydata= xjMEYmJg1hYJKwYBBAHaRw8BAQdAf5E+ri1XLtjqYbZdHOyc8oS+1/XJ5bSlbx5WHXmVBZzN IERhdmlkIFRpbWJlciA8ZHhkdEBkZXYuc25hcnQubWU+wpQEExYKADwWIQQn/Jn96EMUaIoF X+T/ldyyrZpWaAUCYmJg1gIbAwULCQgHAgMiAgEGFQoJCAsCBBYCAwECHgcCF4AACgkQ/5Xc sq2aVmjJZwD8COjPlUwccrlRvbNQ6f87DWchtYO0o8W2DNRM3RLps0EA/jEhIbRV6AsyC8jr 30Ut3aJ3/mO/6G4sLj7OvkEEBH0MzjgEYmJg1hIKKwYBBAGXVQEFAQEHQFpgtIgaByv9lIEY EmpavMO0pYjtu7TMJynwdnGYkN9LAwEIB8J4BBgWCgAgFiEEJ/yZ/ehDFGiKBV/k/5Xcsq2a VmgFAmJiYNYCGwwACgkQ/5Xcsq2aVmhFCwEA0kM9VyYB4bLCM7+SuXUUH+5Ec99Nj4RXxFad Key9GuwA/2BZK6bNyrLSfEk2JDRoskqf7OIL0wa6JOD5SrBnMe8E In-Reply-To: <2026032005-porcupine-nursery-9611@gregkh> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit (resending due to mail format error) On 3/20/26 15:02, Greg KH wrote: > On Fri, Mar 20, 2026 at 01:17:22PM +0900, David Timber wrote: >> lseek() on /dev/null and /dev/zero always returns 0. This is >> problematic for userland programs that detect holes and advancing >> the offset by the delta (SEEK_HOLE - SEEK_DATA), which will always be >> calculated as zero. > But it's always worked this way, what changed to require this to now > change? No, it has not. This time, it's Linux who's at fault. For any other whence the fs does not understand, it should return EINVAL. We can all agree that this is bad because prooly written userspace code could go unnoticed just because it's tested against /dev/null. > What userspace tools are you going to break by doing this? It will break poorly written userspace tools that call lseek() with a wrong value or corrupted stack. I cannot give you the exact data, but in my opinion, there's none. Yes, we don't break userspace, but in this case, there wouldn't be any userspace to break. > Where does POSIX require this to happen for these device nodes? It is inferred from the fact that the offsets to SEEK_DATA and SEEK_HOLE cannot be the same. Ever. This is why whence needs to be checked, regardless of how the particular special device node or VFS behaves. I don't know about the other device node types, but /dev/null is a special case because its common use case is symlinking to mask regular files. Say there's a unsuspecting script or userspace program that applies the logic of dig_holes() without doing lstat() or [ -f "$FILE" ]. The userspace open()'s the path, the dereferenced path happens to be /dev/null. The poor userspace steps into the loop and loops indefinitely. > You just changed how userspace reacts to this, are you SURE that is > going to be ok? As far as I'm concerned, yes /I/ am sure. As outlined above, the start of a hole and data cannot be the same. I've check the behaviour of /dev/null on BSD's(the descendants of the 386BSD codebase) and Unices. All of the ones I've checked checks the validity of whence(i.e. EINVAL is returned). It is in my opinion that Linux fix this incorrect behaviour before SEEK_DATA and SEEK_HOLE(made POSIX in 2024 spec) become widespread and the userspace implementations depending on this broken behaviour start to appear. At the end of the day, even if Linux decides to remain as that black sheep, userspace can always cater to the peculiar of Linux as always. Your call. > And if you really want to do this, shouldn't you > explicitly list what options you are going to return an error for, not > the other way around in this switch statement? Sure. See rerolled. Davo