Skip to content
This repository has been archived by the owner on Feb 26, 2020. It is now read-only.

XDR Regression Tests #1

Closed
behlendorf opened this issue May 14, 2010 · 1 comment
Closed

XDR Regression Tests #1

behlendorf opened this issue May 14, 2010 · 1 comment
Labels
Feature

Comments

@behlendorf
Copy link
Contributor

The XDR implementation currently does not have any regression tests as part of the SPLAT test framework. While I'm not aware of any issues with the XDR code we do need to add some regression tests to make sure nothing gets accidentally broken.
@behlendorf
Copy link
Contributor Author

Closing issue. The XDR encoding test case would be nice but it doubtful we'll ever need to change this code and it's working beautifully.

@prakashsurya prakashsurya mentioned this issue Nov 9, 2011
Closed
This was referenced Nov 10, 2011
Closed
Closed
@scotttcollins scotttcollins mentioned this issue Dec 5, 2011
Closed
@BerndHelber BerndHelber mentioned this issue Dec 7, 2011
Closed
@ghost ghost mentioned this issue Jan 25, 2012
Closed
@bruce-arden bruce-arden mentioned this issue Apr 3, 2012
Closed
@cwolfrum cwolfrum mentioned this issue Apr 17, 2012
Closed
@rayvt rayvt mentioned this issue Apr 27, 2012
Closed
@michaelletzgus michaelletzgus mentioned this issue May 8, 2012
Closed
@dpchrist dpchrist mentioned this issue May 28, 2012
Closed
@b1r63r b1r63r mentioned this issue Jun 15, 2012
Closed
@JasperWallace JasperWallace mentioned this issue Jul 7, 2012
Closed
@TrentonAdams TrentonAdams mentioned this issue Jul 18, 2012
Closed
@schreiberstein schreiberstein mentioned this issue Aug 16, 2012
Closed
@madpenguin madpenguin mentioned this issue Oct 5, 2012
Closed
@pyavdr pyavdr mentioned this issue Nov 11, 2012
Closed
@alexfv alexfv mentioned this issue Nov 23, 2012
Closed
@Rudd-O Rudd-O mentioned this issue Feb 6, 2013
Closed
FransUrbo pushed a commit to FransUrbo/spl that referenced this issue Apr 11, 2013
@zfsrogue
Merge pull request openzfs#1 from lundman/master
70b26c2 
SPL add crypto functions
@inevity inevity mentioned this issue Apr 30, 2013
Closed
@davromaniak davromaniak mentioned this issue Apr 30, 2013
Closed
@inkdot7 inkdot7 mentioned this issue Jun 13, 2013
Closed
This was referenced Jul 15, 2013
Closed
Closed
@cousins cousins mentioned this issue Jul 19, 2013
Closed
@PavelLeon PavelLeon mentioned this issue Jul 28, 2013
Closed
@tuomari tuomari mentioned this issue Sep 16, 2013
Closed
@ZsoltFerenczy ZsoltFerenczy mentioned this issue Sep 30, 2013
Closed
@ltaulell ltaulell mentioned this issue Apr 16, 2014
Closed
@deajan deajan mentioned this issue Jun 9, 2014
Closed
@akorn akorn mentioned this issue Sep 18, 2014
Closed
@greg-hydrogen greg-hydrogen mentioned this issue Nov 15, 2014
Closed
@ColinIanKing ColinIanKing mentioned this issue Jan 8, 2016
Closed
@clefru clefru mentioned this issue Dec 17, 2016
Closed
@verygreen verygreen mentioned this issue Jul 25, 2017
Closed
verygreen added a commit to verygreen/spl that referenced this issue Jul 25, 2017
@verygreen
Remove misguided HAVE_MUTEX_OWNER check
e8897f8 
It is just plain unsafe to peek inside in-kernel
mutex structure and make assumptions about what kernel
does with those internal fields like owner.

Kernel is all too happy to stop doing the expected things
like tracing lock owner once you load a tainted module
like spl/zfs that is not GPL.
As such you will get instant assertion failures like this:

[21597.305519] VERIFY3(((*(volatile typeof((&((&zo->zo_lock)->m_mutex))->owner) *)&((&((&zo->zo_lock)->m_mutex))->owner))) == ((void *)0)) failed (ffff88030be28500 == (null))
[21597.307259] PANIC at zfs_onexit.c:104:zfs_onexit_destroy()
[21597.307792] Showing stack for process 3626
[21597.308343] CPU: 0 PID: 3626 Comm: mkfs.lustre Tainted: P OE ------------ 3.10.0-debug openzfs#1
[21597.309366] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
[21597.309886] ffffffffa046228f 0000000012e37b1d ffff880308c3bcc0 ffffffff816fd404
[21597.310969] ffff880308c3bcd0 ffffffffa01d8754 ffff880308c3be58 ffffffffa01d881f
[21597.312000] ffff880308c3bcf0 ffffffff00000030 ffff880308c3be68 ffff880308c3be08
[21597.312984] Call Trace:
[21597.313477] [] dump_stack+0x19/0x1b
[21597.313993] [] spl_dumpstack+0x44/0x50 [spl]
[21597.314529] [] spl_panic+0xbf/0xf0 [spl]
[21597.315096] [] ? zfs_onexit_destroy+0x126/0x280 [zfs]
[21597.315667] [] zfs_onexit_destroy+0x17c/0x280 [zfs]
[21597.316238] [] zfsdev_release+0x48/0xd0 [zfs]

This fixes openzfs#632
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
@verygreen verygreen mentioned this issue Jul 25, 2017
Merged
behlendorf pushed a commit that referenced this issue Aug 2, 2017
@verygreen @behlendorf
Remove misguided HAVE_MUTEX_OWNER check
d89616f 
It is just plain unsafe to peek inside in-kernel
mutex structure and make assumptions about what kernel
does with those internal fields like owner.

Kernel is all too happy to stop doing the expected things
like tracing lock owner once you load a tainted module
like spl/zfs that is not GPL.

As such you will get instant assertion failures like this:

  VERIFY3(((*(volatile typeof((&((&zo->zo_lock)->m_mutex))->owner) *)&
      ((&((&zo->zo_lock)->m_mutex))->owner))) == 
     ((void *)0)) failed (ffff88030be28500 == (null))
  PANIC at zfs_onexit.c:104:zfs_onexit_destroy()
  Showing stack for process 3626
  CPU: 0 PID: 3626 Comm: mkfs.lustre Tainted: P OE ------------ 3.10.0-debug #1
  Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
  Call Trace:
  dump_stack+0x19/0x1b
  spl_dumpstack+0x44/0x50 [spl]
  spl_panic+0xbf/0xf0 [spl]
  zfs_onexit_destroy+0x17c/0x280 [zfs]
  zfsdev_release+0x48/0xd0 [zfs]

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Chunwei Chen <david.chen@osnexus.com>
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Closes #632 
Closes #633
verygreen added a commit to verygreen/spl that referenced this issue Aug 2, 2017
@verygreen
Remove misguided HAVE_MUTEX_OWNER check
62bef4c 
It is just plain unsafe to peek inside in-kernel
mutex structure and make assumptions about what kernel
does with those internal fields like owner.

Kernel is all too happy to stop doing the expected things
like tracing lock owner once you load a tainted module
like spl/zfs that is not GPL.

As such you will get instant assertion failures like this:

  VERIFY3(((*(volatile typeof((&((&zo->zo_lock)->m_mutex))->owner) *)&
      ((&((&zo->zo_lock)->m_mutex))->owner))) ==
     ((void *)0)) failed (ffff88030be28500 == (null))
  PANIC at zfs_onexit.c:104:zfs_onexit_destroy()
  Showing stack for process 3626
  CPU: 0 PID: 3626 Comm: mkfs.lustre Tainted: P OE ------------ 3.10.0-debug openzfs#1
  Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
  Call Trace:
  dump_stack+0x19/0x1b
  spl_dumpstack+0x44/0x50 [spl]
  spl_panic+0xbf/0xf0 [spl]
  zfs_onexit_destroy+0x17c/0x280 [zfs]
  zfsdev_release+0x48/0xd0 [zfs]

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Chunwei Chen <david.chen@osnexus.com>
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Closes openzfs#632
Closes openzfs#633
verygreen added a commit to verygreen/spl that referenced this issue Aug 2, 2017
@verygreen
Remove misguided HAVE_MUTEX_OWNER check, take 2
26e6a8e 
It is just plain unsafe to peek inside in-kernel
mutex structure and make assumptions about what kernel
does with those internal fields like owner.

Kernel is all too happy to stop doing the expected things
like tracing lock owner once you load a tainted module
like spl/zfs that is not GPL.

As such you will get instant assertion failures like this:

  VERIFY3(((*(volatile typeof((&((&zo->zo_lock)->m_mutex))->owner) *)&
      ((&((&zo->zo_lock)->m_mutex))->owner))) ==
     ((void *)0)) failed (ffff88030be28500 == (null))
  PANIC at zfs_onexit.c:104:zfs_onexit_destroy()
  Showing stack for process 3626
  CPU: 0 PID: 3626 Comm: mkfs.lustre Tainted: P OE ------------ 3.10.0-debug openzfs#1
  Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
  Call Trace:
  dump_stack+0x19/0x1b
  spl_dumpstack+0x44/0x50 [spl]
  spl_panic+0xbf/0xf0 [spl]
  zfs_onexit_destroy+0x17c/0x280 [zfs]
  zfsdev_release+0x48/0xd0 [zfs]

Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Closes openzfs#632
@verygreen verygreen mentioned this issue Aug 2, 2017
Closed
behlendorf pushed a commit that referenced this issue Aug 3, 2017
@verygreen @behlendorf
Remove misguided HAVE_MUTEX_OWNER check, take 2
98cdcb8 
It is just plain unsafe to peek inside in-kernel
mutex structure and make assumptions about what kernel
does with those internal fields like owner.

Kernel is all too happy to stop doing the expected things
like tracing lock owner once you load a tainted module
like spl/zfs that is not GPL.

As such you will get instant assertion failures like this:

  VERIFY3(((*(volatile typeof((&((&zo->zo_lock)->m_mutex))->owner) *)&
      ((&((&zo->zo_lock)->m_mutex))->owner))) ==
     ((void *)0)) failed (ffff88030be28500 == (null))
  PANIC at zfs_onexit.c:104:zfs_onexit_destroy()
  Showing stack for process 3626
  CPU: 0 PID: 3626 Comm: mkfs.lustre Tainted: P OE ------------ 3.10.0-debug #1
  Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
  Call Trace:
  dump_stack+0x19/0x1b
  spl_dumpstack+0x44/0x50 [spl]
  spl_panic+0xbf/0xf0 [spl]
  zfs_onexit_destroy+0x17c/0x280 [zfs]
  zfsdev_release+0x48/0xd0 [zfs]

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Chunwei Chen <david.chen@osnexus.com>
Reviewed-by: Gvozden Neskovic <neskovic@gmail.com>
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Closes #639
Closes #632
tonyhutter pushed a commit that referenced this issue Aug 3, 2017
@verygreen @tonyhutter
Remove misguided HAVE_MUTEX_OWNER check, take 2
eb23d32 
It is just plain unsafe to peek inside in-kernel
mutex structure and make assumptions about what kernel
does with those internal fields like owner.

Kernel is all too happy to stop doing the expected things
like tracing lock owner once you load a tainted module
like spl/zfs that is not GPL.

As such you will get instant assertion failures like this:

  VERIFY3(((*(volatile typeof((&((&zo->zo_lock)->m_mutex))->owner) *)&
      ((&((&zo->zo_lock)->m_mutex))->owner))) ==
     ((void *)0)) failed (ffff88030be28500 == (null))
  PANIC at zfs_onexit.c:104:zfs_onexit_destroy()
  Showing stack for process 3626
  CPU: 0 PID: 3626 Comm: mkfs.lustre Tainted: P OE ------------ 3.10.0-debug #1
  Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
  Call Trace:
  dump_stack+0x19/0x1b
  spl_dumpstack+0x44/0x50 [spl]
  spl_panic+0xbf/0xf0 [spl]
  zfs_onexit_destroy+0x17c/0x280 [zfs]
  zfsdev_release+0x48/0xd0 [zfs]

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Chunwei Chen <david.chen@osnexus.com>
Reviewed-by: Gvozden Neskovic <neskovic@gmail.com>
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Closes #639
Closes #632
ofaaland pushed a commit to ofaaland/spl that referenced this issue Aug 3, 2017
@verygreen @ofaaland
Remove misguided HAVE_MUTEX_OWNER check, take 2
0cd2a57 
It is just plain unsafe to peek inside in-kernel
mutex structure and make assumptions about what kernel
does with those internal fields like owner.

Kernel is all too happy to stop doing the expected things
like tracing lock owner once you load a tainted module
like spl/zfs that is not GPL.

As such you will get instant assertion failures like this:

  VERIFY3(((*(volatile typeof((&((&zo->zo_lock)->m_mutex))->owner) *)&
      ((&((&zo->zo_lock)->m_mutex))->owner))) ==
     ((void *)0)) failed (ffff88030be28500 == (null))
  PANIC at zfs_onexit.c:104:zfs_onexit_destroy()
  Showing stack for process 3626
  CPU: 0 PID: 3626 Comm: mkfs.lustre Tainted: P OE ------------ 3.10.0-debug openzfs#1
  Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
  Call Trace:
  dump_stack+0x19/0x1b
  spl_dumpstack+0x44/0x50 [spl]
  spl_panic+0xbf/0xf0 [spl]
  zfs_onexit_destroy+0x17c/0x280 [zfs]
  zfsdev_release+0x48/0xd0 [zfs]

Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Closes openzfs#632
Fabian-Gruenbichler pushed a commit to Fabian-Gruenbichler/spl that referenced this issue Sep 6, 2017
@verygreen @Fabian-Gruenbichler
Remove misguided HAVE_MUTEX_OWNER check, take 2
be85c9b 
It is just plain unsafe to peek inside in-kernel
mutex structure and make assumptions about what kernel
does with those internal fields like owner.

Kernel is all too happy to stop doing the expected things
like tracing lock owner once you load a tainted module
like spl/zfs that is not GPL.

As such you will get instant assertion failures like this:

  VERIFY3(((*(volatile typeof((&((&zo->zo_lock)->m_mutex))->owner) *)&
      ((&((&zo->zo_lock)->m_mutex))->owner))) ==
     ((void *)0)) failed (ffff88030be28500 == (null))
  PANIC at zfs_onexit.c:104:zfs_onexit_destroy()
  Showing stack for process 3626
  CPU: 0 PID: 3626 Comm: mkfs.lustre Tainted: P OE ------------ 3.10.0-debug openzfs#1
  Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
  Call Trace:
  dump_stack+0x19/0x1b
  spl_dumpstack+0x44/0x50 [spl]
  spl_panic+0xbf/0xf0 [spl]
  zfs_onexit_destroy+0x17c/0x280 [zfs]
  zfsdev_release+0x48/0xd0 [zfs]

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Chunwei Chen <david.chen@osnexus.com>
Reviewed-by: Gvozden Neskovic <neskovic@gmail.com>
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Closes openzfs#639
Closes openzfs#632
@digitalsanity digitalsanity mentioned this issue Oct 3, 2017
Closed
@darrenfreeman darrenfreeman mentioned this issue Mar 26, 2018
Closed
delphix-devops-bot pushed a commit to delphix-devops-bot/spl that referenced this issue May 8, 2018
@ahrens
Merge pull request openzfs#1 from zfsonlinux/master
86e1f04 
merge ZoL
tonyhutter added a commit to tonyhutter/spl that referenced this issue Jan 30, 2019
@tonyhutter
deadlock between mm_sem and tx assign in zfs_write() and page fault
647cca7 
(This is the ported SPL portion of this patch)

The bug time sequence:
1. thread openzfs#1, `zfs_write` assign a txg "n".
2. In a same process, thread openzfs#2, mmap page fault (which means the
`mm_sem` is hold) occurred, `zfs_dirty_inode` open a txg failed,
and wait previous txg "n" completed.
3. thread openzfs#1 call `uiomove` to write, however page fault is occurred
in `uiomove`, which means it need `mm_sem`, but `mm_sem` is hold by
thread openzfs#2, so it stuck and can't complete,  then txg "n" will
not complete.

So thread openzfs#1 and thread openzfs#2 are deadlocked.

Reviewed-by: Chunwei Chen <tuxoko@gmail.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Grady Wong <grady.w@xtaotech.com>
Closes #7939
tonyhutter added a commit that referenced this issue Mar 4, 2019
@tonyhutter
deadlock between mm_sem and tx assign in zfs_write() and page fault
cb4464f 
(This is the ported SPL portion of this patch)

The bug time sequence:
1. thread #1, `zfs_write` assign a txg "n".
2. In a same process, thread #2, mmap page fault (which means the
`mm_sem` is hold) occurred, `zfs_dirty_inode` open a txg failed,
and wait previous txg "n" completed.
3. thread #1 call `uiomove` to write, however page fault is occurred
in `uiomove`, which means it need `mm_sem`, but `mm_sem` is hold by
thread #2, so it stuck and can't complete,  then txg "n" will
not complete.

So thread #1 and thread #2 are deadlocked.

Reviewed-by: Chunwei Chen <tuxoko@gmail.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Grady Wong <grady.w@xtaotech.com>
Closes #7939
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
Feature
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@behlendorf