On Sun, Oct 01, 2023 at 11:08:16PM +0200, Florian Westphal wrote: > Not convinced. In particular, I don't understand what this has to do > with async vs. sync gc. To me this depends how we want to handle > elements that have expired or expire during transaction. > > Example: > > Element E1, times out in 1 hour > Element E2, times out in 1 second > Element E3, timed out (1 second ago, 3 minutes ago, doesn't matter). > > Userspace batch to kernel: > Update Element E1 to time out in 2 hours. > Update Element E2 to time out in 1 hour. > Update Element E3 to time out in 1 hour. > > What is the expected outcome of this request? > > Ignore E3 being reaped already and refresh the timeout (resurrection?) No resurrection, the element might have counters, it already expired. > Ignore E3 being reaped already and ignore the request? > Fail the transaction as E3 timed out already ("does not exist")? Add a new E3. If NLM_F_EXCL is specified, then fail with "does not exist" > Now, what about E2? If transaction is large, it could become > like E3 *during the transaction* unless we introduce some freezing > mechanism. Whats the expected outcome? > > Whats the expected outcome if there is some other, unrelated > failure? I assume we have to roll back all the timeout updates, right? We annotate the new timeout in transaction object, then refresh the timeout update in the commit phase. > If so, why not temporarily make the timeouts effective right away > and then roll back? You mean, from the preparation phase? Then we need to undo what has been done, in case of --check / abort path is exercised, this might just create a bogus element listing. > What if userspace asks to *shrink* timeouts? Same scenario: > > Update Element E1 to time out in 1 second > Update Element E2 to time out in 1 second > Update Element E3 to time out in 1 second > > We could say 'not supported' of course, would avoid the > rollback headache, because in this case long transaction > gc would definitely start to pick some of those elements > up for reaping... No need for rollback if new timeout is store in the transaction object, we just set the new timeout from _commit() step in the NEWSETELEM case, which has to deal with updates. Other objects follow a similar approach.