From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752989AbXCMBWO (ORCPT ); Mon, 12 Mar 2007 21:22:14 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753002AbXCMBWO (ORCPT ); Mon, 12 Mar 2007 21:22:14 -0400 Received: from outpipe-village-512-1.bc.nu ([81.2.110.250]:57874 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1752989AbXCMBWN (ORCPT ); Mon, 12 Mar 2007 21:22:13 -0400 Date: Tue, 13 Mar 2007 02:24:30 +0000 From: Alan Cox To: "Michael K. Edwards" Cc: "Bodo Eggert" <7eggert@gmx.de>, "Eric Dumazet" , "Linux Kernel Mailing List" Subject: Re: sys_write() racy for multi-threaded append? Message-ID: <20070313022430.57503b08@lxorguk.ukuu.org.uk> In-Reply-To: References: <7WzUo-1zl-21@gated-at.bofh.it> <7WAx2-2pg-21@gated-at.bofh.it> <7WAGF-2Bx-9@gated-at.bofh.it> <7WB07-3g5-33@gated-at.bofh.it> <7WBt7-3SZ-23@gated-at.bofh.it> X-Mailer: Claws Mail 2.8.1 (GTK+ 2.10.8; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org > Writing to a file from multiple processes is not usually the problem. > Writing to a common "struct file" from multiple threads is. Not normally because POSIX sensibly invented pread/pwrite. Forgot preadv/pwritev but they did the basics and end of problem > So what? My products are shipping _now_. That doesn't inspire confidence. > even funny. If POSIX mandates stupid shit, and application > programmers don't read that part of the manual anyway (and don't code > on that assumption in practice), to hell with POSIX. On many file Thats funny, you were talking about quality a moment ago. > descriptors, short writes simply can't happen -- and code that There is almost no descriptor this is true for. Any file I/O can and will end up short on disk full or resource limit exceeded or quota exceeded or NFS server exploded or ... And on the device side about the only thing with the vaguest guarantees is pipe(). > purports to handle short writes but has never been exercised is > arguably worse than code that simply bombs on short write. So if I > can't shim in an induce-short-writes-randomly-on-purpose mechanism > during development, I don't want short writes in production, period. Easy enough to do and gcov plus dejagnu or similar tools will let you coverage analyse the resulting test set and replay it. > Sure -- until the one code path in a hundred that handles the "short > write" case incorrectly gets traversed in production, after having > gone untested in a development environment that used a different > filesystem that never happened to trigger it. Competent QA and testing people test all the returns in the manual as well as all the returns they can find in the code. See ptrace(2) if you don't want to do a lot of relinking and strace for some useful worked examples of syscall hooking. Alan