[Bug 207359] projects/clang380-import for TARGET_ARCH=powerpc64 via powerpc64-gcc : c++ exceptions unbounded loop in _Unwind_RaiseException (9 line program)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207359

--- Comment #4 from Mark Millard  ---
(In reply to Mark Millard from comment #3)

And now I see that I types "libc++" in places that I should have typed
"libcxxrt".

Noted here just to help avoid confusions.

-- 
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 207359] projects/clang380-import for TARGET_ARCH=powerpc64 via powerpc64-gcc : c++ exceptions unbounded loop in _Unwind_RaiseException (9 line program)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207359

--- Comment #3 from Mark Millard  ---
(In reply to Mark Millard from comment #2)

I should have noted that powerpc64-gcc was used for buildworld of
projects/clang380-import -r295902 (and other  versions) --and so for libcxxrt
as well.

It is g++ 5.3 that put out the incomplete .eh_frame frame-context tracking.

-- 
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 207359] projects/clang380-import for TARGET_ARCH=powerpc64 via powerpc64-gcc : c++ exceptions unbounded loop in _Unwind_RaiseException (9 line program)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207359

--- Comment #2 from Mark Millard  ---
I've finally traced the low level details of the _Unwind_RaiseException stuck
looping failure. . .

Starting from the observed low-level evidence based on observation via gdb and
such:

A backtrace while stopped during the unbounded looping is:

#0  uw_update_context (context=context@entry=0xccf0,
fs=fs@entry=0xc370) at
/usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:1371
#1  0x501cb95c in _Unwind_RaiseException (exc=0x50815058) at
/usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind.inc:126
#2  0x5016e3a0 in throw_exception (ex=0x50815000) at
/usr/src/lib/libcxxrt/../../contrib/libcxxrt/exception.cc:751
#3  0x1d50 in main () at exception_test.cpp:5

_Unwind_RaiseException never returns for source code that looks like:

#include 

int main(void)
{
try { throw std::exception(); }
catch (std::exception& e) {}
return 0;
}

where in /usr/lib/libc++.so.1 there is:

736 static void throw_exception(__cxa_exception *ex)
737 {
. . .
751 _Unwind_Reason_Code err =
_Unwind_RaiseException(>unwindHeader);
. . .
756 }

The unbounded loop in _Unwind_RaiseException is in the code:

85  _Unwind_Reason_Code
86  _Unwind_RaiseException(struct _Unwind_Exception *exc)
87  {
88struct _Unwind_Context this_context, cur_context;
89_Unwind_Reason_Code code;
90  
91/* Set up this_context to describe the current stack frame.  */
92uw_init_context (_context);
93cur_context = this_context;
94  
95/* Phase 1: Search.  Unwind the stack, calling the personality
routine
96   with the _UA_SEARCH_PHASE flag set.  Do not modify the stack yet. 
*/
97while (1)
98  {
99_Unwind_FrameState fs;
100 
101   /* Set up fs to describe the FDE for the caller of cur_context. 
The
102  first time through the loop, that means __cxa_throw.  */
103   code = uw_frame_state_for (_context, );
. . .
125   /* Update cur_context to describe the same frame as fs.  */
126   uw_update_context (_context, );
127 }
. . .
140 }

The uw_update_context call is doing the following before returning:

1367  /* Compute the return address now, since the return address column
1368 can change from frame to frame.  */
1369  context->ra = __builtin_extract_return_addr
1370(_Unwind_GetPtr (context, fs->retaddr_column));

with context->ra before and after the call both being 0x5016e3a0 . In fact it
was 0x5016e3a0 for the prior uw_frame_state_for call as well and continues to
be so each loop iteration once the problem starts.

As for the code around 0x5016e3a0:

   0x5016e398 :  stw
r10,48(r9)
   0x5016e39c :  bl 
0x50162ae0 <0017.plt_call._Unwind_RaiseException@@GCC_3.0>
   0x5016e3a0 :  ld 
r2,40(r1)
   0x5016e3a4 :  addi   
r1,r1,128
   0x5016e3a8 :  mr 
r4,r31
   0x5016e3ac :  ld 
r0,16(r1)

 From /usr/local/bin/objdump for FreeBSD projects/clang380-import -r295902's
/usr/lib/libc++.so.1 for the same code (to match up with the .eh_frame dwarf
information presented later):

00015398 <.__cxa_end_catch+0x4d8> stw r10,48(r9)
0001539c <.__cxa_end_catch+0x4dc> bl  9ae0

000153a0 <.__cxa_end_catch+0x4e0> ld  r2,40(r1)
000153a4 <.__cxa_end_catch+0x4e4> addir1,r1,128
000153a8 <.__cxa_end_catch+0x4e8> mr  r4,r31
000153ac <.__cxa_end_catch+0x4ec> ld  r0,16(r1)

The code block above from 153a0 up to 153a8 is being given 153a0 as its "return
address" (context->ra) by uw_update_context via interpreting the dwarf
.eh_frame information. So once in that range there it never leaves that range.

The relevant dwarfdump output spanning that area is:
(Note that 153a0 up to 153a8 is part of the range that includes the bl to
_Unwind_RaiseException .)

<0><0x00015310:0x000153dc><>
0x00015310:  
0x00015318:
0x00015324:
0x00015368:
0x00015378:  
0x00015380:
0x000153a8:
0x000153b8:  
0x000153c0:
 fde section offset 4312 0x10d8 cie offset for fde: 4316 0x10dc
 0 DW_CFA_advance_loc 8  (2 * 4)
 1 DW_CFA_register r65 = r0
 4 DW_CFA_offset r31 -8  (1 * -8)
 6 DW_CFA_advance_loc 12  (3 * 4)
 7 DW_CFA_def_cfa_offset 128
10 DW_CFA_offset_extended_sf r65 16  (-2 * -8)
13 DW_CFA_advance_loc 68  (17 * 4)
14 

[Bug 207463] [patch] stable/10/sys/netpfil/pf/pf_ioctl.c:pfioctl(DIOCRSETADDRS) buffer overflow

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207463

Kristof Provost  changed:

   What|Removed |Added

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

--- Comment #1 from Kristof Provost  ---
I think your analysis is correct.

The intention of the bcopy() appears to be to copy additional addresses behind
the original list (hence the adds + size + i construction).

You're correct that the buffer allocated by 'totlen = io->pfrio_size *
sizeof(struct pfr_addr);' is too small for that.
It's possible to panic a box that way.

I don't think your fix is sufficient though. If user space provides a smaller
pfrio_size2 than pfrio_size (remember that all user space programmers are out
to get us!) then we'd still end up running outsize the allocated buffer.

I think we need to allocate the largest of pfrio_size and pfrio_size2:
https://reviews.freebsd.org/D5426

-- 
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 207464] Panic when destroying ZFS snapshot on boot filesystem

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207464

--- Comment #1 from dustinw...@ebureau.com ---
This is almost a stock kernel, with vimage enabled and the ARC patch applied
from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594

I see that the checkin yesterday for vfs_subr.c reverted it to back to a
version from December due to an unexplained ZFS bug. It's possible this is
related, but I've not been able to reproduce it yet on r295115.

-- 
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 207464] Panic when destroying ZFS snapshot on boot filesystem

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207464

Bug ID: 207464
   Summary: Panic when destroying ZFS snapshot on boot filesystem
   Product: Base System
   Version: 10.2-STABLE
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: dustinw...@ebureau.com
CC: freebsd-am...@freebsd.org
CC: freebsd-am...@freebsd.org

FreeBSD 10.3-PRERELEASE #13 r295115M: Mon Feb  1 13:08:30 CST 2016

When destroying a ZFS snapshot of the boot filesystem, the system panicked with
the message:

vputx: negative ref cnt

KDB stack backtrace:

vputx: negative ref count
0xf801d7ab7b10: tag zfs, type VDIR
usecount 0, writecount 0, refcount 0 mountedhere 0
flags (VI_FREE)
 VI_LOCKedlock type zfs: EXCL by thread 0xf80448797960 (pid 7211, zfs,
tid 101642)
panic: vputx: negative ref cnt
cpuid = 13
KDB: stack backtrace:
#0 0x8098f7f0 at kdb_backtrace+0x60
#1 0x80952896 at vpanic+0x126
#2 0x80952763 at panic+0x43
#3 0x809f94e5 at vputx+0x2d5
#4 0x809f2a99 at dounmount+0x689
#5 0x81a851d4 at zfs_unmount_snap+0x114
#6 0x81a884f1 at zfs_ioc_destroy_snaps+0xc1
#7 0x81a86f54 at zfsdev_ioctl+0x664
#8 0x80837469 at devfs_ioctl_f+0x139
#9 0x809aa085 at kern_ioctl+0x255
#10 0x809a9d80 at sys_ioctl+0x140
#11 0x80d68aff at amd64_syscall+0x40f
#12 0x80d4dd7b at Xfast_syscall+0xfb
Uptime: 4h4m41s


(kgdb) bt
#0  __curthread () at ./machine/pcpu.h:219
#1  doadump (textdump=) at /usr/src/sys/kern/kern_shutdown.c:298
#2  0x809524f2 in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:486
#3  0x809528d5 in vpanic (fmt=, ap=) at
/usr/src/sys/kern/kern_shutdown.c:889
#4  0x80952763 in panic (fmt=) at
/usr/src/sys/kern/kern_shutdown.c:818
#5  0x809f94e5 in vputx (vp=0xf801d7ab7b10, func=)
at /usr/src/sys/kern/vfs_subr.c:2510
#6  0x809f2a99 in dounmount (mp=0xf80142dc4660, flags=, td=) at /usr/src/sys/kern/vfs_mount.c:1359
#7  0x81a851d4 in zfs_unmount_snap (snapname=) at
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:3485
#8  0x81a884f1 in zfs_ioc_destroy_snaps (poolname=0xfe00170f8000
"zroot", innvl=, outnvl=0xf804488297a0) at
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:3558
#9  0x81a86f54 in zfsdev_ioctl (dev=, zcmd=, arg=, flag=, td=) at
/usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_ioctl.c:6278
#10 0x80837469 in devfs_ioctl_f (fp=0xf8001ff5b8c0, com=3222821411,
data=0xfe085e28b8e0, cred=, td=0xf80448797960) at
/usr/src/sys/fs/devfs/devfs_vnops.c:786
#11 0x809aa085 in fo_ioctl (fp=, com=,
data=, active_cred=, td=,
fp=, com=, data=,
active_cred=, td=) at /usr/src/sys/sys/file.h:321
#12 kern_ioctl (td=0xf80448797960, fd=, com=)
at /usr/src/sys/kern/sys_generic.c:809
#13 0x809a9d80 in sys_ioctl (td=0xf80448797960,
uap=0xfe085e28ba40) at /usr/src/sys/kern/sys_generic.c:718
#14 0x80d68aff in syscallenter (td=, sa=,
td=, sa=) at
/usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:141
#15 amd64_syscall (td=0xf80448797960, traced=0) at
/usr/src/sys/amd64/amd64/trap.c:959
#16 
#17 0x000801a05f1a in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffc8c8

-- 
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 207463] [patch] stable/10/sys/netpfil/pf/pf_ioctl.c:pfioctl(DIOCRSETADDRS) buffer overflow

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207463

Bug ID: 207463
   Summary: [patch]
stable/10/sys/netpfil/pf/pf_ioctl.c:pfioctl(DIOCRSETAD
DRS) buffer overflow
   Product: Base System
   Version: 10.3-BETA2
  Hardware: Any
OS: Any
Status: New
  Keywords: patch
  Severity: Affects Many People
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: p...@inetstat.net
CC: freebsd-sta...@freebsd.org
  Keywords: patch

Created attachment 167367
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=167367=edit
stable/10/sys/netpfil/pf/pf_ioctl.c patch

While investigating bug #192677 (pfctl iotcl buffer to small for bigger spamd
blacklists) on releng/10.2, I believe I have spotted a kernel buffer overflow
in stable/10/sys/netpfil/pf/pf_ioctl.c / stable/10/sys/netpfil/pf/pf_table.c,
introduced by base r286862 / base r286961.

stable/10/sys/netpfil/pf/pf_ioctl.c:pfioctl(DIOCRSETADDRS):

totlen = io->pfrio_size * sizeof(struct pfr_addr);
pfras = malloc(totlen, M_TEMP, M_WAITOK);

stable/10/sys/netpfil/pf/pf_table.c:pfr_set_addrs():

bcopy(, addr + size + i, sizeof(ad));

Inside pfr_set_addrs(), pfioctl()'s "pfras" becomes "addr", "io->pfrio_size"
becomes "size", and "io->pfrio_size2" becomes "size2".  pfr_set_addrs() uses
size2 to protect the buffer just above that bcopy.  Looking carefully at
stable/10/sys/sbin/pfctl/pfctl_table.c:pfctl_table("replace") and
stable/10/sys/sbin/pfctl/pfctl_radix.c:pfr_buf_grow(), io->pfrio_buffer passed
into the ioctl is size2.

This is theoretical, based on simulating the code mentally.  I'm fairly certain
that my analysis is correct, but I've not verified it via compiled stable/10
code.  The bcopy seems to fairly obviously run off the end of the buffer when
it is only "size".  The fix should be quite simple, by just changing the buffer
to be "size2" in stable/10/sys/netpfil/pf/pf_ioctl.c:pfioctl(DIOCRSETADDRS):

totlen = io->pfrio_size2 * sizeof(struct pfr_addr);

Untested patch attached.  I believe this applies to both stable/10 and head.  I
have tagged it as 10.3-BETA, as that seems to be the places where the more
urgent attention is needed, as it would be quite unfortunate for 10.3 to be
released with this bug (if my analysis is correct).

-- 
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 207069] setting loader password in loader.conf disallows boot

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207069

Ian Lepore  changed:

   What|Removed |Added

 CC||i...@freebsd.org
 Status|New |Open

--- Comment #2 from Ian Lepore  ---
Added dteske@ who is knowledgeable about this stuff.

-- 
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 204081] Uninterruptible sleep under 10.2-RELEASE

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204081

Kubilay Kocak  changed:

   What|Removed |Added

   Keywords||needs-patch, needs-qa
 Status|New |Open
   See Also||https://bugs.freebsd.org/bu
   ||gzilla/show_bug.cgi?id=2009
   ||92
 CC||k...@freebsd.org
URL||https://reviews.freebsd.org
   ||/D5221
  Flags||mfc-stable9?, mfc-stable10?

-- 
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 194925] [pf] [ifconfig] interface group keywords do not work by default

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194925

--- Comment #8 from Mark Felder  ---
The problem I fixed was that "groups" were hidden from ifconfig(8) output.

The outstanding issue is that when pf was ported to FreeBSD we never made
automatic group membership work. As originally stated in this PR:

The problem appears to be that we do not have interfaces in groups by default.
OpenBSD has the following in their ifconfig(8):

 Some interfaces belong to specific groups by default:

 -   All interfaces are members of the all interface
 group.
 -   Cloned interfaces are members of their interface
 family group.  For example, a PPP interface such
 as ppp0 is a member of the ppp interface family
 group.
 -   pppx(4) interfaces are members of the pppx
 interface group.
 -   The interface(s) the default route(s) point to
 are members of the egress interface group.
 -   IEEE 802.11 wireless interfaces are members of
 the wlan interface group.
 -   Any interfaces used for network booting are
 members of the netboot interface group.


This functionality is extremely valuable and expected to work when you read the
pf docs.

-- 
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 194925] [pf] [ifconfig] interface group keywords do not work by default

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194925

Kubilay Kocak  changed:

   What|Removed |Added

  Flags||mfc-stable10?

-- 
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 194925] [pf] [ifconfig] interface group keywords do not work by default

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194925

Kubilay Kocak  changed:

   What|Removed |Added

URL||https://reviews.freebsd.org
   ||/D1185
 CC||d...@freebsd.org

--- Comment #7 from Kubilay Kocak  ---
CC original review approver

-- 
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 207459] ipfw rule using dscp cs4 results in be/cs0

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207459

Andrey V. Elsukov  changed:

   What|Removed |Added

   Assignee|freebsd-bugs@FreeBSD.org|a...@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 207459] ipfw rule using dscp cs4 results in be/cs0

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207459

--- Comment #3 from Andrey V. Elsukov  ---
(In reply to smithi from comment #2)
> Rats, ae@ beat me to it .. i << 32 is of course 0.
> 
> But not just sbin/ipfw .. also in /sys/netpfil/ipfw/ip_fw2.c:

Yes, you are right. Both places should be fixed.

-- 
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 194925] [pf] [ifconfig] interface group keywords do not work by default

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194925

Mark Felder  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|Closed  |Open

--- Comment #6 from Mark Felder  ---
reopening as someone else ran into this problem

-- 
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 207459] ipfw rule using dscp cs4 results in be/cs0

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207459

smi...@nimnet.asn.au changed:

   What|Removed |Added

 CC||smi...@nimnet.asn.au

--- Comment #2 from smi...@nimnet.asn.au ---
Rats, ae@ beat me to it .. i << 32 is of course 0.

But not just sbin/ipfw .. also in /sys/netpfil/ipfw/ip_fw2.c:

case O_DSCP:
{
uint32_t *p;
uint16_t x;
[..]
/* DSCP bitmask is stored as low_u32 high_u32 */
if (x > 32)
  match = *(p + 1)  & (1 << (x - 32));
else
match = *p & (1 << x);
}

-- 
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 207459] ipfw rule using dscp cs4 results in be/cs0

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207459

Andrey V. Elsukov  changed:

   What|Removed |Added

 CC||a...@freebsd.org

--- Comment #1 from Andrey V. Elsukov  ---
Created attachment 167361
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=167361=edit
Proposed patch

Can you test this patch? You only need to rebuild sbin/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 207459] ipfw rule using dscp cs4 results in be/cs0

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207459

Sean  changed:

   What|Removed |Added

   Severity|Affects Only Me |Affects Many People

-- 
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 207459] ipfw rule using dscp cs4 results in be/cs0

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207459

Bug ID: 207459
   Summary: ipfw rule using dscp cs4 results in be/cs0
   Product: Base System
   Version: 10.2-RELEASE
  Hardware: amd64
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: swh...@gov.za
CC: freebsd-am...@freebsd.org
CC: freebsd-am...@freebsd.org

Using dscp cs4 in any rule results in the test being for dscp be:

# ipfw add 1 pipe 1 in dscp cs4 recv igb0
1 pipe 1 ip from any to any in dscp be recv igb0
#

but this:

# ipfw add 1 pipe 1 in dscp cs2 recv igb0
1 pipe 1 ip from any to any in dscp cs2 recv igb0
#

...appears to be fine. Pretty much anything else works other than cs4 which
gets interpreted as be (0x0).

The same applies when using simple rules like 'count'.

cs4, 32, 0x20, all give the same result.

 # ipfw add 1 count in dscp 0x20
1 count ip from any to any in dscp be
 #
 # ipfw -aT list 1
1  3456945  2202370996 1456315172 count ip from any to any in dscp be
 #

This is seen in 9.3-R, 9.3-Rp33, 10.2-Rp8.

-- 
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 207422] sys/amd64/amd64/support.S mempcy does not return dest

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207422

--- Comment #1 from commit-h...@freebsd.org ---
A commit references this bug:

Author: kib
Date: Wed Feb 24 11:58:15 UTC 2016
New revision: 295966
URL: https://svnweb.freebsd.org/changeset/base/295966

Log:
  Return dst as the result from memcpy(9) on amd64.

  PR:   207422
  MFC after:1 week

Changes:
  head/sys/amd64/amd64/support.S

-- 
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 207457] pgrep OR libkvm - cannot get process list (Bad address)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207457

Bug ID: 207457
   Summary: pgrep OR libkvm - cannot get process list (Bad
address)
   Product: Base System
   Version: 9.3-STABLE
  Hardware: Any
OS: Any
Status: New
  Keywords: crash
  Severity: Affects Only Me
  Priority: ---
 Component: bin
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: wojci...@sychut.pl

Created attachment 167358
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=167358=edit
script fragment

pgrep(1) command would occasionally output "pgrep: Cannot get process list
(kvm_getprocs: Bad address)" when issuing `pgrep -f $0` from a script.
It has failed 3 times during a week period, in which the script was run from
cron(8) every minute.
I wasn't able to replicate the issue manually in any kind of loop.

-- 
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 202140] HP Z600 defaults to LAPIC for kern.eventtimer.timer but can't use 'Online CPU idle state' higher than C1 with this setting

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202140

--- Comment #3 from Jochen Breuer  ---
Hi Ivan, changing the timer solves the problem. But if those timers can't be
used with C8, perhaps they shouldn't be the default in the first place.

-- 
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"