Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Amir Goldstein]

On Tue, May 9, 2017 at 10:35 AM, Richard Weinberger  wrote:
> Amir,
>
> Am 09.05.2017 um 09:08 schrieb Amir Goldstein:
>>> Then we can queue this patch for 4.13.
>>> Please resend and make sure it addresses everything what was also
>>> suggested for the xfs s_uuid patch.
>>>
>>
>> Just to be clear, the xfs s_uuid patch is just a memcpy,
>> no different from Oleksij's patch.

See upstream commit
8f720d9 xfs: publish UUID in struct super_block


>
> Wasn't there a huge discussion about LE/BE/uniqueness and more details
> on UUID that hurt my brain.
>

LE/BE discussions are more about which variants of uuid helpers should be
created, among other things, for consumers of s_uuid to check that s_uuid
was filled by fs.
Converting s_uuid type to uuid_t or whatever is for the far future.

uniqueness of s_uuid does not exist with current filesystems,
so no reason whatsoever to act differently with ubifs.
Fixing uniqueness of s_uuid (if at all is needed) is a future VFS task.

Bottom line, for Oleksij's original patch:

Reviewed-by: Amir Goldstein 

If it's not too late for 4.12 that could be nice, because then
ubifs+overlayfs would gain a new feature (constant inode numbers)

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Amir Goldstein]

On Tue, May 9, 2017 at 10:35 AM, Richard Weinberger  wrote:
> Amir,
>
> Am 09.05.2017 um 09:08 schrieb Amir Goldstein:
>>> Then we can queue this patch for 4.13.
>>> Please resend and make sure it addresses everything what was also
>>> suggested for the xfs s_uuid patch.
>>>
>>
>> Just to be clear, the xfs s_uuid patch is just a memcpy,
>> no different from Oleksij's patch.

See upstream commit
8f720d9 xfs: publish UUID in struct super_block


>
> Wasn't there a huge discussion about LE/BE/uniqueness and more details
> on UUID that hurt my brain.
>

LE/BE discussions are more about which variants of uuid helpers should be
created, among other things, for consumers of s_uuid to check that s_uuid
was filled by fs.
Converting s_uuid type to uuid_t or whatever is for the far future.

uniqueness of s_uuid does not exist with current filesystems,
so no reason whatsoever to act differently with ubifs.
Fixing uniqueness of s_uuid (if at all is needed) is a future VFS task.

Bottom line, for Oleksij's original patch:

Reviewed-by: Amir Goldstein 

If it's not too late for 4.12 that could be nice, because then
ubifs+overlayfs would gain a new feature (constant inode numbers)

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Oleksij Rempel]

On 05/09/2017 09:08 AM, Amir Goldstein wrote:

On Tue, May 9, 2017 at 10:01 AM, Richard Weinberger  wrote:


Oleksij,

Am 09.05.2017 um 07:52 schrieb Oleksij Rempel:


If VFS maintainers are fine with that, I'll take it.
From UBIFS' POV it does not matter much. :-)


Ping to VFS maintainers?


What ping? Al made it clear that a flag is not needed.
BTW, xfs s_uuid patch was merged to master.



I'm talking about ubifs patch.


Me too.


:) ok



Then we can queue this patch for 4.13.
Please resend and make sure it addresses everything what was also
suggested for the xfs s_uuid patch.



Just to be clear, the xfs s_uuid patch is just a memcpy,
no different from Oleksij's patch.


So, should i change something?

here is the patch:
https://patchwork.kernel.org/patch/9674817/

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Oleksij Rempel]

On 05/09/2017 09:08 AM, Amir Goldstein wrote:

On Tue, May 9, 2017 at 10:01 AM, Richard Weinberger  wrote:


Oleksij,

Am 09.05.2017 um 07:52 schrieb Oleksij Rempel:


If VFS maintainers are fine with that, I'll take it.
From UBIFS' POV it does not matter much. :-)


Ping to VFS maintainers?


What ping? Al made it clear that a flag is not needed.
BTW, xfs s_uuid patch was merged to master.



I'm talking about ubifs patch.


Me too.


:) ok



Then we can queue this patch for 4.13.
Please resend and make sure it addresses everything what was also
suggested for the xfs s_uuid patch.



Just to be clear, the xfs s_uuid patch is just a memcpy,
no different from Oleksij's patch.


So, should i change something?

here is the patch:
https://patchwork.kernel.org/patch/9674817/

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Richard Weinberger]

Amir,

Am 09.05.2017 um 09:08 schrieb Amir Goldstein:
>> Then we can queue this patch for 4.13.
>> Please resend and make sure it addresses everything what was also
>> suggested for the xfs s_uuid patch.
>>
> 
> Just to be clear, the xfs s_uuid patch is just a memcpy,
> no different from Oleksij's patch.

Wasn't there a huge discussion about LE/BE/uniqueness and more details
on UUID that hurt my brain.

Thanks,
//richard

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Richard Weinberger]

Amir,

Am 09.05.2017 um 09:08 schrieb Amir Goldstein:
>> Then we can queue this patch for 4.13.
>> Please resend and make sure it addresses everything what was also
>> suggested for the xfs s_uuid patch.
>>
> 
> Just to be clear, the xfs s_uuid patch is just a memcpy,
> no different from Oleksij's patch.

Wasn't there a huge discussion about LE/BE/uniqueness and more details
on UUID that hurt my brain.

Thanks,
//richard

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Amir Goldstein]

On Tue, May 9, 2017 at 10:01 AM, Richard Weinberger  wrote:
>
> Oleksij,
>
> Am 09.05.2017 um 07:52 schrieb Oleksij Rempel:
> >>
> >> If VFS maintainers are fine with that, I'll take it.
> >> From UBIFS' POV it does not matter much. :-)
> >>
> >>
> >> Ping to VFS maintainers?
> >>
> >>
> >> What ping? Al made it clear that a flag is not needed.
> >> BTW, xfs s_uuid patch was merged to master.
> >
> >
> > I'm talking about ubifs patch.

Me too.

>
> Then we can queue this patch for 4.13.
> Please resend and make sure it addresses everything what was also
> suggested for the xfs s_uuid patch.
>

Just to be clear, the xfs s_uuid patch is just a memcpy,
no different from Oleksij's patch.

Thanks,
Amir.

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Amir Goldstein]

On Tue, May 9, 2017 at 10:01 AM, Richard Weinberger  wrote:
>
> Oleksij,
>
> Am 09.05.2017 um 07:52 schrieb Oleksij Rempel:
> >>
> >> If VFS maintainers are fine with that, I'll take it.
> >> From UBIFS' POV it does not matter much. :-)
> >>
> >>
> >> Ping to VFS maintainers?
> >>
> >>
> >> What ping? Al made it clear that a flag is not needed.
> >> BTW, xfs s_uuid patch was merged to master.
> >
> >
> > I'm talking about ubifs patch.

Me too.

>
> Then we can queue this patch for 4.13.
> Please resend and make sure it addresses everything what was also
> suggested for the xfs s_uuid patch.
>

Just to be clear, the xfs s_uuid patch is just a memcpy,
no different from Oleksij's patch.

Thanks,
Amir.

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Richard Weinberger]

Oleksij,

Am 09.05.2017 um 07:52 schrieb Oleksij Rempel:
>>
>> If VFS maintainers are fine with that, I'll take it.
>> From UBIFS' POV it does not matter much. :-)
>>
>>
>> Ping to VFS maintainers?
>>
>>
>> What ping? Al made it clear that a flag is not needed.
>> BTW, xfs s_uuid patch was merged to master.
> 
> 
> I'm talking about ubifs patch.

Then we can queue this patch for 4.13.
Please resend and make sure it addresses everything what was also
suggested for the xfs s_uuid patch.

Thanks,
//richard

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Richard Weinberger]

Oleksij,

Am 09.05.2017 um 07:52 schrieb Oleksij Rempel:
>>
>> If VFS maintainers are fine with that, I'll take it.
>> From UBIFS' POV it does not matter much. :-)
>>
>>
>> Ping to VFS maintainers?
>>
>>
>> What ping? Al made it clear that a flag is not needed.
>> BTW, xfs s_uuid patch was merged to master.
> 
> 
> I'm talking about ubifs patch.

Then we can queue this patch for 4.13.
Please resend and make sure it addresses everything what was also
suggested for the xfs s_uuid patch.

Thanks,
//richard

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Oleksij Rempel]

On 05/09/2017 07:37 AM, Amir Goldstein wrote:



On Tue, May 9, 2017 at 7:13 AM, Oleksij Rempel > wrote:



On 05/02/2017 09:37 AM, Richard Weinberger wrote:

Amir,

Am 02.05.2017 um 09:19 schrieb Amir Goldstein:

On Fri, Apr 28, 2017 at 1:03 AM, Richard Weinberger
> wrote:

Am 24.04.2017 um 17:47 schrieb Richard Weinberger:

So, if some flag should be implemented, who
should do it? :)


I'll not do it for you. ;)


Please also see
http://marc.info/?l=linux-fsdevel=149327990608749=2



Richard,

Considering the facts that:
1. I proposed the said flag and Al didn't think it was
needed [1]
2. ext4 already sets s_uuid without any flag for a long time now
3. A similar patch was queued for v4.12 to set s_uuid for
xfs without any flag

I think it would be right to take Oleksij's patch as is.

FYI, my current work on 'constant inode numbers for
overlayfs' requires that
underlying filesystem had set a non-zero s_uuid. Not sure if
that matters for
ubifs+overlayfs users.


If VFS maintainers are fine with that, I'll take it.
From UBIFS' POV it does not matter much. :-)


Ping to VFS maintainers?


What ping? Al made it clear that a flag is not needed.
BTW, xfs s_uuid patch was merged to master.



I'm talking about ubifs patch.

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Oleksij Rempel]

On 05/09/2017 07:37 AM, Amir Goldstein wrote:



On Tue, May 9, 2017 at 7:13 AM, Oleksij Rempel mailto:o...@pengutronix.de>> wrote:



On 05/02/2017 09:37 AM, Richard Weinberger wrote:

Amir,

Am 02.05.2017 um 09:19 schrieb Amir Goldstein:

On Fri, Apr 28, 2017 at 1:03 AM, Richard Weinberger
mailto:rich...@nod.at>> wrote:

Am 24.04.2017 um 17:47 schrieb Richard Weinberger:

So, if some flag should be implemented, who
should do it? :)


I'll not do it for you. ;)


Please also see
http://marc.info/?l=linux-fsdevel=149327990608749=2



Richard,

Considering the facts that:
1. I proposed the said flag and Al didn't think it was
needed [1]
2. ext4 already sets s_uuid without any flag for a long time now
3. A similar patch was queued for v4.12 to set s_uuid for
xfs without any flag

I think it would be right to take Oleksij's patch as is.

FYI, my current work on 'constant inode numbers for
overlayfs' requires that
underlying filesystem had set a non-zero s_uuid. Not sure if
that matters for
ubifs+overlayfs users.


If VFS maintainers are fine with that, I'll take it.
From UBIFS' POV it does not matter much. :-)


Ping to VFS maintainers?


What ping? Al made it clear that a flag is not needed.
BTW, xfs s_uuid patch was merged to master.



I'm talking about ubifs patch.

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Oleksij Rempel]

On 05/02/2017 09:37 AM, Richard Weinberger wrote:

Amir,

Am 02.05.2017 um 09:19 schrieb Amir Goldstein:

On Fri, Apr 28, 2017 at 1:03 AM, Richard Weinberger  wrote:

Am 24.04.2017 um 17:47 schrieb Richard Weinberger:

So, if some flag should be implemented, who should do it? :)


I'll not do it for you. ;)


Please also see http://marc.info/?l=linux-fsdevel=149327990608749=2



Richard,

Considering the facts that:
1. I proposed the said flag and Al didn't think it was needed [1]
2. ext4 already sets s_uuid without any flag for a long time now
3. A similar patch was queued for v4.12 to set s_uuid for xfs without any flag

I think it would be right to take Oleksij's patch as is.

FYI, my current work on 'constant inode numbers for overlayfs' requires that
underlying filesystem had set a non-zero s_uuid. Not sure if that matters for
ubifs+overlayfs users.


If VFS maintainers are fine with that, I'll take it.
From UBIFS' POV it does not matter much. :-)


Ping to VFS maintainers?

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Oleksij Rempel]

On 05/02/2017 09:37 AM, Richard Weinberger wrote:

Amir,

Am 02.05.2017 um 09:19 schrieb Amir Goldstein:

On Fri, Apr 28, 2017 at 1:03 AM, Richard Weinberger  wrote:

Am 24.04.2017 um 17:47 schrieb Richard Weinberger:

So, if some flag should be implemented, who should do it? :)


I'll not do it for you. ;)


Please also see http://marc.info/?l=linux-fsdevel=149327990608749=2



Richard,

Considering the facts that:
1. I proposed the said flag and Al didn't think it was needed [1]
2. ext4 already sets s_uuid without any flag for a long time now
3. A similar patch was queued for v4.12 to set s_uuid for xfs without any flag

I think it would be right to take Oleksij's patch as is.

FYI, my current work on 'constant inode numbers for overlayfs' requires that
underlying filesystem had set a non-zero s_uuid. Not sure if that matters for
ubifs+overlayfs users.


If VFS maintainers are fine with that, I'll take it.
From UBIFS' POV it does not matter much. :-)


Ping to VFS maintainers?

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Richard Weinberger]

Amir,

Am 02.05.2017 um 09:19 schrieb Amir Goldstein:
> On Fri, Apr 28, 2017 at 1:03 AM, Richard Weinberger  wrote:
>> Am 24.04.2017 um 17:47 schrieb Richard Weinberger:
 So, if some flag should be implemented, who should do it? :)
>>>
>>> I'll not do it for you. ;)
>>
>> Please also see http://marc.info/?l=linux-fsdevel=149327990608749=2
>>
> 
> Richard,
> 
> Considering the facts that:
> 1. I proposed the said flag and Al didn't think it was needed [1]
> 2. ext4 already sets s_uuid without any flag for a long time now
> 3. A similar patch was queued for v4.12 to set s_uuid for xfs without any flag
> 
> I think it would be right to take Oleksij's patch as is.
> 
> FYI, my current work on 'constant inode numbers for overlayfs' requires that
> underlying filesystem had set a non-zero s_uuid. Not sure if that matters for
> ubifs+overlayfs users.

If VFS maintainers are fine with that, I'll take it.
>From UBIFS' POV it does not matter much. :-)

Thanks
//richard

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Richard Weinberger]

Amir,

Am 02.05.2017 um 09:19 schrieb Amir Goldstein:
> On Fri, Apr 28, 2017 at 1:03 AM, Richard Weinberger  wrote:
>> Am 24.04.2017 um 17:47 schrieb Richard Weinberger:
 So, if some flag should be implemented, who should do it? :)
>>>
>>> I'll not do it for you. ;)
>>
>> Please also see http://marc.info/?l=linux-fsdevel=149327990608749=2
>>
> 
> Richard,
> 
> Considering the facts that:
> 1. I proposed the said flag and Al didn't think it was needed [1]
> 2. ext4 already sets s_uuid without any flag for a long time now
> 3. A similar patch was queued for v4.12 to set s_uuid for xfs without any flag
> 
> I think it would be right to take Oleksij's patch as is.
> 
> FYI, my current work on 'constant inode numbers for overlayfs' requires that
> underlying filesystem had set a non-zero s_uuid. Not sure if that matters for
> ubifs+overlayfs users.

If VFS maintainers are fine with that, I'll take it.
>From UBIFS' POV it does not matter much. :-)

Thanks
//richard

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Artem Bityutskiy]

On Tue, 2017-04-11 at 22:43 +0200, Richard Weinberger wrote:
> Makes sense.
> 
> Artem, do you remember why UBIFS didn't set s_uuid in first place?

Just did not notice it I think.

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Artem Bityutskiy]

On Tue, 2017-04-11 at 22:43 +0200, Richard Weinberger wrote:
> Makes sense.
> 
> Artem, do you remember why UBIFS didn't set s_uuid in first place?

Just did not notice it I think.

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Amir Goldstein]

On Fri, Apr 28, 2017 at 1:03 AM, Richard Weinberger  wrote:
> Am 24.04.2017 um 17:47 schrieb Richard Weinberger:
>>> So, if some flag should be implemented, who should do it? :)
>>
>> I'll not do it for you. ;)
>
> Please also see http://marc.info/?l=linux-fsdevel=149327990608749=2
>

Richard,

Considering the facts that:
1. I proposed the said flag and Al didn't think it was needed [1]
2. ext4 already sets s_uuid without any flag for a long time now
3. A similar patch was queued for v4.12 to set s_uuid for xfs without any flag

I think it would be right to take Oleksij's patch as is.

FYI, my current work on 'constant inode numbers for overlayfs' requires that
underlying filesystem had set a non-zero s_uuid. Not sure if that matters for
ubifs+overlayfs users.

Amir.

[1] https://marc.info/?l=linux-unionfs=149352864527985=2

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Amir Goldstein]

On Fri, Apr 28, 2017 at 1:03 AM, Richard Weinberger  wrote:
> Am 24.04.2017 um 17:47 schrieb Richard Weinberger:
>>> So, if some flag should be implemented, who should do it? :)
>>
>> I'll not do it for you. ;)
>
> Please also see http://marc.info/?l=linux-fsdevel=149327990608749=2
>

Richard,

Considering the facts that:
1. I proposed the said flag and Al didn't think it was needed [1]
2. ext4 already sets s_uuid without any flag for a long time now
3. A similar patch was queued for v4.12 to set s_uuid for xfs without any flag

I think it would be right to take Oleksij's patch as is.

FYI, my current work on 'constant inode numbers for overlayfs' requires that
underlying filesystem had set a non-zero s_uuid. Not sure if that matters for
ubifs+overlayfs users.

Amir.

[1] https://marc.info/?l=linux-unionfs=149352864527985=2

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Oleksij Rempel]

On 04/28/2017 10:53 AM, Amir Goldstein wrote:

On Fri, Apr 28, 2017 at 1:03 AM, Richard Weinberger  wrote:

Am 24.04.2017 um 17:47 schrieb Richard Weinberger:

So, if some flag should be implemented, who should do it? :)


I'll not do it for you. ;)


Please also see http://marc.info/?l=linux-fsdevel=149327990608749=2



Perhaps you meant this:
https://marc.info/?l=linux-fsdevel=149328358909709=2

There does not seem to be much objections to adding the flag,
so hopefully, we can merge it for v.12 and filesystems and consumers
will pick it up whenever.


Ok, thanks.

Then i will need to wait untill your patches is merged and then resent 
updated patch to avoid merge race condition.

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Oleksij Rempel]

On 04/28/2017 10:53 AM, Amir Goldstein wrote:

On Fri, Apr 28, 2017 at 1:03 AM, Richard Weinberger  wrote:

Am 24.04.2017 um 17:47 schrieb Richard Weinberger:

So, if some flag should be implemented, who should do it? :)


I'll not do it for you. ;)


Please also see http://marc.info/?l=linux-fsdevel=149327990608749=2



Perhaps you meant this:
https://marc.info/?l=linux-fsdevel=149328358909709=2

There does not seem to be much objections to adding the flag,
so hopefully, we can merge it for v.12 and filesystems and consumers
will pick it up whenever.


Ok, thanks.

Then i will need to wait untill your patches is merged and then resent 
updated patch to avoid merge race condition.

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Amir Goldstein]

On Fri, Apr 28, 2017 at 1:03 AM, Richard Weinberger  wrote:
> Am 24.04.2017 um 17:47 schrieb Richard Weinberger:
>>> So, if some flag should be implemented, who should do it? :)
>>
>> I'll not do it for you. ;)
>
> Please also see http://marc.info/?l=linux-fsdevel=149327990608749=2
>

Perhaps you meant this:
https://marc.info/?l=linux-fsdevel=149328358909709=2

There does not seem to be much objections to adding the flag,
so hopefully, we can merge it for v.12 and filesystems and consumers
will pick it up whenever.

Amir.

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Amir Goldstein]

On Fri, Apr 28, 2017 at 1:03 AM, Richard Weinberger  wrote:
> Am 24.04.2017 um 17:47 schrieb Richard Weinberger:
>>> So, if some flag should be implemented, who should do it? :)
>>
>> I'll not do it for you. ;)
>
> Please also see http://marc.info/?l=linux-fsdevel=149327990608749=2
>

Perhaps you meant this:
https://marc.info/?l=linux-fsdevel=149328358909709=2

There does not seem to be much objections to adding the flag,
so hopefully, we can merge it for v.12 and filesystems and consumers
will pick it up whenever.

Amir.

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Richard Weinberger]

Am 24.04.2017 um 17:47 schrieb Richard Weinberger:
>> So, if some flag should be implemented, who should do it? :)
> 
> I'll not do it for you. ;)

Please also see http://marc.info/?l=linux-fsdevel=149327990608749=2

Thanks,
//richard

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Richard Weinberger]

Am 24.04.2017 um 17:47 schrieb Richard Weinberger:
>> So, if some flag should be implemented, who should do it? :)
> 
> I'll not do it for you. ;)

Please also see http://marc.info/?l=linux-fsdevel=149327990608749=2

Thanks,
//richard

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Richard Weinberger]

Oleksij,

Am 12.04.2017 um 09:15 schrieb Oleksij Rempel:
> On Tue, Apr 11, 2017 at 10:48:28PM -0700, Christoph Hellwig wrote:
>> On Tue, Apr 11, 2017 at 10:43:26PM +0200, Richard Weinberger wrote:
>>> Artem, do you remember why UBIFS didn't set s_uuid in first place?
>>
>> It's an extremely odd field - only a hand full of file systems set it
>> (e.g. XFS doesn't, although according to Mimi IMA supports XFS), and
>> it's never even used outside of the IMA/EVM code.
>>
>> We really need a feature flag that this field is valid that IMA can
>> check before adding more support for it.
> 
> It seems to be used by mm/cleancache.c
> void __cleancache_init_shared_fs()
> 
> but this affects only ocfs2.
> 
> So, if some flag should be implemented, who should do it? :)

I'll not do it for you. ;)

> If me, what flag should be created?

A super block flag that denotes that s_uuid is valid.

Thanks,
//richard

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Richard Weinberger]

Oleksij,

Am 12.04.2017 um 09:15 schrieb Oleksij Rempel:
> On Tue, Apr 11, 2017 at 10:48:28PM -0700, Christoph Hellwig wrote:
>> On Tue, Apr 11, 2017 at 10:43:26PM +0200, Richard Weinberger wrote:
>>> Artem, do you remember why UBIFS didn't set s_uuid in first place?
>>
>> It's an extremely odd field - only a hand full of file systems set it
>> (e.g. XFS doesn't, although according to Mimi IMA supports XFS), and
>> it's never even used outside of the IMA/EVM code.
>>
>> We really need a feature flag that this field is valid that IMA can
>> check before adding more support for it.
> 
> It seems to be used by mm/cleancache.c
> void __cleancache_init_shared_fs()
> 
> but this affects only ocfs2.
> 
> So, if some flag should be implemented, who should do it? :)

I'll not do it for you. ;)

> If me, what flag should be created?

A super block flag that denotes that s_uuid is valid.

Thanks,
//richard

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Oleksij Rempel]

On Tue, Apr 11, 2017 at 10:48:28PM -0700, Christoph Hellwig wrote:
> On Tue, Apr 11, 2017 at 10:43:26PM +0200, Richard Weinberger wrote:
> > Artem, do you remember why UBIFS didn't set s_uuid in first place?
> 
> It's an extremely odd field - only a hand full of file systems set it
> (e.g. XFS doesn't, although according to Mimi IMA supports XFS), and
> it's never even used outside of the IMA/EVM code.
> 
> We really need a feature flag that this field is valid that IMA can
> check before adding more support for it.

It seems to be used by mm/cleancache.c
void __cleancache_init_shared_fs()

but this affects only ocfs2.

So, if some flag should be implemented, who should do it? :)
If me, what flag should be created?

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Oleksij Rempel]

On Tue, Apr 11, 2017 at 10:48:28PM -0700, Christoph Hellwig wrote:
> On Tue, Apr 11, 2017 at 10:43:26PM +0200, Richard Weinberger wrote:
> > Artem, do you remember why UBIFS didn't set s_uuid in first place?
> 
> It's an extremely odd field - only a hand full of file systems set it
> (e.g. XFS doesn't, although according to Mimi IMA supports XFS), and
> it's never even used outside of the IMA/EVM code.
> 
> We really need a feature flag that this field is valid that IMA can
> check before adding more support for it.

It seems to be used by mm/cleancache.c
void __cleancache_init_shared_fs()

but this affects only ocfs2.

So, if some flag should be implemented, who should do it? :)
If me, what flag should be created?

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Christoph Hellwig]

On Tue, Apr 11, 2017 at 10:43:26PM +0200, Richard Weinberger wrote:
> Artem, do you remember why UBIFS didn't set s_uuid in first place?

It's an extremely odd field - only a hand full of file systems set it
(e.g. XFS doesn't, although according to Mimi IMA supports XFS), and
it's never even used outside of the IMA/EVM code.

We really need a feature flag that this field is valid that IMA can
check before adding more support for it.

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Christoph Hellwig]

On Tue, Apr 11, 2017 at 10:43:26PM +0200, Richard Weinberger wrote:
> Artem, do you remember why UBIFS didn't set s_uuid in first place?

It's an extremely odd field - only a hand full of file systems set it
(e.g. XFS doesn't, although according to Mimi IMA supports XFS), and
it's never even used outside of the IMA/EVM code.

We really need a feature flag that this field is valid that IMA can
check before adding more support for it.

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Richard Weinberger]

Oleksij,

Am 11.04.2017 um 11:50 schrieb Oleksij Rempel:
> From: Steffen Trumtrar 
> 
> This is need to provide uuid based integrity functionlity for:
> imy_policy (fsuuid option) and  evmctl (--uuid option).
> 
> Signed-off-by: Steffen Trumtrar 
> Signed-off-by: Oleksij Rempel 
> ---
>  fs/ubifs/super.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
> index bff1e8d6f7bd..a584b2f2b11d 100644
> --- a/fs/ubifs/super.c
> +++ b/fs/ubifs/super.c
> @@ -2077,6 +2077,7 @@ static int ubifs_fill_super(struct super_block *sb, 
> void *data, int silent)
>   err = -ENOMEM;
>   goto out_umount;
>   }
> + memcpy(>s_uuid, >uuid, sizeof(c->uuid));

Makes sense.

Artem, do you remember why UBIFS didn't set s_uuid in first place?

Thanks,
//richard

Re: [PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Richard Weinberger]

Oleksij,

Am 11.04.2017 um 11:50 schrieb Oleksij Rempel:
> From: Steffen Trumtrar 
> 
> This is need to provide uuid based integrity functionlity for:
> imy_policy (fsuuid option) and  evmctl (--uuid option).
> 
> Signed-off-by: Steffen Trumtrar 
> Signed-off-by: Oleksij Rempel 
> ---
>  fs/ubifs/super.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
> index bff1e8d6f7bd..a584b2f2b11d 100644
> --- a/fs/ubifs/super.c
> +++ b/fs/ubifs/super.c
> @@ -2077,6 +2077,7 @@ static int ubifs_fill_super(struct super_block *sb, 
> void *data, int silent)
>   err = -ENOMEM;
>   goto out_umount;
>   }
> + memcpy(>s_uuid, >uuid, sizeof(c->uuid));

Makes sense.

Artem, do you remember why UBIFS didn't set s_uuid in first place?

Thanks,
//richard

[PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Oleksij Rempel]

From: Steffen Trumtrar 

This is need to provide uuid based integrity functionlity for:
imy_policy (fsuuid option) and  evmctl (--uuid option).

Signed-off-by: Steffen Trumtrar 
Signed-off-by: Oleksij Rempel 
---
 fs/ubifs/super.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index bff1e8d6f7bd..a584b2f2b11d 100644
--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
@@ -2077,6 +2077,7 @@ static int ubifs_fill_super(struct super_block *sb, void 
*data, int silent)
err = -ENOMEM;
goto out_umount;
}
+   memcpy(>s_uuid, >uuid, sizeof(c->uuid));
 
mutex_unlock(>umount_mutex);
return 0;
-- 
2.11.0

[PATCH v2 3/3] fs: ubifs: set s_uuid in super block

[Oleksij Rempel]

From: Steffen Trumtrar 

This is need to provide uuid based integrity functionlity for:
imy_policy (fsuuid option) and  evmctl (--uuid option).

Signed-off-by: Steffen Trumtrar 
Signed-off-by: Oleksij Rempel 
---
 fs/ubifs/super.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index bff1e8d6f7bd..a584b2f2b11d 100644
--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
@@ -2077,6 +2077,7 @@ static int ubifs_fill_super(struct super_block *sb, void 
*data, int silent)
err = -ENOMEM;
goto out_umount;
}
+   memcpy(>s_uuid, >uuid, sizeof(c->uuid));
 
mutex_unlock(>umount_mutex);
return 0;
-- 
2.11.0