lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 25 Aug 2014 15:52:26 +0900 From: Namjae Jeon <namjae.jeon@...sung.com> To: 'Brian Foster' <bfoster@...hat.com> Cc: 'Dave Chinner' <david@...morbit.com>, 'Theodore Ts'o' <tytso@....edu>, linux-kernel@...r.kernel.org, xfs@....sgi.com, linux-fsdevel@...r.kernel.org, 'Lukáš Czerner' <lczerner@...hat.com>, 'linux-ext4' <linux-ext4@...r.kernel.org> Subject: RE: [PATCH v5 2/10] xfs: Add support FALLOC_FL_INSERT_RANGE for fallocate > Hi Namjae, Hi Brian. Thanks for your mail :) > > Sorry for finding things so late, but it looks like this suffers from > the same couple bugs we've recently discovered with the collapse range > patches. See the following for a couple fixes that have been proposed > recently: > > http://oss.sgi.com/archives/xfs/2014-08/msg00292.html > > This one helps prevent scenarios where we try to cancel a transaction > that is dirty. This leads to a shutdown on XFS. The idea is basically to > avoid logging until we actually make a change, so errors hit early in > the function (before we change anything) won't lead to an abort in the > error path. It looks like the bmap split and shift functions in this > patch could use the very same attention. Okay, I will add this commit to insert range patch. > > http://oss.sgi.com/archives/xfs/2014-08/index.html > > This one deals with a problem with the high level shift algorithm. The > problem with the algorithm here is that 'current_ext' can change > unexpectedly once we release the ilock due to writeback on parts of the > file before the range being collapsed/inserted. E.g., it is not a stable > index once ilock is dropped. The temporary solution is to flush the > entire file, since we have the iolock during the entire operation and > nothing else can dirty the file. The better fix is to track via an > offset across iterations of the shift, rather than the extent count > (iirc, xfs_bunmapi() and other bmap functions provide examples of this > kind of algorithm). Okay, I will check your points. > > Brian > > P.S., It's probably a good idea to remove my r-b tag on the next post as > well to avoid confusion and remind me that I need to take another look > at this. ;) Thanks again. Okay, I will remove it. Thanks Brian! > > > -- > > 1.7.11-rc0 > > > > _______________________________________________ > > xfs mailing list > > xfs@....sgi.com > > http://oss.sgi.com/mailman/listinfo/xfs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists