Re: Checking MAC address of incoming unicast packets

On 01/01/16(Fri) 22:55, Stefan Fritsch wrote: > Hi, > > by default, the ether_input() checks the destination MAC address of > incoming unicast packets only if the interface is in promiscous mode. If > not, it is assumed that the NIC filters unicast packets reliably. > Unfortunately, for

Re: Make em(4) more mpsafe again

On 31.12.2015. 15:08, David Gwynne wrote: > On Sat, Dec 05, 2015 at 03:41:24PM +0100, Claudio Jeker wrote: >> So Mark and I spent some time to figure out what the issue was with ix(4) >> based on that info I resurected the em(4) mpsafe diff that got backed out >> and I applied the same fix. It is

tmpfs uiomove() conversion

Below a diff to convert tmpfs/tmpfs_{subr,vnops}.c. That's an easy one. Nearly all the relevant size variables already are a size_t, or a smaller unsigned type. In the last hunk tn_size (an off_t) might be passed to uiomove(), which is not problematic, because tn_size is constrained to only hold

dev/rnd.c uiovmove() conversion

Below, a diff to convert dev/rnd.c to use uiomove(). cheers, natano Index: dev/rnd.c === RCS file: /cvs/src/sys/dev/rnd.c,v retrieving revision 1.177 diff -u -p -u -r1.177 rnd.c --- dev/rnd.c 28 Dec 2015 05:21:53 - 1.177

Re: Checking MAC address of incoming unicast packets

On Friday 01 January 2016 16:25:59, Theo de Raadt wrote: > dlg writes: > > should we just do it unconditionally? is there a downside to that? It may decrease performance a tiny bit. Since such bits tend to add up, I would be hesitant to enable the check for drivers that don't need it. OTOH,

Re: fuser(1): Fix pledge when `u' flag is used

On Fri, Jan 01, 2016 at 10:29:08PM -0500, Michael Reed wrote: > Hi, > > `fuser -u -c /' doesn't seem to work for me: > > fuser(28663): syscall 33 "getpw" > > The patch below fixes my issue. The pledge condition was already a bit > long, so I just switched to snprintf(3); not sure what's

Re: fuser(1): Fix pledge when `u' flag is used

Michael Reed(m.r...@mykolab.com) on 2016.01.01 22:29:08 -0500: > Hi, > > `fuser -u -c /' doesn't seem to work for me: > > fuser(28663): syscall 33 "getpw" > > The patch below fixes my issue. The pledge condition was already a bit > long, so I just switched to snprintf(3); not sure what's

Remove unused variable in usr.bin/systat/main.c

int ms in cmd_count is unused as of 1.63 Index: main.c === RCS file: /cvs/src/usr.bin/systat/main.c,v retrieving revision 1.63 diff -u -p -r1.63 main.c --- main.c 18 Apr 2015 18:28:38 - 1.63 +++ main.c 1 Jan 2016

unused proc_ispeer() in proc.c

I think that proc_ispeer() is never used: /usr/src$ grep -r ispeer . 2>/dev/null ./sbin/iked/proc.c:int proc_ispeer(struct privsep_proc *, unsigned int, enum privsep_procid); ./sbin/iked/proc.c:proc_ispeer(struct privsep_proc *procs, unsigned int nproc, ./usr.sbin/httpd/proc.c:int

Don't declare main() in fsck, fsck_msdos, fsdb, ncheck_ffs

main() does not need to be declared. Also mark usage() as __dead in fsck_msdos and fsdb. Index: fsck/fsck.c === RCS file: /cvs/src/sbin/fsck/fsck.c,v retrieving revision 1.38 diff -u -p -r1.38 fsck.c --- fsck/fsck.c 23 Nov 2015

dead assignements in usr.bin/systat

an earlier commit today prompted florian@ to run clang, these fixes are a result of issues found. ok? [PATCH 1/4] remove unused variable cur. code probably c from print_bar_title(). diff --git usr.bin/systat/engine.c usr.bin/systat/engine.c index 51c0b7f..bc9f6ef 100644 ---

Re: dead assignements in usr.bin/systat

> Date: Sat, 2 Jan 2016 18:21:07 +0100 > From: Sebastian Benoit > > an earlier commit today prompted florian@ to run clang, these fixes are a > result of issues found. > > ok? sure > [PATCH 1/4] remove unused variable cur. code probably c from > print_bar_title(). > > diff

Re: Don't declare main() in fsck, fsck_msdos, fsdb, ncheck_ffs

On Sat, Jan 2, 2016 at 8:30 AM, Michal Mazurek wrote: > main() does not need to be declared. Out of curiosity, has someone positively confirmed that gcc3, like gcc4, treats main as explicitly declared for the purposes of -Werror-implicit-function-declaration? Philip

vmd.h typo in comment (VMM_DEBUG -> VMD_DEBUG)

Index: vmd.h === RCS file: /cvs/src/usr.sbin/vmd/vmd.h,v retrieving revision 1.16 diff -u -p -r1.16 vmd.h --- vmd.h 11 Dec 2015 10:16:53 - 1.16 +++ vmd.h 2 Jan 2016 14:56:02 - @@ -43,7 +43,7 @@ #define

Re: Remove unused variable in usr.bin/systat/main.c

thanks, committed evh(e...@riseup.net) on 2016.01.02 15:34:50 +0100: > int ms in cmd_count is unused as of 1.63 > > Index: main.c > === > RCS file: /cvs/src/usr.bin/systat/main.c,v > retrieving revision 1.63 > diff -u -p -r1.63

Re: Checking MAC address of incoming unicast packets

> Date: Sat, 2 Jan 2016 10:57:41 +0100 > From: Martin Pieuchot > > If it's acceptable performance-wise to do the check unconditionally I > believe that's the way to go. If not I'm a bit afraid of introducing > a flag/capability for a single driver. Do you know if any other

smtpd.conf(5) term filter misleading use

When the text is not talking about filters, but about accept/reject rules and using the term "filter", try to find some other wording. Bye, Marcus Index: smtpd.conf.5 === RCS file: /cvs/src/usr.sbin/smtpd/smtpd.conf.5,v retrieving

getentropy(2) in ports

Hi Robert, Noticed the following commit: > CVSROOT:/cvs > Module name:ports > Changes by: rob...@cvs.openbsd.org 2016/01/02 06:57:12 > > Modified files: > mail/zarafa/zarafa: Makefile > mail/zarafa/zarafa/patches: patch-common_platform_linux_cpp >

Re: Make em(4) more mpsafe again

Hi David and tech@, I just tried the patch on a December 28 snapshot and got a watchdog timeout while running iperf. Just the snapshot without the patch survives iperf without a timeout. The device in question is this one: em0 at pci1 dev 0 function 0 "Intel 82583V" rev 0x00: msi,

ignore inflight messages in daily output

If mail is in the process of being sent (rather than sitting in the queue) we probably shouldn't complain about it. If something like daily.local causes mail to be sent this can end up with a lot of false positives. (False in the sense that nothing is actually wrong, so the system should be

Re: getentropy(2) in ports

>Hi Robert, > >Noticed the following commit: > >> CVSROOT:/cvs >> Module name:ports >> Changes by: rob...@cvs.openbsd.org 2016/01/02 06:57:12 >> >> Modified files: >> mail/zarafa/zarafa: Makefile >> mail/zarafa/zarafa/patches: patch-common_platform_linux_cpp >>

Remove #include from games section

Hi, Story facts of the day (for myself included), about 13 years ago games section had srandom(time()+getpid()) and was changed by srandomdev(). Of course in the course of years they have been changed to arc4random or random, nevertheless all their consumers kept #include so remove it. As

uudecode(1): add missing "getpw" pledge

uudecode and b64decode might need "getpw" if -s or -o is given. The reason is the getpwnam(3) call on uudecode.c:238 that is reached if 'sflag == 1' and the `remote file name' triggers `tilde expansion': $ cat boom begin 644 ~/boom %8F]O;0H` ` end $ uudecode -s boom Abort trap (core dump) $

Re: uudecode(1): add missing "getpw" pledge

On Sun, Jan 03, 2016 at 06:32:09AM +0100, Theo Buehler wrote: > uudecode and b64decode might need "getpw" if -s or -o is given. The > reason is the getpwnam(3) call on uudecode.c:238 that is reached if > 'sflag == 1' and the `remote file name' triggers `tilde expansion': > > $ cat boom > begin