From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Moyer Subject: Re: [PATCH] aio: Do not return ERESTARTSYS as a result of AIO (v2) Date: Thu, 09 Sep 2010 15:49:19 -0400 Message-ID: References: <1284060970-26829-1-git-send-email-jack@suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andrew Morton , linux-fsdevel@vger.kernel.org, Christoph Hellwig To: Jan Kara Return-path: Received: from mx1.redhat.com ([209.132.183.28]:30970 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755778Ab0IITyX (ORCPT ); Thu, 9 Sep 2010 15:54:23 -0400 In-Reply-To: <1284060970-26829-1-git-send-email-jack@suse.cz> (Jan Kara's message of "Thu, 9 Sep 2010 21:36:10 +0200") Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Jan Kara writes: > OCFS2 can return ERESTARTSYS from its write function when the process is > signalled while waiting for a cluster lock (and the filesystem is mounted with > intr mount option). Generally, it seems reasonable to allow filesystems to > return this error code from its IO functions. As we must not leak ERESTARTSYS > (and similar error codes) to userspace as a result of an AIO operation, we > have to properly convert it to EINTR inside AIO code (restarting the syscall > isn't really an option because other AIO could have been already submitted by > the same io_submit syscall). I had responded to your last posting with: This is a confusing problem description. First, I'm assuming you actually experienced this, is that right? Care to share the details of that? The above paragraph I think you addressed. I'm still curious about this, though. The submission path should be as non-blocking as possible. I guess you can't really get around locking, though. Was the problem witnessed when doing O_DIRECT or buffered AIO? Next, assuming we can get ERSTARTSYS and friends, it will be the return code of a single iocb (reaped via io_getevents), not the return code of the io_submit system call. I'm not saying this is right, I'm just saying that your description of the problem is misleading. That objection stands, but just warrants correcting the problem description. Anyway, the code itself looks fine. ;-) Reviewed-by: Jeff Moyer