Re: [alsa-devel] [PATCH v5 08/11] ASoC: Intel: atom: Make PCI dependency explicit

I > >>> <<<< LOOK HERE > >>> drivers/acpi/Kconfig:6:symbol ARCH_SUPPORTS_ACPI is selected by > >>> IA64_HP_SIM > >>> arch/ia64/Kconfig:200:symbol IA64_HP_SIM is part of choice > >>> > >>> At any rate, a 3 mn gi

Re: [alsa-devel] [PATCH v5 08/11] ASoC: Intel: atom: Make PCI dependency explicit

ers/acpi/Kconfig:6:symbol ARCH_SUPPORTS_ACPI is selected by > IA64_HP_SIM > arch/ia64/Kconfig:200:symbol IA64_HP_SIM is part of choice > > At any rate, a 3 mn git bisect tells me the circular dependency is > exposed by this change: > > f3fd6cd74fedf99b6060f75df00943fda13b65

Re: linux-next: manual merge of the f2fs tree with the fscrypt tree

On Wednesday, January 2, 2019 5:56:10 AM IST Stephen Rothwell wrote: > Hi all, > > On Tue, 11 Dec 2018 10:13:22 +1100 Stephen Rothwell > wrote: > > > > Today's linux-next merge of the f2fs tree got a conflict in: > > > > fs/f2fs/dir.c > > > > between commit: > > > > 848a010287e6 ("f2fs: u

Re: linux-next: Tree for Dec 21

On Friday, December 21, 2018 9:51:49 PM IST Guenter Roeck wrote: > On Fri, Dec 21, 2018 at 07:32:44PM +1100, Stephen Rothwell wrote: > > Hi all, > > > > News: there will be no linux-next release until Jan 2. Have a good break. > > > > Changes since 20181220: > > > > New tree: gpio-brgl > > > >

Re: Regression in next-20181211 with fsverity changes

On Wednesday, December 12, 2018 12:42:20 AM IST Tony Lindgren wrote: > Hi, > > Looks like commit 4de97efb578a ("fsverity: Move verity status check > to fsverity_file_open") causes a boot regression for me with root > on ext4 SDIO card, see below. > fsverity_file_open() used to incorrectly return

Re: [BUG BISECT next] Files cannot be opened after "fsverity: Move verity status check to fsverity_file_open"

On Tuesday, December 11, 2018 11:11:17 PM IST Eric Biggers wrote: > On Tue, Dec 11, 2018 at 03:15:53PM +0100, Krzysztof Kozlowski wrote: > > Hi, > > > > Bisect from today's next pointed me to: > > commit 4de97efb578a094e8fbf279522d41eb9ece1e3e0 > > Author: C

Re: xfs: Deadlock between fs_reclaim and sb_internal

On Friday, June 29, 2018 11:48:39 AM IST Chandan Rajendra wrote: > On Thursday, June 28, 2018 9:31:32 AM IST Ravi Bangoria wrote: > > Hello Darrick, > > > > Lockdep is reporting a deadlock with following trace. Saw this on my > > powerpc vm with 4GB of ram, running Lin

Re: xfs: Deadlock between fs_reclaim and sb_internal

On Thursday, June 28, 2018 9:31:32 AM IST Ravi Bangoria wrote: > Hello Darrick, > > Lockdep is reporting a deadlock with following trace. Saw this on my > powerpc vm with 4GB of ram, running Linus/master kernel. Though, I > don't have exact testcase to reproduce it. Is this something known? I am

Re: linux-next: build warning after merge of the overlayfs tree

On Thursday, November 9, 2017 4:03:06 AM IST Stephen Rothwell wrote: > Hi Miklos, > > After merging the overlayfs tree, today's linux-next build (powerpc > ppc64_defconfig) produced this warning: > > fs/overlayfs/super.c: In function 'ovl_fill_super': > fs/overlayfs/super.c:1070:25: warning: 'num

BUG_ON() in irq_work_run_list

Executing fstests' generic/036 test in a loop on next-20171013 kernel causes BUG_ON()'s condition to evaluate to true, run fstests generic/036 at 2017-10-14 09:23:29 [ cut here ] kernel BUG at /root/repos/linux/kernel/irq_work.c:138! Oops: Exception in kernel mode, sig: 5 [

Re: [PATCH] ext4: fix clang build regression

a fixed-size array > again, but keeping the check for the array overflow. > > Fixes: 2df2c3402fc8 ("ext4: fix warning about stack corruption") > Reported-by: Stefan Agner > Signed-off-by: Arnd Bergmann I executed xfstests on a ppc64 machine with both 4k and 64k block size combination. Tested-by: Chandan Rajendra -- chandan

Re: [PATCH 1/2] ext4: fix warning about stack corruption

don't actually print the last two > members of the array, as we loop though just the first 14 members. > This could be easily addressed by adding two extra columns in the output, > but that could in theory break parsers in user space, and should be > a separate patch if we decide to modify it. > I executed xfstests on a ppc64 machine with both 4k and 64k block size combination. Tested-by: Chandan Rajendra -- chandan

Re: [PATCH] direct-io: don't introduce another read of inode->i_blkbits

more detailed problem > description and reproducer. > > Fixes: 20ce44d545844 > Signed-off-by: Jeff Moyer > > --- > Chandan, can you please test this to ensure this still fixes your problem? This patch fixes the failure, Tested-by: Chandan Rajendra -- chandan

Re: ext4 filesystem corruption with 4.10-rc2 on ppc64le

On Wednesday, January 04, 2017 10:28:37 AM Theodore Ts'o wrote: > On Wed, Jan 04, 2017 at 11:32:42AM +0530, Chandan Rajendra wrote: > > On Wednesday, January 04, 2017 04:18:08 PM Anton Blanchard wrote: > > > I'm consistently seeing ext4 filesystem corruption using

[PATCH] do_direct_IO: Use inode->i_blkbits to compute block count to be cleaned

on an ext4 filesystem with 64k as the block size and when using a virtio based disk (having 512 byte as the logical block size) inside a kvm guest. This commit fixes the bug by using inode->i_blkbits to compute the number of blocks to be cleaned. Signed-off-by: Chandan Rajendra --- fs/direct

Re: ext4 filesystem corruption with 4.10-rc2 on ppc64le

On Wednesday, January 04, 2017 04:18:08 PM Anton Blanchard wrote: > Hi, > > I'm consistently seeing ext4 filesystem corruption using a mainline > kernel. It doesn't take much to trigger it - download a ppc64le Ubuntu > cloud image, boot it in KVM and run: > > sudo apt-get update > sudo apt-get di

[PATCH] clean_bdev_aliases: Prevent cleaning blocks that are not in block range

: Chandan Rajendra --- fs/buffer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/buffer.c b/fs/buffer.c index 1df2bd5..28484b3 100644 --- a/fs/buffer.c +++ b/fs/buffer.c @@ -1660,7 +1660,7 @@ void clean_bdev_aliases(struct block_device *bdev, sector_t block, sector_t len

Re: linux-next: manual merge of the btrfs-kdave tree with Linus' tree

On Tuesday 02 Feb 2016 10:22:16 Stephen Rothwell wrote: > Hi David, > > Today's linux-next merge of the btrfs-kdave tree got a conflict in: > > fs/btrfs/file.c > > between commit: > > 5955102c9984 ("wrappers for ->i_mutex access") > > from Linus' tree and commit: > > 9703fefe0b13 ("Btrf