Weirdness when writing to pseudofs file

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Weirdness when writing to pseudofs file

Johannes Lundberg-2
Hi

I'm fiddling with lindebugfs, which is based on pseudofs. When writing
to a file,

this works: # echo  1 >> /path/to/file

but this does not: # echo 1 > /path/to/file

"Operation not supported." is returned before the pseudofs code is even
entered.

Is this expected behavior? (if so, why?)

Thanks in advance
/Johannes



_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Weirdness when writing to pseudofs file

Konstantin Belousov
On Wed, May 22, 2019 at 10:36:34AM -0700, Johannes Lundberg wrote:

> Hi
>
> I'm fiddling with lindebugfs, which is based on pseudofs. When writing
> to a file,
>
> this works: # echo  1 >> /path/to/file
>
> but this does not: # echo 1 > /path/to/file
>
> "Operation not supported." is returned before the pseudofs code is even
> entered.
>
> Is this expected behavior? (if so, why?)

Does the file exist ?

Pseudofs does not implement VOP_CREATE(), which is reasonable.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Weirdness when writing to pseudofs file

Johannes Lundberg-2

On 5/22/19 10:51 AM, Konstantin Belousov wrote:

> On Wed, May 22, 2019 at 10:36:34AM -0700, Johannes Lundberg wrote:
>> Hi
>>
>> I'm fiddling with lindebugfs, which is based on pseudofs. When writing
>> to a file,
>>
>> this works: # echo  1 >> /path/to/file
>>
>> but this does not: # echo 1 > /path/to/file
>>
>> "Operation not supported." is returned before the pseudofs code is even
>> entered.
>>
>> Is this expected behavior? (if so, why?)
> Does the file exist ?
>
> Pseudofs does not implement VOP_CREATE(), which is reasonable.

Yes, it exists and my custom write function is receiving the call for
">>". (which is for example used by drm driver debugfs to do certain
things on demand by accepting write to a debugfs file)


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Weirdness when writing to pseudofs file

Alan Somers-2
On Wed, May 22, 2019 at 11:59 AM Johannes Lundberg <[hidden email]> wrote:

>
>
> On 5/22/19 10:51 AM, Konstantin Belousov wrote:
> > On Wed, May 22, 2019 at 10:36:34AM -0700, Johannes Lundberg wrote:
> >> Hi
> >>
> >> I'm fiddling with lindebugfs, which is based on pseudofs. When writing
> >> to a file,
> >>
> >> this works: # echo  1 >> /path/to/file
> >>
> >> but this does not: # echo 1 > /path/to/file
> >>
> >> "Operation not supported." is returned before the pseudofs code is even
> >> entered.
> >>
> >> Is this expected behavior? (if so, why?)
> > Does the file exist ?
> >
> > Pseudofs does not implement VOP_CREATE(), which is reasonable.
>
> Yes, it exists and my custom write function is receiving the call for
> ">>". (which is for example used by drm driver debugfs to do certain
> things on demand by accepting write to a debugfs file)

First, you need to try ktrace to see exactly which system call is not
supported.  If the problem still isn't obvious, then you can try
dtrace to see exactly which VOP isn't suppoted.  Do it like this:

sudo ktrace /bin/sh -c "echo 1 > /path/to/file"
sudo kdump
sudo dtrace -i 'fbt:::return /arg1 == 45/ {trace(".")}' -c "/bin/sh -c
'echo 1 > /path/to/file/'"

The dtrace command will show you which function returned EOPNOTSUPP.
However, it will also show a lot of functions that coincidentally
return 45 even though it's not an errno, and even functions that
return void.

-Alan
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Weirdness when writing to pseudofs file

Johannes Lundberg-2

On 5/22/19 11:03 AM, Alan Somers wrote:

> On Wed, May 22, 2019 at 11:59 AM Johannes Lundberg <[hidden email]> wrote:
>>
>> On 5/22/19 10:51 AM, Konstantin Belousov wrote:
>>> On Wed, May 22, 2019 at 10:36:34AM -0700, Johannes Lundberg wrote:
>>>> Hi
>>>>
>>>> I'm fiddling with lindebugfs, which is based on pseudofs. When writing
>>>> to a file,
>>>>
>>>> this works: # echo  1 >> /path/to/file
>>>>
>>>> but this does not: # echo 1 > /path/to/file
>>>>
>>>> "Operation not supported." is returned before the pseudofs code is even
>>>> entered.
>>>>
>>>> Is this expected behavior? (if so, why?)
>>> Does the file exist ?
>>>
>>> Pseudofs does not implement VOP_CREATE(), which is reasonable.
>> Yes, it exists and my custom write function is receiving the call for
>> ">>". (which is for example used by drm driver debugfs to do certain
>> things on demand by accepting write to a debugfs file)
> First, you need to try ktrace to see exactly which system call is not
> supported.  If the problem still isn't obvious, then you can try
> dtrace to see exactly which VOP isn't suppoted.  Do it like this:
>
> sudo ktrace /bin/sh -c "echo 1 > /path/to/file"
> sudo kdump
> sudo dtrace -i 'fbt:::return /arg1 == 45/ {trace(".")}' -c "/bin/sh -c
> 'echo 1 > /path/to/file/'"
>
> The dtrace command will show you which function returned EOPNOTSUPP.
> However, it will also show a lot of functions that coincidentally
> return 45 even though it's not an errno, and even functions that
> return void.
>
> -Alan


Thanks!

It seems, a single '>' will cause it to try to create the file (even
though it already exists) and that fails (kern_openat).


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Weirdness when writing to pseudofs file

Johannes Lundberg-2

On 5/22/19 1:53 PM, Johannes Lundberg wrote:

> On 5/22/19 11:03 AM, Alan Somers wrote:
>> On Wed, May 22, 2019 at 11:59 AM Johannes Lundberg <[hidden email]> wrote:
>>> On 5/22/19 10:51 AM, Konstantin Belousov wrote:
>>>> On Wed, May 22, 2019 at 10:36:34AM -0700, Johannes Lundberg wrote:
>>>>> Hi
>>>>>
>>>>> I'm fiddling with lindebugfs, which is based on pseudofs. When writing
>>>>> to a file,
>>>>>
>>>>> this works: # echo  1 >> /path/to/file
>>>>>
>>>>> but this does not: # echo 1 > /path/to/file
>>>>>
>>>>> "Operation not supported." is returned before the pseudofs code is even
>>>>> entered.
>>>>>
>>>>> Is this expected behavior? (if so, why?)
>>>> Does the file exist ?
>>>>
>>>> Pseudofs does not implement VOP_CREATE(), which is reasonable.
>>> Yes, it exists and my custom write function is receiving the call for
>>> ">>". (which is for example used by drm driver debugfs to do certain
>>> things on demand by accepting write to a debugfs file)
>> First, you need to try ktrace to see exactly which system call is not
>> supported.  If the problem still isn't obvious, then you can try
>> dtrace to see exactly which VOP isn't suppoted.  Do it like this:
>>
>> sudo ktrace /bin/sh -c "echo 1 > /path/to/file"
>> sudo kdump
>> sudo dtrace -i 'fbt:::return /arg1 == 45/ {trace(".")}' -c "/bin/sh -c
>> 'echo 1 > /path/to/file/'"
>>
>> The dtrace command will show you which function returned EOPNOTSUPP.
>> However, it will also show a lot of functions that coincidentally
>> return 45 even though it's not an errno, and even functions that
>> return void.
>>
>> -Alan
>
> Thanks!
>
> It seems, a single '>' will cause it to try to create the file (even
> though it already exists) and that fails (kern_openat).
>
I would guess because of

https://github.com/freebsd/freebsd/blob/master/sys/fs/pseudofs/pseudofs_vnops.c#L1042

struct vop_vector pfs_vnodeops = {
...
.vop_create = VOP_EOPNOTSUPP,
...
}

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Weirdness when writing to pseudofs file

Mark Johnston-2
In reply to this post by Alan Somers-2
On Wed, May 22, 2019 at 12:03:00PM -0600, Alan Somers wrote:

> On Wed, May 22, 2019 at 11:59 AM Johannes Lundberg <[hidden email]> wrote:
> >
> >
> > On 5/22/19 10:51 AM, Konstantin Belousov wrote:
> > > On Wed, May 22, 2019 at 10:36:34AM -0700, Johannes Lundberg wrote:
> > >> Hi
> > >>
> > >> I'm fiddling with lindebugfs, which is based on pseudofs. When writing
> > >> to a file,
> > >>
> > >> this works: # echo  1 >> /path/to/file
> > >>
> > >> but this does not: # echo 1 > /path/to/file
> > >>
> > >> "Operation not supported." is returned before the pseudofs code is even
> > >> entered.
> > >>
> > >> Is this expected behavior? (if so, why?)
> > > Does the file exist ?
> > >
> > > Pseudofs does not implement VOP_CREATE(), which is reasonable.
> >
> > Yes, it exists and my custom write function is receiving the call for
> > ">>". (which is for example used by drm driver debugfs to do certain
> > things on demand by accepting write to a debugfs file)
>
> First, you need to try ktrace to see exactly which system call is not
> supported.  If the problem still isn't obvious, then you can try
> dtrace to see exactly which VOP isn't suppoted.  Do it like this:
>
> sudo ktrace /bin/sh -c "echo 1 > /path/to/file"
> sudo kdump
> sudo dtrace -i 'fbt:::return /arg1 == 45/ {trace(".")}' -c "/bin/sh -c
> 'echo 1 > /path/to/file/'"
>
> The dtrace command will show you which function returned EOPNOTSUPP.
> However, it will also show a lot of functions that coincidentally
> return 45 even though it's not an errno, and even functions that
> return void.

You can also trace VOPs with vfs::vop_*:return.  The return value is in
args[2].
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Weirdness when writing to pseudofs file

Conrad Meyer-2
In reply to this post by Johannes Lundberg-2
On Wed, May 22, 2019 at 1:58 PM Johannes Lundberg <[hidden email]> wrote:

> > It seems, a single '>' will cause it to try to create the file (even
> > though it already exists) and that fails (kern_openat).
> >
> I would guess because of
>
> https://github.com/freebsd/freebsd/blob/master/sys/fs/pseudofs/pseudofs_vnops.c#L1042
>
> struct vop_vector pfs_vnodeops = {
> ...
> .vop_create = VOP_EOPNOTSUPP,
> ...
> }

kern_openat -> vn_open(_cred) should only call VOP_CREATE if namei()
cannot find the named vnode (ni_vp == NULL).  Otherwise, it should
just invoke VOP_OPEN.  This suggests there might be a lookup bug in
pfs?  Tracing VOPs as Mark suggested seems like a good next step.

Best,
Conrad
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Weirdness when writing to pseudofs file

Johannes Lundberg-2

On 5/22/19 3:02 PM, Conrad Meyer wrote:

> On Wed, May 22, 2019 at 1:58 PM Johannes Lundberg <[hidden email]> wrote:
>>> It seems, a single '>' will cause it to try to create the file (even
>>> though it already exists) and that fails (kern_openat).
>>>
>> I would guess because of
>>
>> https://github.com/freebsd/freebsd/blob/master/sys/fs/pseudofs/pseudofs_vnops.c#L1042
>>
>> struct vop_vector pfs_vnodeops = {
>> ...
>> .vop_create = VOP_EOPNOTSUPP,
>> ...
>> }
> kern_openat -> vn_open(_cred) should only call VOP_CREATE if namei()
> cannot find the named vnode (ni_vp == NULL).  Otherwise, it should
> just invoke VOP_OPEN.  This suggests there might be a lookup bug in
> pfs?  Tracing VOPs as Mark suggested seems like a good next step.
>
> Best,
> Conrad

Thanks Conrad. Yeah, that makes sense that it would open instead of
recreating. Tracing a'la Mark points to

vop_getwritemount

failing.


_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Weirdness when writing to pseudofs file

Johannes Lundberg-2

On 5/22/19 4:12 PM, Johannes Lundberg wrote:

> On 5/22/19 3:02 PM, Conrad Meyer wrote:
>> On Wed, May 22, 2019 at 1:58 PM Johannes Lundberg <[hidden email]> wrote:
>>>> It seems, a single '>' will cause it to try to create the file (even
>>>> though it already exists) and that fails (kern_openat).
>>>>
>>> I would guess because of
>>>
>>> https://github.com/freebsd/freebsd/blob/master/sys/fs/pseudofs/pseudofs_vnops.c#L1042
>>>
>>> struct vop_vector pfs_vnodeops = {
>>> ...
>>> .vop_create = VOP_EOPNOTSUPP,
>>> ...
>>> }
>> kern_openat -> vn_open(_cred) should only call VOP_CREATE if namei()
>> cannot find the named vnode (ni_vp == NULL).  Otherwise, it should
>> just invoke VOP_OPEN.  This suggests there might be a lookup bug in
>> pfs?  Tracing VOPs as Mark suggested seems like a good next step.
>>
>> Best,
>> Conrad
> Thanks Conrad. Yeah, that makes sense that it would open instead of
> recreating. Tracing a'la Mark points to
>
> vop_getwritemount
>
> failing.

Actually vop_setattr also shows up in dtrace.

I'll continue digging..

>
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Weirdness when writing to pseudofs file

Alan Somers-2
On Wed, May 22, 2019 at 5:18 PM Johannes Lundberg <[hidden email]> wrote:

>
>
> On 5/22/19 4:12 PM, Johannes Lundberg wrote:
> > On 5/22/19 3:02 PM, Conrad Meyer wrote:
> >> On Wed, May 22, 2019 at 1:58 PM Johannes Lundberg <[hidden email]> wrote:
> >>>> It seems, a single '>' will cause it to try to create the file (even
> >>>> though it already exists) and that fails (kern_openat).
> >>>>
> >>> I would guess because of
> >>>
> >>> https://github.com/freebsd/freebsd/blob/master/sys/fs/pseudofs/pseudofs_vnops.c#L1042
> >>>
> >>> struct vop_vector pfs_vnodeops = {
> >>> ...
> >>> .vop_create = VOP_EOPNOTSUPP,
> >>> ...
> >>> }
> >> kern_openat -> vn_open(_cred) should only call VOP_CREATE if namei()
> >> cannot find the named vnode (ni_vp == NULL).  Otherwise, it should
> >> just invoke VOP_OPEN.  This suggests there might be a lookup bug in
> >> pfs?  Tracing VOPs as Mark suggested seems like a good next step.
> >>
> >> Best,
> >> Conrad
> > Thanks Conrad. Yeah, that makes sense that it would open instead of
> > recreating. Tracing a'la Mark points to
> >
> > vop_getwritemount
> >
> > failing.
>
> Actually vop_setattr also shows up in dtrace.
>
> I'll continue digging..

vop_setattr would get called to truncate the file's size down to 0.
That's probably called by sh which is opening the file with O_TRUNC.

-Alan
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Weirdness when writing to pseudofs file

Johannes Lundberg-2

On 5/22/19 4:22 PM, Alan Somers wrote:

> On Wed, May 22, 2019 at 5:18 PM Johannes Lundberg <[hidden email]> wrote:
>>
>> On 5/22/19 4:12 PM, Johannes Lundberg wrote:
>>> On 5/22/19 3:02 PM, Conrad Meyer wrote:
>>>> On Wed, May 22, 2019 at 1:58 PM Johannes Lundberg <[hidden email]> wrote:
>>>>>> It seems, a single '>' will cause it to try to create the file (even
>>>>>> though it already exists) and that fails (kern_openat).
>>>>>>
>>>>> I would guess because of
>>>>>
>>>>> https://github.com/freebsd/freebsd/blob/master/sys/fs/pseudofs/pseudofs_vnops.c#L1042
>>>>>
>>>>> struct vop_vector pfs_vnodeops = {
>>>>> ...
>>>>> .vop_create = VOP_EOPNOTSUPP,
>>>>> ...
>>>>> }
>>>> kern_openat -> vn_open(_cred) should only call VOP_CREATE if namei()
>>>> cannot find the named vnode (ni_vp == NULL).  Otherwise, it should
>>>> just invoke VOP_OPEN.  This suggests there might be a lookup bug in
>>>> pfs?  Tracing VOPs as Mark suggested seems like a good next step.
>>>>
>>>> Best,
>>>> Conrad
>>> Thanks Conrad. Yeah, that makes sense that it would open instead of
>>> recreating. Tracing a'la Mark points to
>>>
>>> vop_getwritemount
>>>
>>> failing.
>> Actually vop_setattr also shows up in dtrace.
>>
>> I'll continue digging..
> vop_setattr would get called to truncate the file's size down to 0.
> That's probably called by sh which is opening the file with O_TRUNC.
>
> -Alan

It works if I simply return 0 from pfs_setattr so that's the culprit
indeed. Hmm, wonder if there's any elegant solution to this..



_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: Weirdness when writing to pseudofs file

Alan Somers-2
On Wed, May 22, 2019 at 5:33 PM Johannes Lundberg <[hidden email]> wrote:

>
>
> On 5/22/19 4:22 PM, Alan Somers wrote:
> > On Wed, May 22, 2019 at 5:18 PM Johannes Lundberg <[hidden email]> wrote:
> >>
> >> On 5/22/19 4:12 PM, Johannes Lundberg wrote:
> >>> On 5/22/19 3:02 PM, Conrad Meyer wrote:
> >>>> On Wed, May 22, 2019 at 1:58 PM Johannes Lundberg <[hidden email]> wrote:
> >>>>>> It seems, a single '>' will cause it to try to create the file (even
> >>>>>> though it already exists) and that fails (kern_openat).
> >>>>>>
> >>>>> I would guess because of
> >>>>>
> >>>>> https://github.com/freebsd/freebsd/blob/master/sys/fs/pseudofs/pseudofs_vnops.c#L1042
> >>>>>
> >>>>> struct vop_vector pfs_vnodeops = {
> >>>>> ...
> >>>>> .vop_create = VOP_EOPNOTSUPP,
> >>>>> ...
> >>>>> }
> >>>> kern_openat -> vn_open(_cred) should only call VOP_CREATE if namei()
> >>>> cannot find the named vnode (ni_vp == NULL).  Otherwise, it should
> >>>> just invoke VOP_OPEN.  This suggests there might be a lookup bug in
> >>>> pfs?  Tracing VOPs as Mark suggested seems like a good next step.
> >>>>
> >>>> Best,
> >>>> Conrad
> >>> Thanks Conrad. Yeah, that makes sense that it would open instead of
> >>> recreating. Tracing a'la Mark points to
> >>>
> >>> vop_getwritemount
> >>>
> >>> failing.
> >> Actually vop_setattr also shows up in dtrace.
> >>
> >> I'll continue digging..
> > vop_setattr would get called to truncate the file's size down to 0.
> > That's probably called by sh which is opening the file with O_TRUNC.
> >
> > -Alan
>
> It works if I simply return 0 from pfs_setattr so that's the culprit
> indeed. Hmm, wonder if there's any elegant solution to this..

I think it would be legal to return 0 and ignore unchangeable
attributes.  After all, you aren't aiming for a full POSIX-compliant
file system here.

-Alan
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"