[PATCH 0/7] fix setuid/setgid clearing in networked filesystems (rev 7)
This patchset is the 7th revision for fixing the clearing of setuid and setgid bits in networked filesystems. It should apply cleanly to 2.6.23-rc6-mm1. The first four patches in the set are cleanup patches to make sure that those filesystems don't trip the new BUG() call in notify_change. The fifth patch (the main one) fixes notify_change to not clear the ATTR_KILL_S*ID bits when interpreting them into a mode change. The final two patches change NFS and CIFS to take advantage of the new scheme. This is basically the same patchset as version 6. The main differences are changes to ecryptfs and unionfs patches to accomodate changes made in recent -mm patches. Also, when I sent out the 6th revision I forgot to mention that the knfsd patch had been changed to more closely reflect the existing behavior when receiving a setattr call that changes the mode and uid/gid. This patchset is being submitted for inclusion into -mm. Signed-off-by: Jeff Layton [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] ecryptfs: allow lower fs to interpret ATTR_KILL_S*ID
Make sure ecryptfs doesn't trip the BUG() in notify_change. This also allows the lower filesystem to interpret ATTR_KILL_S*ID in its own way. Signed-off-by: Jeff Layton [EMAIL PROTECTED] --- fs/ecryptfs/inode.c |8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/fs/ecryptfs/inode.c b/fs/ecryptfs/inode.c index fc4c6cb..23a2fef 100644 --- a/fs/ecryptfs/inode.c +++ b/fs/ecryptfs/inode.c @@ -959,6 +959,14 @@ static int ecryptfs_setattr(struct dentry *dentry, struct iattr *ia) if (rc 0) goto out; } + + /* +* mode change is for clearing setuid/setgid bits. Allow lower fs +* to interpret this in its own way. +*/ + if (ia-ia_valid (ATTR_KILL_SUID | ATTR_KILL_SGID)) + ia-ia_valid = ~ATTR_MODE; + rc = notify_change(lower_dentry, ia); out: fsstack_copy_attr_all(inode, lower_inode); -- 1.5.2.1 - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] knfsd: only set ATTR_KILL_S*ID if ATTR_MODE isn't being explicitly set
It's theoretically possible for a single SETATTR call to come in that
sets the mode and the uid/gid. In that case, don't set the ATTR_KILL_S*ID
bits since that would trip the BUG() in notify_change. Just fix up the
mode to have the same effect.
Signed-off-by: Jeff Layton [EMAIL PROTECTED]
---
fs/nfsd/vfs.c | 21 +++--
1 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
index 9b21710..e2f0d98 100644
--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -370,14 +370,23 @@ nfsd_setattr(struct svc_rqst *rqstp, struct svc_fh *fhp,
struct iattr *iap,
if (iap-ia_valid ATTR_MODE) {
iap-ia_mode = S_IALLUGO;
imode = iap-ia_mode |= (imode ~S_IALLUGO);
+ /* if changing uid/gid revoke setuid/setgid in mode */
+ if ((iap-ia_valid ATTR_UID) iap-ia_uid != inode-i_uid) {
+ iap-ia_valid |= ATTR_KILL_PRIV;
+ iap-ia_mode = ~S_ISUID;
+ }
+ if ((iap-ia_valid ATTR_GID) iap-ia_gid != inode-i_gid)
+ iap-ia_mode = ~S_ISGID;
+ } else {
+ /*
+* Revoke setuid/setgid bit on chown/chgrp
+*/
+ if ((iap-ia_valid ATTR_UID) iap-ia_uid != inode-i_uid)
+ iap-ia_valid |= ATTR_KILL_SUID | ATTR_KILL_PRIV;
+ if ((iap-ia_valid ATTR_GID) iap-ia_gid != inode-i_gid)
+ iap-ia_valid |= ATTR_KILL_SGID;
}
- /* Revoke setuid/setgid bit on chown/chgrp */
- if ((iap-ia_valid ATTR_UID) iap-ia_uid != inode-i_uid)
- iap-ia_valid |= ATTR_KILL_SUID | ATTR_KILL_PRIV;
- if ((iap-ia_valid ATTR_GID) iap-ia_gid != inode-i_gid)
- iap-ia_valid |= ATTR_KILL_SGID;
-
/* Change the attributes. */
iap-ia_valid |= ATTR_CTIME;
--
1.5.2.1
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/7] unionfs: fix unionfs_setattr to handle ATTR_KILL_S*ID
Don't allow unionfs_setattr to trip the BUG() in notify_change. Clear
ATTR_MODE if the either ATTR_KILL_S*ID is set. This also allows the
lower filesystem to interpret these bits in its own way.
Signed-off-by: Jeff Layton [EMAIL PROTECTED]
---
fs/unionfs/inode.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/fs/unionfs/inode.c b/fs/unionfs/inode.c
index 687b9a7..9cb54d9 100644
--- a/fs/unionfs/inode.c
+++ b/fs/unionfs/inode.c
@@ -1021,6 +1021,13 @@ static int unionfs_setattr(struct dentry *dentry, struct
iattr *ia)
bend = dbend(dentry);
inode = dentry-d_inode;
+ /*
+* mode change is for clearing setuid/setgid. Allow lower filesystem
+* to reinterpret it in its own way.
+*/
+ if (ia-ia_valid (ATTR_KILL_SUID | ATTR_KILL_SGID))
+ ia-ia_valid = ~ATTR_MODE;
+
for (bindex = bstart; (bindex = bend) || (bindex == bstart);
bindex++) {
lower_dentry = unionfs_lower_dentry_idx(dentry, bindex);
--
1.5.2.1
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] VFS: make notify_change pass ATTR_KILL_S*ID to setattr operations
When an unprivileged process attempts to modify a file that has the
setuid or setgid bits set, the VFS will attempt to clear these bits. The
VFS will set the ATTR_KILL_SUID or ATTR_KILL_SGID bits in the ia_valid
mask, and then call notify_change to clear these bits and set the mode
accordingly.
With a networked filesystem (NFS and CIFS in particular but likely
others), the client machine or process may not have credentials that
allow for setting the mode. In some situations, this can lead to file
corruption, an operation failing outright because the setattr fails, or
to races that lead to a mode change being reverted.
In this situation, we'd like to just leave the handling of this to the
server and ignore these bits. The problem is that by the time the
setattr op is called, the VFS has already reinterpreted the ATTR_KILL_*
bits into a mode change. The setattr operation has no way to know its
intent.
The following patch fixes this by making notify_change no longer
clear the ATTR_KILL_SUID and ATTR_KILL_SGID bits in the ia_valid before
handing it off to the setattr inode op. setattr can then check for the
presence of these bits, and if they're set it can assume that the mode
change was only for the purposes of clearing these bits.
This means that we now have an implicit assumption that notify_change is
never called with ATTR_MODE and either ATTR_KILL_S*ID bit set. Nothing
currently enforces that, so this patch also adds a BUG() if that occurs.
Signed-off-by: Jeff Layton [EMAIL PROTECTED]
---
fs/attr.c | 26 --
1 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/fs/attr.c b/fs/attr.c
index ae58bd3..966b73e 100644
--- a/fs/attr.c
+++ b/fs/attr.c
@@ -103,12 +103,11 @@ EXPORT_SYMBOL(inode_setattr);
int notify_change(struct dentry * dentry, struct iattr * attr)
{
struct inode *inode = dentry-d_inode;
- mode_t mode;
+ mode_t mode = inode-i_mode;
int error;
struct timespec now;
unsigned int ia_valid = attr-ia_valid;
- mode = inode-i_mode;
now = current_fs_time(inode-i_sb);
attr-ia_ctime = now;
@@ -125,18 +124,25 @@ int notify_change(struct dentry * dentry, struct iattr *
attr)
if (error)
return error;
}
+
+ /*
+* We now pass ATTR_KILL_S*ID to the lower level setattr function so
+* that the function has the ability to reinterpret a mode change
+* that's due to these bits. This adds an implicit restriction that
+* no function will ever call notify_change with both ATTR_MODE and
+* ATTR_KILL_S*ID set.
+*/
+ if ((ia_valid (ATTR_KILL_SUID|ATTR_KILL_SGID))
+ (ia_valid ATTR_MODE))
+ BUG();
+
if (ia_valid ATTR_KILL_SUID) {
- attr-ia_valid = ~ATTR_KILL_SUID;
if (mode S_ISUID) {
- if (!(ia_valid ATTR_MODE)) {
- ia_valid = attr-ia_valid |= ATTR_MODE;
- attr-ia_mode = inode-i_mode;
- }
- attr-ia_mode = ~S_ISUID;
+ ia_valid = attr-ia_valid |= ATTR_MODE;
+ attr-ia_mode = (inode-i_mode ~S_ISUID);
}
}
if (ia_valid ATTR_KILL_SGID) {
- attr-ia_valid = ~ ATTR_KILL_SGID;
if ((mode (S_ISGID | S_IXGRP)) == (S_ISGID | S_IXGRP)) {
if (!(ia_valid ATTR_MODE)) {
ia_valid = attr-ia_valid |= ATTR_MODE;
@@ -145,7 +151,7 @@ int notify_change(struct dentry * dentry, struct iattr *
attr)
attr-ia_mode = ~S_ISGID;
}
}
- if (!attr-ia_valid)
+ if (!(attr-ia_valid ~(ATTR_KILL_SUID | ATTR_KILL_SGID)))
return 0;
if (ia_valid ATTR_SIZE)
--
1.5.2.1
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] NFS: if ATTR_KILL_S*ID bits are set, then skip mode change
If the ATTR_KILL_S*ID bits are set then any mode change is only for
clearing the setuid/setgid bits. For NFS, skip the mode change and
let the server handle it.
Signed-off-by: Jeff Layton [EMAIL PROTECTED]
---
fs/nfs/inode.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
index 1ca3793..83f624d 100644
--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
@@ -327,6 +327,10 @@ nfs_setattr(struct dentry *dentry, struct iattr *attr)
nfs_inc_stats(inode, NFSIOS_VFSSETATTR);
+ /* skip mode change if it's just for clearing setuid/setgid */
+ if (attr-ia_valid (ATTR_KILL_SUID | ATTR_KILL_SGID))
+ attr-ia_valid = ~ATTR_MODE;
+
if (attr-ia_valid ATTR_SIZE) {
if (!S_ISREG(inode-i_mode) || attr-ia_size ==
i_size_read(inode))
attr-ia_valid = ~ATTR_SIZE;
--
1.5.2.1
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] CIFS: ignore mode change if it's just for clearing setuid/setgid bits
If the ATTR_KILL_S*ID bits are set then any mode change is only for
clearing the setuid/setgid bits. For CIFS, skip the mode change and
let the server handle it.
Signed-off-by: Jeff Layton [EMAIL PROTECTED]
---
fs/cifs/inode.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/fs/cifs/inode.c b/fs/cifs/inode.c
index 552d68b..515ccc1 100644
--- a/fs/cifs/inode.c
+++ b/fs/cifs/inode.c
@@ -1555,6 +1555,11 @@ int cifs_setattr(struct dentry *direntry, struct iattr
*attrs)
}
time_buf.Attributes = 0;
+
+ /* skip mode change if it's just for clearing setuid/setgid */
+ if (attrs-ia_valid (ATTR_KILL_SUID|ATTR_KILL_SGID))
+ attrs-ia_valid = ~ATTR_MODE;
+
if (attrs-ia_valid ATTR_MODE) {
cFYI(1, (Mode changed to 0x%x, attrs-ia_mode));
mode = attrs-ia_mode;
--
1.5.2.1
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/7] reiserfs: turn of ATTR_KILL_S*ID at beginning of reiserfs_setattr
reiserfs_setattr can call notify_change recursively using the same
iattr struct. This could cause it to trip the BUG() in notify_change.
Fix reiserfs to clear those bits near the beginning of the function.
Signed-off-by: Jeff Layton [EMAIL PROTECTED]
---
fs/reiserfs/inode.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/fs/reiserfs/inode.c b/fs/reiserfs/inode.c
index 9ea1200..0804289 100644
--- a/fs/reiserfs/inode.c
+++ b/fs/reiserfs/inode.c
@@ -3061,7 +3061,11 @@ int reiserfs_setattr(struct dentry *dentry, struct iattr
*attr)
{
struct inode *inode = dentry-d_inode;
int error;
- unsigned int ia_valid = attr-ia_valid;
+ unsigned int ia_valid;
+
+ /* must be turned off for recursive notify_change calls */
+ ia_valid = attr-ia_valid = ~(ATTR_KILL_SUID|ATTR_KILL_SGID);
+
reiserfs_write_lock(inode-i_sb);
if (attr-ia_valid ATTR_SIZE) {
/* version 2 items will be caught by the s_maxbytes check
--
1.5.2.1
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [00/41] Large Blocksize Support V7 (adds memmap support)
On Thu, Sep 20, 2007 at 11:38:21AM +1000, David Chinner wrote: Sure, and that's what I meant when I said VPC + large pages was a means to the end, not the only solution to the problem. The whole point is that it's not an end, it's an end to your own fs centric view only (which is sure fair enough), but I watch the whole VM not just the pagecache... The same way the fs-centric view will hope to get this little bit of further optimization from largepages to reach the end, my VM-wide view wants the same little bit of opitmization for *everything* including tmpfs and anonymous memory, slab etc..! This is clearly why config-page-shift is better... If you're ok not to be on the edge and you want a generic rpm image that run quite optimally for any workload, then 4k+fslblock is just fine of course. But if we go on the edge we should aim for the _very_ end for the whole VM, not just for the end of the pagecache on certain files. Especially when the complexity involved in the mmap code is similar, and it will reject heavily if we merge this not-very-end solution that only reaches the end for the pagecache. No, I don't like fsblock because it is inherently a struture per filesystem block construct, just like buggerheads. You still need to allocate millions of them when you have millions dirty pages around. Rather than type it all out again, read the fsblocks thread from here: http://marc.info/?l=linux-fsdevelm=118284983925719w=2 Thanks for the pointer! FWIW, with Chris mason's extent-based block mapping (which btrfs is using and Christoph Hellwig is porting XFS over to) we completely remove buggerheads from XFS and so fsblock would be a pretty major step backwards for us if Chris's work goes into mainline. I tend to agree if we change it fsblock should support extent if that's what you need on xfs to support range-locking etc... Whatever happens in vfs should please all existing fs without people needing to go their own way again... Or replace fsblock with Chris's block mapping. Frankly I didn't see Chris's code so I cannot comment further. But your complains sounds sensible. We certainly want to avoid lowlevel fs to get smarter again than the vfs. The brainer stuff should be in vfs! That's not in the filesystem, though. ;) However, I agree that if you don't have mmap then it's not worthwhile and the changes for VPC aren't trivial. Yep. 3. avoiding the need for vmap() as it has great overhead and does not scale - Nick is starting to work on that and has already had good results. Frankly I don't follow this vmap thing. Can you elaborate? We current support metadata blocks larger than page size for certain types of metadata in XFS. e.g. directory blocks. This however, requires vmap()ing a bunch of individual, non-contiguous pages out of a block device address space in exactly the fashion that was proposed by Nick with fsblock originally. vmap() has severe scalability problems - read this subthread of this discussion between Nick and myself: http://lkml.org/lkml/2007/9/11/508 So the idea of vmap is that it's much simpler to have a contiguous virtual address space large blocksize, than to find the right b_data[index] once you exceed PAGE_SIZE... The global tlb flush with ipi would kill performance, you can forget any global mapping here. The only chance to do this would be like we do with kmap_atomic per-cpu on highmem, with preempt_disable (for the enjoyment of the rt folks out there ;). what's the problem of having it per-cpu? Is this what fsblock already does? You've just have to allocate a new virtual range large numberofentriesinvmap*blocksize every time you mount a new fs. Then instead of calling kmap you call vmap and vunmap when you're finished. That should provide decent performance, especially with physically indexed caches. Anything more heavyweight than what I suggested is probably overkill, even vmalloc_to_page. Hmm - so you'll need page cache tail packing as well in that case to prevent memory being wasted on small files. That means any way we look at it (VPC+mmap or config-page-shift+fsblock+pctails) we've got some non-trivial VM modifications to make. Hmm no, the point of config-page-shift is that if you really need to reach the very end, you probably don't care about wasting some memory, because either your workload can't fit in cache, or it fits in cache regardless, or you're not wasting memory because you work with large files... The only point of this largepage stuff is to go an extra mile to save a bit more of cpu vs a strict vmap based solution (fsblock of course will be smart enough that if it notices the PAGE_SIZE is = blocksize it doesn't need to run any vmap at all and it can just use the direct mapping, so vmap translates in 1 branch only to check the blocksize variable, PAGE_SIZE is immediate in the .text at compile time). But if you care about that tiny bit of performance during I/O
Re: [13/17] Virtual compound page freeing in interrupt context
On Wednesday 19 September 2007 13:36, Christoph Lameter wrote:
If we are in an interrupt context then simply defer the free via a
workqueue.
In an interrupt context it is not possible to use vmalloc_addr() to
determine the vmalloc address. So add a variant that does that too.
Removing a virtual mappping *must* be done with interrupts enabled
since tlb_xx functions are called that rely on interrupts for
processor to processor communications.
These things will clash drastically with my lazy TLB flushing and scalability
work. Actually the lazy TLB flushing will provide a natural way to defer
unmapping at interrupt time, and the scalability work should make it
easier to vmap from interrupt context too, if you really need that.
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
mm/page_alloc.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
Index: linux-2.6/mm/page_alloc.c
===
--- linux-2.6.orig/mm/page_alloc.c2007-09-18 20:10:55.0 -0700
+++ linux-2.6/mm/page_alloc.c 2007-09-18 20:11:40.0 -0700
@@ -1297,7 +1297,12 @@ abort:
return NULL;
}
-static void vcompound_free(void *addr)
+/*
+ * Virtual Compound freeing functions. This is complicated by the vmalloc
+ * layer not being able to free virtual allocations when interrupts are
+ * disabled. So we defer the frees via a workqueue if necessary.
+ */
+static void __vcompound_free(void *addr)
{
struct page **pages = vunmap(addr);
int i;
@@ -1320,6 +1325,22 @@ static void vcompound_free(void *addr)
kfree(pages);
}
+static void vcompound_free_work(struct work_struct *w)
+{
+ __vcompound_free((void *)w);
+}
+
+static void vcompound_free(void *addr)
+{
+ if (in_interrupt()) {
+ struct work_struct *w = addr;
+
+ INIT_WORK(w, vcompound_free_work);
+ schedule_work(w);
+ } else
+ __vcompound_free(addr);
+}
+
/*
* This is the 'heart' of the zoned buddy allocator.
*/
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [13/17] Virtual compound page freeing in interrupt context
On Wed, 19 Sep 2007, Nick Piggin wrote: Removing a virtual mappping *must* be done with interrupts enabled since tlb_xx functions are called that rely on interrupts for processor to processor communications. These things will clash drastically with my lazy TLB flushing and scalability work. Actually the lazy TLB flushing will provide a natural way to defer unmapping at interrupt time, and the scalability work should make it easier to vmap from interrupt context too, if you really need that. Both would be good to have. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/11] eCryptfs: Replace encrypt, decrypt, and inode size write
On Wed, Sep 19, 2007 at 10:46:26PM -0700, Andrew Morton wrote:
(from ecryptfs_encrypt_page()):
+ enc_extent_virt = kmalloc(PAGE_CACHE_SIZE, GFP_USER);
I'd have thought that alloc_page() would be nicer. After all, we _are_
treating it as a page, and not as a random piece of memry.
+ if (!enc_extent_virt) {
+ rc = -ENOMEM;
+ ecryptfs_printk(KERN_ERR, Error allocating memory for
+ encrypted extent\n);
+ goto out;
+ }
+ enc_extent_page = virt_to_page(enc_extent_virt);
And then we don't need this.
If neither kmap() nor kmap_atomic() can be safely used to get a
virtual address to pass to vfs_write(), then I do not know what my
other options are here.
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/11] eCryptfs: Convert mmap functions to use persistent file
On Wed, Sep 19, 2007 at 10:50:57PM -0700, Andrew Morton wrote:
On Mon, 17 Sep 2007 16:50:16 -0500 Michael Halcrow [EMAIL PROTECTED] wrote:
+ecryptfs_copy_up_encrypted_with_header(struct page *page,
+ struct ecryptfs_crypt_stat *crypt_stat)
+{
...
+ flush_dcache_page(page);
+ if (rc) {
+ ClearPageUptodate(page);
+ printk(KERN_ERR %s: Error reading xattr
+ region; rc = [%d]\n, __FUNCTION__, rc);
+ goto out;
+ }
+ SetPageUptodate(page);
I don't know what sort of page `page' refers to here, but normally we only
manipulate the page uptodate status under lock_page().
This is the page that eCryptfs gets via
ecryptfs_aops-ecryptfs_readpage(), so this should be okay. The
comment should make the fact that the page is locked explicit.
Signed-off-by: Michael Halcrow [EMAIL PROTECTED]
---
diff --git a/fs/ecryptfs/mmap.c b/fs/ecryptfs/mmap.c
index 04103ff..c6a8a33 100644
--- a/fs/ecryptfs/mmap.c
+++ b/fs/ecryptfs/mmap.c
@@ -111,7 +111,7 @@ static void set_header_info(char *page_virt,
* ecryptfs_copy_up_encrypted_with_header
* @page: Sort of a ``virtual'' representation of the encrypted lower
*file. The actual lower file does not have the metadata in
- *the header.
+ *the header. This is locked.
* @crypt_stat: The eCryptfs inode's cryptographic context
*
* The ``view'' is the version of the file that userspace winds up
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/11] eCryptfs: Replace encrypt, decrypt, and inode size write
In message [EMAIL PROTECTED], Michael Halcrow writes:
On Wed, Sep 19, 2007 at 10:46:26PM -0700, Andrew Morton wrote:
(from ecryptfs_encrypt_page()):
+ enc_extent_virt = kmalloc(PAGE_CACHE_SIZE, GFP_USER);
I'd have thought that alloc_page() would be nicer. After all, we _are_
treating it as a page, and not as a random piece of memry.
+ if (!enc_extent_virt) {
+ rc = -ENOMEM;
+ ecryptfs_printk(KERN_ERR, Error allocating memory for
+ encrypted extent\n);
+ goto out;
+ }
+ enc_extent_page = virt_to_page(enc_extent_virt);
And then we don't need this.
If neither kmap() nor kmap_atomic() can be safely used to get a
virtual address to pass to vfs_write(), then I do not know what my
other options are here.
kmap_atomic is intended for short-lived code sections, where you may not
sleep, so you can't do a vfs_read/write in b/t kmap/kunmap_atomic.
Erez.
-
To unsubscribe from this list: send the line unsubscribe linux-fsdevel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/18] exportfs: add new methods
On Wed, 19 Sep 2007 18:30:25 +0200 Christoph Hellwig [EMAIL PROTECTED] wrote: + /* + * It's not a directory. Life is a little more complicated. + */ + struct dentry *target_dir, *nresult; + char nbuf[NAME_MAX+1]; Lots of stack usage there. - To unsubscribe from this list: send the line unsubscribe linux-fsdevel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
