On Tue, Nov 20, 2018 at 01:33:18PM -0700, Andy Lutomirski wrote: > > > On Nov 20, 2018, at 1:07 PM, Stephen Rothwell <s...@canb.auug.org.au> wrote: > > > > Hi Joel, > > > >> On Tue, 20 Nov 2018 10:39:26 -0800 Joel Fernandes <j...@joelfernandes.org> > >> wrote: > >> > >>> On Tue, Nov 20, 2018 at 07:13:17AM -0800, Andy Lutomirski wrote: > >>> On Mon, Nov 19, 2018 at 9:21 PM Joel Fernandes (Google) > >>> <j...@joelfernandes.org> wrote: > >>>> > >>>> A better way to do F_SEAL_FUTURE_WRITE seal was discussed [1] last week > >>>> where we don't need to modify core VFS structures to get the same > >>>> behavior of the seal. This solves several side-effects pointed out by > >>>> Andy [2]. > >>>> > >>>> [1] https://lore.kernel.org/lkml/20181111173650.ga256...@google.com/ > >>>> [2] > >>>> https://lore.kernel.org/lkml/69ce06cc-e47c-4992-848a-66eb23ee6...@amacapital.net/ > >>>> > >>>> Suggested-by: Andy Lutomirski <l...@kernel.org> > >>>> Fixes: 5e653c2923fd ("mm: Add an F_SEAL_FUTURE_WRITE seal to memfd") > >>> > >>> What tree is that commit in? Can we not just fold this in? > >> > >> It is in linux-next. Could we keep both commits so we have the history? > > > > Well, its in Andrew's mmotm, so its up to him. > > > > > > Unless mmotm is more magical than I think, the commit hash in your fixed > tag is already nonsense. mmotm gets rebased all the time, and is only > barely a git tree.
I wouldn't go so far to call it nonsense. It was a working patch, it just did things differently. Your help with improving the patch is much appreciated. I am Ok with whatever Andrew wants to do, if it is better to squash it with the original, then I can do that and send another patch. - Joel
