From: Richard Weinberger <richard@nod.at>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Christoph Hellwig <hch@infradead.org>,
Miklos Szeredi <miklos@szeredi.hu>,
Al Viro <viro@zeniv.linux.org.uk>,
linux-unionfs@vger.kernel.org,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Hugh Dickins <hughd@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Oleksij Rempel <ore@pengutronix.de>
Subject: Re: [PATCH] tmpfs: generate random sb->s_uuid
Date: Tue, 9 May 2017 12:09:21 +0200 [thread overview]
Message-ID: <0f4814d3-e13b-4fb8-151d-652ce2fed6b4@nod.at> (raw)
In-Reply-To: <CAOQ4uxjXX5nAHu0PVfM_mPi9wMtoDjf-XpBO6reMZPXQoW8mMw@mail.gmail.com>
Amir,
Am 09.05.2017 um 11:54 schrieb Amir Goldstein:
>>> There is. generate_random_uuid needs to die, and adding more callers
>>> isn't the way to go.
>
> That's Christoph's opinion and its fine. I stated my opinion above.
> It's up to tmpfs/vfs maintainers to make the call about my patch.
>
>>> Same for ubifs btw.
>
> Same in what regard?
> ubifs has generate_random_uuid() since 2008.
> When the cleanup patch to generate_random_uuid() will be ready,
> it will fixup ubifs as well.
>
>>
>> I agree. Right now UBIFS uses generate_random_uuid() in both kernel and mkfs.ubifs.
>> Before we expose it to ->s_uuid, UBIFS should use the correct UUID generation functions.
>
> Richard, this makes no sense at all.
> You have deployed filesystems whose UUID has already been set using
> generate_random_uuid(). You are not going to reformat those filesystems
> when generate_random_uuid() dies in the kernel, so how is this even related
> to exporting the filesystem's UUID to s_uuid?
Well, maybe we need a new feature flag in UBIFS that the UUID is now usable.
Sure, in the best case we just expose the existing UUID to ->s_uuid and everything
is fine.
> The changes that Christoph promotes to the kernel uuid common functions
> are important because we have too many home brewed implementations of
> uuid handling in the kernel. But making the code cleaner and more reusable
> isn't going to change the on-disk uuid representation and for filesystems, it
> probably won't even change the cpu uuid representation (i.e. in super block
> structs).
>
> Seriously, it's not my battle to fight.
> I don't stand to loose anything if Oleksij's patch gets held hostage
> for the uuid
> cleanups, but I don't get the UBIFS maintainer POV on the matter at hand.
My POV is easy, I'm nervous about all this changes and the rush behind them.
And when Christoph raises concerns, I'm especially careful.
That's why I'm taking the UBIFS ->s_uuid patch for 4.13 after I had enough
time to verify and think. And finally that's also why I asked Oleksij
to follow the discussion. If he can explain in detail why UBIFS does the right
thing I have a much better feeling. If I have to figure myself it takes time
which I don't have right now.
Thanks,
//richard
next prev parent reply other threads:[~2017-05-09 10:09 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-05 9:44 [PATCH] tmpfs: generate random sb->s_uuid Amir Goldstein
2017-05-05 10:01 ` Christoph Hellwig
2017-05-05 10:20 ` Amir Goldstein
2017-05-09 9:02 ` Christoph Hellwig
2017-05-09 9:18 ` Richard Weinberger
2017-05-09 9:54 ` Amir Goldstein
2017-05-09 10:09 ` Richard Weinberger [this message]
2017-05-09 10:27 ` Oleksij Rempel
2017-05-09 10:50 ` Amir Goldstein
2017-05-10 2:51 ` Hugh Dickins
2017-05-07 12:11 ` kbuild test robot
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=0f4814d3-e13b-4fb8-151d-652ce2fed6b4@nod.at \
--to=richard@nod.at \
--cc=akpm@linux-foundation.org \
--cc=amir73il@gmail.com \
--cc=hch@infradead.org \
--cc=hughd@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=miklos@szeredi.hu \
--cc=ore@pengutronix.de \
--cc=viro@zeniv.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox