Re: socket splice task

2016-08-24 Thread Ted Unangst
Alexander Bluhm wrote: > Several possible solutions like letting tasks sleep at a different > priority or changing kernel threads to user priority have been > discussed. There was no consensus what to do. > > To move forward and uncouple the splicing improvement from the > scheduler discussion, I

pax/tar/cpio: don't mix filenames and diagnositic in list mode

2016-08-24 Thread Philip Guenther
When in list mode, the filenames in the archive are written to stdout. For pax, POSIX says that *only* the file listing output may be written there; all diagnostic output must go to stderr. So don't use listf or listfd to write non-file-listing output. There's a tricky bit that I'm not sure

Re: Use UWXN on armv7 when possible

2016-08-24 Thread Jonathan Gray
On Thu, Aug 25, 2016 at 12:49:45AM +0200, Mark Kettenis wrote: > So enabling full hardware-enforced W^X is perhaps a bit to much at > this moment. But enabling the bit that enforces that the kernel > cannot execute pages that are writable by userland should be fine. > The diff does this on all ARM

pax: use user_from_uid() and group_from_gid()

2016-08-24 Thread Philip Guenther
pax includes routines for caching getpw{nam,uid} and getgr{nam,gid} results. Okay, but libc already has caching uid->name and gid->name routines: user_from_uid() and group_from_gid(). Let's switch pax over to the libc routines. That'll free up a little space on the ramdisks. Notes: 1) the pa

Use UWXN on armv7 when possible

2016-08-24 Thread Mark Kettenis
So enabling full hardware-enforced W^X is perhaps a bit to much at this moment. But enabling the bit that enforces that the kernel cannot execute pages that are writable by userland should be fine. The diff does this on all ARMv7 processors that include the Virtualization Extensions, which is what

Re: socket splice task

2016-08-24 Thread Alexander Bluhm
On Fri, Jul 29, 2016 at 08:07:14PM -0400, Ted Unangst wrote: > Alexander Bluhm wrote: > > On Fri, Jul 29, 2016 at 06:46:52PM -0400, Ted Unangst wrote: > > > Alexander Bluhm wrote: > > > > + /* Avoid user land starvation. */ > > > > + yield(); > > > > > > you don't need to yield here, t

Re: No 'struct route_in6' in ip6_getpmtu()

2016-08-24 Thread Alexander Bluhm
On Wed, Aug 24, 2016 at 05:52:39PM +0200, Martin Pieuchot wrote: > Diff below simplifies ip6_getpmtu() to use a 'struct rtentry *' instead > of two 'struct route_in6'. > > ok? I have tested it with regress/sys/netinet/pmtu . OK bluhm@ > + if (rt != NULL) { ... > - } else if (ifp0) { > -

Re: inconsistent error handling in fgetln(3)

2016-08-24 Thread Andrey Chernov
On 24.08.2016 22:03, Ingo Schwarze wrote: >> Could you show some code? In my testing fgetwln() fails on next read if >> previously there was partial line with tail EILSEQ. Stdio not advance >> its pointer over the sequence with EILSEQ. > > See below for a radically stripped down version of FreeBSD

grep -o ^....

2016-08-24 Thread Ted Unangst
per freebsd bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201650 echo "1234 1234 1234" | grep -o ^ 1234 Index: util.c === RCS file: /cvs/src/usr.bin/grep/util.c,v retrieving revision 1.55 diff -u -p -r1.55 util.c

Re: inconsistent error handling in fgetln(3)

2016-08-24 Thread Ingo Schwarze
Hi Andrey, Andrey Chernov wrote on Wed, Aug 24, 2016 at 09:15:15PM +0300: > And if we plan to change original 44lite > function behavior, all BSD camps should agree at least. I agree that it is preferable to do such bugfixes in consensus, if possible; that helps to improve quality and coherence.

Re: inconsistent error handling in fgetln(3)

2016-08-24 Thread Andrey Chernov
On 24.08.2016 20:49, Ingo Schwarze wrote: >> Yes, it is a bit problematic, but it is the way this function >> designed in BSD 44lite, so I disagree with the patch. >> I.e. preserving partial line is more essential for it than >> returning no line at all (NULL), so tail error on partial line >> is n

Re: inconsistent error handling in fgetln(3)

2016-08-24 Thread Todd C. Miller
On Wed, 24 Aug 2016 19:49:47 +0200, Ingo Schwarze wrote: > See the improved patch below! Looks good. I wouldn't bother with an else after the break but if you think it reads better that way, that's fine with me. - todd

Re: inconsistent error handling in fgetln(3)

2016-08-24 Thread Ingo Schwarze
Hi Todd, hi Andrey, Todd C. Miller wrote on Wed, Aug 24, 2016 at 10:03:47AM -0600: > I'm probably not understanding something here No, i think yours is a great idea, i merely failed to think of it. > but why can't you just test for __SEOF in fp->_flags > when __srefill() returns non-zero > and

Re: inconsistent error handling in fgetln(3)

2016-08-24 Thread Andrey Chernov
On 24.08.2016 18:33, Ingo Schwarze wrote: > 2. The stdio read buffer is not empty at the time of the call > or the first __refill() succeeds, but then a subsequent __refill() > fails: > fgetln(3) returns a buffer containing the concatenation of all > strings that were returned by t

Re: inconsistent error handling in fgetln(3)

2016-08-24 Thread Todd C. Miller
I'm probably not understanding something here but why can't you just test for __SEOF in fp->_flags when __srefill() returns non-zero and treat the absence of __SEOF as an error? - todd

No 'struct route_in6' in ip6_getpmtu()

2016-08-24 Thread Martin Pieuchot
Diff below simplifies ip6_getpmtu() to use a 'struct rtentry *' instead of two 'struct route_in6'. ok? Index: netinet6/ip6_output.c === RCS file: /cvs/src/sys/netinet6/ip6_output.c,v retrieving revision 1.212 diff -u -p -r1.212 ip6_o

inconsistent error handling in fgetln(3)

2016-08-24 Thread Ingo Schwarze
Hi, what happens in fgetln(3) when the buffer runs out and reading more bytes fails before a newline character is found? There are two cases: 1. The stdio read buffer is empty at the time of the call, and the read(2) in __refill() fails: fgetln(3) returns NULL and sets errno and the std

armv7 pmap nodom

2016-08-24 Thread Artturi Alm
Hi, been running w/this on wandboard for some days building ports. pm_cstate should go too, but it's another small diff. -Artturi diff --git a/sys/arch/arm/arm/cpuswitch7.S b/sys/arch/arm/arm/cpuswitch7.S index 2eeecec..3196c8e 100644 --- a/sys/arch/arm/arm/cpuswitch7.S +++ b/sys/arch/arm/arm/c

Re: armv7 pmap: get rid if pmap_fault_fixup

2016-08-24 Thread Artturi Alm
On Wed, Aug 24, 2016 at 11:51:56AM +0200, Mark Kettenis wrote: > The pmap_fault_fixup() functions does a number of different fixups: > > 1. page modified emulation > > 2. page access emulation > > 3. entering level-1 entries for level-2 page tables > > Since it is a generic function that gets c

armv7 pmap: get rid if pmap_fault_fixup

2016-08-24 Thread Mark Kettenis
The pmap_fault_fixup() functions does a number of different fixups: 1. page modified emulation 2. page access emulation 3. entering level-1 entries for level-2 page tables Since it is a generic function that gets called for many fault types, it has to be careful to only enter mappings that are

splraise for pccbb(4)

2016-08-24 Thread David Gwynne
i noticed this when trying to figure out what level a cardslot would interrupt at. now we have splraise this is a lot more straightforward. avoiding an splraise when we're not sure whats actually lower than IPL_BIO is not worth the effort. splraise to a lower level is fine. ok? Index: pccbb.c =