linux-kernel - Re: sched: exporting linux-rt migrate

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]

Date:   Mon, 14 Dec 2020 23:31:34 +0000
From:   Orivej Desh <c@...vej.org>
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Steven Rostedt <rostedt@...dmis.org>,
        linux-rt-users@...r.kernel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Brian Behlendorf <behlendorf1@...l.gov>
Subject: Re: sched: exporting linux-rt migrate_disable for ZFS

* Sebastian Andrzej Siewior <bigeasy@...utronix.de> [2020-12-14]
> On 2020-12-08 23:58:27 [+0000], Orivej Desh wrote:
> > With sched-Add-migrate_disable.patch first released in v5.9-rc8-rt14 [1]
> > linux-rt defines functions migrate_disable and migrate_enable.
> > They are used in linux headers in various macros and static inline
> > functions, and in particular in kmap_atomic and kunmap_atomic.
> > The latter are needed by ZFS which currently fails to build against
> > 5.9-rt [2] because these functions are exported with EXPORT_SYMBOL_GPL.
> > Could you export them with EXPORT_SYMBOL instead?  
> 
> This is out of my jurisdiction, so just a few notes:
> - v5.9 is out of maintenance. Be careful.

Thanks! I have noticed a bug with usb-storage (using smp_processor_id
in preemptible code) in 5.9.1-rt20 thas has been fixed in 5.10-rt17.

> - We don't export symbols for out-of-tree modules.

The issue is that in the vanilla kernel these two functions are
available as macros that expand into EXPORT_SYMBOL function calls
(kunmap_atomic_high, etc.). If I am not mistaken the kernel is
generally supposed to keep the API made available to non-GPL modules
still available, for example here https://lwn.net/Articles/171838/ :
"When GPL-only exports were first added to the kernel, they went in
with the understanding that only new symbols would be tagged
GPL-only. The current module interface - while always subject to
change - was not to have symbols withdrawn arbitrarily." The current
rt patch has this effect: it makes non-GPL API of the vanilla kernel
GPL-only.