Re: [f2fs-dev] [PATCH] fscrypt: remove filesystem specific build config option

2019-01-24 Thread Theodore Y. Ts'o
On Thu, Jan 24, 2019 at 10:29:50AM -0800, Eric Biggers wrote:
> 
> Hi Ted, that sounds good to me.  I assume you know how to get that set up?
> Also, should I go ahead and send a patch that adds myself to the MAINTAINERS
> file?

I have the request to the git.kernel.org folks and the edits to the
MAINTAINERS file already done, so I'll send them out shortly.  :-)

   - Ted


Re: [f2fs-dev] [PATCH] fscrypt: remove filesystem specific build config option

2019-01-24 Thread Eric Biggers
On Thu, Jan 24, 2019 at 12:03:37AM -0500, Theodore Y. Ts'o wrote:
> On Thu, Jan 10, 2019 at 05:01:17PM -0800, Eric Biggers wrote:
> > 
> > Indeed, Chandan Rajendra sent out a new version of the patch which fixes the
> > problem (by removing the 'select BLOCK' from fs/ubifs/Kconfig), but it never
> > made it into the fscrypt tree and hence never made it into linux-next.
> > 
> > Ted, what you are planning to do with the fscrypt tree following the 
> > fsverity
> > discussion?  IMO, we should keep the fsverity stuff in its own branch, 
> > separate
> > from any fscrypt changes.  As a suggestion, in the branch "fscrypt" of my
> > linux.git repo [1], I applied just these four patches on top of v5.0-rc1 and
> > resolved the conflicts with them no longer being on top of fsverity...
> 
> Sorry, I was on vacation last week and I've been catching up on things
> this week.  I've reset the master branch on my fscrypt.git tree so
> that it has what you have on your fscrypt branch, rebased to 5.0-rc3.
> 
> Also, as we had talked about earlier, it probably makes sense to set
> up jointly maintained git tree for fscrypt and fsverity.  My proposal
> is that we set up a new fscrypt.git tree, at
> /pub/scm/fs/fscrypt/fscrypt.git, that would be owned by the "FSCRYPT
> group", with group membership being ebiggers, jaeguk, and tytso.
> We'll have to figure out ways that we can jointly update the git tree
> without stepping on each other, probably using a group chat.  Does
> that sound good to you?
> 

Hi Ted, that sounds good to me.  I assume you know how to get that set up?
Also, should I go ahead and send a patch that adds myself to the MAINTAINERS
file?

- Eric


Re: [f2fs-dev] [PATCH] fscrypt: remove filesystem specific build config option

2019-01-23 Thread Theodore Y. Ts'o
On Thu, Jan 10, 2019 at 05:01:17PM -0800, Eric Biggers wrote:
> 
> Indeed, Chandan Rajendra sent out a new version of the patch which fixes the
> problem (by removing the 'select BLOCK' from fs/ubifs/Kconfig), but it never
> made it into the fscrypt tree and hence never made it into linux-next.
> 
> Ted, what you are planning to do with the fscrypt tree following the fsverity
> discussion?  IMO, we should keep the fsverity stuff in its own branch, 
> separate
> from any fscrypt changes.  As a suggestion, in the branch "fscrypt" of my
> linux.git repo [1], I applied just these four patches on top of v5.0-rc1 and
> resolved the conflicts with them no longer being on top of fsverity...

Sorry, I was on vacation last week and I've been catching up on things
this week.  I've reset the master branch on my fscrypt.git tree so
that it has what you have on your fscrypt branch, rebased to 5.0-rc3.

Also, as we had talked about earlier, it probably makes sense to set
up jointly maintained git tree for fscrypt and fsverity.  My proposal
is that we set up a new fscrypt.git tree, at
/pub/scm/fs/fscrypt/fscrypt.git, that would be owned by the "FSCRYPT
group", with group membership being ebiggers, jaeguk, and tytso.
We'll have to figure out ways that we can jointly update the git tree
without stepping on each other, probably using a group chat.  Does
that sound good to you?

- Ted


Re: [f2fs-dev] [PATCH] fscrypt: remove filesystem specific build config option

2019-01-10 Thread Eric Biggers
On Thu, Jan 10, 2019 at 03:32:30PM -0800, Guenter Roeck wrote:
> On Sat, Dec 08, 2018 at 12:21:38PM +0530, Chandan Rajendra wrote:
> > In order to have a common code base for fscrypt "post read" processing
> > for all filesystems which support encryption, this commit removes
> > filesystem specific build config option (e.g. CONFIG_EXT4_FS_ENCRYPTION)
> > and replaces it with a build option (i.e. CONFIG_FS_ENCRYPTION) whose
> > value affects all the filesystems making use of fscrypt.
> > 
> > Signed-off-by: Chandan Rajendra 
> > Signed-off-by: Theodore Ts'o 
> 
> This results in:
> 
> Building ia64:allnoconfig ... failed
> --
> Error log:
> make[1]: Entering directory '/tmp/buildbot-builddir.7Wft3'
>   GEN Makefile
> scripts/kconfig/conf  --allnoconfig Kconfig
> arch/ia64/Kconfig:128:error: recursive dependency detected!
> arch/ia64/Kconfig:128:choice  contains symbol IA64_HP_SIM
> arch/ia64/Kconfig:202:symbol IA64_HP_SIM is part of choice PM
> kernel/power/Kconfig:144: symbol PM is selected by PM_SLEEP
> kernel/power/Kconfig:104: symbol PM_SLEEP depends on HIBERNATE_CALLBACKS
> kernel/power/Kconfig:31:  symbol HIBERNATE_CALLBACKS is selected by 
> HIBERNATION
> kernel/power/Kconfig:34:  symbol HIBERNATION depends on SWAP
> init/Kconfig:250: symbol SWAP depends on BLOCK
> block/Kconfig:5:  symbol BLOCK is selected by UBIFS_FS
> fs/ubifs/Kconfig:1:   symbol UBIFS_FS depends on MISC_FILESYSTEMS
> fs/Kconfig:227:   symbol MISC_FILESYSTEMS is selected by ACPI_APEI
> drivers/acpi/apei/Kconfig:8:  symbol ACPI_APEI depends on ACPI
> drivers/acpi/Kconfig:9:   symbol ACPI depends on ARCH_SUPPORTS_ACPI
> drivers/acpi/Kconfig:6:   symbol ARCH_SUPPORTS_ACPI is selected by 
> IA64_HP_SIM
> arch/ia64/Kconfig:202:symbol IA64_HP_SIM is part of choice 
> For a resolution refer to Documentation/kbuild/kconfig-language.txt
> subsection "Kconfig recursive dependency limitations"
> 
> Didn't we have exactly the same problem before ?
> 
> Guenter

Indeed, Chandan Rajendra sent out a new version of the patch which fixes the
problem (by removing the 'select BLOCK' from fs/ubifs/Kconfig), but it never
made it into the fscrypt tree and hence never made it into linux-next.

Ted, what you are planning to do with the fscrypt tree following the fsverity
discussion?  IMO, we should keep the fsverity stuff in its own branch, separate
from any fscrypt changes.  As a suggestion, in the branch "fscrypt" of my
linux.git repo [1], I applied just these four patches on top of v5.0-rc1 and
resolved the conflicts with them no longer being on top of fsverity:

fscrypt: remove CRYPTO_CTR dependency
ext4: use IS_ENCRYPTED() to check encryption status
f2fs: use IS_ENCRYPTED() to check encryption status
fscrypt: remove filesystem specific build config option

(The last patch is the fixed version.)

Please consider doing the same with the official fscrypt tree.  Thanks!

[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/log/?h=fscrypt

- Eric