Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1551231 > unrolled thread

Re: [PATCH v2] fscrypt: Factor out bio specific functions

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v2] fscrypt: Factor out bio specific functions Eric Biggers <ebiggers3@gmail.com> - 2017-01-04 21:30 +0100
    Re: [PATCH v2] fscrypt: Factor out bio specific functions Richard Weinberger <richard@nod.at> - 2017-01-05 00:00 +0100
    Re: [PATCH v2] fscrypt: Factor out bio specific functions Theodore Ts'o <tytso@mit.edu> - 2017-01-07 20:30 +0100
      Re: [PATCH v2] fscrypt: Factor out bio specific functions Richard Weinberger <richard@nod.at> - 2017-01-07 23:50 +0100
        Re: [PATCH v2] fscrypt: Factor out bio specific functions Christoph Hellwig <hch@infradead.org> - 2017-01-09 14:40 +0100

#1551231 — Re: [PATCH v2] fscrypt: Factor out bio specific functions

On Tue, Jan 03, 2017 at 09:28:36AM -0500, Theodore Ts'o wrote:
> On Tue, Jan 03, 2017 at 10:49:26AM +0100, Richard Weinberger wrote:
> > Ted,
> > 
> > Am 01.01.2017 um 22:47 schrieb Theodore Ts'o:
> > > On Mon, Dec 19, 2016 at 12:25:32PM +0100, Richard Weinberger wrote:
> > >> That way we can get rid of the direct dependency on CONFIG_BLOCK.
> > >>
> > >> Reported-by: Arnd Bergmann <arnd@arndb.de>
> > >> Reported-by: Randy Dunlap <rdunlap@infradead.org>
> > >> Suggested-by: Christoph Hellwig <hch@infradead.org>
> > >> Fixes: d475a507457b ("ubifs: Add skeleton for fscrypto")
> > >> Signed-off-by: Richard Weinberger <richard@nod.at>
> > > 
> > > Applied, thanks.
> > 
> > Just to make sure, this fixes a build error and should
> > go into Linus' tree ASAP.
> 
> I didn't consider this a build error since it could be fixed via a
> config change.  And it is a pretty big patch, even if it is mostly
> moving (not that git recognized it as such)...
> 

I thought you're supposed to be able to build the kernel no matter how it's
configured.  If this patch is really too large for 4.10 then perhaps we should
make FS_ENCRYPTION select CONFIG_BLOCK instead?

Eric

[toc] | [next] | [standalone]

#1551474

Am 04.01.2017 um 21:10 schrieb Eric Biggers:
> On Tue, Jan 03, 2017 at 09:28:36AM -0500, Theodore Ts'o wrote:
>> On Tue, Jan 03, 2017 at 10:49:26AM +0100, Richard Weinberger wrote:
>>> Ted,
>>>
>>> Am 01.01.2017 um 22:47 schrieb Theodore Ts'o:
>>>> On Mon, Dec 19, 2016 at 12:25:32PM +0100, Richard Weinberger wrote:
>>>>> That way we can get rid of the direct dependency on CONFIG_BLOCK.
>>>>>
>>>>> Reported-by: Arnd Bergmann <arnd@arndb.de>
>>>>> Reported-by: Randy Dunlap <rdunlap@infradead.org>
>>>>> Suggested-by: Christoph Hellwig <hch@infradead.org>
>>>>> Fixes: d475a507457b ("ubifs: Add skeleton for fscrypto")
>>>>> Signed-off-by: Richard Weinberger <richard@nod.at>
>>>>
>>>> Applied, thanks.
>>>
>>> Just to make sure, this fixes a build error and should
>>> go into Linus' tree ASAP.
>>
>> I didn't consider this a build error since it could be fixed via a
>> config change.  And it is a pretty big patch, even if it is mostly
>> moving (not that git recognized it as such)...
>>
> 
> I thought you're supposed to be able to build the kernel no matter how it's
> configured.  If this patch is really too large for 4.10 then perhaps we should
> make FS_ENCRYPTION select CONFIG_BLOCK instead?

My initial plan was a config fix but hch asked to fix the root cause right now.
https://lkml.org/lkml/2016/12/16/118

Thanks,
//richard

[toc] | [prev] | [next] | [standalone]

#1553719

On Wed, Jan 04, 2017 at 12:10:43PM -0800, Eric Biggers wrote:
> 
> I thought you're supposed to be able to build the kernel no matter how it's
> configured.  If this patch is really too large for 4.10 then perhaps we should
> make FS_ENCRYPTION select CONFIG_BLOCK instead?

We already have FS_ENCRYPTIOn depending on BLOCK, so this is *not*
fixing a build break.

Given that, it's a bit harder to claim this is a must-have bug fix for
the stable branch?

						- Ted

[toc] | [prev] | [next] | [standalone]

#1553760

Ted,

Am 07.01.2017 um 20:24 schrieb Theodore Ts'o:
> On Wed, Jan 04, 2017 at 12:10:43PM -0800, Eric Biggers wrote:
>>
>> I thought you're supposed to be able to build the kernel no matter how it's
>> configured.  If this patch is really too large for 4.10 then perhaps we should
>> make FS_ENCRYPTION select CONFIG_BLOCK instead?
> 
> We already have FS_ENCRYPTIOn depending on BLOCK, so this is *not*
> fixing a build break.

Kconfig is tricky. We face a build error with CONFIG_BLOCK=n with UBIFS_FS_ENCRYPTION enabled.
UBIFS file encryption does "select FS_ENCRYPTION" just like ext4 and f2fs.
This will enable ENCRYPTION even when no block support is available.

I can make UBIFS depend on BLOCK as intermediate fix.
But the real fix is this patch.

Thanks,
//richard

[toc] | [prev] | [next] | [standalone]

#1554317

On Sat, Jan 07, 2017 at 11:40:15PM +0100, Richard Weinberger wrote:
> Kconfig is tricky. We face a build error with CONFIG_BLOCK=n with UBIFS_FS_ENCRYPTION enabled.
> UBIFS file encryption does "select FS_ENCRYPTION" just like ext4 and f2fs.
> This will enable ENCRYPTION even when no block support is available.

It's the good old select vs depends mess once again.

> I can make UBIFS depend on BLOCK as intermediate fix.
> But the real fix is this patch.

And despite the diffstat it's simple and trivial as it just moves code.
There is no good reason not to take it for 4.10.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web