Re: [PATCH v3] powerpc/64: Fix memcmp reading past the end of src/dest

2019-03-25 Thread Chandan Rajendra
s2. So check if it's within 8 > bytes of a 4K boundary and if so go to the byte-by-byte loop. > > Fixes: 2d9ee327adce ("powerpc/64: Align bytes before fall back to .Lshort in > powerpc64 memcmp()") > Cc: sta...@vger.kernel.org # v4.19+ > Reported-by: Chandan Rajendra

Re: [PATCH v3] powerpc/64: Fix memcmp reading past the end of src/dest

2019-03-25 Thread Chandan Rajendra
s2. So check if it's within 8 > bytes of a 4K boundary and if so go to the byte-by-byte loop. > > Fixes: 2d9ee327adce ("powerpc/64: Align bytes before fall back to .Lshort in > powerpc64 memcmp()") > Cc: sta...@vger.kernel.org # v4.19+ > Reported-by: Chandan Rajendra

Re: BUG: memcmp(): Accessing invalid memory location

2019-02-06 Thread Chandan Rajendra
On Thursday, February 7, 2019 5:27:09 AM IST Michael Ellerman wrote: > Chandan Rajendra writes: > > On Wednesday, February 6, 2019 5:20:04 PM IST Michael Ellerman wrote: > >> Chandan Rajendra writes: > >> > On Friday, February 1, 2019 4:43:52 PM IST Michael E

Re: BUG: memcmp(): Accessing invalid memory location

2019-02-06 Thread Chandan Rajendra
On Wednesday, February 6, 2019 5:20:04 PM IST Michael Ellerman wrote: > Chandan Rajendra writes: > > On Friday, February 1, 2019 4:43:52 PM IST Michael Ellerman wrote: > >> Michael Ellerman writes: > >> > >> > Adding Simon who wrote the code. > >>

Re: BUG: memcmp(): Accessing invalid memory location

2019-02-03 Thread Chandan Rajendra
On Friday, February 1, 2019 4:43:52 PM IST Michael Ellerman wrote: > Michael Ellerman writes: > > > Adding Simon who wrote the code. > > > > Chandan Rajendra writes: > >> When executing fstests' generic/026 test, I hit the following call trace, > >>

BUG: memcmp(): Accessing invalid memory location

2019-01-24 Thread Chandan Rajendra
When executing fstests' generic/026 test, I hit the following call trace, [ 417.061038] BUG: Unable to handle kernel data access at 0xc0062ac4 [ 417.062172] Faulting instruction address: 0xc0092240 [ 417.062242] Oops: Kernel access of bad area, sig: 11 [#1] [ 417.062299] LE

BUG_ON() in irq_work_run_list

2017-10-14 Thread Chandan Rajendra
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

[PATCH] powerpc: Wire up statx() syscall

2017-03-16 Thread Chandan Rajendra
of test-statx.c Signed-off-by: Chandan Rajendra <chan...@linux.vnet.ibm.com> --- arch/powerpc/include/asm/systbl.h | 1 + arch/powerpc/include/asm/unistd.h | 2 +- arch/powerpc/include/uapi/asm/unistd.h | 1 + 3 files changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/p

Re: syscall statx not implemented on powerpc

2017-03-13 Thread Chandan Rajendra
On Monday, March 13, 2017 03:33:07 AM Chris Packham wrote: > Hi, > > I've just attempted to build a powerpc kernel from 4.11-rc2 using a > custom defconfig (available on request) and I'm hitting the following > error in the early stages of compilation. > > :1325:2: error: #warning syscall

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

2017-01-09 Thread Chandan Rajendra
detailed problem > description and reproducer. > > Fixes: 20ce44d545844 > Signed-off-by: Jeff Moyer <jmo...@redhat.com> > > --- > Chandan, can you please test this to ensure this still fixes your problem? This patch fixes the failure, Tested-by: Chandan Rajendra <chan...@linux.vnet.ibm.com> -- chandan

Re: ext4 filesystem corruption with 4.10-rc2 on ppc64le

2017-01-08 Thread Chandan Rajendra
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 a mai

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

2017-01-08 Thread Chandan Rajendra
ecuted 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 Rajen

Re: ext4 filesystem corruption with 4.10-rc2 on ppc64le

2017-01-03 Thread Chandan Rajendra
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

[PATCH] ext4: ext4_mb_mark_free_simple: Fix integer value truncation

2016-11-03 Thread Chandan Rajendra
'border' variable is set to a value of 2 times the block size of the underlying filesystem. With 64k block size, the resulting value won't fit into a 16-bit variable. Hence this commit changes the data type of 'border' to 'unsigned int'. Signed-off-by: Chandan Rajendra <chan...@linux.vnet.ibm.

Re: [PATCH] powerpc: Wire up copy_file_range() syscall

2016-01-13 Thread Chandan Rajendra
On Thursday 14 Jan 2016 09:53:31 Michael Ellerman wrote: > On Wed, 2016-01-13 at 22:20 +0530, Chandan Rajendra wrote: > > Test runs on a ppc64 BE guest succeeded. > > Were the tests built 64-bit or 32-bit? > The test tool (xfs_io to be precise) was built as a 64-bit bi

[PATCH] powerpc: Wire up copy_file_range() syscall

2016-01-13 Thread Chandan Rajendra
Test runs on a ppc64 BE guest succeeded. Signed-off-by: Chandan Rajendra <chan...@linux.vnet.ibm.com> --- The "yet to be upstreamed" fstests test (https://github.com/chandanr/xfstests/commit/c2ce6196711e02792b434448e29f45b5f9a955f6) was used to test the syscall. The test