* [Virtio-fs] when not to forget explicitly
@ 2020-12-06 10:46 Laszlo Ersek
2020-12-07 8:26 ` Miklos Szeredi
0 siblings, 1 reply; 2+ messages in thread
From: Laszlo Ersek @ 2020-12-06 10:46 UTC (permalink / raw)
To: Miklos Szeredi; +Cc: virtio-fs
Hi Miklos,
what FUSE requests are those after which the client is not supposed to
ask the server to forget a nodeid?
I'm surprised to see the following comment in
"tools/virtiofsd/passthrough_ll.c", in "struct lo_inode":
/*
* This counter keeps the inode alive during the FUSE session.
* Incremented when the FUSE inode number is sent in a reply
* (FUSE_LOOKUP, FUSE_READDIRPLUS, etc). Decremented when an inode is
* released by requests like FUSE_FORGET, FUSE_RMDIR, FUSE_RENAME, etc.
*
* Note that this value is untrusted because the client can manipulate
* it arbitrarily using FUSE_FORGET requests.
*
* Protected by lo->mutex.
*/
uint64_t nlookup;
I can identify the places in my FUSE client code where I learn of a new
inode, but I can't tell what requests include an automatic "forget".
The above mentions FUSE_RMDIR, which I didn't expect. I guess it also
applies to FUSE_UNLINK. Is there anything else?
I'd really appreciate an exhaustive list of request types that
auto-forget :)
Thank you!
Laszlo
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [Virtio-fs] when not to forget explicitly
2020-12-06 10:46 [Virtio-fs] when not to forget explicitly Laszlo Ersek
@ 2020-12-07 8:26 ` Miklos Szeredi
0 siblings, 0 replies; 2+ messages in thread
From: Miklos Szeredi @ 2020-12-07 8:26 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: virtio-fs-list
On Sun, Dec 6, 2020 at 11:46 AM Laszlo Ersek <lersek@redhat.com> wrote:
>
> Hi Miklos,
>
> what FUSE requests are those after which the client is not supposed to
> ask the server to forget a nodeid?
>
> I'm surprised to see the following comment in
> "tools/virtiofsd/passthrough_ll.c", in "struct lo_inode":
>
> /*
> * This counter keeps the inode alive during the FUSE session.
> * Incremented when the FUSE inode number is sent in a reply
> * (FUSE_LOOKUP, FUSE_READDIRPLUS, etc). Decremented when an inode is
> * released by requests like FUSE_FORGET, FUSE_RMDIR, FUSE_RENAME, etc.
> *
> * Note that this value is untrusted because the client can manipulate
> * it arbitrarily using FUSE_FORGET requests.
> *
> * Protected by lo->mutex.
> */
> uint64_t nlookup;
>
> I can identify the places in my FUSE client code where I learn of a new
> inode, but I can't tell what requests include an automatic "forget".
>
> The above mentions FUSE_RMDIR, which I didn't expect. I guess it also
> applies to FUSE_UNLINK. Is there anything else?
Nope, the comment is wrong. It is only decremented on FUSE_FORGET.
Thanks,
Miklos
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2020-12-07 8:26 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-06 10:46 [Virtio-fs] when not to forget explicitly Laszlo Ersek
2020-12-07 8:26 ` Miklos Szeredi
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.