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, 24 Feb 2014 10:12:34 +0900 From: Namjae Jeon <linkinjeon@...il.com> To: Dave Chinner <david@...morbit.com> Cc: viro@...iv.linux.org.uk, bpm@....com, tytso@....edu, adilger.kernel@...ger.ca, jack@...e.cz, mtk.manpages@...il.com, lczerner@...hat.com, linux-fsdevel@...r.kernel.org, xfs@....sgi.com, linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org, Namjae Jeon <namjae.jeon@...sung.com>, Ashish Sangwan <a.sangwan@...sung.com> Subject: Re: [PATCH v5 2/10] xfs: Add support FALLOC_FL_COLLAPSE_RANGE for fallocate 2014-02-24 6:22 GMT+09:00, Dave Chinner <david@...morbit.com>: > On Wed, Feb 19, 2014 at 01:37:55AM +0900, Namjae Jeon wrote: >> From: Namjae Jeon <namjae.jeon@...sung.com> >> >> This patch implements fallocate's FALLOC_FL_COLLAPSE_RANGE for XFS. >> >> The semantics of this flag are following: >> 1) It collapses the range lying between offset and length by removing any >> data >> blocks which are present in this range and than updates all the >> logical >> offsets of extents beyond "offset + len" to nullify the hole created >> by >> removing blocks. In short, it does not leave a hole. >> 2) It should be used exclusively. No other fallocate flag in combination. >> 3) Offset and length supplied to fallocate should be fs block size >> aligned >> in case of xfs and ext4. >> 4) Collaspe range does not work beyond i_size. >> >> Signed-off-by: Namjae Jeon <namjae.jeon@...sung.com> >> Signed-off-by: Ashish Sangwan <a.sangwan@...sung.com> > ..... >> + while (!error && !done) { >> + tp = xfs_trans_alloc(mp, XFS_TRANS_DIOSTRAT); >> + tp->t_flags |= XFS_TRANS_RESERVE; > Hi Dave. > This probably shouldn't use XFS_TRANS_RESERVE. If we are at ENOSPC, > then the operation simply fails. Yes, we've already punched the > hole, so we shouldn't get ENOSPC here, but I don't think it's worth > dipping into the reserve pool as it has much more important uses... Okay. > > You don' tneed to resent the entire patch for this - I can remove it > directly myself.... Thanks very much for your help!! > > Otherwise it looks good, so consider it > > Reviewed-by: Dave Chinner <dchinner@...hat.com> > > Cheers, > > Dave. > -- > Dave Chinner > david@...morbit.com > -- 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