On Wed, Oct 04, 2023 at 04:32:26PM +0200, Pablo Neira Ayuso wrote: > On Wed, Oct 04, 2023 at 02:48:45PM +0200, Florian Westphal wrote: > > I also think we need to find a different strategy for the > > dump-and-reset part when the reset could be interrupted > > by a transaction. > > I think it should be possible to deal with this from userspace. > > The idea would be to keep the old cache. Then, from the new cache, if > EINTR happened before, iterate over the list of objects in the new > cache and then lookup for the old objects, then pour the stats from > the old to the new objects, then release old cache. Then only one old > cache is kept around in worst case. This needs a lookup function for > each stateful object type on the old cache based on the handle. In case of EINTR, user space will reset multiple times, right? So returned state from generation X must be combined with that from generation X+1. Easy with counters (val1 + val2) but funny and/or inconsistent with quotas (val1 - val2 might be < 0). I'd still just declare reset command for multiple items unreliable and point out the need for scripts to use a combination of list command and a number of reset commands for the individual items if the actual values matter. I just noticed, for the above to be viable 'reset rule' command must be changed - it is silent right now. Cheers, Phil
