On 10/25, Chuck Lever wrote: > > On Wed, Oct 25, 2023 at 07:54:36PM +0200, Oleg Nesterov wrote: > > On 10/25, Chuck Lever wrote: > > > > > > > Another question is why we can't simply turn nn->writeverf into seqcount_t. > > > > I guess we can't because nfsd_reset_write_verifier() needs spin_lock() to > > > > serialise with itself, right? > > > > > > "reset" is supposed to be very rare operation. Using a lock in that > > > case is probably quite acceptable, as long as reading the verifier > > > is wait-free and guaranteed to be untorn. > > > > > > But a seqcount_t is only 32 bits. > > > > Again, I don't understand you. > > > > Once again, we can turn writeverf into seqcount_t, see the patch below. > > The patch below does not turn "writeverf" into a seqcount_t, it > turns "writeverf_lock" into a seqcount_t. Yes, typo. Of course I meant writeverf_lock. A bit strange it was not clear. > Your original proposal made no sense. Which one??? I thought that you agree that the current nfsd_copy_write_verifier() code makes no send, at least that is how I interpreted your previous email. Confused. > But I see now what you > would like to change. OK, > I'm not familiar enough with these primitives to have a strong > opinion. What do you think would be the benefit? See above. And just in case let me repeat. No, I don't think we can/should turn writeverf_lock (double check I didn't say "writeverf") into seqcount_t. Oleg.
