On Thu, Apr 02, 2020 at 01:55:19PM -0700, Ira Weiny wrote: > > I'd just return an error for that case, don't play silly games like > > evicting the inode. > > I think I agree with Christoph here. But I want to clarify. I was heading in > a direction of failing the ioctl completely. But we could have the flag change > with an appropriate error which could let the user know the change has been > delayed. > > But I don't immediately see what error code is appropriate for such an > indication. Candidates I can envision: > > EAGAIN > ERESTART > EUSERS > EINPROGRESS > > None are perfect but I'm leaning toward EINPROGRESS. I really, really dislike that idea. The whole point of not forcing evictions is to make it clear - no this inode is "busy" you can't do that. A reasonably smart application can try to evict itself. But returning an error and doing a lazy change anyway is straight from the playbook for arcane and confusing API designs.
