Re: [PATCH v3 1/6] io_uring/mock: add basic infra for test mock files

[Jens Axboe <axboe@kernel.dk>]

On 5/30/25 6:21 AM, Pavel Begunkov wrote:
> On 5/30/25 12:48, Jens Axboe wrote:
>> On 5/30/25 5:45 AM, Pavel Begunkov wrote:
>>> On 5/30/25 12:31, Jens Axboe wrote:
>>>> On 5/30/25 2:38 AM, Pavel Begunkov wrote:
>>>>> io_uring commands provide an ioctl style interface for files to
>>>>> implement file specific operations. io_uring provides many features and
>>>>> advanced api to commands, and it's getting hard to test as it requires
>>>>> specific files/devices.
>>>>>
>>>>> Add basic infrastucture for creating special mock files that will be
>>>>> implementing the cmd api and using various io_uring features we want to
>>>>> test. It'll also be useful to test some more obscure read/write/polling
>>>>> edge cases in the future.
>>>>
>>>> Do we want to have the creation of a mock file be a privileged
>>>> operation?
>>>
>>> It doesn't do anything that would warrant that, maybe just yet.
>>> Do you mean from the security perspective? i.e. making sure a
>>> user can't exploit it if there is anything to be exploited.
>>> I'd really hope nobody would compile this thing for non-test
>>> kernels. Maybe I should make it dependent on lockdep to enforce
>>> it.
>>
>> People do all sorts of weird stuff. I know it doesn't do anything
>> that warrants making it root only, but at least as root only, any
>> side effects will be limited to that. I think that'd be better than
>> making it forcibly depend on something unrelated (but debug'y) like
>> lockdep.
> 
> I don't hate the CAP_ADMIN idea, I'll add it, but making it
> dependent on something incompatible with production kernels is
> the only way to ensure it's used in the intended way.

But any kind of dependency like lockdep will mean that I cannot run
testing without lockdep, or whatever else the dependency might be. I
think that'd be rather unfortunate, I tend to test with both a "stock"
kind of config, and a KASAN && PROVE_LOCKING setup.

So I really don't think we should limit ourselves that way, attempting
to stop a weird use case by adding artificial dependencies.

-- 
Jens Axboe