Don't override all errors in opendev

Not all errors coming from diskmap should be overwritten. In particular, if we get EBUSY, that doesn't mean "try again with accessing /dev/foo, fail and return ENOENT instead". Maybe we should add more errors to this list, or even invert the filtering logic - I'm: 1) not an expert in this area;

Re: Don't override all errors in opendev

2016-01-20 1:10 GMT+03:00 Vadim Zhukov : > Not all errors coming from diskmap should be overwritten. > In particular, if we get EBUSY, that doesn't mean "try again with > accessing /dev/foo, fail and return ENOENT instead". > > Maybe we should add more errors to this list, or

Re: 0 is UIO_USERSPACE

Martin Natano wrote: > 0 is the same as UIO_USERSPACE, but more readable. No binary change. Makes sense. The entire tree uses the symbolic enum values. These are the only places that use 0. > Index: ./arch/octeon/dev/amdcf.c > ===

Re: sis(4) induced uvm faults on net4801

Hi, I have the same problem with an re(4) adapter and CARP. My post is in the bugs mail list (UVM Fault with CARP on re(4), 2016-01-17 09:15) Fabrice Le 2016-01-07 12:36, Nathanael Rensen a écrit : > tl;dr: Zero-length packets from sis(4) on net4801 result in negative > length mbufs

Re: spec_vnops.c uiomove() conversion

> Date: Mon, 18 Jan 2016 19:12:01 +0100 > From: Stefan Kempf > > Martin Natano wrote: > > Below the conversion to uiomove() for kern/spec_vnops.c. This diff > > prevents truncation of uio_resid when passed to min(). > > Looks good. Basically the same reasoning as with the

Re: cd9660 uiomove() conversion

> > Diff reads good. ok? ok kettenis@ > Some thoughts (mostly for myself) inline. > > Martin Natano wrote: > > Below the uiomove conversion for isofs/cd9660/cd9660_vnops.c. > > > > cheers, > > natano > > > > Index: isofs/cd9660/cd9660_vnops.c > >

Fix nfs_nget() description

Apparently the function was refactored and but the old description remained. I came across this a few weeks ago. Does my revision look good? Index: nfs/nfs_node.c === RCS file: /cvs/src/sys/nfs/nfs_node.c,v retrieving revision 1.62

segfault with tail -f

First noticed while running (and interrupting) dpb whilst tailing logs. Sequence of events, it may be relevant that $dir is on NFS: - mkdir $dir/a - for i in 1 2 3; do echo foo > $dir/a/$i; done - tail -f $dir/a/* - (in another window) doas rm -rf $dir #0 0x1664d4fa in tfreopen (tf=0x7f57732c)

Quoting ${CC} expansion in libiberty Makefile

Previously sent to misc@, but I was told to send it here instead. Cheers, Andreas - Forwarded message from Andreas Kusalananda Kähäri - Date: Mon, 18 Jan 2016 16:33:34 +0100 From: Andreas Kusalananda Kähäri To: openbsd-misc

I have a mirror testing program for you.

I have a 500 line program I wrote that reads openbsd.org.ftp.html and scraps off the html and ftp mirrors, records them all without redundancies as http mirrors in memory and downloads the appropriate version and machine architecture's SHA256 in the package folder. It tests all the mirrors for

Re: [patch] mg: Prevent out-of-bounds read when PATH="/:..."

On Tue, Jan 19, 2016 at 12:35:27PM +0100, Sunil Nimmagadda wrote: > > - dlen = strlen(dir); > > - while (dir[dlen-1] == '/') > > - dir[--dlen] = '\0'; /* strip trailing '/' */ > dlen could never be zero as we are replacing dir[0] with '.' if >

Re: [patch] mg: Prevent out-of-bounds read when PATH="/:..."

> On Tue, Jan 19, 2016 at 12:35:27PM +0100, Sunil Nimmagadda wrote: > > > > - dlen = strlen(dir); > > > - while (dir[dlen-1] == '/') > > > - dir[--dlen] = '\0'; /* strip trailing '/' */ > > > dlen could never be zero as we are replacing dir[0]

vmctl create nit-picks

Hi, below some comments regarding the vmctl disk image creation code. Index: main.c === RCS file: /cvs/src/usr.sbin/vmctl/main.c,v retrieving revision 1.13 diff -u -p -u -r1.13 main.c --- main.c 5 Jan 2016 16:25:34 -

vmx: vmxnet3_load_mbuf will still do the wrong thing

Hi, We've just run into a vmx panic and code inspection revealed that my previous diff contained a mistake, the pullup operation is called on a wrong mbuf chain. I apologize for overlooking this issue. We're not 100% certain that this fixes our exact problem yet since we can't reproduce it at