From mboxrd@z Thu Jan 1 00:00:00 1970 From: hooanon05@yahoo.co.jp Subject: [RFC 6/8] Aufs2: fmode_exec Date: Mon, 23 Feb 2009 16:37:24 +0900 Message-ID: <7816.1235374644@jrobl> References: <7558.1235374266@jrobl> To: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Return-path: Received: from vsmtp04.dti.ne.jp ([202.216.231.139]:39465 "EHLO vsmtp04.dti.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752497AbZBWHh0 (ORCPT ); Mon, 23 Feb 2009 02:37:26 -0500 In-Reply-To: <7558.1235374266@jrobl> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: > This is my second trial to ask incorporating aufs into mainline. FMODE_EXEC and deny_write() ---------------------------------------------------------------------- Generally Unix prevents an executing file from writing its filedata. In linux it is implemented by deny_write() and allow_write(). When a file is executed by exec() family, open_exec() (and sys_uselib()) they opens the file and calls deny_write(). If the file is aufs's virtual one, it has no meaning. The file which deny_write() is really necessary is the file on a branch. But the FMODE_EXEC flag is not passed to ->open() operation. So aufs adopt a dirty trick. - in order to get FMODE_EXEC, aufs ->lookup() and ->d_revalidate() set nd->intent.open.file->private_data to nd->intent.open.flags temporary. - in aufs ->open(), when FMODE_EXEC is set in file->private_data, it calls deny_write() for the file on a branch. - when the aufs file is released, allow_write() for the file on a branch is called.