From owner-freebsd-arch@FreeBSD.ORG  Wed Jan 25 00:17:18 2006
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
X-Original-To: arch@freebsd.org
Delivered-To: freebsd-arch@FreeBSD.ORG
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by hub.freebsd.org (Postfix) with ESMTP id BC28716A41F
	for <arch@freebsd.org>; Wed, 25 Jan 2006 00:17:17 +0000 (GMT)
	(envelope-from davidxu@freebsd.org)
Message-ID: <43D6C3A5.4060100@freebsd.org>
Date: Wed, 25 Jan 2006 08:17:41 +0800
From: David Xu <davidxu@freebsd.org>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US;
	rv:1.7.12) Gecko/20060117
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: arch@freebsd.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: 
Subject: vfs_aio.c is still not safe
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Jan 2006 00:17:18 -0000

Even with recently change to vfs_aio.c, the kernel AIO code is
still not safe to be used. The problem is a AIO daemon thread
may be blocked on sockets, pipe, and fifo if peer does not
transfer any data, the problem can be accumulated and all
daemon threads will be blocked if such user process increases.
I don't know who hacked socket code to support some level of
callback, it seems work, but in fact, it may only work for
first AIO request, if user queued multiple requests, same problem
will happen, I tried to workaround this problem by using
non-blocking I/O, but with current file ops, there is no such
support, I can not change O_NONBLOCK on fly because userland
and kernel have race, PR: kernel/41331 is a well explained
problem, userland will hit the race.

So possible solution could be:
1) disable AIO support for none disk file.
2) someone implement callbacks for pipe, fifo, and add
   non-blocking feature to fo_read/fo_write.

The former is simple, the later needs some effort, however
with superio kqueue, the AIO support for socket and pipe is
less important, I prefer 1) to make the AIO code usable.

David Xu