Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757753AbYHOJJ4 (ORCPT ); Fri, 15 Aug 2008 05:09:56 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751444AbYHOJJr (ORCPT ); Fri, 15 Aug 2008 05:09:47 -0400 Received: from earthlight.etchedpixels.co.uk ([81.2.110.250]:35080 "EHLO lxorguk.ukuu.org.uk" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750920AbYHOJJr (ORCPT ); Fri, 15 Aug 2008 05:09:47 -0400 Date: Fri, 15 Aug 2008 09:51:43 +0100 From: Alan Cox To: Theodore Tso Cc: david@lang.hm, Christoph Hellwig , Eric Paris , tvrtko.ursulin@sophos.com, andi@firstfloor.org, Arjan van de Ven , linux-kernel@vger.kernel.org, malware-list@lists.printk.net, malware-list-bounces@dmesg.printk.net, peterz@infradead.org, viro@ZenIV.linux.org.uk Subject: Re: [malware-list] TALPA - a threat model? well sorta. Message-ID: <20080815095143.65c5912b@lxorguk.ukuu.org.uk> In-Reply-To: <20080815020400.GG13048@mit.edu> References: <20080813192922.GI8232@mit.edu> <20080814093103.6CD102FE8B4@pmx1.sophos.com> <20080814132455.GE6469@mit.edu> <1218721713.3540.125.camel@localhost.localdomain> <20080814155028.GB8256@mit.edu> <1218734985.9375.5.camel@paris.rdu.redhat.com> <20080814191726.GG22488@mit.edu> <20080814193408.GA10236@infradead.org> <20080814194111.GH22488@mit.edu> <20080815020400.GG13048@mit.edu> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; x86_64-redhat-linux-gnu) Organization: Red Hat UK Cyf., Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, Y Deyrnas Gyfunol. Cofrestrwyd yng Nghymru a Lloegr o'r rhif cofrestru 3798903 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 800 Lines: 17 > According to Eric Paris the clean/dirty state is only stored in > memory. We could use the extended attribute interface as a way of not > defining a new system call, or some other interface, but I'm not sure > it's such a great match given that the extended attributes interface > are designed for persistent data. This is another application layer matter. At the end of the day why does the kernel care where this data is kept. For all we know someone might want to centralise it or even distribute it between nodes on a clustered file system. Alan -- 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/