* Re: [kernel,2.6.33-git11] lib8390: use spin_lock_irqsave for locking
From: David Miller @ 2010-03-08 17:56 UTC (permalink / raw)
To: ken_kawasaki; +Cc: netdev
In-Reply-To: <20100308212433.0fa3e453.ken_kawasaki@spring.nifty.jp>
From: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Date: Mon, 8 Mar 2010 21:24:33 +0900
>
>> This change is not correct.
>>
>> disable_irq is being intentionally used because the reset
>> sequence can take a very long time and we don't want to
>> have cpu interrupts disabled during the entire sequence.
>>
>> Otherwise slow serial devices will drop characters and
>> stuff like that.
>
>
> Actually, disable_irq is _not_ safe for lib8390 on SMP system.
> Same CPU or other CPU can call enable_irq.
>
> so lib8390 does not work properly on my SMP system.
Then you need to fix that bug, because your patch here, again,
is not correct.
^ permalink raw reply
* RE: [PATCH] Export smbios strings associated with onboard devicesto sysfs
From: Narendra_K @ 2010-03-08 17:57 UTC (permalink / raw)
To: achiang
Cc: Matt_Domsch, netdev, linux-hotplug, linux-pci, Jordan_Hargrave,
Sandeep_K_Shandilya, Charles_Rose, Shyam_Iyer
In-Reply-To: <20100308173838.GC20953@ldl.fc.hp.com>
> -----Original Message-----
> From: Alex Chiang [mailto:achiang@hp.com]
> Sent: Monday, March 08, 2010 11:09 PM
> To: K, Narendra
> Cc: Domsch, Matt; netdev@vger.kernel.org; linux-
> hotplug@vger.kernel.org; linux-pci@vger.kernel.org; Hargrave, Jordan;
> Shandilya, Sandeep K; Rose, Charles; Iyer, Shyam
> Subject: Re: [PATCH] Export smbios strings associated with onboard
> devicesto sysfs
>
> * Narendra K <Narendra_K@dell.com>:
> >
> > Resending the patch with review comments incorporated.
> >
> > Signed-off-by: Jordan Hargrave <Jordan_Hargrave@dell.com>
> > Signed-off-by: Narendra K <Narendra_K@dell.com>
>
> Here is a patch I wrote that would be nice if you could
> incorporate into your patch series.
>
> It adds support for HP OEM SMBIOS record Type 209, so that you
> can populate the 'label' attribute on existing HP platforms.
>
> It needs that hunk I suggested in my previous mail to apply
> cleanly.
>
Sure, thanks.
With regards,
Narendra K
^ permalink raw reply
* Re: [PATCH] net: fix route cache rebuilds
From: Neil Horman @ 2010-03-08 18:06 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Paweł Staszewski
In-Reply-To: <1268054400.6148.99.camel@edumazet-laptop>
On Mon, Mar 08, 2010 at 02:20:00PM +0100, Eric Dumazet wrote:
> We added an automatic route cache rebuilding in commit 1080d709fb9d8cd43
> but had to correct few bugs. One of the assumption of original patch,
> was that entries where kept sorted in a given way.
>
> This assumption is known to be wrong (commit 1ddbcb005c395518 gave an
> explanation of this and corrected a leak) and expensive to respect.
>
> Paweł Staszewski reported to me one of his machine got its routing cache
> disabled after few messages like :
>
> [ 2677.850065] Route hash chain too long!
> [ 2677.850080] Adjust your secret_interval!
> [82839.662993] Route hash chain too long!
> [82839.662996] Adjust your secret_interval!
> [155843.731650] Route hash chain too long!
> [155843.731664] Adjust your secret_interval!
> [155843.811881] Route hash chain too long!
> [155843.811891] Adjust your secret_interval!
> [155843.858209] vlan0811: 5 rebuilds is over limit, route caching
> disabled
> [155843.858212] Route hash chain too long!
> [155843.858213] Adjust your secret_interval!
>
> This is because rt_intern_hash() might be fooled when computing a chain
> length, because multiple entries with same keys can differ because of
> TOS (or mark/oif) bits.
>
> In the rare case the fast algorithm see a too long chain, and before
> taking expensive path, we call a helper function in order to not count
> duplicates of same routes, that only differ with tos/mark/oif bits. This
> helper works with data already in cpu cache and is not be very
> expensive, despite its O(N^2) implementation.
>
> Paweł Staszewski sucessfully tested this patch on his loaded router.
>
> Reported-and-tested-by: Paweł Staszewski <pstaszewski@itcare.pl>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
> net/ipv4/route.c | 50 ++++++++++++++++++++++++++++++++++-----------
> 1 file changed, 38 insertions(+), 12 deletions(-)
>
This looks pretty reasonable to me, Thanks Eric!
Acked-by: Neil Horman <nhorman@tuxdriver.com>
> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> index b2ba558..d9b4024 100644
> --- a/net/ipv4/route.c
> +++ b/net/ipv4/route.c
> @@ -146,7 +146,6 @@ static struct dst_entry *ipv4_negative_advice(struct dst_entry *dst);
> static void ipv4_link_failure(struct sk_buff *skb);
> static void ip_rt_update_pmtu(struct dst_entry *dst, u32 mtu);
> static int rt_garbage_collect(struct dst_ops *ops);
> -static void rt_emergency_hash_rebuild(struct net *net);
>
>
> static struct dst_ops ipv4_dst_ops = {
> @@ -780,11 +779,30 @@ static void rt_do_flush(int process_context)
> #define FRACT_BITS 3
> #define ONE (1UL << FRACT_BITS)
>
> +/*
> + * Given a hash chain and an item in this hash chain,
> + * find if a previous entry has the same hash_inputs
> + * (but differs on tos, mark or oif)
> + * Returns 0 if an alias is found.
> + * Returns ONE if rth has no alias before itself.
> + */
> +static int has_noalias(const struct rtable *head, const struct rtable *rth)
> +{
> + const struct rtable *aux = head;
> +
> + while (aux != rth) {
> + if (compare_hash_inputs(&aux->fl, &rth->fl))
> + return 0;
> + aux = aux->u.dst.rt_next;
> + }
> + return ONE;
> +}
> +
> static void rt_check_expire(void)
> {
> static unsigned int rover;
> unsigned int i = rover, goal;
> - struct rtable *rth, *aux, **rthp;
> + struct rtable *rth, **rthp;
> unsigned long samples = 0;
> unsigned long sum = 0, sum2 = 0;
> unsigned long delta;
> @@ -835,15 +853,7 @@ nofree:
> * attributes don't unfairly skew
> * the length computation
> */
> - for (aux = rt_hash_table[i].chain;;) {
> - if (aux == rth) {
> - length += ONE;
> - break;
> - }
> - if (compare_hash_inputs(&aux->fl, &rth->fl))
> - break;
> - aux = aux->u.dst.rt_next;
> - }
> + length += has_noalias(rt_hash_table[i].chain, rth);
> continue;
> }
> } else if (!rt_may_expire(rth, tmo, ip_rt_gc_timeout))
> @@ -1073,6 +1083,21 @@ work_done:
> out: return 0;
> }
>
> +/*
> + * Returns number of entries in a hash chain that have different hash_inputs
> + */
> +static int slow_chain_length(const struct rtable *head)
> +{
> + int length = 0;
> + const struct rtable *rth = head;
> +
> + while (rth) {
> + length += has_noalias(head, rth);
> + rth = rth->u.dst.rt_next;
> + }
> + return length >> FRACT_BITS;
> +}
> +
> static int rt_intern_hash(unsigned hash, struct rtable *rt,
> struct rtable **rp, struct sk_buff *skb)
> {
> @@ -1185,7 +1210,8 @@ restart:
> rt_free(cand);
> }
> } else {
> - if (chain_length > rt_chain_length_max) {
> + if (chain_length > rt_chain_length_max &&
> + slow_chain_length(rt_hash_table[hash].chain) > rt_chain_length_max) {
> struct net *net = dev_net(rt->u.dst.dev);
> int num = ++net->ipv4.current_rt_cache_rebuild_count;
> if (!rt_caching(dev_net(rt->u.dst.dev))) {
>
>
>
>
>
^ permalink raw reply
* Re: [PATCH 2/6] C/R: Basic support for network namespaces and devices (v5)
From: Dan Smith @ 2010-03-08 18:07 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Oren Laadan, containers, den, netdev, davem, benjamin.thery
In-Reply-To: <m1hboqu2cv.fsf@fess.ebiederm.org>
EB> Can we take advantage of the fact that when you destroy a network
EB> namespace the virtual devices in that network namespace are also
EB> destroyed?
Hmm, that kinda seems like cheating, but maybe so. I'll take a look :)
--
Dan Smith
IBM Linux Technology Center
email: danms@us.ibm.com
^ permalink raw reply
* Re: [net-next-2.6 PATCH] bonding: refuse to change bond type if it's used
From: Stephen Hemminger @ 2010-03-08 18:24 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, fubar, bonding-devel, davem
In-Reply-To: <20100308175406.GA2834@psychotron.lab.eng.brq.redhat.com>
On Mon, 8 Mar 2010 18:54:06 +0100
Jiri Pirko <jpirko@redhat.com> wrote:
> It's not desirable to be able to change the type of net_device in bond device if
> it's in use by bridge, or vlan, or so. At the moment, there is possible for
> example to have INFINIBAND bond type in bridge (by adding bond with eth type to
> a bridge first and then enslave INFINIBAND device).
Rather than building lots of back pointer dependencies, why not
have another netdevice notifier that allows other subsystems to
see the type change and reject it if they care? That way the code
would be more modular and expandable.
^ permalink raw reply
* Re: [PATCH 2/6] C/R: Basic support for network namespaces and devices (v5)
From: Oren Laadan @ 2010-03-08 18:36 UTC (permalink / raw)
To: Dan Smith; +Cc: containers, den, netdev, davem, ebiederm, benjamin.thery
In-Reply-To: <871vfuiul6.fsf@caffeine.danplanet.com>
Dan Smith wrote:
> OL> I'm confused: in checkpoint_ns() inside the for_each_netdev() loop
> OL> you first test for dev->netdev_ops->ndo_checkpoint and then call
> OL> checkpoint_obj(... CKPT_OBJ_NETDEV) - which in turn will call
> OL> checkpoint_netdev(), which will again test for
> dev-> netdev_ops->ndo_checkpoint ... am I reading it wrongly ?
>
> In the case of veth, yes. It goes something like this:
>
> checkpoint_netns() {
> foreach netdev in netns {
> checkpoint_netdev {
> if netdev is veth {
> checkpoint_peer(); // Will call checkpoint_netdev again
> }
> }
> }
> }
>
> It shouldn't happen, but it seems like since we could potentially add
> another checkpoint_obj(mydev) somewhere other than in
> checkpoint_netdev(), it is reasonable to check that there is actually
> something to call before we call it.
>
> Would you prefer a BUG()?
Ok.. so this is solved over IRC - the test was redundant :)
>
> OL> How about this - to me it feels simpler:
>
> OL> dev = rtnl_newlink(veth_new_link_msg, &veth, this_name);
> OL> if (IS_ERR(dev))
> OL> return dev;
>
> OL> peer = dev_get_by_name(current->nsproxy->net_ns, peer_name);
> OL> if (!peer) {
> OL> ret = -EINVAL;
> OL> goto err_dev;
> OL> }
> OL> ret = ckpt_obj_insert(ctx, peer, h->veth.peer_ref,
> OL> CKPT_OBJ_NETDEV);
> OL> if (ret < 0)
> OL> goto err_peer;
>
> OL> dev_put(peer);
>
> OL> dq.dev = dev;
> OL> dq.peer = peer;
> OL> ret = deferqueue_add(ctx->deferqueue, &dq, sizeof(dq),
> OL> netdev_noop, netdev_cleanup);
> OL> if (ret)
> OL> goto err_peer;
>
> If you fail here you need to unregister_netdev() because the dev_put()
> that the objhash will not cause it to happen. Unless we add something
> to allow you to remove your object from the hash, you can't prevent
> that final put, so you have to have it in the deferqueue for
> later. You can't check the refcount in the objhash function because it
> will differ depending on the number of addresses and protocols the
> device has, and those don't get released until unregister_netdev()
> which will block if you call it before you've released all of your
> references. If the objhash put function could examine ctx->errno,
> then it could drop its reference and then call unregister_netdev(),
> but that would involve changing all the drop functions. What am I
> missing?
>
Oh .. I see - I missed that point that a ref is taken once it's
inserted to the objhash, so insert must be preceeded by the call
to deferqueue. Thanks for the explanation.
It still makes sense to have a single call to deferqueue that
relates to both the veth and the peer, instead of two separate
calls, no ?
Oren.
^ permalink raw reply
* Re: [PATCH 0/6]qlcnic: bug fixes
From: David Miller @ 2010-03-08 18:45 UTC (permalink / raw)
To: amit.salecha; +Cc: netdev, dhananjay.phadke, ameen.rahman
In-Reply-To: <1268043290-19929-1-git-send-email-amit.salecha@qlogic.com>
From: Amit Kumar Salecha <amit.salecha@qlogic.com>
Date: Mon, 8 Mar 2010 02:14:44 -0800
> Hi
> Series of 6 patches to fix minor bugs and to enhance driver statistics.
> Please apply them in net-2.6 tree.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: fix route cache rebuilds
From: David Miller @ 2010-03-08 18:46 UTC (permalink / raw)
To: nhorman; +Cc: eric.dumazet, netdev, pstaszewski
In-Reply-To: <20100308180603.GC23634@hmsreliant.think-freely.org>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Mon, 8 Mar 2010 13:06:03 -0500
> On Mon, Mar 08, 2010 at 02:20:00PM +0100, Eric Dumazet wrote:
...
>> Reported-and-tested-by: Paweł Staszewski <pstaszewski@itcare.pl>
>> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
...
> This looks pretty reasonable to me, Thanks Eric!
> Acked-by: Neil Horman <nhorman@tuxdriver.com>
Applied, thanks guys.
^ permalink raw reply
* Re: [PATCH 1/2] be2net: remove usage of be_pci_func
From: David Miller @ 2010-03-08 18:46 UTC (permalink / raw)
To: ajitk, ajitkhaparde; +Cc: netdev
In-Reply-To: <20100308002125.GA18118@serverengines.com>
From: Ajit Khaparde <ajitkhaparde@gmail.com>
Date: Mon, 8 Mar 2010 05:51:27 +0530
> When PCI functions are virtuialized in applications by assigning PCI
> functions to VM (PCI passthrough), the be2net driver in the VM sees a
> different function number. So, use of PCI function number in any
> calculation will break existing code. This patch takes care of it.
>
> Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] be2net: remove unused code in be_load_fw
From: David Miller @ 2010-03-08 18:46 UTC (permalink / raw)
To: ajitk, ajitkhaparde; +Cc: netdev
In-Reply-To: <20100308002342.GB18118@serverengines.com>
From: Ajit Khaparde <ajitkhaparde@gmail.com>
Date: Mon, 8 Mar 2010 05:53:44 +0530
> This patch cleans up some unused code from be_load_fw().
>
> Signed-off-by: Ajit Khaparde <ajitk@serverengines.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: add __must_check to sk_add_backlog
From: David Miller @ 2010-03-08 18:46 UTC (permalink / raw)
To: yi.zhu; +Cc: netdev
In-Reply-To: <1268014899-31318-1-git-send-email-yi.zhu@intel.com>
From: Zhu Yi <yi.zhu@intel.com>
Date: Mon, 8 Mar 2010 10:21:39 +0800
> Add the "__must_check" tag to sk_add_backlog() so that any failure to
> check and drop packets will be warned about.
>
> Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH V3 2/8] tcp: use limited socket backlog
From: David Miller @ 2010-03-08 18:46 UTC (permalink / raw)
To: eric.dumazet; +Cc: yi.zhu, netdev
In-Reply-To: <1268040117.6148.68.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 08 Mar 2010 10:21:57 +0100
> Le vendredi 05 mars 2010 à 07:19 +0100, Eric Dumazet a écrit :
>
>> I'll submit a followup patch to add a MIB counter if your patch gets in.
>>
>
> As promised, here it is.
>
> [PATCH] tcp: Add SNMP counters for backlog and min_ttl drops
>
> Commit 6b03a53a (tcp: use limited socket backlog) added the possibility
> of dropping frames when backlog queue is full.
>
> Commit d218d111 (tcp: Generalized TTL Security Mechanism) added the
> possibility of dropping frames when TTL is under a given limit.
>
> This patch adds new SNMP MIB entries, named TCPBacklogDrop and
> TCPMinTTLDrop, published in /proc/net/netstat in TcpExt: line
>
> netstat -s | egrep "TCPBacklogDrop|TCPMinTTLDrop"
> TCPBacklogDrop: 0
> TCPMinTTLDrop: 0
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH 6/13] bridge: Add core IGMP snooping support
From: Arnd Bergmann @ 2010-03-08 18:50 UTC (permalink / raw)
To: paulmck; +Cc: Herbert Xu, David S. Miller, netdev, Stephen Hemminger
In-Reply-To: <20100307031151.GA7546@linux.vnet.ibm.com>
On Sunday 07 March 2010, Paul E. McKenney wrote:
> On Sun, Mar 07, 2010 at 10:45:00AM +0800, Herbert Xu wrote:
> > On Sat, Mar 06, 2010 at 11:00:00AM -0800, Paul E. McKenney wrote:
>
> OK, just re-checked your patch, and it looks OK.
>
> Also adding Arnd to CC.
>
> Arnd, would it be reasonable to extend your RCU-sparse changes to have
> four different pointer namespaces, one for each flavor of RCU? (RCU,
> RCU-bh, RCU-sched, and SRCU)? Always a fan of making the computer do
> the auditing where reasonable. ;-)
Yes, I guess that would be possible. I'd still leave out the rculist
from any annotations for now, as this would get even more complex then.
One consequence will be the need for new rcu_assign_pointer{,_bh,_sched}
macros that check the address space of the first argument, otherwise
you'd be able to stick anything in there, including non-__rcu pointers.
I've also found a few places (less than a handful) that use RCU to
protect per-CPU data. Not sure how to deal with that, because now
this also has its own named address space (__percpu), and it's probably
a bit too much to introduce all combinations of
{s,}rcu_{assign_pointer,dereference}{,_bh,_sched}{,_const}{,_percpu},
so I'm ignoring them for now.
> This could potentially catch the mismatched call_rcu()s, at least if the
> rcu_head could be labeled.
I haven't labeled the rcu_head at all so far, and I'm not sure if that's
necessary. What I've been thinking about is replacing typical code like
/* this is called with the writer-side lock held */
void foo_assign(struct foo *foo, struct bar *newbar)
{
struct bar *bar = rcu_dereference_const(foo->bar); /* I just had to add
this dereference */
rcu_assign_pointer(foo->bar, newbar);
if (bar)
call_rcu(&bar->rcu, bar_destructor);
}
with the shorter
void foo_assign(struct foo *foo, struct bar *newbar)
{
struct bar *bar = rcu_exchange(foo->bar, newbar);
if (bar)
call_rcu(&bar->rcu, bar_destructor);
}
Now we could combine this to
void foo_assign(struct foo *foo, struct bar *newbar)
{
rcu_exchange_call(foo->bar, newbar, rcu, bar_destructor);
}
#define rcu_exchange_call(ptr, new, member, func) \
({ \
typeof(new) old = rcu_exchange((ptr),(new)); \
if (old) \
call_rcu(&(old)->member, (func)); \
old; \
})
and make appropriate versions of all the above rcu methods for this.
With some extra macro magic, this could even become type safe and
accept a function that takes a typeof(ptr) argument instead of the
rcu_head.
Arnd
^ permalink raw reply
* RE: TCP_COOKIE_TRANSACTIONS synack data
From: Eric Dumazet @ 2010-03-08 19:28 UTC (permalink / raw)
To: Penttilä Mika, David Miller
Cc: netdev@vger.kernel.org, William Allen Simpson
In-Reply-To: <2BC93087D531FF4A98881820AFE8AE7B74C409E1D6@jklmail01.ixonos.local>
Le lundi 08 mars 2010 à 18:33 +0200, Penttilä Mika a écrit :
> >
> > Le lundi 08 mars 2010 à 16:27 +0200, Penttilä Mika a écrit :
> > > The TCP_COOKIE_TRANSACTIONS synack data seems pretty unsafe atm.
> > > >From tcp_make_synack():
> > >
> > >
> > > u8 *buf = skb_put(skb, cvp->s_data_desired);
> > >
> > > /* copy data directly from the listening socket. */
> > > memcpy(buf, cvp->s_data_payload, cvp->s_data_desired);
> > >
> > >
> > > The skb here is allocated for MAX_TCP_HEADER + 15 and synack data
> > could be as long as TCP_MSS_DEFAULT, panic():ing at the skb_put().
> > >
> >
> > Indeed, since start of december 2009.
> >
> > Do you plan to provide a patch do you prefer someone else take care of
> > it ?
> >
>
> I'm not planning to provide a patch at least very soon so I think someone else can provide a quicker fix.
>
>
OK thanks Mika !
I suspect following patch might be an appropriate fix for this problem.
[PATCH] tcp: Fix tcp_make_synack()
Commit 4957faad (TCPCT part 1g: Responder Cookie => Initiator), part
of TCP_COOKIE_TRANSACTION implementation, forgot to correctly size
synack skb in case user data must be included.
Many thanks to Mika Pentillä for spotting this error.
Reported-by: Penttillä Mika <mika.penttila@ixonos.com>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/ipv4/tcp_output.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 4a1605d..f181b78 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -2395,13 +2395,17 @@ struct sk_buff *tcp_make_synack(struct sock *sk, struct dst_entry *dst,
struct tcp_extend_values *xvp = tcp_xv(rvp);
struct inet_request_sock *ireq = inet_rsk(req);
struct tcp_sock *tp = tcp_sk(sk);
+ const struct tcp_cookie_values *cvp = tp->cookie_values;
struct tcphdr *th;
struct sk_buff *skb;
struct tcp_md5sig_key *md5;
int tcp_header_size;
int mss;
+ int s_data_desired = 0;
- skb = sock_wmalloc(sk, MAX_TCP_HEADER + 15, 1, GFP_ATOMIC);
+ if (cvp != NULL && cvp->s_data_constant && cvp->s_data_desired)
+ s_data_desired = cvp->s_data_desired;
+ skb = sock_wmalloc(sk, MAX_TCP_HEADER + 15 + s_data_desired, 1, GFP_ATOMIC);
if (skb == NULL)
return NULL;
@@ -2457,16 +2461,12 @@ struct sk_buff *tcp_make_synack(struct sock *sk, struct dst_entry *dst,
TCPCB_FLAG_SYN | TCPCB_FLAG_ACK);
if (OPTION_COOKIE_EXTENSION & opts.options) {
- const struct tcp_cookie_values *cvp = tp->cookie_values;
-
- if (cvp != NULL &&
- cvp->s_data_constant &&
- cvp->s_data_desired > 0) {
- u8 *buf = skb_put(skb, cvp->s_data_desired);
+ if (s_data_desired) {
+ u8 *buf = skb_put(skb, s_data_desired);
/* copy data directly from the listening socket. */
- memcpy(buf, cvp->s_data_payload, cvp->s_data_desired);
- TCP_SKB_CB(skb)->end_seq += cvp->s_data_desired;
+ memcpy(buf, cvp->s_data_payload, s_data_desired);
+ TCP_SKB_CB(skb)->end_seq += s_data_desired;
}
if (opts.hash_size > 0) {
^ permalink raw reply related
* Re: TCP_COOKIE_TRANSACTIONS synack data
From: David Miller @ 2010-03-08 19:32 UTC (permalink / raw)
To: eric.dumazet; +Cc: mika.penttila, netdev, william.allen.simpson
In-Reply-To: <1268076495.2819.57.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 08 Mar 2010 20:28:15 +0100
> [PATCH] tcp: Fix tcp_make_synack()
>
> Commit 4957faad (TCPCT part 1g: Responder Cookie => Initiator), part
> of TCP_COOKIE_TRANSACTION implementation, forgot to correctly size
> synack skb in case user data must be included.
>
> Many thanks to Mika Pentillä for spotting this error.
>
> Reported-by: Penttillä Mika <mika.penttila@ixonos.com>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Thanks Eric, applied and I'll queue this up for 2.6.33-stable
^ permalink raw reply
* [PATCH] tipc: filter out messages not intended for this host
From: Neil Horman @ 2010-03-08 19:41 UTC (permalink / raw)
To: netdev; +Cc: allan.stephens, nhorman, davem
Port commit 20deb48d16fdd07ce2fdc8d03ea317362217e085
from git://tipc.cslab.ericsson.net/pub/git/people/allan/tipc.git
Part of the larger effort I'm trying to help with getting all the downstreamed
code from windriver forward ported to the upstream tree
Origional commit message
Restore check to filter out inadverdently received messages
This patch reimplements a check that allows TIPC to discard messages
that are not intended for it. This check was present in TIPC 1.5/1.6,
but was removed by accident during the development of TIPC 1.7; it has
now been updated to account for new features present in TIPC 1.7 and
reinserted into TIPC. The main benefit of this check is to filter
out messages arriving from orphaned link endpoints, which can arise
when a node exits the network and then re-enters it with a different
TIPC network address (i.e. <Z.C.N> value).
tested with the tipc sanity test suite.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Origionally-authored-by: Allan Stephens <allan.stephens@windriver.com>
link.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/net/tipc/link.c b/net/tipc/link.c
index 6f50f64..da3a384 100644
--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -1882,6 +1882,15 @@ void tipc_recv_msg(struct sk_buff *head, struct tipc_bearer *tb_ptr)
(msg_destnode(msg) != tipc_own_addr)))
goto cont;
+ /* Discard non-routeable messages destined for another node */
+
+ if (unlikely(!msg_isdata(msg) &&
+ (msg_destnode(msg) != tipc_own_addr))) {
+ if ((msg_user(msg) != CONN_MANAGER) &&
+ (msg_user(msg) != MSG_FRAGMENTER))
+ goto cont;
+ }
+
/* Locate unicast link endpoint that should handle message */
n_ptr = tipc_node_find(msg_prevnode(msg));
^ permalink raw reply related
* [PATCH] ethtool: Use noinline_for_stack
From: Eric Dumazet @ 2010-03-08 19:46 UTC (permalink / raw)
To: David Miller; +Cc: netdev
Use self documenting noinline_for_stack instead of duplicated comments.
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/core/ethtool.c | 40 ++++++++--------------------------------
1 file changed, 8 insertions(+), 32 deletions(-)
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index 33d2ded..f4cb6b6 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -200,10 +200,7 @@ static int ethtool_set_settings(struct net_device *dev, void __user *useraddr)
return dev->ethtool_ops->set_settings(dev, &cmd);
}
-/*
- * noinline attribute so that gcc doesnt use too much stack in dev_ethtool()
- */
-static noinline int ethtool_get_drvinfo(struct net_device *dev, void __user *useraddr)
+static noinline_for_stack int ethtool_get_drvinfo(struct net_device *dev, void __user *useraddr)
{
struct ethtool_drvinfo info;
const struct ethtool_ops *ops = dev->ethtool_ops;
@@ -242,10 +239,7 @@ static noinline int ethtool_get_drvinfo(struct net_device *dev, void __user *use
return 0;
}
-/*
- * noinline attribute so that gcc doesnt use too much stack in dev_ethtool()
- */
-static noinline int ethtool_get_sset_info(struct net_device *dev,
+static noinline_for_stack int ethtool_get_sset_info(struct net_device *dev,
void __user *useraddr)
{
struct ethtool_sset_info info;
@@ -305,10 +299,7 @@ out:
return ret;
}
-/*
- * noinline attribute so that gcc doesnt use too much stack in dev_ethtool()
- */
-static noinline int ethtool_set_rxnfc(struct net_device *dev, void __user *useraddr)
+static noinline_for_stack int ethtool_set_rxnfc(struct net_device *dev, void __user *useraddr)
{
struct ethtool_rxnfc cmd;
@@ -321,10 +312,7 @@ static noinline int ethtool_set_rxnfc(struct net_device *dev, void __user *usera
return dev->ethtool_ops->set_rxnfc(dev, &cmd);
}
-/*
- * noinline attribute so that gcc doesnt use too much stack in dev_ethtool()
- */
-static noinline int ethtool_get_rxnfc(struct net_device *dev, void __user *useraddr)
+static noinline_for_stack int ethtool_get_rxnfc(struct net_device *dev, void __user *useraddr)
{
struct ethtool_rxnfc info;
const struct ethtool_ops *ops = dev->ethtool_ops;
@@ -396,10 +384,7 @@ static void __rx_ntuple_filter_add(struct ethtool_rx_ntuple_list *list,
list->count++;
}
-/*
- * noinline attribute so that gcc doesnt use too much stack in dev_ethtool()
- */
-static noinline int ethtool_set_rx_ntuple(struct net_device *dev, void __user *useraddr)
+static noinline_for_stack int ethtool_set_rx_ntuple(struct net_device *dev, void __user *useraddr)
{
struct ethtool_rx_ntuple cmd;
const struct ethtool_ops *ops = dev->ethtool_ops;
@@ -867,10 +852,7 @@ static int ethtool_set_eeprom(struct net_device *dev, void __user *useraddr)
return ret;
}
-/*
- * noinline attribute so that gcc doesnt use too much stack in dev_ethtool()
- */
-static noinline int ethtool_get_coalesce(struct net_device *dev, void __user *useraddr)
+static noinline_for_stack int ethtool_get_coalesce(struct net_device *dev, void __user *useraddr)
{
struct ethtool_coalesce coalesce = { .cmd = ETHTOOL_GCOALESCE };
@@ -884,10 +866,7 @@ static noinline int ethtool_get_coalesce(struct net_device *dev, void __user *us
return 0;
}
-/*
- * noinline attribute so that gcc doesnt use too much stack in dev_ethtool()
- */
-static noinline int ethtool_set_coalesce(struct net_device *dev, void __user *useraddr)
+static noinline_for_stack int ethtool_set_coalesce(struct net_device *dev, void __user *useraddr)
{
struct ethtool_coalesce coalesce;
@@ -1297,10 +1276,7 @@ static int ethtool_set_value(struct net_device *dev, char __user *useraddr,
return actor(dev, edata.data);
}
-/*
- * noinline attribute so that gcc doesnt use too much stack in dev_ethtool()
- */
-static noinline int ethtool_flash_device(struct net_device *dev, char __user *useraddr)
+static noinline_for_stack int ethtool_flash_device(struct net_device *dev, char __user *useraddr)
{
struct ethtool_flash efl;
^ permalink raw reply related
* Re: [RFC][PATCH] ns: Syscalls for better namespace sharing control.
From: Daniel Lezcano @ 2010-03-08 19:57 UTC (permalink / raw)
To: Eric W. Biederman
Cc: Pavel Emelyanov, Sukadev Bhattiprolu, Serge Hallyn,
Linux Netdev List, containers, Netfilter Development Mailinglist,
Ben Greear
In-Reply-To: <m11vfuvi1t.fsf@fess.ebiederm.org>
Eric W. Biederman wrote:
> Daniel Lezcano <daniel.lezcano@free.fr> writes:
>
>
>> Eric W. Biederman wrote:
>>
>>> I have take an snapshot of my development tree and placed it at.
>>>
>>>
>>> git://git.kernel.org/pub/scm/linux/people/ebiederm/linux-2.6.33-nsfd-v5.git
>>>
>>>
>> Hi Eric,
>>
>> thanks for the pointer.
>>
>> I tried to boot the kernel under qemu and I got this oops:
>>
>
> I am clearly running an old userspace on my test machine. No udev.
> It looks like udev has a long standing netlink misfeature, where
> it does not initializing NETLINK_CB....
>
>
> >From 8d85e3ab88718eda3d94cf8e1be14b69dae2b8f1 Mon Sep 17 00:00:00 2001
> From: Eric W. Biederman <ebiederm@xmission.com>
> Date: Mon, 8 Mar 2010 09:25:20 -0800
> Subject: [PATCH] kobject_uevent: Use the netlink allocator helper...
>
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
>
Thanks.
I was able to boot but I have the following warning:
------------[ cut here ]------------
WARNING: at net/netlink/af_netlink.c:198 netlink_sock_destruct+0x72/0xac()
Hardware name:
Modules linked in: [last unloaded: scsi_wait_scan]
Pid: 840, comm: nash-hotplug Tainted: G W 2.6.33 #2
Call Trace:
[<ffffffff812df182>] ? netlink_sock_destruct+0x72/0xac
[<ffffffff8102ca29>] warn_slowpath_common+0x77/0xa4
[<ffffffff8102ca65>] warn_slowpath_null+0xf/0x11
[<ffffffff812df182>] netlink_sock_destruct+0x72/0xac
[<ffffffff812bb2a4>] __sk_free+0x1e/0x118
[<ffffffff812bb40d>] sk_free+0x19/0x1b
[<ffffffff812e0dc2>] netlink_release+0x246/0x253
[<ffffffff812b825a>] sock_release+0x1a/0x6b
[<ffffffff812b82cd>] sock_close+0x22/0x26
[<ffffffff810c7823>] __fput+0x11b/0x1d7
[<ffffffff810c78f6>] fput+0x17/0x19
[<ffffffff810c4ae2>] filp_close+0x67/0x72
[<ffffffff8102e75c>] put_files_struct+0x6a/0xd4
[<ffffffff8102e80d>] exit_files+0x47/0x4f
[<ffffffff8102fe59>] do_exit+0x1eb/0x693
[<ffffffff813864c2>] ? _raw_spin_unlock_irq+0x2b/0x31
[<ffffffff81030373>] do_group_exit+0x72/0x9b
[<ffffffff8103f37c>] get_signal_to_deliver+0x3a1/0x3c1
[<ffffffff81001e8e>] do_notify_resume+0x8d/0x6ea
[<ffffffff810538c9>] ? trace_hardirqs_on_caller+0x110/0x13a
[<ffffffff8102851e>] ? finish_task_switch+0x6a/0xb3
[<ffffffff810284b4>] ? finish_task_switch+0x0/0xb3
[<ffffffff813867aa>] ? retint_signal+0x11/0x87
[<ffffffff810538c9>] ? trace_hardirqs_on_caller+0x110/0x13a
[<ffffffff813867df>] retint_signal+0x46/0x87
---[ end trace d4a1e4cbaa70d63d ]---
And I have a kernel panic when exiting a network namespace using a macvlan:
linux-swk0 login: BUG: unable to handle kernel paging request at
ffff880035475678
IP: [<ffffffff8128dbef>] macvlan_stop+0x54/0x7a
PGD 160b063 PUD 160f063 PMD 2aa067 PTE 35475160
Oops: 0002 [#1] DEBUG_PAGEALLOC
last sysfs file: /sys/devices/pci0000:00/0000:00:03.0/net/eth0/flags
CPU 0
Pid: 10, comm: netns Tainted: G W 2.6.33 #2 /
RIP: 0010:[<ffffffff8128dbef>] [<ffffffff8128dbef>] macvlan_stop+0x54/0x7a
RSP: 0018:ffff88003f92bc50 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff880035440800 RCX: ffff880035440800
RDX: ffff880035475678 RSI: ffff88003f913710 RDI: ffff88003cde9800
RBP: ffff88003f92bc70 R08: 0000000000000004 R09: 0000000000000000
R10: 0080000000000000 R11: ffff88003f92bbf0 R12: ffff88003cde9800
R13: ffff880035440de0 R14: 0080000000000000 R15: 0000000800000000
FS: 0000000000000000(0000) GS:ffffffff8161b000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffff880035475678 CR3: 000000003eb41000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process netns (pid: 10, threadinfo ffff88003f92a000, task ffff88003f913058)
Stack:
ffffffff814328a0 ffff880035440800 ffffffff814328a0 ffff88003553a800
<0> ffff88003f92bc90 ffffffff812c9150 ffff880035440800 ffff88003f92bd00
<0> ffff88003f92bcd0 ffffffff812c9259 ffff88003f92bcd0 ffff88003f92bd00
Call Trace:
[<ffffffff812c9150>] dev_close+0x86/0xa8
[<ffffffff812c9259>] rollback_registered_many+0xe7/0x208
[<ffffffff812c9390>] unregister_netdevice_many+0x16/0x62
[<ffffffff812c952d>] default_device_exit_batch+0x9f/0xb3
[<ffffffff812c3906>] ops_exit_list+0x4e/0x56
[<ffffffff812c40f4>] cleanup_net+0xfe/0x1b7
[<ffffffff81042db6>] worker_thread+0x227/0x32d
[<ffffffff81042d60>] ? worker_thread+0x1d1/0x32d
[<ffffffff813864c2>] ? _raw_spin_unlock_irq+0x2b/0x31
[<ffffffff812c3ff6>] ? cleanup_net+0x0/0x1b7
[<ffffffff810466ae>] ? autoremove_wake_function+0x0/0x38
[<ffffffff81042b8f>] ? worker_thread+0x0/0x32d
[<ffffffff810462e0>] kthread+0x7c/0x84
[<ffffffff810035b4>] kernel_thread_helper+0x4/0x10
[<ffffffff8138673a>] ? restore_args+0x0/0x30
[<ffffffff81046264>] ? kthread+0x0/0x84
[<ffffffff810035b0>] ? kernel_thread_helper+0x0/0x10
Code: 01 00 00 02 74 0b 83 ce ff 4c 89 e7 e8 a1 8f 03 00 48 8b b3 50 02
00 00 4c 89 e7 e8 df 8e 03 00 49 8b 45 18 49 8b 55 20 48 85 c0 <48> 89
02 74 04 48 89 50 08 48 be 00 02 20 00 00 00 ad de 49 89
RIP [<ffffffff8128dbef>] macvlan_stop+0x54/0x7a
RSP <ffff88003f92bc50>
CR2: ffff880035475678
---[ end trace d4a1e4cbaa70d63e ]---
addr2line -e ./vmlinux ffffffff812c9150 gives net/core/dev.c:1252
^ permalink raw reply
* [PATCH] tipc: fix endianness on tipc subscriber messages
From: Neil Horman @ 2010-03-08 20:03 UTC (permalink / raw)
To: netdev; +Cc: allan.stephens, davem, nhorman
Remove htohl implementation from tipc
I was working on forward porting the downstream commits for TIPC and ran accross this one:
http://tipc.cslab.ericsson.net/cgi-bin/gitweb.cgi?p=people/allan/tipc.git;a=commitdiff;h=894279b9437b63cbb02405ad5b8e033b51e4e31e
I was going to just take it, when I looked closer and noted what it was doing.
This is basically a routine to byte swap fields of data in sent/received packets
for tipc, dependent upon the receivers guessed endianness of the peer when a
connection is established. Asside from just seeming silly to me, it appears to
violate the latest RFC draft for tipc:
http://tipc.sourceforge.net/doc/draft-spec-tipc-02.txt
Which, according to section 4.2 and 4.3.3, requires that all fields of all
commands be sent in network byte order. So instead of just taking this patch,
instead I'm removing the htohl function and replacing the calls with calls to
ntohl in the rx path and htonl in the send path.
As part of this fix, I'm also changing the subscr_cancel function, which
searches the list of subscribers, using a memcmp of the entire subscriber list,
for the entry to tear down. unfortunately it memcmps the entire tipc_subscr
structure which has several bits that are private to the local side, so nothing
will ever match. section 5.2 of the draft spec indicates the <type,upper,lower>
tuple should uniquely identify a subscriber, so convert subscr_cancel to just
match on those fields (properly endian swapped).
I've tested this using the tipc test suite, and its passed without issue.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Allan Stephens <allan.stephens@windriver.com>
subscr.c | 57 ++++++++++++++++++++++-----------------------------------
subscr.h | 2 --
2 files changed, 22 insertions(+), 37 deletions(-)
diff --git a/net/tipc/subscr.c b/net/tipc/subscr.c
index ac91f0d..ff123e5 100644
--- a/net/tipc/subscr.c
+++ b/net/tipc/subscr.c
@@ -76,19 +76,6 @@ struct top_srv {
static struct top_srv topsrv = { 0 };
/**
- * htohl - convert value to endianness used by destination
- * @in: value to convert
- * @swap: non-zero if endianness must be reversed
- *
- * Returns converted value
- */
-
-static u32 htohl(u32 in, int swap)
-{
- return swap ? swab32(in) : in;
-}
-
-/**
* subscr_send_event - send a message containing a tipc_event to the subscriber
*
* Note: Must not hold subscriber's server port lock, since tipc_send() will
@@ -107,11 +94,11 @@ static void subscr_send_event(struct subscription *sub,
msg_sect.iov_base = (void *)&sub->evt;
msg_sect.iov_len = sizeof(struct tipc_event);
- sub->evt.event = htohl(event, sub->swap);
- sub->evt.found_lower = htohl(found_lower, sub->swap);
- sub->evt.found_upper = htohl(found_upper, sub->swap);
- sub->evt.port.ref = htohl(port_ref, sub->swap);
- sub->evt.port.node = htohl(node, sub->swap);
+ sub->evt.event = htonl(event);
+ sub->evt.found_lower = htonl(found_lower);
+ sub->evt.found_upper = htonl(found_upper);
+ sub->evt.port.ref = htonl(port_ref);
+ sub->evt.port.node = htonl(node);
tipc_send(sub->server_ref, 1, &msg_sect);
}
@@ -287,16 +274,23 @@ static void subscr_cancel(struct tipc_subscr *s,
{
struct subscription *sub;
struct subscription *sub_temp;
+ __u32 type, lower, upper;
int found = 0;
/* Find first matching subscription, exit if not found */
+ type = ntohl(s->seq.type);
+ lower = ntohl(s->seq.lower);
+ upper = ntohl(s->seq.upper);
+
list_for_each_entry_safe(sub, sub_temp, &subscriber->subscription_list,
subscription_list) {
- if (!memcmp(s, &sub->evt.s, sizeof(struct tipc_subscr))) {
- found = 1;
- break;
- }
+ if ((type == sub->seq.type) &&
+ (lower == sub->seq.lower) &&
+ (upper == sub->seq.upper)) {
+ found = 1;
+ break;
+ }
}
if (!found)
return;
@@ -325,16 +319,10 @@ static struct subscription *subscr_subscribe(struct tipc_subscr *s,
struct subscriber *subscriber)
{
struct subscription *sub;
- int swap;
-
- /* Determine subscriber's endianness */
-
- swap = !(s->filter & (TIPC_SUB_PORTS | TIPC_SUB_SERVICE));
/* Detect & process a subscription cancellation request */
- if (s->filter & htohl(TIPC_SUB_CANCEL, swap)) {
- s->filter &= ~htohl(TIPC_SUB_CANCEL, swap);
+ if (ntohl(s->filter) & TIPC_SUB_CANCEL) {
subscr_cancel(s, subscriber);
return NULL;
}
@@ -359,11 +347,11 @@ static struct subscription *subscr_subscribe(struct tipc_subscr *s,
/* Initialize subscription object */
- sub->seq.type = htohl(s->seq.type, swap);
- sub->seq.lower = htohl(s->seq.lower, swap);
- sub->seq.upper = htohl(s->seq.upper, swap);
- sub->timeout = htohl(s->timeout, swap);
- sub->filter = htohl(s->filter, swap);
+ sub->seq.type = ntohl(s->seq.type);
+ sub->seq.lower = ntohl(s->seq.lower);
+ sub->seq.upper = ntohl(s->seq.upper);
+ sub->timeout = ntohl(s->timeout);
+ sub->filter = ntohl(s->filter);
if ((!(sub->filter & TIPC_SUB_PORTS) ==
!(sub->filter & TIPC_SUB_SERVICE)) ||
(sub->seq.lower > sub->seq.upper)) {
@@ -376,7 +364,6 @@ static struct subscription *subscr_subscribe(struct tipc_subscr *s,
INIT_LIST_HEAD(&sub->nameseq_list);
list_add(&sub->subscription_list, &subscriber->subscription_list);
sub->server_ref = subscriber->port_ref;
- sub->swap = swap;
memcpy(&sub->evt.s, s, sizeof(struct tipc_subscr));
atomic_inc(&topsrv.subscription_count);
if (sub->timeout != TIPC_WAIT_FOREVER) {
diff --git a/net/tipc/subscr.h b/net/tipc/subscr.h
index 45d89bf..c20f496 100644
--- a/net/tipc/subscr.h
+++ b/net/tipc/subscr.h
@@ -53,7 +53,6 @@ typedef void (*tipc_subscr_event) (struct subscription *sub,
* @nameseq_list: adjacent subscriptions in name sequence's subscription list
* @subscription_list: adjacent subscriptions in subscriber's subscription list
* @server_ref: object reference of server port associated with subscription
- * @swap: indicates if subscriber uses opposite endianness in its messages
* @evt: template for events generated by subscription
*/
@@ -66,7 +65,6 @@ struct subscription {
struct list_head nameseq_list;
struct list_head subscription_list;
u32 server_ref;
- int swap;
struct tipc_event evt;
};
^ permalink raw reply related
* Re: [net-next-2.6 PATCH] bonding: refuse to change bond type if it's used
From: David Miller @ 2010-03-08 20:16 UTC (permalink / raw)
To: shemminger; +Cc: jpirko, netdev, fubar, bonding-devel
In-Reply-To: <20100308102448.7acfe7c0@nehalam>
From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Mon, 8 Mar 2010 10:24:48 -0800
> On Mon, 8 Mar 2010 18:54:06 +0100
> Jiri Pirko <jpirko@redhat.com> wrote:
>
>> It's not desirable to be able to change the type of net_device in bond device if
>> it's in use by bridge, or vlan, or so. At the moment, there is possible for
>> example to have INFINIBAND bond type in bridge (by adding bond with eth type to
>> a bridge first and then enslave INFINIBAND device).
>
> Rather than building lots of back pointer dependencies, why not
> have another netdevice notifier that allows other subsystems to
> see the type change and reject it if they care? That way the code
> would be more modular and expandable.
Agreed.
^ permalink raw reply
* Re: [PATCH] ethtool: Use noinline_for_stack
From: David Miller @ 2010-03-08 20:17 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1268077563.2819.61.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 08 Mar 2010 20:46:03 +0100
> Use self documenting noinline_for_stack instead of duplicated comments.
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH]: tipc: Fix oops on send prior to entering networked mode (v2)
From: David Miller @ 2010-03-08 20:19 UTC (permalink / raw)
To: nhorman; +Cc: netdev, jon.maloy, allan.stephens, tipc-discussion
In-Reply-To: <20100302183312.GB22294@hmsreliant.think-freely.org>
Doesn't apply to net-2.6, Neil please respin.
^ permalink raw reply
* Re: [PATCH] tipc: filter out messages not intended for this host
From: David Miller @ 2010-03-08 20:20 UTC (permalink / raw)
To: nhorman; +Cc: netdev, allan.stephens
In-Reply-To: <20100308194149.GD23634@hmsreliant.think-freely.org>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Mon, 8 Mar 2010 14:41:49 -0500
> Port commit 20deb48d16fdd07ce2fdc8d03ea317362217e085
> from git://tipc.cslab.ericsson.net/pub/git/people/allan/tipc.git
>
> Part of the larger effort I'm trying to help with getting all the downstreamed
> code from windriver forward ported to the upstream tree
>
> Origional commit message
> Restore check to filter out inadverdently received messages
> This patch reimplements a check that allows TIPC to discard messages
> that are not intended for it. This check was present in TIPC 1.5/1.6,
> but was removed by accident during the development of TIPC 1.7; it has
> now been updated to account for new features present in TIPC 1.7 and
> reinserted into TIPC. The main benefit of this check is to filter
> out messages arriving from orphaned link endpoints, which can arise
> when a node exits the network and then re-enters it with a different
> TIPC network address (i.e. <Z.C.N> value).
>
> tested with the tipc sanity test suite.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> Origionally-authored-by: Allan Stephens <allan.stephens@windriver.com>
Adds trailing whitespace, please fix:
davem@sunset:~/src/GIT/net-2.6$ pcheck diff
+ git apply --check --whitespace=error-all diff
diff:11: trailing whitespace.
if (unlikely(!msg_isdata(msg) &&
fatal: 1 line adds whitespace errors.
^ permalink raw reply
* Re: [PATCH] tipc: fix endianness on tipc subscriber messages
From: David Miller @ 2010-03-08 20:21 UTC (permalink / raw)
To: nhorman; +Cc: netdev, allan.stephens
In-Reply-To: <20100308200315.GE23634@hmsreliant.think-freely.org>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Mon, 8 Mar 2010 15:03:15 -0500
> Remove htohl implementation from tipc
Applied, thanks Neil.
^ permalink raw reply
* Re: [PATCH] socket: Merge getsockname and getpeername into a single function
From: David Miller @ 2010-03-08 20:24 UTC (permalink / raw)
To: kenan; +Cc: netdev
In-Reply-To: <20100304032612.GB9016@home.unix.ba>
From: Kenan Kalajdzic <kenan@unix.ba>
Date: Thu, 4 Mar 2010 04:26:13 +0100
> The code of getsockname is almost identical to getpeername. This patch removes
> duplicate code and merges both functions into a single common function.
>
> Signed-off-by: Kenan Kalajdzic <kenan@unix.ba>
Since you still have to conditionalize things like the security
calls, this doesn't look any cleaner to me than what we have
there already.
I'm not applying this, sorry.
^ 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