On Wed, 24 Aug 2022 at 21:00, lepton <ytht.net@xxxxxxxxx> wrote: > > On Mon, Aug 22, 2022 at 6:37 AM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > > > On Wed, 29 Jul 2020 at 01:45, Lepton Wu <ytht.net@xxxxxxxxx> wrote: > > > > > > With this, user space can have more control to just abort some kind of > > > fuse connections. Currently, in Android, it will write to abort file > > > to abort all fuse connections while in some cases, we'd like to keep > > > some fuse connections. This can help that. > > > > You can grep the same info from /proc/self/mountinfo. Why does that not work? > Hi Miklos, thanks for this hint. That will work. But the code in user > space will be more complicated and not straightforward. > For now, I can see 2 issues with mountinfo: > 1. one connection could have multiple entries under > /proc/self/mountinfo if there are bind mounts, user space code needs > to handle that. Using the first match should be okay, bind mounts will have the same filesystem type. > 2. /proc/self/mountinfo is limited by namespace, so in theory, some > connection under /sys/fs/fuse/connections could be missed in it. True. OTOH this could be a security issue as well, since the point of namespaces is to hide information. > While this isn't an issue > for the current android code, maybe it could get broken in the future. > > Overall, I am feeling my kernel patch is a straightforward and simple > solution and it's just one more attribute under > /sys/fs/fuse/connections, may I know if there are any downsides to > doing this? Your patch adds an ad-hoc interface for a very specific purpose with likely no other users. As long as this information can be gotten in other ways there's no compelling reason to add a new interface. Thanks, Miklos