Re: Weirdness when writing to pseudofs file

From: Alan Somers <asomers_at_freebsd.org>
Date: Wed, 22 May 2019 17:57:13 -0600
On Wed, May 22, 2019 at 5:33 PM Johannes Lundberg <johalun_at_freebsd.org> wrote:
>
>
> On 5/22/19 4:22 PM, Alan Somers wrote:
> > On Wed, May 22, 2019 at 5:18 PM Johannes Lundberg <johalun_at_freebsd.org> 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 <johalun_at_freebsd.org> 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
Received on Wed May 22 2019 - 21:57:28 UTC

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