On Tue, 05 Dec 2023, Jens Axboe wrote: > On 12/4/23 2:02 PM, NeilBrown wrote: > > It isn't clear to me what _GPL is appropriate, but maybe the rules > > changed since last I looked..... are there rules? > > > > My reasoning was that the call is effectively part of the user-space > > ABI. A user-space process can call this trivially by invoking any > > system call. The user-space ABI is explicitly a boundary which the GPL > > does not cross. So it doesn't seem appropriate to prevent non-GPL > > kernel code from doing something that non-GPL user-space code can > > trivially do. > > By that reasoning, basically everything in the kernel should be non-GPL > marked. And while task_work can get used by the application, it happens > only indirectly or implicitly. So I don't think this reasoning is sound > at all, it's not an exported ABI or API by itself. > > For me, the more core of an export it is, the stronger the reason it > should be GPL. FWIW, I don't think exporting task_work functionality is > a good idea in the first place, but if there's a strong reason to do so, > it should most certainly not be accessible to non-GPL modules. Basically > NO new export should be non-GPL. An alternate to exporting task_work_run() might be to call it from try_to_freeze(). I think that too should only be called from a context where no locks are held etc. Obviously try_to_freeze would only call task_work_run() if PF_RUNS_TASK_WORK were set. I'm not sure this is a *good* idea, but it is an idea that would avoid the export. For now I change the export to _GPL. Thanks, NeilBrown
