On Thu Jan 23, 2020 at 3:05 AM, Claudio Jeker wrote:
> On Thu, Jan 23, 2020 at 10:48:06AM +0900, Lee B wrote:
> >
> > OK, the umb_softc part was straightforward enough, thanks. I'd like
> > some advice on how to handle the ifconfig(8) changes to accomodate
> > this though. I see the wifi code
On Tue Jan 14, 2020 at 5:59 PM, Claudio Jeker wrote:
>
> Since the credentials should not be passed back to userland I would not
> add them to struct umb_parameter but instead to struct umb_softc.
> Then you don't need to use struct umb_parameter for the ioctl and
> instead
> could just pass the
On Tue, Jan 21, 2020, at 7:10 PM, Mark Kettenis wrote:
> The attached diff fixes amdgpu(4) and might very well fix radeondrm(4)
> as well.
[...]
For the record, this fixes running piglit with radeon on my HD7570 since this
was committed. It used to lock up on the test spec/arb_sync/sync_api,
ok?
When isakmpd's main process dies abnormally, currently its "monitor"
process exits with status 0. Fix it to use the exit status of main
process.
Index: sbin/isakmpd/monitor.c
===
RCS file:
On Thu, 23 Jan 2020, Damien Miller wrote:
> On Wed, 22 Jan 2020, Stuart Henderson wrote:
>
> > On 2020/01/21 15:39, Damien Miller wrote:
> > > CVSROOT: /cvs
> > > Module name: src
> > > Changes by: d...@cvs.openbsd.org2020/01/21 15:39:57
> > >
> > > Modified files:
> > >
On Thu, Jan 23, 2020 at 10:48:06AM +0900, Lee B wrote:
> On Tue Jan 14, 2020 at 5:59 PM, Claudio Jeker wrote:
> >
> > Since the credentials should not be passed back to userland I would not
> > add them to struct umb_parameter but instead to struct umb_softc.
> > Then you don't need to use struct
Sleep for the same duration as the delay(9) in the cold path.
ok?
Index: pv/hyperv.c
===
RCS file: /cvs/src/sys/dev/pv/hyperv.c,v
retrieving revision 1.44
diff -u -p -r1.44 hyperv.c
--- pv/hyperv.c 7 Oct 2019 15:36:01 -
On Thu, Jan 23, 2020 at 02:36:43PM +1100, Damien Miller wrote:
> On Wed, 22 Jan 2020, Stuart Henderson wrote:
>
> > On 2020/01/21 15:39, Damien Miller wrote:
> > > CVSROOT: /cvs
> > > Module name: src
> > > Changes by: d...@cvs.openbsd.org2020/01/21 15:39:57
> > >
> > > Modified
On Wed, Jan 22, 2020 at 05:02:32AM +0100, Claudio Jeker wrote:
> 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
Hi,
this is the second attempt of a diff that prepares acpivout(4) to work
with the X395. The previous one broke due to recursive ACPI locking.
So apparently we cannot change the brightness using the acpivout(4) ACPI
methods. Instead we need to call amdgpu(4) to change the brightness.
But the
On Wed, Dec 18, 2019 at 03:28:48PM -0600, Brad DeMorrow wrote:
> This is a rather large patch that moves my previously submitted
> VA-API ports into xenocara. For your convenience, I've inlined
> a diff that shows you all of the changes I made to existing files
> that you can easily read in your
Ticks to milliseconds.
ok?
Index: i2c/ihidev.c
===
RCS file: /cvs/src/sys/dev/i2c/ihidev.c,v
retrieving revision 1.21
diff -u -p -r1.21 ihidev.c
--- i2c/ihidev.c31 Jul 2019 16:09:12 - 1.21
+++ i2c/ihidev.c23
On Wed, 22 Jan 2020, Stuart Henderson wrote:
> On 2020/01/21 15:39, Damien Miller wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: d...@cvs.openbsd.org2020/01/21 15:39:57
> >
> > Modified files:
> > usr.bin/ssh: sshd.c
> >
> > Log message:
> > expose the
You're right, this diff does some massive pointer juggling that I
overlooked.
I'll drop the diff.
On 1/22/20 10:59 AM, Otto Moerbeek wrote:
> On Wed, Jan 22, 2020 at 10:51:45AM +0100, Martijn van Duren wrote:
>
>> Trying to wrap my head around some of the snmpd code I found this pearl
>> that
Hello, Florian,
Apologies for the delay in my response. I was mostly off-line for the
last ten days or so. Inn-line
On 10/1/20 03:56, Florian Obser wrote:
Hi Fernando,
On Thu, Jan 09, 2020 at 08:49:15AM -0300, Fernando Gont wrote:
Hi, Pamela,
[]
Just happened to see this (sorry
Trying to wrap my head around some of the snmpd code I found this pearl
that appears to do nothing more than warm up the room.
OK?
martijn@
Index: Makefile
===
RCS file: /cvs/src/usr.sbin/snmpd/Makefile,v
retrieving revision 1.16
Hello,
sorry for typo in my earlier mail.
> cd sys/arch/`uname -p`/conf
> echo 'option WIT_PF_LOCK' >> GENERIC.MP
> config GENERIC.MP
> cd ../compile/GENERIC.MP/
> make clean
> make
do s/WIT_PF_LOCK/WITH_PF_LOCK in the snippet above.
my apologize.
On Wed, Jan 22, 2020 at 10:51:45AM +0100, Martijn van Duren wrote:
> Trying to wrap my head around some of the snmpd code I found this pearl
> that appears to do nothing more than warm up the room.
Do you really want to get rid of the init of snmpd_env->sc_cpustates ?
-Otto
>
> OK?
>
On Tue, Jan 21, 2020 at 12:31:52PM +0100, Martin Pieuchot wrote:
> 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.
>
On 2020/01/21 15:39, Damien Miller wrote:
> CVSROOT: /cvs
> Module name: src
> Changes by: d...@cvs.openbsd.org2020/01/21 15:39:57
>
> Modified files:
> usr.bin/ssh: sshd.c
>
> Log message:
> expose the number of currently-authenticating connections
> along with the
Just like dt(4) or mem(4), ksyms(4) allows userland to read kernel
addresses.
Diff below makes `allowkmem' a requirement for opening the
pseudo-device.
ok?
Index: sys/dev/ksyms.c
===
RCS file: /cvs/src/sys/dev/ksyms.c,v
retrieving
On Wed, Jan 22, 2020 at 12:44:18AM -0500, Ted Unangst wrote:
> 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:
Major 30 is taken on both platforms, so use 32 to give a chance for
people to use dt(4) and btrace(8) on these platforms.
Ok?
===
RCS file: /cvs/src/etc/etc.alpha/MAKEDEV.md,v
retrieving revision 1.72
diff -u -p -r1.72 MAKEDEV.md
dt(4) is a debugging interface that allows userland to read kernel
addresses. So its access should be restricted by default, just like
mem(4).
Diff prevent opening the pseudo-device unless `allowkmem' is set.
ok?
Index: sys/dev/dt/dt_dev.c
I guess this needs to be changed again, to retain more info from the
original title.
Stuart Henderson wrote:
> On 2020/01/21 15:39, Damien Miller wrote:
> > CVSROOT:/cvs
> > Module name:src
> > Changes by: d...@cvs.openbsd.org2020/01/21 15:39:57
> >
> > Modified files:
> >
Hi,
I think we've (or at least I have) mused about this for a while; a
recent mail reminded me that this feature should go - a window manager
doesn't need to parse the ssh known_hosts file for a menu; there are
better tools for this.
Remove menu-ssh.
okay?
Index: calmwm.h
On Wed, Jan 22, 2020 at 03:15:37PM -0500, Okan Demirmen wrote:
> Hi,
>
> I think we've (or at least I have) mused about this for a while; a
> recent mail reminded me that this feature should go - a window manager
> doesn't need to parse the ssh known_hosts file for a menu; there are
> better
On Wed, 22 Jan 2020 15:12:25 +0100, Martin Pieuchot wrote:
> dt(4) is a debugging interface that allows userland to read kernel
> addresses. So its access should be restricted by default, just like
> mem(4).
>
> Diff prevent opening the pseudo-device unless `allowkmem' is set.
Does it really
On Wed, 22 Jan 2020 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
On Wed, 22 Jan 2020 15:17:32 +0100, Martin Pieuchot wrote:
> Just like dt(4) or mem(4), ksyms(4) allows userland to read kernel
> addresses.
>
> Diff below makes `allowkmem' a requirement for opening the
> pseudo-device.
Won't this break everything that uses /dev/ksyms? The default for
Hi,
Disclaimer: I don't have such hardware to test with or without the diff below,
but I think if we add this change in any shape or form then we should add this
as well otherwise we could bump into the vuln [0] that Ilja found on NetBSD
which could leak the credentials.
[0]
Todd C. Miller wrote:
> On Wed, 22 Jan 2020 15:17:32 +0100, Martin Pieuchot wrote:
>
> > Just like dt(4) or mem(4), ksyms(4) allows userland to read kernel
> > addresses.
> >
> > Diff below makes `allowkmem' a requirement for opening the
> > pseudo-device.
>
> Won't this break everything that
On Wed, Jan 22, 2020 at 03:15:37PM -0500, Okan Demirmen wrote:
> Remove menu-ssh.
OK kn
Todd C. Miller wrote:
> On Wed, 22 Jan 2020 15:12:25 +0100, Martin Pieuchot wrote:
>
> > dt(4) is a debugging interface that allows userland to read kernel
> > addresses. So its access should be restricted by default, just like
> > mem(4).
> >
> > Diff prevent opening the pseudo-device unless
oops, no kidding, otherwise it is the older value.
Matthew Martin wrote:
> On Wed, Jan 22, 2020 at 12:44:18AM -0500, Ted Unangst wrote:
> > should not size the size until the allocation succeeds, or the free path
> > will
> > try to deref the null array.
> >
> >
> > Index: json.c
> >
Hello All,
Just to let you know that someone has posted on twitter in
German that they are giving away aload of Unix Gear,
some Sun Sparc stuff in there that may be of use to
people who are supporting or trying to do builds
it was re-tweeted by Philip Jocks, and it is in German,
but you can
Mark Kettenis wrote:
> Theo de Raadt schreef op 2020-01-22 23:20:
> > this is not actually surprising. there are only about 3 majors
> > which can't
> > move around without problem. It is a MD detail, which is why tables
> > have
> > to know about it
> >
> > ok
>
> I sometimes wish we'd split
On Tue, Jan 21, 2020 at 12:31:52PM +0100, Martin Pieuchot wrote:
> New diff that works with 82576, previous breakage reported by Hrvoje
> Popovski. So far the following models have been tested, I'm looking for
> more tests :o)
>
> em3 at pci2 dev 0 function 0 "Intel 82571EB" rev 0x06: apic 0
this is not actually surprising. there are only about 3 majors which can't
move around without problem. It is a MD detail, which is why tables have
to know about it
ok
Martin Pieuchot wrote:
> Major 30 is taken on both platforms, so use 32 to give a chance for
> people to use dt(4) and
Matthew Martin wrote:
> On Wed, Jan 22, 2020 at 12:44:18AM -0500, Ted Unangst wrote:
> > should not size the size until the allocation succeeds, or the free path
> > will
> > try to deref the null array.
> >
> >
> > Index: json.c
> >
Todd C. Miller schreef op 2020-01-22 17:25:
On Wed, 22 Jan 2020 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
Theo de Raadt schreef op 2020-01-22 23:20:
this is not actually surprising. there are only about 3 majors which
can't
move around without problem. It is a MD detail, which is why tables
have
to know about it
ok
I sometimes wish we'd split the majors into MI and MD "ranges", but
that'd
On Wed, 22 Jan 2020 14:55:08 -0700, "Theo de Raadt" wrote:
> You can see where an object would be, but you can't read the object.
> This is unlike dt where you can see the object and via parameter
> inspection deeply reason about the value plaed at object addresses.
>
> However, the permissions
Now that we've separated the sleeping path and the busy-waiting path
we can remove the ticks.
"i" is a count of milliseconds here. Convert it to a timespec to
get a starting interval "ts" and add that to the current time "now"
to get an absolute timeout "end".
Then we chip away at it as we loop
44 matches
Mail list logo
