Hello,
this is a new version based on corrections by henning@ with few more
things added.
I'm not sure whether the type changes in pfvar.h won't break anything,
but it would be nice to have the types uniform.
Any comments or suggestions?
--
Martin Pelikan
Index
Only the bits necessary to set up a filter and lock down an incoming interface.
Index: kern/kern_pledge.c
===
RCS file: /cvs/src/sys/kern/kern_pledge.c,v
retrieving revision 1.174
diff -u -p -r1.174 kern_pledge.c
--- kern/kern_pledge
> In many bpf-using programs, bpf is setup before privs are droppped,
> then locked, and then no significant ioctl's are done after that.
>
> So please show the userland diffs that use this.
You're right. I was thinking of arp(8) but that code path is write only.
I wrote it for the GSoC dhcpd wh
Index: yp.c
===
RCS file: /cvs/src/usr.sbin/ypldap/yp.c,v
retrieving revision 1.14
diff -u -p -r1.14 yp.c
--- yp.c11 Feb 2015 01:26:00 - 1.14
+++ yp.c12 Feb 2015 02:21:09 -
@@ -51,6 +51,7 @@ int yp_check(
eof ctx);
+ free(asalt, M_TEMP, salt_len + 4);
+
+ return 0;
}
Index: dev/luks.c
===
RCS file: dev/luks.c
diff -N dev/luks.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ dev/luks.c 24 May 2015 12:02:30 -
@@ -0,0 +1,252 @@
+/*
+ * Copyright (c) 2015 Martin Pelikan
+ *
Index: bioctl.c
===
RCS file: /cvs/src/sbin/bioctl/bioctl.c,v
retrieving revision 1.126
diff -u -p -r1.126 bioctl.c
--- bioctl.c11 May 2015 12:14:22 - 1.126
+++ bioctl.c24 May 2015 12:39:27 -
@@ -31,6 +31,7 @@
#in
> But why? Sharing encrypted disks between systems is probably a mistake.
My scenarios are multiboot desktop/laptop and external flash/hard drives.
Do you store your backup unencrypted? What if you're away and someone else
[here: a Linux user] has been given a task of performing restores?
This f
> - port xlocale(3) from FreeBSD -- this is what this patch does
>
> I did the patch in two parts, separating include/ and lib/libc/, because my
Second part (include/ headers) follows.
--
Martin Pelikan
Index: _ctype.h
==
> > - port xlocale(3) from FreeBSD -- this is what this patch does
> >
> Second part (include/ headers) follows.
Apologies, I left one bit out. Here it is.
--
Martin Pelikan
Index: locale.h
===
RCS file: /cvs/src/i
got a
possible speedup as well! :-)
Ok's? Comments? Can haz committed?
--
Martin Pelikan
Index: net/hfsc.c
===
RCS file: /cvs/src/sys/net/hfsc.c,v
retrieving revision 1.1
diff -u -p -r1.1 hfsc.c
--- net/hfsc.c 12 Oct 2013
;altq_disc" as "transition.altq.altq_disc" will clash with pf_altq's
member. This diff renames pf_altq::altq_disc to altq_disc_state.
(Ah, the good old C namespace problems! ;-))
It builds on amd64 and shouldn't make any difference.
ok?
--
Mart
s
pointer field (which will be gone after transition).
Compiles & is being tested on amd64.
--
Martin Pelikan
Index: altq/if_altq.h
===
RCS file: /cvs/src/sys/altq/if_altq.h,v
retrieving revision 1.16
diff -u -p -r1.16 if_altq.h
--
e (it can remain 2
years old), removes the now useless ifq_hfsc pointer.
As always, it's being heavily tested.
--
Martin Pelikan
? net/hfsc.c.instrumented
Index: altq/if_altq.h
===
RCS file: /cvs/src/sys/altq/if_altq.h,v
ing it
xlocale or others), I suspect libcxx maintainers won't be very happy
about #ifdef __OpenBSD__
Please correct me if the philosophy is wrong. Or better, suggest other
ways forward :-)
--
Martin Pelikan
add it to our ports tree.
>
> The shim is going to be a lot less work, and doesn't preclude an
> implentation inside libc at a later stage.
Thanks for showing the right direction. I'll look into it as soon as
I have more time; at least I know what is needed and how big is it.
--
Martin Pelikan
tree, to make it work with unlimited v3
diff, you obviously need to substitute some ->'s for .'s.
comments? ok?
--
Martin Pelikan
Index: hfsc.c
===
RCS file: /cvs/src/sys/net/hfsc.c,v
retrieving revision 1.1
diff -u -p -
> As far as I know, HZ is all we have in a portable fashion. How do you
> get better?
>
> (I have an answer. I've prodded for years. Noone has bit yet. Maybe
> you will).
Is the answer "start writing drivers for other timers and make them run
softclock independently of the scheduler tick"? D
Same as v3, only it applies to -current.
ok?
Index: altq/if_altq.h
===
RCS file: /cvs/src/sys/altq/if_altq.h,v
retrieving revision 1.16
diff -u -p -r1.16 if_altq.h
--- altq/if_altq.h 12 Oct 2013 12:13:10 - 1.16
+++ alt
http://storkhole.cz/openssl-free_1.svg
http://storkhole.cz/openssl-free_2.svg
http://storkhole.cz/openssl-free_3.svg
http://storkhole.cz/openssl-free_4.svg
http://storkhole.cz/openssl-free_5.svg
http://storkhole.cz/openssl-free_6.svg
http://storkhole.cz/openssl-free_7.svg
http://storkhole.cz/openss
here even more to it?
> and fix, so please watch your vmstat -i numbers carefully,
I never quite understood what is the "total" number useful for. For
how long and how heavily has the system been used? What do you compare
that to, if you use it to make some statement?
Nevertheless, thanks for all the good work!
--
Martin Pelikan
) and these parts of code
are quite critical, this probably needs heavier testing than my laptop
and Alix board.
Any comments? Corrections? Input?
Thanks in advance.
--
Martin Pelikan
Index: net/pf.c
===
RCS file: /cvs/src/sys/n
It doesn't fix departures (if_leave_group jumps on a non-existing
interface), but I guess people don't remove interfaces that often.
I will rewrite and post the rest of the big one if someone shows
interest in this bit.
--
Martin
since you typically need tunnel fo just few places and not on all
interfaces at the same time.
--
Martin Pelikan
might just sit here, or wait on someone's todo list.
--
Martin Pelikan
Index: net/if.h
===
RCS file: /cvs/src/sys/net/if.h,v
retrieving revision 1.128
diff -u -p -r1.128 if.h
--- net/if.h8 Jul 2011 18:48:51 - 1.128
++
Hi,
ugly typo; anyone thinks this should survive to the upcoming release?
--
Martin Pelikan
Index: net/pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.764
diff -u -p -r1.764 pf.c
--- net/pf.c9 Jul 2011 17:42:19
leaking, though.
--
Martin Pelikan
Index: net/if_vether.c
===
RCS file: /cvs/src/sys/net/if_vether.c,v
retrieving revision 1.15
diff -u -p -r1.15 if_vether.c
--- net/if_vether.c 2 Apr 2010 21:45:49 - 1.15
+++ net/if_vether.c
the timing.
--
Martin Pelikan
Index: net/if.c
===
RCS file: /cvs/src/sys/net/if.c,v
retrieving revision 1.239
diff -u -p -r1.239 if.c
--- net/if.c9 Jul 2011 00:47:18 - 1.239
+++ net/if.c22 Jul 2011 11:54:30 -
On Fri, Jul 22, 2011 at 09:46:45AM -0400, Kenneth R Westerback wrote:
> On Fri, Jul 22, 2011 at 02:51:32PM +0200, Martin Pelikan wrote:
> > The whole logic in these two seems pretty ugly, but inet6 crashed when I
> > tried to make it look prettier and more uniform.
>
> Wha
On Fri, Jul 22, 2011 at 04:06:07PM +0200, Martin Pelikan wrote:
> Or, we can introduce ifa_free() which would look and function correct,
> and migrate all IFAFREE() and ifafree() calls towards that, one by one.
Sorry for posting too early; this is obviously too complicated as the
only p
t forget to recompile libkvm AND ps
Anyone has anything to say or is willing to commit?
--
Martin Pelikan
Index: sys/sysctl.h
===
RCS file: /cvs/src/sys/sys/sysctl.h,v
retrieving revision 1.116
diff -u -p -r1.116 sysctl.h
--- sys/sysc
Hi,
kvm_open(3) is a cross-reference, not a function call with 3.
Plus, why do we mention the same page four times?
--
Martin Pelikan
Index: lib/libkvm/kvm_read.3
===
RCS file: /cvs/src/lib/libkvm/kvm_read.3,v
retrieving revision
.
--
Martin Pelikan
Index: sbin/pfctl/pfctl_qstats.c
===
RCS file: /cvs/src/sbin/pfctl/pfctl_qstats.c,v
retrieving revision 1.32
diff -u -p -r1.32 pfctl_qstats.c
--- sbin/pfctl/pfctl_qstats.c 4 Jul 2011 22:49:03 - 1.32
+++ sbin/pfctl
Hi!
I'm working with Gigabyte H61M-S2V-B3 right now. Graphics built in CPU
supports at most 800x600 in X.org, but the rest of the machine seems
fine. Dmesg at dmesg@ and at NYCBUG database.
However, these are missing (fixed with the aid of UCW's database).
--
Martin Pelikan
Inde
Index: disklabel.8
===
RCS file: /cvs/src/sbin/disklabel/disklabel.8,v
retrieving revision 1.103
diff -u -p -r1.103 disklabel.8
--- disklabel.8 5 Jun 2011 11:57:17 - 1.103
+++ disklabel.8 3 Sep 2011 23:45:26 -
@@ -163,7 +
art of the PCH rather than the CPU, so the "Sandybridge"
> codename doesn't apply. I'll see if I can come up with a better
> naming scheme.
What I meant was 'the one found on chipset made for Sandy Bridges'.
RMH_1 and RMH_2 as suggested by jsg is probably better idea, a
Hi,
motivated by many devs over the weekend I looked at some of the inet6
code again. Easy stuff goes first:
--
Martin Pelikan
Index: in6.c
===
RCS file: /cvs/src/sys/netinet6/in6.c,v
retrieving revision 1.93
diff -u -p -r1.93
.
If there are some ok's, I could start rewriting stuff in the forwarding
path (like pf_addr_compare).
If there is a reason to keep them all 32bit, it might as well get
documented :-)
--
Martin Pelikan
Index: in6.h
===
RCS file
string to that
macro, describing what is the software actually trying to do, in English.
--
Martin Pelikan
Hi!
Noone reads this, so noone noticed, but it's just weird.
--
Martin Pelikan
Index: sync.c
===
RCS file: /cvs/src/usr.sbin/dhcpd/sync.c,v
retrieving revision 1.10
diff -u -p -r1.10 sync.c
--- sync.c 23 Dec 2010 17:38:04
t; Any comments/OKs? (it's pretty straightforward, but intended for
> post 5.3).
That's a great idea!
Should this go in, please don't forget pfstat as well (haven't tested
it, though)
--
Martin Pelikan
--- parse.y.old Thu Jan 11 17:01:58 2007
+
eems like a typical copy-paste error) does the
job. At least with "echo 7.6.5.4 | nc whois.ripe.net 43".
Any comments?
--
Martin Pelikan
Index: netcat.c
===
RCS file: /cvs/src/usr.bin/nc/netcat.c,v
retrieving revision 1.
> wfd is stdin, so doing a shutdown on it will mostly be a noop, right?
Of course you're right. I was so focused on finding the bug I didn't
look above what the fd is :-(
Are you okay with removing this particular shutdown(2) line?
--
Martin Pelikan
contains changes required to the kernel, subsequent ones have the
(most complicated) tcpdump(8) bit and (untested) pcap(3) bit.
Any thoughts? I find it extremely useful and very small change. Will test it
on a system with thousands of queues, but don't expect anything bad with it.
--
Martin Pe
> This mail contains changes required to the kernel, subsequent ones have the
> (most complicated) tcpdump(8) bit and (untested) pcap(3) bit.
tcpdump(8) change follows:
Index: usr.sbin/tcpdump/privsep.c
===
RCS file: /cvs/src/usr.s
> This mail contains changes required to the kernel, subsequent ones have the
> (most complicated) tcpdump(8) bit and (untested) pcap(3) bit.
Just as pcap_setdirection(3), it doesn't have any current user, but it
might be useful to some.
Index: lib/libpcap/Makefile
=
nd obviously forgot it in the kernel part.
Do you think using u_int is better? I'll change it in the other diff.
OK now? Anything else? If you don't tell people what are they doing
wrong, they'll just keep doing it ;-)
--
Martin Pelikan
Index: usr.sbin/tcpdump/privsep.c
==
no benefit.
Because it does two different things. -N preserves the old buggy
behavior and -q does (according to their man page) waiting in seconds.
What does 'q' stand for anyway?
--
Martin Pelikan
t, is if does
it work on other architectures and if it is indeed correct. Although
the numbers suggest quite an improvement, bear in mind this kind of
load does not at all resemble any software actually doing useful stuff.
Any comments?
--
Martin Pelik
es to put p_sigmask on an address
ending with 0xFFF with 4k-sized pages, we have two problems already.
I'm only asking if such a situation can happen, or if there is some
ensure_this_assignment_is_always_atomic(&p->p_sigmask, mask); function
that I missed.
--
Martin Pelikan
heck p_sigmask of
> something else than curproc.
It seems there isn't.
--
Martin Pelikan
Index: compat/linux/linux_signal.c
===
RCS file: /cvs/src/sys/compat/linux/linux_signal.c,v
retrieving revision 1.15
diff -u -p -r1.15 l
d garbage.
Whereas MOV is ok. Obviously, sane architectures doing LD, AND and ST
are ok as well, as long as the ST is atomic (I don't have any experience
with hppa and random search on the internet suggested that pa-riscs
do have word stores atomically).
--
Martin Pelikan
checked the code that thoroughly but this is what POSIX says.
> There's also a couple of additional p->p_sigmask |= ... in kern_sig.c.
>
> All of these need to become atomic_setbits_int/atomic_clearbits_int calls.
Does the third one do the charm? I haven't compiled the othe
Hello tech@,
please test this; I sent it to some folks but it looks like they were busy...
On Thu, Sep 02, 2010 at 06:07:57PM +0200, Henning Brauer wrote:
> this diff I like. get 2 or 3 ppl to test and I'll commit it :)
--
Martin Pelikan
Index:
DNS server addresses are not likely to be changed often.
Any comments or suggestions are welcome.
--
Martin Pelikan
Index: config.c
===
RCS file: /cvs/src/usr.sbin/rtadvd/config.c,v
retrieving revision 1.26
diff -u -p -r1.26 config.c
Sorry, I forgot this part:
Index: icmp6.h
===
RCS file: /cvs/src/sys/netinet/icmp6.h,v
retrieving revision 1.33
diff -u -p -r1.33 icmp6.h
--- icmp6.h 22 Mar 2010 12:23:32 - 1.33
+++ icmp6.h 11 Sep 2010 16:20:15 -
resolv in the base
system? I'll be probably reworking my RDNSS implementation in rtsold
and rtadvd because of the new RFC 6106, which is already in "standards
track". Of course it adds another fighter over resolv.conf...
--
Martin Pelikan
g for IPsec bugs, so if anyone is interested...
--
Martin Pelikan
Index: ike_auth.c
===
RCS file: /cvs/src/sbin/isakmpd/ike_auth.c,v
retrieving revision 1.110
diff -u -p -r1.110 ike_auth.c
--- ike_auth.c 16 Apr 2007 13:01:39 -
)
Any comments?
--
Martin Pelikan
Index: parse.y
===
RCS file: /cvs/src/usr.sbin/ospf6d/parse.y,v
retrieving revision 1.20
diff -u -p -r1.20 parse.y
--- parse.y 13 Dec 2010 13:43:37 - 1.20
+++ parse.y 12 Jan 2011 22:
o be consistent and the information
"configuration OK" to keep its meaning up. Because I found in CVS log
that Henning and Theo were discussing that earlier, I did it this way.
After all, it doesn't look like an expensive check, or is it?
--
Martin Pelikan
On Thu, Jan 13, 2011 at 04:02:47PM +0100, Henning Brauer wrote:
> the check is dirt cheap, so that is not the point.
>
> the aforementioned discussion is just being revived ;)
no problem then, here's the new one
--
Martin Pelikan
w about it without crashing
Comments? Corrections? Thanks in advance.
--
Martin Pelikan
Index: area.c
===
RCS file: /cvs/src/usr.sbin/ospf6d/area.c,v
retrieving revision 1.4
diff -u -p -r1.4 area.c
--- area.c 28 Dec 2008 20:08:31
On Wed, Jan 26, 2011 at 04:44:30PM +0100, Martin Pelikan wrote:
> Hello tech@, claudio@ in particular,
> this diff corrects the behavior of ospf6d when:
> - vlan/vether/? interface is added with some inet6 address
> - a configured interface is removed (please test with usb devs)
>
hanks
--
Martin Pelikan
Index: tun.4
===
RCS file: /cvs/src/share/man/man4/tun.4,v
retrieving revision 1.38
diff -u -p -r1.38 tun.4
--- tun.4 23 Sep 2010 01:24:32 - 1.38
+++ tun.4 25 Mar 2011 21:21:57 -
@@ -36,7 +
Hi!
Here's one copy-paste error in awk(1).
CVS log mentions some upstream; anyone have idea what that is? They may
be interested...
--
Martin Pelikan
Index: run.c
===
RCS file: /cvs/src/usr.bin/awk/run.c,v
retrieving revision
uot;), 24) }' | bc -e
'obase=16'
DE
I hope it starts a discussion (at least), but I don't really know what
the correct way is to these problems.
--
Martin Pelikan
Index: run.c
===
RCS file: /cvs/src/usr.b
65 matches
Mail list logo
