All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: Koen Vandeputte <koen.vandeputte@ncentric.com>
Cc: OpenWrt Development List <openwrt-devel@lists.openwrt.org>,
	linux-mtd@lists.infradead.org
Subject: Re: UBIFS issues within kernel 4.14.69?
Date: Sun, 16 Sep 2018 21:39:22 +0200	[thread overview]
Message-ID: <1680286.R2LEE90rvs@blindfold> (raw)
In-Reply-To: <18519120.7jNkZpEG5c@blindfold>

Koen,

Am Samstag, 15. September 2018, 09:13:09 CEST schrieb Richard Weinberger:
> Koen,
> 
> Am Dienstag, 11. September 2018, 16:26:34 CEST schrieb Koen Vandeputte:
> > 
> > On 2018-09-11 15:46, Koen Vandeputte wrote:
> > > Hi Richard,
> > ...
> > 
> > > I'm only seeing these issues on UBIFS enabled volumes.
> > >
> > > It seems it's related to one of your 5 commits, but I'm still in the 
> > > process of bisecting to find the actual culprit.
> > > As soon as I've found it, I'll let you know, but maybe you already 
> > > have an idea here?
> > >
> > Reverting ("ubifs: xattr: Don't operate on deleted inodes") fixes the 
> > weird issues.
> 
> Thanks for finding that bad commit!
> I fear by fixing one bug I've uncovered another one.
> 
> So, I guess you are using overlayfs?
> Which overlayfs features are you using?

I guess I've figured myself.
overlayfs is using temp files (O_TMPFILE), and a recent overlayfs
feature uses xattrs to indicate directory redirects.
So it can happen that a temp file, which has link count 0, gains
xattrs.

UBIFS models xattrs like regular files in directories. Since you cannot
add new files to a unlinked directory, UBIFS kind of enforced that for
xattrs too.
I say "kind of" because technically it works but can trigger an assertion
in UBIFS's journal code.
Recently I saw this assertion but failed to conclude that xattr operations on
unlinked files are perfectly fine and "fixed" the assert.

The right solution is reverting "ubifs: xattr: Don't operate on deleted inodes"
and removing the false positive asserts from UBIFS' journal code.

Sadly xfstests does not test for that, I'll prepare a new test case.
Maybe other file systems got this wrong too.

Thanks,
//richard

  reply	other threads:[~2018-09-16 19:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <d3f55a2a-dd98-1bc6-272a-9a7b9a318b76@ncentric.com>
     [not found] ` <daa753bf-8572-f2d4-847a-e7a87e49333d@ncentric.com>
2018-09-15  7:13   ` UBIFS issues within kernel 4.14.69? Richard Weinberger
2018-09-16 19:39     ` Richard Weinberger [this message]
2018-09-16 20:11       ` Koen Vandeputte
2018-09-16 21:58         ` Richard Weinberger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1680286.R2LEE90rvs@blindfold \
    --to=richard@nod.at \
    --cc=koen.vandeputte@ncentric.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=openwrt-devel@lists.openwrt.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.