Re: Weirdness when writing to pseudofs file

From: Johannes Lundberg <johalun_at_FreeBSD.org>
Date: Wed, 22 May 2019 13:57:40 -0700
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 <johalun_at_freebsd.org> 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,
...
}
Received on Wed May 22 2019 - 18:57:42 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:20 UTC