Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S269242AbUISOqr (ORCPT ); Sun, 19 Sep 2004 10:46:47 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S269245AbUISOqr (ORCPT ); Sun, 19 Sep 2004 10:46:47 -0400 Received: from mx1.redhat.com ([66.187.233.31]:30140 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S269242AbUISOqp (ORCPT ); Sun, 19 Sep 2004 10:46:45 -0400 Date: Sun, 19 Sep 2004 10:46:18 -0400 (EDT) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: Andreas Gruenbacher cc: Andrew Morton , , Stephen Smalley , Christoph Hellwig , Subject: Re: [PATCH 1/6] xattr consolidation v2 - generic xattr API In-Reply-To: <200409191213.57977.agruen@suse.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 811 Lines: 26 On Sun, 19 Sep 2004, Andreas Gruenbacher wrote: > Documentation/filesystems/Locking seems to be accurate. There's an out of date comment in fs/devpts/xattr.c (which is no excuse for screwing it up though). > The old handler API was fine at the FS level where locking was guaranteed > anyways. At the VFS level we should do better. Passing in the buffer and the > buffer size at the same time gets us rid of the problem without requiring any > locking. Ok, I'll incorporate this and resubmit the patches soon. - James -- James Morris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/