Date: Wed, 29 Apr 2009 00:59:30 -0700
From: Andrew Morton <akpm@linux-foundation.org>
To: Nikanth Karthikesan <knikanth@novell.com>
Cc: Jens Axboe <jens.axboe@oracle.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH][RFC] Handle improbable possibility of
 io_context->refcount overflow
Message-Id: <20090429005930.3752dd6d.akpm@linux-foundation.org>
In-Reply-To: <200904291221.40361.knikanth@novell.com>
References: <200904291221.40361.knikanth@novell.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1066
Lines: 23

On Wed, 29 Apr 2009 12:21:39 +0530 Nikanth Karthikesan <knikanth@novell.com> wrote:

> Hi Jens
> 
> Currently io_context has an atomic_t(int) as refcount. In case of cfq, for
> each device a task does I/O, a reference to the io_context would be taken. And
> when there are multiple process sharing io_contexts(CLONE_IO) would also have
> a reference to the same io_context. Theoretically the possible maximum number
> of processes sharing the same io_context + the number of disks/cfq_data
> referring to the same io_context can overflow the 32-bit counter on a very
> high-end machine. Even though it is an improbable case, let us make it
> difficult by changing the refcount to atomic64_t(long).
> 

Sorry, atomic64_t isn't implemented on 32 bit architectures.

Perhaps it should be, but I expect it'd be pretty slow.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/