Re: [PATCH v2 0/3] File Sealing & memfd_create()

[Jan Kara]

On Mon 02-06-14 13:42:59, Minchan Kim wrote:
> Hello,
> 
> On Mon, May 19, 2014 at 01:44:25PM +0200, David Herrmann wrote:
> > Hi
> > 
> > On Thu, May 15, 2014 at 12:35 AM, Hugh Dickins <hughd@xxxxxxxxxx> wrote:
> > > The aspect which really worries me is this: the maintenance burden.
> > > This approach would add some peculiar new code, introducing a rare
> > > special case: which we might get right today, but will very easily
> > > forget tomorrow when making some other changes to mm.  If we compile
> > > a list of danger areas in mm, this would surely belong on that list.
> > 
> > I tried doing the page-replacement in the last 4 days, but honestly,
> > it's far more complex than I thought. So if no-one more experienced
> > with mm/ comes up with a simple implementation, I'll have to delay
> > this for some more weeks.
> > 
> > However, I still wonder why we try to fix this as part of this
> > patchset. Using FUSE, a DIRECT-IO call can be delayed for an arbitrary
> > amount of time. Same is true for network block-devices, NFS, iscsi,
> > maybe loop-devices, ... This means, _any_ once mapped page can be
> > written to after an arbitrary delay. This can break any feature that
> > makes FS objects read-only (remounting read-only, setting S_IMMUTABLE,
> > sealing, ..).
> > 
> > Shouldn't we try to fix the _cause_ of this?
> 
> I didn't follow this patchset and couldn't find what's your most cocern
> but at a first glance, it seems you have troubled with pinned page.
> If so, it's really big problem for CMA and I think peterz's approach(ie,
> mm_mpin) is really make sense to me.
  Well, his concern are pinned pages (and also pages used for direct IO and
similar) but not because they are pinned but because they can be modified
while someone holds reference to them. So I'm not sure Peter's patches will
help here.
 
> https://lkml.org/lkml/2014/5/26/340

								Honza
-- 
Jan Kara <jack@xxxxxxx>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/