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 1644732BF42 for ; Sun, 22 Mar 2026 13:20:37 +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=1774185639; cv=none; b=osslz9fthKheZk1Np6q9qNgVyJXg5ksR9eO3ND4Equ5cZXYoohc3xGeemxtXEfT7kaL2mC9ALNyxSXriLDsMPlebambgA4DdrwFuXiYiFi/GGYNh/oJfaaSCILAfZu/pGiFM35jWkl7g2mbnZd1/P7dFVkuJ57CMwS1NFq/pFeI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774185639; c=relaxed/simple; bh=0yUMWXqof7yr3CwsGeu49CaY3CFBmwrY/GPPy6vycoI=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=DmsQjIToGed2Ka2F66BGEYPA2FOHDrpqAmlNHljrBqiHCz0bPSbadqfjVWipsA+818p1GpIaJLvhM0wT3/o+JeIcBN5XQLnyMwFzZTVDE9rw6BjiIZVdPZ7BBt2TAZtOlgOkhroI82WYirRRrHh752Bb+j+5YeQcra4FC4dYr3w= 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=pYOU1crD; 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="pYOU1crD" Received: from embla.dev.snart.me (localhost [IPv6:::1]) by embla.dev.snart.me (Postfix) with ESMTP id 0D3C21D490; Sun, 22 Mar 2026 13:20:35 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 embla.dev.snart.me 0D3C21D490 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dev.snart.me; s=00; t=1774185636; bh=0yUMWXqof7yr3CwsGeu49CaY3CFBmwrY/GPPy6vycoI=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From; b=pYOU1crD72t7xqMGV77W2GxyNknABBAStZisCmWqJ1T0HJW55MEcD6wiA70SEWSCg GFFOnNEXDA4kucQZTNNVsMxtg0JXiPvcHl756aTBCfQlmMYZTifVmOsbpgBnPAjN4b zQZ8FBzu2yN45gwKWeKspQ/0JV9MkqY4WeeL/uH4= Received: from [192.168.1.18] ([182.226.25.243]) by embla.dev.snart.me with ESMTPSA id 0FQDK6Psv2m7xAgA8KYfjw (envelope-from ); Sun, 22 Mar 2026 13:20:35 +0000 Message-ID: Date: Sun, 22 Mar 2026 22:20:34 +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 Subject: Re: [PATCH] drivers/char/mem.c: fix null and zero dev lseek From: David Timber 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> <559131c2-99da-4f3f-9243-0d027de398f8@dev.snart.me> 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: <559131c2-99da-4f3f-9243-0d027de398f8@dev.snart.me> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 3/22/26 20:52, David Timber wrote: >> 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. >> 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. On the second thought, one possible scenario where the offsets to hole and data being the same would be a TOCTOU condition where a hole has been dug in between lseek() calls. Either way, that means the file is being manipulated by multiple processes so in fallocate's case, it might as well just terminate prematurely to be on the safe side. btw, I don't maintain util-linux, so I'd just like to mention that it's up to the maintainers to decide. In addition to that, other sparse-aware userspace tools like compression filter, tar, and rsync always lstat() before doing anything "sparse". The kernel returning EINVAL is more for extereme edge cases like fallocate(to prevent such programs from shooting themselves in the foot). >> 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. I just removed the confusing comments and made the function use one return statement. We could do other errnos as per POSIX spec, but to be honest, EINVAL should suffice. I get the gist of where you were getting at - /dev/null isn't really the scope of POSIX so technically Linux could do whatever. I wouldn't complicate things. It's a simple dev node. So keep the code simple? Davo