linux-kernel - Re: [ 022/180] ioat2: kill pending flag

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]

Date:	Thu, 4 Oct 2012 22:16:09 +0200
From:	Willy Tarreau <w@....eu>
To:	Ben Hutchings <ben@...adent.org.uk>
Cc:	Dan Williams <dan.j.williams@...el.com>,
	linux-kernel@...r.kernel.org, stable@...r.kernel.org,
	Stephan Baerwolf <stephan.baerwolf@...ilmenau.de>,
	Marcelo Tosatti <mtosatti@...hat.com>,
	Michael Ellerman <michael@...erman.id.au>,
	Avi Kivity <avi@...hat.com>
Subject: Re: [ 022/180] ioat2: kill pending flag

Hi Ben,

I'm doing a grouped reply for your reports.

On Thu, Oct 04, 2012 at 03:47:37PM +0100, Ben Hutchings wrote:
> On Tue, 2012-10-02 at 00:52 +0200, Willy Tarreau wrote:
> > 2.6.32-longterm review patch.  If anyone has any objections, please let me know.
> > 
> > ------------------
> > 
> > From: Dan Williams <dan.j.williams@...el.com>
> > 
> > commit 281befa5592b0c5f9a3856b5666c62ac66d3d9ee upstream.
> > 
> > The pending == 2 case no longer exists in the driver so, we can use
> > ioat2_ring_pending() outside the lock to determine if there might be any
> > descriptors in the ring that the hardware has not seen.
> [...]
> 
> What bug does this fix?

Quoting Mike Galbraith :

  "While testing tbench 40 throughput on a 40 core (+SMT) Intel SDV S3E37,
   I found spin_lock_bh() consuming _90%_ of the box, driving throughput
   straight through the floor.  The commit below fixed it up.

   This looks horrific enough to me to qualify for 2.6.32-longterm."

>  Is ioat2_ring_pending() *really* safe to call without the ring_lock?

I'll let Dan respond on this, he's the original path author.

On Thu, Oct 04, 2012 at 06:15:34PM +0100, Ben Hutchings wrote:
> On Tue, Oct 02, 2012 at 12:52:37AM +0200, Willy Tarreau wrote:
> > 2.6.32-longterm review patch.  If anyone has any objections, please let me know.
> > 
> > ------------------
> > 
> > From: =?latin1?q?Stephan=20B=E4rwolf?= <stephan.baerwolf@...ilmenau.de>
> > 
> > commit 0769c5de24621141c953fbe1f943582d37cb4244 upstream
> [...]
> 
> I'm not sure where this comes from - but probably from cherry-picking
> backporting in my local repo.  The correct upstream commit hash is
> bdb42f5afebe208eae90406959383856ae2caf2b.

I did some mistakes when cherry-picking patches, I used cherry-pick -x
on some of them because my fingers type "-x" automatically here, but
some of my scripts are used to automatically write the commit line from
the cherry-pick line.

When I noticed the error, I reviewed all the affected patches and fixed
the few erroneous ones by hand, but it seems like 2 of them have slipped
through the cracks, or I failed a copy-paste during the fix.

I'll fix the commits, thanks for checking !

On Thu, Oct 04, 2012 at 06:35:13PM +0100, Ben Hutchings wrote:
> On Tue, Oct 02, 2012 at 12:52:42AM +0200, Willy Tarreau wrote:
> > 2.6.32-longterm review patch.  If anyone has any objections, please let me know.
> > 
> > ------------------
> > 
> > From: Avi Kivity <avi@...hat.com>
> > 
> > commit 3e515705a1f46beb1c942bb8043c16f8ac7b1e9e upstream
> [...]
> > --- a/arch/ia64/kvm/kvm-ia64.c
> > +++ b/arch/ia64/kvm/kvm-ia64.c
> > @@ -1185,6 +1185,11 @@ out:
> >  
> >  #define PALE_RESET_ENTRY    0x80000000ffffffb0UL
> >  
> > +bool kvm_vcpu_compatible(struct kvm_vcpu *vcpu)
> > +{
> > +	return irqchip_in_kernel(vcpu->kcm) == (vcpu->arch.apic != NULL);
> > +}
> > +
> [...]
> 
> Fails to build; fixed by commit 8281715b4109b5ee26032ff7b77c0d575c4150f7.

Queued now, thanks very much!

Willy

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