On Wed, Sep 14, 2016 at 02:46:27PM +1000, David Gwynne wrote:
> Yes, this is just a conservative first step to that.
OK on the first step. I hope more follow :)
> On 14 Sep 2016 12:00 p.m., "Todd C. Miller"
> wrote:
>
> > Looks OK. Do you intend to change m_copym0 to m_copym and remove
> > th
Yes, this is just a conservative first step to that.
On 14 Sep 2016 12:00 p.m., "Todd C. Miller"
wrote:
> Looks OK. Do you intend to change m_copym0 to m_copym and remove
> the deep copy code?
>
> - todd
>
On Tue, Sep 13, 2016 at 01:29:17PM +0200, Otto Moerbeek wrote:
> As often, real life came in between. Did anybody do measurements? I
> really would like to to see hard data.
It seems that the price is relatively modest.
I ran several 'make build's:
3rd gen X1, i7 5500U, 2.4GHz (amd64):
On Wed, Sep 07, 2016 at 06:29:07PM -0400, Ted Unangst wrote:
> There's some overlap here with canaries, but nothing wrong with that. :)
The diff breaks canaries since random_junk() overwrites them before they
are validated. The following straightforward modification fixes that:
> Index: malloc.c
Looks OK. Do you intend to change m_copym0 to m_copym and remove
the deep copy code?
- todd
> On 14 Sep 2016, at 11:08, David Gwynne wrote:
>
> ok?
>
> Index: sys/arch/amd64/conf/GENERIC
> ===
> RCS file: /cvs/src/sys/arch/amd64/conf/GENERIC,v
> retrieving revision 1.433
> diff -u -p -r1.433 GENERIC
> --- sys/arch/amd64/c
ok?
Index: share/man/man9/mbuf.9
===
RCS file: /cvs/src/share/man/man9/mbuf.9,v
retrieving revision 1.103
diff -u -p -r1.103 mbuf.9
--- share/man/man9/mbuf.9 13 Sep 2016 19:56:55 - 1.103
+++ share/man/man9/mbuf.9
> On 13 Sep 2016, at 19:37, Martin Pieuchot wrote:
>
> Doing...
>
> # ifconfig axen0 lladdr bla
>
> is currently broken because we don't update the MAC address in the
> driver, which makes the chip drop all the packets unless in promisc
> mode.
>
> Diff below fixes that, ok?
Currently, innetgr(3) will return false if all of user, host and
domain are specified, even if the tuple would otherwise match.
The commented assumption "If a domainname is given, we would have
found a match" is simply not true.
I also moved the strdup after the "Too bad need the slow recursive
w
On Tue, Sep 13, 2016 at 06:35:08PM +0200, Martin Natano wrote:
> Currently pkg-config files are generated at install time, while they
> should be generated at build time like everything else. One reason why
> generating files during install is bad is that the two steps might be
> run by two differn
Currently pkg-config files are generated at install time, while they
should be generated at build time like everything else. One reason why
generating files during install is bad is that the two steps might be
run by two differnt users, resulting in permission problems.
While there I removed the d
On Tue, 13 Sep 2016 12:25:58 -0400, "Ted Unangst" wrote:
> convert two if else if chains to switches.
OK millert@
- todd
convert two if else if chains to switches.
Index: base64.c
===
RCS file: /cvs/src/usr.sbin/acme-client/base64.c,v
retrieving revision 1.5
diff -u -p -r1.5 base64.c
--- base64.c1 Sep 2016 13:49:32 - 1.5
+++ base64.c13
The ncurses(3) and curs_util(3) man pages reference some manual pages
that do not exist.
$ man 3 curs_memleaks
man: No entry for curs_memleak in the manual
$ man 3 curs_trace
man: No entry for curs_trace in the manual
$ man 3 legacy_coding
man: No en
On Tue, 13 Sep 2016 14:19:24 +0200
j...@wxcvbn.org (Jeremie Courreges-Anglas) wrote:
> Since it has been introduced, ip6_setpktopt has only been called with
> (sticky=1, cmsg=0) or (sticky=0, cmsg=1). Let's simplify this code.
Ok vgross@
>
>
> Index: ip6_output.c
> ===
David Hill writes:
> Hello -
>
> Here is a diff to switch some bcopy's to memcpy's.
>
> Most bcopy's are on freshly alloc'd memory.
Looks fine to me, ok jca@
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Since it has been introduced, ip6_setpktopt has only been called with
(sticky=1, cmsg=0) or (sticky=0, cmsg=1). Let's simplify this code.
Index: ip6_output.c
===
RCS file: /cvs/src/sys/netinet6/ip6_output.c,v
retrieving revision 1.
"Todd C. Miller" writes:
> There's no need to check for isascii() with ANSI ctype macros/functions.
> Eliminating the macros makes the code clearer.
ok jca@
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
On Thu, Sep 08, 2016 at 08:15:42AM +0200, Otto Moerbeek wrote:
> On Wed, Sep 07, 2016 at 06:29:07PM -0400, Ted Unangst wrote:
>
> > Instead of always using a fixed byte pattern, I think malloc should use a
> > random pattern. Now, this sometimes means it's harder to identify exactly
> > what's us
On Thu, Sep 08, 2016 at 06:42:33PM -0400, Daniel Micay wrote:
> On Wed, 2016-09-07 at 18:29 -0400, Ted Unangst wrote:
> > Instead of always using a fixed byte pattern, I think malloc should
> > use a
> > random pattern. Now, this sometimes means it's harder to identify
> > exactly
> > what's used
On 10 September 2016 at 08:42, Nikolay Edigaryev wrote:
> This fixes a bug introduced in revision 1.8 of timer.c that causes
> evtimer_set() to be called on an already active event, which is an error
> according to event_add(3):
>
>>The event in the ev argument must be already initialized by event
Came across two 'refer[e]ring' typos in the pledge(2) man page. The first
diff fixes those. After grepping through the source tree, there's a few
more, similar typos in unrelated files. Attached a second diff for those.
Left HTTP-related stuff alone since refe[r]er is the preferred term in that
co
Here's the big scary diff I've been using for some months now to stop
grabbing the KERNEL_LOCK() in bpf_mtap(9). This has been originally
written to prevent lock ordering inside pf_test(). Now that we're
heading toward using a rwlock, we won't have this problem, but fewer
usages of KERNEL_LOCK()
Doing...
# ifconfig axen0 lladdr bla
is currently broken because we don't update the MAC address in the
driver, which makes the chip drop all the packets unless in promisc
mode.
Diff below fixes that, ok?
Index: if_axen.c
=
> Date: Tue, 13 Sep 2016 10:30:03 +0200
> From: Martin Pieuchot
>
> On 12/09/16(Mon) 13:54, Martin Pieuchot wrote:
> > TCP timers end up calling ip_output(), which will soon require that the
> > caller holds a rwlock.
> >
> > In order to do that, I diff below changes 'struct tcptimer' to become
On 12/09/16(Mon) 13:54, Martin Pieuchot wrote:
> TCP timers end up calling ip_output(), which will soon require that the
> caller holds a rwlock.
>
> In order to do that, I diff below changes 'struct tcptimer' to become a
> tuple of (timeout, task). When a timeout fires, the corresponding task
>
On Tue, 13 Sep 2016 10:08:13 +0200
Martin Pieuchot wrote:
> On 12/09/16(Mon) 12:12, Vincent Gross wrote:
> > On Mon, 12 Sep 2016 10:49:03 +0200
> > Martin Pieuchot wrote:
> >
> > > I'd like to use a write lock to serialize accesses to ip_output().
> > > This will be used to guarantee that ato
On 12/09/16(Mon) 12:12, Vincent Gross wrote:
> On Mon, 12 Sep 2016 10:49:03 +0200
> Martin Pieuchot wrote:
>
> > I'd like to use a write lock to serialize accesses to ip_output().
> > This will be used to guarantee that atomic code sections in the
> > socket layer stay atomic when the input/forwa
On 12/09/16(Mon) 21:14, Frank Groeneveld wrote:
> On Mon, Sep 12, 2016 at 10:18:14AM +0200, Martin Pieuchot wrote:
> >
> > I just committed your driver, with some tweaks in the manpage.
>
> Great, thank you!
>
> > > It is quite likely related to this discussion:
> > >
> > > http://marc.info/?l=
29 matches
Mail list logo
