Re: [PATCH] module,bug: Add TAINT_OOT_MODULE flag for modules notbuilt in-tree

[Luis R. Rodriguez]

On Mon, Dec 12, 2011 at 1:58 PM, Ben Hutchings <ben@xxxxxxxxxxxxxxx> wrote:
> On Mon, Dec 12, 2011 at 01:40:44PM -0800, Luis R. Rodriguez wrote:
>> On Mon, Oct 24, 2011 at 6:12 AM, Ben Hutchings <ben@xxxxxxxxxxxxxxx> wrote:
>> > Use of the GPL or a compatible licence doesn't necessarily make the code
>> > any good. ÂWe already consider staging modules to be suspect, and this
>> > should also be true for out-of-tree modules which may receive very
>> > little review.
>> >
>> > Signed-off-by: Ben Hutchings <ben@xxxxxxxxxxxxxxx>
>> > ---
>> > Debian has been carrying this for the last few kernel versions. ÂThe
>> > recent thread '[RFC] virtualbox tainting.' and discussions at KS suggest
>> > that this might be more generally useful.
>>
>> This indeed seems like a good idea to advocate getting things upstream
>> (not just staging) but what about the case where we have upstream
>> drivers from future kernels backported to older kernels and the newer
>> driver is simply provided as a feature for users who may need new
>> features / chipset support on their old distribution kernel?
>
> They continue to work without any loss of functionality. Â(After the
> follow-up patches to keep dynamic debugging and lock debugging
> working.)

Great!

>> It seems this taint flag will be used for driers backported through
>> compat-wireless, the compat kernel module or any other backported
>> driver, even if it is indeed upstream and whereby kernel developer
>> *do* commit to actually fixing issues. In our experience
>> compat-wireless bugs *are real bugs*, not backport bugs so we do look
>> into them. In our latest linux-next.git based release for example
>> backport code consists only of 1.3804% of the code.
>
> Now you can look for (O) after the module name in a BUG/Oops message
> and you can tell whether the user really had the original or
> compat-wireless version of the driver.
>
> It is really up to each distributor or developer how they treat
> bug reports with the O taint. ÂWhen handling Debian bug reports I
> won't automatically reject such a tainted kernel but I will look
> carefully at the module list.

I'm working on getting my companies to abandon 802.11 proprietary
drivers for good. For Station mode of operation this is pretty much
mission complete. For AP products.. this is work in progress. The out
of tree flag is a good utility one can use to help justify working
upstream but if we treat any future-kernel-backported-driver equally
to any out of tree crap piece of shit driver, it seems to do unjustice
to the value of a properly upstream backported driver. I will note
that I put a lot of effort to ensure that the backport effort is
upstream-centric in an *extremely* upstream-biased way, see how I
label extra patches for tarballs [1]. If your patches are not upstream
the only way you get into these tarballs are by providing patches into
these directories:

  * pending-stable/ stable fixes from linux-next.git not yet on a stable release
  * linux-next-cherry-picks/ patches upstream but that won't go to the
stable release that we want to cherry pick
  * linux-next-pending/ patches posted on the public development
mailing list, patch not yet merged due to the maintainer being away on
vacation or whatever
  * crap/ patches not even posted publicly yet

Each tarball used also gets pegged with a letter if *any* patch from
any of these directories gets applied. The compat module, upon being
loaded, will also print the kernel ring buffer the exact release,
whether extra patches were provided, the upstream git tree used as
base and so on.

So -- although from a technical perspective this may mean Debian /
other kernel developers may ignore the taint flag for compat-wireless
it'd sure be nice to avoid it for them all together. Just can't think
of a way to do it yet... If you agree should we continue to think of a
way if its possible?

[1] http://wireless.kernel.org/en/users/Download/stable#Legend

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