linux-kernel - Re: [REGRESSION] nfsd crashing with 3.6.0-rc7 on PowerPC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1349139509.3847.2.camel@pasglop>
Date:	Tue, 02 Oct 2012 10:58:29 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Alexander Graf <agraf@...e.de>
Cc:	"J. Bruce Fields" <bfields@...ldses.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	LKML List <linux-kernel@...r.kernel.org>,
	linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
	linux-nfs@...r.kernel.org, Jan Kara <jack@...e.cz>,
	skinsbursky@...allels.com, bfields@...hat.com, anton@...ba.org
Subject: Re: [REGRESSION] nfsd crashing with 3.6.0-rc7 on PowerPC

On Mon, 2012-10-01 at 16:03 +0200, Alexander Graf wrote:
> Phew. Here we go :). It looks to be more of a PPC specific problem than it appeared as at first:

Ok, so I suspect the problem is the pushing down of the locks which
breaks with iommu backends that have a separate flush callback. In
that case, the flush moves out of the allocator lock.

Now we do call flush before we return, still, but it becomes racy
I suspect, but somebody needs to give it a closer look. I'm hoping
Anton or Nish will later today.

Cheers,
Ben.

> 
> b4c3a8729ae57b4f84d661e16a192f828eca1d03 is first bad commit
> commit b4c3a8729ae57b4f84d661e16a192f828eca1d03
> Author: Anton Blanchard <anton@...ba.org>
> Date:   Thu Jun 7 18:14:48 2012 +0000
> 
>     powerpc/iommu: Implement IOMMU pools to improve multiqueue adapter performance
>     
>     At the moment all queues in a multiqueue adapter will serialise
>     against the IOMMU table lock. This is proving to be a big issue,
>     especially with 10Gbit ethernet.
>     
>     This patch creates 4 pools and tries to spread the load across
>     them. If the table is under 1GB in size we revert back to the
>     original behaviour of 1 pool and 1 largealloc pool.
>     
>     We create a hash to map CPUs to pools. Since we prefer interrupts to
>     be affinitised to primary CPUs, without some form of hashing we are
>     very likely to end up using the same pool. As an example, POWER7
>     has 4 way SMT and with 4 pools all primary threads will map to the
>     same pool.
>     
>     The largealloc pool is reduced from 1/2 to 1/4 of the space to
>     partially offset the overhead of breaking the table up into pools.
>     
>     Some performance numbers were obtained with a Chelsio T3 adapter on
>     two POWER7 boxes, running a 100 session TCP round robin test.
>     
>     Performance improved 69% with this patch applied.
>     
>     Signed-off-by: Anton Blanchard <anton@...ba.org>
>     Signed-off-by: Benjamin Herrenschmidt <benh@...nel.crashing.org>
> 
> :040000 040000 039ae3cbdcfded9c6b13e58a3fc67609f1b587b0 6755a8c4a690cc80dcf834d1127f21db925476d6 M	arch
> 
> 
> Alex


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