Re: pipex(4): kill pipexintr()

2020-07-31 Thread Vitaliy Makkoveev
On Fri, Jul 31, 2020 at 10:25:48PM +0200, Martin Pieuchot wrote: > On 31/07/20(Fri) 21:58, Vitaliy Makkoveev wrote: > > [...] > > What denies us to move pipex(4) under it's own lock? > > Such question won't lead us anywhere. It assumes it makes sense to move > pipex under its own lock. This ass

Re: pipex(4): kill pipexintr()

2020-07-31 Thread Martin Pieuchot
On 31/07/20(Fri) 21:58, Vitaliy Makkoveev wrote: > [...] > What denies us to move pipex(4) under it's own lock? Such question won't lead us anywhere. It assumes it makes sense to move pipex under its own lock. This assumption has many drawback which clearly haven't been studied and more importa

Re: pipex(4): kill pipexintr()

2020-07-31 Thread Vitaliy Makkoveev
Well, since pipexintr() killing was rejected, I propose to implement reference counters to protect pipex(4) session itself. Diff below does this. Index: sys/net/if_ethersubr.c === RCS file: /cvs/src/sys/net/if_ethersubr.c,v retrieving

Re: pipex(4): kill pipexintr()

2020-07-31 Thread Vitaliy Makkoveev
On Fri, Jul 31, 2020 at 08:26:22PM +0200, Martin Pieuchot wrote: > On 31/07/20(Fri) 12:15, Vitaliy Makkoveev wrote: > > On Fri, Jul 31, 2020 at 09:36:32AM +0900, YASUOKA Masahiko wrote: > > > On Thu, 30 Jul 2020 22:43:10 +0300 > > > Vitaliy Makkoveev wrote: > > > > On Thu, Jul 30, 2020 at 10:05:13

Re: pipex(4): kill pipexintr()

2020-07-31 Thread Martin Pieuchot
On 31/07/20(Fri) 12:15, Vitaliy Makkoveev wrote: > On Fri, Jul 31, 2020 at 09:36:32AM +0900, YASUOKA Masahiko wrote: > > On Thu, 30 Jul 2020 22:43:10 +0300 > > Vitaliy Makkoveev wrote: > > > On Thu, Jul 30, 2020 at 10:05:13PM +0900, YASUOKA Masahiko wrote: > > >> On Thu, 30 Jul 2020 15:34:09 +0300

xhci(4): fix for usbd_start_next: error=13

2020-07-31 Thread Marcus Glocker
When playing around with uvideo(4) devices I'm quite regular hitting the error message in the subject when closing the device. The problem seems to be some false return code ordering in xhci_device_isoc_start(): if (sc->sc_bus.dying || xp->halted) return (USBD_IOERROR); /* Why would you

Re: usbd_abort_pipe(); usbd_close_pipe; dance

2020-07-31 Thread Martin Pieuchot
On 31/07/20(Fri) 11:22, Marcus Glocker wrote: > Maybe I'm missing something here. You aren't. Historically usbd_close_pipe() wasn't aborting transfers. We changed it to do so as it happened to be the easiest fix to some issues that had been copy/pasted. It's just that nobody took the time to do

Re: cat(1): add more restrictive pledge(2)

2020-07-31 Thread Theo de Raadt
As a general rule, pledge uses isn't supposed to make programs more complicated. Stuart Henderson wrote: > On 2020/07/31 00:07, tempmai...@firemail.cc wrote: > > I have to say I'm only a beginner to C but hopefully my patch is > > good. > > > > This patch adds a second and more restrictive pled

Re: usbd_abort_pipe(); usbd_close_pipe; dance

2020-07-31 Thread Marcus Glocker
On Fri, 31 Jul 2020 11:59:45 +0200 Gerhard Roth wrote: > Hi Marcus, > > On 2020-07-31 11:22, Marcus Glocker wrote: > > Maybe I'm missing something here. > > > > But is there any specific reason why the most of our USB drivers are > > calling usbd_abort_pipe() right before usbd_close_pipe()? Si

Re: usbd_abort_pipe(); usbd_close_pipe; dance

2020-07-31 Thread Gerhard Roth
Hi Marcus, On 2020-07-31 11:22, Marcus Glocker wrote: Maybe I'm missing something here. But is there any specific reason why the most of our USB drivers are calling usbd_abort_pipe() right before usbd_close_pipe()? Since usbd_close_pipe() already will call usbd_abort_pipe() if the pipe isn't e

usbd_abort_pipe(); usbd_close_pipe; dance

2020-07-31 Thread Marcus Glocker
Maybe I'm missing something here. But is there any specific reason why the most of our USB drivers are calling usbd_abort_pipe() right before usbd_close_pipe()? Since usbd_close_pipe() already will call usbd_abort_pipe() if the pipe isn't empty, as documented in the man page: DESCRIPTION Th

Re: pipex(4): kill pipexintr()

2020-07-31 Thread Vitaliy Makkoveev
On Fri, Jul 31, 2020 at 09:36:32AM +0900, YASUOKA Masahiko wrote: > On Thu, 30 Jul 2020 22:43:10 +0300 > Vitaliy Makkoveev wrote: > > On Thu, Jul 30, 2020 at 10:05:13PM +0900, YASUOKA Masahiko wrote: > >> On Thu, 30 Jul 2020 15:34:09 +0300 > >> Vitaliy Makkoveev wrote: > >> > On Thu, Jul 30, 2020

Re: cat(1): add more restrictive pledge(2)

2020-07-31 Thread Stuart Henderson
On 2020/07/31 00:07, tempmai...@firemail.cc wrote: > I have to say I'm only a beginner to C but hopefully my patch is > good. > > This patch adds a second and more restrictive pledge (only "stdio" > instead of "stdio rpath") after the getopt loop if there is no > input file or if the input file is

ifconfig: print tpmr(4) members

2020-07-31 Thread Klemens Nanni
This diff is to be applied on top of my other diff on tech@ with subject "ifconfig: merge switch_status() into bridge_status()". It hooks completes the output of tpmr intefaces in what I think is the simplest and least intrusive way. tpmr is a trivial bridge and has no specific ioctls, so to dist