headers
Anton Altaparmakov | 8 Feb 01:07
Favicon

Direct i/o changes break all non-GPL file systems

Hi Linus, Andrew, Christoph,

With kernel 3.1, Christoph removed i_alloc_sem and replaced it with calls (namely inode_dio_wait() and
inode_dio_done()) which are EXPORT_SYMBOL_GPL() thus they cannot be used by non-GPL file systems and
further inode_dio_wait() was pushed from notify_change() into the file system ->setattr() method but
no non-GPL file system can make this call.

That means non-GPL file systems cannot exist any more unless they do not use any VFS functionality related
to reading/writing as far as I can tell or at least as long as they want to implement direct i/o.

What are commercial file systems meant to do now?

For example Tuxera exFAT uses the generic write code which means that read/write use the generic direct_IO
functions however Tuxera exFAT's setattr() method cannot call inode_dio_wait() and there are places
where exfat_truncate() is called directly with i_alloc_sem held and now this needs to be replaced with
calls to inode_dio_wait() but we cannot do that as the function is GPL only.

Previously when APIs have been changed that were accessible to non-GPL modules it was made sure those APIs
remained that way but this does not appear to be the case here.

Do all non-GPL file systems now really have to re-implement the entire read-write code paths for
themselves for the sake of two GPL only exports in the direct i/o code?  That seems a bit harsh!

Have I missed something?  If not would you accept a patch to change the two needed GPL only symbols into
EXPORT_SYMBOL() ones?

Thanks a lot in advance!

Best regards,
(Continue reading)

Permalink | Reply |
headers
Alan Cox | 8 Feb 01:15
Face
Picon

Re: Direct i/o changes break all non-GPL file systems

On Wed, 8 Feb 2012 00:07:15 +0000
Anton Altaparmakov <anton <at> tuxera.com> wrote:

> Hi Linus, Andrew, Christoph,
> 
> With kernel 3.1, Christoph removed i_alloc_sem and replaced it with calls (namely inode_dio_wait() and
inode_dio_done()) which are EXPORT_SYMBOL_GPL() thus they cannot be used by non-GPL file systems and
further inode_dio_wait() was pushed from notify_change() into the file system ->setattr() method but
no non-GPL file system can make this call.

I'm advised by my lawyer that when this occurs that I should always
inform the other party the following

"For a Linux kernel containing any code I own the code is under the GNU
public license v2 (in some cases or later), I have never given permission
for that code to be used as part of a combined or derivative work which
contains binary chunks. I have never said that modules are somehow
magically outside the GPL and I am doubtful that in most cases a work
containing binary modules for a Linux kernel is compatible with the
licensing, although I accept there may be some cases that it is."

So unless your code is remarkably non-derivative I don't see that
anything has changed.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply |
headers
Anton Altaparmakov | 8 Feb 01:28
Favicon

Re: Direct i/o changes break all non-GPL file systems

Hi Alan,

I don't really want to get into this discussion due to the likelihood of people using it as an excuse to start a
flamewar which we can really do without.

Linus has previously stated that he is happy for binary kernel modules to exist and I believe that a kernel
module calling EXPORT_SYMBOL() functions is the equivalent of a user space program executing system
calls.  I do not believe this has even been decided in court so let us please not start a flamewar on the
subject!  I am sure both points of view have their merits but unless they are tested in court there is no point
in wasting everyones time discussing the subject to death.  That has been done many times before ad nauseum.

Can we please let this sort of debate be and just focus on the question whether this breakage for non-GPL
modules was intentional or accidental and if the latter whether the author, namely Christoph, would be
willing to reconsider his choice and allow the symbols to become generically exported, in which case we
can return to the state we had before by exporting the two symbols to all modules.

Thank you (and apologise for top posting).

Best regards,

	Anton

On 8 Feb 2012, at 00:15, Alan Cox wrote:

> On Wed, 8 Feb 2012 00:07:15 +0000
> Anton Altaparmakov <anton <at> tuxera.com> wrote:
> 
>> Hi Linus, Andrew, Christoph,
>> 
>> With kernel 3.1, Christoph removed i_alloc_sem and replaced it with calls (namely inode_dio_wait()
(Continue reading)

Permalink | Reply |
headers
Andreas Dilger | 8 Feb 02:51
Picon

Re: Direct i/o changes break all non-GPL file systems

On 2012-02-07, at 5:28 PM, Anton Altaparmakov wrote:
> Linus has previously stated that he is happy for binary kernel modules to exist and I believe that a kernel
module calling EXPORT_SYMBOL() functions is the equivalent of a user space program executing system
calls.  I do not believe this has even been decided in court so let us please not start a flamewar on the
subject!  I am sure both points of view have their merits but unless they are tested in court there is no point
in wasting everyones time discussing the subject to death.  That has been done many times before ad nauseum.
> 
> Can we please let this sort of debate be and just focus on the question whether this breakage for non-GPL
modules was intentional or accidental and if the latter whether the author, namely Christoph, would be
willing to reconsider his choice and allow the symbols to become generically exported, in which case we
can return to the state we had before by exporting the two symbols to all modules.

This doesn't affect me directly, since Lustre is itself a GPL filesystem,
but it does seem a bit harsh for such a minor amount of functionality.

Looking at inode_dio_wait(), there isn't anything in there that couldn't
be implemented without using that GPL-only symbol export.  Both inode_dio_wait()
and __inode_dio_wait() use only functions that are themselves EXPORT_SYMBOL()
(i.e. not GPL-only) and locally accessible structures (inode->i_dio_count
and inode->i_state), so I don't see any benefit or reason in making
inode_dio_wait() itself GPL.

Cheers, Andreas

> On 8 Feb 2012, at 00:15, Alan Cox wrote:
>> On Wed, 8 Feb 2012 00:07:15 +0000
>> Anton Altaparmakov <anton <at> tuxera.com> wrote:
>> 
>>> Hi Linus, Andrew, Christoph,
>>>
(Continue reading)

Permalink | Reply |
headers
Linus Torvalds | 10 Feb 20:28
Gravatar

Re: Direct i/o changes break all non-GPL file systems

On Tue, Feb 7, 2012 at 5:51 PM, Andreas Dilger <adilger <at> dilger.ca> wrote:
>
> This doesn't affect me directly, since Lustre is itself a GPL filesystem,
> but it does seem a bit harsh for such a minor amount of functionality.

It also wasn't documented in the commit or apparently even intentional.

> Looking at inode_dio_wait(), there isn't anything in there that couldn't
> be implemented without using that GPL-only symbol export.  Both inode_dio_wait()
> and __inode_dio_wait() use only functions that are themselves EXPORT_SYMBOL()
> (i.e. not GPL-only) and locally accessible structures (inode->i_dio_count
> and inode->i_state), so I don't see any benefit or reason in making
> inode_dio_wait() itself GPL.

Yes. I suspect we should just remove the _GPL part. Christoph, Al?

                      Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply |
headers
Al Viro | 10 Feb 22:19
Picon
Favicon

Re: Direct i/o changes break all non-GPL file systems

On Fri, Feb 10, 2012 at 11:28:27AM -0800, Linus Torvalds wrote:
> On Tue, Feb 7, 2012 at 5:51 PM, Andreas Dilger <adilger <at> dilger.ca> wrote:
> >
> > This doesn't affect me directly, since Lustre is itself a GPL filesystem,
> > but it does seem a bit harsh for such a minor amount of functionality.
> 
> It also wasn't documented in the commit or apparently even intentional.
> 
> > Looking at inode_dio_wait(), there isn't anything in there that couldn't
> > be implemented without using that GPL-only symbol export. ?Both inode_dio_wait()
> > and __inode_dio_wait() use only functions that are themselves EXPORT_SYMBOL()
> > (i.e. not GPL-only) and locally accessible structures (inode->i_dio_count
> > and inode->i_state), so I don't see any benefit or reason in making
> > inode_dio_wait() itself GPL.
> 
> Yes. I suspect we should just remove the _GPL part. Christoph, Al?

I'm all for it; TBH, I simply missed _GPL on those back then.  As far as I'm
concerned, there are 3 cases:
	1) it's a part of general-purpose API and it does make sense for
modules; use EXPORT_SYMBOL
	2) it's a kernel-internal thing that is not used by in-tree modules
and should not be used by any modules; don't export it at all
	3) it's a layering violation that unfortunately still is needed for
an in-tree module.  The *only* case where I'd consider EXPORT_SYMBOL_GPL
borderline useful, as a bad proxy for EXPORT_SYMBOL_DONT_USE_OUT_OF_TREE.

It's Christoph's code, though, so I'm not happy with just going ahead and
ripping that _GPL off those exports.  Christoph?
(Continue reading)

Permalink | Reply |
headers
Andi Kleen | 11 Feb 17:18

Re: Direct i/o changes break all non-GPL file systems

Al Viro <viro <at> ZenIV.linux.org.uk> writes:

> and should not be used by any modules; don't export it at all
> 	3) it's a layering violation that unfortunately still is needed for
> an in-tree module.  The *only* case where I'd consider EXPORT_SYMBOL_GPL
> borderline useful, as a bad proxy for EXPORT_SYMBOL_DONT_USE_OUT_OF_TREE.

I had the namespace patches to make this explicit some time ago

http://lwn.net/Articles/259839/

This allows to export specific symbols only for special other modules,
in case it's only a single module that needs a "backdoor"

I can look at resubmitting the patchkit.

-Andi
--

-- 
ak <at> linux.intel.com -- Speaking for myself only
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply |

Gmane