From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens Axboe Subject: Re: generic_make_request not locked Date: Tue, 30 Apr 2013 08:08:29 +0200 Message-ID: <20130430060829.GF9563@kernel.dk> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel , linux-kernel To: remaper Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Tue, Apr 30 2013, remaper wrote: > /* > * We only want one ->make_request_fn to be active at a time, > * else stack usage with stacked devices could be a problem. > * So use current->bio_list to keep a list of requests > * submited by a make_request_fn function. > * current->bio_list is also used as a flag to say if > * generic_make_request is currently active in this task or not. > * If it is NULL, then no make_request is active. If it is non-NULL, > * then a make_request is active, and new requests should be added > * at the tail > */ > void generic_make_request(struct bio *bio) > { > ... > if (current->bio_list) { > /* make_request is active */ > bio_list_add(current->bio_list, bio); > return; > } > ... > } > > current->bio_list is a global variable, and generic_make_request would > run on multithread environment, so, i don't understand why here( > bio_list_add ) not lock? thx everybody. 'current' refers to the task currently executing task. So current->bio_list isn't shared, hence there's no need for any locking. -- Jens Axboe