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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <D35F212C-0C17-43CE-885D-62C6DF58E2C2@dilger.ca>
Date:	Tue, 7 Feb 2012 18:51:55 -0700
From:	Andreas Dilger <adilger@...ger.ca>
To:	Anton Altaparmakov <anton@...era.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Christoph Hellwig <hch@...radead.org>,
	Szabolcs Szakacsits <szaka@...era.com>,
	Janne Kalliomäki <janne@...era.com>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: 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@...era.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.
> 
> 
> -- 
> Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
> Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
> Linux NTFS maintainer, http://www.linux-ntfs.org/
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


Cheers, Andreas





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/