ENOENT as an ioctl return code

ENOENT as an ioctl return code

[Thomas Hellstrom]

Hi,

By concidence I ran across this lkml message

http://marc.info/?l=linux-kernel&m=135628421403144&w=2

with an important part in the middle: (this is not a drm commit)

To make matters worse, commit f0ed2ce840b3 is clearly total and utter
CRAP even if it didn't break applications. ENOENT is not a valid error
return from an ioctl. Never has been, never will be. ENOENT means "No
such file and directory", and is for path operations. ioctl's are done
on files that have already been opened, there's no way in hell that
ENOENT would ever be valid.

Perhaps we should rethink the use of ENOENT when not finding mode objects?

Thanks,
Thomas

Re: ENOENT as an ioctl return code

[Daniel Vetter]

On Tue, Dec 03, 2013 at 09:09:40PM +0100, Thomas Hellstrom wrote:
> Hi,
> 
> By concidence I ran across this lkml message
> 
> http://marc.info/?l=linux-kernel&m=135628421403144&w=2
> 
> with an important part in the middle: (this is not a drm commit)
> 
> To make matters worse, commit f0ed2ce840b3 is clearly total and utter
> CRAP even if it didn't break applications. ENOENT is not a valid error
> return from an ioctl. Never has been, never will be. ENOENT means "No
> such file and directory", and is for path operations. ioctl's are done
> on files that have already been opened, there's no way in hell that
> ENOENT would ever be valid.
> 
> Perhaps we should rethink the use of ENOENT when not finding mode objects?

Yeah, it's somewhat abuse, otoh if we'd do a dma-buf export telling
userspace that "no such file exists" is a pretty precise answer. In a way
we _do_ duplicate file objects ... And having this special error code for
lookup failures is occasionally rather useful imo.

So honestly I'd prefer we keep on doing our practice.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: ENOENT as an ioctl return code

[Thomas Hellstrom]

On 12/03/2013 09:41 PM, Daniel Vetter wrote:
> On Tue, Dec 03, 2013 at 09:09:40PM +0100, Thomas Hellstrom wrote:
>> Hi,
>>
>> By concidence I ran across this lkml message
>>
>> http://marc.info/?l=linux-kernel&m=135628421403144&w=2
>>
>> with an important part in the middle: (this is not a drm commit)
>>
>> To make matters worse, commit f0ed2ce840b3 is clearly total and utter
>> CRAP even if it didn't break applications. ENOENT is not a valid error
>> return from an ioctl. Never has been, never will be. ENOENT means "No
>> such file and directory", and is for path operations. ioctl's are done
>> on files that have already been opened, there's no way in hell that
>> ENOENT would ever be valid.
>>
>> Perhaps we should rethink the use of ENOENT when not finding mode objects?
> Yeah, it's somewhat abuse, otoh if we'd do a dma-buf export telling
> userspace that "no such file exists" is a pretty precise answer. In a way
> we _do_ duplicate file objects ... And having this special error code for
> lookup failures is occasionally rather useful imo.
>
> So honestly I'd prefer we keep on doing our practice.

Hmm, yes, I figure this might have originated in the GEM ioctls that was 
actually trying to mimic file behavior,
but then spilled over to the mode objects in the modesetting code...

Just thought I'd raise the issue since I saw that message..

Thanks,
Thomas


> -Daniel

Re: ENOENT as an ioctl return code

[Dave Airlie]

On Wed, Dec 4, 2013 at 7:13 AM, Thomas Hellstrom <thomas@shipmail.org> wrote:
> On 12/03/2013 09:41 PM, Daniel Vetter wrote:
>>
>> On Tue, Dec 03, 2013 at 09:09:40PM +0100, Thomas Hellstrom wrote:
>>>
>>> Hi,
>>>
>>> By concidence I ran across this lkml message
>>>
>>> http://marc.info/?l=linux-kernel&m=135628421403144&w=2
>>>
>>> with an important part in the middle: (this is not a drm commit)
>>>
>>> To make matters worse, commit f0ed2ce840b3 is clearly total and utter
>>> CRAP even if it didn't break applications. ENOENT is not a valid error
>>> return from an ioctl. Never has been, never will be. ENOENT means "No
>>> such file and directory", and is for path operations. ioctl's are done
>>> on files that have already been opened, there's no way in hell that
>>> ENOENT would ever be valid.
>>>
>>> Perhaps we should rethink the use of ENOENT when not finding mode
>>> objects?
>>
>> Yeah, it's somewhat abuse, otoh if we'd do a dma-buf export telling
>> userspace that "no such file exists" is a pretty precise answer. In a way
>> we _do_ duplicate file objects ... And having this special error code for
>> lookup failures is occasionally rather useful imo.
>>
>> So honestly I'd prefer we keep on doing our practice.
>
>
> Hmm, yes, I figure this might have originated in the GEM ioctls that was
> actually trying to mimic file behavior,
> but then spilled over to the mode objects in the modesetting code...
>
> Just thought I'd raise the issue since I saw that message..
>

We just need to make sure userspace relies on it, then we can't change it :-P

Linus would enter an infinite loop and possibly explode.

Dave.