On 9/22/2026 4:04 PM, Christian König wrote: > On 9/22/26 09:55, Huang Rui wrote: > ... >>> As far as I can see we have solved the problems at hand and the rules how >>> to handle the user queues should be pretty clear by now. >>> >> Assuming every kref_get() has a matching kref_put(), and the queue object >> itself does not participate in a circular ownership chain, I don't >> immediately see how taking a temporary queue reference would cause >> correctness issues. > The reference on the user queue object is meant to keep it alive for the > duration of IOCTLs, e.g. prevent concurrent destruction from the close IOCTL.
why only IOCTL???? Since the kref has been embedded in the struct user queue, it should keep the queue alive during ANY OPERATIONS, Not only IOCTL. Or it will race with the destruction callback in kref_put, and causing UAF problems. Do you see any kernel documents says that kref should only be used in ioctl contexts? > > It CAN'T be used to grab references from either atomic, interrupt or worker > context since then you can't drop the reference any more without risking > destruction from non IOCTL context which in turn causes tons of lifetime > problems. > > This is just standard refcounting rules to keep objects alive during an IOCTL. Where do you see such standard? It is just a atomic number, not a lock. >> Could you please point us to the historical issue or the corresponding >> commits that led to removing this approach previously? > See Sunils original approach, he made exactly the same mistake and I already > had to fix that back then. > > I don't remember if it was actually committed or if we only discussed that on > the mailing list. > > Regards, > Christian. > >> Thanks, >> Ray
