[Bug 226637] misc/mbuffer: Immediate failure with 2017.10.11

[bugzilla-noreply at freebsd.org]

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

            Bug ID: 226637
           Summary: misc/mbuffer: Immediate failure with 2017.10.11
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Many People
          Priority: ---
         Component: Individual Port(s)
          Assignee: mm at FreeBSD.org
          Reporter: eborisch+FreeBSD at gmail.com
             Flags: maintainer-feedback?(mm at FreeBSD.org)
          Assignee: mm at FreeBSD.org

Created attachment 191527
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=191527&action=edit
Patches to fix and improve mbuffer behavior on FreeBSD.

Overview:

With no explicit counts set, mbuffer 2017.10.11 fails immediately on FreeBSD if
the physical memory on the system > ~ 6GB and kern.ipc.semvmx is its default
(32767 * 50 * 4096).


Steps to reproduce:


$ mbuffer -q < /dev/zero > /dev/null
mbuffer: fatal: cannot allocate more than 32767 blocks.
This is a system dependent limit, depending on the maximum semaphore value.
Please choose a bigger block size.


Additional information:


Attached is a patch to fix/improve this behavior. Will also submit upstream. 

Fixed (settings.c): reads the wrong parameter (checked SysV, but wants posix
semaphore limits), and into an uninitialized and wrong-sized variable with
sysctlbyname. Completely remove that part and just use 'mxnrsem =
sysconf(_SC_SEM_VALUE_MAX)' which returns the desired value (such that
sem_init(,,<=mxnrsem) will not fail EINVAL). Tested on 11.1; I don't have a <=
10.x around to test. Removes almost all __FreeBSD__ switches from settings.c.

Fixed (mbuffer.c): Don't allow default setting to be invalid. Clamp Numblocks
to mxnrsem.

Enhancement (mbuffer.c): Actually get free memory (similar value to the check
of _SC_AVPHYS_PAGES used where available) rather than total system memory when
calculating NumP/50 memory to use.

-- 
You are receiving this mail because:
You are the assignee for the bug.