Date: Thu, 2 Sep 2004 23:14:48 +0200
From: Andi Kleen <ak@suse.de>
To: Roland Dreier <roland@topspin.com>
Cc: jakub@redhat.com, ak@suse.de, ecd@skynet.be, pavel@suse.cz,
       discuss@x86-64.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] fs/compat.c: rwsem instead of BKL around ioctl32_hash_table
Message-ID: <20040902211448.GE16175@wotan.suse.de>
References: <20040901072245.GF13749@mellanox.co.il> <524qmi2e1s.fsf@topspin.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <524qmi2e1s.fsf@topspin.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1239
Lines: 27

On Wed, Sep 01, 2004 at 08:40:15AM -0700, Roland Dreier wrote:
> Currently the BKL is used to synchronize access to ioctl32_hash_table
> in fs/compat.c.  It seems that an rwsem would be more appropriate,
> since this would allow multiple lookups to occur in parallel (and also
> serve the general good of minimizing use of the BKL).
> 
> I added lock_kernel()/unlock_kernel() around the call to t->handler
> when a compatibility handler is found in compat_sys_ioctl() to
> preserve the expectation that the BKL will be held during driver ioctl
> operations.  It should be safe to do lock_kernel() while holding
> ioctl32_sem because of the magic BKL sleep semantics.
> 
> I have booted this and run some basic 32-bit userspace on ppc64, and
> also compile tested this for x86_64 and sparc64.

It does not make much sense because the ioctl will take the BKL 
anyways.

If you wanted to fix it properly better make it use RCU - 
but it cannot work for the case of calling a compat handler.

-Andi
-
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/