On 2016-08-13 11:34, Theo de Raadt wrote:
I have to admit, it's a bit shocking that VOLTAGE REGULATORS have to
be
exposed to the software in the first place.
Just imagine a bug in some OS or firmware causing the voltages to
spike
up and fry the hell out of a device.
I guess that's modern-day
> I have to admit, it's a bit shocking that VOLTAGE REGULATORS have to be
> exposed to the software in the first place.
> Just imagine a bug in some OS or firmware causing the voltages to spike
> up and fry the hell out of a device.
>
> I guess that's modern-day hardware design for you.
No, tha
I have to admit, it's a bit shocking that VOLTAGE REGULATORS have to be
exposed to the software in the first place.
Just imagine a bug in some OS or firmware causing the voltages to spike
up and fry the hell out of a device.
I guess that's modern-day hardware design for you.
Mark Kettenis wrot
Mark Kettenis writes:
> With relro, certain bits of a process that were mapped into memory as
> writable are revreted back to read-only after making some initial
> changes. Since the kernel coredump code only writes out writable
> pieces of memory, these relro bits are not written out. Unfortun
Theo Buehler writes:
> Here's one final diff I have for jot for now:
>
> Use strchr(3) and strspn(3) instead of handrolled functions.
>
> Part of dsl@NetBSD's r1.20.
ok jca@
--
jca | PGP: 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
On Fri, Aug 12, 2016 at 2:56 PM, Mark Kettenis wrote:
> The diff below fixes that bu also dumping out all the bits that have
> an amap allocated. That's a sign that the pages are no longer
> pristine and have been written to.
>
> ok?
_There's_ the check, nice!
This would have affected dumping o
With relro, certain bits of a process that were mapped into memory as
writable are revreted back to read-only after making some initial
changes. Since the kernel coredump code only writes out writable
pieces of memory, these relro bits are not written out. Unfortunately
these bits contain essenti
On Fri, Aug 12, 2016 at 09:56:41PM +0200, fRANz wrote:
> On Sat, Aug 6, 2016 at 2:18 AM, William Ahern
> wrote:
> > isakmpd unconditionally sends NAT-T keepalive messages every 30 seconds,
> > whereas iked's ikev2_ike_sa_alive only sends a keepalive message iff
> > `!foundin && foundout`. But tha
Here's one final diff I have for jot for now:
Use strchr(3) and strspn(3) instead of handrolled functions.
Part of dsl@NetBSD's r1.20.
Index: jot.c
===
RCS file: /cvs/src/usr.bin/jot/jot.c,v
retrieving revision 1.33
diff -u -p -r1.3
The diff below adds a simple "regulator" API, Regulators are devices
that apply voltage and/or current to subsystems to power them on.
Examples are applying voltage to an SD card, powering a USB bus,
turning on an Ethernet PHY, scaling the CPU voltage. Regulators come
in many flavours. The simple
> Theo Buehler wrote:
> > Any comment, support or objection on this one?
> >
> > I'm aware that this diff is hard to review, but doing it in several
> > steps won't simplify the main step all that much, I think.
> >
> > The regression tests cover this part of the code quite well, I think.
>
> mo
Theo Buehler wrote:
> Any comment, support or objection on this one?
>
> I'm aware that this diff is hard to review, but doing it in several
> steps won't simplify the main step all that much, I think.
>
> The regression tests cover this part of the code quite well, I think.
move fast and break
Any comment, support or objection on this one?
I'm aware that this diff is hard to review, but doing it in several
steps won't simplify the main step all that much, I think.
The regression tests cover this part of the code quite well, I think.
- Forwarded message from Theo Buehler -
Da
> From: Martin Pieuchot
> Date: Fri, 12 Aug 2016 20:44:04 +0200
>
> On 08/11/16 06:43, David Gwynne wrote:
> > ive been tinkering with per cpu memory in the kernel
> > [...]
>
> I'd like to have more people comment on this because we need an MP-safe
> way to handle counters in the network stack.
On 08/11/16 06:43, David Gwynne wrote:
> ive been tinkering with per cpu memory in the kernel
> [...]
I'd like to have more people comment on this because we need an MP-safe
way to handle counters in the network stack.
> im still debating whether the API should do protection against
> interrupts
someone once said tech@ is where patches go and www@ is no longer
there...
Bye, Marcus
Index: 60.html
===
RCS file: /cvs/www/60.html,v
retrieving revision 1.47
diff -u -p -u -r1.47 60.html
--- 60.html 10 Aug 2016 13:49:33 -
The following diff makes httpd stricter with respect to TLS configuration:
- Do not allow TLS and non-TLS to be configured on the same port.
- Do not allow TLS options to be specified without a TLS listener.
- Ensure that TLS options are the same when a server is specified on the
same address/po
Fuse stores the vnode type in two places: vtype in struct fusefs_node
and v_type in struct vnode. Given the fact, that fusefs_node structs are
never allocated without an associated vnode and those two fields are
always in sync, one of those locations is superfluous.
Ok?
natano
Index: miscfs/fus
> Index: miscfs/fuse/fusefs_node.h
> ===
> RCS file: /cvs/src/sys/miscfs/fuse/fusefs_node.h,v
> retrieving revision 1.2
> diff -u -p -r1.2 fusefs_node.h
> --- miscfs/fuse/fusefs_node.h 1 Feb 2014 09:30:38 - 1.2
> +++ miscfs/f
David Gwynne wrote:
> i recently proposed replacing a hash with an rb tree somewhere in
> the network stack, but it was pointed out that rb trees are big.
>
> in hindsight i think the other person was talking about the size
> of an RB_ENTRY inside each thing you're tracking, but it made me
> look
IPv6 provides a dedicated range for documentation, so let's use it.
This is consistent with the IPv4 example.
ok?
Index: sshd_config.5
===
RCS file: /cvs/src/usr.bin/ssh/sshd_config.5,v
retrieving revision 1.227
diff -u -p -p -u -r1
On Fri, 08 Jul 2016 at 18:51:17 -0500, joshua stein wrote:
> If the EC fails to go into burst mode for whatever reason, the Burst
> Acknowledge byte will not be there to read, which means the status
> won't have EC_STAT_OBF, which means acpiec_wait will spin forever,
> hanging the machine.
>
> Thi
> Date: Fri, 12 Aug 2016 14:26:34 +0200
> From: Claudio Jeker
>
> On Fri, Aug 12, 2016 at 04:38:45PM +1000, David Gwynne wrote:
> >
> > > On 1 Aug 2016, at 21:07, Simon Mages wrote:
> > >
> > > I sent this message to dlg@ directly to discuss my modification of his
> > > diff to make the
> > >
On Fri, Aug 12, 2016 at 04:38:45PM +1000, David Gwynne wrote:
>
> > On 1 Aug 2016, at 21:07, Simon Mages wrote:
> >
> > I sent this message to dlg@ directly to discuss my modification of his
> > diff to make the
> > bigger mbuf clusters work. i got no response so far, thats why i
> > decided to
> From: David Gwynne
> Date: Fri, 12 Aug 2016 16:38:45 +1000
>
> > On 1 Aug 2016, at 21:07, Simon Mages wrote:
> >
> > I sent this message to dlg@ directly to discuss my modification of his
> > diff to make the
> > bigger mbuf clusters work. i got no response so far, thats why i
> > decided to
On Thu, Aug 11, 2016 at 10:48:59AM -0400, Ted Unangst wrote:
> Martin Natano wrote:
> > I'm already working on a diff to decouple fuse from ufs ihash. In the
> > meantime: Make sure the necessary code is compiled in when fuse is
> > enabled in the config.
>
> Are people building kernels with FFS?
this updates the diff after the SLIST changes in uvm.
On Thu, Aug 11, 2016 at 10:19:20AM +1000, David Gwynne wrote:
> i recently proposed replacing a hash with an rb tree somewhere in
> the network stack, but it was pointed out that rb trees are big.
>
> in hindsight i think the other person was
On 2016-06-23 05:42, Theo de Raadt wrote:
secondly, allocating more than 4g at a time to socket buffers is
generally a waste of memory.
and there is one further problem.
Eventually, this subsystem will starve the system. Other subsystems
which also need large amounts of memory, then have to s
28 matches
Mail list logo
