On Thu, Sep 11, 2014 at 6:14 PM, Maxim Patlasov <mpatla...@parallels.com> wrote:
> I really need your help to proceed with this patch. Could you please explain > what those places are where we should allow interruption. > > BTW, as for "just an optimization", I've recently noticed that __fput() > calls locks_remove_file(). So guarantees provided by the patch-set are on > the same level as flock(2) behaviour. SIGKILL trumps that. At least that's what I think, and that's what NFS currently does as well, AFAICS. > >> >> Also fuse really should distinguish fatal and non-fatal interruptions >> and handle them accordingly... > > > And elaborate on this concern, please. Requests have two states where they stay for any significant amount of time: PENDING (queued to userspace) and SENT (in userspace). Currently we do the following for interrupted requests: PENDING: - non-fatal signal: do nothing - fatal signal: dequeue and return -EINTR, unless force is set SENT: - send INTERRUPT request to userspace This is fine, but fatal interrupts should be able to abort SENT and forced requests as well without having to wait for the userspace reply. This is what I was referring to. This would not be difficult, were it not for i_mutex and s_vfs_rename_mutex being held by some operations. For correctness, we can't release these while a reply is not received, since the locking expecations of the userspace filesystem would not be met. This can be solved by adding shadow locks to fuse that we hold onto even after the request is interrupted. Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
