From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 B692F3CB2E5; Fri, 13 Mar 2026 16:55:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773420922; cv=none; b=SPHT9lAvr3gn/x22fbGN/pqmVURW6C1oP3ZMdn092rNsgFnUn72Tj/8NHElVtIyFFgL0P1DIUrWCr6RJ9rOn0EP6bK+0FTEGZLKdxjW1OJKpWaQBlS878lW0cnf79ax/1fLlQ8KlfML0My9dhyZw+kWwu1yqCotwQxXAN+yYtPk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773420922; c=relaxed/simple; bh=baiNm/cmPS4XXblwmiJyoB/1uw5qigLq+GeTLGJPF7g=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=qtAeb0qyOqUUFKMoc1Sv9n3tyBczgloq5Y0aZRL/UhgaK7yaewgdk0diJmajr10vbhBBuJcENlsolC+U2IB89qpyWnNMrQRoduwVm+eJIBnXxcyhIurgHc6WCaJJsChY0P/Subv29bkqGS5tDQGYs4jUp299lcAsTeFl0cJxrIM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lyKdwyFg; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lyKdwyFg" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1494BC4AF09; Fri, 13 Mar 2026 16:55:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773420922; bh=baiNm/cmPS4XXblwmiJyoB/1uw5qigLq+GeTLGJPF7g=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lyKdwyFgZEkFhnwl3H84TQ4TiHRtNBGHnSUJpL+bbrRRWnxxGT/cpfpx+rsVvWHnh ZJGDMxgAiyTJCuaTfVvPPdAVuamT2rutLRxRFI5VjwTyEJ2daklBGS2TLbfeUb2kPD pp0VuJ3NZ1vSBWpHfuCNBRtvljh0T+i5av/c/wa+VTgOcQsDvkyyqRLmVcuSiOr+pa nZbLuBH5yY8g4nhVcHZtDHYxhDb90Ou0/9vdx5fbcAl61v0k3nyon+xHtYJx8Ag51n rxBDa4kvpAzMj9C5LjILB2EAczgYxXc9CdvtJ5NrJmKatW3/9v6GITgI44Fc/RQt4f uos80lV7v5jrw== Date: Fri, 13 Mar 2026 12:55:20 -0400 From: Sasha Levin To: Greg Kroah-Hartman Cc: linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-kselftest@vger.kernel.org, workflows@vger.kernel.org, tools@kernel.org, x86@kernel.org, Thomas Gleixner , "Paul E. McKenney" , Jonathan Corbet , Dmitry Vyukov , Randy Dunlap , Cyril Hrubis , Kees Cook , Jake Edge , David Laight , Askar Safin , Gabriele Paoloni , Mauro Carvalho Chehab , Christian Brauner , Alexander Viro , Andrew Morton , Masahiro Yamada , Shuah Khan , Ingo Molnar , Arnd Bergmann Subject: Re: [PATCH 6/9] kernel/api: add API specification for sys_close Message-ID: References: <20260313150928.2637368-1-sashal@kernel.org> <20260313150928.2637368-7-sashal@kernel.org> <2026031321-steadfast-fang-ba42@gregkh> 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; format=flowed Content-Disposition: inline In-Reply-To: <2026031321-steadfast-fang-ba42@gregkh> On Fri, Mar 13, 2026 at 04:52:30PM +0100, Greg Kroah-Hartman wrote: >On Fri, Mar 13, 2026 at 11:09:16AM -0400, Sasha Levin wrote: >> + * notes: This syscall has subtle non-POSIX semantics: the fd is ALWAYS closed >> + * regardless of the return value. POSIX specifies that on EINTR, the state >> + * of the fd is unspecified, but Linux always closes it. HP-UX requires >> + * retrying close() on EINTR, but doing so on Linux may close an unrelated >> + * fd that was reassigned by another thread. For portable code, the safest >> + * approach is to check for errors but never retry close(). > >We don't care about HP-UX :) Fair :) The original text was contrasting Linux's "always closed" behavior with HP-UX. I'll just drop that reference. >> + * Error codes from the flush callback (EIO, ENOSPC, EDQUOT) indicate that >> + * previously written data may have been lost. These errors are particularly >> + * common on NFS where write errors are often deferred to close time. > >What flush callback? This was referring to f_op->flush, which filp_flush() calls during close. But you're right, that's internal plumbing. I'll reworded to describe the behavior without referencing internal callbacks: Error codes like EIO, ENOSPC, and EDQUOT indicate that previously buffered writes may have failed to reach storage. >> + * >> + * The driver's release() callback errors are explicitly ignored by the >> + * kernel, so device driver cleanup errors are not propagated to userspace. > >What "The driver" here? release() callbacks aren't really relevant >here. The original text was noting that __fput() ignores the return value of f_op->release(), so even if a driver's cleanup fails, userspace never sees it via close(). But agreed, that's an internal implementation detail not relevant to the syscall specification. Removed. Thanks for the review! -- Thanks, Sasha