[Bug 220096] [acpi] sys/dev/acpica/acpi_thermal.c: a sleep-under-mutex bug in acpi_tz_thread

2017-06-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220096

Bug ID: 220096
   Summary: [acpi] sys/dev/acpica/acpi_thermal.c: a
sleep-under-mutex bug in acpi_tz_thread
   Product: Base System
   Version: 11.0-RELEASE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: baijiaju1...@163.com

The driver may sleep under a mutex, and the code path in file
"sys/dev/acpica/acpi_thermal.c" in FreeBSD 11.0 release is:
acpi_tz_thread [line 992: acquire the mutex]
acpi_tz_thread [line 993]
acpi_tz_thread [line 1003]
acpi_tz_thread [line 1004] (msleep is excuted)
acpi_tz_thread [line 1008]
acpi_tz_thread [line 970]
acpi_tz_thread [line 971]
acpi_tz_thread [line 975]
  malloc(M_WAITOK) [line 976]

The possible fix of this bug is to replace "M_WAITOK" in malloc with
"M_NOWAIT".

This bug is found by a static analysis tool written by myself, and it is
checked by my review of the FreeBSD code.

Thanks,
Jia-Ju Bai

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 220095] [scsi] sys/dev/dpt/dpt_scsi.c: a sleep-under-mutex bug in dpt_init

2017-06-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220095

Bug ID: 220095
   Summary: [scsi] sys/dev/dpt/dpt_scsi.c: a sleep-under-mutex bug
in dpt_init
   Product: Base System
   Version: 11.0-RELEASE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: baijiaju1...@163.com

The driver may sleep under a mutex, and the function call path in file
"sys/dev/dpt/dpt_scsi.c" in FreeBSD 11.0 is:
dpt_init [line 1246: acquire the mutex]
  dptallocsgmap [line 1282]
bus_dmamap_load(BUS_DMA_WAITOK) [line 323] --> may sleep

The possible fix of this bug is to set the last parameter in bus_dmamap_load to
"BUS_DMA_NOWAIT".

This bug is found by a static analysis tool written by myself, and it is
checked by my review of the FreeBSD code.

Thanks,
Jia-Ju Bai

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 220094] [scsi] sys/cam/scsi/scsi_sa.c: a sleep-under-mutex bug in saioctl

2017-06-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220094

Bug ID: 220094
   Summary: [scsi] sys/cam/scsi/scsi_sa.c: a sleep-under-mutex bug
in saioctl
   Product: Base System
   Version: 11.0-RELEASE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: baijiaju1...@163.com

The driver may sleep under a mutex, and the function call path in file
"sys/cam/scsi/scsi_sa.c" in FreeBSD 11.0 is:
saioctl [line 1680: acquire the mutex]
  saextget [line 1683]
malloc(M_WAITOK) [line ] --> may sleep

The possible fix of this bug is to replace "M_WAITOK" in malloc with
"M_NOWAIT".

This bug is found by a static analysis tool written by myself, and it is
checked by my review of the FreeBSD code.

Thanks,
Jia-Ju Bai

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 155163] [patch] Add Recursive Functionality to setfacl(1)

2017-06-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=155163

Ed Maste  changed:

   What|Removed |Added

 CC||ema...@freebsd.org

--- Comment #9 from Ed Maste  ---
This is open for review in https://reviews.freebsd.org/D9096, and it is
currently blocked on issues raised in that review.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 220086] linux compat layer statfs implementation should present zfs as ext2

2017-06-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220086

--- Comment #3 from Ed Maste  ---
Can you try the patch in https://reviews.freebsd.org/D11252

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 220086] linux compat layer statfs implementation should present zfs as ext2

2017-06-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220086

--- Comment #2 from Conrad Meyer  ---
FWIW, a Linux user reports ZFS on Linux shows 2fc12fc1 for statfs f_type.

I don't think pretending to be ext2 makes much sense.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 220086] linux compat layer statfs implementation should present zfs as ext2

2017-06-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220086

Conrad Meyer  changed:

   What|Removed |Added

 CC||c...@freebsd.org

--- Comment #1 from Conrad Meyer  ---
What value does ZFS on Linux present?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 220086] linux compat layer statfs implementation should present zfs as ext2

2017-06-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220086

Bug ID: 220086
   Summary: linux compat layer statfs implementation should
present zfs as ext2
   Product: Base System
   Version: 11.0-STABLE
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: b...@facefault.org

The statfs implementation in sys/compat/linux/linux_stats.c (function
bsd_to_linux_ftype) does not currently handle zfs filesystems. Some proprietary
software (e.g. Splunk) expects a sane value for statfs.f_type and will refuse
to function when that's 0L.

SmartOS solved this issue (https://smartos.org/bugview/OS-3932) by presenting
zfs as ext2; the same solution should work for FreeBSD.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 220078] [patch] [panic] [ipfw] repeatable kernel panic due to unlocked INADDR_TO_IFP usage

2017-06-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220078

Mark Linimon  changed:

   What|Removed |Added

   Assignee|freebsd-bugs@FreeBSD.org|freebsd-i...@freebsd.org

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 220076] [patch] [panic] [netgraph] repeatable kernel panic due to a race in ng_iface(4)

2017-06-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220076

--- Comment #1 from Mark Linimon  ---
*** Bug 220077 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 220077] [patch] [panic] repeatable kernel panic due to a race in

2017-06-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220077

Mark Linimon  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|New |Closed

--- Comment #1 from Mark Linimon  ---


*** This bug has been marked as a duplicate of bug 220076 ***

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 220079] [kern] sys/kern/vfs_subr.c: double mutex locks in vgone

2017-06-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220079

Mateusz Guzik  changed:

   What|Removed |Added

   Assignee|freebsd-bugs@FreeBSD.org|m...@freebsd.org
 Status|New |Closed
 CC||m...@freebsd.org
 Resolution|--- |Not A Bug

--- Comment #1 from Mateusz Guzik  ---
The code is:

VOP_LOCK(rootvp, LK_EXCLUSIVE|LK_INTERLOCK);
vgone(rootvp);

The LK_INTERLOCK flags tells the locking routine that the interlock is held and
the contract is that it is dropped prior to return, hence vgone is called
without the lock held.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 220079] [kern] sys/kern/vfs_subr.c: double mutex locks in vgone

2017-06-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220079

Bug ID: 220079
   Summary: [kern] sys/kern/vfs_subr.c: double mutex locks in
vgone
   Product: Base System
   Version: 11.0-RELEASE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: baijiaju1...@163.com

The kernel may has double mutex locks, and the code path in file
"sys/kern/vfs_subr.c" in FreeBSD 11.0 release is:
vflush [line 3050: acquire the lock by VI_LOCK]
  vgone [line 3057]
VI_LOCK [line 3100] --> lock again

This bug is found by a static analysis tool written by myself, and it is
checked by my review of the FreeBSD code.

Jia-Ju Bai

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 220078] [patch] [panic] [ipfw] repeatable kernel panic due to unlocked INADDR_TO_IFP usage

2017-06-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220078

--- Comment #3 from Eugene Grosbein  ---
Created attachment 183570
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=183570=edit
lock access to INADDR_HASH in the ip_input()

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 220078] [patch] [panic] [ipfw] repeatable kernel panic due to unlocked INADDR_TO_IFP usage

2017-06-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220078

Eugene Grosbein  changed:

   What|Removed |Added

 Attachment #183569|lock access to  |lock access to INADDR_HASH
description|INADDR_TO_IFP in the stf(4) |in the stf(4)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 220078] [patch] [panic] [ipfw] repeatable kernel panic due to unlocked INADDR_TO_IFP usage

2017-06-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220078

--- Comment #2 from Eugene Grosbein  ---
Created attachment 183569
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=183569=edit
lock access to INADDR_TO_IFP in the stf(4)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 220078] [patch] [panic] [ipfw] repeatable kernel panic due to unlocked INADDR_TO_IFP usage

2017-06-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220078

--- Comment #1 from Eugene Grosbein  ---
Created attachment 183568
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=183568=edit
lock access to INADDR_TO_IFP in the in_mcast.c

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 220078] [patch] [panic] [ipfw] repeatable kernel panic due to unlocked INADDR_TO_IFP usage

2017-06-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220078

Bug ID: 220078
   Summary: [patch] [panic] [ipfw] repeatable kernel panic due to
unlocked INADDR_TO_IFP usage
   Product: Base System
   Version: 11.0-STABLE
  Hardware: Any
OS: Any
Status: New
  Keywords: patch
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: eu...@freebsd.org
  Keywords: patch

Created attachment 183567
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=183567=edit
lock access to INADDR_TO_IFP in the ipfw

There are several places in kernel sources where code performs unlocked access
to the hash of host's IP addresses. If adresses change often enough, a panic
may occur.

For example, part of kgdb script of latest panic of my mpd server:

1642case O_IP_DST_ME:
1643if (is_ipv4) {
1644struct ifnet *tif;
1645
1646INADDR_TO_IFP(dst_ip, tif);
(kgdb) p ia
$3 = (struct in_ifaddr *) 0xdeadc0dedeadc0de

Attached patches add needed locking to several such places including ipfw.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 220077] [patch] [panic] repeatable kernel panic due to a race in

2017-06-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220077

Bug ID: 220077
   Summary: [patch] [panic] repeatable kernel panic due to a race
in
   Product: Base System
   Version: 11.0-STABLE
  Hardware: Any
OS: Any
Status: New
  Keywords: patch
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: eu...@freebsd.org
  Keywords: patch

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 220076] [patch] [panic] [netgraph] repeatable kernel panic due to a race in ng_iface(4)

2017-06-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220076

Eugene Grosbein  changed:

   What|Removed |Added

  Flags||mfc-stable10?,
   ||mfc-stable11?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 220073] iflib panic r320049

2017-06-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220073

Dmitry Chagin  changed:

   What|Removed |Added

   Assignee|freebsd-bugs@FreeBSD.org|freebsd-...@freebsd.org

--- Comment #1 from Dmitry Chagin  ---
commented bridge solves problem for me

# vmm support
#cloned_interfaces="bridge0 tap0 tap1 tap2"
#ifconfig_bridge0="addm em0 addm tap0 addm tap1 addm tap2"

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 220076] [patch] [panic] [netgraph] repeatable kernel panic due to a race in ng_iface(4)

2017-06-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220076

Bug ID: 220076
   Summary: [patch] [panic] [netgraph] repeatable kernel panic due
to a race in ng_iface(4)
   Product: Base System
   Version: 11.0-STABLE
  Hardware: Any
OS: Any
Status: New
  Keywords: patch
  Severity: Affects Some People
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: eu...@freebsd.org
  Keywords: patch

Created attachment 183566
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=183566=edit
protect ng_iface private data

I observe repeatable panics at netgraph level while doing stress test
for net/mpd5 daemon under stable/11 r317184. It connects, uses and disconnects
lots of ngXX interfaces and corresponding netgraph nodes and hooks.

Crashdump points to ng_iface node which private data - set of hooks - may be
modified in respond to userland request while another kernel thread sends data
over hook being disconnected. Here is a scenario:

1. mpd runs its BundNcpsLeave() procedure for an interface calling
NgSendMsg(csock, path, NGM_GENERIC_COOKIE, NGM_RMHOOK, , sizeof(rm)) that
leads to libnetgraph's NgDeliverMsg() and sendto() system call for AF_NETGRAPH.

The kernel reponds with ng_findhook->ng_destroy_hook->NG_HOOK_UNREF
(_NG_HOOK_UNREF/ng_unref_hook)->NG_FREE_HOOK: free((hook), M_NETGRAPH_HOOK).

2. In parallel, userland process like ftpd sends some data over IPv4 socket to
corresponding interface being up and running. It may utilize hook being freed
same time by another kernel thread that leads to:

Fatal trap 9: general protection fault while in kernel mode
cpuid = 0; apic id = 00
instruction pointer = 0x20:0x8097f249
stack pointer   = 0x28:0xfe0239542ec0
frame pointer   = 0x28:0xfe0239542f00
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 28999 (ftpd)
trap number = 9
panic: general protection fault
cpuid = 0
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2c/frame 0xfe0239542840
kdb_backtrace() at kdb_backtrace+0x53/frame 0xfe0239542910
vpanic() at vpanic+0x249/frame 0xfe02395429e0
kproc_shutdown() at kproc_shutdown/frame 0xfe0239542a40
trap_fatal() at trap_fatal+0x60a/frame 0xfe0239542b70
trap() at trap+0x97c/frame 0xfe0239542dd0
trap_check() at trap_check+0x15/frame 0xfe0239542df0
calltrap() at calltrap+0x8/frame 0xfe0239542df0
--- trap 0x9, rip = 0x8097f249, rsp = 0xfe0239542ec0, rbp =
0xfe0239542f00 ---
ng_address_hook() at ng_address_hook+0x59/frame 0xfe0239542f00
ng_iface_send() at ng_iface_send+0x108/frame 0xfe0239542f90
ng_iface_output() at ng_iface_output+0x447/frame 0xfe0239543060
ip_output() at ip_output+0x1864/frame 0xfe0239543300
tcp_output() at tcp_output+0x2602/frame 0xfe02395436a0
tcp_disconnect() at tcp_disconnect+0x18e/frame 0xfe02395436e0
tcp_usr_disconnect() at tcp_usr_disconnect+0xe6/frame 0xfe0239543710
sodisconnect() at sodisconnect+0x62/frame 0xfe0239543740
soclose() at soclose+0x95/frame 0xfe02395437b0
soo_close() at soo_close+0x4d/frame 0xfe02395437e0
fo_close() at fo_close+0x31/frame 0xfe0239543810
_fdrop() at _fdrop+0x46/frame 0xfe0239543840
closef() at closef+0x2d7/frame 0xfe02395438f0
closefp() at closefp+0xde/frame 0xfe0239543940
kern_close() at kern_close+0xe7/frame 0xfe0239543990
sys_close() at sys_close+0x1f/frame 0xfe02395439b0
syscallenter() at syscallenter+0x4ff/frame 0xfe0239543a80
amd64_syscall() at amd64_syscall+0x2a/frame 0xfe0239543bb0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0239543bb0
--- syscall (6, FreeBSD ELF64, sys_close), rip = 0x801a4033a, rsp =
0x7fffd0a8, rbp = 0x7fffd0d0 ---
Uptime: 2h11m5s
Dumping 544 out of 8156 MB:..3%..12%..21%..33%..42%..53%..62%..71%..83%..92%

Reading symbols from /boot/modules/geom_mirror.ko...done.
Loaded symbols for /boot/modules/geom_mirror.ko
Reading symbols from /boot/modules/accf_http.ko...done.
Loaded symbols for /boot/modules/accf_http.ko
Reading symbols from /boot/modules/nvidia.ko...done.
Loaded symbols for /boot/modules/nvidia.ko
Reading symbols from /boot/modules/vboxdrv.ko...done.
Loaded symbols for /boot/modules/vboxdrv.ko
Reading symbols from /boot/modules/mmc.ko...done.
Loaded symbols for /boot/modules/mmc.ko
Reading symbols from /boot/modules/mmcsd.ko...done.
Loaded symbols for /boot/modules/mmcsd.ko
Reading symbols from /boot/modules/sdhci.ko...done.
Loaded symbols for /boot/modules/sdhci.ko
Reading symbols from /boot/modules/h_ertt.ko...done.
Loaded symbols for /boot/modules/h_ertt.ko
Reading symbols from /boot/modules/cc_chd.ko...done.
Loaded symbols for

[Bug 219846] [panic] [kevent] mutex nm_kn_lock not owned, netmap with INVARIANTS+WITNESS

2017-06-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219846

--- Comment #2 from Harald Schmalzbauer  ---
Like kib@ suggested in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206053, I already tried to
replacing 1 with 0 in the sys/dev/netmap/netmap_freebsd.c:netmap_kqfilter() at
the call to knlist_add(), which does indeed prevent the initial panic (when the
guest boots), but ends up in another panic short afterwards:

(quoting my github report)

panic: mutex nm_kn_lock owned at
/usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_event.c:2176
cpuid = 6
KDB: stack backtrace:
#0 0x805cb1a7 at kdb_backtrace+0x67
#1 0x8058b0e6 at vpanic+0x186
#2 0x8058b163 at panic+0x43
#3 0x8056c216 at __mtx_assert+0xc6
now:
#4 0x80545219 at knote+0x39
#5 0x8041ebc7 at nm_os_selwakeup+0x87
#6 0x8041c94d at netmap_notify+0x1d
#7 0x8041c701 at netmap_poll+0x821
#8 0x8041f63c at netmap_knrw+0x6c
#9 0x805443d7 at kqueue_kevent+0x397

#10 0x80543fd6 at kern_kevent_fp+0x96
#11 0x80543eef at kern_kevent+0x9f
#12 0x80543cf8 at sys_kevent+0x138
#13 0x80881b5a at amd64_syscall+0x57a
#14 0x8086563b at Xfast_syscall+0xfb

#0  doadump (textdump=) at pcpu.h:222
#1  0x8058ab60 in kern_reboot (howto=260) at
/usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_shutdown.c:366
#2  0x8058b120 in vpanic (fmt=, ap=)
at
/usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_shutdown.c:759
#3  0x8058b163 in panic (fmt=) at
/usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_shutdown.c:690
#4  0x8056c216 in __mtx_assert (c=,
what=, file=, line=)
at
/usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_mutex.c:1013
#5  0x80545219 in knote (list=, hint=256,
lockflags=0) at
/usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_event.c:2034
#6  0x8041ebc7 in nm_os_selwakeup (si=0xfe00088b94c0) at
/usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_freebsd.c:1259
#7  0x8041c94d in netmap_notify (kring=,
flags=)
at
/usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap.c:2777
#8  0x8041c701 in netmap_poll (priv=,
events=, sr=0x0)
at
/usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap.c:2735
#9  0x8041f63c in netmap_knrw (kn=,
hint=, events=1)
at
/usr/local/share/deploy-tools/RELENG_11/src/sys/dev/netmap/netmap_freebsd.c:1313
#10 0x805443d7 in kqueue_kevent (kq=0xf8001aa08600,
td=0xf80141470560, nchanges=, nevents=,
k_ops=0xfe045b5028a0, timeout=) at
/usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_event.c:1700
#11 0x80543fd6 in kern_kevent_fp (td=0xf80141470560,
fp=, nchanges=0, nevents=,
k_ops=, timeout=) at
/usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_event.c:1050
#12 0x80543eef in kern_kevent (td=0xf80141470560, fd=6,
nchanges=0, nevents=64, k_ops=0xfe045b5028a0, timeout=0x0)
at /usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_event.c:993
#13 0x80543cf8 in sys_kevent (td=0xf80141470560,
uap=0xfe045b502a30) at
/usr/local/share/deploy-tools/RELENG_11/src/sys/kern/kern_event.c:925
#14 0x80881b5a in amd64_syscall (td=0xf80141470560,
traced=0) at subr_syscall.c:135
#15 0x8086563b in Xfast_syscall () at
/usr/local/share/deploy-tools/RELENG_11/src/sys/amd64/amd64/exception.S:396
#16 0x00080122813a in ?? ()

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 219846] [panic] [kevent] mutex nm_kn_lock not owned, netmap with INVARIANTS+WITNESS

2017-06-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219846

Harald Schmalzbauer  changed:

   What|Removed |Added

   See Also||https://bugs.freebsd.org/bu
   ||gzilla/show_bug.cgi?id=2060
   ||53

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 220074] [kern] sys/kern/kern_prot.c: a sleep-under-mutex bug in crextend

2017-06-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220074

Mateusz Guzik  changed:

   What|Removed |Added

 Status|New |Closed
   Hardware|i386|Any
 Resolution|--- |Not A Bug
 CC||m...@freebsd.org
   Assignee|freebsd-bugs@FreeBSD.org|m...@freebsd.org

--- Comment #1 from Mateusz Guzik  ---
The loop in crcopysafe is supposed to guarantee that the memory allocated for
the new credential set is sufficient. i.e. it is an invariant that crcopy as
called from here does not have to malloc.

it would be better if there was no malloc codepath from here in the first
place, but there is no bug here and the entire cr* family needs to be
refactored

as such I'm closing as NOTABUG. thanks for reporting.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 220074] [kern] sys/kern/kern_prot.c: a sleep-under-mutex bug in crextend

2017-06-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220074

Bug ID: 220074
   Summary: [kern] sys/kern/kern_prot.c: a sleep-under-mutex bug
in crextend
   Product: Base System
   Version: 11.0-RELEASE
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: baijiaju1...@163.com

The kernel may sleep under a mutex, and the function call path in file
"sys/kern/kern_prot.c" is:
sys_setuid [line 502: acquire the mutex]
  crcopysafe [line 506]
crcopy [line 1991]
  crsetgroups [line 1892]
crextend [line 2081]
  malloc(M_WAITOK) [line 2032] --> may sleep

The possible fix of this bug is to replace "M_WAITOK" in malloc with
"M_NOWAIT".

This bug is found by a static analysis tool written by myself, and it is
checked by my review of the FreeBSD code.

Jia-Ju Bai

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 220074] [kern] sys/kern/kern_prot.c: a sleep-under-mutex bug in crextend

2017-06-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220074

Jia-Ju Bai  changed:

   What|Removed |Added

   Hardware|Any |i386
 CC||baijiaju1...@163.com

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 220073] iflib panic r320049

2017-06-17 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220073

Bug ID: 220073
   Summary: iflib panic r320049
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Many People
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: dcha...@freebsd.org

Fatal trap 12: page fault while in kernel mode
cpuid = 6; apic id = 06
fault virtual address   = 0x0
fault code  = supervisor write data, page not present
instruction pointer = 0x20:0x8071093e
stack pointer   = 0x28:0xfe04562cf8f0
frame pointer   = 0x28:0xfe04562cf9d0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 0 (if_io_tqg_6)

(kgdb) bt
#0  __curthread () at ./machine/pcpu.h:232
#1  doadump (textdump=0x81453290) at
/home/git/head/sys/kern/kern_shutdown.c:318
#2  0x8036e4cc in db_fncall_generic (addr=,
rv=, nargs=, 
args=) at /home/git/head/sys/ddb/db_command.c:581
#3  db_fncall (dummy1=, dummy2=,
dummy3=, dummy4=)
at /home/git/head/sys/ddb/db_command.c:629
#4  0x8036e03f in db_command (last_cmdp=,
cmd_table=, dopager=)
at /home/git/head/sys/ddb/db_command.c:453
#5  0x8036dd74 in db_command_loop () at
/home/git/head/sys/ddb/db_command.c:506
#6  0x80370eaf in db_trap (type=, code=)
at /home/git/head/sys/ddb/db_main.c:248
#7  0x8063eed3 in kdb_trap (type=0xc, code=0x0, tf=) at
/home/git/head/sys/kern/subr_kdb.c:654
#8  0x8092caa2 in trap_fatal (frame=0xfe04562cf830, eva=0x0) at
/home/git/head/sys/amd64/amd64/trap.c:819
#9  0x8092cb52 in trap_pfault (frame=0xfe04562cf830, usermode=0x0)
at /home/git/head/sys/amd64/amd64/trap.c:680
#10 0x8092be8d in trap (frame=0xfe04562cf830) at
/home/git/head/sys/amd64/amd64/trap.c:425
#11 
#12 m_init (how=0x1, type=0x1, m=, flags=) at
/home/git/head/sys/sys/mbuf.h:721
#13 iflib_rxd_pkt_get (rxq=, ri=) at
/home/git/head/sys/net/iflib.c:2432
#14 iflib_rxeof (budget=0x10, rxq=) at
/home/git/head/sys/net/iflib.c:2529
#15 _task_fn_rx (context=0xf800046e9000) at
/home/git/head/sys/net/iflib.c:3510
#16 0x8063d3b9 in gtaskqueue_run_locked (queue=0xf80008f9c200)
at /home/git/head/sys/kern/subr_gtaskqueue.c:329
#17 0x8063d148 in gtaskqueue_thread_loop (arg=) at
/home/git/head/sys/kern/subr_gtaskqueue.c:504
#18 0x805c180b in fork_exit (callout=0x8063d0c0
, arg=0xfef2f098, 
frame=0xfe04562cfac0) at /home/git/head/sys/kern/kern_fork.c:1038
#19 
(kgdb)
(kgdb) up 13
#13 iflib_rxd_pkt_get (rxq=, ri=) at
/home/git/head/sys/net/iflib.c:2432
2432m_init(m, M_NOWAIT, MT_DATA, M_PKTHDR);
(kgdb) p m
$1 = (struct mbuf *) 0x0
(kgdb)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"