From: Tao Ma <[email protected]>
In commit 353eb83c we removes i_state_flags with 64-bit longs,
But in case we call EXT4_IOC_SETFLAGS, we fail to save the
high 32-bit state flags and only stores the low 32-bit back
to ei->i_flags. So the state flags are missing now in 64-bit
long architecture.
Cc: "Theodore Ts'o" <[email protected]>
Cc: stable <[email protected]>
Signed-off-by: Tao Ma <[email protected]>
---
fs/ext4/ext4.h | 21 +++++++++++++++++++++
fs/ext4/ioctl.c | 3 +++
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index ebec24a..855ddba 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -1345,6 +1345,16 @@ static inline void ext4_clear_state_flags(struct ext4_inode_info *ei)
{
(ei)->i_state_flags = 0;
}
+
+static inline unsigned long ext4_save_state_flags(struct ext4_inode_info *ei)
+{
+ return (ei)->i_state_flags;
+}
+
+static inline void ext4_restore_state_flags(struct ext4_inode_info *ei,
+ unsigned long state)
+{
+}
#else
EXT4_INODE_BIT_FNS(state, flags, 32)
@@ -1352,6 +1362,17 @@ static inline void ext4_clear_state_flags(struct ext4_inode_info *ei)
{
/* We depend on the fact that callers will set i_flags */
}
+
+static inline unsigned long ext4_save_state_flags(struct ext4_inode_info *ei)
+{
+ return (ei)->i_flags >> 32;
+}
+
+static inline void ext4_restore_state_flags(struct ext4_inode_info *ei,
+ unsigned long state)
+{
+ (ei)->i_flags |= state << 32;
+}
#endif
#else
/* Assume that user mode programs are passing in an ext4fs superblock, not
diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
index 6eee255..a2cc254 100644
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@ -40,6 +40,7 @@ long ext4_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
struct ext4_iloc iloc;
unsigned int oldflags;
unsigned int jflag;
+ unsigned long state_flags;
if (!inode_owner_or_capable(inode))
return -EACCES;
@@ -60,6 +61,7 @@ long ext4_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
goto flags_out;
oldflags = ei->i_flags;
+ state_flags = ext4_save_state_flags(ei);
/* The JOURNAL_DATA flag is modifiable only by root */
jflag = flags & EXT4_JOURNAL_DATA_FL;
@@ -118,6 +120,7 @@ long ext4_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
flags = flags & EXT4_FL_USER_MODIFIABLE;
flags |= oldflags & ~EXT4_FL_USER_MODIFIABLE;
ei->i_flags = flags;
+ ext4_restore_state_flags(ei, state_flags);
ext4_set_inode_flags(inode);
inode->i_ctime = ext4_current_time(inode);
--
1.7.1
On 05/04/2012 11:37 PM, Tao Ma wrote:
> From: Tao Ma <[email protected]>
>
> In commit 353eb83c we removes i_state_flags with 64-bit longs,
> But in case we call EXT4_IOC_SETFLAGS, we fail to save the
> high 32-bit state flags and only stores the low 32-bit back
> to ei->i_flags. So the state flags are missing now in 64-bit
> long architecture.
>
> Cc: "Theodore Ts'o" <[email protected]>
> Cc: stable <[email protected]>
> Signed-off-by: Tao Ma <[email protected]>
ping?
> ---
> fs/ext4/ext4.h | 21 +++++++++++++++++++++
> fs/ext4/ioctl.c | 3 +++
> 2 files changed, 24 insertions(+), 0 deletions(-)
>
> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> index ebec24a..855ddba 100644
> --- a/fs/ext4/ext4.h
> +++ b/fs/ext4/ext4.h
> @@ -1345,6 +1345,16 @@ static inline void ext4_clear_state_flags(struct ext4_inode_info *ei)
> {
> (ei)->i_state_flags = 0;
> }
> +
> +static inline unsigned long ext4_save_state_flags(struct ext4_inode_info *ei)
> +{
> + return (ei)->i_state_flags;
> +}
> +
> +static inline void ext4_restore_state_flags(struct ext4_inode_info *ei,
> + unsigned long state)
> +{
> +}
> #else
> EXT4_INODE_BIT_FNS(state, flags, 32)
>
> @@ -1352,6 +1362,17 @@ static inline void ext4_clear_state_flags(struct ext4_inode_info *ei)
> {
> /* We depend on the fact that callers will set i_flags */
> }
> +
> +static inline unsigned long ext4_save_state_flags(struct ext4_inode_info *ei)
> +{
> + return (ei)->i_flags >> 32;
> +}
> +
> +static inline void ext4_restore_state_flags(struct ext4_inode_info *ei,
> + unsigned long state)
> +{
> + (ei)->i_flags |= state << 32;
> +}
> #endif
> #else
> /* Assume that user mode programs are passing in an ext4fs superblock, not
> diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
> index 6eee255..a2cc254 100644
> --- a/fs/ext4/ioctl.c
> +++ b/fs/ext4/ioctl.c
> @@ -40,6 +40,7 @@ long ext4_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
> struct ext4_iloc iloc;
> unsigned int oldflags;
> unsigned int jflag;
> + unsigned long state_flags;
>
> if (!inode_owner_or_capable(inode))
> return -EACCES;
> @@ -60,6 +61,7 @@ long ext4_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
> goto flags_out;
>
> oldflags = ei->i_flags;
> + state_flags = ext4_save_state_flags(ei);
>
> /* The JOURNAL_DATA flag is modifiable only by root */
> jflag = flags & EXT4_JOURNAL_DATA_FL;
> @@ -118,6 +120,7 @@ long ext4_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
> flags = flags & EXT4_FL_USER_MODIFIABLE;
> flags |= oldflags & ~EXT4_FL_USER_MODIFIABLE;
> ei->i_flags = flags;
> + ext4_restore_state_flags(ei, state_flags);
>
> ext4_set_inode_flags(inode);
> inode->i_ctime = ext4_current_time(inode);
On Fri, May 04, 2012 at 11:37:49PM +0800, Tao Ma wrote:
> From: Tao Ma <[email protected]>
>
> In commit 353eb83c we removes i_state_flags with 64-bit longs,
> But in case we call EXT4_IOC_SETFLAGS, we fail to save the
> high 32-bit state flags and only stores the low 32-bit back
> to ei->i_flags. So the state flags are missing now in 64-bit
> long architecture.
The problem with this approach is that we are still editing i_flags
and then replacing it with the new value. So we're vulnerable to
races where some other process is modifies the i_state_flags between
when we sample it using ext4_save_state_flags() and when we restore
them.
This is a better way to fix the problem, and what I plan to commit
into the ext4 tree:
commit 79906964a187c405db72a3abc60eb9b50d804fbc
Author: Theodore Ts'o <[email protected]>
Date: Thu May 31 23:46:01 2012 -0400
ext4: don't trash state flags in EXT4_IOC_SETFLAGS
In commit 353eb83c we removed i_state_flags with 64-bit longs, But
when handling the EXT4_IOC_SETFLAGS ioctl, we replace i_flags
directly, which trashes the state flags which are stored in the high
32-bits of i_flags on 64-bit platforms. So use the the
ext4_{set,clear}_inode_flags() functions which use atomic bit
manipulation functions instead.
Reported-by: Tao Ma <[email protected]>
Signed-off-by: "Theodore Ts'o" <[email protected]>
Cc: [email protected]
diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
index feba55a..8ad112a 100644
--- a/fs/ext4/ioctl.c
+++ b/fs/ext4/ioctl.c
@@ -38,7 +38,7 @@ long ext4_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
handle_t *handle = NULL;
int err, migrate = 0;
struct ext4_iloc iloc;
- unsigned int oldflags;
+ unsigned int oldflags, mask, i;
unsigned int jflag;
if (!inode_owner_or_capable(inode))
@@ -115,8 +115,14 @@ long ext4_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
if (err)
goto flags_err;
- flags = flags & EXT4_FL_USER_MODIFIABLE;
- flags |= oldflags & ~EXT4_FL_USER_MODIFIABLE;
+ for (i = 0, mask = 1; i < 32; i++, mask <<= 1) {
+ if (!(mask & EXT4_FL_USER_MODIFIABLE))
+ continue;
+ if (mask & flags)
+ ext4_set_inode_flag(inode, i);
+ else
+ ext4_clear_inode_flag(inode, i);
+ }
ei->i_flags = flags;
ext4_set_inode_flags(inode);
Hi Ted,
Sorry for the delay.
On 06/01/2012 11:48 AM, Ted Ts'o wrote:
> On Fri, May 04, 2012 at 11:37:49PM +0800, Tao Ma wrote:
>> From: Tao Ma <[email protected]>
>>
>> In commit 353eb83c we removes i_state_flags with 64-bit longs,
>> But in case we call EXT4_IOC_SETFLAGS, we fail to save the
>> high 32-bit state flags and only stores the low 32-bit back
>> to ei->i_flags. So the state flags are missing now in 64-bit
>> long architecture.
>
> The problem with this approach is that we are still editing i_flags
> and then replacing it with the new value. So we're vulnerable to
> races where some other process is modifies the i_state_flags between
> when we sample it using ext4_save_state_flags() and when we restore
> them.
>
> This is a better way to fix the problem, and what I plan to commit
> into the ext4 tree:
>
> commit 79906964a187c405db72a3abc60eb9b50d804fbc
> Author: Theodore Ts'o <[email protected]>
> Date: Thu May 31 23:46:01 2012 -0400
>
> ext4: don't trash state flags in EXT4_IOC_SETFLAGS
>
> In commit 353eb83c we removed i_state_flags with 64-bit longs, But
> when handling the EXT4_IOC_SETFLAGS ioctl, we replace i_flags
> directly, which trashes the state flags which are stored in the high
> 32-bits of i_flags on 64-bit platforms. So use the the
> ext4_{set,clear}_inode_flags() functions which use atomic bit
> manipulation functions instead.
>
> Reported-by: Tao Ma <[email protected]>
> Signed-off-by: "Theodore Ts'o" <[email protected]>
> Cc: [email protected]
>
> diff --git a/fs/ext4/ioctl.c b/fs/ext4/ioctl.c
> index feba55a..8ad112a 100644
> --- a/fs/ext4/ioctl.c
> +++ b/fs/ext4/ioctl.c
> @@ -38,7 +38,7 @@ long ext4_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
> handle_t *handle = NULL;
> int err, migrate = 0;
> struct ext4_iloc iloc;
> - unsigned int oldflags;
> + unsigned int oldflags, mask, i;
> unsigned int jflag;
>
> if (!inode_owner_or_capable(inode))
> @@ -115,8 +115,14 @@ long ext4_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
> if (err)
> goto flags_err;
>
> - flags = flags & EXT4_FL_USER_MODIFIABLE;
> - flags |= oldflags & ~EXT4_FL_USER_MODIFIABLE;
> + for (i = 0, mask = 1; i < 32; i++, mask <<= 1) {
> + if (!(mask & EXT4_FL_USER_MODIFIABLE))
> + continue;
> + if (mask & flags)
> + ext4_set_inode_flag(inode, i);
> + else
> + ext4_clear_inode_flag(inode, i);
> + }
> ei->i_flags = flags;
You forget to remove this line and we can still get the problem.
I am busy with other stuff and when I got to it, it is already in linus'
tree. So I have sent out another patch to remove this line and after
that my test case passed. The patch subject is "[PATCH] ext4: Don't set
i_flags in EXT4_IOC_SETFLAGS."
Thanks
Tao
>
> ext4_set_inode_flags(inode);
>
>
> --
> 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