[opensuse-kernel] XFS/ext4 temporary data corruption and possible fix
Hi,
XFS and ext4 in 11.3 are vulnerable to a possible temporary data
corruption when using aio+dio (basically there is a window in which
zeros are read back from a file even though AIO write to that location
is already reported as completed). The fix is already available upstream
but it changes prototype of ->end_io callback and thus it changes KABI.
It's impossible to fix the problem without changing the ->end_io callback
(more information has to be passed into the callback).
For SLES 11 SP1, we'll have a terrible hack so that KABI is preserved
but what should we do for 11.3? Do we take KABI issues there seriously
enough that it warranties doing the same hack or can we afford to change
the KABI?
Honza
--
Jan Kara
On Wed, Aug 04, 2010 at 04:36:26PM +0200, Jan Kara wrote:
Hi,
XFS and ext4 in 11.3 are vulnerable to a possible temporary data corruption when using aio+dio (basically there is a window in which zeros are read back from a file even though AIO write to that location is already reported as completed). The fix is already available upstream but it changes prototype of ->end_io callback and thus it changes KABI. It's impossible to fix the problem without changing the ->end_io callback (more information has to be passed into the callback). For SLES 11 SP1, we'll have a terrible hack so that KABI is preserved but what should we do for 11.3? Do we take KABI issues there seriously enough that it warranties doing the same hack or can we afford to change the KABI?
We don't care as much about KABI issues for 11.3. This sounds like a patch that should be made to the upstream .34-stable tree, right? Are you sure that it's not already there? thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Wed, Aug 04, 2010 at 04:36:26PM +0200, Jan Kara wrote:
Hi,
XFS and ext4 in 11.3 are vulnerable to a possible temporary data corruption when using aio+dio (basically there is a window in which zeros are read back from a file even though AIO write to that location is already reported as completed). The fix is already available upstream but it changes prototype of ->end_io callback and thus it changes KABI. It's impossible to fix the problem without changing the ->end_io callback (more information has to be passed into the callback). For SLES 11 SP1, we'll have a terrible hack so that KABI is preserved but what should we do for 11.3? Do we take KABI issues there seriously enough that it warranties doing the same hack or can we afford to change the KABI?
We don't care as much about KABI issues for 11.3. This sounds like a patch that should be made to the upstream .34-stable tree, right? Are you sure that it's not already there? It's not because it's not in Linus's tree yet. Only Ted Tso has it in his
On Wed 04-08-10 08:25:02, Greg KH wrote:
tree queued... After he pushes his tree to Linus I believe he will send the
fix to -stable as well.
Honza
--
Jan Kara
On Wed, Aug 04, 2010 at 06:02:14PM +0200, Jan Kara wrote:
On Wed, Aug 04, 2010 at 04:36:26PM +0200, Jan Kara wrote:
Hi,
XFS and ext4 in 11.3 are vulnerable to a possible temporary data corruption when using aio+dio (basically there is a window in which zeros are read back from a file even though AIO write to that location is already reported as completed). The fix is already available upstream but it changes prototype of ->end_io callback and thus it changes KABI. It's impossible to fix the problem without changing the ->end_io callback (more information has to be passed into the callback). For SLES 11 SP1, we'll have a terrible hack so that KABI is preserved but what should we do for 11.3? Do we take KABI issues there seriously enough that it warranties doing the same hack or can we afford to change the KABI?
We don't care as much about KABI issues for 11.3. This sounds like a patch that should be made to the upstream .34-stable tree, right? Are you sure that it's not already there? It's not because it's not in Linus's tree yet. Only Ted Tso has it in his
On Wed 04-08-10 08:25:02, Greg KH wrote: tree queued... After he pushes his tree to Linus I believe he will send the fix to -stable as well.
Ok, if not, please remind me about them. If they go that route, they will end up in the 11.3 kernel releases automatically. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Wed, 4 Aug 2010 16:36:26 +0200
Jan Kara
It's impossible to fix the problem without changing the ->end_io callback (more information has to be passed into the callback). For SLES 11 SP1, we'll have a terrible hack so that KABI is preserved but what should we do for 11.3? Do we take KABI issues there seriously enough that it warranties doing the same hack or can we afford to change the KABI?
What kind of external modules might be affected? If GFX drivers and VMware (does it still exist?) are not affected, I guess nobody will care too much for 11.3 For SLES it's of course a different issue because there are lots of 3rd party commercial filesystems etc (and I'm just guessing that they might be more affected by this change). Or is this a core change that will break every single module? (I personally don't care at all, since on my hardware I don't need any external modules) Have fun, seife -- Stefan Seyfried "Any ideas, John?" "Well, surrounding them's out." -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
On Wed 04-08-10 22:49:01, Stefan Seyfried wrote:
On Wed, 4 Aug 2010 16:36:26 +0200 Jan Kara
wrote: It's impossible to fix the problem without changing the ->end_io callback (more information has to be passed into the callback). For SLES 11 SP1, we'll have a terrible hack so that KABI is preserved but what should we do for 11.3? Do we take KABI issues there seriously enough that it warranties doing the same hack or can we afford to change the KABI?
What kind of external modules might be affected? If GFX drivers and VMware (does it still exist?) are not affected, I guess nobody will care too much for 11.3 Generally only filesystem drivers. In particular those that use direct IO and play some tricks so that they need a special handling in ->end_io callback. OK, since Ted will merge the fixes soon and post them for -stable inclusion, I think I don't have to worry then.
Honza
--
Jan Kara
participants (3)
-
Greg KH
-
Jan Kara
-
Stefan Seyfried