public inbox for linux-unionfs@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/2] ovl: constant d_ino across copy up
@ 2017-05-11 13:42 Amir Goldstein
  2017-05-11 13:42 ` [PATCH 1/2] ovl: mark upper dir with type origin entries "impure" Amir Goldstein
  2017-05-11 13:42 ` [PATCH 2/2] ovl: constant d_ino across copy up Amir Goldstein
  0 siblings, 2 replies; 12+ messages in thread
From: Amir Goldstein @ 2017-05-11 13:42 UTC (permalink / raw)
  To: Miklos Szeredi; +Cc: Vivek Goyal, linux-unionfs

Miklos,

Following patches fix constant d_ino.
I've tested them with the improved xfstest overlay/017.

Fixing constat d_ino for this merge cycle is not urgent,
although you may consider the patch simple enough to be
a candidate for rc2.

However, I do recommend that you consider the "impure"
dir patch for this merge cycle. If you include it, it will
guaranty the on-disk rule:
A) An upper directory that contains entries with valid
   "origin" is either "merge" or marked "impure"

If you don't include it in the same merge window as constant
st_ino, then we will need to deal with violations of this rule.
OTOH, we already do need to deal with the situation of:
B) Non-merge upper directory that contains dir entries with
   "redirect" that is not marked "impure"

Assuming that we will not want to give up on the "impure"
optimization for ovl_iterate(), then dealing with B) is quite
simple - let old redirected dirs have d_ino != st_ino.
'find -ino' never looks at d_ino of subdirs and I don't know
which programs do care about it. Also, d_ino != st_ino for
subdirs also in past kernels, so it won't be a regression.

Dealing with A) (if "impure" doesn't go into 4.12) will be
more challenging, because it will allow the following combinations:
- non constant st_ino, which is consistent with d_ino (<= v4.11)
- constant st_ino, which is consistent with d_ino (>= v4.13)
- constant st_ino, which is sometimes consistent with d_ino
  (depending on whether the file was moved with kernel v4.12 or v4.13)

Thoughts?

Amir Goldstein (2):
  ovl: mark upper dir with type origin entries "impure"
  ovl: constant d_ino across copy up

 fs/overlayfs/dir.c       |  41 ++++++++++++++++-
 fs/overlayfs/namei.c     |  25 +++++++++--
 fs/overlayfs/overlayfs.h |   5 ++-
 fs/overlayfs/ovl_entry.h |   1 +
 fs/overlayfs/readdir.c   | 115 ++++++++++++++++++++++++++++++++++++++++++++---
 fs/overlayfs/util.c      |  15 +++++++
 6 files changed, 189 insertions(+), 13 deletions(-)

-- 
2.7.4

^ permalink raw reply	[flat|nested] 12+ messages in thread
* Re: [PATCH 2/2] ovl: constant d_ino across copy up
@ 2017-05-19 13:37 Miklos Szeredi
  2017-05-23 22:40 ` Amir Goldstein
  2017-05-23 22:40 ` Amir Goldstein
  0 siblings, 2 replies; 12+ messages in thread
From: Miklos Szeredi @ 2017-05-19 13:37 UTC (permalink / raw)
  To: Amir Goldstein; +Cc: Vivek Goyal, open list:OVERLAY FILESYSTEM

On Fri, May 19, 2017 at 3:09 PM, Amir Goldstein <amir73il@gmail.com> wrote:
> On Fri, May 19, 2017 at 3:22 PM, Miklos Szeredi <miklos@szeredi.hu> wrote:

> Right, so perhaps mounter's creds isn't the right choice.
> What we need is to install new credentials with elevated permissions
> for lookup. Can we do that?
>
> But looking at this from another perspective, if user can readdir,
> but cannot lookup inside it, then user cannot stat the files listed by
> readdir and therefore user cannot observe the st_ino/d_ino
> inconsistency due to lookup failure. If we say that we don't really
> care about this corner case, then we silently ignore -EACCESS
> and report the upper d_ino.
>
> But I am mostly debating this for the sake of debating. If you prefer
> to do this "by hand" because it's the "right thing to do", that seems
> like a good enough reason to me. As I wrote, this reeks of a layer
> violation that may come back to bite us in the future,  even if right now,
> we cannot figure out why.

Well, even if we go by the route of looking up the overlay dentry, we
shoudn't be hacking around the permission checks (yeah, overlayfs
started out doing that, because I didn't know better at the time).
Instead we can export __lookup_hash() and use that.

But I simply don't know which route is better.  There's a tradeoff
between memory use and performance, but all depends on usage patterns.
Probably doesn't matter much, so just choose the one which you feel
better about.

Thanks,
Miklos


Thanks,
Miklos

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2017-05-23 22:40 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-05-11 13:42 [PATCH 0/2] ovl: constant d_ino across copy up Amir Goldstein
2017-05-11 13:42 ` [PATCH 1/2] ovl: mark upper dir with type origin entries "impure" Amir Goldstein
2017-05-16  9:29   ` Miklos Szeredi
2017-05-11 13:42 ` [PATCH 2/2] ovl: constant d_ino across copy up Amir Goldstein
2017-05-13 14:25   ` Amir Goldstein
2017-05-19  9:35     ` Miklos Szeredi
2017-05-19 11:34       ` Amir Goldstein
2017-05-19 12:22         ` Miklos Szeredi
2017-05-19 13:09           ` Amir Goldstein
  -- strict thread matches above, loose matches on Subject: below --
2017-05-19 13:37 Miklos Szeredi
2017-05-23 22:40 ` Amir Goldstein
2017-05-23 22:40 ` Amir Goldstein

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox