Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932455Ab2HPNXy (ORCPT ); Thu, 16 Aug 2012 09:23:54 -0400 Received: from natasha.panasas.com ([67.152.220.90]:36937 "EHLO natasha.panasas.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932326Ab2HPNXx (ORCPT ); Thu, 16 Aug 2012 09:23:53 -0400 Message-ID: <502CF446.9010107@panasas.com> Date: Thu, 16 Aug 2012 16:23:18 +0300 From: Boaz Harrosh User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111113 Thunderbird/8.0 MIME-Version: 1.0 To: CC: Marco Stornelli , , , Andrew Morton , , , , , Al Viro , , , , Linux Kernel , , Linux FS Devel Subject: Re: [PATCH 2/8] exofs: remove lock/unlock super References: <502CC4AA.6040702@gmail.com> <1345119652.3393.220.camel@sauron.fi.intel.com> <502CE840.4060802@panasas.com> <1345122611.3393.225.camel@sauron.fi.intel.com> <502CF259.9040300@panasas.com> In-Reply-To: <502CF259.9040300@panasas.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1928 Lines: 64 On 08/16/2012 04:15 PM, Boaz Harrosh wrote: > On 08/16/2012 04:10 PM, Artem Bityutskiy wrote: > >> On Thu, 2012-08-16 at 15:32 +0300, Boaz Harrosh wrote: >>> On 08/16/2012 03:20 PM, Artem Bityutskiy wrote: >>> >>>> On Thu, 2012-08-16 at 12:00 +0200, Marco Stornelli wrote: >>>>> From: Marco Stornelli >>>>> >>>>> Remove lock and unlock super operation. >>>>> >>>>> Signed-off-by: Marco Stornelli >>>> >>>> Acked-by: Artem Bityutskiy >>>> >>> >>> >>> Are you sure? It used to be that exofs_sync_fs() could be called >>> concurrently. >>> >>> What about two "bash -c sync" calls or a sync and an unmount >>> in parallel. anything protecting that? >>> >>> If so then sure, but please let me test first. >> >> Umm, actually we will probably end up writing the same twice without the >> lock. >> > > > No we are not allowed to run exofs_sync_fs() concurrently because it uses > a per-alllocated scratch buffer to do it's stuff so you can end up with data > corruption on disk. > I take that back. We kmalloc. (We used to not too). In theory the counter in question could change mid flight and the IOs can be submitted out of order, But the chance for that is very very slim. So It's fine. It's a deprecated counter anyway, so I'm OK to drop it. I'll completely remove it the next time I increment the sb version number. Thanks Boaz > And we cannot use a spin-lock because we might sleep in ore_write() > > There are some optimizations I can do here, but lets for now just do > the sb->s_lock thing, and I might decide to completely revamp the > all thing later. > > Thanks > Boaz -- 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/