Date: Mon, 23 May 2016 14:21:31 +0200 From: Joerg Sonnenberger <joerg@bec.de> To: Matthew Macy <mmacy@nextbsd.org> Cc: Joerg Sonnenberger <joerg@bec.de>, "<freebsd-hackers@freebsd.org>" <freebsd-hackers@freebsd.org> Subject: Re: read(2) and thus bsdiff is limited to 2^31 bytes Message-ID: <20160523122131.GC8747@britannica.bec.de> In-Reply-To: <154db353935.dd5e87c1133922.4370692881788049491@nextbsd.org> References: <b2515cae-b75d-66e9-4207-3cf100ab3ab0@erdgeist.org> <20160522225414.GB24398@britannica.bec.de> <154dab43060.11208cdfd132112.2616144627831899155@nextbsd.org> <20160522231203.GB25503@britannica.bec.de> <154db353935.dd5e87c1133922.4370692881788049491@nextbsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, May 22, 2016 at 06:22:58PM -0700, Matthew Macy wrote: > > > > ---- On Sun, 22 May 2016 16:12:03 -0700 Joerg Sonnenberger <joerg@bec.de> wrote ---- > > On Sun, May 22, 2016 at 04:02:02PM -0700, Matthew Macy wrote: > > > > > > > > > > > > ---- On Sun, 22 May 2016 15:54:14 -0700 Joerg Sonnenberger <joerg@bec.de> wrote ---- > > > > On Sun, May 22, 2016 at 10:54:30PM +0200, Dirk Engling wrote: > > > > > When trying to bsdiff two DVD images, I noticed it failing due to > > > > > read(2) returning EINVAL to the tool. man 2 read says, this would only > > > > > happen for a negative value for fildes, which clearly was not true. > > > > > > > > I would classify that as implementation bug. It seems perfectly sensible > > > > to turn overly large requests into a short read/write, even for blocking > > > > files. But erroring out seems to be quite wrong to me. > > > > > > > > > > read(2) takes a size_t so this is clearly an internal bug where it's an int and treating it as a negative value. > > > > Not exactly. The reason for cutting it off are many fold. Using int in > > the kernel is one argument. The requirement for locking the IO range for > > concurrent read/write operations from other threads is a bigger > > argument. > > > That still doesn't justify EINVAL as a return. Does read(2) need to > make atomicity guarantees? See my first sentence. I consider returning EINVAL for too large buffer size a bug. Yes, read/write operations should be atomic with regard to other processes on the system. Atomic meaning in this context that the read can be observed either completely or not at all. This still doesn't mean that read must execute the full size. Other cases for short read/writes are socket, pipes etc. Joerg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160523122131.GC8747>