* [PATCH 1/1] drivers/net/usb/usbnet.c: No need for usb_free_urb in rx_complete
From: Kautuk Consul @ 2011-09-03 17:35 UTC (permalink / raw)
To: Oliver Neukum
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
Kautuk Consul
usb_hcd_giveback_urb frees the urb irrespective of any return
value from the urb->complete function. It calls usb_put_urb which
is #defined to usb_free_urb, so maybe we shouldn't be freeing this
from rx_complete.
But I can't get around the fact that this has not been detected as a problem
till now, so I could be quite wrong about this. :)
Signed-off-by: Kautuk Consul <consul.kautuk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/net/usb/usbnet.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index ce395fe..6df8094 100644
--- a/drivers/net/usb/usbnet.c
+++ b/drivers/net/usb/usbnet.c
@@ -491,7 +491,6 @@ block:
rx_submit (dev, urb, GFP_ATOMIC);
return;
}
- usb_free_urb (urb);
}
netif_dbg(dev, rx_err, dev->net, "no read resubmitted\n");
}
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 1/2] bridge: leave carrier on for empty bridge
From: Nicolas de Pesloüan @ 2011-09-03 18:32 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David S. Miller, netdev
In-Reply-To: <20110902151100.327af0bf@nehalam.ftrdhcpuser.net>
Le 03/09/2011 00:11, Stephen Hemminger a écrit :
> On Fri, 02 Sep 2011 23:39:03 +0200
> Nicolas de Pesloüan<nicolas.2p.debian@gmail.com> wrote:
>
>> Le 02/09/2011 19:22, Stephen Hemminger a écrit :
>>> This resolves a regression seen by some users of bridging.
>>> Some users use the bridge like a dummy device.
>>> They expect to be able to put an IPv6 address on the device
>>> with no ports attached during boot.
>>>
>>> Note: the bridge still will reflect the state of ports in the
>>> bridge if there are any added.
>>
>> Doesn't this jeopardize the behavior introduced in 1faa4356a3bd89ea11fb92752d897cff3a20ec0e
>> "bridge: control carrier based on ports online"?
>>
>> If the user starts the DHCP client before adding the first port to the bridge, the DHCP client will
>> have a carrier and start the autoconfiguration process. This was the old behavior, but you fixed it.
>>
>> Nicolas.
>>
>
> There is no perfect solution.
> If DHCP works then IPv6 breaks?
Instead of asserting carrier when the bridge have no port, can't we assert carrier when the three
following condition are true at the same time :
- The bridge have no port.
- At least one IP address is setup on the bridge.
- The two above conditions are true for more than a configurable amount of seconds, with a default
of 10, for example.
This would only delay carrier on for a few seconds for the regression and keep the current behavior
(carrier off until at least 1 port is on) for DHCP.
Nicolas.
^ permalink raw reply
* [PATCH] netfilter: install nf_nat.h and related headers to INSTALL_HDR_PATH
From: Anthony G. Basile @ 2011-09-03 18:49 UTC (permalink / raw)
To: davem
Cc: kaber, basile, blueness, gurligebis, base-system, kernel,
toolchain, mchehab, hverkuil, laurent.pinchart, arnd, eparis,
linux-kernel, netdev, netfilter-devel, netfilter, coreteam
Currently nf_nat.h, nf_conntrack_tuple.h and related headers under
include/net/netfilter are not installed as part of the public kernel
headers. However, there are userland applications, other than iptables
which ships with its own headers, which need these to make use of NAT in
the kernel's netfilter API. For example, miniupnpd, requires them and is
forced to search /usr/src/linux when building.
This patch makes these headers public by installing them in
INSTALL_HDR_PATH.
See: https://bugs.gentoo.org/376873
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
---
include/Kbuild | 1 +
include/linux/Kbuild | 1 +
include/net/Kbuild | 1 +
include/net/netfilter/Kbuild | 6 ++++++
include/net/netfilter/ipv4/Kbuild | 1 +
include/net/netfilter/ipv6/Kbuild | 2 ++
6 files changed, 12 insertions(+), 0 deletions(-)
create mode 100644 include/net/Kbuild
create mode 100644 include/net/netfilter/Kbuild
create mode 100644 include/net/netfilter/ipv4/Kbuild
create mode 100644 include/net/netfilter/ipv6/Kbuild
diff --git a/include/Kbuild b/include/Kbuild
index 8d226bf..9fb8300 100644
--- a/include/Kbuild
+++ b/include/Kbuild
@@ -5,6 +5,7 @@ header-y += asm-generic/
header-y += linux/
header-y += sound/
header-y += mtd/
+header-y += net/
header-y += rdma/
header-y += video/
header-y += drm/
diff --git a/include/linux/Kbuild b/include/linux/Kbuild
index 619b565..5569432 100644
--- a/include/linux/Kbuild
+++ b/include/linux/Kbuild
@@ -228,6 +228,7 @@ header-y += keyboard.h
header-y += keyctl.h
header-y += l2tp.h
header-y += limits.h
+header-y += list_nulls.h
header-y += llc.h
header-y += loop.h
header-y += lp.h
diff --git a/include/net/Kbuild b/include/net/Kbuild
new file mode 100644
index 0000000..9546082
--- /dev/null
+++ b/include/net/Kbuild
@@ -0,0 +1 @@
+header-y += netfilter/
diff --git a/include/net/netfilter/Kbuild b/include/net/netfilter/Kbuild
new file mode 100644
index 0000000..143f188
--- /dev/null
+++ b/include/net/netfilter/Kbuild
@@ -0,0 +1,6 @@
+header-y += nf_nat.h
+header-y += nf_conntrack.h
+header-y += nf_conntrack_tuple.h
+header-y += nf_conntrack_extend.h
+header-y += ipv4/
+header-y += ipv6/
diff --git a/include/net/netfilter/ipv4/Kbuild b/include/net/netfilter/ipv4/Kbuild
new file mode 100644
index 0000000..a15e304
--- /dev/null
+++ b/include/net/netfilter/ipv4/Kbuild
@@ -0,0 +1 @@
+header-y += nf_conntrack_ipv4.h
diff --git a/include/net/netfilter/ipv6/Kbuild b/include/net/netfilter/ipv6/Kbuild
new file mode 100644
index 0000000..07d43a4
--- /dev/null
+++ b/include/net/netfilter/ipv6/Kbuild
@@ -0,0 +1,2 @@
+header-y += nf_conntrack_icmpv6.h
+header-y += nf_conntrack_ipv6.h
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] netfilter: install nf_nat.h and related headers to INSTALL_HDR_PATH
From: Jan Engelhardt @ 2011-09-03 19:41 UTC (permalink / raw)
To: Anthony G. Basile
Cc: davem, kaber, blueness, gurligebis, base-system, kernel,
toolchain, mchehab, hverkuil, laurent.pinchart, arnd, eparis,
linux-kernel, netdev, netfilter-devel, netfilter, coreteam
In-Reply-To: <1315075784-10163-1-git-send-email-basile@opensource.dyc.edu>
On Saturday 2011-09-03 20:49, Anthony G. Basile wrote:
>Currently nf_nat.h, nf_conntrack_tuple.h and related headers under
>include/net/netfilter are not installed as part of the public kernel
>headers. However, there are userland applications, other than iptables
>which ships with its own headers, which need these to make use of NAT in
>the kernel's netfilter API. For example, miniupnpd, requires them and is
>forced to search /usr/src/linux when building.
>
>This patch makes these headers public by installing them in
>INSTALL_HDR_PATH.
>
>See: https://bugs.gentoo.org/376873
>
>Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
>@@ -0,0 +1,6 @@
>+header-y += nf_nat.h
>+header-y += nf_conntrack.h
>+header-y += nf_conntrack_tuple.h
>+header-y += nf_conntrack_extend.h
>+header-y += ipv4/
>+header-y += ipv6/
Should not the to-be-exported files better go into linux/ instead?
^ permalink raw reply
* Re: [PATCH 1/1] drivers/net/usb/usbnet.c: No need for usb_free_urb in rx_complete
From: Alan Stern @ 2011-09-03 20:02 UTC (permalink / raw)
To: Kautuk Consul; +Cc: Oliver Neukum, netdev, linux-usb
In-Reply-To: <1315071353-14978-1-git-send-email-consul.kautuk@gmail.com>
On Sat, 3 Sep 2011, Kautuk Consul wrote:
> usb_hcd_giveback_urb frees the urb irrespective of any return
> value from the urb->complete function. It calls usb_put_urb which
> is #defined to usb_free_urb, so maybe we shouldn't be freeing this
> from rx_complete.
usb_free_urb() doesn't free its argument unless the refcount drops to
0. The refcount is incremented during usb_hcd_submit_urb(), and the
decrement during usb_hcd_giveback_urb() merely undoes this increment.
> But I can't get around the fact that this has not been detected as a problem
> till now, so I could be quite wrong about this. :)
Quite probably. :-)
Alan Stern
^ permalink raw reply
* Re: [PATCH 02/15] user ns: setns: move capable checks into per-ns attach helper
From: Matt Helsley @ 2011-09-04 1:51 UTC (permalink / raw)
To: Serge Hallyn
Cc: akpm, segooon, linux-kernel, netdev, containers, dhowells,
ebiederm, rdunlap
In-Reply-To: <1314993400-6910-5-git-send-email-serge@hallyn.com>
On Fri, Sep 02, 2011 at 07:56:27PM +0000, Serge Hallyn wrote:
> From: "Serge E. Hallyn" <serge@hallyn.com>
I was confused about this patch until I realized that you're not
simply "moving" the capability checks but "distributing" them. Then
you're showing that you'll soon change some to nsown_capable() or
ns_capable() using the strange cpp pattern in the snippet below.
At least I think that's what you intended. A commit message would
help :).
Cheers,
-Matt Helsley
>
> Signed-off-by: Serge E. Hallyn <serge.hallyn@canonical.com>
> Cc: Eric W. Biederman <ebiederm@xmission.com>
> ---
> ipc/namespace.c | 7 +++++++
> kernel/fork.c | 5 +++++
> kernel/nsproxy.c | 11 ++++++++---
> kernel/utsname.c | 7 +++++++
> net/core/net_namespace.c | 7 +++++++
> 5 files changed, 34 insertions(+), 3 deletions(-)
>
> diff --git a/ipc/namespace.c b/ipc/namespace.c
> index ce0a647..a0a7609 100644
> --- a/ipc/namespace.c
> +++ b/ipc/namespace.c
> @@ -163,6 +163,13 @@ static void ipcns_put(void *ns)
>
> static int ipcns_install(struct nsproxy *nsproxy, void *ns)
> {
> +#if 0
> + struct ipc_namespace *newns = ns;
> + if (!ns_capable(newns->user_ns, CAP_SYS_ADMIN))
> +#else
> + if (!capable(CAP_SYS_ADMIN))
> +#endif
> + return -1;
> /* Ditch state from the old ipc namespace */
> exit_sem(current);
> put_ipc_ns(nsproxy->ipc_ns);
^ permalink raw reply
* Re: [PATCH 1/2] bridge: leave carrier on for empty bridge
From: Stephen Hemminger @ 2011-09-04 4:14 UTC (permalink / raw)
To: Nicolas de Pesloüan; +Cc: David S. Miller, netdev
In-Reply-To: <4E6272BC.4020707@gmail.com>
On Sat, 03 Sep 2011 20:32:28 +0200
Nicolas de Pesloüan <nicolas.2p.debian@gmail.com> wrote:
> Le 03/09/2011 00:11, Stephen Hemminger a écrit :
> > On Fri, 02 Sep 2011 23:39:03 +0200
> > Nicolas de Pesloüan<nicolas.2p.debian@gmail.com> wrote:
> >
> >> Le 02/09/2011 19:22, Stephen Hemminger a écrit :
> >>> This resolves a regression seen by some users of bridging.
> >>> Some users use the bridge like a dummy device.
> >>> They expect to be able to put an IPv6 address on the device
> >>> with no ports attached during boot.
> >>>
> >>> Note: the bridge still will reflect the state of ports in the
> >>> bridge if there are any added.
> >>
> >> Doesn't this jeopardize the behavior introduced in 1faa4356a3bd89ea11fb92752d897cff3a20ec0e
> >> "bridge: control carrier based on ports online"?
> >>
> >> If the user starts the DHCP client before adding the first port to the bridge, the DHCP client will
> >> have a carrier and start the autoconfiguration process. This was the old behavior, but you fixed it.
> >>
> >> Nicolas.
> >>
> >
> > There is no perfect solution.
> > If DHCP works then IPv6 breaks?
>
> Instead of asserting carrier when the bridge have no port, can't we assert carrier when the three
> following condition are true at the same time :
>
> - The bridge have no port.
> - At least one IP address is setup on the bridge.
> - The two above conditions are true for more than a configurable amount of seconds, with a default
> of 10, for example.
>
> This would only delay carrier on for a few seconds for the regression and keep the current behavior
> (carrier off until at least 1 port is on) for DHCP.
This fails on two counts:
1. Bridge's often run without IP addresses!
2. DHCP won't try and send out request until carrier is true.
^ permalink raw reply
* [PATCH -next v2] unix stream: Fix use-after-free crashes
From: Yan, Zheng @ 2011-09-04 5:44 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: davem@davemloft.net, sfr@canb.auug.org.au,
tim.c.chen@linux.intel.com, jirislaby@gmail.com,
sedat.dilek@gmail.com
Commit 0856a30409 (Scm: Remove unnecessary pid & credential references
in Unix socket's send and receive path) introduced a use-after-free bug.
It passes the scm reference to the first skb. Skb(s) afterwards may
reference freed data structure because the first skb can be destructed
by the receiver at anytime. The fix is by passing the scm reference to
the very last skb.
Signed-off-by: Zheng Yan <zheng.z.yan@intel.com>
Reported-by: Jiri Slaby <jirislaby@gmail.com>
---
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index e6d9d10..77ec8e8 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -1577,6 +1577,7 @@ static int unix_stream_sendmsg(struct kiocb *kiocb, struct socket *sock,
int sent = 0;
struct scm_cookie tmp_scm;
bool fds_sent = false;
+ bool scm_ref = true;
int max_level;
if (NULL == siocb->scm)
@@ -1637,12 +1638,15 @@ static int unix_stream_sendmsg(struct kiocb *kiocb, struct socket *sock,
*/
size = min_t(int, size, skb_tailroom(skb));
+ /* pass the scm reference to the very last skb */
+ if (sent + size >= len)
+ scm_ref = false;
- /* Only send the fds and no ref to pid in the first buffer */
- err = unix_scm_to_skb(siocb->scm, skb, !fds_sent, fds_sent);
+ /* Only send the fds in the first buffer */
+ err = unix_scm_to_skb(siocb->scm, skb, !fds_sent, scm_ref);
if (err < 0) {
kfree_skb(skb);
- goto out;
+ goto out_err;
}
max_level = err + 1;
fds_sent = true;
@@ -1650,7 +1654,7 @@ static int unix_stream_sendmsg(struct kiocb *kiocb, struct socket *sock,
err = memcpy_fromiovec(skb_put(skb, size), msg->msg_iov, size);
if (err) {
kfree_skb(skb);
- goto out;
+ goto out_err;
}
unix_state_lock(other);
@@ -1667,10 +1671,10 @@ static int unix_stream_sendmsg(struct kiocb *kiocb, struct socket *sock,
sent += size;
}
- if (skb)
- scm_release(siocb->scm);
- else
+ if (scm_ref)
scm_destroy(siocb->scm);
+ else
+ scm_release(siocb->scm);
siocb->scm = NULL;
return sent;
@@ -1683,9 +1687,10 @@ pipe_err:
send_sig(SIGPIPE, current, 0);
err = -EPIPE;
out_err:
- if (skb == NULL)
+ if (scm_ref)
scm_destroy(siocb->scm);
-out:
+ else
+ scm_release(siocb->scm);
siocb->scm = NULL;
return sent ? : err;
}
^ permalink raw reply related
* Re: [PATCH -next v2] unix stream: Fix use-after-free crashes
From: Sedat Dilek @ 2011-09-04 7:12 UTC (permalink / raw)
To: Yan, Zheng
Cc: netdev@vger.kernel.org, davem@davemloft.net, sfr@canb.auug.org.au,
tim.c.chen@linux.intel.com, jirislaby@gmail.com
In-Reply-To: <4E631032.6050606@intel.com>
On Sun, Sep 4, 2011 at 7:44 AM, Yan, Zheng <zheng.z.yan@intel.com> wrote:
> Commit 0856a30409 (Scm: Remove unnecessary pid & credential references
> in Unix socket's send and receive path) introduced a use-after-free bug.
> It passes the scm reference to the first skb. Skb(s) afterwards may
> reference freed data structure because the first skb can be destructed
> by the receiver at anytime. The fix is by passing the scm reference to
> the very last skb.
>
s/by passing/bypassing ?
> Signed-off-by: Zheng Yan <zheng.z.yan@intel.com>
> Reported-by: Jiri Slaby <jirislaby@gmail.com>
> ---
Tested on i386 against linux-next (next-20110831).
- Sedat -
^ permalink raw reply
* Re: [PATCH 1/2] bridge: leave carrier on for empty bridge
From: Nicolas de Pesloüan @ 2011-09-04 7:35 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David S. Miller, netdev
In-Reply-To: <20110903211438.2a43d2f2@nehalam.ftrdhcpuser.net>
Le 04/09/2011 06:14, Stephen Hemminger a écrit :
>> Instead of asserting carrier when the bridge have no port, can't we assert carrier when the three
>> following condition are true at the same time :
>>
>> - The bridge have no port.
>> - At least one IP address is setup on the bridge.
>> - The two above conditions are true for more than a configurable amount of seconds, with a default
>> of 10, for example.
>>
>> This would only delay carrier on for a few seconds for the regression and keep the current behavior
>> (carrier off until at least 1 port is on) for DHCP.
>
> This fails on two counts:
> 1. Bridge's often run without IP addresses!
> 2. DHCP won't try and send out request until carrier is true.
Sorry, I missed to say that we should of course also assert carrier on if one port has carrier on.
And rethinking about it, the delay is probably useless :
bridge_carrier_on = at_least_one_port_has_carrier_on | (bridge_has_no_port & bridge_has_at_least_one_ip)
That way :
- for those using bridge without any port, manually setting the IP will assert carrier on. (By the
way, why don't they use a dummy device instead?)
- for those using bridge with ports:
-- Using any kind of autoconfig will work as expected. Carrier will only be asserted at the time
first port get carrier.
-- Using static IP confifiguration, carrier will possibly be erroneously reported as on during the
small time gap between IP address configuration and first port is added to the bridge. This time gap
may be removed by simply configuring the IP after the first port is added. This is probably already
true for most distribs. And anyway, this time gap is probably not a problem.
-- Carrier will also be erroneously reported as on after removing the last port, if the bridge still
has an IP. (But we can arrange for this not to happen).
And in order to ensure user really understand why carrier is on of off, we can simply issue an INFO
message for the non-natural case (bridge_has_no_port & bridga_has_at_least_one_ip).
I consider all this reasonable.
Nicolas.
^ permalink raw reply
* Re: [PATCH 02/11] net: add function to allocate skbuff head without data area
From: Eric Dumazet @ 2011-09-04 8:12 UTC (permalink / raw)
To: kaber; +Cc: davem, netfilter-devel, netdev
In-Reply-To: <1315070771-18576-3-git-send-email-kaber@trash.net>
Le samedi 03 septembre 2011 à 19:26 +0200, kaber@trash.net a écrit :
> +struct sk_buff *__alloc_skb_head(gfp_t gfp_mask, int node)
> +{
> + struct sk_buff *skb;
> +
> + /* Get the HEAD */
> + skb = kmem_cache_alloc_node(skbuff_head_cache,
> + gfp_mask & ~__GFP_DMA, node);
> + if (!skb)
> + goto out;
> + prefetchw(skb);
Please remove this prefetchw(), since we have no delay between it and
actual memset(skb).
> +
> + /*
> + * Only clear those fields we need to clear, not those that we will
> + * actually initialise below. Hence, don't put any more fields after
> + * the tail pointer in struct sk_buff!
> + */
> + memset(skb, 0, offsetof(struct sk_buff, tail));
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH -next v2] unix stream: Fix use-after-free crashes
From: Yan, Zheng @ 2011-09-04 8:23 UTC (permalink / raw)
To: sedat.dilek
Cc: netdev@vger.kernel.org, davem@davemloft.net, sfr@canb.auug.org.au,
tim.c.chen@linux.intel.com, jirislaby@gmail.com
In-Reply-To: <CA+icZUU25QMMCVT1VfF9XB0wrkppNmKQbHwoHDAQ-qV9bi+HqQ@mail.gmail.com>
On Sun, Sep 4, 2011 at 3:12 PM, Sedat Dilek <sedat.dilek@googlemail.com> wrote:
> On Sun, Sep 4, 2011 at 7:44 AM, Yan, Zheng <zheng.z.yan@intel.com> wrote:
>> Commit 0856a30409 (Scm: Remove unnecessary pid & credential references
>> in Unix socket's send and receive path) introduced a use-after-free bug.
>> It passes the scm reference to the first skb. Skb(s) afterwards may
>> reference freed data structure because the first skb can be destructed
>> by the receiver at anytime. The fix is by passing the scm reference to
>> the very last skb.
>>
>
> s/by passing/bypassing ?
No
>
>> Signed-off-by: Zheng Yan <zheng.z.yan@intel.com>
>> Reported-by: Jiri Slaby <jirislaby@gmail.com>
>> ---
>
> Tested on i386 against linux-next (next-20110831).
>
Thank you.
> - Sedat -
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] usbnet: ignore get interface retval of -EINPROGRESS
From: Oliver Neukum @ 2011-09-04 10:16 UTC (permalink / raw)
To: Jim Wylder; +Cc: netdev
In-Reply-To: <CAPopfEWi0v9VXeDYcBfEgnWYxg7WcTTj3GBc6USzwcN+aGrKOQ@mail.gmail.com>
Am Samstag, 3. September 2011, 19:32:44 schrieb Jim Wylder:
Hi,
> Thanks for the quick feedback. True usbnet_start_xmit() could be
> running at anytime, but the usb_autopm_get_interface_async() will only
> return -EINPROGRESS when rpm_resume detects that
> dev->power.runtime_status == RPM_RESUMING. My understanding is that
> for an asynchronous request, the promise that the device is resuming
> would be equivalent to cases where usb_autopm_get_interface_async()
> returns success.
If CONFIG_PM is set.
> In all other cases, when we are not attempting to resume an already
> resuming interface, this change should have no impact.
>
> Are you recommending that I add an additional check for DEV_ASLEEP,
The check is already there but depending on CONFIG_PM.
> possibly to decide whether to drop the or continue on? Or am I
> missing your point? I had not done anything similar because my
> understanding was that knowing that the device is in fact resuming
> would be sufficient.
At that point it is sufficient. Upon further thought it looks like your check
is correct.
We just need to make very sure that for the decision to queue or
to submit EVENT_DEV_ASLEEP is relevant.
Would you consider defining a macro with a nice name for the
==0 || == -EINPROGRESS check, so that any reader knows what
this is about? This is because I doubt only usbnet is affected.
Regards
Oliver
^ permalink raw reply
* Re: linux-next: Tree for Aug 26 (git-bisect: [0856a30] Scm: Remove unnecessary pid & credential references in Unix socket's send and receive path)
From: Sedat Dilek @ 2011-09-04 10:43 UTC (permalink / raw)
To: Stephen Rothwell, tim.c.chen
Cc: linux-next, LKML, jirislaby, David Miller, Yan, Zheng,
Valdis.Kletnieks, netdev
In-Reply-To: <CA+icZUXOnoG07Z8-AAUNqvuJmq6-OY1_dTzkxsBOLczoNYYGEw@mail.gmail.com>
On Fri, Sep 2, 2011 at 11:43 PM, Sedat Dilek <sedat.dilek@googlemail.com> wrote:
> On Fri, Aug 26, 2011 at 7:00 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> Hi all,
>>
>> The powerpc allyesconfig build still fails today.
>>
>> Changes since 20110825:
>>
>> The slave-dma tree gained a conflict against Linus' tree.
>>
>> I have reverted the x86/spinlocks branch from the tip tree for today.
>>
>> The ptrace tree lost its build failure.
>>
>> The xen tree lost its conflict since I reveretd the version of the same
>> patches in the tip tree..
>>
>> The tty tree still has its build failure but I applied a supplied test
>> patch for it.
>>
>> The staging tree lost its build failures and gained a conflict against
>> the net tree.
>>
>> The moduleh tree lost a conflict.
>>
>> The akpm tree lost its build failure.
>>
>> ----------------------------------------------------------------------------
>>
>
> Hi,
>
> I saw diverse strange kernel-panics letting my notebook blink and
> scream a high-frequency tone, really ugly.
>
> My last good linux-next (l-n) kernel was next-20110818 and the next
> l-n kernel in series which I built and was broken: next-20110826.
> ( BTW, 29/31 Aug are broken too. )
>
> For the correctness I built 22/23/24/25 Aug which were all good.
> As usual when I do once a year a git-bisect... its the last step of 12
> steps in total (see git-bisect_visualize.txt and
> git-bisect_view-stat.txt).
>
> I was irritated by using next-20110825 and next-20110826 as git-bisect
> good and bad, as the first offered commit-id pointed me to
> 3.1-rc1-665-gec5efe7, but I was sure the culprit is definitely
> v3.1-rc3+ and furthermore I got no info how many revisions have to be
> walked through. So, I cancelled this run.
>
> Next thought was to do a git format-patch using above mentionned
> commit-ids (of the tags): 819 single patches.
> I took the commit-ids of 0001 (good) and 0818 (bad) - 0819 was
> linux-specific mumbo-jumbo.
>
> Jiri has reported a similiar breakage in [2] and returning CULPRIT
> commit [1] helped him.
> ( This git-bisect steal a whole Friday. Anyway, it's good to see we
> isolated the "bad" patch. )
>
> As a personal conclusion, trust more git-bisect...
> It does not hurt to NOT turn off brain my looking over the single
> patches, there were lots of staging, arm, powerpc which could be
> surely ignored, but in the end you are wiser - 12 steps are faster
> than reverting xxx single commits on spec.
>
> - Sedat -
>
> [1] http://git.us.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=0856a304091b33a8e8f9f9c98e776f425af2b625
> [2] http://lkml.org/lkml/2011/9/1/332
> [3] http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
> [4] http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#using-bisect
>
> P.S.: Used 0001 (good) and 0818 (bad) for git-bisect
>
> $ head -5 0001-target-Change-TCM_NON_EXISTENT_LUN-response-to-ASC-L.patch
> 0818-Fixes-the-deadlock-when-inserting-and-removing-the-d.patch
> ==> 0001-target-Change-TCM_NON_EXISTENT_LUN-response-to-ASC-L.patch <==
> From eb39d34004888afcc0a44d9c36383cd69fa3b3b9 Mon Sep 17 00:00:00 2001
> From: Nicholas Bellinger <nab@linux-iscsi.org>
> Date: Tue, 26 Jul 2011 16:59:00 -0700
> Subject: [PATCH 001/819] target: Change TCM_NON_EXISTENT_LUN response to
> ASC=LOGICAL UNIT NOT SUPPORTED
>
> ==> 0818-Fixes-the-deadlock-when-inserting-and-removing-the-d.patch <==
> From 9b198e560524e3fe341cd2ae478a1cdf2f57fc33 Mon Sep 17 00:00:00 2001
> From: Clifton Barnes <cabarnes@indesign-llc.com>
> Date: Thu, 25 Aug 2011 09:47:59 +1000
> Subject: [PATCH 818/819] Fixes the deadlock when inserting and removing the
> ds2780.
>
Issue fixed, see "[PATCH -next v2] unix stream: Fix use-after-free crashes" [1].
- Sedat -
[1] http://marc.info/?l=linux-netdev&m=131511507007022&w=2
^ permalink raw reply
* [PATCH 2/2] net: Handle different key sizes between address families in flow cache
From: David Ward @ 2011-09-04 13:07 UTC (permalink / raw)
To: netdev; +Cc: Julian Anastasov, David Ward
In-Reply-To: <alpine.LFD.2.00.1109031004500.1492@ja.ssi.bg>
With the conversion of struct flowi to a union of AF-specific structs, some
operations on the flow cache need to account for the exact size of the key.
Signed-off-by: David Ward <david.ward@ll.mit.edu>
---
include/net/flow.h | 19 +++++++++++++++++++
net/core/flow.c | 28 ++++++++++++++++------------
2 files changed, 35 insertions(+), 12 deletions(-)
diff --git a/include/net/flow.h b/include/net/flow.h
index 2ec377d..99119f6 100644
--- a/include/net/flow.h
+++ b/include/net/flow.h
@@ -7,6 +7,7 @@
#ifndef _NET_FLOW_H
#define _NET_FLOW_H
+#include <linux/socket.h>
#include <linux/in6.h>
#include <linux/atomic.h>
@@ -161,6 +162,24 @@ static inline struct flowi *flowidn_to_flowi(struct flowidn *fldn)
return container_of(fldn, struct flowi, u.dn);
}
+typedef unsigned long flow_compare_t;
+
+static inline size_t flowi_size(u16 family)
+{
+ switch (family) {
+ case AF_INET:
+ BUILD_BUG_ON(sizeof(struct flowi4) % sizeof(flow_compare_t));
+ return sizeof(struct flowi4);
+ case AF_INET6:
+ BUILD_BUG_ON(sizeof(struct flowi6) % sizeof(flow_compare_t));
+ return sizeof(struct flowi6);
+ case AF_DECnet:
+ BUILD_BUG_ON(sizeof(struct flowidn) % sizeof(flow_compare_t));
+ return sizeof(struct flowidn);
+ }
+ return 0;
+}
+
#define FLOW_DIR_IN 0
#define FLOW_DIR_OUT 1
#define FLOW_DIR_FWD 2
diff --git a/net/core/flow.c b/net/core/flow.c
index bf32c33..1545445 100644
--- a/net/core/flow.c
+++ b/net/core/flow.c
@@ -172,26 +172,24 @@ static void flow_new_hash_rnd(struct flow_cache *fc,
static u32 flow_hash_code(struct flow_cache *fc,
struct flow_cache_percpu *fcp,
- const struct flowi *key)
+ const struct flowi *key,
+ size_t keysize)
{
const u32 *k = (const u32 *) key;
- return jhash2(k, (sizeof(*key) / sizeof(u32)), fcp->hash_rnd)
+ return jhash2(k, (keysize / sizeof(u32)), fcp->hash_rnd)
& (flow_cache_hash_size(fc) - 1);
}
-typedef unsigned long flow_compare_t;
-
/* I hear what you're saying, use memcmp. But memcmp cannot make
* important assumptions that we can here, such as alignment and
- * constant size.
+ * size.
*/
-static int flow_key_compare(const struct flowi *key1, const struct flowi *key2)
+static int flow_key_compare(const struct flowi *key1, const struct flowi *key2,
+ size_t keysize)
{
const flow_compare_t *k1, *k1_lim, *k2;
- const int n_elem = sizeof(struct flowi) / sizeof(flow_compare_t);
-
- BUILD_BUG_ON(sizeof(struct flowi) % sizeof(flow_compare_t));
+ const int n_elem = keysize / sizeof(flow_compare_t);
k1 = (const flow_compare_t *) key1;
k1_lim = k1 + n_elem;
@@ -215,6 +213,7 @@ flow_cache_lookup(struct net *net, const struct flowi *key, u16 family, u8 dir,
struct flow_cache_entry *fle, *tfle;
struct hlist_node *entry;
struct flow_cache_object *flo;
+ size_t keysize;
unsigned int hash;
local_bh_disable();
@@ -222,6 +221,11 @@ flow_cache_lookup(struct net *net, const struct flowi *key, u16 family, u8 dir,
fle = NULL;
flo = NULL;
+
+ keysize = flowi_size(family);
+ if (!keysize)
+ goto nocache;
+
/* Packet really early in init? Making flow_cache_init a
* pre-smp initcall would solve this. --RR */
if (!fcp->hash_table)
@@ -230,11 +234,11 @@ flow_cache_lookup(struct net *net, const struct flowi *key, u16 family, u8 dir,
if (fcp->hash_rnd_recalc)
flow_new_hash_rnd(fc, fcp);
- hash = flow_hash_code(fc, fcp, key);
+ hash = flow_hash_code(fc, fcp, key, keysize);
hlist_for_each_entry(tfle, entry, &fcp->hash_table[hash], u.hlist) {
if (tfle->family == family &&
tfle->dir == dir &&
- flow_key_compare(key, &tfle->key) == 0) {
+ flow_key_compare(key, &tfle->key, keysize) == 0) {
fle = tfle;
break;
}
@@ -248,7 +252,7 @@ flow_cache_lookup(struct net *net, const struct flowi *key, u16 family, u8 dir,
if (fle) {
fle->family = family;
fle->dir = dir;
- memcpy(&fle->key, key, sizeof(*key));
+ memcpy(&fle->key, key, keysize);
fle->object = NULL;
hlist_add_head(&fle->u.hlist, &fcp->hash_table[hash]);
fcp->hash_count++;
--
1.7.1
^ permalink raw reply related
* [PATCH 0/2] Fixes to flow cache for AF-specifc flowi structs
From: David Ward @ 2011-09-04 13:07 UTC (permalink / raw)
To: netdev; +Cc: Julian Anastasov, David Ward
In-Reply-To: <alpine.LFD.2.00.1109031004500.1492@ja.ssi.bg>
These fixes to the flow cache are needed with the conversion to AF-specific
flowi structs. They are written so as to avoid introducing AF-specific code
into net/core/flow.c.
Note that __xfrm_policy_check (in net/xfrm/xfrm_policy.c) still allocates a
struct flowi on the stack and passes it to flow_cache_lookup. My understanding
is that since this is on the stack, this will not be aligned, and therefore it
will cause problems with flow_hash_code and flow_key_compare. Is that correct?
Signed-off-by: David Ward <david.ward@ll.mit.edu>
David Ward (2):
net: Align AF-specific flowi structs to long
net: Handle different key sizes between address families in flow
cache
include/net/flow.h | 25 ++++++++++++++++++++++---
net/core/flow.c | 28 ++++++++++++++++------------
2 files changed, 38 insertions(+), 15 deletions(-)
^ permalink raw reply
* [PATCH 1/2] net: Align AF-specific flowi structs to long
From: David Ward @ 2011-09-04 13:07 UTC (permalink / raw)
To: netdev; +Cc: Julian Anastasov, David Ward
In-Reply-To: <alpine.LFD.2.00.1109031004500.1492@ja.ssi.bg>
AF-specific flowi structs are now passed to flow_key_compare, which must
also be aligned to a long.
Signed-off-by: David Ward <david.ward@ll.mit.edu>
---
include/net/flow.h | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/net/flow.h b/include/net/flow.h
index 78113da..2ec377d 100644
--- a/include/net/flow.h
+++ b/include/net/flow.h
@@ -68,7 +68,7 @@ struct flowi4 {
#define fl4_ipsec_spi uli.spi
#define fl4_mh_type uli.mht.type
#define fl4_gre_key uli.gre_key
-};
+} __attribute__((__aligned__(BITS_PER_LONG/8)));
static inline void flowi4_init_output(struct flowi4 *fl4, int oif,
__u32 mark, __u8 tos, __u8 scope,
@@ -112,7 +112,7 @@ struct flowi6 {
#define fl6_ipsec_spi uli.spi
#define fl6_mh_type uli.mht.type
#define fl6_gre_key uli.gre_key
-};
+} __attribute__((__aligned__(BITS_PER_LONG/8)));
struct flowidn {
struct flowi_common __fl_common;
@@ -127,7 +127,7 @@ struct flowidn {
union flowi_uli uli;
#define fld_sport uli.ports.sport
#define fld_dport uli.ports.dport
-};
+} __attribute__((__aligned__(BITS_PER_LONG/8)));
struct flowi {
union {
--
1.7.1
^ permalink raw reply related
* Re: [next] unix stream crashes
From: Valdis.Kletnieks @ 2011-09-04 14:43 UTC (permalink / raw)
To: Yan, Zheng
Cc: Jiri Slaby, sedat.dilek, Sedat Dilek, Tim Chen, David S. Miller,
ML netdev, LKML, Stephen Rothwell
In-Reply-To: <CAAM7YAkB3VVNMmBMVuvEZuV6oGZeyog37_sjFGUunu+15apvZA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 321 bytes --]
On Sat, 03 Sep 2011 20:30:19 +0800, "Yan, Zheng " said:
> The skb can be destructed before the while loop in unix_stream_sendmsg stops.
> please try below patch.
Tried this on top of next-20110831, and system is up and running fine.
Feel free to stick this on it:
Tested-By: Valdis Kletnieks <valdis.kletnieks@vt.edu>
[-- Attachment #2: Type: application/pgp-signature, Size: 227 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] net: Handle different key sizes between address families in flow cache
From: Michał Mirosław @ 2011-09-04 15:34 UTC (permalink / raw)
To: David Ward; +Cc: netdev, Julian Anastasov
In-Reply-To: <1315141641-3120-3-git-send-email-david.ward@ll.mit.edu>
2011/9/4 David Ward <david.ward@ll.mit.edu>:
> With the conversion of struct flowi to a union of AF-specific structs, some
> operations on the flow cache need to account for the exact size of the key.
[...]
> --- a/include/net/flow.h
> +++ b/include/net/flow.h
[...]
> +typedef unsigned long flow_compare_t;
> +
> +static inline size_t flowi_size(u16 family)
> +{
> + switch (family) {
> + case AF_INET:
> + BUILD_BUG_ON(sizeof(struct flowi4) % sizeof(flow_compare_t));
> + return sizeof(struct flowi4);
> + case AF_INET6:
> + BUILD_BUG_ON(sizeof(struct flowi6) % sizeof(flow_compare_t));
> + return sizeof(struct flowi6);
> + case AF_DECnet:
> + BUILD_BUG_ON(sizeof(struct flowidn) % sizeof(flow_compare_t));
> + return sizeof(struct flowidn);
> + }
> + return 0;
> +}
Since most called user (flow_key_compare) uses returned value didided
by sizeof(flow_compare_t), you could just return divided value here
and save some shift operations by it.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [PATCH -next v2] unix stream: Fix use-after-free crashes
From: Joe Perches @ 2011-09-04 15:50 UTC (permalink / raw)
To: Yan, Zheng
Cc: sedat.dilek, netdev@vger.kernel.org, davem@davemloft.net,
sfr@canb.auug.org.au, tim.c.chen@linux.intel.com,
jirislaby@gmail.com
In-Reply-To: <CAAM7YAk0csJLLVFF6KYA8vMG_BN6QDvmYvtnY0Sq7P=cBsuKfg@mail.gmail.com>
On Sun, 2011-09-04 at 16:23 +0800, Yan, Zheng wrote:
> On Sun, Sep 4, 2011 at 3:12 PM, Sedat Dilek <sedat.dilek@googlemail.com> wrote:
> > On Sun, Sep 4, 2011 at 7:44 AM, Yan, Zheng <zheng.z.yan@intel.com> wrote:
> >> It passes the scm reference to the first skb. Skb(s) afterwards may
> >> reference freed data structure because the first skb can be destructed
> >> by the receiver at anytime. The fix is by passing the scm reference to
> >> the very last skb.
> > s/by passing/bypassing ?
> No
(putting on my Randy Dunlap hat)
The issue was fixed by passing...
or maybe
The fix is to pass...
^ permalink raw reply
* Re: [PATCH 08/11] netlink: implement memory mapped sendmsg()
From: Michał Mirosław @ 2011-09-04 16:18 UTC (permalink / raw)
To: kaber; +Cc: davem, netfilter-devel, netdev
In-Reply-To: <1315070771-18576-9-git-send-email-kaber@trash.net>
On Sat, Sep 03, 2011 at 07:26:08PM +0200, kaber@trash.net wrote:
> From: Patrick McHardy <kaber@trash.net>
>
> Add support for memory mapped sendmsg() to netlink. Userspace queued to
> be processed frames into the TX ring and invokes sendmsg with
> msg.iov.iov_base = NULL to trigger processing of all pending messages.
>
> Since the kernel usually performs full message validation before beginning
> processing, userspace must be prevented from modifying the message
> contents while the kernel is processing them. In order to do so, the
> frames contents are copied to an allocated skb in case the the ring is
> mapped more than once or the file descriptor is shared (f.i. through
> AF_UNIX file descriptor passing).
>
> Otherwise an skb without a data area is allocated, the data pointer set
> to point to the data area of the ring frame and the skb is processed.
> Once the skb is freed, the destructor releases the frame back to userspace
> by setting the status to NL_MMAP_STATUS_UNUSED.
Is this protected from threads? Like: one thread waits on sendmsg() and
another (same process) changes the buffer.
Best Regards,
Michał Mirosław
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] bridge: leave carrier on for empty bridge
From: Stephen Hemminger @ 2011-09-04 16:36 UTC (permalink / raw)
To: Nicolas de Pesloüan; +Cc: David S. Miller, netdev
In-Reply-To: <4E632A2E.5040805@gmail.com>
On Sun, 04 Sep 2011 09:35:10 +0200
Nicolas de Pesloüan <nicolas.2p.debian@gmail.com> wrote:
> Le 04/09/2011 06:14, Stephen Hemminger a écrit :
>
> >> Instead of asserting carrier when the bridge have no port, can't we assert carrier when the three
> >> following condition are true at the same time :
> >>
> >> - The bridge have no port.
> >> - At least one IP address is setup on the bridge.
> >> - The two above conditions are true for more than a configurable amount of seconds, with a default
> >> of 10, for example.
> >>
> >> This would only delay carrier on for a few seconds for the regression and keep the current behavior
> >> (carrier off until at least 1 port is on) for DHCP.
> >
> > This fails on two counts:
> > 1. Bridge's often run without IP addresses!
> > 2. DHCP won't try and send out request until carrier is true.
>
> Sorry, I missed to say that we should of course also assert carrier on if one port has carrier on.
>
> And rethinking about it, the delay is probably useless :
>
> bridge_carrier_on = at_least_one_port_has_carrier_on | (bridge_has_no_port & bridge_has_at_least_one_ip)
>
> That way :
> - for those using bridge without any port, manually setting the IP will assert carrier on. (By the
> way, why don't they use a dummy device instead?)
>
> - for those using bridge with ports:
> -- Using any kind of autoconfig will work as expected. Carrier will only be asserted at the time
> first port get carrier.
> -- Using static IP confifiguration, carrier will possibly be erroneously reported as on during the
> small time gap between IP address configuration and first port is added to the bridge. This time gap
> may be removed by simply configuring the IP after the first port is added. This is probably already
> true for most distribs. And anyway, this time gap is probably not a problem.
> -- Carrier will also be erroneously reported as on after removing the last port, if the bridge still
> has an IP. (But we can arrange for this not to happen).
>
> And in order to ensure user really understand why carrier is on of off, we can simply issue an INFO
> message for the non-natural case (bridge_has_no_port & bridga_has_at_least_one_ip).
>
> I consider all this reasonable.
>
> Nicolas.
Any bridge behaviour based on IP address configuration is a
layering violation and won't work. The problem is related to dynamic issues
with IPv6 and DHCP and needs to be addressed at that level.
^ permalink raw reply
* Re: [PATCH 1/2] bridge: leave carrier on for empty bridge
From: Krzysztof Olędzki @ 2011-09-04 17:12 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Nicolas de Pesloüan, David S. Miller, netdev
In-Reply-To: <20110904093634.685d7c56@nehalam.ftrdhcpuser.net>
On 2011-09-04 18:36, Stephen Hemminger wrote:
> On Sun, 04 Sep 2011 09:35:10 +0200
> Nicolas de Pesloüan<nicolas.2p.debian@gmail.com> wrote:
>
>> Le 04/09/2011 06:14, Stephen Hemminger a écrit :
>>
>>>> Instead of asserting carrier when the bridge have no port, can't we assert carrier when the three
>>>> following condition are true at the same time :
>>>>
>>>> - The bridge have no port.
>>>> - At least one IP address is setup on the bridge.
>>>> - The two above conditions are true for more than a configurable amount of seconds, with a default
>>>> of 10, for example.
>>>>
>>>> This would only delay carrier on for a few seconds for the regression and keep the current behavior
>>>> (carrier off until at least 1 port is on) for DHCP.
>>>
>>> This fails on two counts:
>>> 1. Bridge's often run without IP addresses!
>>> 2. DHCP won't try and send out request until carrier is true.
>>
>> Sorry, I missed to say that we should of course also assert carrier on if one port has carrier on.
>>
>> And rethinking about it, the delay is probably useless :
>>
>> bridge_carrier_on = at_least_one_port_has_carrier_on | (bridge_has_no_port& bridge_has_at_least_one_ip)
>>
>> That way :
>> - for those using bridge without any port, manually setting the IP will assert carrier on. (By the
>> way, why don't they use a dummy device instead?)
>>
>> - for those using bridge with ports:
>> -- Using any kind of autoconfig will work as expected. Carrier will only be asserted at the time
>> first port get carrier.
>> -- Using static IP confifiguration, carrier will possibly be erroneously reported as on during the
>> small time gap between IP address configuration and first port is added to the bridge. This time gap
>> may be removed by simply configuring the IP after the first port is added. This is probably already
>> true for most distribs. And anyway, this time gap is probably not a problem.
>> -- Carrier will also be erroneously reported as on after removing the last port, if the bridge still
>> has an IP. (But we can arrange for this not to happen).
>>
>> And in order to ensure user really understand why carrier is on of off, we can simply issue an INFO
>> message for the non-natural case (bridge_has_no_port& bridga_has_at_least_one_ip).
>>
>> I consider all this reasonable.
>>
>> Nicolas.
>
> Any bridge behaviour based on IP address configuration is a
> layering violation and won't work. The problem is related to dynamic issues
> with IPv6 and DHCP and needs to be addressed at that level.
Maybe we can simply add a switch controlling if a bridge with no
attached ports has carrier off (default) or on.
For example:
echo {0|1} > /sys/devices/virtual/net/brX/bridge/orphaned_carrier
brctl orphaned_carrier brX {on|off}
Best regards,
Krzysztof Olędzki
^ permalink raw reply
* Re: [PATCH 2/2] Add a netlink attribute INET_DIAG_SECCTX
From: Rongqing Li @ 2011-09-05 0:32 UTC (permalink / raw)
To: Paul Moore; +Cc: netdev, selinux, linux-security-module
In-Reply-To: <1971656.b979ahlREa@sifl>
On 09/01/2011 08:28 PM, Paul Moore wrote:
> On Thursday, September 01, 2011 05:33:07 PM Rongqing Li wrote:
>> On 09/01/2011 05:18 AM, Paul Moore wrote:
>>> On Wednesday, August 31, 2011 04:36:17 PM rongqing.li@windriver.com wrote:
>>>> From: Roy.Li<rongqing.li@windriver.com>
>>>>
>>>> Add a new netlink attribute INET_DIAG_SECCTX to dump the security
>>>> context of TCP sockets.
>>>
>>> You'll have to forgive me, I'm not familiar with the netlink code used
>>> by
>>> netstat and friends, but is there anyway to report back the security
>>> context of UDP sockets? Or does the code below handle that already?
>>>
>>> In general, AF_INET and AF_INET6 sockets, regardless of any upper level
>>> protocols, have security contexts associated with them and it would be
>>> nice to see them in netstat.
>>
>> Yes, this is real concern, If the dumping tcp security context can be
>> accepted by netdev, I am planning to implement it for ipv4 udp socket, unix
>> socket. then ipv6..
>
> Great, I'm glad to hear you're planning on implementing this for more than
> just TCP.
>
> I understand your desire to have the basic idea accepted with only TCP
> implemented - and that is fine with me - but I would like to see support for
> all of the protocols merged at the same time. In other words, seeking the
> basic ACKs for TCP from the davem, et al is okay but I'd like to defer merging
> TCP support until you have everything implemented and ready to be merged.
>
Ok, I will try
--
Best Reagrds,
Roy | RongQing Li
^ permalink raw reply
* Re: [PATCH 1/2] bridge: leave carrier on for empty bridge
From: Ang Way Chuang @ 2011-09-05 4:51 UTC (permalink / raw)
To: Krzysztof Olędzki
Cc: Stephen Hemminger, Nicolas de Pesloüan, David S. Miller,
netdev, Achmad Basuki
In-Reply-To: <4E63B175.6020106@ans.pl>
On 05/09/11 02:12, Krzysztof Olędzki wrote:
> On 2011-09-04 18:36, Stephen Hemminger wrote:
>> On Sun, 04 Sep 2011 09:35:10 +0200
>> Nicolas de Pesloüan<nicolas.2p.debian@gmail.com> wrote:
>>
>>> Le 04/09/2011 06:14, Stephen Hemminger a écrit :
>>>
>>>>> Instead of asserting carrier when the bridge have no port, can't we assert carrier when the three
>>>>> following condition are true at the same time :
>>>>>
>>>>> - The bridge have no port.
>>>>> - At least one IP address is setup on the bridge.
>>>>> - The two above conditions are true for more than a configurable amount of seconds, with a default
>>>>> of 10, for example.
>>>>>
>>>>> This would only delay carrier on for a few seconds for the regression and keep the current behavior
>>>>> (carrier off until at least 1 port is on) for DHCP.
>>>>
>>>> This fails on two counts:
>>>> 1. Bridge's often run without IP addresses!
>>>> 2. DHCP won't try and send out request until carrier is true.
>>>
>>> Sorry, I missed to say that we should of course also assert carrier on if one port has carrier on.
>>>
>>> And rethinking about it, the delay is probably useless :
>>>
>>> bridge_carrier_on = at_least_one_port_has_carrier_on | (bridge_has_no_port& bridge_has_at_least_one_ip)
>>>
>>> That way :
>>> - for those using bridge without any port, manually setting the IP will assert carrier on. (By the
>>> way, why don't they use a dummy device instead?)
>>>
>>> - for those using bridge with ports:
>>> -- Using any kind of autoconfig will work as expected. Carrier will only be asserted at the time
>>> first port get carrier.
>>> -- Using static IP confifiguration, carrier will possibly be erroneously reported as on during the
>>> small time gap between IP address configuration and first port is added to the bridge. This time gap
>>> may be removed by simply configuring the IP after the first port is added. This is probably already
>>> true for most distribs. And anyway, this time gap is probably not a problem.
>>> -- Carrier will also be erroneously reported as on after removing the last port, if the bridge still
>>> has an IP. (But we can arrange for this not to happen).
>>>
>>> And in order to ensure user really understand why carrier is on of off, we can simply issue an INFO
>>> message for the non-natural case (bridge_has_no_port& bridga_has_at_least_one_ip).
>>>
>>> I consider all this reasonable.
>>>
>>> Nicolas.
>>
>> Any bridge behaviour based on IP address configuration is a
>> layering violation and won't work. The problem is related to dynamic issues
>> with IPv6 and DHCP and needs to be addressed at that level.
>
> Maybe we can simply add a switch controlling if a bridge with no attached ports has carrier off (default) or on.
>
> For example:
> echo {0|1} > /sys/devices/virtual/net/brX/bridge/orphaned_carrier
>
> brctl orphaned_carrier brX {on|off}
>
> Best regards,
>
> Krzysztof Olędzki
My colleague investigated the problem. In the case of libvirt, there are 2 issues at hand:
- dnsmasq cannot bind to port 53 for IPv6 address, therefore fails.
- radvd fails to start because the interface is treated as being down.
This blog entry from Daniel Berrange explains the configuration used by libvirt:
http://berrange.com/posts/2011/06/16/providing-ipv6-connectivity-to-virtual-guests-with-libvirt-and-kvm/
It's quite possible that other users may have the same problem in the future if they plan to use radvd or
dnsmasq on a bridge interface. I'm not sure if there are other applications that depend on the carrier on
a bridge interface to function properly. Come to think of it, unless the user is aware of the change
in carrier on the bridge interface, it is very hard for them to diagnose the problem and apply the right
solution (toggling the carrier). Ideally, there is no reason why dnsmasq and radvd should be started if
there is no port attached to a bridge interface. But, we cannot assume that's how it is done.
I think that it is prudent that the whole commit should be reverted because the problem may not be limited
to libvirt use case.
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox