Re: mainline/master bisection: baseline.login on odroid-xu3

Re: mainline/master bisection: baseline.login on odroid-xu3

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 9056 bytes --]

On Sun, Apr 17, 2022 at 04:59:47AM -0700, KernelCI bot wrote:

The KernelCI bisection bot found a boot regression on Odroid-XU3 with
commit 8d9d651ff2270 (ARM: use LOADADDR() to get load address of
section).  It appears to trigger a deadlock somehow at some point after
the secondary CPUs come up:

<6>[    0.133301] smp: Bringing up secondary CPUs ...
<6>[    0.138439] CPU1: thread -1, cpu 1, socket 1, mpidr 80000101
<6>[    0.139400] CPU2: thread -1, cpu 2, socket 1, mpidr 80000102
<6>[    0.140325] CPU3: thread -1, cpu 3, socket 1, mpidr 80000103
<6>[    0.141167] CPU4: thread -1, cpu 0, socket 0, mpidr 80000000
<6>[    0.141185] CPU4: Spectre v2: using ICIALLU workaround
<6>[    0.168676] CPU4: Spectre BHB: using loop workaround
<5>[    0.780471] random: fast init done
<3>[   21.167354] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
<3>[   21.172051] rcu: 	4-....: (0 ticks this GP) idle=001/1/0x40000000 softirq=0/0 fqs=1050 
<4>[   21.180284] 	(detected by 0, t=2102 jiffies, g=-1199, q=1)
<6>[   21.186003] Sending NMI from CPU 0 to CPUs 4:
<5>[   44.300722] random: crng init done
<3>[   94.237962] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
<3>[   94.242664] rcu: 	4-....: (0 ticks this GP) idle=001/1/0x40000000 softirq=0/0 fqs=4202 
<4>[   94.250897] 	(detected by 0, t=8407 jiffies, g=-1199, q=1)
<6>[   94.256616] Sending NMI from CPU 0 to CPUs 4:
<3>[  167.308571] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
<3>[  167.313269] rcu: 	4-....: (0 ticks this GP) idle=001/1/0x40000000 softirq=0/0 fqs=7354 
<4>[  167.321502] 	(detected by 0, t=14712 jiffies, g=-1199, q=1)
<6>[  167.327308] Sending NMI from CPU 0 to CPUs 4:

I've not deleted any context below for reference, this includes links to
full logs of the failure, a log of the bisection and a tag for the
report from the bot:

> * If you do send a fix, please include this trailer:            *
> *   Reported-by: "kernelci.org bot" <bot@kernelci.org>          *
> *                                                               *
> * Hope this helps!                                              *
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

> 
> mainline/master bisection: baseline.login on odroid-xu3
> 
> Summary:
>   Start:      90ea17a9e27b5 Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
>   Plain log:  https://storage.kernelci.org/mainline/master/v5.18-rc2-291-g90ea17a9e27b5/arm/multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y/gcc-10/lab-collabora/baseline-odroid-xu3.txt
>   HTML log:   https://storage.kernelci.org/mainline/master/v5.18-rc2-291-g90ea17a9e27b5/arm/multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y/gcc-10/lab-collabora/baseline-odroid-xu3.html
>   Result:     8d9d651ff2270 ARM: use LOADADDR() to get load address of sections
> 
> Checks:
>   revert:     PASS
>   verify:     PASS
> 
> Parameters:
>   Tree:       mainline
>   URL:        https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>   Branch:     master
>   Target:     odroid-xu3
>   CPU arch:   arm
>   Lab:        lab-collabora
>   Compiler:   gcc-10
>   Config:     multi_v7_defconfig+CONFIG_THUMB2_KERNEL=y
>   Test case:  baseline.login
> 
> Breaking commit found:
> 
> -------------------------------------------------------------------------------
> commit 8d9d651ff2270a632e9dc497b142db31e8911315
> Author: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> Date:   Fri Feb 11 19:49:50 2022 +0000
> 
>     ARM: use LOADADDR() to get load address of sections
>     
>     Use the linker's LOADADDR() macro to get the load address of the
>     sections, and provide a macro to set the start and end symbols.
>     
>     Acked-by: Catalin Marinas <catalin.marinas@arm.com>
>     Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> 
> diff --git a/arch/arm/include/asm/vmlinux.lds.h b/arch/arm/include/asm/vmlinux.lds.h
> index 4a91428c324db..e02710d17cf93 100644
> --- a/arch/arm/include/asm/vmlinux.lds.h
> +++ b/arch/arm/include/asm/vmlinux.lds.h
> @@ -26,6 +26,11 @@
>  #define ARM_MMU_DISCARD(x)	x
>  #endif
>  
> +/* Set start/end symbol names to the LMA for the section */
> +#define ARM_LMA(sym, section)						\
> +	sym##_start = LOADADDR(section);				\
> +	sym##_end = LOADADDR(section) + SIZEOF(section)
> +
>  #define PROC_INFO							\
>  		. = ALIGN(4);						\
>  		__proc_info_begin = .;					\
> @@ -110,19 +115,19 @@
>   * only thing that matters is their relative offsets
>   */
>  #define ARM_VECTORS							\
> -	__vectors_start = .;						\
> +	__vectors_lma = .;						\
>  	.vectors 0xffff0000 : AT(__vectors_start) {			\
>  		*(.vectors)						\
>  	}								\
> -	. = __vectors_start + SIZEOF(.vectors);				\
> -	__vectors_end = .;						\
> +	ARM_LMA(__vectors, .vectors);					\
> +	. = __vectors_lma + SIZEOF(.vectors);				\
>  									\
> -	__stubs_start = .;						\
> -	.stubs ADDR(.vectors) + 0x1000 : AT(__stubs_start) {		\
> +	__stubs_lma = .;						\
> +	.stubs ADDR(.vectors) + 0x1000 : AT(__stubs_lma) {		\
>  		*(.stubs)						\
>  	}								\
> -	. = __stubs_start + SIZEOF(.stubs);				\
> -	__stubs_end = .;						\
> +	ARM_LMA(__stubs, .stubs);					\
> +	. = __stubs_lma + SIZEOF(.stubs);				\
>  									\
>  	PROVIDE(vector_fiq_offset = vector_fiq - ADDR(.vectors));
> -------------------------------------------------------------------------------
> 
> 
> Git bisection log:
> 
> -------------------------------------------------------------------------------
> git bisect start
> # good: [ea4424be16887a37735d6550cfd0611528dbe5d9] Merge tag 'mtd/fixes-for-5.17-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux
> git bisect good ea4424be16887a37735d6550cfd0611528dbe5d9
> # bad: [90ea17a9e27b5778ec517efb1ce0b81d36905654] Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
> git bisect bad 90ea17a9e27b5778ec517efb1ce0b81d36905654
> # bad: [169e77764adc041b1dacba84ea90516a895d43b2] Merge tag 'net-next-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next
> git bisect bad 169e77764adc041b1dacba84ea90516a895d43b2
> # bad: [baaa68a9796ef2cadfe5caaf4c730412eda0f31c] Merge tag 'arm-soc-5.18' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
> git bisect bad baaa68a9796ef2cadfe5caaf4c730412eda0f31c
> # bad: [5191290407668028179f2544a11ae9b57f0bcf07] Merge tag 'for-5.18-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux
> git bisect bad 5191290407668028179f2544a11ae9b57f0bcf07
> # bad: [5628b8de1228436d47491c662dc521bc138a3d43] Merge tag 'random-5.18-rc1-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/crng/random
> git bisect bad 5628b8de1228436d47491c662dc521bc138a3d43
> # bad: [eaa54b1458ca84092e513d554dd6d234245e6bef] Merge tag 'x86_cleanups_for_v5.18_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
> git bisect bad eaa54b1458ca84092e513d554dd6d234245e6bef
> # bad: [c81801eb7f2476a25d8fb27449e01b0bef46908a] Merge tag 'acpi-5.17-rc9' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
> git bisect bad c81801eb7f2476a25d8fb27449e01b0bef46908a
> # bad: [c30b5b8cfb72cc83c10793588ce94471a4769409] Merge tag 'staging-5.17-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
> git bisect bad c30b5b8cfb72cc83c10793588ce94471a4769409
> # bad: [3bf7edc84a9eb4007dd9a0cb8878a7e1d5ec6a3b] Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
> git bisect bad 3bf7edc84a9eb4007dd9a0cb8878a7e1d5ec6a3b
> # skip: [cd22a8bfcfe07ef35b1b5d96dd468e92dc5e9d8a] Merge tag 'arm64-spectre-bhb-for-v5.17-2' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
> git bisect skip cd22a8bfcfe07ef35b1b5d96dd468e92dc5e9d8a
> # good: [bd09128d16fac3c34b80bd6a29088ac632e8ce09] arm64: Add percpu vectors for EL1
> git bisect good bd09128d16fac3c34b80bd6a29088ac632e8ce09
> # bad: [b9baf5c8c5c356757f4f9d8180b5e9d234065bc3] ARM: Spectre-BHB workaround
> git bisect bad b9baf5c8c5c356757f4f9d8180b5e9d234065bc3
> # good: [04e91b7324760a377a725e218b5ee783826d30f5] ARM: early traps initialisation
> git bisect good 04e91b7324760a377a725e218b5ee783826d30f5
> # bad: [8d9d651ff2270a632e9dc497b142db31e8911315] ARM: use LOADADDR() to get load address of sections
> git bisect bad 8d9d651ff2270a632e9dc497b142db31e8911315
> # first bad commit: [8d9d651ff2270a632e9dc497b142db31e8911315] ARM: use LOADADDR() to get load address of sections
> -------------------------------------------------------------------------------
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#25908): https://groups.io/g/kernelci-results/message/25908
> Mute This Topic: https://groups.io/mt/90521049/1131744
> Group Owner: kernelci-results+owner@groups.io
> Unsubscribe: https://groups.io/g/kernelci-results/unsub [broonie@kernel.org]
> -=-=-=-=-=-=-=-=-=-=-=-
> 
> 

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: mainline/master bisection: baseline.login on odroid-xu3

[Russell King (Oracle)]

On Sun, Apr 17, 2022 at 08:35:29PM +0100, Mark Brown wrote:
> On Sun, Apr 17, 2022 at 04:59:47AM -0700, KernelCI bot wrote:
> 
> The KernelCI bisection bot found a boot regression on Odroid-XU3 with
> commit 8d9d651ff2270 (ARM: use LOADADDR() to get load address of
> section).  It appears to trigger a deadlock somehow at some point after
> the secondary CPUs come up:

If the primary CPU is still happy, then the secondary CPUs should be.
Quite simply, if something is broken in the setup of the vectors, the
primary CPU would also be affected by this commit. However...

> <6>[    0.133301] smp: Bringing up secondary CPUs ...
> <6>[    0.138439] CPU1: thread -1, cpu 1, socket 1, mpidr 80000101
> <6>[    0.139400] CPU2: thread -1, cpu 2, socket 1, mpidr 80000102
> <6>[    0.140325] CPU3: thread -1, cpu 3, socket 1, mpidr 80000103
> <6>[    0.141167] CPU4: thread -1, cpu 0, socket 0, mpidr 80000000
> <6>[    0.141185] CPU4: Spectre v2: using ICIALLU workaround
> <6>[    0.168676] CPU4: Spectre BHB: using loop workaround

Given that there was a problem with the loop implementation, please
ensure that when you bisect, you have the following commit in place
every time you test a bisect point:

6c7cb60bff7a ("ARM: fix Thumb2 regression with Spectre BHB")

Otherwise, yes, it is known that Thumb2 will be broken.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: mainline/master bisection: baseline.login on odroid-xu3

[Russell King (Oracle)]

On Sun, Apr 17, 2022 at 10:27:58PM +0100, Russell King (Oracle) wrote:
> On Sun, Apr 17, 2022 at 08:35:29PM +0100, Mark Brown wrote:
> > On Sun, Apr 17, 2022 at 04:59:47AM -0700, KernelCI bot wrote:
> > 
> > The KernelCI bisection bot found a boot regression on Odroid-XU3 with
> > commit 8d9d651ff2270 (ARM: use LOADADDR() to get load address of
> > section).  It appears to trigger a deadlock somehow at some point after
> > the secondary CPUs come up:
> 
> If the primary CPU is still happy, then the secondary CPUs should be.
> Quite simply, if something is broken in the setup of the vectors, the
> primary CPU would also be affected by this commit. However...
> 
> > <6>[    0.133301] smp: Bringing up secondary CPUs ...
> > <6>[    0.138439] CPU1: thread -1, cpu 1, socket 1, mpidr 80000101
> > <6>[    0.139400] CPU2: thread -1, cpu 2, socket 1, mpidr 80000102
> > <6>[    0.140325] CPU3: thread -1, cpu 3, socket 1, mpidr 80000103
> > <6>[    0.141167] CPU4: thread -1, cpu 0, socket 0, mpidr 80000000
> > <6>[    0.141185] CPU4: Spectre v2: using ICIALLU workaround
> > <6>[    0.168676] CPU4: Spectre BHB: using loop workaround
> 
> Given that there was a problem with the loop implementation, please
> ensure that when you bisect, you have the following commit in place
> every time you test a bisect point:
> 
> 6c7cb60bff7a ("ARM: fix Thumb2 regression with Spectre BHB")
> 
> Otherwise, yes, it is known that Thumb2 will be broken.

Also, I should say, if this commit is really the case:

8d9d651ff227 ("ARM: use LOADADDR() to get load address of sections")

then I need to see two vmlinux binaries (the decompressed kernel ELF
image) for analysis of why this commit is causing the failure.
Basically, I need to disassemble the code and see what the toolchain
is doing to screw up the kernel.

If it isn't obvious from that, then I have no idea why this commit
would cause such a strange regression.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: mainline/master bisection: baseline.login on odroid-xu3

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1643 bytes --]

On Sun, Apr 17, 2022 at 10:27:58PM +0100, Russell King (Oracle) wrote:

> If the primary CPU is still happy, then the secondary CPUs should be.
> Quite simply, if something is broken in the setup of the vectors, the
> primary CPU would also be affected by this commit. However...

Yes, I was quite confused.

> > <6>[    0.141185] CPU4: Spectre v2: using ICIALLU workaround
> > <6>[    0.168676] CPU4: Spectre BHB: using loop workaround

> Given that there was a problem with the loop implementation, please
> ensure that when you bisect, you have the following commit in place
> every time you test a bisect point:

> 6c7cb60bff7a ("ARM: fix Thumb2 regression with Spectre BHB")

> Otherwise, yes, it is known that Thumb2 will be broken.

Ah, that won't have been in there (since the bot is just running off
what it finds in git) and indeed looking at the most recent results:

   https://linux.kernelci.org/test/job/mainline/branch/master/kernel/v5.18-rc2-351-ga2c29ccd94778/plan/baseline/

it does look like it's just Thumb2 that's failing.  However that's got
Linus' tree as of a2c29ccd9477861b16ddc02c411a6c9665250558 which does
feature the above commit so there's something else off (I expect we'll
see newer results soon at https://linux.kernelci.org/job/mainline/ since
it looks like Linus just tagged -rc3).  It does seem to be only this
board, other boards are booting the Thumb2 kernel fine, so I'd not be
surprised if missing the above commit just confused the bisection.

We'd need to rerun a bisection with the above commit in place I guess, I
don't have access to trigger that - Guillaume (in CCs) can hopefully
help next week.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: mainline/master bisection: baseline.login on odroid-xu3

[Guillaume Tucker]

Please see the bisection report below about a boot failure.

Reports aren't automatically sent to the public while we're
trialing new bisection features on kernelci.org but this one
looks valid.

Guillaume

On 29/01/2020 23:00, kernelci.org bot wrote:
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> * This automated bisection report was sent to you on the basis  *
> * that you may be involved with the breaking commit it has      *
> * found.  No manual investigation has been done to verify it,   *
> * and the root cause of the problem may be somewhere else.      *
> *                                                               *
> * If you do send a fix, please include this trailer:            *
> *   Reported-by: "kernelci.org bot" <bot@kernelci.org>          *
> *                                                               *
> * Hope this helps!                                              *
> * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> 
> mainline/master bisection: baseline.login on odroid-xu3
> 
> Summary:
>   Start:      b3a608222336 Merge branch 'for-v5.6' of git://git.kernel.org:/pub/scm/linux/kernel/git/jmorris/linux-security
>   Plain log:  https://storage.kernelci.org//mainline/master/v5.5-3996-gb3a608222336/arm/multi_v7_defconfig+CONFIG_SMP=n/gcc-8/lab-collabora/baseline-exynos5422-odroidxu3.txt
>   HTML log:   https://storage.kernelci.org//mainline/master/v5.5-3996-gb3a608222336/arm/multi_v7_defconfig+CONFIG_SMP=n/gcc-8/lab-collabora/baseline-exynos5422-odroidxu3.html
>   Result:     71723a96b8b1 dmaengine: Create symlinks between DMA channels and slaves
> 
> Checks:
>   revert:     PASS
>   verify:     PASS
> 
> Parameters:
>   Tree:       mainline
>   URL:        git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>   Branch:     master
>   Target:     odroid-xu3
>   CPU arch:   arm
>   Lab:        lab-collabora
>   Compiler:   gcc-8
>   Config:     multi_v7_defconfig+CONFIG_SMP=n
>   Test case:  baseline.login
> 
> Breaking commit found:
> 
> -------------------------------------------------------------------------------
> commit 71723a96b8b1367fefc18f60025dae792477d602
> Author: Geert Uytterhoeven <geert+renesas@glider.be>
> Date:   Fri Jan 17 16:30:56 2020 +0100
> 
>     dmaengine: Create symlinks between DMA channels and slaves
>     
>     Currently it is not easy to find out which DMA channels are in use, and
>     which slave devices are using which channels.
>     
>     Fix this by creating two symlinks between the DMA channel and the actual
>     slave device when a channel is requested:
>       1. A "slave" symlink from DMA channel to slave device,
>       2. A "dma:<name>" symlink slave device to DMA channel.
>     When the channel is released, the symlinks are removed again.
>     The latter requires keeping track of the slave device and the channel
>     name in the dma_chan structure.
>     
>     Note that this is limited to channel request functions for requesting an
>     exclusive slave channel that take a device pointer (dma_request_chan()
>     and dma_request_slave_channel*()).
>     
>     Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>     Tested-by: Niklas Söderlund <niklas.soderlund@ragnatech.se>
>     Link: https://lore.kernel.org/r/20200117153056.31363-1-geert+renesas@glider.be
>     Signed-off-by: Vinod Koul <vkoul@kernel.org>
> 
> diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
> index 51a2f2b1b2de..f3ef4edd4de1 100644
> --- a/drivers/dma/dmaengine.c
> +++ b/drivers/dma/dmaengine.c
> @@ -60,6 +60,8 @@ static long dmaengine_ref_count;
>  
>  /* --- sysfs implementation --- */
>  
> +#define DMA_SLAVE_NAME	"slave"
> +
>  /**
>   * dev_to_dma_chan - convert a device pointer to its sysfs container object
>   * @dev - device node
> @@ -730,11 +732,11 @@ struct dma_chan *dma_request_chan(struct device *dev, const char *name)
>  	if (has_acpi_companion(dev) && !chan)
>  		chan = acpi_dma_request_slave_chan_by_name(dev, name);
>  
> -	if (chan) {
> -		/* Valid channel found or requester needs to be deferred */
> -		if (!IS_ERR(chan) || PTR_ERR(chan) == -EPROBE_DEFER)
> -			return chan;
> -	}
> +	if (PTR_ERR(chan) == -EPROBE_DEFER)
> +		return chan;
> +
> +	if (!IS_ERR_OR_NULL(chan))
> +		goto found;
>  
>  	/* Try to find the channel via the DMA filter map(s) */
>  	mutex_lock(&dma_list_mutex);
> @@ -754,7 +756,23 @@ struct dma_chan *dma_request_chan(struct device *dev, const char *name)
>  	}
>  	mutex_unlock(&dma_list_mutex);
>  
> -	return chan ? chan : ERR_PTR(-EPROBE_DEFER);
> +	if (!IS_ERR_OR_NULL(chan))
> +		goto found;
> +
> +	return ERR_PTR(-EPROBE_DEFER);
> +
> +found:
> +	chan->slave = dev;
> +	chan->name = kasprintf(GFP_KERNEL, "dma:%s", name);
> +	if (!chan->name)
> +		return ERR_PTR(-ENOMEM);
> +
> +	if (sysfs_create_link(&chan->dev->device.kobj, &dev->kobj,
> +			      DMA_SLAVE_NAME))
> +		dev_err(dev, "Cannot create DMA %s symlink\n", DMA_SLAVE_NAME);
> +	if (sysfs_create_link(&dev->kobj, &chan->dev->device.kobj, chan->name))
> +		dev_err(dev, "Cannot create DMA %s symlink\n", chan->name);
> +	return chan;
>  }
>  EXPORT_SYMBOL_GPL(dma_request_chan);
>  
> @@ -812,6 +830,13 @@ void dma_release_channel(struct dma_chan *chan)
>  	/* drop PRIVATE cap enabled by __dma_request_channel() */
>  	if (--chan->device->privatecnt == 0)
>  		dma_cap_clear(DMA_PRIVATE, chan->device->cap_mask);
> +	if (chan->slave) {
> +		sysfs_remove_link(&chan->slave->kobj, chan->name);
> +		kfree(chan->name);
> +		chan->name = NULL;
> +		chan->slave = NULL;
> +	}
> +	sysfs_remove_link(&chan->dev->device.kobj, DMA_SLAVE_NAME);
>  	mutex_unlock(&dma_list_mutex);
>  }
>  EXPORT_SYMBOL_GPL(dma_release_channel);
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index f52f274773ed..fef69a9c5824 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -294,10 +294,12 @@ struct dma_router {
>  /**
>   * struct dma_chan - devices supply DMA channels, clients use them
>   * @device: ptr to the dma device who supplies this channel, always !%NULL
> + * @slave: ptr to the device using this channel
>   * @cookie: last cookie value returned to client
>   * @completed_cookie: last completed cookie for this channel
>   * @chan_id: channel ID for sysfs
>   * @dev: class device for sysfs
> + * @name: backlink name for sysfs
>   * @device_node: used to add this to the device chan list
>   * @local: per-cpu pointer to a struct dma_chan_percpu
>   * @client_count: how many clients are using this channel
> @@ -308,12 +310,14 @@ struct dma_router {
>   */
>  struct dma_chan {
>  	struct dma_device *device;
> +	struct device *slave;
>  	dma_cookie_t cookie;
>  	dma_cookie_t completed_cookie;
>  
>  	/* sysfs */
>  	int chan_id;
>  	struct dma_chan_dev *dev;
> +	const char *name;
>  
>  	struct list_head device_node;
>  	struct dma_chan_percpu __percpu *local;
> -------------------------------------------------------------------------------
> 
> 
> Git bisection log:
> 
> -------------------------------------------------------------------------------
> git bisect start
> # good: [4703d9119972bf586d2cca76ec6438f819ffa30e] Merge tag 'xarray-5.5' of git://git.infradead.org/users/willy/linux-dax
> git bisect good 4703d9119972bf586d2cca76ec6438f819ffa30e
> # bad: [b3a6082223369203d7e7db7e81253ac761377644] Merge branch 'for-v5.6' of git://git.kernel.org:/pub/scm/linux/kernel/git/jmorris/linux-security
> git bisect bad b3a6082223369203d7e7db7e81253ac761377644
> # bad: [a78208e2436963d0b2c7d186277d6e1a9755029a] Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6
> git bisect bad a78208e2436963d0b2c7d186277d6e1a9755029a
> # bad: [b1dba2473114588be3df916bf629a61bdcc83737] Merge tag 'selinux-pr-20200127' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux
> git bisect bad b1dba2473114588be3df916bf629a61bdcc83737
> # good: [9e1af7567b266dc6c3c8fd434ea807b3206bfdc1] Merge tag 'mmc-v5.6' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc
> git bisect good 9e1af7567b266dc6c3c8fd434ea807b3206bfdc1
> # bad: [aae1464f46a2403565f75717438118691d31ccf1] Merge tag 'regulator-v5.6' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
> git bisect bad aae1464f46a2403565f75717438118691d31ccf1
> # bad: [a5b871c91d470326eed3ae0ebd2fc07f3aee9050] Merge tag 'dmaengine-5.6-rc1' of git://git.infradead.org/users/vkoul/slave-dma
> git bisect bad a5b871c91d470326eed3ae0ebd2fc07f3aee9050
> # good: [12fb2b993e1508a0d9032a2314dfdda2a3a5535e] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid
> git bisect good 12fb2b993e1508a0d9032a2314dfdda2a3a5535e
> # good: [7d083ae983573de16e3ab0bfd47486996d211417] dmaengine: doc: Add sections for per descriptor metadata support
> git bisect good 7d083ae983573de16e3ab0bfd47486996d211417
> # good: [e606c8b9d751e593b71bdcb636ac3392c62c1c50] dmaengine: s3c24xx-dma: fix spelling mistake "to" -> "too"
> git bisect good e606c8b9d751e593b71bdcb636ac3392c62c1c50
> # good: [8f47d1a5e545f903cd049c42da31a3be36178447] dmaengine: idxd: connect idxd to dmaengine subsystem
> git bisect good 8f47d1a5e545f903cd049c42da31a3be36178447
> # good: [f46e49a9cc3814f3564477f0fffc00e0a2bc9e80] livepatch: Handle allocation failure in the sample of shadow variable API
> git bisect good f46e49a9cc3814f3564477f0fffc00e0a2bc9e80
> # good: [e9f08b65250d73ab70e79e194813f52b8d306784] dmaengine: hisilicon: Add Kunpeng DMA engine support
> git bisect good e9f08b65250d73ab70e79e194813f52b8d306784
> # bad: [71723a96b8b1367fefc18f60025dae792477d602] dmaengine: Create symlinks between DMA channels and slaves
> git bisect bad 71723a96b8b1367fefc18f60025dae792477d602
> # first bad commit: [71723a96b8b1367fefc18f60025dae792477d602] dmaengine: Create symlinks between DMA channels and slaves
> -------------------------------------------------------------------------------
> 

Re: mainline/master bisection: baseline.login on odroid-xu3

[Geert Uytterhoeven]

Hi Guillaume,

On Thu, Jan 30, 2020 at 12:13 AM Guillaume Tucker
<guillaume.tucker@collabora.com> wrote:
> On 29/01/2020 23:00, kernelci.org bot wrote:
> > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> > * This automated bisection report was sent to you on the basis  *
> > * that you may be involved with the breaking commit it has      *
> > * found.  No manual investigation has been done to verify it,   *
> > * and the root cause of the problem may be somewhere else.      *
> > *                                                               *
> > * If you do send a fix, please include this trailer:            *
> > *   Reported-by: "kernelci.org bot" <bot@kernelci.org>          *
> > *                                                               *
> > * Hope this helps!                                              *
> > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
> >
> > mainline/master bisection: baseline.login on odroid-xu3
> >
> > Summary:
> >   Start:      b3a608222336 Merge branch 'for-v5.6' of git://git.kernel.org:/pub/scm/linux/kernel/git/jmorris/linux-security
> >   Plain log:  https://storage.kernelci.org//mainline/master/v5.5-3996-gb3a608222336/arm/multi_v7_defconfig+CONFIG_SMP=n/gcc-8/lab-collabora/baseline-exynos5422-odroidxu3.txt
> >   HTML log:   https://storage.kernelci.org//mainline/master/v5.5-3996-gb3a608222336/arm/multi_v7_defconfig+CONFIG_SMP=n/gcc-8/lab-collabora/baseline-exynos5422-odroidxu3.html
> >   Result:     71723a96b8b1 dmaengine: Create symlinks between DMA channels and slaves

Sorry for the breakage. Please try Marek's fix:
https://lore.kernel.org/lkml/20200130070834.17537-1-m.szyprowski@samsung.com/

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: mainline/master bisection: baseline.login on odroid-xu3

[Vinod Koul]

On 29-01-20, 23:13, Guillaume Tucker wrote:
> Please see the bisection report below about a boot failure.
> 
> Reports aren't automatically sent to the public while we're
> trialing new bisection features on kernelci.org but this one
> looks valid.

Thanks, the fix has been pushed out to dmaengine-next and should be in
linux-next tomorrow.

-- 
~Vinod