patch ext4_ext_put_in_cache-uses-__u32-to-receive-physical-block-number.patch queued to -stable tree
This is a note to let you know that we have just queued up the patch titled
Subject: ext4_ext_put_in_cache uses __u32 to receive physical block
number
to the 2.6.22-stable tree. Its filename is
ext4_ext_put_in_cache-uses-__u32-to-receive-physical-block-number.patch
A git repo of this tree can be found at
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
From [EMAIL PROTECTED] Tue Jul 31 00:48:13 2007
From: Mingming Cao [EMAIL PROTECTED]
Date: Tue, 31 Jul 2007 00:37:46 -0700
Subject: ext4_ext_put_in_cache uses __u32 to receive physical block number
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], linux-ext4@vger.kernel.org, [EMAIL PROTECTED], [EMAIL
PROTECTED], [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
From: Mingming Cao [EMAIL PROTECTED]
Yan Zheng wrote:
I think I found a bug in ext4/extents.c, ext4_ext_put_in_cache uses
__u32 to receive physical block number. ext4_ext_put_in_cache is
used in ext4_ext_get_blocks, it sets ext4 inode's extent cache
according most recently tree lookup (higher 16 bits of saved physical
block number are always zero). when serving a mapping request,
ext4_ext_get_blocks first check whether the logical block is in
inode's extent cache. if the logical block is in the cache and the
cached region isn't a gap, ext4_ext_get_blocks gets physical block
number by using cached region's physical block number and offset in
the cached region. as described above, ext4_ext_get_blocks may
return wrong result when there are physical block numbers bigger than
0x.
You are right. Thanks for reporting this!
Signed-off-by: Mingming Cao [EMAIL PROTECTED]
Cc: Yan Zheng [EMAIL PROTECTED]
Cc: linux-ext4@vger.kernel.org
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
--- a/fs/ext4/extents.c~ext4_ext_put_in_cache-uses-__u32-to-receive-physical
+++ a/fs/ext4/extents.c
@@ -1544,7 +1544,7 @@ int ext4_ext_walk_space(struct inode *in
static void
ext4_ext_put_in_cache(struct inode *inode, __u32 block,
- __u32 len, __u32 start, int type)
+ __u32 len, ext4_fsblk_t start, int type)
{
struct ext4_ext_cache *cex;
BUG_ON(len == 0);
_
___
stable mailing list
[EMAIL PROTECTED]
http://linux.kernel.org/mailman/listinfo/stable
Patches currently in stable-queue which might be from [EMAIL PROTECTED] are
queue-2.6.22/ext4_ext_put_in_cache-uses-__u32-to-receive-physical-block-number.patch
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
patch jbd-commit-fix-transaction-dropping.patch queued to -stable tree
This is a note to let you know that we have just queued up the patch titled
Subject: jbd commit: fix transaction dropping
to the 2.6.22-stable tree. Its filename is
jbd-commit-fix-transaction-dropping.patch
A git repo of this tree can be found at
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
From [EMAIL PROTECTED] Sun Jul 15 23:37:47 2007
From: Jan Kara [EMAIL PROTECTED]
Date: Sun, 15 Jul 2007 23:37:18 -0700
Subject: jbd commit: fix transaction dropping
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
linux-ext4@vger.kernel.org, [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
From: Jan Kara [EMAIL PROTECTED]
We have to check that also the second checkpoint list is non-empty before
dropping the transaction.
Signed-off-by: Jan Kara [EMAIL PROTECTED]
Cc: Chuck Ebbert [EMAIL PROTECTED]
Cc: Kirill Korotaev [EMAIL PROTECTED]
Cc: linux-ext4@vger.kernel.org
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
diff -puN fs/jbd/commit.c~jbd-commit-fix-transaction-dropping fs/jbd/commit.c
--- a/fs/jbd/commit.c~jbd-commit-fix-transaction-dropping
+++ a/fs/jbd/commit.c
@@ -887,7 +887,8 @@ restart_loop:
journal-j_committing_transaction = NULL;
spin_unlock(journal-j_state_lock);
- if (commit_transaction-t_checkpoint_list == NULL) {
+ if (commit_transaction-t_checkpoint_list == NULL
+ commit_transaction-t_checkpoint_io_list == NULL) {
__journal_drop_transaction(journal, commit_transaction);
} else {
if (journal-j_checkpoint_transactions == NULL) {
_
___
stable mailing list
[EMAIL PROTECTED]
http://linux.kernel.org/mailman/listinfo/stable
Patches currently in stable-queue which might be from [EMAIL PROTECTED] are
queue-2.6.22/jbd-commit-fix-transaction-dropping.patch
queue-2.6.22/jbd2-commit-fix-transaction-dropping.patch
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
patch jbd2-commit-fix-transaction-dropping.patch queued to -stable tree
This is a note to let you know that we have just queued up the patch titled
Subject: jbd2 commit: fix transaction dropping
to the 2.6.22-stable tree. Its filename is
jbd2-commit-fix-transaction-dropping.patch
A git repo of this tree can be found at
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
From [EMAIL PROTECTED] Sun Jul 15 23:37:38 2007
From: Jan Kara [EMAIL PROTECTED]
Date: Sun, 15 Jul 2007 23:37:20 -0700
Subject: jbd2 commit: fix transaction dropping
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
linux-ext4@vger.kernel.org, [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
From: Jan Kara [EMAIL PROTECTED]
We have to check that also the second checkpoint list is non-empty before
dropping the transaction.
Signed-off-by: Jan Kara [EMAIL PROTECTED]
Cc: Chuck Ebbert [EMAIL PROTECTED]
Cc: Kirill Korotaev [EMAIL PROTECTED]
Cc: linux-ext4@vger.kernel.org
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
diff -puN fs/jbd2/commit.c~jbd2-commit-fix-transaction-dropping fs/jbd2/commit.c
--- a/fs/jbd2/commit.c~jbd2-commit-fix-transaction-dropping
+++ a/fs/jbd2/commit.c
@@ -896,7 +896,8 @@ restart_loop:
journal-j_committing_transaction = NULL;
spin_unlock(journal-j_state_lock);
- if (commit_transaction-t_checkpoint_list == NULL) {
+ if (commit_transaction-t_checkpoint_list == NULL
+ commit_transaction-t_checkpoint_io_list == NULL) {
__jbd2_journal_drop_transaction(journal, commit_transaction);
} else {
if (journal-j_checkpoint_transactions == NULL) {
_
___
stable mailing list
[EMAIL PROTECTED]
http://linux.kernel.org/mailman/listinfo/stable
Patches currently in stable-queue which might be from [EMAIL PROTECTED] are
queue-2.6.22/jbd-commit-fix-transaction-dropping.patch
queue-2.6.22/jbd2-commit-fix-transaction-dropping.patch
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: E2fsprogs git tree
Theodore Ts'o wrote: People may have noticed that e2fsprogs 1.40 and roughly a week later e2fsprogs 1.40.1 have been released, while there hasn't been any activity at http://thunk.org/hg/e2fsprogs. That's because right after e2fsprogs 1.40, I have moved the e2fsprogs development activity over to git. The public repositories can be found here: http://www.kernel.org/pub/scm/fs/ext2/e2fsprogs.git git://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git and here: git://repo.or.cz/e2fsprogs.git http://repo.or.cz/r/e2fsprogs.git Hi Ted, I tried to clone the source tree but it failed. The command git-clone http://www.kernel.org/pub/scm/fs/ext2/e2fsprogs.git; failed with : error: Could not interpret tags/APPLE_UUID_SNAP_1 as something to pull The command git-clone http://repo.or.cz/r/e2fsprogs.git; failed with: error: Can't lock ref Could you have a look at this please? Thank you very much, Valérie - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: E2fsprogs git tree
Valerie, How about this: git clone git://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git It works for me. Valerie Clement wrote: Theodore Ts'o wrote: People may have noticed that e2fsprogs 1.40 and roughly a week later e2fsprogs 1.40.1 have been released, while there hasn't been any activity at http://thunk.org/hg/e2fsprogs. That's because right after e2fsprogs 1.40, I have moved the e2fsprogs development activity over to git. The public repositories can be found here: http://www.kernel.org/pub/scm/fs/ext2/e2fsprogs.git git://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git and here: git://repo.or.cz/e2fsprogs.git http://repo.or.cz/r/e2fsprogs.git Hi Ted, I tried to clone the source tree but it failed. The command git-clone http://www.kernel.org/pub/scm/fs/ext2/e2fsprogs.git; failed with : error: Could not interpret tags/APPLE_UUID_SNAP_1 as something to pull The command git-clone http://repo.or.cz/r/e2fsprogs.git; failed with: error: Can't lock ref Could you have a look at this please? Thank you very much, Val�rie - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: E2fsprogs git tree
On Tue, Aug 07, 2007 at 06:23:46PM +0200, Valerie Clement wrote: Hi Ted, I tried to clone the source tree but it failed. The command git-clone http://www.kernel.org/pub/scm/fs/ext2/e2fsprogs.git; failed with : error: Could not interpret tags/APPLE_UUID_SNAP_1 as something to pull The command git-clone http://repo.or.cz/r/e2fsprogs.git; failed with: error: Can't lock ref What version of git are you using? Make sure you are using something which is at least git 1.5.x. BTW, the better URL's to use are: git clone git://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git or git clone git://repo.or.cz/e2fsprogs.git The http walkers are *much* more inefficient. I did try out git-clone using the http URL's, and it works, but it's slow. The other possibility is that you have some kind of nasty http transparent proxy which is corrupting the http protocol stream. This is why the git transport is seriously the much, much, MUCH better alternative. - Ted - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: E2fsprogs git tree
On Tue, 7 Aug 2007 13:28:14 -0400 Theodore Tso [EMAIL PROTECTED] wrote: On Tue, Aug 07, 2007 at 06:23:46PM +0200, Valerie Clement wrote: Hi Ted, I tried to clone the source tree but it failed. The command git-clone http://www.kernel.org/pub/scm/fs/ext2/e2fsprogs.git; failed with : error: Could not interpret tags/APPLE_UUID_SNAP_1 as something to pull The command git-clone http://repo.or.cz/r/e2fsprogs.git; failed with: error: Can't lock ref What version of git are you using? Make sure you are using something which is at least git 1.5.x. I get the same error as Valerie when using version 1.4.4.2. The same version worked a couple of weeks ago when using the http URL. BTW, the better URL's to use are: git clone git://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git or git clone git://repo.or.cz/e2fsprogs.git This seems to works fine using my older version of git. The http walkers are *much* more inefficient. I did try out git-clone using the http URL's, and it works, but it's slow. The other possibility is that you have some kind of nasty http transparent proxy which is corrupting the http protocol stream. This is why the git transport is seriously the much, much, MUCH better alternative. - Ted -JRS - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/25] move handling of setuid/gid bits from VFS into individual setattr functions (RESEND)
First thanks a lot for doing this work, it's been long needed. Second please don't send out that many patches. We encourage people to split things into small patches when the changes are logially separated. Which these are not - it's a flag day change (which btw is fine despite the rants soe people spewed in reply to this), so it should be one single patch. (Or one for all mainline filesystems + one per fs only in -mm to make Andrew's life a little easier if you really care.) - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/25] VFS: move attr_kill logic from notify_change into helper function
+void attr_kill_to_mode(struct inode *inode, struct iattr *attr) This function badly needs a kerneldoc description. Also I can't say I like the name a lot, but without a clearly better idea I should probably not complain :) We should at least add a generic_ prefix to indicate it's a generic helper valid for most filesystem (and the kerneldoc comment can explain the details) - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[2.6.22.2 review 43/84] ext4_ext_put_in_cache uses __u32 to receive physical block number
From: Mingming Cao [EMAIL PROTECTED]
Yan Zheng wrote:
I think I found a bug in ext4/extents.c, ext4_ext_put_in_cache uses
__u32 to receive physical block number. ext4_ext_put_in_cache is
used in ext4_ext_get_blocks, it sets ext4 inode's extent cache
according most recently tree lookup (higher 16 bits of saved physical
block number are always zero). when serving a mapping request,
ext4_ext_get_blocks first check whether the logical block is in
inode's extent cache. if the logical block is in the cache and the
cached region isn't a gap, ext4_ext_get_blocks gets physical block
number by using cached region's physical block number and offset in
the cached region. as described above, ext4_ext_get_blocks may
return wrong result when there are physical block numbers bigger than
0x.
You are right. Thanks for reporting this!
Signed-off-by: Mingming Cao [EMAIL PROTECTED]
Cc: Yan Zheng [EMAIL PROTECTED]
Cc: linux-ext4@vger.kernel.org
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
---
fs/ext4/extents.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/ext4/extents.c
+++ b/fs/ext4/extents.c
@@ -1445,7 +1445,7 @@ int ext4_ext_walk_space(struct inode *in
static void
ext4_ext_put_in_cache(struct inode *inode, __u32 block,
- __u32 len, __u32 start, int type)
+ __u32 len, ext4_fsblk_t start, int type)
{
struct ext4_ext_cache *cex;
BUG_ON(len == 0);
--
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[2.6.22.2 review 58/84] jbd commit: fix transaction dropping
From: Jan Kara [EMAIL PROTECTED]
We have to check that also the second checkpoint list is non-empty before
dropping the transaction.
Signed-off-by: Jan Kara [EMAIL PROTECTED]
Cc: Chuck Ebbert [EMAIL PROTECTED]
Cc: Kirill Korotaev [EMAIL PROTECTED]
Cc: linux-ext4@vger.kernel.org
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
---
fs/jbd/commit.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/fs/jbd/commit.c
+++ b/fs/jbd/commit.c
@@ -887,7 +887,8 @@ restart_loop:
journal-j_committing_transaction = NULL;
spin_unlock(journal-j_state_lock);
- if (commit_transaction-t_checkpoint_list == NULL) {
+ if (commit_transaction-t_checkpoint_list == NULL
+ commit_transaction-t_checkpoint_io_list == NULL) {
__journal_drop_transaction(journal, commit_transaction);
} else {
if (journal-j_checkpoint_transactions == NULL) {
--
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[2.6.22.2 review 59/84] jbd2 commit: fix transaction dropping
From: Jan Kara [EMAIL PROTECTED]
We have to check that also the second checkpoint list is non-empty before
dropping the transaction.
Signed-off-by: Jan Kara [EMAIL PROTECTED]
Cc: Chuck Ebbert [EMAIL PROTECTED]
Cc: Kirill Korotaev [EMAIL PROTECTED]
Cc: linux-ext4@vger.kernel.org
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
Signed-off-by: Greg Kroah-Hartman [EMAIL PROTECTED]
---
fs/jbd2/commit.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/fs/jbd2/commit.c
+++ b/fs/jbd2/commit.c
@@ -896,7 +896,8 @@ restart_loop:
journal-j_committing_transaction = NULL;
spin_unlock(journal-j_state_lock);
- if (commit_transaction-t_checkpoint_list == NULL) {
+ if (commit_transaction-t_checkpoint_list == NULL
+ commit_transaction-t_checkpoint_io_list == NULL) {
__jbd2_journal_drop_transaction(journal, commit_transaction);
} else {
if (journal-j_checkpoint_transactions == NULL) {
--
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH][e2fsprogs] Move ext2fs_struct_generic_bitmap back into ext2fs.h
From: Jose R. Santos [EMAIL PROTECTED]
Move ext2fs_struct_generic_bitmap back into ext2fs.h
In Commit: f1f115a78f5ea599fc5f8815a741d43fedd5840d
The ext2fs_struct_generic_bitmap structure is remove from ext2fs.h and
put into gen_bitmap.c. This breaks big endian compiles since swapfs.c
uses this structure as well if EXT2_BIG_ENDIAN_BITMAPS is defined.
Since we have multiple users, this patch move
ext2fs_struct_generic_bitmap back into ext2fs.h in order to compile on
PowerPC or other big endian archs.
Signed-off-by: Jose R. Santos [EMAIL PROTECTED]
--
lib/ext2fs/ext2fs.h | 11 +++
lib/ext2fs/gen_bitmap.c | 11 ---
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/lib/ext2fs/ext2fs.h b/lib/ext2fs/ext2fs.h
index d1cda2f..f34d2f9 100644
--- a/lib/ext2fs/ext2fs.h
+++ b/lib/ext2fs/ext2fs.h
@@ -100,6 +100,17 @@ typedef __u32 ext2_dirhash_t;
typedef struct struct_ext2_filsys *ext2_filsys;
+struct ext2fs_struct_generic_bitmap {
+ errcode_t magic;
+ ext2_filsys fs;
+ __u32 start, end;
+ __u32 real_end;
+ char* description;
+ char* bitmap;
+ errcode_t base_error_code;
+ __u32 reserved[7];
+};
+
#define EXT2FS_MARK_ERROR 0
#define EXT2FS_UNMARK_ERROR1
#define EXT2FS_TEST_ERROR 2
diff --git a/lib/ext2fs/gen_bitmap.c b/lib/ext2fs/gen_bitmap.c
index 66172e5..3d01149 100644
--- a/lib/ext2fs/gen_bitmap.c
+++ b/lib/ext2fs/gen_bitmap.c
@@ -27,17 +27,6 @@
#include ext2_fs.h
#include ext2fs.h
-struct ext2fs_struct_generic_bitmap {
- errcode_t magic;
- ext2_filsys fs;
- __u32 start, end;
- __u32 real_end;
- char* description;
- char* bitmap;
- errcode_t base_error_code;
- __u32 reserved[7];
-};
-
/*
* Used by previously inlined function, so we have to export this and
* not change the function signature
-
To unsubscribe from this list: send the line unsubscribe linux-ext4 in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/25] move handling of setuid/gid bits from VFS into individual setattr functions (RESEND)
On Tue, 7 Aug 2007 21:49:09 +0100 Christoph Hellwig [EMAIL PROTECTED] wrote: First thanks a lot for doing this work, it's been long needed. Second please don't send out that many patches. We encourage people to split things into small patches when the changes are logially separated. Which these are not - it's a flag day change (which btw is fine despite the rants soe people spewed in reply to this), so it should be one single patch. (Or one for all mainline filesystems + one per fs only in -mm to make Andrew's life a little easier if you really care.) Thanks. I debated about how best to split these up. A coworker mentioned that Andrew had tossed him back a single patch that touched several mainline filesystems and asked him to break it up. I took that to mean that the patches should generally be split out, but I guess I took that too far ;-) -- Jeff Layton [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/25] VFS: move attr_kill logic from notify_change into helper function
On Tue, 7 Aug 2007 21:51:49 +0100 Christoph Hellwig [EMAIL PROTECTED] wrote: +void attr_kill_to_mode(struct inode *inode, struct iattr *attr) This function badly needs a kerneldoc description. Also I can't say I like the name a lot, but without a clearly better idea I should probably not complain :) Thanks for the comments. I'm not thrilled with the name either, but kill_suid and *remove_suid were already taken, and I really didn't want to name this something too similar since there are already so many similarly named functions that don't do the same thing. I'm definitely open to suggestions for something different. We should at least add a generic_ prefix to indicate it's a generic helper valid for most filesystem (and the kerneldoc comment can explain the details) Both good suggestions. I'll plan to incorporate them in the next respin of the set. Thanks, -- Jeff Layton [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/25] move handling of setuid/gid bits from VFS into individual setattr functions (RESEND)
On Mon, 6 Aug 2007 09:54:03 -0400 Jeff Layton [EMAIL PROTECTED] wrote: Apologies for the resend, but the original sending had the date in the email header and it caused some of these to bounce... ( Please consider trimming the Cc list if discussing some aspect of this that doesn't concern everyone.) 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 in particular but most likely others), the client machine may not have credentials that allow for the clearing of these bits. In some situations, this can lead to file corruption, or to an operation failing outright because the setattr fails. 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 nfs_setattr is called, the VFS has already reinterpreted the ATTR_KILL_* bits into a mode change. We can't fix this in the filesystems where this is a problem, as doing so would leave us having to second-guess what the VFS wants us to do. So we need to change it so that filesystems have more flexibility in how to interpret the ATTR_KILL_* bits. The first patch in the following patchset moves this logic into a helper function, and then only calls this helper function for inodes that do not have a setattr operation defined. The subsequent patches fix up individual filesystem setattr functions to call this helper function. The upshot of this is that with this change, filesystems that define a setattr inode operation are now responsible for handling the ATTR_KILL bits as well. They can trivially do so by calling the helper, but they must do so. Some of the follow-on patches may not be strictly necessary, but I decided that it was better to take the conservative approach and call the helper when I wasn't sure. I've tried to CC the maintainers for the individual filesystems as well where I could find them, please let me know if there are others who should be informed. Comments and suggestions appreciated... From a purely practical standpoint: it's a concern that all filesytems need patching to continue to correctly function after this change. There might be filesystems which you missed, and there are out-of-tree filesystems which won't be updated. And I think the impact upon the out-of-tree filesystems would be fairly severe: they quietly and subtly get their secutiry guarantees broken (I think?) Is there any way in which we can prevent these problems? Say - rename something so that unconverted filesystems will reliably fail to compile? - leave existing filesystems alone, but add a new inode_operations.setattr_jeff, which the networked filesytems can implement, and teach core vfs to call setattr_jeff in preference to setattr? Something else? - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/25] move handling of setuid/gid bits from VFS into individual setattr functions (RESEND)
On Tue, 2007-08-07 at 17:15 -0700, Andrew Morton wrote: Is there any way in which we can prevent these problems? Say The problem here is that we occasionally DO need to add new flags, and yes, they MAY be security related. The whole reason why we're now having to change the semantics of setattr is because somebody tried to hack their way around the write+suid issue. I suspect we will see the exact same thing will happen again in a couple of years with Serge's ATTR_KILL_PRIV flag. - rename something so that unconverted filesystems will reliably fail to compile? - leave existing filesystems alone, but add a new inode_operations.setattr_jeff, which the networked filesytems can implement, and teach core vfs to call setattr_jeff in preference to setattr? If you really need to know that the filesystem is handling the flags, then how about instead having -setattr() return something which indicates which flags it actually handled? That is likely to be a far more intrusive change, but it is one which is future-proof. Trond - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/25] move handling of setuid/gid bits from VFS into individual setattr functions (RESEND)
On Tue, 07 Aug 2007 20:45:34 -0400 Trond Myklebust [EMAIL PROTECTED] wrote: - rename something so that unconverted filesystems will reliably fail to compile? - leave existing filesystems alone, but add a new inode_operations.setattr_jeff, which the networked filesytems can implement, and teach core vfs to call setattr_jeff in preference to setattr? If you really need to know that the filesystem is handling the flags, then how about instead having -setattr() return something which indicates which flags it actually handled? That is likely to be a far more intrusive change, but it is one which is future-proof. If we change -setattr so that it will return a positive, non-zero value which the caller can then check and reliably do printk(that filesystem needs updating) then that addresses my concern, sure. - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
