On Wed, Jan 22, 2020 at 01:05:31AM -0500, Ted Unangst wrote:
> don't need semicolon after } in statements.
OK claudio@
>
> Index: ifconfig/brconfig.c
> ===
> RCS file: /home/cvs/src/sbin/ifconfig/brconfig.c,v
> retrieving revision 1
don't need semicolon after } in statements.
Index: ifconfig/brconfig.c
===
RCS file: /home/cvs/src/sbin/ifconfig/brconfig.c,v
retrieving revision 1.24
diff -u -p -r1.24 brconfig.c
--- ifconfig/brconfig.c 24 Oct 2019 18:54:10 -
On Wed, Jan 22, 2020 at 12:56:00AM +0100, Claudio Jeker wrote:
> On Tue, Jan 21, 2020 at 03:58:58PM +0100, Remi Locherer wrote:
> > On Tue, Jan 21, 2020 at 01:09:30PM +0100, Denis Fondras wrote:
> > > On Tue, Jan 21, 2020 at 09:35:06AM +0100, Remi Locherer wrote:
> > > > > @@ -235,6 +233,7 @@ lsa_c
should not size the size until the allocation succeeds, or the free path will
try to deref the null array.
Index: json.c
===
RCS file: /home/cvs/src/usr.sbin/acme-client/json.c,v
retrieving revision 1.14
diff -u -p -r1.14 json.c
---
Karel Gardas wrote:
>
>
> On 1/21/20 2:33 AM, Claudio Jeker wrote:
> > Please test this since I can't test this properly at the moment.
>
> Would like to, but all hunks fail on today current:
it's been committed.
fine.
Ted Unangst wrote:
> Scott Cheloha wrote:
> > > 1) it isn't documented that + can take a smaller number
> > > 2) it will be hard to train people to use +0001
> >
> > These are my concerns as well.
> >
> > An idea I had a while back was to drop support for +hhmm and just
> > support +minu
Scott Cheloha wrote:
> > 1) it isn't documented that + can take a smaller number
> > 2) it will be hard to train people to use +0001
>
> These are my concerns as well.
>
> An idea I had a while back was to drop support for +hhmm and just
> support +minutes, like we do with shutdown(8). The invoc
This diff implements 'max-prefix NUM out' which is a simple way to avoid
leaking full tables to upstream or peers. If the limit is triggered the
session will be closed with a NOTIFICATION (kind of suicide for the good
of the Internet).
In bgpctl the counters are visible in the 'bgpctl show nei' ou
On Wed, 22 Jan 2020 at 03:10:01 +0100, Mark Kettenis wrote:
> The attached diff fixes amdgpu(4) and might very well fix radeondrm(4) as
> well. The problems with the hardware cursor are gone, various screen
> corruptions no longer seem to happen and the laptop I have here suspends and
> resumes no
Scott Cheloha wrote:
> On Tue, Jan 21, 2020 at 07:23:43PM -0700, Theo de Raadt wrote:
> > I suspect this breaks an usage case which is not documented.
> >
> > People may be doing leave +1 to mean "1 minutes".
> >
> > % leave +1
> > Alarm set for Tue Jan 21 19:23. (pid 55602)
> > % date
> > Tue
Scott Cheloha wrote:
> On Tue, Jan 21, 2020 at 07:23:43PM -0700, Theo de Raadt wrote:
> > I suspect this breaks an usage case which is not documented.
> >
> > People may be doing leave +1 to mean "1 minutes".
> >
> > % leave +1
> > Alarm set for Tue Jan 21 19:23. (pid 55602)
> > % date
> > Tue
On Tue, Jan 21, 2020 at 07:23:43PM -0700, Theo de Raadt wrote:
> I suspect this breaks an usage case which is not documented.
>
> People may be doing leave +1 to mean "1 minutes".
>
> % leave +1
> Alarm set for Tue Jan 21 19:23. (pid 55602)
> % date
> Tue Jan 21 19:22:32 MST 2020
> % Just one mor
The attached diff fixes amdgpu(4) and might very well fix radeondrm(4)
as well. The problems with the hardware cursor are gone, various screen
corruptions no longer seem to happen and the laptop I have here suspends
and resumes now.
I still occasionally see some glitches playing youtube videos,
If you look at the for-loop in ciss_cmd() you can see that there are
really two loops. One for SCSI_NOSLEEP with delay(9), the other with
tsleep(9). The two paths basically don't interact, they merely happen
to share the loop.
If we pull the if-else out of the loop and give each clause its own
f
I suspect this breaks an usage case which is not documented.
People may be doing leave +1 to mean "1 minutes".
% leave +1
Alarm set for Tue Jan 21 19:23. (pid 55602)
% date
Tue Jan 21 19:22:32 MST 2020
% Just one more minute!
1) it isn't documented that + can take a smaller number
2) it will be
In testing leave, I found it accepts "12" and will alarm at 00:12, which is
probably not desirable. this check thats the specified time has 4 digits so
that the hour/minute math works properly.
Index: leave.c
===
RCS file: /home/cvs/
Rewrite some of the page to avoid second person.
Index: leave.1
===
RCS file: /home/cvs/src/usr.bin/leave/leave.1,v
retrieving revision 1.16
diff -u -p -r1.16 leave.1
--- leave.1 13 Jul 2018 16:59:46 - 1.16
+++ leave.1
On Mon, Dec 23, 2019 at 01:26:34PM -0600, Scott Cheloha wrote:
> hz/4 -> 250ms.
>
> ok?
1mo bump.
> Index: w83l518d_sdmmc.c
> ===
> RCS file: /cvs/src/sys/dev/ic/w83l518d_sdmmc.c,v
> retrieving revision 1.4
> diff -u -p -r1.4 w83l51
On Mon, Dec 23, 2019 at 01:23:28PM -0600, Scott Cheloha wrote:
> 1/16 seconds is exactly 62500 microseconds.
>
> ok?
1mo bump.
> Index: arch/hppa/hppa/autoconf.c
> ===
> RCS file: /cvs/src/sys/arch/hppa/hppa/autoconf.c,v
> retrievin
David Gwynne wrote:
> > On 22 Jan 2020, at 8:54 am, Damien Miller wrote:
> >
> > On Wed, 22 Jan 2020, David Gwynne wrote:
> >
> >>> Index: sys/kern/kern_pledge.c
> >>> ===
> >>> RCS file: /cvs/src/sys/kern/kern_pledge.c,v
> >>> re
> On 22 Jan 2020, at 8:54 am, Damien Miller wrote:
>
> On Wed, 22 Jan 2020, David Gwynne wrote:
>
>>> Index: sys/kern/kern_pledge.c
>>> ===
>>> RCS file: /cvs/src/sys/kern/kern_pledge.c,v
>>> retrieving revision 1.255
>>> diff -u
I am a big grumpy about /etc/protocols becoming another file that
is bypassed (accepted transparently) in kernel pledge. but dlg
has convinced me hardcoding would be worse.
Hello,
below is a diff, which makes pfsync(4) more pf_lock friendly. The diff is
sitting in my tree for some time. Hrvoje did some preliminary testing already.
He could trigger some sparks and smoke, which I could put off. However don't
get too much excited about the change yet. At this phase I r
On Tue, Jan 21, 2020 at 03:58:58PM +0100, Remi Locherer wrote:
> On Tue, Jan 21, 2020 at 01:09:30PM +0100, Denis Fondras wrote:
> > On Tue, Jan 21, 2020 at 09:35:06AM +0100, Remi Locherer wrote:
> > > > @@ -235,6 +233,7 @@ lsa_check(struct rde_nbr *nbr, struct ls
> > > > case LSA_TYPE_NETWO
Hi,
I think that is a good idea.
On Wed, 22 Jan 2020 08:35:05 +1000
David Gwynne wrote:
> Has anyone got an opinion on this? I am still interested in doing more
> packet capture things on OpenBSD using GRE as a transport, and the idea
> of maintaining this out of tree just makes me feel tired.
>
On Wed, 22 Jan 2020, David Gwynne wrote:
> Has anyone got an opinion on this? I am still interested in doing more
> packet capture things on OpenBSD using GRE as a transport, and the idea
> of maintaining this out of tree just makes me feel tired.
This is cool. I don't spot any major problems wit
Has anyone got an opinion on this? I am still interested in doing more
packet capture things on OpenBSD using GRE as a transport, and the idea
of maintaining this out of tree just makes me feel tired.
On Tue, Oct 29, 2019 at 06:34:50PM +1000, David Gwynne wrote:
> i've been toying with this idea o
Ted Unangst wrote:
> MarcusMüller wrote:
> > I've just stumbled across a malfunction in signify: It cannot handle
> > file names that contain a `)` character, when checking a list of hashes
> > generated by `sha256` command line utilities (`sha256sum --tags` on
> > Linux).
>
> This fix is unfortu
On Tue, Jan 21, 2020 at 10:55:47PM +0100, Klemens Nanni wrote:
> This shows that mem(4) can be opened at "Secure mode" even though
> securelevel(7) says it cannot.
Rebooting with allowkmem unset shows that /dev/mem cannot be opened at
all:
# kern.securelevel kern.allowkmem
kern.sec
On Mon, Jan 20, 2020 at 04:41:42PM -0700, Theo de Raadt wrote:
> The test is:
>
> switch (minor(dev)) {
> case 0:
> case 1:
> if (securelevel <= 0 || allowkmem)
> break;
> return (EPERM);
>
> Maybe
> /dev/mem an
On 1/21/20 2:33 AM, Claudio Jeker wrote:
Please test this since I can't test this properly at the moment.
Would like to, but all hunks fail on today current:
solo$ patch < /tmp/piixpm.patch
Hmm... Looks like a unified diff to me...
The text leading up to this was:
-
>> While discussing recent config_detach(9) vs close(2) race I figured
>> out that the 'indirect' flag (`cd_indirect') is never set.
Some struct cfdriver initialize it to 1. See isa_cd in
sys/dev/isa/isa.c.
>> Time to kill this feature?
Please don't.
On Tue, Jan 21, 2020 at 01:09:30PM +0100, Denis Fondras wrote:
> On Tue, Jan 21, 2020 at 09:35:06AM +0100, Remi Locherer wrote:
> > > @@ -235,6 +233,7 @@ lsa_check(struct rde_nbr *nbr, struct ls
> > > case LSA_TYPE_NETWORK:
> > > if ((len % sizeof(u_int32_t)) ||
> > > len
Scott Cheloha writes:
> Given the SCSI_NOSLEEP split here I think the simplest thing we can do
> is ask to sleep as much as we delay(9).
>
> The question is: if you *could* poll in 10us intervals here with
> tsleep_nsec(9), would you want to? If so, then this works. If
> not, what is a more ap
On 16/01/20(Thu) 11:20, Martin Pieuchot wrote:
> While discussing recent config_detach(9) vs close(2) race I figured
> out that the 'indirect' flag (`cd_indirect') is never set.
>
> Time to kill this feature?
>
> This survived build on x86, armv7, sgi, hppa, luna88k, alpha, landisk,
> sparc64.
>
On Tue, Jan 21, 2020 at 09:35:06AM +0100, Remi Locherer wrote:
> > @@ -235,6 +233,7 @@ lsa_check(struct rde_nbr *nbr, struct ls
> > case LSA_TYPE_NETWORK:
> > if ((len % sizeof(u_int32_t)) ||
> > len < sizeof(lsa->hdr) + sizeof(u_int32_t)) {
> > + l
> On 21 Jan 2020, at 11:57, Stefan Sperling wrote:
>
> On Tue, Jan 21, 2020 at 11:34:28AM +0100, Mischa wrote:
>> Hi All,
>>
>> I have an APU2 with a iwm card which keeps on acting up on a regular basis.
>>
>> apu2# dmesg | grep iwm
>> iwm0 at pci1 dev 0 function 0 "Intel Dual Band Wireless
On Tue, Jan 21, 2020 at 09:41:28AM +0100, Remi Locherer wrote:
> On Mon, Jan 20, 2020 at 05:08:26PM +0100, Denis Fondras wrote:
> > On Sun, Jan 19, 2020 at 11:04:16PM +0100, Remi Locherer wrote:
> > > This makes the interface setting "type p2p" configurable globally or
> > > per area. ospf(6)d allo
On 20/01/20(Mon) 16:42, Martin Pieuchot wrote:
> Diff below is a refactoring of the actual em(4) code and defines that
> will allows me to present a shorter diff to interrupt multiple CPUs and
> make use of multiple queues.
>
> It contains the following items:
>
> - Abstract the allocation/free
claudio and i have been looking at some tun(4) semantics, and want to
move stuff around, but feel constrained because PIPEX has been very
carefully added to tun(4). the PIPEX bits make it hard to rearrange
tun(4), so this moves that functionality out into a separate driver
called pppac(4).
there's
On Tue, Jan 21, 2020 at 11:34:28AM +0100, Mischa wrote:
> Hi All,
>
> I have an APU2 with a iwm card which keeps on acting up on a regular basis.
>
> apu2# dmesg | grep iwm
> iwm0 at pci1 dev 0 function 0 "Intel Dual Band Wireless AC 7260" rev 0x73, msi
> iwm0: hw rev 0x140, fw ver 17.3216344376.
Hi All,
I have an APU2 with a iwm card which keeps on acting up on a regular basis.
apu2# dmesg | grep iwm
iwm0 at pci1 dev 0 function 0 "Intel Dual Band Wireless AC 7260" rev 0x73, msi
iwm0: hw rev 0x140, fw ver 17.3216344376.0, address f8:16:54:06:b9:a9
After the APU has booted properly it fai
On Tue, Jan 21, 2020 at 09:31:36AM +0100, Claudio Jeker wrote:
> So the 'Last error:' message for sessions that failed do often not include
> the suberror and also it is only shown for NOTIFICATIONS we sent but not
> for received notifications. The following diff fixes this.
>
> So instead of:
>
So I did a full bulk build with the following diff.
No failure due to old keyword.
This contains exactly:
- abort directly instead of setting pgn->must_make = false
- tag as "SPECIAL_DEPRECATED" all old keywords
- remove the conditionals with those OP. We just keep OP_INVISIBLE because
it's actua
On Mon, Jan 20, 2020 at 05:08:26PM +0100, Denis Fondras wrote:
> On Sun, Jan 19, 2020 at 11:04:16PM +0100, Remi Locherer wrote:
> > This makes the interface setting "type p2p" configurable globally or
> > per area. ospf(6)d allows this for almost all interface related settings.
> >
> > As a side-e
On Mon, Jan 20, 2020 at 05:03:34PM +0100, Denis Fondras wrote:
> No need to pass peerid to lsa_snap()
>
> While at it, remove unused variable.
ok iremi@ with a small comment below.
>
> Index: rde.c
> ===
> RCS file: /cvs/src/usr.sb
So the 'Last error:' message for sessions that failed do often not include
the suberror and also it is only shown for NOTIFICATIONS we sent but not
for received notifications. The following diff fixes this.
So instead of:
Last error: Cease
or
Last error: unknown error code
I now get:
Last e
47 matches
Mail list logo
