Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <d4a8f2a4-b662-19c2-f3ad-cc27fcd5211c@kernel.dk>
Date:   Wed, 7 Sep 2022 08:12:23 -0600
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.1
Subject: Re: [PATCH] kernel: export task_work_add
Content-Language: en-US
To:     Christoph Hellwig <hch@lst.de>
Cc:     Bart Van Assche <bvanassche@acm.org>,
        Ming Lei <ming.lei@redhat.com>, linux-kernel@vger.kernel.org,
        linux-block@vger.kernel.org
References: <20220829040013.549212-1-ming.lei@redhat.com>
 <5a1b3716-bcf8-8c37-2bd5-44e885de1f48@acm.org>
 <2d4655d4-2510-eb1e-2e4d-9d910e823293@kernel.dk>
 <20220907140550.GA21414@lst.de>
From:   Jens Axboe <axboe@kernel.dk>
In-Reply-To: <20220907140550.GA21414@lst.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 9/7/22 8:05 AM, Christoph Hellwig wrote:
> On Wed, Sep 07, 2022 at 07:44:05AM -0600, Jens Axboe wrote:
>> On the patch itself, it definitely makes sense in the context of ublk.
>> My hesitation is mostly around not really wanting to export this to
>> generic modular users. It's OK for core interfaces, of which ublk is
>> on the way to becoming, but I really don't like the idea of random
>> modules using it. But that's not really something we can manage with
>> the export, it's either exported or it's not...
> 
> Yes, I'm really worried about folks doing stupid things with it.
> Thinking of the whole loop saga..

Exactly. But we don't really have any tools outside of clearly marking
it as such. It's not like we have an EXPORT_MODULE_CORE_GPL() and with
that requiring a driver or modular kernel feature that marks the module
as MODULE_IS_CORE_GPL().

-- 
Jens Axboe