Re: hostname.if(5) clarification
On Mon, Nov 26, 2012 at 04:30:47PM +0200, Paul Irofti wrote: Be more specific about the order of interpretation. Okay? diff --git share/man/man5/hostname.if.5 share/man/man5/hostname.if.5 index b07459f..aa8446f 100644 --- share/man/man5/hostname.if.5 +++ share/man/man5/hostname.if.5 @@ -49,6 +49,8 @@ A configuration file is not needed for lo0. The configuration information is expressed in a line-by-line packed format which makes the most common cases simpler; those dense formats are described below. +The order of the configuration lines matters, they are interpreted from the +top down. Any lines not matching these packed formats are passed directly to .Xr ifconfig 8 . The packed formats are converted using a somewhat inflexible parser and if we say this, then we should provide guidance to folks about how to order the lines. what is the specific problem, or the general rule, that you are addressing? jmc
Re: hostname.if(5) clarification
On Mon, Nov 26, 2012 at 12:11 PM, Andres Perera andre...@zoho.com wrote:
don't know about OP, but yesterday i was surprised when rtlabel had to
be specified after inet
just double checked; s/after/before
ifconfig(8) section on rtlabel bears no mention about the order
before rearranging, lines were just C sorted:
cat hostname.ral0
inet 192.168.2/24
rtlabel egress
afterboot:
route -vn show -inet | awk '{$2=;print}' | column -t
...
Destination Flags Refs Use MtuPrio Iface Label
default UGS4 557 - 12ral0
10.0.0/24 UC 1 0 - 4 re0
10.0.0.11 UHLc 3 1100 - 4 re0
127/8 UGRS 0 0 33152 8 lo0
127.0.0.1 UH 2 2433152 4 lo0
192.168.2/24 UC 1 0 - 4 ral0
192.168.2.1 UHLc 1 0 - 4 ral0
224/4 URS0 0 33152 8 lo0
i haven't fully researched the relationship between the two, but at
least during boot's run of netstart, this is a case where order of
lines and thus ifconfig commands do matter
On Mon, Nov 26, 2012 at 11:56 AM, Jason McIntyre j...@kerhand.co.uk wrote:
On Mon, Nov 26, 2012 at 04:30:47PM +0200, Paul Irofti wrote:
Be more specific about the order of interpretation. Okay?
diff --git share/man/man5/hostname.if.5 share/man/man5/hostname.if.5
index b07459f..aa8446f 100644
--- share/man/man5/hostname.if.5
+++ share/man/man5/hostname.if.5
@@ -49,6 +49,8 @@ A configuration file is not needed for lo0.
The configuration information is expressed in a line-by-line packed format
which makes the most common cases simpler; those dense formats are
described
below.
+The order of the configuration lines matters, they are interpreted from the
+top down.
Any lines not matching these packed formats are passed directly to
.Xr ifconfig 8 .
The packed formats are converted using a somewhat inflexible parser and
if we say this, then we should provide guidance to folks about how to
order the lines. what is the specific problem, or the general rule, that
you are addressing?
jmc
Re: hostname.if(5) clarification
On Mon, Nov 26, 2012 at 04:26:12PM +, Jason McIntyre wrote: On Mon, Nov 26, 2012 at 04:30:47PM +0200, Paul Irofti wrote: Be more specific about the order of interpretation. Okay? diff --git share/man/man5/hostname.if.5 share/man/man5/hostname.if.5 index b07459f..aa8446f 100644 --- share/man/man5/hostname.if.5 +++ share/man/man5/hostname.if.5 @@ -49,6 +49,8 @@ A configuration file is not needed for lo0. The configuration information is expressed in a line-by-line packed format which makes the most common cases simpler; those dense formats are described below. +The order of the configuration lines matters, they are interpreted from the +top down. Any lines not matching these packed formats are passed directly to .Xr ifconfig 8 . The packed formats are converted using a somewhat inflexible parser and if we say this, then we should provide guidance to folks about how to order the lines. what is the specific problem, or the general rule, that you are addressing? Problem: /etc/hostname.iwn0: dhcp nwid foo wpakey bar Gets neighbour's lease then drops it then gets the lease from the foo network using the bar wpakey. Solution: /etc/hostname.iwn0 nwid foo wpakey bar dhcp Sets the network to foo and associates a password to it and then tries to get a lease. Order matters. Perhaps there's a better way to phrase it but, as far as guidance goes, I guess it's not quite possible to do that because ifconfig alone has a plethora of possible usages.
Re: hostname.if(5) clarification
On Mon, Nov 26, 2012 at 04:26:12PM +, Jason McIntyre wrote: On Mon, Nov 26, 2012 at 04:30:47PM +0200, Paul Irofti wrote: Be more specific about the order of interpretation. Okay? diff --git share/man/man5/hostname.if.5 share/man/man5/hostname.if.5 index b07459f..aa8446f 100644 --- share/man/man5/hostname.if.5 +++ share/man/man5/hostname.if.5 @@ -49,6 +49,8 @@ A configuration file is not needed for lo0. The configuration information is expressed in a line-by-line packed format which makes the most common cases simpler; those dense formats are described below. +The order of the configuration lines matters, they are interpreted from the +top down. Any lines not matching these packed formats are passed directly to .Xr ifconfig 8 . The packed formats are converted using a somewhat inflexible parser and if we say this, then we should provide guidance to folks about how to order the lines. what is the specific problem, or the general rule, that you are addressing? jmc I suggest the following. I think the dhcp example is likely a common use case that is obvious and clear. Ken Index: hostname.if.5 === RCS file: /cvs/src/share/man/man5/hostname.if.5,v retrieving revision 1.56 diff -u -p -r1.56 hostname.if.5 --- hostname.if.5 8 Jul 2011 01:30:26 - 1.56 +++ hostname.if.5 26 Nov 2012 17:29:13 - @@ -63,6 +63,17 @@ For example: .Bd -literal -offset indent inet 10.0.0.1 255.255.255.0 10.0.0.255 description Bob's uplink .Ed +.Pp +Each line is processed separately and in order. +For example: +.Bd -literal -offset indent +nwid mynwid +wpakey mywpakey +dhcp +.Ed +.Pp +would run ifconfig to set the nwid of the interface, run it again to set the wpakey of the interface, and then start +.Xr dhclient 8 . .Sh STATIC ADDRESS CONFIGURATION The following packed formats are valid for configuring network interfaces with static addresses:
Re: hostname.if(5) clarification
On Mon, Nov 26, 2012 at 07:19:23PM +0200, Paul Irofti wrote: On Mon, Nov 26, 2012 at 04:26:12PM +, Jason McIntyre wrote: On Mon, Nov 26, 2012 at 04:30:47PM +0200, Paul Irofti wrote: Be more specific about the order of interpretation. Okay? diff --git share/man/man5/hostname.if.5 share/man/man5/hostname.if.5 index b07459f..aa8446f 100644 --- share/man/man5/hostname.if.5 +++ share/man/man5/hostname.if.5 @@ -49,6 +49,8 @@ A configuration file is not needed for lo0. The configuration information is expressed in a line-by-line packed format which makes the most common cases simpler; those dense formats are described below. +The order of the configuration lines matters, they are interpreted from the +top down. Any lines not matching these packed formats are passed directly to .Xr ifconfig 8 . The packed formats are converted using a somewhat inflexible parser and if we say this, then we should provide guidance to folks about how to order the lines. what is the specific problem, or the general rule, that you are addressing? Problem: /etc/hostname.iwn0: dhcp nwid foo wpakey bar Gets neighbour's lease then drops it then gets the lease from the foo network using the bar wpakey. Solution: /etc/hostname.iwn0 nwid foo wpakey bar dhcp Sets the network to foo and associates a password to it and then tries to get a lease. Order matters. Perhaps there's a better way to phrase it but, as far as guidance goes, I guess it's not quite possible to do that because ifconfig alone has a plethora of possible usages. does dhcp nwid foo wpakey bar give you problems too? because hostname.if(5) suggests it should not: A DHCP-configured network interface setup consists of dhcp options so if it isn;t working, isn;t that indicative of a worse problem? or that we have not documented how dhcp works sufficiently? we can;t just say order matters, but not provide any guidance. having said that, i think the text The packed formats are converted, which i think deraadt added, was meant to address something like this. maybe he remembers? anyway...i still dislike the idea of just saying order matters. also, could someone really expect the file to not be parsed top down (i don;t know, i'm just asking. it seems unlikely to me you'd start parsing from the end and work up)? jmc
Re: hostname.if(5) clarification
On Mon, Nov 26, 2012 at 05:40:06PM +, Jason McIntyre wrote: On Mon, Nov 26, 2012 at 07:19:23PM +0200, Paul Irofti wrote: On Mon, Nov 26, 2012 at 04:26:12PM +, Jason McIntyre wrote: On Mon, Nov 26, 2012 at 04:30:47PM +0200, Paul Irofti wrote: Be more specific about the order of interpretation. Okay? diff --git share/man/man5/hostname.if.5 share/man/man5/hostname.if.5 index b07459f..aa8446f 100644 --- share/man/man5/hostname.if.5 +++ share/man/man5/hostname.if.5 @@ -49,6 +49,8 @@ A configuration file is not needed for lo0. The configuration information is expressed in a line-by-line packed format which makes the most common cases simpler; those dense formats are described below. +The order of the configuration lines matters, they are interpreted from the +top down. Any lines not matching these packed formats are passed directly to .Xr ifconfig 8 . The packed formats are converted using a somewhat inflexible parser and if we say this, then we should provide guidance to folks about how to order the lines. what is the specific problem, or the general rule, that you are addressing? Problem: /etc/hostname.iwn0: dhcp nwid foo wpakey bar Gets neighbour's lease then drops it then gets the lease from the foo network using the bar wpakey. Solution: /etc/hostname.iwn0 nwid foo wpakey bar dhcp Sets the network to foo and associates a password to it and then tries to get a lease. Order matters. Perhaps there's a better way to phrase it but, as far as guidance goes, I guess it's not quite possible to do that because ifconfig alone has a plethora of possible usages. does dhcp nwid foo wpakey bar give you problems too? because hostname.if(5) suggests it should not: A DHCP-configured network interface setup consists of dhcp options There have been problems reported with doing everything on one line in the past. so if it isn;t working, isn;t that indicative of a worse problem? or that we have not documented how dhcp works sufficiently? Not sure how much more we can document here. I'm actually wondering if it wouldn't be more clear to eliminate the 'options' processing after 'dhcp', i.e. make people do those things on separate, preceeding lines. we can;t just say order matters, but not provide any guidance. having said that, i think the text The packed formats are converted, which i think deraadt added, was meant to address something like this. maybe he remembers? Well, hostname.if is simply a mechanism to script ifconfig invocations. If you don't know in what order you need to issue the ifconfig invocations required to configure your network, I'm not sure if hostname.if can explain it in a reasonable amount of space. anyway...i still dislike the idea of just saying order matters. also, could someone really expect the file to not be parsed top down (i don;t know, i'm just asking. it seems unlikely to me you'd start parsing from the end and work up)? jmc The misunderstanding I have seen run along the lines that all the lines will be processed and then the system will issue a coherent set of commands to achieve the described network. When really it is, as I said, just a way to put all the ifconfig and related commands in one file. . Ken
Re: hostname.if(5) clarification
On Mon, Nov 26, 2012 at 01:58:45PM -0500, Kenneth R Westerback wrote: does dhcp nwid foo wpakey bar give you problems too? because hostname.if(5) suggests it should not: A DHCP-configured network interface setup consists of dhcp options There have been problems reported with doing everything on one line in the past. so if it isn;t working, isn;t that indicative of a worse problem? or that we have not documented how dhcp works sufficiently? Not sure how much more we can document here. I'm actually wondering if it wouldn't be more clear to eliminate the 'options' processing after 'dhcp', i.e. make people do those things on separate, preceeding lines. we should absolutely remove it if a) we're aware it causes problems and b) we think it makes sense to do it another way. the diff in your previous mail is actually better anyway - the info i was missing was i didn;t realise ifconfig got invoked separately for every line in hostname.if. we can;t just say order matters, but not provide any guidance. having said that, i think the text The packed formats are converted, which i think deraadt added, was meant to address something like this. maybe he remembers? Well, hostname.if is simply a mechanism to script ifconfig invocations. If you don't know in what order you need to issue the ifconfig invocations required to configure your network, I'm not sure if hostname.if can explain it in a reasonable amount of space. but it's clear if we document that ifconfig is invoked separately with each line. anyway...i still dislike the idea of just saying order matters. also, could someone really expect the file to not be parsed top down (i don;t know, i'm just asking. it seems unlikely to me you'd start parsing from the end and work up)? jmc The misunderstanding I have seen run along the lines that all the lines will be processed and then the system will issue a coherent set of commands to achieve the described network. When really it is, as I said, just a way to put all the ifconfig and related commands in one file. i'm not sure i understand. but anyway i think your previous diff, plus removing the dhcp options recommendation, will be a decent start. jmc
Re: raw_usrreq - spl diff
Any thoughts?
On Tue, Nov 13, 2012 at 02:18:35PM -0500, David Hill wrote:
Hello -
I originally asked mikeb if splnet was needed in net/pfkey.c. He added
onto my diff (which I have included below). I noticed route_usrreq from
net/rtsock.c calls raw_usrreq protected by splsoftnet.
I thought I'd send it to tech@ to possibly get more feedback.
Here is the diff I am running with. I haven't had any regressions.
Index: sys/net/pfkey.c
===
RCS file: /cvs/src/sys/net/pfkey.c,v
retrieving revision 1.19
diff -N -u -p sys/net/pfkey.c
--- sys/net/pfkey.c20 Sep 2012 10:25:03 - 1.19
+++ sys/net/pfkey.c11 Nov 2012 01:18:42 -
@@ -198,15 +198,12 @@ static int
pfkey_attach(struct socket *socket, struct mbuf *proto, struct proc *p)
{
int rval;
- int s;
if (!(socket-so_pcb = malloc(sizeof(struct rawcb),
M_PCB, M_DONTWAIT | M_ZERO)))
return (ENOMEM);
- s = splnet();
rval = raw_usrreq(socket, PRU_ATTACH, NULL, proto, NULL, p);
- splx(s);
if (rval)
goto ret;
@@ -228,12 +225,10 @@ ret:
static int
pfkey_detach(struct socket *socket, struct proc *p)
{
- int rval, i, s;
+ int rval, i;
rval = pfkey_versions[socket-so_proto-pr_protocol]-release(socket);
- s = splnet();
i = raw_usrreq(socket, PRU_DETACH, NULL, NULL, NULL, p);
- splx(s);
if (!rval)
rval = i;
@@ -246,7 +241,6 @@ pfkey_usrreq(struct socket *socket, int req, struct mb
struct mbuf *nam, struct mbuf *control, struct proc *p)
{
int rval;
- int s;
if ((socket-so_proto-pr_protocol PFKEY_PROTOCOL_MAX) ||
(socket-so_proto-pr_protocol 0) ||
@@ -261,9 +255,7 @@ pfkey_usrreq(struct socket *socket, int req, struct mb
return (pfkey_detach(socket, p));
default:
- s = splnet();
rval = raw_usrreq(socket, req, mbuf, nam, control, p);
- splx(s);
}
return (rval);
Index: sys/net/raw_usrreq.c
===
RCS file: /cvs/src/sys/net/raw_usrreq.c,v
retrieving revision 1.14
diff -N -u -p sys/net/raw_usrreq.c
--- sys/net/raw_usrreq.c 11 Jan 2012 23:47:06 - 1.14
+++ sys/net/raw_usrreq.c 11 Nov 2012 01:18:42 -
@@ -151,7 +151,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m,
{
struct rawcb *rp = sotorawcb(so);
int error = 0;
- int len;
+ int len, s;
if (req == PRU_CONTROL)
return (EOPNOTSUPP);
@@ -163,6 +163,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m,
error = EINVAL;
goto release;
}
+ s = splsoftnet();
switch (req) {
/*
@@ -269,6 +270,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m,
/*
* stat: don't bother with a blocksize.
*/
+ splx(s);
return (0);
/*
@@ -276,6 +278,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m,
*/
case PRU_RCVOOB:
case PRU_RCVD:
+ splx(s);
return (EOPNOTSUPP);
case PRU_LISTEN:
@@ -308,6 +311,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m,
panic(raw_usrreq);
}
release:
+ splx(s);
if (m != NULL)
m_freem(m);
return (error);
Re: raw_usrreq - spl diff
We've discussed this with claudio and while there are might
be some other related issues with pr_usrreq and spls, I think
this particular diff needs to be committed. OK?
On Tue, Nov 13, 2012 at 14:18 -0500, David Hill wrote:
Hello -
I originally asked mikeb if splnet was needed in net/pfkey.c. He added
onto my diff (which I have included below). I noticed route_usrreq from
net/rtsock.c calls raw_usrreq protected by splsoftnet.
I thought I'd send it to tech@ to possibly get more feedback.
Here is the diff I am running with. I haven't had any regressions.
Index: sys/net/pfkey.c
===
RCS file: /cvs/src/sys/net/pfkey.c,v
retrieving revision 1.19
diff -N -u -p sys/net/pfkey.c
--- sys/net/pfkey.c 20 Sep 2012 10:25:03 - 1.19
+++ sys/net/pfkey.c 11 Nov 2012 01:18:42 -
@@ -198,15 +198,12 @@ static int
pfkey_attach(struct socket *socket, struct mbuf *proto, struct proc *p)
{
int rval;
- int s;
if (!(socket-so_pcb = malloc(sizeof(struct rawcb),
M_PCB, M_DONTWAIT | M_ZERO)))
return (ENOMEM);
- s = splnet();
rval = raw_usrreq(socket, PRU_ATTACH, NULL, proto, NULL, p);
- splx(s);
if (rval)
goto ret;
@@ -228,12 +225,10 @@ ret:
static int
pfkey_detach(struct socket *socket, struct proc *p)
{
- int rval, i, s;
+ int rval, i;
rval = pfkey_versions[socket-so_proto-pr_protocol]-release(socket);
- s = splnet();
i = raw_usrreq(socket, PRU_DETACH, NULL, NULL, NULL, p);
- splx(s);
if (!rval)
rval = i;
@@ -246,7 +241,6 @@ pfkey_usrreq(struct socket *socket, int req, struct mb
struct mbuf *nam, struct mbuf *control, struct proc *p)
{
int rval;
- int s;
if ((socket-so_proto-pr_protocol PFKEY_PROTOCOL_MAX) ||
(socket-so_proto-pr_protocol 0) ||
@@ -261,9 +255,7 @@ pfkey_usrreq(struct socket *socket, int req, struct mb
return (pfkey_detach(socket, p));
default:
- s = splnet();
rval = raw_usrreq(socket, req, mbuf, nam, control, p);
- splx(s);
}
return (rval);
Index: sys/net/raw_usrreq.c
===
RCS file: /cvs/src/sys/net/raw_usrreq.c,v
retrieving revision 1.14
diff -N -u -p sys/net/raw_usrreq.c
--- sys/net/raw_usrreq.c 11 Jan 2012 23:47:06 - 1.14
+++ sys/net/raw_usrreq.c 11 Nov 2012 01:18:42 -
@@ -151,7 +151,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m,
{
struct rawcb *rp = sotorawcb(so);
int error = 0;
- int len;
+ int len, s;
if (req == PRU_CONTROL)
return (EOPNOTSUPP);
@@ -163,6 +163,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m,
error = EINVAL;
goto release;
}
+ s = splsoftnet();
switch (req) {
/*
@@ -269,6 +270,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m,
/*
* stat: don't bother with a blocksize.
*/
+ splx(s);
return (0);
/*
@@ -276,6 +278,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m,
*/
case PRU_RCVOOB:
case PRU_RCVD:
+ splx(s);
return (EOPNOTSUPP);
case PRU_LISTEN:
@@ -308,6 +311,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m,
panic(raw_usrreq);
}
release:
+ splx(s);
if (m != NULL)
m_freem(m);
return (error);
Re: hostname.if(5) clarification
Penned by Kenneth R. Westerback on 20121126 12:58.45, we have: | On Mon, Nov 26, 2012 at 05:40:06PM +, Jason McIntyre wrote: | On Mon, Nov 26, 2012 at 07:19:23PM +0200, Paul Irofti wrote: | On Mon, Nov 26, 2012 at 04:26:12PM +, Jason McIntyre wrote: |On Mon, Nov 26, 2012 at 04:30:47PM +0200, Paul Irofti wrote: | Be more specific about the order of interpretation. Okay? | | diff --git share/man/man5/hostname.if.5 share/man/man5/hostname.if.5 | index b07459f..aa8446f 100644 | --- share/man/man5/hostname.if.5 | +++ share/man/man5/hostname.if.5 | @@ -49,6 +49,8 @@ A configuration file is not needed for lo0. | The configuration information is expressed in a line-by-line packed format | which makes the most common cases simpler; those dense formats are described | below. | +The order of the configuration lines matters, they are interpreted from the | +top down. | Any lines not matching these packed formats are passed directly to | .Xr ifconfig 8 . | The packed formats are converted using a somewhat inflexible parser and | | |if we say this, then we should provide guidance to folks about how to |order the lines. what is the specific problem, or the general rule, that |you are addressing? | | Problem: | | /etc/hostname.iwn0: | dhcp | nwid foo | wpakey bar | | Gets neighbour's lease then drops it then gets the lease from the foo | network using the bar wpakey. | | Solution: | | /etc/hostname.iwn0 | nwid foo | wpakey bar | dhcp | | Sets the network to foo and associates a password to it and then tries | to get a lease. | | Order matters. Perhaps there's a better way to phrase it but, as far as | guidance goes, I guess it's not quite possible to do that because | ifconfig alone has a plethora of possible usages. | | | does dhcp nwid foo wpakey bar give you problems too? because | hostname.if(5) suggests it should not: | | A DHCP-configured network interface setup consists of | | dhcp options | | There have been problems reported with doing everything on one line in the | past. In this scenario 'options' may as well be called 'ifconfig-options'. | | so if it isn;t working, isn;t that indicative of a worse problem? or | that we have not documented how dhcp works sufficiently? | | Not sure how much more we can document here. I'm actually wondering if it | wouldn't be more clear to eliminate the 'options' processing after 'dhcp', | i.e. make people do those things on separate, preceeding lines. Welcome to the pain that is 'do we break backwards compat?' There is a lot we could do if we could break backwards compat. | we can;t just say order matters, but not provide any guidance. having | said that, i think the text The packed formats are converted, which i | think deraadt added, was meant to address something like this. maybe he | remembers? | | Well, hostname.if is simply a mechanism to script ifconfig invocations. If | you don't know in what order you need to issue the ifconfig invocations | required to configure your network, I'm not sure if hostname.if can | explain it in a reasonable amount of space. Indeed. The 'shorthand' or 'packed' syntax of hostname.if permits avoiding typing 'netmask' in the v4 case and 'prefixlen' in the v6 case, for example. | anyway...i still dislike the idea of just saying order matters. also, | could someone really expect the file to not be parsed top down (i don;t | know, i'm just asking. it seems unlikely to me you'd start parsing from | the end and work up)? | | jmc | | | The misunderstanding I have seen run along the lines that all the | lines will be processed and then the system will issue a coherent set of | commands to achieve the described network. When really it is, as I said, | just a way to put all the ifconfig and related commands in one file. | | . Ken There is limited intelligence in the hostname.if parser implemented in sh. It passes things to ifconfig rather blindly and definitely does things in order without regards to any intelligence. If one were to have a hostname.if consisting of: up down up down up down up down You'd need to understand that 'up' is passed to one invocation of ifconfig, down to another, and so on, in order. Generally speaking, one line in hostname.if (that is not a comment) is one action. The exception is the line beginning with 'dest' which was invented to permit gif(4) tunnel configuration syntax. If there are desires to improve this (I hear Naddy grumbling!) then the stomach to break backwards compat must be present, or suggestions on how to do it without breaking backwards compat must be suggested. I'm out of ideas, but will be glad to work with anyone towards any changes desired so long as it is clear what the grammar of hostname.if should look like
Re: raw_usrreq - spl diff
Date: Mon, 26 Nov 2012 20:37:22 +0100
From: Mike Belopuhov m...@belopuhov.com
We've discussed this with claudio and while there are might
be some other related issues with pr_usrreq and spls, I think
this particular diff needs to be committed. OK?
Whenever a diff like this is proposed, it's worth considering to
sprinkle in some splassert's.
On Tue, Nov 13, 2012 at 14:18 -0500, David Hill wrote:
Hello -
I originally asked mikeb if splnet was needed in net/pfkey.c. He added
onto my diff (which I have included below). I noticed route_usrreq from
net/rtsock.c calls raw_usrreq protected by splsoftnet.
I thought I'd send it to tech@ to possibly get more feedback.
Here is the diff I am running with. I haven't had any regressions.
Index: sys/net/pfkey.c
===
RCS file: /cvs/src/sys/net/pfkey.c,v
retrieving revision 1.19
diff -N -u -p sys/net/pfkey.c
--- sys/net/pfkey.c 20 Sep 2012 10:25:03 - 1.19
+++ sys/net/pfkey.c 11 Nov 2012 01:18:42 -
@@ -198,15 +198,12 @@ static int
pfkey_attach(struct socket *socket, struct mbuf *proto, struct proc *p)
{
int rval;
- int s;
if (!(socket-so_pcb = malloc(sizeof(struct rawcb),
M_PCB, M_DONTWAIT | M_ZERO)))
return (ENOMEM);
- s = splnet();
rval = raw_usrreq(socket, PRU_ATTACH, NULL, proto, NULL, p);
- splx(s);
if (rval)
goto ret;
@@ -228,12 +225,10 @@ ret:
static int
pfkey_detach(struct socket *socket, struct proc *p)
{
- int rval, i, s;
+ int rval, i;
rval = pfkey_versions[socket-so_proto-pr_protocol]-release(socket);
- s = splnet();
i = raw_usrreq(socket, PRU_DETACH, NULL, NULL, NULL, p);
- splx(s);
if (!rval)
rval = i;
@@ -246,7 +241,6 @@ pfkey_usrreq(struct socket *socket, int req, struct mb
struct mbuf *nam, struct mbuf *control, struct proc *p)
{
int rval;
- int s;
if ((socket-so_proto-pr_protocol PFKEY_PROTOCOL_MAX) ||
(socket-so_proto-pr_protocol 0) ||
@@ -261,9 +255,7 @@ pfkey_usrreq(struct socket *socket, int req, struct mb
return (pfkey_detach(socket, p));
default:
- s = splnet();
rval = raw_usrreq(socket, req, mbuf, nam, control, p);
- splx(s);
}
return (rval);
Index: sys/net/raw_usrreq.c
===
RCS file: /cvs/src/sys/net/raw_usrreq.c,v
retrieving revision 1.14
diff -N -u -p sys/net/raw_usrreq.c
--- sys/net/raw_usrreq.c11 Jan 2012 23:47:06 - 1.14
+++ sys/net/raw_usrreq.c11 Nov 2012 01:18:42 -
@@ -151,7 +151,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m,
{
struct rawcb *rp = sotorawcb(so);
int error = 0;
- int len;
+ int len, s;
if (req == PRU_CONTROL)
return (EOPNOTSUPP);
@@ -163,6 +163,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m,
error = EINVAL;
goto release;
}
+ s = splsoftnet();
switch (req) {
/*
@@ -269,6 +270,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m,
/*
* stat: don't bother with a blocksize.
*/
+ splx(s);
return (0);
/*
@@ -276,6 +278,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m,
*/
case PRU_RCVOOB:
case PRU_RCVD:
+ splx(s);
return (EOPNOTSUPP);
case PRU_LISTEN:
@@ -308,6 +311,7 @@ raw_usrreq(struct socket *so, int req, struct mbuf *m,
panic(raw_usrreq);
}
release:
+ splx(s);
if (m != NULL)
m_freem(m);
return (error);
Re: raw_usrreq - spl diff
On Mon, Nov 26, 2012 at 8:54 PM, Mark Kettenis mark.kette...@xs4all.nl wrote: Date: Mon, 26 Nov 2012 20:37:22 +0100 From: Mike Belopuhov m...@belopuhov.com We've discussed this with claudio and while there are might be some other related issues with pr_usrreq and spls, I think this particular diff needs to be committed. OK? Whenever a diff like this is proposed, it's worth considering to sprinkle in some splassert's. where do you want to put splasserts? i honestly don't see a place where it would matter: raw_usrreq will call splsoftnet itself. pfkey_* functions don't neet splnet for anything else.
Re: hostname.if(5) clarification
Jason McIntyre j...@kerhand.co.uk wrote: On Mon, Nov 26, 2012 at 07:19:23PM +0200, Paul Irofti wrote: On Mon, Nov 26, 2012 at 04:26:12PM +, Jason McIntyre wrote: On Mon, Nov 26, 2012 at 04:30:47PM +0200, Paul Irofti wrote: Be more specific about the order of interpretation. Okay? diff --git share/man/man5/hostname.if.5 share/man/man5/hostname.if.5 index b07459f..aa8446f 100644 --- share/man/man5/hostname.if.5 +++ share/man/man5/hostname.if.5 @@ -49,6 +49,8 @@ A configuration file is not needed for lo0. The configuration information is expressed in a line-by-line packed format which makes the most common cases simpler; those dense formats are described below. +The order of the configuration lines matters, they are interpreted from the +top down. Any lines not matching these packed formats are passed directly to .Xr ifconfig 8 . The packed formats are converted using a somewhat inflexible parser and if we say this, then we should provide guidance to folks about how to order the lines. what is the specific problem, or the general rule, that you are addressing? Problem: /etc/hostname.iwn0: dhcp nwid foo wpakey bar Gets neighbour's lease then drops it then gets the lease from the foo network using the bar wpakey. Solution: /etc/hostname.iwn0 nwid foo wpakey bar dhcp Sets the network to foo and associates a password to it and then tries to get a lease. Order matters. Perhaps there's a better way to phrase it but, as far as guidance goes, I guess it's not quite possible to do that because ifconfig alone has a plethora of possible usages. does dhcp nwid foo wpakey bar give you problems too? because hostname.if(5) suggests it should not: A DHCP-configured network interface setup consists of dhcp options so if it isn;t working, isn;t that indicative of a worse problem? or that we have not documented how dhcp works sufficiently? we can;t just say order matters, but not provide any guidance. having said that, i think the text The packed formats are converted, which i think deraadt added, was meant to address something like this. maybe he remembers? anyway...i still dislike the idea of just saying order matters. also, could someone really expect the file to not be parsed top down (i don;t know, i'm just asking. it seems unlikely to me you'd start parsing from the end and work up)? This was my first thought, too. With Ken's example it makes more sense.
Re: hostname.if(5) clarification
Todd T. Fries t...@fries.net wrote: If there are desires to improve this (I hear Naddy grumbling!) then the stomach to break backwards compat must be present, or suggestions on how to do it without breaking backwards compat must be suggested. My suggestion is two-fold: * Introduce a new format. This new format will ignore # comments, call ! commands, but otherwise pass on everything unchanged to ifconfig. I'm neutral on the matter of retaining dhcp and rtsol as shortcuts for !dhclient \$if and !rtsol \$if. * To maintain backward compatibility, retain the old parsing for hostname.* files. Interface configuration files in the new format will have a different name; if.* or whatever. Does that sound workable? -- Christian naddy Weisgerber na...@mips.inka.de
Re: hostname.if(5) clarification
From: na...@mips.inka.de (Christian Weisgerber) Date: Mon, 26 Nov 2012 20:44:45 + (UTC) Todd T. Fries t...@fries.net wrote: If there are desires to improve this (I hear Naddy grumbling!) then the stomach to break backwards compat must be present, or suggestions on how to do it without breaking backwards compat must be suggested. My suggestion is two-fold: * Introduce a new format. This new format will ignore # comments, call ! commands, but otherwise pass on everything unchanged to ifconfig. I'm neutral on the matter of retaining dhcp and rtsol as shortcuts for !dhclient \$if and !rtsol \$if. * To maintain backward compatibility, retain the old parsing for hostname.* files. Interface configuration files in the new format will have a different name; if.* or whatever. Does that sound workable? I don't really see what this buys us. You still have to maintain the backwards compat code. You'll end up with an inconsistent mess of hostname.if and if.whatever files. And all of this to fix what exactly?
Re: hostname.if(5) clarification
On 2012/11/26 17:40, Jason McIntyre wrote: anyway...i still dislike the idea of just saying order matters. also, could someone really expect the file to not be parsed top down Yes, I think they might; people are used to config files being read and parsed before being applied, and because this file isn't a straight set of commands to pass to ifconfig(8) I think it's not unreasonable that someone should treat it as a config file.
Re: hostname.if(5) clarification
Mark Kettenis: I don't really see what this buys us. You still have to maintain the backwards compat code. You'll end up with an inconsistent mess of hostname.if and if.whatever files. And all of this to fix what exactly? To preserve my sanity every time I need to figure out how to bring ifconfig commands into a format that passes through the transformations done by the hostname.if parser. Remember how we were struggling with -autoconfprivacy a few months ago? -- Christian naddy Weisgerber na...@mips.inka.de
Re: hostname.if(5) clarification
If there are desires to improve this (I hear Naddy grumbling!) then the stomach to break backwards compat must be present, or suggestions on how to do it without breaking backwards compat must be suggested. My suggestion is two-fold: * Introduce a new format. This new format will ignore # comments, call ! commands, but otherwise pass on everything unchanged to ifconfig. I'm neutral on the matter of retaining dhcp and rtsol as shortcuts for !dhclient \$if and !rtsol \$if. * To maintain backward compatibility, retain the old parsing for hostname.* files. Interface configuration files in the new format will have a different name; if.* or whatever. Does that sound workable? Not really. The netbsd experiment with ifconfig file format does not appear to have been a success. reason why? ifconfig has a really crummy argument parser, with all sorts of side effects. hostname.* files were supposed to isolate people from some of those nasty effects. stated simply, it would not have helped Paul. He would have made the same mistake.
Re: new device ids
Le 23/11/2012 08:35, Kirill Bychkov a écrit : Hi. This patch adds fingerprint reader and ati video, found on my girlfriend's hp pavillion dv6. OK? Index: pci/pcidevs === RCS file: /cvs/src/sys/dev/pci/pcidevs,v retrieving revision 1.1661 diff -u -r1.1661 pcidevs --- pci/pcidevs 17 Nov 2012 15:42:29 - 1.1661 +++ pci/pcidevs 23 Nov 2012 04:24:46 - @@ -1264,6 +1264,7 @@ product ATI RADEON_HD66700x6758 Radeon HD 6670 product ATI RADEON_HD58000x6899 Radeon HD 5800 product ATI RADEON_HD57000x68b8 Radeon HD 5700 +product ATI MOBILITY_HD6550 0x68c1 Radeon Mobility HD 6550 product ATI RADEON_HD56700x68d8 Radeon HD 5670 product ATI MOBILITY_HD5470 0x68e0 Radeon Mobility HD 5470 product ATI MOBILITY_HD5430 0x68e1 Radeon Mobility HD 5430 Index: usb/usbdevs === RCS file: /cvs/src/sys/dev/usb/usbdevs,v retrieving revision 1.592 diff -u -r1.592 usbdevs --- usb/usbdevs 21 Nov 2012 05:24:19 - 1.592 +++ usb/usbdevs 23 Nov 2012 04:24:46 - @@ -509,6 +509,7 @@ vendor MOBILITY 0x1342 Mobility vendor DICKSMITH 0x1371 Dick Smith Electronics vendor NETGEAR3 0x1385 Netgear +vendor VALIDITYSENSORS 0x138a Validity Sensors Inc. vendor BALTECH 0x13ad Baltech vendor CISCOLINKSYS 0x13b1 Cisco-Linksys vendor SHARK 0x13d2 Shark @@ -4052,6 +4053,9 @@ /* USI products */ product USI MC60 0x10c5 MC60 Serial + +/* Validity Sensors Inc. products */ +product VALIDITYSENSORS VFS301 0x0005 Fingerprint reader VFS301 /* Velleman products */ product VELLEMAN K8055 0x5500 K8055 USB Experiment interface board Looks good: http://www.pcidatabase.com/vendor_details.php?id=240 http://www.pcidatabase.com/vendor_details.php?id=1689
sqlite3 3.7.14.1
Hi, here's a 250k diff to update our base sqlite3 to the latest 3.7.14.1 : http://rhaalovely.net/~landry/shared/sqlite-3.7.14.1.diff I hope i got the diff right, iirc no local modifications were made to the actual code. Mozilla 18 branch depends on it (for no good reason as usual) so i'd like to get it in in the coming weeks. Bumped major to 21.0, builds fine on amd64. No more testing than that.. i'll do a bulk build with it. Can we run the regress tests from databases/sqlite3 on the base sqlite ? Nothing fancy in the 3.7.14 and .1 releases : http://www.sqlite.org/changes.html Landry
Re: hostname.if(5) clarification
On Mon, Nov 26, 2012 at 05:36:20PM -0700, Theo de Raadt wrote: If there are desires to improve this (I hear Naddy grumbling!) then the stomach to break backwards compat must be present, or suggestions on how to do it without breaking backwards compat must be suggested. My suggestion is two-fold: * Introduce a new format. This new format will ignore # comments, call ! commands, but otherwise pass on everything unchanged to ifconfig. I'm neutral on the matter of retaining dhcp and rtsol as shortcuts for !dhclient \$if and !rtsol \$if. * To maintain backward compatibility, retain the old parsing for hostname.* files. Interface configuration files in the new format will have a different name; if.* or whatever. Does that sound workable? Not really. The netbsd experiment with ifconfig file format does not appear to have been a success. reason why? ifconfig has a really crummy argument parser, with all sorts of side effects. hostname.* files were supposed to isolate people from some of those nasty effects. stated simply, it would not have helped Paul. He would have made the same mistake. Plus some interface changes need multiple ifconfig commands and a specific order to work. I think there is no way to express complex interface configurations without having an order in which the operations are done. Sure it is possible to throw the ordering all into netstart but I think that is not helpful. -- :wq Claudio
