linux-kernel - Re: [PATCH 4.4 00/30] 4.4.57-stable review

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:   Sat, 25 Mar 2017 12:27:06 +0100
From:   Alexandre Belloni <alexandre.belloni@...e-electrons.com>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     Kevin Hilman <khilman@...libre.com>,
        "kernelci.org bot" <bot@...nelci.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org,
        akpm@...ux-foundation.org, shuahkh@....samsung.com,
        patches@...nelci.org, ben.hutchings@...ethink.co.uk,
        stable@...r.kernel.org, nicolas.ferre@...el.com,
        Ludovic Desroches <ludovic.desroches@...rochip.com>,
        Richard Genoud <richard.genoud@...il.com>
Subject: Re: [PATCH 4.4 00/30] 4.4.57-stable review

On 24/03/2017 at 21:15:28 -0700, Guenter Roeck wrote:
> On 03/24/2017 05:10 PM, Kevin Hilman wrote:
> > + at91 maintainers
> > 

+ Richard, Ludovic

> > kernelci.org bot <bot@...nelci.org> writes:
> > 
> > > stable-rc boot: 496 boots: 1 failed, 492 passed with 2 offline, 1 conflict (v4.4.56-31-gbcd1e808ead3)
> > > 
> > > Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/kernel/v4.4.56-31-gbcd1e808ead3/
> > > Full Build Summary: https://kernelci.org/build/stable-rc/kernel/v4.4.56-31-gbcd1e808ead3/
> > > 
> > > Tree: stable-rc
> > > Branch: local/linux-4.4.y
> > > Git Describe: v4.4.56-31-gbcd1e808ead3
> > > Git Commit: bcd1e808ead359a9af8476025d8b8a5349796dcd
> > > Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > > Tested: 97 unique boards, 23 SoC families, 31 builds out of 202
> > > 
> > > Boot Regressions Detected:
> > > 
> > > arm:
> > > 
> > >     multi_v7_defconfig+CONFIG_LKDTM=y:
> > >         at91-sama5d2_xplained:
> > >             lab-free-electrons: new failure (last pass: v4.4.51-27-g2ffd736763bc)
> > 
> > This one is definitely a new regression.  Hopefully the AT91 maintainers
> > (now Cc'd) can have a closer look.
> > 
> 
> 6b1d7b6f54c7 would be a candidate for a culprit.
> 

Possibly and it may exercise a part of the logic that is not quite
robust in atmel_set_ops(). Basically, atmel_rx_from_pdc() must not be
chosen on sama5d2 (it has no PDC).

For reference, bootlog here:
https://storage.kernelci.org/stable-rc/v4.4.56-31-gbcd1e808ead3/arm-multi_v7_defconfig+CONFIG_LKDTM=y/lab-free-electrons/boot-at91-sama5d2_xplained.html

> > > Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.)
> > > 
> > > arm:
> > > 
> > >     multi_v7_defconfig+CONFIG_PROVE_LOCKING=y:
> > >         at91-sama5d3_xplained:
> > >             lab-baylibre-seattle: PASS
> > >             lab-free-electrons: FAIL
> > 
> > @Alexandre: Because it's passing in my lab and failing in yours, I'm
> > guessing this is still the UART overflow issue we've discussed before?
> > 
> > What's strange is that this defconfig in your lab seems to only be
> > booting for stable/linux-4.4.y[1] but not mailine or newer stable trees,
> > so I couldn't check if the problem still exists in mainline.
> > 

It definitively exists but it is not solvable quickly. Either we run
without DMA and we'll see the issue because CONFIG_PROVE_LOCKING makes
the interrupt handling to slow and characters are dropped. Or, we add
DMA and then CONFIG_PROVE_LOCKING will find a deadlock (that's a real
deadlock, not a false positive) and the platform will not boot.

This only affects sama5d3 because it is the only SoC using the hdma
controller with the uart IP. Earlier SoCs have a PDC and later SoCs are
using the xdma controller.

This happens because atc_chain_complete() keeps the lock before calling
the callback.  And atmel_complete_tx_dma() will call dmaengine function
that will try to acquire the lock. No issue using the xdmac because
there is no lock.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com