ffsb job does not exit on xfs 4.14-rc1+

Hi, ffsb test won't exit like this on Linus tree 4.14-rc1+. Latest commit cd4175b11685 This does not happen on v4.13 Thanks, 1 1505 Ss 0 0:00 /usr/sbin/sshd -D 1505 1752 Ss 0 0:00 \_ sshd: root [priv] 1752 1762 S0 0:00 | \_ sshd: root@pts/0 1762 1763 Ss 0

ffsb job does not exit on xfs 4.14-rc1+

Hi, ffsb test won't exit like this on Linus tree 4.14-rc1+. Latest commit cd4175b11685 This does not happen on v4.13 Thanks, 1 1505 Ss 0 0:00 /usr/sbin/sshd -D 1505 1752 Ss 0 0:00 \_ sshd: root [priv] 1752 1762 S0 0:00 | \_ sshd: root@pts/0 1762 1763 Ss 0

Re: fanotify_mark FAN_MARK_FLUSH | _MOUNT stress blocks write to directory

On Thu, Aug 31, 2017 at 07:52:41AM +0300, Amir Goldstein wrote: > On Thu, Aug 31, 2017 at 6:51 AM, Xiong Zhou <xz...@redhat.com> wrote: > > hi, > > > > This happens on 4.13.0-rc7+ to commit 42ff72c > > Don't understand. Is this a regression? from which commi

Re: fanotify_mark FAN_MARK_FLUSH | _MOUNT stress blocks write to directory

On Thu, Aug 31, 2017 at 07:52:41AM +0300, Amir Goldstein wrote: > On Thu, Aug 31, 2017 at 6:51 AM, Xiong Zhou wrote: > > hi, > > > > This happens on 4.13.0-rc7+ to commit 42ff72c > > Don't understand. Is this a regression? from which commit? No. I'm just saying the

fanotify_mark FAN_MARK_FLUSH | _MOUNT stress blocks write to directory

hi, This happens on 4.13.0-rc7+ to commit 42ff72c After firing up the stress, touch a file in monitoring directory could hang like forever. Pretty easy to hit. Thanks, Xiong [ 492.060879] INFO: task touch:2259 blocked for more than 120 seconds. [ 492.093497] Not tainted

fanotify_mark FAN_MARK_FLUSH | _MOUNT stress blocks write to directory

hi, This happens on 4.13.0-rc7+ to commit 42ff72c After firing up the stress, touch a file in monitoring directory could hang like forever. Pretty easy to hit. Thanks, Xiong [ 492.060879] INFO: task touch:2259 blocked for more than 120 seconds. [ 492.093497] Not tainted

0324 tree BUG at kernel/auditsc.c:1513!

[11230.930568] [ cut here ] [11230.953828] kernel BUG at kernel/auditsc.c:1513! [11230.976157] invalid opcode: [#1] SMP [11230.995917] Modules linked in: btrfs xor raid6_pq ext2 dm_thin_pool dm_persistent_data dm_bio_prison dm_bufio loop ext4 jbd2 mbcache xt_CHECKSUM

0324 tree BUG at kernel/auditsc.c:1513!

[11230.930568] [ cut here ] [11230.953828] kernel BUG at kernel/auditsc.c:1513! [11230.976157] invalid opcode: [#1] SMP [11230.995917] Modules linked in: btrfs xor raid6_pq ext2 dm_thin_pool dm_persistent_data dm_bio_prison dm_bufio loop ext4 jbd2 mbcache xt_CHECKSUM

fsx tests on DAX started to fail with msync failure on 0307 -next tree

Hi, xfstests cases: generic/075 generic/112 generic/127 generic/231 generic/263 fail with DAX, pass without it. Both xfs and ext4. It was okay on 0306 -next tree. + ./check generic/075 FSTYP -- xfs (non-debug) PLATFORM -- Linux/x86_64 hp-dl360g9-12

fsx tests on DAX started to fail with msync failure on 0307 -next tree

Hi, xfstests cases: generic/075 generic/112 generic/127 generic/231 generic/263 fail with DAX, pass without it. Both xfs and ext4. It was okay on 0306 -next tree. + ./check generic/075 FSTYP -- xfs (non-debug) PLATFORM -- Linux/x86_64 hp-dl360g9-12

Re: [PATCH 0/2] fix for direct-I/O to DAX mappings

On Sat, Feb 25, 2017 at 09:08:28AM -0800, Dan Williams wrote: > Hi Andrew, > > While Ross was doing a review of a new mmap+DAX direct-I/O test case for > xfstests, from Xiong, he noticed occasions where it failed to trigger a > page dirty event. Dave then spotted the problem fixed by patch1. The

Re: [PATCH 0/2] fix for direct-I/O to DAX mappings

On Sat, Feb 25, 2017 at 09:08:28AM -0800, Dan Williams wrote: > Hi Andrew, > > While Ross was doing a review of a new mmap+DAX direct-I/O test case for > xfstests, from Xiong, he noticed occasions where it failed to trigger a > page dirty event. Dave then spotted the problem fixed by patch1. The

Re: boot failure, module: overflow in relocation

Nevermind, it got fixed now i think. On Thu, Mar 02, 2017 at 05:51:27PM +0800, Xiong Zhou wrote: > Hi, > > One host failed to boot while merge going on, > > [ 13.076303] module: overflow in relocation type 10 val a0060e58 > [ 13.076338] module: overflow in relo

Re: boot failure, module: overflow in relocation

Nevermind, it got fixed now i think. On Thu, Mar 02, 2017 at 05:51:27PM +0800, Xiong Zhou wrote: > Hi, > > One host failed to boot while merge going on, > > [ 13.076303] module: overflow in relocation type 10 val a0060e58 > [ 13.076338] module: overflow in relo

boot failure, module: overflow in relocation

Hi, One host failed to boot while merge going on, [ 13.076303] module: overflow in relocation type 10 val a0060e58 [ 13.076338] module: overflow in relocation type 10 val a01ac96b [ 13.076340] module: `scsi_transport_sas' likely not compiled with -mcmodel=kernel [

boot failure, module: overflow in relocation

Hi, One host failed to boot while merge going on, [ 13.076303] module: overflow in relocation type 10 val a0060e58 [ 13.076338] module: overflow in relocation type 10 val a01ac96b [ 13.076340] module: `scsi_transport_sas' likely not compiled with -mcmodel=kernel [

Re: mm allocation failure and hang when running xfstests generic/269 on xfs

On Thu, Mar 02, 2017 at 09:42:23AM +0100, Michal Hocko wrote: > On Thu 02-03-17 12:17:47, Anshuman Khandual wrote: > > On 03/02/2017 10:49 AM, Xiong Zhou wrote: > > > On Wed, Mar 01, 2017 at 04:37:31PM -0800, Christoph Hellwig wrote: > > >> On Wed, Mar 01, 2017 a

Re: mm allocation failure and hang when running xfstests generic/269 on xfs

On Thu, Mar 02, 2017 at 09:42:23AM +0100, Michal Hocko wrote: > On Thu 02-03-17 12:17:47, Anshuman Khandual wrote: > > On 03/02/2017 10:49 AM, Xiong Zhou wrote: > > > On Wed, Mar 01, 2017 at 04:37:31PM -0800, Christoph Hellwig wrote: > > >> On Wed, Mar 01, 2017 a

Re: mm allocation failure and hang when running xfstests generic/269 on xfs

On Wed, Mar 01, 2017 at 04:37:31PM -0800, Christoph Hellwig wrote: > On Wed, Mar 01, 2017 at 12:46:34PM +0800, Xiong Zhou wrote: > > Hi, > > > > It's reproduciable, not everytime though. Ext4 works fine. > > On ext4 fsstress won't run bulkstat because it doesn't exist

Re: mm allocation failure and hang when running xfstests generic/269 on xfs

On Wed, Mar 01, 2017 at 04:37:31PM -0800, Christoph Hellwig wrote: > On Wed, Mar 01, 2017 at 12:46:34PM +0800, Xiong Zhou wrote: > > Hi, > > > > It's reproduciable, not everytime though. Ext4 works fine. > > On ext4 fsstress won't run bulkstat because it doesn't exist

mm allocation failure and hang when running xfstests generic/269 on xfs

Hi, It's reproduciable, not everytime though. Ext4 works fine. Based on test logs, it's bad on Linus tree commit: e5d56ef Merge tag 'watchdog-for-linus-v4.11' It's good on commit: f8e6859 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc Trying to narrow down a little bit.

mm allocation failure and hang when running xfstests generic/269 on xfs

Hi, It's reproduciable, not everytime though. Ext4 works fine. Based on test logs, it's bad on Linus tree commit: e5d56ef Merge tag 'watchdog-for-linus-v4.11' It's good on commit: f8e6859 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc Trying to narrow down a little bit.

Ext4 new shutdown ioctl fails generic/04{4,5,6}

Hi, On latest Linus tree, xfstests generic/04{4,5,6} fails. FSTYP -- ext4 PLATFORM -- Linux/x86_64 rhel73 4.10.0-master-45554b2+ MKFS_OPTIONS -- /dev/sdc MOUNT_OPTIONS -- -o acl,user_xattr -o context=system_u:object_r:nfs_t:s0 /dev/sdc /test2 generic/045 - output mismatch

Ext4 new shutdown ioctl fails generic/04{4,5,6}

Hi, On latest Linus tree, xfstests generic/04{4,5,6} fails. FSTYP -- ext4 PLATFORM -- Linux/x86_64 rhel73 4.10.0-master-45554b2+ MKFS_OPTIONS -- /dev/sdc MOUNT_OPTIONS -- -o acl,user_xattr -o context=system_u:object_r:nfs_t:s0 /dev/sdc /test2 generic/045 - output mismatch

LTP write03 writev07 xfs failures

Hi, These 2 tests PASS on Linus tree commit: 37c8596 Merge tag 'tty-4.11-rc1' of git://git.kernel.org/pub/scm/linux... FAIL on commit: 60e8d3e Merge tag 'pci-v4.11-changes' of git://git.kernel.org/pub/scm/... LTP latest commit: c60d3ca move_pages12: include lapi/mmap.h Steps: sh-4.2# pwd

LTP write03 writev07 xfs failures

Hi, These 2 tests PASS on Linus tree commit: 37c8596 Merge tag 'tty-4.11-rc1' of git://git.kernel.org/pub/scm/linux... FAIL on commit: 60e8d3e Merge tag 'pci-v4.11-changes' of git://git.kernel.org/pub/scm/... LTP latest commit: c60d3ca move_pages12: include lapi/mmap.h Steps: sh-4.2# pwd

LTP write03 writev07 xfs failures

Hi, These 2 tests PASS on Linus tree commit: 37c8596 Merge tag 'tty-4.11-rc1' of git://git.kernel.org/pub/scm/linux... FAIL on commit: 60e8d3e Merge tag 'pci-v4.11-changes' of git://git.kernel.org/pub/scm/... LTP latest commit: c60d3ca move_pages12: include lapi/mmap.h Steps: sh-4.2# pwd

LTP write03 writev07 xfs failures

Hi, These 2 tests PASS on Linus tree commit: 37c8596 Merge tag 'tty-4.11-rc1' of git://git.kernel.org/pub/scm/linux... FAIL on commit: 60e8d3e Merge tag 'pci-v4.11-changes' of git://git.kernel.org/pub/scm/... LTP latest commit: c60d3ca move_pages12: include lapi/mmap.h Steps: sh-4.2# pwd

Re: Starting kvm/qemu guest crash kernel linux-next 0221 tree

On Wed, Feb 22, 2017 at 09:28:21AM +0100, Paolo Bonzini wrote: > > > On 22/02/2017 02:52, Xiong Zhou wrote: > > Hi, > > > > Starting a guest begin to crash kernel on 0221 -next tree. > > > > It's fine on 0220 tree. I reproduced only once. Now it's hard

Re: Starting kvm/qemu guest crash kernel linux-next 0221 tree

On Wed, Feb 22, 2017 at 09:28:21AM +0100, Paolo Bonzini wrote: > > > On 22/02/2017 02:52, Xiong Zhou wrote: > > Hi, > > > > Starting a guest begin to crash kernel on 0221 -next tree. > > > > It's fine on 0220 tree. I reproduced only once. Now it's hard

Starting kvm/qemu guest crash kernel linux-next 0221 tree

Hi, Starting a guest begin to crash kernel on 0221 -next tree. It's fine on 0220 tree. Thanks, Xiong - Feb 22 09:24:29 host-12 systemd-journald[405]: Received SIGTERM from PID 1 (systemd). Feb 22 09:24:29 host-12 kernel: systemd: 24 output lines suppressed due to ratelimiting Feb

Starting kvm/qemu guest crash kernel linux-next 0221 tree

Hi, Starting a guest begin to crash kernel on 0221 -next tree. It's fine on 0220 tree. Thanks, Xiong - Feb 22 09:24:29 host-12 systemd-journald[405]: Received SIGTERM from PID 1 (systemd). Feb 22 09:24:29 host-12 kernel: systemd: 24 output lines suppressed due to ratelimiting Feb

Re: linux-next 0112 tree breaks fs DAX

On Fri, Jan 13, 2017 at 06:16:41PM +0800, Xiong Zhou wrote: > Hi, > > These cases "hang" when testing with -o dax mount option: > xfstests generic/030 generic/34{0,4,5,6} generic/198 > (maybe more) > > The test programme holetest or aiodio keep running f

Re: linux-next 0112 tree breaks fs DAX

On Fri, Jan 13, 2017 at 06:16:41PM +0800, Xiong Zhou wrote: > Hi, > > These cases "hang" when testing with -o dax mount option: > xfstests generic/030 generic/34{0,4,5,6} generic/198 > (maybe more) > > The test programme holetest or aiodio keep running f

Re: [PATCH] dax: fix deadlock with DAX 4k holes

lly transition from > locking based on the DAX empty entry to locking on the 4k zero page. > > With the test case reported by Xiong this happens very regularly in my test > setup, with some runs resulting in 9+ threads in this deadlocked state. > With this fix I've been able to run that

Re: [PATCH] dax: fix deadlock with DAX 4k holes

lly transition from > locking based on the DAX empty entry to locking on the 4k zero page. > > With the test case reported by Xiong this happens very regularly in my test > setup, with some runs resulting in 9+ threads in this deadlocked state. > With this fix I've been able to run that s

Re: LTP rwtest01 blocks on DAX mountpoint

On Tue, Jan 03, 2017 at 09:57:10AM -0700, Ross Zwisler wrote: > On Tue, Jan 03, 2017 at 02:49:22PM +0800, Xiong Zhou wrote: > > On Mon, Jan 02, 2017 at 02:49:41PM -0700, Ross Zwisler wrote: > > > On Mon, Jan 02, 2017 at 06:16:17PM +0100, Jan Kara wrote: > > > > On Fri

Re: LTP rwtest01 blocks on DAX mountpoint

On Tue, Jan 03, 2017 at 09:57:10AM -0700, Ross Zwisler wrote: > On Tue, Jan 03, 2017 at 02:49:22PM +0800, Xiong Zhou wrote: > > On Mon, Jan 02, 2017 at 02:49:41PM -0700, Ross Zwisler wrote: > > > On Mon, Jan 02, 2017 at 06:16:17PM +0100, Jan Kara wrote: > > > > On Fri

Re: LTP rwtest01 blocks on DAX mountpoint

On Tue, Jan 03, 2017 at 09:57:10AM -0700, Ross Zwisler wrote: > On Tue, Jan 03, 2017 at 02:49:22PM +0800, Xiong Zhou wrote: > > On Mon, Jan 02, 2017 at 02:49:41PM -0700, Ross Zwisler wrote: > > > On Mon, Jan 02, 2017 at 06:16:17PM +0100, Jan Kara wrote: > > > > On Fri

Re: LTP rwtest01 blocks on DAX mountpoint

On Tue, Jan 03, 2017 at 09:57:10AM -0700, Ross Zwisler wrote: > On Tue, Jan 03, 2017 at 02:49:22PM +0800, Xiong Zhou wrote: > > On Mon, Jan 02, 2017 at 02:49:41PM -0700, Ross Zwisler wrote: > > > On Mon, Jan 02, 2017 at 06:16:17PM +0100, Jan Kara wrote: > > > > On Fri

Re: LTP rwtest01 blocks on DAX mountpoint

On Tue, Jan 03, 2017 at 09:57:10AM -0700, Ross Zwisler wrote: > On Tue, Jan 03, 2017 at 02:49:22PM +0800, Xiong Zhou wrote: > > On Mon, Jan 02, 2017 at 02:49:41PM -0700, Ross Zwisler wrote: > > > On Mon, Jan 02, 2017 at 06:16:17PM +0100, Jan Kara wrote: > > > > On Fri

Re: LTP rwtest01 blocks on DAX mountpoint

On Tue, Jan 03, 2017 at 09:57:10AM -0700, Ross Zwisler wrote: > On Tue, Jan 03, 2017 at 02:49:22PM +0800, Xiong Zhou wrote: > > On Mon, Jan 02, 2017 at 02:49:41PM -0700, Ross Zwisler wrote: > > > On Mon, Jan 02, 2017 at 06:16:17PM +0100, Jan Kara wrote: > > > > On Fri

Re: LTP rwtest01 blocks on DAX mountpoint

On Mon, Jan 02, 2017 at 02:49:41PM -0700, Ross Zwisler wrote: > On Mon, Jan 02, 2017 at 06:16:17PM +0100, Jan Kara wrote: > > On Fri 30-12-16 17:33:53, Xiong Zhou wrote: > > > On Sat, Dec 24, 2016 at 07:07:14PM +0800, Xiong Zhou wrote: > > > > Hi lists, snip

Re: LTP rwtest01 blocks on DAX mountpoint

On Mon, Jan 02, 2017 at 02:49:41PM -0700, Ross Zwisler wrote: > On Mon, Jan 02, 2017 at 06:16:17PM +0100, Jan Kara wrote: > > On Fri 30-12-16 17:33:53, Xiong Zhou wrote: > > > On Sat, Dec 24, 2016 at 07:07:14PM +0800, Xiong Zhou wrote: > > > > Hi lists, snip

Re: LTP rwtest01 blocks on DAX mountpoint

On Sat, Dec 24, 2016 at 07:07:14PM +0800, Xiong Zhou wrote: > Hi lists, > > Since around 20161129 tag, LTP rwtest01 on dax mountpoint blocks > on linux-next tree, now on Linus tree. > > In "normal", rwtest01 subcase ends in a few minutes, now it keeps > running fo

Re: LTP rwtest01 blocks on DAX mountpoint

On Sat, Dec 24, 2016 at 07:07:14PM +0800, Xiong Zhou wrote: > Hi lists, > > Since around 20161129 tag, LTP rwtest01 on dax mountpoint blocks > on linux-next tree, now on Linus tree. > > In "normal", rwtest01 subcase ends in a few minutes, now it keeps > running fo

LTP rwtest01 blocks on DAX mountpoint

Hi lists, Since around 20161129 tag, LTP rwtest01 on dax mountpoint blocks on linux-next tree, now on Linus tree. In "normal", rwtest01 subcase ends in a few minutes, now it keeps running for hours on dax mountpoint, both ext4 and xfs. Ctrl + c can interrupt it. It is always reproducible,

LTP rwtest01 blocks on DAX mountpoint

Hi lists, Since around 20161129 tag, LTP rwtest01 on dax mountpoint blocks on linux-next tree, now on Linus tree. In "normal", rwtest01 subcase ends in a few minutes, now it keeps running for hours on dax mountpoint, both ext4 and xfs. Ctrl + c can interrupt it. It is always reproducible,

multi-threads libvmmalloc fork test hang

# description nvml test suite vmmalloc_fork test hang. $ ps -eo stat,comm | grep vmma S+ vmmalloc_fork Sl+ vmmalloc_fork Z+ vmmalloc_fork Sl+ vmmalloc_fork Z+ vmmalloc_fork Z+ vmmalloc_fork Sl+ vmmalloc_fork Z+ vmmalloc_fork Z+ vmmalloc_fork Z+ vmmalloc_fork dmesg: [

multi-threads libvmmalloc fork test hang

# description nvml test suite vmmalloc_fork test hang. $ ps -eo stat,comm | grep vmma S+ vmmalloc_fork Sl+ vmmalloc_fork Z+ vmmalloc_fork Sl+ vmmalloc_fork Z+ vmmalloc_fork Z+ vmmalloc_fork Sl+ vmmalloc_fork Z+ vmmalloc_fork Z+ vmmalloc_fork Z+ vmmalloc_fork dmesg: [

xfstests xfs fuzzers fail with DAX

Hi, A few xfs fuzzers in xfstests fail with dax mount option, pass without dax. They are xfs/086 xfs/088 xfs/089 xfs/091. xfstests to commit 4470ad4c7e (Jul 26) kernel to commit dd95069545 (Jul 24) + ./check xfs/091 FSTYP -- xfs (non-debug) PLATFORM -- Linux/x86_64 rhel73

xfstests xfs fuzzers fail with DAX

Hi, A few xfs fuzzers in xfstests fail with dax mount option, pass without dax. They are xfs/086 xfs/088 xfs/089 xfs/091. xfstests to commit 4470ad4c7e (Jul 26) kernel to commit dd95069545 (Jul 24) + ./check xfs/091 FSTYP -- xfs (non-debug) PLATFORM -- Linux/x86_64 rhel73

Re: [PATCH] Fix reported kmemleak

anch: v4.7-rc2+bio_put > > Cc: Christoph Hellwig <h...@lst.de> > Cc: ax...@kernel.dk > cc: David Drysdale <drysd...@google.com> > Cc: Xiong Zhou <xz...@redhat.com> Thanks for the information! > Cc: Stephen Rothwell <s...@canb.auug.org.au> > Cc: lin

Re: [PATCH] Fix reported kmemleak

branch: v4.7-rc2+bio_put > > Cc: Christoph Hellwig > Cc: ax...@kernel.dk > cc: David Drysdale > Cc: Xiong Zhou Thanks for the information! > Cc: Stephen Rothwell > Cc: linux-n...@vger.kernel.org > Cc: linux-nvd...@ml01.01.org > Cc: Christoph Hellwig > Cc: Larr

Re: linux-next/linux memleak after IO on dax mountpoint

adding block-list On Fri, Jun 03, 2016 at 09:48:27AM -0700, Bart Van Assche wrote: > On 06/02/2016 08:22 AM, David Drysdale wrote: > > FWIW, I'm also seeing kmemleak report a leak with v4.7-rc1, in > > a different scenario (just normal desktop use). Not done much > > digging so far, but this

Re: linux-next/linux memleak after IO on dax mountpoint

adding block-list On Fri, Jun 03, 2016 at 09:48:27AM -0700, Bart Van Assche wrote: > On 06/02/2016 08:22 AM, David Drysdale wrote: > > FWIW, I'm also seeing kmemleak report a leak with v4.7-rc1, in > > a different scenario (just normal desktop use). Not done much > > digging so far, but this

Re: linux-next/linux memleak after IO on dax mountpoint

On Thu, Jun 02, 2016 at 04:22:37PM +0100, David Drysdale wrote: > On Sat, May 28, 2016 at 5:05 AM, Xiong Zhou <xz...@redhat.com> wrote: > > On Fri, May 27, 2016 at 04:46:17PM +0800, Xiong Zhou wrote: > > ... > >> Still working on to id which commit in

Re: linux-next/linux memleak after IO on dax mountpoint

On Thu, Jun 02, 2016 at 04:22:37PM +0100, David Drysdale wrote: > On Sat, May 28, 2016 at 5:05 AM, Xiong Zhou wrote: > > On Fri, May 27, 2016 at 04:46:17PM +0800, Xiong Zhou wrote: > > ... > >> Still working on to id which commit in this merge causes this issue

Re: linux-next memleak after IO on dax mountpoint

Hi, Jeff On Wed, Jun 01, 2016 at 10:37:26AM -0400, Jeff Moyer wrote: > Xiong Zhou <xz...@redhat.com> writes: > > > On Fri, May 27, 2016 at 04:46:17PM +0800, Xiong Zhou wrote: > > ... > >> Still working on to id which commit in this merge causes this issuer,

Re: linux-next memleak after IO on dax mountpoint

Hi, Jeff On Wed, Jun 01, 2016 at 10:37:26AM -0400, Jeff Moyer wrote: > Xiong Zhou writes: > > > On Fri, May 27, 2016 at 04:46:17PM +0800, Xiong Zhou wrote: > > ... > >> Still working on to id which commit in this merge causes this issuer, > > > > Narrow

Re: linux-next memleak after IO on dax mountpoint

On Fri, May 27, 2016 at 04:46:17PM +0800, Xiong Zhou wrote: ... > Still working on to id which commit in this merge causes this issuer, Narrowed down to: 37e5823 block: add offset in blk_add_request_payload() e048948 blk-mq: Export tagset iter function 58b4560 nvme: add helper nvme_map_

Re: linux-next memleak after IO on dax mountpoint

On Fri, May 27, 2016 at 04:46:17PM +0800, Xiong Zhou wrote: ... > Still working on to id which commit in this merge causes this issuer, Narrowed down to: 37e5823 block: add offset in blk_add_request_payload() e048948 blk-mq: Export tagset iter function 58b4560 nvme: add helper nvme_map_

linux-next memleak after IO on dax mountpoint

Hi, Reporting an oom/memleak issue in linux-next tree: #Description: dbench invokes oom-killer, make host unavaiable. dbench was doing IO on nvdimm device mounted fs with dax mount option. It happens on both xfs and ext4 filesystems. It does not happen testing without dax mountoption. Seems

linux-next memleak after IO on dax mountpoint

Hi, Reporting an oom/memleak issue in linux-next tree: #Description: dbench invokes oom-killer, make host unavaiable. dbench was doing IO on nvdimm device mounted fs with dax mount option. It happens on both xfs and ext4 filesystems. It does not happen testing without dax mountoption. Seems

Re: linux-next: Tree for May 17

Hi Stephen, On Mon, May 23, 2016 at 4:37 PM, Stephen Rothwell <s...@canb.auug.org.au> wrote: > Hi Xiong, > > On Mon, 23 May 2016 16:13:28 +0800 Xiong Zhou <jencce.ker...@gmail.com> wrote: >> >> hi, >> >> On Tue, May 17, 2016 at 1:04 PM, Steph

Re: linux-next: Tree for May 17

Hi Stephen, On Mon, May 23, 2016 at 4:37 PM, Stephen Rothwell wrote: > Hi Xiong, > > On Mon, 23 May 2016 16:13:28 +0800 Xiong Zhou wrote: >> >> hi, >> >> On Tue, May 17, 2016 at 1:04 PM, Stephen Rothwell >> wrote: >> > >> > I have cre

Re: linux-next: Tree for May 17

hi, On Tue, May 17, 2016 at 1:04 PM, Stephen Rothwell wrote: > Hi all, > > Please do not add any v4.8 destined material to your linux-next included > branches until after v4.7-rc1 has been released. > > Changes since 20160516: > > The vfs tree gained a conflict against the

Re: linux-next: Tree for May 17

hi, On Tue, May 17, 2016 at 1:04 PM, Stephen Rothwell wrote: > Hi all, > > Please do not add any v4.8 destined material to your linux-next included > branches until after v4.7-rc1 has been released. > > Changes since 20160516: > > The vfs tree gained a conflict against the ext4 tree. > > The

Re: [PATCH v3 2/5] /dev/dax, pmem: direct access to persistent memory

On Wed, May 18, 2016 at 01:56:16PM -0700, Dan Williams wrote: > Device DAX is the device-centric analogue of Filesystem DAX > (CONFIG_FS_DAX). It allows memory ranges to be allocated and mapped > without need of an intervening file system. Device DAX is strict, > precise and predictable.

Re: [PATCH v3 2/5] /dev/dax, pmem: direct access to persistent memory

On Wed, May 18, 2016 at 01:56:16PM -0700, Dan Williams wrote: > Device DAX is the device-centric analogue of Filesystem DAX > (CONFIG_FS_DAX). It allows memory ranges to be allocated and mapped > without need of an intervening file system. Device DAX is strict, > precise and predictable.

Re: Linux-next parallel cp workload hang

On Thu, May 19, 2016 at 09:02:31AM +1000, Dave Chinner wrote: > On Thu, May 19, 2016 at 12:17:26AM +1000, Dave Chinner wrote: > > Patch below should fix the deadlock. > > The test has been running for several hours without failure using > this patch, so I'd say this fixes the problem... Yes, the

Re: Linux-next parallel cp workload hang

On Thu, May 19, 2016 at 09:02:31AM +1000, Dave Chinner wrote: > On Thu, May 19, 2016 at 12:17:26AM +1000, Dave Chinner wrote: > > Patch below should fix the deadlock. > > The test has been running for several hours without failure using > this patch, so I'd say this fixes the problem... Yes, the

Linux-next parallel cp workload hang

Hi, Parallel cp workload (xfstests generic/273) hangs like blow. It's reproducible with a small chance, less the 1/100 i think. Have hit this in linux-next 20160504 0506 0510 trees, testing on xfs with loop or block device. Ext4 survived several rounds of testing. Linux next 20160510 tree hangs

Linux-next parallel cp workload hang

Hi, Parallel cp workload (xfstests generic/273) hangs like blow. It's reproducible with a small chance, less the 1/100 i think. Have hit this in linux-next 20160504 0506 0510 trees, testing on xfs with loop or block device. Ext4 survived several rounds of testing. Linux next 20160510 tree hangs

Re: [PATCH trivial] scripts/prune-kernel: remove kdump images

ping ? On Mon, Mar 7, 2016 at 3:56 PM, Xiong Zhou <jencce.ker...@gmail.com> wrote: > Signed-off-by: Xiong Zhou <jencce.ker...@gmail.com> > --- > scripts/prune-kernel | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/scripts/prune-kernel

Re: [PATCH trivial] scripts/prune-kernel: remove kdump images

ping ? On Mon, Mar 7, 2016 at 3:56 PM, Xiong Zhou wrote: > Signed-off-by: Xiong Zhou > --- > scripts/prune-kernel | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/scripts/prune-kernel b/scripts/prune-kernel > index ab5034e..9c67be2 100755 > --

Re: binary execution from DAX mount hang since next-20160407

On Fri, Apr 15, 2016 at 4:38 PM, Hugh Dickins <hu...@google.com> wrote: > On Fri, 15 Apr 2016, Xiong Zhou wrote: > >> Hi, all >> >> Since tag next-20160407 in linux-next repo, executing binary >> from/in DAX mount hangs. >> >> It does not hang if mou

Re: binary execution from DAX mount hang since next-20160407

On Fri, Apr 15, 2016 at 4:38 PM, Hugh Dickins wrote: > On Fri, 15 Apr 2016, Xiong Zhou wrote: > >> Hi, all >> >> Since tag next-20160407 in linux-next repo, executing binary >> from/in DAX mount hangs. >> >> It does not hang if mount without dax

Re: binary execution from DAX mount hang since next-20160407

# cat /proc/cmdline BOOT_IMAGE=/vmlinuz-4.6.0-rc3-next-20160414+ root=/dev/mapper/x--01-root ro crashkernel=auto rd.lvm.lv=x-01/root rd.lvm.lv=xx/swap console=ttyS1,115200n81 memmap=10G!5G memmap=15G!15G selinux=0 LANG=en_US.UTF-8 # mkfs.ext4 -V mke2fs 1.43-WIP (15-Mar-2016) Using

Re: binary execution from DAX mount hang since next-20160407

# cat /proc/cmdline BOOT_IMAGE=/vmlinuz-4.6.0-rc3-next-20160414+ root=/dev/mapper/x--01-root ro crashkernel=auto rd.lvm.lv=x-01/root rd.lvm.lv=xx/swap console=ttyS1,115200n81 memmap=10G!5G memmap=15G!15G selinux=0 LANG=en_US.UTF-8 # mkfs.ext4 -V mke2fs 1.43-WIP (15-Mar-2016) Using

Re: [-next] BUG_ON in scsi_target_destroy()

Hi, On Wed, Apr 13, 2016 at 11:14 PM, James Bottomley wrote: > On Wed, 2016-04-13 at 10:41 +0200, Johannes Thumshirn wrote: >> Hi Sergey, Xiong, >> >> Can you try below patch? >> >> On Montag, 11. April 2016 18:01:47 CEST Sergey Senozhatsky wrote: >> > Hello, >> > >> >

Re: [-next] BUG_ON in scsi_target_destroy()

Hi, On Wed, Apr 13, 2016 at 11:14 PM, James Bottomley wrote: > On Wed, 2016-04-13 at 10:41 +0200, Johannes Thumshirn wrote: >> Hi Sergey, Xiong, >> >> Can you try below patch? >> >> On Montag, 11. April 2016 18:01:47 CEST Sergey Senozhatsky wrote: >> > Hello, >> > >> > commit

Re: [-next] BUG_ON in scsi_target_destroy()

Hi, On Wed, Apr 13, 2016 at 4:41 PM, Johannes Thumshirn wrote: > Hi Sergey, Xiong, > > Can you try below patch? This survives modprobe -r scsi_debug. > > On Montag, 11. April 2016 18:01:47 CEST Sergey Senozhatsky wrote: >> Hello, >> >> commit

Re: [-next] BUG_ON in scsi_target_destroy()

Hi, On Wed, Apr 13, 2016 at 4:41 PM, Johannes Thumshirn wrote: > Hi Sergey, Xiong, > > Can you try below patch? This survives modprobe -r scsi_debug. > > On Montag, 11. April 2016 18:01:47 CEST Sergey Senozhatsky wrote: >> Hello, >> >> commit 7b106f2de6938c31ce5e9c86bc70ad3904666b96 >>

Re: [PATCH v4 1/2] scsi: Add intermediate STARGET_REMOVE state to scsi_target_state

On Wed, Apr 13, 2016 at 4:19 PM, Johannes Thumshirn <jthumsh...@suse.de> wrote: > Hi Xiong > Sorry for the late reply > > On Dienstag, 12. April 2016 21:01:53 CEST Xiong Zhou wrote: >> How about this? >> >> drivers/scsi/scsi_scan: mark STARGET_REMOVE state befor

Re: [PATCH v4 1/2] scsi: Add intermediate STARGET_REMOVE state to scsi_target_state

On Wed, Apr 13, 2016 at 4:19 PM, Johannes Thumshirn wrote: > Hi Xiong > Sorry for the late reply > > On Dienstag, 12. April 2016 21:01:53 CEST Xiong Zhou wrote: >> How about this? >> >> drivers/scsi/scsi_scan: mark STARGET_REMOVE state before destroy &

Re: [PATCH v4 1/2] scsi: Add intermediate STARGET_REMOVE state to scsi_target_state

How about this? drivers/scsi/scsi_scan: mark STARGET_REMOVE state before destroy Signed-off-by: Xiong Zhou <jencce.ker...@gmail.com> --- drivers/scsi/scsi_scan.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c index 27df7e7..2

Re: [PATCH v4 1/2] scsi: Add intermediate STARGET_REMOVE state to scsi_target_state

How about this? drivers/scsi/scsi_scan: mark STARGET_REMOVE state before destroy Signed-off-by: Xiong Zhou --- drivers/scsi/scsi_scan.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c index 27df7e7..21092e5 100644 --- a/drivers/scsi

Re: [PATCH v4 1/2] scsi: Add intermediate STARGET_REMOVE state to scsi_target_state

Hi, On Tue, Apr 5, 2016 at 5:50 PM, Johannes Thumshirn wrote: > Add intermediate STARGET_REMOVE state to scsi_target_state to avoid > running into the BUG_ON() in scsi_target_reap(). The STARGET_REMOVE > state is only valid in the path from scsi_remove_target() to >

Re: [PATCH v4 1/2] scsi: Add intermediate STARGET_REMOVE state to scsi_target_state

Hi, On Tue, Apr 5, 2016 at 5:50 PM, Johannes Thumshirn wrote: > Add intermediate STARGET_REMOVE state to scsi_target_state to avoid > running into the BUG_ON() in scsi_target_reap(). The STARGET_REMOVE > state is only valid in the path from scsi_remove_target() to > scsi_target_destroy()

Re: 4.5.0+ panic when setup loop device

Hi, On Thu, Mar 17, 2016 at 7:39 PM, Thomas Gleixner wrote: > B1;2802;0cOn Thu, 17 Mar 2016, Peter Zijlstra wrote: > >> On Thu, Mar 17, 2016 at 11:21:24AM +0100, Thomas Gleixner wrote: >> > On Thu, 17 Mar 2016, Peter Zijlstra wrote: >> > >> > > Could you please try? I'm not

Re: 4.5.0+ panic when setup loop device

Hi, On Thu, Mar 17, 2016 at 7:39 PM, Thomas Gleixner wrote: > B1;2802;0cOn Thu, 17 Mar 2016, Peter Zijlstra wrote: > >> On Thu, Mar 17, 2016 at 11:21:24AM +0100, Thomas Gleixner wrote: >> > On Thu, 17 Mar 2016, Peter Zijlstra wrote: >> > >> > > Could you please try? I'm not sure how this would

[PATCH trivial] scripts/prune-kernel: remove kdump images

Signed-off-by: Xiong Zhou <jencce.ker...@gmail.com> --- scripts/prune-kernel | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/prune-kernel b/scripts/prune-kernel index ab5034e..9c67be2 100755 --- a/scripts/prune-kernel +++ b/scripts/prune-kernel @@ -14,7 +14,7

[PATCH trivial] scripts/prune-kernel: remove kdump images

Signed-off-by: Xiong Zhou --- scripts/prune-kernel | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/prune-kernel b/scripts/prune-kernel index ab5034e..9c67be2 100755 --- a/scripts/prune-kernel +++ b/scripts/prune-kernel @@ -14,7 +14,7 @@ do echo

ext2/3 using ext4 module mkdir IO error on pmem DAX mount

Hi, mkdir failed IO error on pmem DAX ext2/3 fs mount using ext4 module. This happends only on -next tree, not on Linus' tree, at least from 4.5.0-rc5-next-20160224. .config attached. sh-4.2# uname -r 4.5.0-rc6-next-20160301 sh-4.2# sh -x extmod.sh + testmkdir ext2 /dev/pmem0 /daxmnt ext4 +

ext2/3 using ext4 module mkdir IO error on pmem DAX mount

Hi, mkdir failed IO error on pmem DAX ext2/3 fs mount using ext4 module. This happends only on -next tree, not on Linus' tree, at least from 4.5.0-rc5-next-20160224. .config attached. sh-4.2# uname -r 4.5.0-rc6-next-20160301 sh-4.2# sh -x extmod.sh + testmkdir ext2 /dev/pmem0 /daxmnt ext4 +

[PATCH] staging: android: logger: fix kuid/uid in logger_entry

From: Xiong Zhou struct logger_entry can be returned to userspace via ioctl, so it is wrong to have a kuid_t member, fixing it to uid_t. This was introduced by commit bd471258f2, to pass uidguid type checks : UIDGID_STRICT_TYPE_CHECKS, which has been removed from kernel in commit 261000a56b6

[PATCH] staging: android: logger: fix kuid/uid in logger_entry

From: Xiong Zhou jencce.ker...@gmail.com struct logger_entry can be returned to userspace via ioctl, so it is wrong to have a kuid_t member, fixing it to uid_t. This was introduced by commit bd471258f2, to pass uidguid type checks : UIDGID_STRICT_TYPE_CHECKS, which has been removed from kernel

Re: [vfs] WARNING: CPU: 3 PID: 2339 at mm/truncate.c:758 pagecache_isize_extended+0xdd/0x120()

still in rc2 [ cut here ] WARNING: CPU: 0 PID: 18152 at mm/truncate.c:758 pagecache_isize_extended+0xfd/0x110() Modules linked in: btrfs xor zlib_deflate raid6_pq ntfs fuse x86_pkg_temp_thermal wmi radeon e1000e ttm CPU: 0 PID: 18152 Comm: Cache I/O Tainted: GW

Re: [vfs] WARNING: CPU: 3 PID: 2339 at mm/truncate.c:758 pagecache_isize_extended+0xdd/0x120()

still in rc2 [ cut here ] WARNING: CPU: 0 PID: 18152 at mm/truncate.c:758 pagecache_isize_extended+0xfd/0x110() Modules linked in: btrfs xor zlib_deflate raid6_pq ntfs fuse x86_pkg_temp_thermal wmi radeon e1000e ttm CPU: 0 PID: 18152 Comm: Cache I/O Tainted: GW

  1   2   >