* Re: [PATCH] iproute2: dont filter cached routes on iproute_get
From: Stephen Hemminger @ 2010-08-23 15:15 UTC (permalink / raw)
To: Ulrich Weber; +Cc: Andreas Henriksson, Fabio Comolli, netdev
In-Reply-To: <20100812090519.GA13769@babylon>
On Thu, 12 Aug 2010 11:05:19 +0200
Ulrich Weber <uweber@astaro.com> wrote:
> iproute_get will return cloned routes for IPv4
> and cloned as well non-cloned routes for IPv6.
>
> Therefore RTM_F_CLONED flag should not be checked
> for iproute_get routes. Check in print_route will
> always fail because valid values are 0 and 1.
>
> Signed-off-by: Ulrich Weber <uweber@astaro.com>
> ---
> ip/iproute.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/ip/iproute.c b/ip/iproute.c
> index 711576e..b43933c 100644
> --- a/ip/iproute.c
> +++ b/ip/iproute.c
> @@ -1286,6 +1286,7 @@ int iproute_get(int argc, char **argv)
> memset(&req, 0, sizeof(req));
>
> iproute_reset_filter();
> + filter.cloned = 2;
>
> req.n.nlmsg_len = NLMSG_LENGTH(sizeof(struct rtmsg));
> req.n.nlmsg_flags = NLM_F_REQUEST;
Applied
--
^ permalink raw reply
* Re: RFC: MTU for serving NFS on Infiniband
From: Ben Hutchings @ 2010-08-23 15:12 UTC (permalink / raw)
To: Marc Aurele La France; +Cc: linux-kernel, netdev
In-Reply-To: <alpine.LNX.2.00.1008230842290.9325@abcyxhiz.aict.ualberta.ca>
On Mon, 2010-08-23 at 08:44 -0600, Marc Aurele La France wrote:
> My apologies for the multiple post. I got bit the first time around by my
> MUA's configuration.
>
> ----
>
> Greetings.
>
> For some time now, the kernel and I have been having an argument over what
> the MTU should be for serving NFS over Infiniband. I say 65520, the
> documented maximum for connected mode. But, so far, I've been unable to have
> anything over 32192 remain stable.
>
> Back in the 2.6.14 -> .15 period, sunrpc's sk_buff allocations were changed
> from GFP_KERNEL to GFP_ATOMIC (b079fa7baa86b47579f3f60f86d03d21c76159b8
> mainstream commit). Understandably, this was to prevent recursion through
> the NFS and sunrpc code. This is fine for the most common MTU out there, as
> the kernel is almost certain to find a free page. But, as one increases the
> MTU, memory fragmentation starts to play a role in nixing these allocations.
[...]
I'm not familiar with the NFS server, but what you're saying suggests
that this code needs a more radical rethink.
Firstly, I don't see why NFS should require each packet's payload to be
contiguous. It could use page fragments and then leave it to the
networking core to linearize the buffer if necessary for stupid
hardware.
Secondly, if it's doing its own segmentation it can't take advantage of
TSO. This is likely to be a real drag on performance. If it were
taking advantage of TSO then the effective MTU over TCP/IP could be
about 64K and it would already have hit this problem on Ethernet.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] driver core: platform_bus: allow runtime override of dev_pm_ops
From: Grant Likely @ 2010-08-23 15:12 UTC (permalink / raw)
To: Kevin Hilman, linux-kernel
Cc: Magnus Damm, Greg Kroah-Hartman, Uwe Kleine-König,
Paul Mundt, Magnus Damm, Eric Miao, linux-kernel, netdev
In-Reply-To: <1282575949-27826-1-git-send-email-khilman@deeprootsystems.com>
"Kevin Hilman" <khilman@deeprootsystems.com> wrote:
>From: Kevin Hilman <khilman@ti.com>
>
>Currently, the platform_bus allows customization of several of the
>busses dev_pm_ops methods by using weak symbols so that platform code
>can override them. The weak-symbol approach is not scalable when
>wanting to support multiple platforms in a single kernel binary.
>
>Instead, provide __init methods for platform code to customize the
>dev_pm_ops methods at runtime.
>
>NOTE: after these dynamic methods are merged, the weak symbols should
> be removed from drivers/base/platform.c. AFAIK, this will only
> affect SH and sh-mobile which should be converted to use this
> runtime approach instead of the weak symbols. After SH &
> sh-mobile are converted, the weak symobols could be removed.
>
>Tested on OMAP3.
>
>Cc: Grant Likely <grant.likely@secretlab.ca>
>Cc: Magnus Damm <magnus.damm@gmail.com>
>Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
>---
> drivers/base/platform.c | 16 ++++++++++++++++
> include/linux/platform_device.h | 3 +++
> 2 files changed, 19 insertions(+), 0 deletions(-)
>
>diff --git a/drivers/base/platform.c b/drivers/base/platform.c
>index c6c933f..a7d8a00 100644
>--- a/drivers/base/platform.c
>+++ b/drivers/base/platform.c
>@@ -976,6 +976,22 @@ struct bus_type platform_bus_type = {
> };
> EXPORT_SYMBOL_GPL(platform_bus_type);
>
>+const struct dev_pm_ops * __init platform_bus_get_pm_ops(void)
>+{
>+ struct bus_type *bus = &platform_bus_type;
>+
>+ return bus->pm;
>+}
>+
>+int __init platform_bus_set_pm_ops(struct dev_pm_ops *pm)
>+{
>+ struct bus_type *bus = &platform_bus_type;
>+
>+ bus->pm = pm;
>+
>+ return 0;
>+}
>+
Looks okay to me, but these functions should have kerneldoc headers describing what they are, and more importantly, the constraints and what the acceptable use case is.
g.
> int __init platform_bus_init(void)
> {
> int error;
>diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
>index d7ecad0..4bce2c9 100644
>--- a/include/linux/platform_device.h
>+++ b/include/linux/platform_device.h
>@@ -138,6 +138,9 @@ extern struct platform_device *platform_create_bundle(struct platform_driver *dr
> struct resource *res, unsigned int n_res,
> const void *data, size_t size);
>
>+extern const struct dev_pm_ops * __init platform_bus_get_pm_ops(void);
>+extern int __init platform_bus_set_pm_ops(struct dev_pm_ops *pm);
>+
> /* early platform driver interface */
> struct early_platform_driver {
> const char *class_str;
>--
>1.7.2.1
>
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
^ permalink raw reply
* [PATCH] driver core: platform_bus: allow runtime override of dev_pm_ops
From: Kevin Hilman @ 2010-08-23 15:05 UTC (permalink / raw)
To: linux-kernel
Cc: Grant Likely, Magnus Damm, Greg Kroah-Hartman,
Uwe Kleine-König, Paul Mundt, Magnus Damm, Kevin Hilman,
Eric Miao, linux-kernel, netdev
From: Kevin Hilman <khilman@ti.com>
Currently, the platform_bus allows customization of several of the
busses dev_pm_ops methods by using weak symbols so that platform code
can override them. The weak-symbol approach is not scalable when
wanting to support multiple platforms in a single kernel binary.
Instead, provide __init methods for platform code to customize the
dev_pm_ops methods at runtime.
NOTE: after these dynamic methods are merged, the weak symbols should
be removed from drivers/base/platform.c. AFAIK, this will only
affect SH and sh-mobile which should be converted to use this
runtime approach instead of the weak symbols. After SH &
sh-mobile are converted, the weak symobols could be removed.
Tested on OMAP3.
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Magnus Damm <magnus.damm@gmail.com>
Signed-off-by: Kevin Hilman <khilman@deeprootsystems.com>
---
drivers/base/platform.c | 16 ++++++++++++++++
include/linux/platform_device.h | 3 +++
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index c6c933f..a7d8a00 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -976,6 +976,22 @@ struct bus_type platform_bus_type = {
};
EXPORT_SYMBOL_GPL(platform_bus_type);
+const struct dev_pm_ops * __init platform_bus_get_pm_ops(void)
+{
+ struct bus_type *bus = &platform_bus_type;
+
+ return bus->pm;
+}
+
+int __init platform_bus_set_pm_ops(struct dev_pm_ops *pm)
+{
+ struct bus_type *bus = &platform_bus_type;
+
+ bus->pm = pm;
+
+ return 0;
+}
+
int __init platform_bus_init(void)
{
int error;
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index d7ecad0..4bce2c9 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -138,6 +138,9 @@ extern struct platform_device *platform_create_bundle(struct platform_driver *dr
struct resource *res, unsigned int n_res,
const void *data, size_t size);
+extern const struct dev_pm_ops * __init platform_bus_get_pm_ops(void);
+extern int __init platform_bus_set_pm_ops(struct dev_pm_ops *pm);
+
/* early platform driver interface */
struct early_platform_driver {
const char *class_str;
--
1.7.2.1
^ permalink raw reply related
* Re: RFC: MTU for serving NFS on Infiniband
From: Stephen Hemminger @ 2010-08-23 15:05 UTC (permalink / raw)
To: Marc Aurele La France; +Cc: linux-kernel, netdev
In-Reply-To: <alpine.LNX.2.00.1008230842290.9325@abcyxhiz.aict.ualberta.ca>
On Mon, 23 Aug 2010 08:44:37 -0600 (MDT)
Marc Aurele La France <tsi@ualberta.ca> wrote:
> My apologies for the multiple post. I got bit the first time around by my
> MUA's configuration.
>
> ----
>
> Greetings.
>
> For some time now, the kernel and I have been having an argument over what
> the MTU should be for serving NFS over Infiniband. I say 65520, the
> documented maximum for connected mode. But, so far, I've been unable to have
> anything over 32192 remain stable.
>
> Back in the 2.6.14 -> .15 period, sunrpc's sk_buff allocations were changed
> from GFP_KERNEL to GFP_ATOMIC (b079fa7baa86b47579f3f60f86d03d21c76159b8
> mainstream commit). Understandably, this was to prevent recursion through
> the NFS and sunrpc code. This is fine for the most common MTU out there, as
> the kernel is almost certain to find a free page. But, as one increases the
> MTU, memory fragmentation starts to play a role in nixing these allocations.
>
> These allocation failures ultimately result in sparse files being written
> through NFS. Granted, many of my users' application are oblivious to
> this because they don't check for such errors. But it would be nice if the
> kernel were more resilient in this regard.
>
> For a few months now, I've been running with sunrpc sk_buff allocations using
> GFP_NOFS instead, which allows for dirty data to be flushed out and still
> avoids recursion through sunrpc. With this, I've been able to increase the
> stable MTU to 32192. But no further, as eventually there is no dirty data
> left and memory fragmentation becomes mostly due to yet-to-be-sync'ed
> filesystem data. There's also the matter that using GFP_NOFS for this can
> slow down NFS quite a bit.
>
> In regrouping for my next tack at this, I noticed that all stack traces go
> through ip_append_data(). This would be ipv6_append_data() in the IPv6 case.
> A _very_ rough draft that would have ip_append_data() temporarily drop down
> to a smaller fake MTU follows ...
Why doesn't NFS generate page size fragments? Does Infiniband or your
device not support this? Any thing that requires higher order allocation
is going to unstable under load. Let's fix the cause not the apply bandaid
solution to the symptom.
^ permalink raw reply
* Re: [PATCH 2/2] platform: Facilitate the creation of pseudo-platform buses
From: Kevin Hilman @ 2010-08-23 14:53 UTC (permalink / raw)
To: Grant Likely
Cc: Moffett, Kyle D, Patrick Pannuto, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org, magnus.damm@gmail.com,
gregkh@suse.de, Paul Mundt, Magnus Damm, Rafael J. Wysocki,
Eric Miao, Dmitry Torokhov, netdev@vger.kernel.org,
Kyle D Moffett
In-Reply-To: <AANLkTi=WKcb59jJQuLVfqJG07Et+cU75GOC5Lrr_dXR4@mail.gmail.com>
Grant Likely <grant.likely@secretlab.ca> writes:
>>> If the override is global to the platform_bus_type, then the model
>>> will not scale.
>>
>> It will not scale any more (or less) than the current functionality of
>> the driver model which handles this globally. Again, if scalabilty
>> becomes a problem down the road, lets fix it then.
>
> Alright, I can agree to that. I do agree that the runtime override is
> far and away better than the weak symbol approach. However, there
> needs to be some very clear rules in place for users of the override,
> namely that users must understand that they are stewards of the
> platform_bus_type, and must take care to preserve the default
> behaviour for "uninteresting" devices.
Completely agree here.
Any overrides of the dev_pm_ops functions that do not also call the
pm_generic_* functions (or their equivalents) should be suspect.
I'll post a proposal for a runtime override shortly.
> Also, the expectation should be that it is a temporary measure until a
> better abstraction is implemented. It might be that a separate
> bus_type is the way to go (if the multiple driver registration problem
> can be solved) or it might be a way to differentiate pm_ops either
> per-device or per-parent. I'm not sure, but I'm starting on an OMAP
> project soon, so I may very well end up working on this.
Yes, I'll be glad to work on this too, but first I need to get through
reviewing the backlog of all the OMAP drivers we're converting to
runtime PM.
Kevin
^ permalink raw reply
* Re: IPsec: Why do pfkey_getspi and xfrm_alloc_userspi call xfrm_find_acq_byseq?
From: Christophe Gouault @ 2010-08-23 14:47 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <4C727806.3060102@6wind.com>
Christophe Gouault wrote:
> Hi David,
>
> First of all, thank you for your answer.
>
> David Miller wrote:
>> From: Christophe Gouault <christophe.gouault@6wind.com>
>> Date: Thu, 19 Aug 2010 14:55:21 +0200
>>
>>> The call to xfrm_find_acq_byseq() by the pfkey_getspi() and
>>> xfrm_alloc_userspi() functions is quite costly and proves to entail
>>> scalability issues when performing thousands of IKE negotiations with
>>> racoon (from ipsec-tools distribution) or charon (from strongswan
>>> distribution).
>>>
>>> Removing this call in the kernel drastically accelerates the
>>> processing and does not seem to entail functional problems.
>>>
>>> For now, I don't see the point of this call. I need to understand its
>>> purpose, because I'm highly tempted to simply remove it.
>> First of all, removing a function because you don't understand
>> why it's there is rarely a good idea :-)
> Yes, don't worry, I never act that way. I was deliberately a little
> provocative ;-)
>> I think the semantics require that we check for existing ACQUIRE
>> state entries before we allocate an SPI.
> Well, I still don't see in which case this can happen. The only
> situations in which an ACQUIRE state entry is created is when an
> acquire message is raised by the kernel (this creates a temporary
> outbound state) or when a getspi is issued from the userland (this
> creates a temporary state, as far as I know, this is the future
> inbound state negotiated by IKE).
>
> In my humble opinion, issuing a getspi for the output state does not
> make sense since the SPI is chosen by the destination host.
> So the possibly existing ACQUIRE state entry would be the result of a
> former getspi with the same value of the seq field. So this call would
> aim at cancelling a former call to getspi,
Correction: it does not cancel the former call but returns the existing
ACQUIRE state entry.
By the way, is it possible that the first call (to xfrm_find_acq_byseq)
returns a state that the second call (to xfrm_find_acq) would not find?
> maybe to cope with an application that would retry a failed
> negotiation before the former getspi expired?... I'm not really
> convinced by this explanation.
>
> But there are maybe other uses of the getspi call than assigning a SPI
> for the inbound state of an IKE negotiation...
>> The likelyhood of breaking something if you remove the call is very
>> high.
> Probably. I'm still interested in a concrete example ;-)
>
> Christophe
^ permalink raw reply
* Re: [PATCH 1/1] posix clocks: introduce syscall for clock tuning.
From: Arnd Bergmann @ 2010-08-23 14:46 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Richard Cochran, john stultz, linux-api-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20100823134330.GM12892-6jwH94ZQLHl74goWV3ctuw@public.gmane.org>
On Monday 23 August 2010, Matthew Wilcox wrote:
> On Mon, Aug 23, 2010 at 02:57:26PM +0200, Arnd Bergmann wrote:
> > > +static inline int common_clock_adj(const clockid_t which_clock, int ppb,
> > > + struct timespec *tp)
> > > +{
> > > + return -EOPNOTSUPP;
> > > +}
> > > +
> > > static int no_timer_create(struct k_itimer *new_timer)
> > > {
> > > return -EOPNOTSUPP;
> >
> > So we already return -EOPNOTSUPP in some cases? The man page does not document this.
> > I wonder if we should change that to -EINVAL as well.
>
> ENOTTY is the usual errno for "inappropriate ioctl for device". Due to
> the way this patch has been chopped up, I can't tell if that's what is
> intended here.
It's for the CLOCK_* syscall family, which I think is different enough from
an ioctl that ENOTTY makes no sense.
The documented return values of timer_create() are EAGAIN, EINVAL and
ENOMEM.
Arnd
^ permalink raw reply
* RFC: MTU for serving NFS on Infiniband
From: Marc Aurele La France @ 2010-08-23 14:44 UTC (permalink / raw)
To: linux-kernel, netdev
My apologies for the multiple post. I got bit the first time around by my
MUA's configuration.
----
Greetings.
For some time now, the kernel and I have been having an argument over what
the MTU should be for serving NFS over Infiniband. I say 65520, the
documented maximum for connected mode. But, so far, I've been unable to have
anything over 32192 remain stable.
Back in the 2.6.14 -> .15 period, sunrpc's sk_buff allocations were changed
from GFP_KERNEL to GFP_ATOMIC (b079fa7baa86b47579f3f60f86d03d21c76159b8
mainstream commit). Understandably, this was to prevent recursion through
the NFS and sunrpc code. This is fine for the most common MTU out there, as
the kernel is almost certain to find a free page. But, as one increases the
MTU, memory fragmentation starts to play a role in nixing these allocations.
These allocation failures ultimately result in sparse files being written
through NFS. Granted, many of my users' application are oblivious to
this because they don't check for such errors. But it would be nice if the
kernel were more resilient in this regard.
For a few months now, I've been running with sunrpc sk_buff allocations using
GFP_NOFS instead, which allows for dirty data to be flushed out and still
avoids recursion through sunrpc. With this, I've been able to increase the
stable MTU to 32192. But no further, as eventually there is no dirty data
left and memory fragmentation becomes mostly due to yet-to-be-sync'ed
filesystem data. There's also the matter that using GFP_NOFS for this can
slow down NFS quite a bit.
In regrouping for my next tack at this, I noticed that all stack traces go
through ip_append_data(). This would be ipv6_append_data() in the IPv6 case.
A _very_ rough draft that would have ip_append_data() temporarily drop down
to a smaller fake MTU follows ...
diff -adNpru linux-2.6.35.2/net/ipv4/ip_output.c devel-2.6.35.2/net/ipv4/ip_output.c
--- linux-2.6.35.2/net/ipv4/ip_output.c 2010-08-13 14:44:56.000000000 -0600
+++ devel-2.6.35.2/net/ipv4/ip_output.c 2010-08-14 17:09:46.000000000 -0600
@@ -801,10 +801,10 @@ int ip_append_data(struct sock *sk,
int exthdrlen;
int mtu;
int copy;
- int err;
+ int err = 0;
int offset = 0;
unsigned int maxfraglen, fragheaderlen;
- int csummode = CHECKSUM_NONE;
+ int csummode;
struct rtable *rt;
if (flags&MSG_PROBE)
@@ -852,10 +852,9 @@ int ip_append_data(struct sock *sk,
exthdrlen = 0;
mtu = inet->cork.fragsize;
}
- hh_len = LL_RESERVED_SPACE(rt->u.dst.dev);
+ hh_len = LL_RESERVED_SPACE(rt->u.dst.dev);
fragheaderlen = sizeof(struct iphdr) + (opt ? opt->optlen : 0);
- maxfraglen = ((mtu - fragheaderlen) & ~7) + fragheaderlen;
if (inet->cork.length + length > 0xFFFF - fragheaderlen) {
ip_local_error(sk, EMSGSIZE, rt->rt_dst, inet->inet_dport,
@@ -863,6 +862,12 @@ int ip_append_data(struct sock *sk,
return -EMSGSIZE;
}
+ inet->cork.length += length;
+
+retry_with_smaller_mtu_data:
+ csummode = CHECKSUM_NONE;
+ maxfraglen = ((mtu - fragheaderlen) & ~7) + fragheaderlen;
+
/*
* transhdrlen > 0 means that this is the first fragment and we wish
* it won't be fragmented in the future.
@@ -875,15 +880,19 @@ int ip_append_data(struct sock *sk,
skb = skb_peek_tail(&sk->sk_write_queue);
- inet->cork.length += length;
- if (((length > mtu) || (skb && skb_is_gso(skb))) &&
+ if ((err == 0) && ((length > mtu) || (skb && skb_is_gso(skb))) &&
(sk->sk_protocol == IPPROTO_UDP) &&
(rt->u.dst.dev->features & NETIF_F_UFO)) {
err = ip_ufo_append_data(sk, getfrag, from, length, hh_len,
fragheaderlen, transhdrlen, mtu,
flags);
- if (err)
- goto error;
+ if (err) {
+ if (mtu == ETH_DATA_LEN || err != -ENOBUFS)
+ goto error;
+ mtu = ETH_DATA_LEN;
+ goto retry_with_smaller_mtu_data;
+ }
+
return 0;
}
@@ -957,8 +966,12 @@ alloc_new_skb:
time stamped */
ipc->shtx.flags = 0;
}
- if (skb == NULL)
- goto error;
+ if (skb == NULL) {
+ if (mtu == ETH_DATA_LEN || err != -ENOBUFS)
+ goto error;
+ mtu = ETH_DATA_LEN;
+ goto retry_with_smaller_mtu_data;
+ }
/*
* Fill in the control structures
@@ -1112,7 +1125,6 @@ ssize_t ip_append_page(struct sock *sk,
mtu = inet->cork.fragsize;
fragheaderlen = sizeof(struct iphdr) + (opt ? opt->optlen : 0);
- maxfraglen = ((mtu - fragheaderlen) & ~7) + fragheaderlen;
if (inet->cork.length + size > 0xFFFF - fragheaderlen) {
ip_local_error(sk, EMSGSIZE, rt->rt_dst, inet->inet_dport, mtu);
@@ -1123,6 +1135,7 @@ ssize_t ip_append_page(struct sock *sk,
return -EINVAL;
inet->cork.length += size;
+
if ((size + skb->len > mtu) &&
(sk->sk_protocol == IPPROTO_UDP) &&
(rt->u.dst.dev->features & NETIF_F_UFO)) {
@@ -1130,6 +1143,8 @@ ssize_t ip_append_page(struct sock *sk,
skb_shinfo(skb)->gso_type = SKB_GSO_UDP;
}
+retry_with_smaller_mtu_page:
+ maxfraglen = ((mtu - fragheaderlen) & ~7) + fragheaderlen;
while (size > 0) {
int i;
@@ -1153,8 +1168,13 @@ ssize_t ip_append_page(struct sock *sk,
alloclen = fragheaderlen + hh_len + fraggap + 15;
skb = sock_wmalloc(sk, alloclen, 1, sk->sk_allocation);
if (unlikely(!skb)) {
- err = -ENOBUFS;
- goto error;
+ if (mtu == ETH_DATA_LEN) {
+ err = -ENOBUFS;
+ goto error;
+ }
+
+ mtu = ETH_DATA_LEN;
+ goto retry_with_smaller_mtu_page;
}
/*
Now, I don't have this working quite right yet, but in the meantime, I'd
appreciate some comments over whether this is an appropriate path to follow
and/or ideas on other avenues I should be exploring instead.
Thanks.
Marc.
+----------------------------------+----------------------------------+
| Marc Aurele La France | work: 1-780-492-9310 |
| Academic Information and | fax: 1-780-492-1729 |
| Communications Technologies | email: tsi@ualberta.ca |
| 352 General Services Building +----------------------------------+
| University of Alberta | |
| Edmonton, Alberta | Standard disclaimers apply |
| T6G 2H1 | |
| CANADA | |
+----------------------------------+----------------------------------+
^ permalink raw reply
* No subject
From: auto595907 @ 2010-08-23 14:32 UTC (permalink / raw)
To: maciej.rutecki; +Cc: netdev, linux-kernel
>I created a Bugzilla entry at
>https://bugzilla.kernel.org/show_bug.cgi?id=16423
>for your bug report, please add your address to the CC list in
>there, thanks!
>
>--
>Maciej Rutecki
>http://www.maciek.unixy.pl
this patch fixes the bug above
(http://marc.info/?l=netfilter-devel&m=128116762801769&w=2)
thanks.
^ permalink raw reply
* Re: [PATCH] netfilter: xt_condition: add security capability support
From: Jan Engelhardt @ 2010-08-23 14:34 UTC (permalink / raw)
To: Luciano Coelho
Cc: ext Changli Gao, kaber@trash.net, netfilter-devel@vger.kernel.org,
netdev@vger.kernel.org, James Morris,
linux-security-module@vger.kernel.org
In-Reply-To: <1282570935.7198.5.camel@powerslave>
On Monday 2010-08-23 15:42, Luciano Coelho wrote:
>> > /* Defaults, these can be overridden on the module command-line. */
>> > static unsigned int condition_list_perms = S_IRUGO | S_IWUSR;
>> > static unsigned int condition_uid_perms = 0;
>> > static unsigned int condition_gid_perms = 0;
>> > +static unsigned int condition_capabilities = CAP_NET_ADMIN;
>> >
>> It is strange that we set security policy in this way. Maybe the
>> permission of the proc file is enough in this case.
>
>Yes, that is another way to do it. But in our device we use security
>capabilities more extensively than normal file permissions. That's why
>we need this.
>
>If this is too restrictive (ie. having CAP_NET_ADMIN) for most users, we
>could change the default value to no capabilities needed. Then we can
>set CAP_NET_ADMIN when loading the module.
But it looks as strange as the Yama code attempt. This is the one time
where I would personally be looking into SELinux, or perhaps SMACK if
the former is too complex, to whether _t'ing off procfs is possible.
^ permalink raw reply
* Re: Broadcom 5709 take long time to bring up
From: Joe Jin @ 2010-08-23 14:21 UTC (permalink / raw)
To: Joe Jin
Cc: Benjamin Li, Michael Chan, terry.liu@oracle.com,
netdev@vger.kernel.org
In-Reply-To: <20100819081115.GA6419@joejin-pc.cn.oracle.com>
Again, I moved cnic.ko and bnx2i.ko to other directory, still
bnx2 device came back took 3 seconds.
Any suggestions is appreciate!
Joe
On 2010-08-19 16:11, Joe Jin wrote:
> Hi,
>
> Just confirmed it, there was not iscsi configured on the server.
>
> Thanks,
> Joe
>
>
> On 2010-08-19 09:13, Joe Jin wrote:
> > Hi Benjamin,
> >
> > Thanks for your reply, see the answers in the lines.
> >
> > On 2010-08-18 09:08, Benjamin Li wrote:
> > > Hi Joe,
> > >
> > > Just a couple of quick questions:
> > >
> > > 1. It is possible that autonegotiation could take in the orders of
> > > seconds depending on the remote partner. Could you describe the remote
> > > partner?
> >
> > I dont think it caused that.
> > >From system log(see below) could saw brought up the interface took
> > around 3 seconds. I have add some debugging codes in the drivers and
> > could saw 3 times poll the devices and all the state of device is
> > link down.
> >
> > Also, from system could found during bootup, brought all devices
> > took less than 1 seconds, but ifdown/ifup take long times.
> >
> > >
> > > 2. Are there iSCSI offload connections? With iSCSI there is
> > > additionial overhead to cleanup/setup iSCSI connections on the
> > > chip/firmware when ifup'ing/ifdown'ing a network interface.
> >
> > I'll confirm it later, but from system log saw have initialized
> > iSCSI module, it maybe cause it.
> >
> > >
> > > 3. Could you provide the kernel logs during this up/down test? I
> > > wanted to see if there was anything interesting in the kernel logs.
> > >
> >
> > Here are kernel log:
> >
> >
> > System log of bootup
> > ~~~~~~~~~~~~~~~~~~~~
> > Jul 19 11:23:28 bond-test kernel: Ethernet Channel Bonding Driver: v3.4.0 (October 7, 2008)
> > Jul 19 11:23:28 bond-test kernel: bonding: Warning: updelay (150) is not a multiple of miimon (100), updelay rounded to 100 ms
> > Jul 19 11:23:28 bond-test kernel: bonding: MII link monitoring set to 100 ms
> > Jul 19 11:23:28 bond-test kernel: ADDRCONF(NETDEV_UP): bond0: link is not ready
> > Jul 19 11:23:28 bond-test kernel: bonding: bond0: Adding slave eth0.
> > Jul 19 11:23:28 bond-test kernel: bnx2: eth0: using MSI
> > Jul 19 11:23:28 bond-test kernel: iscsi: registered transport (bcm570x-020000)
> > Jul 19 11:23:28 bond-test kernel: bnx2i: netif=eth0, iscsi=bcm570x-020000
> > Jul 19 11:23:28 bond-test kernel: bnx2i [02:00.00]: ISCSI_INIT passed
> > Jul 19 11:23:28 bond-test kernel: bonding: bond0: enslaving eth0 as a backup interface with a down link.
> > Jul 19 11:23:28 bond-test kernel: bonding: bond0: Adding slave eth1.
> > Jul 19 11:23:28 bond-test kernel: bnx2: eth1: using MSI
> > Jul 19 11:23:28 bond-test kernel: iscsi: registered transport (bcm570x-020001)
> > Jul 19 11:23:28 bond-test kernel: bnx2i: netif=eth1, iscsi=bcm570x-020001
> > Jul 19 11:23:28 bond-test kernel: bnx2i [02:00.01]: ISCSI_INIT passed
> > Jul 19 11:23:28 bond-test kernel: bonding: bond0: enslaving eth1 as a backup interface with a down link.
> > Jul 19 11:23:28 bond-test kernel: bnx2: eth1 NIC Copper Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON
> > Jul 19 11:23:28 bond-test kernel: bonding: bond0: link status up for interface eth1, enabling it in 0 ms.
> > Jul 19 11:23:28 bond-test kernel: bonding: bond0: link status definitely up for interface eth1.
> > Jul 19 11:23:28 bond-test kernel: bonding: bond0: making interface eth1 the new active one.
> > Jul 19 11:23:28 bond-test kernel: bonding: bond0: first active interface up!
> > Jul 19 11:23:28 bond-test kernel: ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
> > Jul 19 11:23:28 bond-test kernel: bnx2: eth0 NIC Copper Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON
> > Jul 19 11:23:28 bond-test kernel: bonding: bond0: link status up for interface eth0, enabling it in 100 ms.
> > Jul 19 11:23:28 bond-test kernel: bonding: bond0: link status definitely up for interface eth0.
> > Jul 19 11:23:28 bond-test kernel: bonding: bond0: making interface eth0 the new active one.
> >
> >
> > System log of the testcase
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Jul 19 11:25:41 bond-test kernel: bonding: bond0: Removing slave eth0
> > Jul 19 11:25:41 bond-test kernel: bonding: bond0: Warning: the permanent HWaddr of eth0 - 00:26:55:4F:1F:18 - is still in use by bond0. Set the HWaddr of eth0 to a different address to avoid conflicts.
> > Jul 19 11:25:41 bond-test kernel: bonding: bond0: releasing active interface eth0
> > Jul 19 11:25:41 bond-test kernel: bonding: bond0: making interface eth1 the new active one.
> > Jul 19 11:25:45 bond-test kernel: bonding: bond0: Adding slave eth0.
> > Jul 19 11:25:45 bond-test kernel: bnx2: eth0: using MSI
> > Jul 19 11:25:45 bond-test kernel: bnx2i [02:00.00]: ISCSI_INIT passed
> > Jul 19 11:25:45 bond-test kernel: bonding: bond0: enslaving eth0 as a backup interface with a down link.
> > Jul 19 11:25:47 bond-test kernel: bonding: bond0: Removing slave eth1
> > Jul 19 11:25:47 bond-test kernel: bonding: bond0: releasing active interface eth1
> > Jul 19 11:25:48 bond-test kernel: bnx2: eth0 NIC Copper Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON
> > Jul 19 11:25:48 bond-test kernel: bonding: bond0: link status up for interface eth0, enabling it in 0 ms.
> > Jul 19 11:25:48 bond-test kernel: bonding: bond0: link status definitely up for interface eth0.
> > Jul 19 11:25:48 bond-test kernel: bonding: bond0: making interface eth0 the new active one.
> > Jul 19 11:25:53 bond-test kernel: bonding: bond0: Adding slave eth1.
> > Jul 19 11:25:53 bond-test kernel: bnx2: eth1: using MSI
> > Jul 19 11:25:53 bond-test kernel: bnx2i [02:00.01]: ISCSI_INIT passed
> > Jul 19 11:25:53 bond-test kernel: bonding: bond0: enslaving eth1 as a backup interface with a down link.
> > Jul 19 11:25:55 bond-test kernel: bonding: bond0: Removing slave eth0
> > Jul 19 11:25:55 bond-test kernel: bonding: bond0: Warning: the permanent HWaddr of eth0 - 00:26:55:4F:1F:18 - is still in use by bond0. Set the HWaddr of eth0 to a different address to avoid conflicts.
> > Jul 19 11:25:55 bond-test kernel: bonding: bond0: releasing active interface eth0
> > Jul 19 11:25:56 bond-test kernel: bnx2: eth1 NIC Copper Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON
> > Jul 19 11:25:56 bond-test kernel: bonding: bond0: link status up for interface eth1, enabling it in 0 ms.
> > Jul 19 11:25:56 bond-test kernel: bonding: bond0: link status definitely up for interface eth1.
> > Jul 19 11:25:56 bond-test kernel: bonding: bond0: making interface eth1 the new active one.
> > Jul 19 11:25:59 bond-test kernel: bonding: bond0: Adding slave eth0.
> > Jul 19 11:25:59 bond-test kernel: bnx2: eth0: using MSI
> > Jul 19 11:25:59 bond-test kernel: bnx2i [02:00.00]: ISCSI_INIT passed
> > Jul 19 11:25:59 bond-test kernel: bonding: bond0: enslaving eth0 as a backup interface with a down link.
> > Jul 19 11:26:02 bond-test kernel: bnx2: eth0 NIC Copper Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON
> > Jul 19 11:26:02 bond-test kernel: bonding: bond0: link status up for interface eth0, enabling it in 100 ms.
> > Jul 19 11:26:02 bond-test kernel: bonding: bond0: link status definitely up for interface eth0.
> > Jul 19 11:26:02 bond-test kernel: bonding: bond0: making interface eth0 the new active one.
> > Jul 19 11:26:27 bond-test kernel: bonding: bond0: Removing slave eth1
> > Jul 19 11:26:27 bond-test kernel: bonding: bond0: releasing backup interface eth1
> > Jul 19 11:26:29 bond-test kernel: bonding: bond0: Adding slave eth1.
> > Jul 19 11:26:29 bond-test kernel: bnx2: eth1: using MSI
> > Jul 19 11:26:29 bond-test kernel: bnx2i [02:00.01]: ISCSI_INIT passed
> > Jul 19 11:26:29 bond-test kernel: bonding: bond0: enslaving eth1 as a backup interface with a down link.
> > Jul 19 11:26:32 bond-test kernel: bnx2: eth1 NIC Copper Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON
> > Jul 19 11:26:32 bond-test kernel: bonding: bond0: link status up for interface eth1, enabling it in 100 ms.
> > Jul 19 11:26:32 bond-test kernel: bonding: bond0: link status definitely up for interface eth1.
> > Jul 19 11:26:33 bond-test kernel: bonding: bond0: Removing slave eth0
> > Jul 19 11:26:33 bond-test kernel: bonding: bond0: Warning: the permanent HWaddr of eth0 - 00:26:55:4F:1F:18 - is still in use by bond0. Set the HWaddr of eth0 to a different address to avoid conflicts.
> > Jul 19 11:26:33 bond-test kernel: bonding: bond0: releasing active interface eth0
> > Jul 19 11:26:33 bond-test kernel: bonding: bond0: making interface eth1 the new active one.
> > Jul 19 11:26:36 bond-test kernel: bonding: bond0: Adding slave eth0.
> > Jul 19 11:26:36 bond-test kernel: bnx2: eth0: using MSI
> > Jul 19 11:26:36 bond-test kernel: bnx2i [02:00.00]: ISCSI_INIT passed
> > Jul 19 11:26:36 bond-test kernel: bonding: bond0: enslaving eth0 as a backup interface with a down link.
> > Jul 19 11:26:38 bond-test kernel: bnx2: eth0 NIC Copper Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON
> > Jul 19 11:26:39 bond-test kernel: bonding: bond0: link status up for interface eth0, enabling it in 100 ms.
> > Jul 19 11:26:39 bond-test kernel: bonding: bond0: link status definitely up for interface eth0.
> > Jul 19 11:26:39 bond-test kernel: bonding: bond0: making interface eth0 the new active one.
> > Jul 19 11:27:07 bond-test kernel: bonding: bond0: Removing slave eth1
> > Jul 19 11:27:07 bond-test kernel: bonding: bond0: releasing backup interface eth1
> > Jul 19 11:27:09 bond-test kernel: bonding: bond0: Adding slave eth1.
> > Jul 19 11:27:09 bond-test kernel: bnx2: eth1: using MSI
> > Jul 19 11:27:09 bond-test kernel: bnx2i [02:00.01]: ISCSI_INIT passed
> > Jul 19 11:27:09 bond-test kernel: bonding: bond0: enslaving eth1 as a backup interface with a down link.
> > Jul 19 11:27:12 bond-test kernel: bnx2: eth1 NIC Copper Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON
> > Jul 19 11:27:12 bond-test kernel: bonding: bond0: link status up for interface eth1, enabling it in 100 ms.
> > Jul 19 11:27:12 bond-test kernel: bonding: bond0: link status definitely up for interface eth1.
> > Jul 19 11:27:12 bond-test kernel: bonding: bond0: Removing slave eth0
> > Jul 19 11:27:12 bond-test kernel: bonding: bond0: Warning: the permanent HWaddr of eth0 - 00:26:55:4F:1F:18 - is still in use by bond0. Set the HWaddr of eth0 to a different address to avoid conflicts.
> > Jul 19 11:27:12 bond-test kernel: bonding: bond0: releasing active interface eth0
> > Jul 19 11:27:12 bond-test kernel: bonding: bond0: making interface eth1 the new active one.
> > Jul 19 11:27:15 bond-test kernel: bonding: bond0: Adding slave eth0.
> > Jul 19 11:27:15 bond-test kernel: bnx2: eth0: using MSI
> > Jul 19 11:27:15 bond-test kernel: bnx2i [02:00.00]: ISCSI_INIT passed
> > Jul 19 11:27:15 bond-test kernel: bonding: bond0: enslaving eth0 as a backup interface with a down link.
> > Jul 19 11:27:18 bond-test kernel: bnx2: eth0 NIC Copper Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON
> > Jul 19 11:27:18 bond-test kernel: bonding: bond0: link status up for interface eth0, enabling it in 100 ms.
> > Jul 19 11:27:18 bond-test kernel: bonding: bond0: link status definitely up for interface eth0.
> > Jul 19 11:27:18 bond-test kernel: bonding: bond0: making interface eth0 the new active one.
> > Jul 19 11:27:22 bond-test kernel: bonding: bond0: Removing slave eth1
> > Jul 19 11:27:22 bond-test kernel: bonding: bond0: releasing backup interface eth1
> > Jul 19 11:27:24 bond-test kernel: bonding: bond0: Adding slave eth1.
> > Jul 19 11:27:24 bond-test kernel: bnx2: eth1: using MSI
> > Jul 19 11:27:24 bond-test kernel: bnx2i [02:00.01]: ISCSI_INIT passed
> > Jul 19 11:27:24 bond-test kernel: bonding: bond0: enslaving eth1 as a backup interface with a down link.
> > Jul 19 11:27:26 bond-test kernel: bnx2: eth1 NIC Copper Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON
> > Jul 19 11:27:26 bond-test kernel: bonding: bond0: link status up for interface eth1, enabling it in 100 ms.
> > Jul 19 11:27:26 bond-test kernel: bonding: bond0: link status definitely up for interface eth1.
> > Jul 19 11:27:27 bond-test kernel: bonding: bond0: Removing slave eth0
> > Jul 19 11:27:27 bond-test kernel: bonding: bond0: Warning: the permanent HWaddr of eth0 - 00:26:55:4F:1F:18 - is still in use by bond0. Set the HWaddr of eth0 to a different address to avoid conflicts.
> > Jul 19 11:27:27 bond-test kernel: bonding: bond0: releasing active interface eth0
> > Jul 19 11:27:27 bond-test kernel: bonding: bond0: making interface eth1 the new active one.
> > Jul 19 11:27:30 bond-test kernel: bonding: bond0: Adding slave eth0.
> > Jul 19 11:27:30 bond-test kernel: bnx2: eth0: using MSI
> > Jul 19 11:27:30 bond-test kernel: bnx2i [02:00.00]: ISCSI_INIT passed
> > Jul 19 11:27:30 bond-test kernel: bonding: bond0: enslaving eth0 as a backup interface with a down link.
> > Jul 19 11:27:33 bond-test kernel: bnx2: eth0 NIC Copper Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON
> > Jul 19 11:27:33 bond-test kernel: bonding: bond0: link status up for interface eth0, enabling it in 100 ms.
> > Jul 19 11:27:33 bond-test kernel: bonding: bond0: link status definitely up for interface eth0.
> > Jul 19 11:27:33 bond-test kernel: bonding: bond0: making interface eth0 the new active one.
> > Jul 19 11:27:52 bond-test kernel: bonding: bond0: Removing slave eth1
> > Jul 19 11:27:52 bond-test kernel: bonding: bond0: releasing backup interface eth1
> > Jul 19 11:27:54 bond-test kernel: bonding: bond0: Adding slave eth1.
> > Jul 19 11:27:54 bond-test kernel: bnx2: eth1: using MSI
> > Jul 19 11:27:54 bond-test kernel: bnx2i [02:00.01]: ISCSI_INIT passed
> > Jul 19 11:27:54 bond-test kernel: bonding: bond0: enslaving eth1 as a backup interface with a down link.
> > Jul 19 11:27:56 bond-test kernel: bnx2: eth1 NIC Copper Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON
> > Jul 19 11:27:56 bond-test kernel: bonding: bond0: link status up for interface eth1, enabling it in 100 ms.
> > Jul 19 11:27:56 bond-test kernel: bonding: bond0: link status definitely up for interface eth1.
> > Jul 19 11:28:05 bond-test kernel: bonding: bond0: Removing slave eth0
> > Jul 19 11:28:05 bond-test kernel: bonding: bond0: Warning: the permanent HWaddr of eth0 - 00:26:55:4F:1F:18 - is still in use by bond0. Set the HWaddr of eth0 to a different address to avoid conflicts.
> > Jul 19 11:28:05 bond-test kernel: bonding: bond0: releasing active interface eth0
> > Jul 19 11:28:05 bond-test kernel: bonding: bond0: making interface eth1 the new active one.
> > Jul 19 11:28:07 bond-test ntpd[7189]: synchronized to 144.145.109.92, stratum 3
> > Jul 19 11:28:07 bond-test kernel: bonding: bond0: Adding slave eth0.
> > Jul 19 11:28:07 bond-test kernel: bnx2: eth0: using MSI
> > Jul 19 11:28:07 bond-test kernel: bnx2i [02:00.00]: ISCSI_INIT passed
> > Jul 19 11:28:07 bond-test kernel: bonding: bond0: enslaving eth0 as a backup interface with a down link.
> > Jul 19 11:28:11 bond-test kernel: bnx2: eth0 NIC Copper Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON
> > Jul 19 11:28:11 bond-test kernel: bonding: bond0: link status up for interface eth0, enabling it in 100 ms.
> > Jul 19 11:28:11 bond-test kernel: bonding: bond0: link status definitely up for interface eth0.
> > Jul 19 11:28:11 bond-test kernel: bonding: bond0: making interface eth0 the new active one.
> > Jul 19 11:28:32 bond-test kernel: bonding: bond0: Removing slave eth1
> > Jul 19 11:28:32 bond-test kernel: bonding: bond0: releasing backup interface eth1
> > Jul 19 11:28:34 bond-test kernel: bonding: bond0: Adding slave eth1.
> > Jul 19 11:28:34 bond-test kernel: bnx2: eth1: using MSI
> > Jul 19 11:28:34 bond-test kernel: bnx2i [02:00.01]: ISCSI_INIT passed
> > Jul 19 11:28:34 bond-test kernel: bonding: bond0: enslaving eth1 as a backup interface with a down link.
> > Jul 19 11:28:37 bond-test kernel: bnx2: eth1 NIC Copper Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON
> > Jul 19 11:28:37 bond-test kernel: bonding: bond0: link status up for interface eth1, enabling it in 100 ms.
> > Jul 19 11:28:37 bond-test kernel: bonding: bond0: link status definitely up for interface eth1.
> > Jul 19 11:28:40 bond-test kernel: bonding: bond0: Removing slave eth0
> > Jul 19 11:28:40 bond-test kernel: bonding: bond0: Warning: the permanent HWaddr of eth0 - 00:26:55:4F:1F:18 - is still in use by bond0. Set the HWaddr of eth0 to a different address to avoid conflicts.
> > Jul 19 11:28:40 bond-test kernel: bonding: bond0: releasing active interface eth0
> > Jul 19 11:28:40 bond-test kernel: bonding: bond0: making interface eth1 the new active one.
> > Jul 19 11:28:43 bond-test kernel: bonding: bond0: Adding slave eth0.
> > Jul 19 11:28:43 bond-test kernel: bnx2: eth0: using MSI
> > Jul 19 11:28:43 bond-test kernel: bnx2i [02:00.00]: ISCSI_INIT passed
> > Jul 19 11:28:43 bond-test kernel: bonding: bond0: enslaving eth0 as a backup interface with a down link.
> > Jul 19 11:28:45 bond-test kernel: bnx2: eth0 NIC Copper Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON
> > Jul 19 11:28:45 bond-test kernel: bonding: bond0: link status up for interface eth0, enabling it in 100 ms.
> > Jul 19 11:28:45 bond-test kernel: bonding: bond0: link status definitely up for interface eth0.
> > Jul 19 11:28:45 bond-test kernel: bonding: bond0: making interface eth0 the new active one.
> > Jul 19 11:28:45 bond-test kernel: bonding: bond0: Removing slave eth1
> > Jul 19 11:28:45 bond-test kernel: bonding: bond0: releasing backup interface eth1
> > Jul 19 11:28:48 bond-test kernel: bonding: bond0: Adding slave eth1.
> > Jul 19 11:28:48 bond-test kernel: bnx2: eth1: using MSI
> > Jul 19 11:28:48 bond-test kernel: bnx2i [02:00.01]: ISCSI_INIT passed
> > Jul 19 11:28:48 bond-test kernel: bonding: bond0: enslaving eth1 as a backup interface with a down link.
> > Jul 19 11:28:51 bond-test kernel: bnx2: eth1 NIC Copper Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON
> > Jul 19 11:28:51 bond-test kernel: bonding: bond0: link status up for interface eth1, enabling it in 100 ms.
> > Jul 19 11:28:51 bond-test kernel: bonding: bond0: link status definitely up for interface eth1.
> > Jul 19 11:28:53 bond-test kernel: bonding: bond0: Removing slave eth0
> > Jul 19 11:28:53 bond-test kernel: bonding: bond0: Warning: the permanent HWaddr of eth0 - 00:26:55:4F:1F:18 - is still in use by bond0. Set the HWaddr of eth0 to a different address to avoid conflicts.
> > Jul 19 11:28:53 bond-test kernel: bonding: bond0: releasing active interface eth0
> > Jul 19 11:28:53 bond-test kernel: bonding: bond0: making interface eth1 the new active one.
> > Jul 19 11:28:57 bond-test kernel: bonding: bond0: Adding slave eth0.
> > Jul 19 11:28:57 bond-test kernel: bnx2: eth0: using MSI
> > Jul 19 11:28:57 bond-test kernel: bnx2i [02:00.00]: ISCSI_INIT passed
> > Jul 19 11:28:57 bond-test kernel: bonding: bond0: enslaving eth0 as a backup interface with a down link.
> > Jul 19 11:28:59 bond-test kernel: bonding: bond0: Removing slave eth1
> > Jul 19 11:28:59 bond-test kernel: bonding: bond0: releasing active interface eth1
> > Jul 19 11:29:00 bond-test kernel: bnx2: eth0 NIC Copper Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON
> > Jul 19 11:29:00 bond-test kernel: bonding: bond0: link status up for interface eth0, enabling it in 0 ms.
> > Jul 19 11:29:00 bond-test kernel: bonding: bond0: link status definitely up for interface eth0.
> > Jul 19 11:29:00 bond-test kernel: bonding: bond0: making interface eth0 the new active one.
> > Jul 19 11:29:13 bond-test kernel: bonding: bond0: Adding slave eth1.
> > Jul 19 11:29:13 bond-test kernel: bnx2: eth1: using MSI
> > Jul 19 11:29:13 bond-test kernel: bnx2i [02:00.01]: ISCSI_INIT passed
> > Jul 19 11:29:13 bond-test kernel: bonding: bond0: enslaving eth1 as a backup interface with a down link.
> > Jul 19 11:29:15 bond-test kernel: bonding: bond0: Removing slave eth0
> > Jul 19 11:29:15 bond-test kernel: bonding: bond0: Warning: the permanent HWaddr of eth0 - 00:26:55:4F:1F:18 - is still in use by bond0. Set the HWaddr of eth0 to a different address to avoid conflicts.
> > Jul 19 11:29:15 bond-test kernel: bonding: bond0: releasing active interface eth0
> > Jul 19 11:29:15 bond-test kernel: bnx2: eth1 NIC Copper Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON
> > Jul 19 11:29:16 bond-test kernel: bonding: bond0: link status up for interface eth1, enabling it in 0 ms.
> > Jul 19 11:29:16 bond-test kernel: bonding: bond0: link status definitely up for interface eth1.
> > Jul 19 11:29:16 bond-test kernel: bonding: bond0: making interface eth1 the new active one.
> > Jul 19 11:29:20 bond-test kernel: bonding: bond0: Adding slave eth0.
> > Jul 19 11:29:20 bond-test kernel: bnx2: eth0: using MSI
> > Jul 19 11:29:20 bond-test kernel: bnx2i [02:00.00]: ISCSI_INIT passed
> > Jul 19 11:29:20 bond-test kernel: bonding: bond0: enslaving eth0 as a backup interface with a down link.
> > Jul 19 11:29:22 bond-test kernel: bnx2: eth0 NIC Copper Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON
> > Jul 19 11:29:22 bond-test kernel: bonding: bond0: link status up for interface eth0, enabling it in 100 ms.
> > Jul 19 11:29:22 bond-test kernel: bonding: bond0: link status definitely up for interface eth0.
> >
> >
> >
> > Thanks,
> > Joe
>
> --
> Joe Jin | Team Leader, Software Development | +8610.8278.6295
> ORACLE | Linux and Virtualization
> Incubator Building 2-A ZPark | Beijing China, 100094
--
Joe Jin | Team Leader, Software Development | +8610.8278.6295
ORACLE | Linux and Virtualization
Incubator Building 2-A ZPark | Beijing China, 100094
^ permalink raw reply
* Re: [Bugme-new] [Bug 16626] New: Machine hangs with EIP at skb_copy_and_csum_dev
From: Jarek Poplawski @ 2010-08-23 14:14 UTC (permalink / raw)
To: Plamen Petrov
Cc: Eric Dumazet, Andrew Morton, netdev, bugzilla-daemon,
bugme-daemon
In-Reply-To: <4C72802D.8090405@fs.uni-ruse.bg>
On Mon, Aug 23, 2010 at 05:05:33PM +0300, Plamen Petrov wrote:
> Well, so far - so good. No oopses.
>
> I think I'm hitting some compiler related issue here...
>
> The kernel with the patch I sent applied is working pretty fine
> even with "generic-receive-offload" ON for my tg3 nic...
>
> What is the big difference there?
Oopses should be replaced with warnings, so please check the
syslog etc from time to time.
Jarek P.
^ permalink raw reply
* Re: [Bugme-new] [Bug 16626] New: Machine hangs with EIP at skb_copy_and_csum_dev
From: Plamen Petrov @ 2010-08-23 14:05 UTC (permalink / raw)
To: Jarek Poplawski
Cc: Eric Dumazet, Andrew Morton, netdev, bugzilla-daemon,
bugme-daemon
In-Reply-To: <4C727B06.2060002@fs.uni-ruse.bg>
На 23.8.2010 г. 16:43, Plamen Petrov написа:
> На 23.8.2010 г. 16:10, Jarek Poplawski написа:
>> On Mon, Aug 23, 2010 at 03:00:43PM +0200, Eric Dumazet wrote:
>> ...
>>> I was about to suggest a similar patch ;)
>>>
>>> Also prints skb->csum_offset and skb->len if possible
>>
>> Feel free to send it: I'm a bit in hurry now...
>>
>> Jarek P.
>
> Currently compiling the kernel with the attached patch.
>
> And, by the way, if there are any patches to follow, would you
> please, send them as attachments? I think my mail client is
> line-wrapping the patches...
>
> The results will be sent soon, too.
Well, so far - so good. No oopses.
I think I'm hitting some compiler related issue here...
The kernel with the patch I sent applied is working pretty fine
even with "generic-receive-offload" ON for my tg3 nic...
What is the big difference there?
Or do we need to dig into the object files now? Because that's
what's too scary for me...
Plamen
P.S. The compiler I am using is :
root@crux:~# gcc -v
> Using built-in specs.
> Target: i686-pc-linux-gnu
> Configured with: ../gcc-4.4.4/configure --prefix=/usr --libexecdir=/usr/lib --enable-languages=c,c++,objc --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-shared --disable-nls --with-x=no
> Thread model: posix
> gcc version 4.4.4 (CRUX) (GCC)
Anything obviously special about it?
^ permalink raw reply
* Re: [Bugme-new] [Bug 16626] New: Machine hangs with EIP at skb_copy_and_csum_dev
From: Plamen Petrov @ 2010-08-23 13:43 UTC (permalink / raw)
To: Jarek Poplawski
Cc: Eric Dumazet, Andrew Morton, netdev, bugzilla-daemon,
bugme-daemon
In-Reply-To: <20100823131056.GA19160@ff.dom.local>
[-- Attachment #1: Type: text/plain, Size: 551 bytes --]
На 23.8.2010 г. 16:10, Jarek Poplawski написа:
> On Mon, Aug 23, 2010 at 03:00:43PM +0200, Eric Dumazet wrote:
> ...
>> I was about to suggest a similar patch ;)
>>
>> Also prints skb->csum_offset and skb->len if possible
>
> Feel free to send it: I'm a bit in hurry now...
>
> Jarek P.
Currently compiling the kernel with the attached patch.
And, by the way, if there are any patches to follow, would you
please, send them as attachments? I think my mail client is
line-wrapping the patches...
The results will be sent soon, too.
Plamen
[-- Attachment #2: tg3-gro-debug.patch --]
[-- Type: text/plain, Size: 1598 bytes --]
diff --git a/net/core/dev.c b/net/core/dev.c
index 3721fbb..24a53d0 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1935,6 +1935,26 @@ static inline int skb_needs_linearize(struct sk_buff *skb,
illegal_highdma(dev, skb))));
}
+static int skb_csum_start_bug(struct sk_buff *skb)
+{
+
+ if (skb->ip_summed == CHECKSUM_PARTIAL) {
+ long csstart;
+
+ csstart = skb->csum_start - skb_headroom(skb);
+ if (WARN_ON(csstart > skb_headlen(skb))) {
+ pr_warning("csum_start %u, offset %u, headroom %d, headlen %d, len %d\n",
+ skb->csum_start,
+ skb->csum_offset,
+ skb_headroom(skb),
+ skb_headlen(skb),
+ skb->len);
+ return 1;
+ }
+ }
+ return 0;
+}
+
int dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev,
struct netdev_queue *txq)
{
@@ -1955,11 +1975,13 @@ int dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev,
skb_orphan_try(skb);
if (netif_needs_gso(dev, skb)) {
+ skb_csum_start_bug(skb);
if (unlikely(dev_gso_segment(skb)))
goto out_kfree_skb;
if (skb->next)
goto gso;
} else {
+ skb_csum_start_bug(skb);
if (skb_needs_linearize(skb, dev) &&
__skb_linearize(skb))
goto out_kfree_skb;
@@ -1997,7 +2019,12 @@ gso:
if (dev->priv_flags & IFF_XMIT_DST_RELEASE)
skb_dst_drop(nskb);
- rc = ops->ndo_start_xmit(nskb, dev);
+ if (skb_csum_start_bug(skb)) {
+ kfree_skb(skb);
+ rc = NETDEV_TX_OK;
+ } else
+ rc = ops->ndo_start_xmit(nskb, dev);
+
if (unlikely(rc != NETDEV_TX_OK)) {
if (rc & ~NETDEV_TX_MASK)
goto out_kfree_gso_skb;
^ permalink raw reply related
* Re: [PATCH 1/1] posix clocks: introduce syscall for clock tuning.
From: Matthew Wilcox @ 2010-08-23 13:43 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Richard Cochran, john stultz, linux-api-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <201008231457.26690.arnd-r2nGTMty4D4@public.gmane.org>
On Mon, Aug 23, 2010 at 02:57:26PM +0200, Arnd Bergmann wrote:
> > +static inline int common_clock_adj(const clockid_t which_clock, int ppb,
> > + struct timespec *tp)
> > +{
> > + return -EOPNOTSUPP;
> > +}
> > +
> > static int no_timer_create(struct k_itimer *new_timer)
> > {
> > return -EOPNOTSUPP;
>
> So we already return -EOPNOTSUPP in some cases? The man page does not document this.
> I wonder if we should change that to -EINVAL as well.
ENOTTY is the usual errno for "inappropriate ioctl for device". Due to
the way this patch has been chopped up, I can't tell if that's what is
intended here.
--
Matthew Wilcox Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply
* Re: [PATCH] netfilter: xt_condition: add security capability support
From: Luciano Coelho @ 2010-08-23 13:42 UTC (permalink / raw)
To: ext Changli Gao
Cc: kaber@trash.net, netfilter-devel@vger.kernel.org,
netdev@vger.kernel.org, James Morris,
linux-security-module@vger.kernel.org
In-Reply-To: <AANLkTi=2H+ytOQU9nC_dRp_GB5Sy1831VY14oW=YSOrG@mail.gmail.com>
On Mon, 2010-08-23 at 15:37 +0200, ext Changli Gao wrote:
> On Mon, Aug 23, 2010 at 8:50 PM, <luciano.coelho@nokia.com> wrote:
> > From: Luciano Coelho <luciano.coelho@nokia.com>
> >
> > Add a module parameter that allows the required security capability to
> > change the conditions from userspace to be specified. By default the
> > module will require the CAP_NET_ADMIN capability.
> >
> > Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
> > ---
> > net/netfilter/xt_condition.c | 10 ++++++++++
> > 1 files changed, 10 insertions(+), 0 deletions(-)
> >
> > diff --git a/net/netfilter/xt_condition.c b/net/netfilter/xt_condition.c
> > index 06205aa..fd279e5 100644
> > --- a/net/netfilter/xt_condition.c
> > +++ b/net/netfilter/xt_condition.c
> > @@ -29,11 +29,13 @@
> > #include <linux/netfilter/xt_condition.h>
> > #include <net/netns/generic.h>
> > #include <asm/uaccess.h>
> > +#include <linux/capability.h>
> >
> > /* Defaults, these can be overridden on the module command-line. */
> > static unsigned int condition_list_perms = S_IRUGO | S_IWUSR;
> > static unsigned int condition_uid_perms = 0;
> > static unsigned int condition_gid_perms = 0;
> > +static unsigned int condition_capabilities = CAP_NET_ADMIN;
> >
> > MODULE_AUTHOR("Stephane Ouellette <ouellettes@videotron.ca>");
> > MODULE_AUTHOR("Massimiliano Hofer <max@nucleus.it>");
> > @@ -47,6 +49,8 @@ module_param(condition_uid_perms, uint, S_IRUSR | S_IWUSR);
> > MODULE_PARM_DESC(condition_uid_perms, "default user owner of /proc/net/nf_condition/* files");
> > module_param(condition_gid_perms, uint, S_IRUSR | S_IWUSR);
> > MODULE_PARM_DESC(condition_gid_perms, "default group owner of /proc/net/nf_condition/* files");
> > +module_param(condition_capabilities, uint, CAP_NET_ADMIN);
> > +MODULE_PARM_DESC(condition_capabilities, "default capabilities required to change /proc/net/nf_condition/* files");
>
> It is strange that we set security policy in this way. Maybe the
> permission of the proc file is enough in this case.
Yes, that is another way to do it. But in our device we use security
capabilities more extensively than normal file permissions. That's why
we need this.
If this is too restrictive (ie. having CAP_NET_ADMIN) for most users, we
could change the default value to no capabilities needed. Then we can
set CAP_NET_ADMIN when loading the module.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] netfilter: xt_condition: add security capability support
From: Changli Gao @ 2010-08-23 13:37 UTC (permalink / raw)
To: luciano.coelho
Cc: kaber, netfilter-devel, netdev, James Morris,
linux-security-module
In-Reply-To: <1282567801-2673-1-git-send-email-luciano.coelho@nokia.com>
On Mon, Aug 23, 2010 at 8:50 PM, <luciano.coelho@nokia.com> wrote:
> From: Luciano Coelho <luciano.coelho@nokia.com>
>
> Add a module parameter that allows the required security capability to
> change the conditions from userspace to be specified. By default the
> module will require the CAP_NET_ADMIN capability.
>
> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
> ---
> net/netfilter/xt_condition.c | 10 ++++++++++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/net/netfilter/xt_condition.c b/net/netfilter/xt_condition.c
> index 06205aa..fd279e5 100644
> --- a/net/netfilter/xt_condition.c
> +++ b/net/netfilter/xt_condition.c
> @@ -29,11 +29,13 @@
> #include <linux/netfilter/xt_condition.h>
> #include <net/netns/generic.h>
> #include <asm/uaccess.h>
> +#include <linux/capability.h>
>
> /* Defaults, these can be overridden on the module command-line. */
> static unsigned int condition_list_perms = S_IRUGO | S_IWUSR;
> static unsigned int condition_uid_perms = 0;
> static unsigned int condition_gid_perms = 0;
> +static unsigned int condition_capabilities = CAP_NET_ADMIN;
>
> MODULE_AUTHOR("Stephane Ouellette <ouellettes@videotron.ca>");
> MODULE_AUTHOR("Massimiliano Hofer <max@nucleus.it>");
> @@ -47,6 +49,8 @@ module_param(condition_uid_perms, uint, S_IRUSR | S_IWUSR);
> MODULE_PARM_DESC(condition_uid_perms, "default user owner of /proc/net/nf_condition/* files");
> module_param(condition_gid_perms, uint, S_IRUSR | S_IWUSR);
> MODULE_PARM_DESC(condition_gid_perms, "default group owner of /proc/net/nf_condition/* files");
> +module_param(condition_capabilities, uint, CAP_NET_ADMIN);
> +MODULE_PARM_DESC(condition_capabilities, "default capabilities required to change /proc/net/nf_condition/* files");
It is strange that we set security policy in this way. Maybe the
permission of the proc file is enough in this case.
> MODULE_ALIAS("ipt_condition");
> MODULE_ALIAS("ip6t_condition");
>
> @@ -88,6 +92,12 @@ static int condition_proc_write(struct file *file, const char __user *input,
> char buf[sizeof("+037777777777")];
> unsigned long long value;
>
> + if (!capable(condition_capabilities)) {
> + pr_debug("not enough capabilities (requires %0X)\n",
> + condition_capabilities);
> + return -EPERM;
> + }
> +
> if (length == 0)
> return 0;
>
> --
> 1.7.0.4
>
> --
> 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
>
--
Regards,
Changli Gao(xiaosuo@gmail.com)
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" 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: IPsec: Why do pfkey_getspi and xfrm_alloc_userspi call xfrm_find_acq_byseq?
From: Christophe Gouault @ 2010-08-23 13:30 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100822.005353.260099324.davem@davemloft.net>
Hi David,
First of all, thank you for your answer.
David Miller wrote:
> From: Christophe Gouault <christophe.gouault@6wind.com>
> Date: Thu, 19 Aug 2010 14:55:21 +0200
>
>> The call to xfrm_find_acq_byseq() by the pfkey_getspi() and
>> xfrm_alloc_userspi() functions is quite costly and proves to entail
>> scalability issues when performing thousands of IKE negotiations with
>> racoon (from ipsec-tools distribution) or charon (from strongswan
>> distribution).
>>
>> Removing this call in the kernel drastically accelerates the
>> processing and does not seem to entail functional problems.
>>
>> For now, I don't see the point of this call. I need to understand its
>> purpose, because I'm highly tempted to simply remove it.
> First of all, removing a function because you don't understand
> why it's there is rarely a good idea :-)
Yes, don't worry, I never act that way. I was deliberately a little
provocative ;-)
> I think the semantics require that we check for existing ACQUIRE
> state entries before we allocate an SPI.
Well, I still don't see in which case this can happen. The only
situations in which an ACQUIRE state entry is created is when an acquire
message is raised by the kernel (this creates a temporary outbound
state) or when a getspi is issued from the userland (this creates a
temporary state, as far as I know, this is the future inbound state
negotiated by IKE).
In my humble opinion, issuing a getspi for the output state does not
make sense since the SPI is chosen by the destination host.
So the possibly existing ACQUIRE state entry would be the result of a
former getspi with the same value of the seq field. So this call would
aim at cancelling a former call to getspi, maybe to cope with an
application that would retry a failed negotiation before the former
getspi expired?... I'm not really convinced by this explanation.
But there are maybe other uses of the getspi call than assigning a SPI
for the inbound state of an IKE negotiation...
> The likelyhood of breaking something if you remove the call is very
> high.
Probably. I'm still interested in a concrete example ;-)
Christophe
^ permalink raw reply
* [PATCH] net_sched: act_csum: coding style cleanup
From: Changli Gao @ 2010-08-23 13:27 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: David S. Miller, netdev, Changli Gao
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
---
net/sched/act_csum.c | 77 +++++++++++++++++++++++++--------------------------
1 file changed, 38 insertions(+), 39 deletions(-)
diff --git a/net/sched/act_csum.c b/net/sched/act_csum.c
index be41f1c..67dc7ce 100644
--- a/net/sched/act_csum.c
+++ b/net/sched/act_csum.c
@@ -42,9 +42,9 @@ static u32 csum_idx_gen;
static DEFINE_RWLOCK(csum_lock);
static struct tcf_hashinfo csum_hash_info = {
- .htab = tcf_csum_ht,
- .hmask = CSUM_TAB_MASK,
- .lock = &csum_lock,
+ .htab = tcf_csum_ht,
+ .hmask = CSUM_TAB_MASK,
+ .lock = &csum_lock,
};
static const struct nla_policy csum_policy[TCA_CSUM_MAX + 1] = {
@@ -73,7 +73,8 @@ static int tcf_csum_init(struct nlattr *nla, struct nlattr *est,
pc = tcf_hash_check(parm->index, a, bind, &csum_hash_info);
if (!pc) {
- pc = tcf_hash_create(parm->index, est, a, sizeof(*p), bind, &csum_idx_gen, &csum_hash_info);
+ pc = tcf_hash_create(parm->index, est, a, sizeof(*p), bind,
+ &csum_idx_gen, &csum_hash_info);
if (IS_ERR(pc))
return PTR_ERR(pc);
p = to_tcf_csum(pc);
@@ -230,8 +231,9 @@ static int tcf_csum_ipv4_udp(struct sk_buff *skb, struct iphdr *iph,
struct udphdr *udph;
u16 ul;
- /* Support both UDP and UDPLITE checksum algorithms,
- * Don't use udph->len to get the real length without any protocol check,
+ /*
+ * Support both UDP and UDPLITE checksum algorithms, Don't use
+ * udph->len to get the real length without any protocol check,
* UDPLITE uses udph->len for another thing,
* Use iph->tot_len, or just ipl.
*/
@@ -249,10 +251,8 @@ static int tcf_csum_ipv4_udp(struct sk_buff *skb, struct iphdr *iph,
if (udplite) {
if (ul == 0)
skb->csum = csum_partial(udph, ipl - ihl, 0);
-
else if ((ul >= sizeof(*udph)) && (ul <= ipl - ihl))
skb->csum = csum_partial(udph, ul, 0);
-
else
goto ignore_obscure_skb;
} else {
@@ -282,8 +282,9 @@ static int tcf_csum_ipv6_udp(struct sk_buff *skb, struct ipv6hdr *ip6h,
struct udphdr *udph;
u16 ul;
- /* Support both UDP and UDPLITE checksum algorithms,
- * Don't use udph->len to get the real length without any protocol check,
+ /*
+ * Support both UDP and UDPLITE checksum algorithms, Don't use
+ * udph->len to get the real length without any protocol check,
* UDPLITE uses udph->len for another thing,
* Use ip6h->payload_len + sizeof(*ip6h) ... , or just ipl.
*/
@@ -340,32 +341,32 @@ static int tcf_csum_ipv4(struct sk_buff *skb, u32 update_flags)
switch (iph->frag_off & htons(IP_OFFSET) ? 0 : iph->protocol) {
case IPPROTO_ICMP:
if (update_flags & TCA_CSUM_UPDATE_FLAG_ICMP)
- if (!tcf_csum_ipv4_icmp(skb,
- iph->ihl * 4, ntohs(iph->tot_len)))
+ if (!tcf_csum_ipv4_icmp(skb, iph->ihl * 4,
+ ntohs(iph->tot_len)))
goto fail;
break;
case IPPROTO_IGMP:
if (update_flags & TCA_CSUM_UPDATE_FLAG_IGMP)
- if (!tcf_csum_ipv4_igmp(skb,
- iph->ihl * 4, ntohs(iph->tot_len)))
+ if (!tcf_csum_ipv4_igmp(skb, iph->ihl * 4,
+ ntohs(iph->tot_len)))
goto fail;
break;
case IPPROTO_TCP:
if (update_flags & TCA_CSUM_UPDATE_FLAG_TCP)
- if (!tcf_csum_ipv4_tcp(skb, iph,
- iph->ihl * 4, ntohs(iph->tot_len)))
+ if (!tcf_csum_ipv4_tcp(skb, iph, iph->ihl * 4,
+ ntohs(iph->tot_len)))
goto fail;
break;
case IPPROTO_UDP:
if (update_flags & TCA_CSUM_UPDATE_FLAG_UDP)
- if (!tcf_csum_ipv4_udp(skb, iph,
- iph->ihl * 4, ntohs(iph->tot_len), 0))
+ if (!tcf_csum_ipv4_udp(skb, iph, iph->ihl * 4,
+ ntohs(iph->tot_len), 0))
goto fail;
break;
case IPPROTO_UDPLITE:
if (update_flags & TCA_CSUM_UPDATE_FLAG_UDPLITE)
- if (!tcf_csum_ipv4_udp(skb, iph,
- iph->ihl * 4, ntohs(iph->tot_len), 1))
+ if (!tcf_csum_ipv4_udp(skb, iph, iph->ihl * 4,
+ ntohs(iph->tot_len), 1))
goto fail;
break;
}
@@ -386,7 +387,7 @@ fail:
}
static int tcf_csum_ipv6_hopopts(struct ipv6_opt_hdr *ip6xh,
- unsigned int ixhl, unsigned int *pl)
+ unsigned int ixhl, unsigned int *pl)
{
int off, len, optlen;
unsigned char *xh = (void *)ip6xh;
@@ -395,8 +396,7 @@ static int tcf_csum_ipv6_hopopts(struct ipv6_opt_hdr *ip6xh,
len = ixhl - off;
while (len > 1) {
- switch (xh[off])
- {
+ switch (xh[off]) {
case IPV6_TLV_PAD0:
optlen = 1;
break;
@@ -476,14 +476,14 @@ static int tcf_csum_ipv6(struct sk_buff *skb, u32 update_flags)
goto done;
case IPPROTO_UDP:
if (update_flags & TCA_CSUM_UPDATE_FLAG_UDP)
- if (!tcf_csum_ipv6_udp(skb, ip6h,
- hl, pl + sizeof(*ip6h), 0))
+ if (!tcf_csum_ipv6_udp(skb, ip6h, hl,
+ pl + sizeof(*ip6h), 0))
goto fail;
goto done;
case IPPROTO_UDPLITE:
if (update_flags & TCA_CSUM_UPDATE_FLAG_UDPLITE)
- if (!tcf_csum_ipv6_udp(skb, ip6h,
- hl, pl + sizeof(*ip6h), 1))
+ if (!tcf_csum_ipv6_udp(skb, ip6h, hl,
+ pl + sizeof(*ip6h), 1))
goto fail;
goto done;
default:
@@ -544,7 +544,6 @@ static int tcf_csum_dump(struct sk_buff *skb,
struct tcf_csum *p = a->priv;
struct tc_csum opt = {
.update_flags = p->update_flags,
-
.index = p->tcf_index,
.action = p->tcf_action,
.refcnt = p->tcf_refcnt - ref,
@@ -566,17 +565,17 @@ nla_put_failure:
}
static struct tc_action_ops act_csum_ops = {
- .kind = "csum",
- .hinfo = &csum_hash_info,
- .type = TCA_ACT_CSUM,
- .capab = TCA_CAP_NONE,
- .owner = THIS_MODULE,
- .act = tcf_csum,
- .dump = tcf_csum_dump,
- .cleanup = tcf_csum_cleanup,
- .lookup = tcf_hash_search,
- .init = tcf_csum_init,
- .walk = tcf_generic_walker
+ .kind = "csum",
+ .hinfo = &csum_hash_info,
+ .type = TCA_ACT_CSUM,
+ .capab = TCA_CAP_NONE,
+ .owner = THIS_MODULE,
+ .act = tcf_csum,
+ .dump = tcf_csum_dump,
+ .cleanup = tcf_csum_cleanup,
+ .lookup = tcf_hash_search,
+ .init = tcf_csum_init,
+ .walk = tcf_generic_walker
};
MODULE_DESCRIPTION("Checksum updating actions");
^ permalink raw reply related
* Re: [Bugme-new] [Bug 16626] New: Machine hangs with EIP at skb_copy_and_csum_dev
From: Jarek Poplawski @ 2010-08-23 13:10 UTC (permalink / raw)
To: Eric Dumazet
Cc: Plamen Petrov, Andrew Morton, netdev, bugzilla-daemon,
bugme-daemon
In-Reply-To: <1282568443.2486.34.camel@edumazet-laptop>
On Mon, Aug 23, 2010 at 03:00:43PM +0200, Eric Dumazet wrote:
...
> I was about to suggest a similar patch ;)
>
> Also prints skb->csum_offset and skb->len if possible
Feel free to send it: I'm a bit in hurry now...
Jarek P.
^ permalink raw reply
* Re: [Bugme-new] [Bug 16626] New: Machine hangs with EIP at skb_copy_and_csum_dev
From: Eric Dumazet @ 2010-08-23 13:00 UTC (permalink / raw)
To: Jarek Poplawski
Cc: Plamen Petrov, Andrew Morton, netdev, bugzilla-daemon,
bugme-daemon
In-Reply-To: <20100823124736.GA16966@ff.dom.local>
Le lundi 23 août 2010 à 12:47 +0000, Jarek Poplawski a écrit :
> On Mon, Aug 23, 2010 at 02:47:23PM +0300, Plamen Petrov wrote:
> > ???? 21.8.2010 ??. 11:07, Jarek Poplawski ????????????:
> >> On Sat, Aug 21, 2010 at 09:50:58AM +0200, Eric Dumazet wrote:
> >>> Le samedi 21 ao??t 2010 ?? 09:47 +0200, Jarek Poplawski a écrit :
> >>>> On Fri, Aug 20, 2010 at 09:38:35PM +0200, Jarek Poplawski wrote:
> >>>>> Plamen Petrov wrote, On 20.08.2010 12:53:
> >>>>>> So, I guess its David and Herbert's turn?...
> >>>>>
> >>>>> If you're bored in the meantime I'd suggest to do check the realtek
> >>>>> driver eg:
> >>>>> - for locking with the patch below,
> >>>>> - to turn off with ethtool its tx-checksumming and/or scatter-gather,
> ...
> > Yeah, 3 days and counting, right until I decided to try the freshly
> > announced 2.6.36-rc2.
> >
> > So I upgraded the kernel, but left the scripts that turn GRO off for
> > the tg3 card still run at system startup. This way the system ran for
> > 2 and a half hours, when I decided its time to try turning GRO on.
> >
> > I first tried to turn GRO on for the tg3 nic, and the system oopsed
> > immediately (if the panic screen is necessary - please, ask for it).
> >
> > After the system came back, I tried turning GRO on for the 2 RealTek
> > 8139 nics, too, but ethtool only accepted turning GRO off.
> >
> > And unfortunately, I can't test if other nics will fail the same way
> > as the motherboard integrated tg3 I have does, so for now, this is
> > only a tg3 + GRO on problem; I don't have any other hardware to test
> > with available.
>
> A little misunderstanding: I was intersted with turning off some
> features on realteks to change the packet path from tg3 with gro
> to realtek without gro and without tx-checksumming etc.
>
> But maybe you could try the patch below instead (so the patched
> kernel, tg3 with gro on, and realteks without any change).
>
> Thanks,
> Jarek P.
>
> --- (for debugging only)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 3721fbb..51823cd 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -1935,6 +1935,23 @@ static inline int skb_needs_linearize(struct sk_buff *skb,
> illegal_highdma(dev, skb))));
> }
>
> +static int skb_csum_start_bug(struct sk_buff *skb)
> +{
> +
> + if (skb->ip_summed == CHECKSUM_PARTIAL) {
> + long csstart;
> +
> + csstart = skb->csum_start - skb_headroom(skb);
> + if (WARN_ON(csstart > skb_headlen(skb))) {
> + pr_warning("csum_start %d, headroom %d, headlen %d\n",
> + skb->csum_start, skb_headroom(skb),
> + skb_headlen(skb));
I was about to suggest a similar patch ;)
Also prints skb->csum_offset and skb->len if possible
pr_err("csum_start %u, offset %u, headroom %d, headlen %d, len %d\n",
skb->csum_start,
skb->csum_offset,
skb_headroom(skb),
skb_headlen(skb),
skb->len);
> + return 1;
> + }
> + }
> + return 0;
> +}
> +
> int dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev,
> struct netdev_queue *txq)
> {
> @@ -1955,11 +1972,13 @@ int dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev,
> skb_orphan_try(skb);
>
> if (netif_needs_gso(dev, skb)) {
> + skb_csum_start_bug(skb);
> if (unlikely(dev_gso_segment(skb)))
> goto out_kfree_skb;
> if (skb->next)
> goto gso;
> } else {
> + skb_csum_start_bug(skb);
> if (skb_needs_linearize(skb, dev) &&
> __skb_linearize(skb))
> goto out_kfree_skb;
> @@ -1997,7 +2016,12 @@ gso:
> if (dev->priv_flags & IFF_XMIT_DST_RELEASE)
> skb_dst_drop(nskb);
>
> - rc = ops->ndo_start_xmit(nskb, dev);
> + if (skb_csum_start_bug(skb)) {
> + kfree_skb(skb);
> + rc = NETDEV_TX_OK;
> + } else
> + rc = ops->ndo_start_xmit(nskb, dev);
> +
> if (unlikely(rc != NETDEV_TX_OK)) {
> if (rc & ~NETDEV_TX_MASK)
> goto out_kfree_gso_skb;
^ permalink raw reply
* Re: [PATCH v4 0/2] Get and Set Feature Reports on HIDRAW (USB and Bluetooth)
From: Jiri Kosina @ 2010-08-23 13:00 UTC (permalink / raw)
To: Alan Ott
Cc: Stefan Achatz, Antonio Ospite, Alexey Dobriyan, Tejun Heo,
Alan Stern, Greg Kroah-Hartman, Marcel Holtmann, Stephane Chatty,
Michael Poole, David S. Miller, Bastien Nocera, Eric Dumazet,
linux-input, linux-kernel, linux-usb, linux-bluetooth, netdev
In-Reply-To: <1281990059-3562-1-git-send-email-alan@signal11.us>
On Mon, 16 Aug 2010, Alan Ott wrote:
> This is version 4. Built against 2.6.35+ revision 320b2b8de12698 .
>
> Alan Ott (2):
> HID: Add Support for Setting and Getting Feature Reports from hidraw
> Bluetooth: hidp: Add support for hidraw HIDIOCGFEATURE and
> HIDIOCSFEATURE
>
> drivers/hid/hidraw.c | 105 ++++++++++++++++++++++++++++++++++++--
> drivers/hid/usbhid/hid-core.c | 37 +++++++++++++-
> include/linux/hid.h | 3 +
> include/linux/hidraw.h | 3 +
> net/bluetooth/hidp/core.c | 114 +++++++++++++++++++++++++++++++++++++++--
> net/bluetooth/hidp/hidp.h | 8 +++
> 6 files changed, 260 insertions(+), 10 deletions(-)
Marcel, as per our previous discussion -- what is your word on this? I'd
be glad taking it once you Ack the bluetooth bits (which, as far as I
understood from your last mail, don't have strong objections against any
more).
Thanks,
--
Jiri Kosina
SUSE Labs, Novell Inc.
^ permalink raw reply
* Re: [PATCH 1/1] posix clocks: introduce syscall for clock tuning.
From: Arnd Bergmann @ 2010-08-23 12:57 UTC (permalink / raw)
To: Richard Cochran, john stultz, linux-api-u79uwXL29TY76Z2rM5mHXA
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <e253843e07ce5d15c2c8d11ce786bf979ed85ca5.1282550649.git.richard.cochran-3mrvs1K0uXizZXS1Dc/lvw@public.gmane.org>
On Monday 23 August 2010, Richard Cochran wrote:
> A new syscall is introduced that allows tuning of a POSIX clock. The
> syscall is implemented for four architectures: arm, blackfin, powerpc,
> and x86.
>
> The new syscall, clock_adjtime, takes two parameters, a frequency
> adjustment in parts per billion, and a pointer to a struct timespec
> containing the clock offset. If the pointer is NULL, a frequency
> adjustment is performed. Otherwise, the clock offset is immediately
> corrected by skipping to the new time value.
It looks well-implemented, and seems to be a reasonable extension
to the clock API. I'm looking forward to your ptp patches on top
of this to see how it all fits together.
For new syscalls, it's best to take linux-api on Cc. I also added
John, since he participated in the discussion.
> In addtion, the patch provides way to unregister a posix clock. This
> function is need to support posix clocks implemented as modules.
This part should probably be a separate patch, and you need to add
some form of serialization here to avoid races between the clock
system calls and the unregistration.
> diff --git a/kernel/posix-cpu-timers.c b/kernel/posix-cpu-timers.c
> index 9829646..5843f5a 100644
> --- a/kernel/posix-cpu-timers.c
> +++ b/kernel/posix-cpu-timers.c
> @@ -207,6 +207,11 @@ int posix_cpu_clock_set(const clockid_t which_clock, const struct timespec *tp)
> return error;
> }
>
> +int posix_cpu_clock_adj(const clockid_t which_clock, int ppb,
> + struct timespec *tp)
> +{
> + return -EOPNOTSUPP;
> +}
EOPNOTSUPP is specific to sockets, better use -EINVAL here.
Where do you use this function?
> /*
> * Sample a per-thread clock for the given task.
> diff --git a/kernel/posix-timers.c b/kernel/posix-timers.c
> index ad72342..089b0d1 100644
> --- a/kernel/posix-timers.c
> +++ b/kernel/posix-timers.c
> @@ -197,6 +197,12 @@ static int common_timer_create(struct k_itimer *new_timer)
> return 0;
> }
>
> +static inline int common_clock_adj(const clockid_t which_clock, int ppb,
> + struct timespec *tp)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> static int no_timer_create(struct k_itimer *new_timer)
> {
> return -EOPNOTSUPP;
So we already return -EOPNOTSUPP in some cases? The man page does not document this.
I wonder if we should change that to -EINVAL as well.
> @@ -488,6 +494,21 @@ void register_posix_clock(const clockid_t clock_id, struct k_clock *new_clock)
> }
> EXPORT_SYMBOL_GPL(register_posix_clock);
>
> +void unregister_posix_clock(const clockid_t clock_id)
> +{
> + struct k_clock *clock;
> +
> + if ((unsigned) clock_id >= MAX_CLOCKS) {
> + pr_err("POSIX clock unregister failed for clock_id %d\n",
> + clock_id);
> + return;
> + }
> +
> + clock = &posix_clocks[clock_id];
> + memset(clock, 0, sizeof(*clock));
> +}
> +EXPORT_SYMBOL_GPL(unregister_posix_clock);
> +
It would be possible to add locks here to serialize unregistration of a clock against
dereferencing members of posix_clocks[], but that would cause noticable overhead.
A better alternative might be to make it an RCU-protected array of pointers, and
use a rcu_assign_pointer/rcu_syncronize/kfree or call_rcu sequence in unregister_posix_clock.
Or you just live with not being able to unload this module.
Arnd
^ permalink raw reply
* [PATCH][RESEND] netfilter: fix CONFIG_COMPAT support
From: Florian Westphal @ 2010-08-23 12:56 UTC (permalink / raw)
To: davem; +Cc: netfilter-devel, netdev, Florian Westphal
commit f3c5c1bfd430858d3a05436f82c51e53104feb6b
(netfilter: xtables: make ip_tables reentrant) forgot to
also compute the jumpstack size in the compat handlers.
Result is that "iptables -I INPUT -j userchain" turns into -j DROP.
Reported by Sebastian Roesner on #netfilter, closes
http://bugzilla.netfilter.org/show_bug.cgi?id=669.
Note: arptables change is compile-tested only.
Signed-off-by: Florian Westphal <fw@strlen.de>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
---
David, it would nice if you could take this patch as Patrick seems
to be on vacation.
Problem introduced during 2.6.35 development cycle.
net/ipv4/netfilter/arp_tables.c | 3 +++
net/ipv4/netfilter/ip_tables.c | 3 +++
net/ipv6/netfilter/ip6_tables.c | 3 +++
3 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/net/ipv4/netfilter/arp_tables.c b/net/ipv4/netfilter/arp_tables.c
index 51d6c31..e8f4f9a 100644
--- a/net/ipv4/netfilter/arp_tables.c
+++ b/net/ipv4/netfilter/arp_tables.c
@@ -1420,6 +1420,9 @@ static int translate_compat_table(const char *name,
if (ret != 0)
break;
++i;
+ if (strcmp(arpt_get_target(iter1)->u.user.name,
+ XT_ERROR_TARGET) == 0)
+ ++newinfo->stacksize;
}
if (ret) {
/*
diff --git a/net/ipv4/netfilter/ip_tables.c b/net/ipv4/netfilter/ip_tables.c
index 97b64b2..d163f2e 100644
--- a/net/ipv4/netfilter/ip_tables.c
+++ b/net/ipv4/netfilter/ip_tables.c
@@ -1751,6 +1751,9 @@ translate_compat_table(struct net *net,
if (ret != 0)
break;
++i;
+ if (strcmp(ipt_get_target(iter1)->u.user.name,
+ XT_ERROR_TARGET) == 0)
+ ++newinfo->stacksize;
}
if (ret) {
/*
diff --git a/net/ipv6/netfilter/ip6_tables.c b/net/ipv6/netfilter/ip6_tables.c
index 29a7bca..8e754be 100644
--- a/net/ipv6/netfilter/ip6_tables.c
+++ b/net/ipv6/netfilter/ip6_tables.c
@@ -1766,6 +1766,9 @@ translate_compat_table(struct net *net,
if (ret != 0)
break;
++i;
+ if (strcmp(ip6t_get_target(iter1)->u.user.name,
+ XT_ERROR_TARGET) == 0)
+ ++newinfo->stacksize;
}
if (ret) {
/*
--
1.7.1
^ permalink raw reply related
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