* Re: xfrm_input() and ->seq oddities
From: Al Viro @ 2008-02-03 11:04 UTC (permalink / raw)
To: Herbert Xu; +Cc: David Miller, netdev
In-Reply-To: <20080203030516.GA5685@gondor.apana.org.au>
On Sun, Feb 03, 2008 at 02:05:16PM +1100, Herbert Xu wrote:
> On Sun, Feb 03, 2008 at 12:37:19AM +0000, Al Viro wrote:
> >
> > This is still very odd... Where do you initialize ->seq.input? What
>
> In xfrm_input.
>
> > guarantees that async call of xfrm_input() will be always preceded by
> > at least one non-async one?
>
> OK I admit it isn't pretty. But the encap_type argument is reused to
> indicate async resumption. That is, if we enter with encap_type < 0,
> it means that we're resuming a previous operation and seq.input has
> therefore been set by the previous xfrm_input call.
*Ouch*
So what you are saying is
* callers of xfrm_input_resume() are in callbacks that couldn't
have been set other than from esp_input()/esp6_input()
* these two could have only been called via ->type->input()
* ->type->input() is called from xfrm_input(), immediately after
having set ->seq.input, *or* from xfrm6_input_addr(). The former is safe.
* xfrm6_input_addr() calls ->type->input() of object it gets from
xfrm_state_lookup_byaddr(). The protocol number passed to the latter comes
from xfrm6_input_addr() argument.
* the protocol numbers given to xfrm6_input_addr() by its callers
are IPPROTO_DSTOPTS and IPPROTO_ROUTING resp; ->input() instances in their
xfrm_type do *not* set callbacks that could lead to xfrm_input_resume(),
so we are safe.
IMO that at least deserves a comment near xfrm_input()...
doe
^ permalink raw reply
* Re: [PATCHES 0/5]: Add hashinfo member to struct proto and get net/ structs back on a diet
From: David Miller @ 2008-02-03 12:09 UTC (permalink / raw)
To: acme; +Cc: netdev
In-Reply-To: <47a39bf3.1087460a.06ae.ffffd95f@mx.google.com>
From: acme@ghostprotocols.net
Date: Fri, 1 Feb 2008 20:23:31 -0200
> Hi David,
>
> Please consider pulling from:
>
> master.kernel.org:/pub/scm/linux/kernel/git/acme/net-2.6.25
>
> There are many more structs that have holes, they seem to crop up, even
> on DCCP! People should use some paholing 8-)
>
> I'll prepare another round after carnival, and also will look at using
> sparse and/or Uli's libdisasm and/or DeHydra to find struct member accesses in
> functions to correlate that with struct layout when doing automatic struct
> member reorgs, so as not to step into Eric's fast path 8-P
I've pulled these all in as patches, thanks for following
up on this work!
^ permalink raw reply
* Re: [git patches] net driver updates #2
From: David Miller @ 2008-02-03 12:21 UTC (permalink / raw)
To: jeff; +Cc: netdev, linux-kernel
In-Reply-To: <20080201.215210.247648606.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Fri, 01 Feb 2008 21:52:10 -0800 (PST)
> From: Jeff Garzik <jeff@garzik.org>
> Date: Fri, 1 Feb 2008 16:03:38 -0500
>
> > Please pull from 'upstream2-davem' branch of
>
> This is now pulled and pushed back out to net-2.6
The first S2io patch breaks the build so I'm removing it from the
net-2.6 tree. I suspect you rejected an earlier patch that added the
tx_lock member to the S2IO device private.
If you do that Jeff, please at least do a quick sanity check of the
build.
If, instead, I messed things up somehow, my apologies in advance.
drivers/net/s2io.c: In function 's2io_vlan_rx_kill_vid':
drivers/net/s2io.c:395: error: 'struct s2io_nic' has no member named 'tx_lock'
drivers/net/s2io.c:399: error: 'struct s2io_nic' has no member named 'tx_lock'
S2io: Support for vlan_rx_kill_vid entry point
- Added s2io_vlan_rx_kill_vid entry point function for unregistering vlan.
- Fix to aggregate vlan packets. IP offset is incremented by
4 bytes if the packet contains vlan header.
Signed-off-by: Surjit Reang <surjit.reang@neterion.com>
Signed-off-by: Ramkrishna Vepa <ram.vepa@neterion.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
---
drivers/net/s2io.c | 108 +++++++++++++++++++++++++++++-----------------------
drivers/net/s2io.h | 7 ++-
2 files changed, 65 insertions(+), 50 deletions(-)
diff --git a/drivers/net/s2io.c b/drivers/net/s2io.c
index 5fab7d7..dcad502 100644
--- a/drivers/net/s2io.c
+++ b/drivers/net/s2io.c
@@ -386,6 +386,19 @@ static void s2io_vlan_rx_register(struct net_device *dev,
/* A flag indicating whether 'RX_PA_CFG_STRIP_VLAN_TAG' bit is set or not */
static int vlan_strip_flag;
+/* Unregister the vlan */
+static void s2io_vlan_rx_kill_vid(struct net_device *dev, unsigned long vid)
+{
+ unsigned long flags;
+ struct s2io_nic *nic = dev->priv;
+
+ spin_lock_irqsave(&nic->tx_lock, flags);
+ if (nic->vlgrp)
+ vlan_group_set_device(nic->vlgrp, vid, NULL);
+
+ spin_unlock_irqrestore(&nic->tx_lock, flags);
+}
+
/*
* Constants to be programmed into the Xena's registers, to configure
* the XAUI.
@@ -2948,7 +2961,7 @@ static void rx_intr_handler(struct ring_info *ring_data)
struct lro *lro = &nic->lro0_n[i];
if (lro->in_use) {
update_L3L4_header(nic, lro);
- queue_rx_frame(lro->parent);
+ queue_rx_frame(lro->parent, lro->vlan_tag);
clear_lro_session(lro);
}
}
@@ -7371,7 +7384,8 @@ static int rx_osm_handler(struct ring_info *ring_data, struct RxD_t * rxdp)
{
lro_append_pkt(sp, lro,
skb, tcp_len);
- queue_rx_frame(lro->parent);
+ queue_rx_frame(lro->parent,
+ lro->vlan_tag);
clear_lro_session(lro);
sp->mac_control.stats_info->
sw_stat.flush_max_pkts++;
@@ -7382,7 +7396,8 @@ static int rx_osm_handler(struct ring_info *ring_data, struct RxD_t * rxdp)
lro->frags_len;
sp->mac_control.stats_info->
sw_stat.sending_both++;
- queue_rx_frame(lro->parent);
+ queue_rx_frame(lro->parent,
+ lro->vlan_tag);
clear_lro_session(lro);
goto send_up;
case 0: /* sessions exceeded */
@@ -7408,31 +7423,12 @@ static int rx_osm_handler(struct ring_info *ring_data, struct RxD_t * rxdp)
*/
skb->ip_summed = CHECKSUM_NONE;
}
- } else {
+ } else
skb->ip_summed = CHECKSUM_NONE;
- }
+
sp->mac_control.stats_info->sw_stat.mem_freed += skb->truesize;
- if (!sp->lro) {
- skb->protocol = eth_type_trans(skb, dev);
- if ((sp->vlgrp && RXD_GET_VLAN_TAG(rxdp->Control_2) &&
- vlan_strip_flag)) {
- /* Queueing the vlan frame to the upper layer */
- if (napi)
- vlan_hwaccel_receive_skb(skb, sp->vlgrp,
- RXD_GET_VLAN_TAG(rxdp->Control_2));
- else
- vlan_hwaccel_rx(skb, sp->vlgrp,
- RXD_GET_VLAN_TAG(rxdp->Control_2));
- } else {
- if (napi)
- netif_receive_skb(skb);
- else
- netif_rx(skb);
- }
- } else {
send_up:
- queue_rx_frame(skb);
- }
+ queue_rx_frame(skb, RXD_GET_VLAN_TAG(rxdp->Control_2));
dev->last_rx = jiffies;
aggregate:
atomic_dec(&sp->rx_bufs_left[ring_no]);
@@ -7790,6 +7786,7 @@ s2io_init_nic(struct pci_dev *pdev, const struct pci_device_id *pre)
SET_ETHTOOL_OPS(dev, &netdev_ethtool_ops);
dev->features |= NETIF_F_HW_VLAN_TX | NETIF_F_HW_VLAN_RX;
dev->vlan_rx_register = s2io_vlan_rx_register;
+ dev->vlan_rx_kill_vid = (void *)s2io_vlan_rx_kill_vid;
/*
* will use eth_mac_addr() for dev->set_mac_address
@@ -8061,7 +8058,8 @@ module_init(s2io_starter);
module_exit(s2io_closer);
static int check_L2_lro_capable(u8 *buffer, struct iphdr **ip,
- struct tcphdr **tcp, struct RxD_t *rxdp)
+ struct tcphdr **tcp, struct RxD_t *rxdp,
+ struct s2io_nic *sp)
{
int ip_off;
u8 l2_type = (u8)((rxdp->Control_1 >> 37) & 0x7), ip_len;
@@ -8072,19 +8070,20 @@ static int check_L2_lro_capable(u8 *buffer, struct iphdr **ip,
return -1;
}
- /* TODO:
- * By default the VLAN field in the MAC is stripped by the card, if this
- * feature is turned off in rx_pa_cfg register, then the ip_off field
- * has to be shifted by a further 2 bytes
- */
- switch (l2_type) {
- case 0: /* DIX type */
- case 4: /* DIX type with VLAN */
- ip_off = HEADER_ETHERNET_II_802_3_SIZE;
- break;
+ /* Checking for DIX type or DIX type with VLAN */
+ if ((l2_type == 0)
+ || (l2_type == 4)) {
+ ip_off = HEADER_ETHERNET_II_802_3_SIZE;
+ /*
+ * If vlan stripping is disabled and the frame is VLAN tagged,
+ * shift the offset by the VLAN header size bytes.
+ */
+ if ((!vlan_strip_flag) &&
+ (rxdp->Control_1 & RXD_FRAME_VLAN_TAG))
+ ip_off += HEADER_VLAN_SIZE;
+ } else {
/* LLC, SNAP etc are considered non-mergeable */
- default:
- return -1;
+ return -1;
}
*ip = (struct iphdr *)((u8 *)buffer + ip_off);
@@ -8111,7 +8110,7 @@ static inline int get_l4_pyld_length(struct iphdr *ip, struct tcphdr *tcp)
}
static void initiate_new_session(struct lro *lro, u8 *l2h,
- struct iphdr *ip, struct tcphdr *tcp, u32 tcp_pyld_len)
+ struct iphdr *ip, struct tcphdr *tcp, u32 tcp_pyld_len, u16 vlan_tag)
{
DBG_PRINT(INFO_DBG,"%s: Been here...\n", __FUNCTION__);
lro->l2h = l2h;
@@ -8122,6 +8121,7 @@ static void initiate_new_session(struct lro *lro, u8 *l2h,
lro->sg_num = 1;
lro->total_len = ntohs(ip->tot_len);
lro->frags_len = 0;
+ lro->vlan_tag = vlan_tag;
/*
* check if we saw TCP timestamp. Other consistency checks have
* already been done.
@@ -8253,15 +8253,16 @@ s2io_club_tcp_session(u8 *buffer, u8 **tcp, u32 *tcp_len, struct lro **lro,
struct iphdr *ip;
struct tcphdr *tcph;
int ret = 0, i;
+ u16 vlan_tag = 0;
if (!(ret = check_L2_lro_capable(buffer, &ip, (struct tcphdr **)tcp,
- rxdp))) {
+ rxdp, sp))) {
DBG_PRINT(INFO_DBG,"IP Saddr: %x Daddr: %x\n",
ip->saddr, ip->daddr);
- } else {
+ } else
return ret;
- }
+ vlan_tag = RXD_GET_VLAN_TAG(rxdp->Control_2);
tcph = (struct tcphdr *)*tcp;
*tcp_len = get_l4_pyld_length(ip, tcph);
for (i=0; i<MAX_LRO_SESSIONS; i++) {
@@ -8321,7 +8322,8 @@ s2io_club_tcp_session(u8 *buffer, u8 **tcp, u32 *tcp_len, struct lro **lro,
switch (ret) {
case 3:
- initiate_new_session(*lro, buffer, ip, tcph, *tcp_len);
+ initiate_new_session(*lro, buffer, ip, tcph, *tcp_len,
+ vlan_tag);
break;
case 2:
update_L3L4_header(sp, *lro);
@@ -8349,15 +8351,25 @@ static void clear_lro_session(struct lro *lro)
memset(lro, 0, lro_struct_size);
}
-static void queue_rx_frame(struct sk_buff *skb)
+static void queue_rx_frame(struct sk_buff *skb, u16 vlan_tag)
{
struct net_device *dev = skb->dev;
+ struct s2io_nic *sp = dev->priv;
skb->protocol = eth_type_trans(skb, dev);
- if (napi)
- netif_receive_skb(skb);
- else
- netif_rx(skb);
+ if (sp->vlgrp && vlan_tag
+ && (vlan_strip_flag)) {
+ /* Queueing the vlan frame to the upper layer */
+ if (sp->config.napi)
+ vlan_hwaccel_receive_skb(skb, sp->vlgrp, vlan_tag);
+ else
+ vlan_hwaccel_rx(skb, sp->vlgrp, vlan_tag);
+ } else {
+ if (sp->config.napi)
+ netif_receive_skb(skb);
+ else
+ netif_rx(skb);
+ }
}
static void lro_append_pkt(struct s2io_nic *sp, struct lro *lro,
diff --git a/drivers/net/s2io.h b/drivers/net/s2io.h
index 9f6016c..2cbbb83 100644
--- a/drivers/net/s2io.h
+++ b/drivers/net/s2io.h
@@ -534,6 +534,7 @@ struct RxD_t {
#define RXD_OWN_XENA s2BIT(7)
#define RXD_T_CODE (s2BIT(12)|s2BIT(13)|s2BIT(14)|s2BIT(15))
#define RXD_FRAME_PROTO vBIT(0xFFFF,24,8)
+#define RXD_FRAME_VLAN_TAG s2BIT(24)
#define RXD_FRAME_PROTO_IPV4 s2BIT(27)
#define RXD_FRAME_PROTO_IPV6 s2BIT(28)
#define RXD_FRAME_IP_FRAG s2BIT(29)
@@ -808,10 +809,12 @@ struct lro {
int sg_num;
int in_use;
__be16 window;
+ u16 vlan_tag;
u32 cur_tsval;
u32 cur_tsecr;
u8 saw_ts;
-};
+} ____cacheline_aligned;
+
/* These flags represent the devices temporary state */
enum s2io_device_state_t
@@ -1087,7 +1090,7 @@ static int
s2io_club_tcp_session(u8 *buffer, u8 **tcp, u32 *tcp_len, struct lro **lro,
struct RxD_t *rxdp, struct s2io_nic *sp);
static void clear_lro_session(struct lro *lro);
-static void queue_rx_frame(struct sk_buff *skb);
+static void queue_rx_frame(struct sk_buff *skb, u16 vlan_tag);
static void update_L3L4_header(struct s2io_nic *sp, struct lro *lro);
static void lro_append_pkt(struct s2io_nic *sp, struct lro *lro,
struct sk_buff *skb, u32 tcp_len);
--
1.5.4.rc5
^ permalink raw reply related
* Fwd: [PATCH] [NET_SCHED] Add #ifdef CONFIG_NET_EMATCH in net/sched/cls_flow.c (latest git broken build)
From: Rami Rosen @ 2008-02-03 12:37 UTC (permalink / raw)
To: netdev
In-Reply-To: <eb3ff54b0802030051x604c991fwe11184e25d0a7550@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1253 bytes --]
---------- Forwarded message ----------
From: Rami Rosen <ramirose@gmail.com>
Date: Feb 3, 2008 10:51 AM
Subject: [PATCH] [NET_SCHED] Add #ifdef CONFIG_NET_EMATCH in
net/sched/cls_flow.c (latest git broken build)
To: David Miller <davem@davemloft.net>, kaber@trash.net,
lizf@cn.fujitsu.com, linux-kernel@vger.kernel.org
Hi,
The 2.6 latest git build was broken when using the following
configuration options:
CONFIG_NET_EMATCH=n
CONFIG_NET_CLS_FLOW=y
with the following error:
net/sched/cls_flow.c: In function 'flow_dump':
net/sched/cls_flow.c:598: error: 'struct tcf_ematch_tree' has no
member named 'hdr'
make[2]: *** [net/sched/cls_flow.o] Error 1
make[1]: *** [net/sched] Error 2
make: *** [net] Error 2
see the recent post by Li Zefan:
http://www.spinics.net/lists/netdev/msg54434.html
The reason for this crash is that struct tcf_ematch_tree (net/pkt_cls.h) is
empty when CONFIG_NET_EMATCH is not defined.
When CONFIG_NET_EMATCH is defined, the tcf_ematch_tree structure indeed holds
a struct tcf_ematch_tree_hdr (hdr) as flow_dump() expects.
This patch adds #ifdef CONFIG_NET_EMATCH in flow_dump to avoid this.
The patch was build against latest 2.6 git net tree.
Regards,
Rami Rosen
Signed-off-by: Rami Rosen <ramirose@gmail.com>
[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 559 bytes --]
diff --git a/net/sched/cls_flow.c b/net/sched/cls_flow.c
index 5a7f6a3..8d76986 100644
--- a/net/sched/cls_flow.c
+++ b/net/sched/cls_flow.c
@@ -594,11 +594,11 @@ static int flow_dump(struct tcf_proto *tp, unsigned long fh,
if (tcf_exts_dump(skb, &f->exts, &flow_ext_map) < 0)
goto nla_put_failure;
-
+#ifdef CONFIG_NET_EMATCH
if (f->ematches.hdr.nmatches &&
tcf_em_tree_dump(skb, &f->ematches, TCA_FLOW_EMATCHES) < 0)
goto nla_put_failure;
-
+#endif
nla_nest_end(skb, nest);
if (tcf_exts_dump_stats(skb, &f->exts, &flow_ext_map) < 0)
^ permalink raw reply related
* No pmtu probing on retransmits?
From: Andi Kleen @ 2008-02-03 12:37 UTC (permalink / raw)
To: jheffner, netdev
Hallo,
While looking for something else in tcp_output.c I noticed that
MTU probing seems to be only done in tcp_write_xmit (when
packets come directly from process context), but not via the timer
driven timer retransmit path (tcp_retransmit_skb). Is that intentional?
It looks quite weird. I would normally assume PMTU blackholes get usually
detected on retransmit timeouts. Or do I miss something?
You seem to have assumed interrupt context at least
because tcp_mtu_probe() uses GFP_ATOMIC which is only needed for
interrupts. Currently it is only called in process context I think.
-Andi
^ permalink raw reply
* Re: pull request: wireless-2.6 'fixes' 2008-02-01
From: David Miller @ 2008-02-03 12:44 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20080201224100.GD3050-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Fri, 1 Feb 2008 17:41:00 -0500
> Dave,
>
> Here are some more fixes suitable for 2.6.25. Also there is a patch
> that includes the mac80211 alignment warning as a configurable option,
> which should stop it from annoying normal users.
>
> Let me know if there are problems!
Pulled and pushed back out, thanks John.
^ permalink raw reply
* driver fixes merged...
From: David Miller @ 2008-02-03 12:51 UTC (permalink / raw)
To: netdev
I merged in everything Jeff and John sent to me except the S2IO vlan
fix that broke the build.
I also sent in Arnaldo's 6 patch set.
I fly home from AU tomorrow and therefore I'll be offline for about a
day.
^ permalink raw reply
* Re: No pmtu probing on retransmits?
From: John Heffner @ 2008-02-03 14:04 UTC (permalink / raw)
To: Andi Kleen; +Cc: netdev
In-Reply-To: <20080203123719.GA3323@basil.nowhere.org>
Andi Kleen wrote:
> Hallo,
>
> While looking for something else in tcp_output.c I noticed that
> MTU probing seems to be only done in tcp_write_xmit (when
> packets come directly from process context), but not via the timer
> driven timer retransmit path (tcp_retransmit_skb). Is that intentional?
> It looks quite weird. I would normally assume PMTU blackholes get usually
> detected on retransmit timeouts. Or do I miss something?
MTU probing occurs only when everything is going fine. We are probing
a larger size than currently in use. In the case of a timeout, we
want to retransmit with the safe smaller size.
> You seem to have assumed interrupt context at least
> because tcp_mtu_probe() uses GFP_ATOMIC which is only needed for
> interrupts. Currently it is only called in process context I think.
I'm pretty sure it'll get called on ACK processing in softirq, f.e.:
tcp_mtu_probe()
tcp_write_xmit()
__tcp_push_pending_frames()
tcp_data_snd_check()
tcp_rcv_established()
Am I missing something?
-John
^ permalink raw reply
* Re: [2.6 patch] net/phy/fixed.c: fix a use-after-free
From: Anton Vorontsov @ 2008-02-03 14:21 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Vitaly Bordug, Jeff Garzik, netdev
In-Reply-To: <20080202211502.GC9375@cs181133002.pp.htv.fi>
On Sat, Feb 02, 2008 at 11:15:02PM +0200, Adrian Bunk wrote:
> This patch fixes a use-after-free introduced by
> commit a79d8e93d300adb84cccc38ac396cfb118c238ad and spotted by the
> Coverity checker.
Nice catch.
We didn't encounter this bug because fixed.c is bool, so
module_exit isn't used. Thus, technically, we can remove it
completely.
But I prefer your patch, because later, we might want to create
library versions of the fixed_mdio_bus_{init,exit}. To use, for
example, with PCI ethernet card that might have MDIO-less PHY,
i.e. configuration is hardwired in the eeprom, but driver still
want to use phylib framework.
Thanks,
> Signed-off-by: Adrian Bunk <bunk@kernel.org>
>
> ---
> 20c51455b2faed63c3026fd4d7139e5a6a917d31
> diff --git a/drivers/net/phy/fixed.c b/drivers/net/phy/fixed.c
> index 73b6d39..ca9b040 100644
> --- a/drivers/net/phy/fixed.c
> +++ b/drivers/net/phy/fixed.c
> @@ -236,12 +236,12 @@ module_init(fixed_mdio_bus_init);
> static void __exit fixed_mdio_bus_exit(void)
> {
> struct fixed_mdio_bus *fmb = &platform_fmb;
> - struct fixed_phy *fp;
> + struct fixed_phy *fp, *tmp;
>
> mdiobus_unregister(&fmb->mii_bus);
> platform_device_unregister(pdev);
>
> - list_for_each_entry(fp, &fmb->phys, node) {
> + list_for_each_entry_safe(fp, tmp, &fmb->phys, node) {
> list_del(&fp->node);
> kfree(fp);
> }
>
>
--
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2
^ permalink raw reply
* [PATCH][NET_SCHED] sch_tree_lock in cbq_put, hfsc_put_class and htb_put
From: Jarek Poplawski @ 2008-02-03 14:52 UTC (permalink / raw)
To: David Miller; +Cc: Stephen Hemminger, jamal, Patrick McHardy, netdev
[NET_SCHED] sch_tree_lock in cbq_put, hfsc_put_class and htb_put
Qdisc_class_ops ->put() "methods" call xxx_destroy_class() functions
without sch_tree_lock(), which is needed at least for qdisc_destroy()
of a subqueue, but also for deactivating and list/rb_tree updates in
case of HTB. (Since errors caused by such a bug could be very hard to
reproduce the effectiveness of this patch wasn't confirmed by tests,
but IMHO the need of this lock is quite obvious here.)
Signed-off-by: Jarek Poplawski <jarkao2@gmail.com>
---
net/sched/sch_cbq.c | 14 ++++++++------
net/sched/sch_hfsc.c | 5 ++++-
net/sched/sch_htb.c | 5 ++++-
3 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/net/sched/sch_cbq.c b/net/sched/sch_cbq.c
index 09969c1..bbf47fe 100644
--- a/net/sched/sch_cbq.c
+++ b/net/sched/sch_cbq.c
@@ -1748,16 +1748,18 @@ static void cbq_put(struct Qdisc *sch, unsigned long arg)
struct cbq_class *cl = (struct cbq_class*)arg;
if (--cl->refcnt == 0) {
+ sch_tree_lock(sch);
#ifdef CONFIG_NET_CLS_ACT
- struct cbq_sched_data *q = qdisc_priv(sch);
+ {
+ struct cbq_sched_data *q = qdisc_priv(sch);
- spin_lock_bh(&sch->dev->queue_lock);
- if (q->rx_class == cl)
- q->rx_class = NULL;
- spin_unlock_bh(&sch->dev->queue_lock);
+ if (q->rx_class == cl)
+ q->rx_class = NULL;
+ }
#endif
cbq_destroy_class(sch, cl);
+ sch_tree_unlock(sch);
}
}
@@ -1965,10 +1967,10 @@ static int cbq_delete(struct Qdisc *sch, unsigned long arg)
cbq_sync_defmap(cl);
cbq_rmprio(q, cl);
- sch_tree_unlock(sch);
if (--cl->refcnt == 0)
cbq_destroy_class(sch, cl);
+ sch_tree_unlock(sch);
return 0;
}
diff --git a/net/sched/sch_hfsc.c b/net/sched/sch_hfsc.c
index 87293d0..494d042 100644
--- a/net/sched/sch_hfsc.c
+++ b/net/sched/sch_hfsc.c
@@ -1262,8 +1262,11 @@ hfsc_put_class(struct Qdisc *sch, unsigned long arg)
{
struct hfsc_class *cl = (struct hfsc_class *)arg;
- if (--cl->refcnt == 0)
+ if (--cl->refcnt == 0) {
+ sch_tree_lock(sch);
hfsc_destroy_class(sch, cl);
+ sch_tree_unlock(sch);
+ }
}
static unsigned long
diff --git a/net/sched/sch_htb.c b/net/sched/sch_htb.c
index e1a579e..268a2d1 100644
--- a/net/sched/sch_htb.c
+++ b/net/sched/sch_htb.c
@@ -1305,8 +1305,11 @@ static void htb_put(struct Qdisc *sch, unsigned long arg)
{
struct htb_class *cl = (struct htb_class *)arg;
- if (--cl->refcnt == 0)
+ if (--cl->refcnt == 0) {
+ sch_tree_lock(sch);
htb_destroy_class(sch, cl);
+ sch_tree_unlock(sch);
+ }
}
static int htb_change_class(struct Qdisc *sch, u32 classid,
^ permalink raw reply related
* Re: [PATCH] Unbreak sky2 on 88E8039 with current git
From: Stephen Hemminger @ 2008-02-03 18:08 UTC (permalink / raw)
To: Petr Vandrovec; +Cc: netdev, linux-kernel
In-Reply-To: <47A51168.5040301@vandrovec.name>
On Sat, 02 Feb 2008 16:57:12 -0800
Petr Vandrovec <petr@vandrovec.name> wrote:
> Stephen Hemminger wrote:
> > On Sat, 2 Feb 2008 11:52:43 +0100
> > Petr Vandrovec <petr@vandrovec.name> wrote:
> >
> >> Hello,
> >> since I synced my tree to Linus's one two days ago, sky2's packet receiption
> >> dies almost instantly. Device still transmits packets, but no receive.
> >> Fortunately fix is simple, unfortunately I do not know why fix works...
> >>
> >> Commit f03b865491c2f30f2a4d77cdafc69c978ceb38a0 (sky2: align IP header on Rx
> >> if possible) stopped aligning receive buffers on devices which do not need
> >> HANG_CHECK. Unfortunately there is at least one device (mine, Yukon FE, rev 3)
> >> which is not happy if receive buffer is not aligned. I have no idea which
> >> other chips/revisions are affected as well.
> >>
> >> Without patch 'ping -f -b 192.168.101.255' RX count stops incrementing in less
> >> than 50 packets. With patch in place it can run like before, for hours...
> >> Box is an AMD rev F processor, with nVidia's MCP61 chipset.
> >> Petr
> >
> > I don't have a Yukon FE, but I believe that the Yukon FE does have a ram
> > buffer, so you HANG_CHECK should be enabled for that device. You can check
> > by running:
> > ethtool -d eth0 | grep 'Ram Buffer'
> > With ram buffer (like XL, EC)
> >
> > # ethtool -d eth0 | grep 'Ram Buffer'
> > Ram Buffer 0x18
> >
> > No ram buffer (like EC-U, FE+, ...)
> > # ethtool -d eth0 | grep 'Ram Buffer'
> > Ram Buffer 0x00
>
> Some small one (if it is size):
>
> gwy:~# ethtool -d eth0 | grep 'Ram'
> Ram Buffer 0x01
>
> I've never observed hang on that device, and I have it for over year. I
> stress it sufficiently to kill EC rev 2 I have in the notebook when I
> copy some data between these two boxes, but this FE never hung.
> Petr
>
Since the ram buffer is only 4K on this chip, 2K is used for rx.
You probably could make it hang by making CPU busy and hitting it
with 2 packets whose total length is was 1K each.
--
Stephen Hemminger <stephen.hemminger@vyatta.com>
^ permalink raw reply
* [PATCH] [NET] phy/broadcom: add support for BCM5481 PHY
From: Anton Vorontsov @ 2008-02-03 18:58 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Maciej W. Rozycki, Andy Fleming, netdev
This patch adds support for BCM5481 PHY. Unfortunately it's hard to
get specifications for this PHY, so its special register 0x18 isn't
annotated properly (but we know it's used to set up the delays).
I've kept the magic numbers, so we'll not forget to fix it at the
first opportunity, and will name that register and its bits correctly.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/net/phy/broadcom.c | 54 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index 29666c8..d15280e 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -99,6 +99,41 @@ static int bcm54xx_config_intr(struct phy_device *phydev)
return err;
}
+static int bcm5481_config_aneg(struct phy_device *phydev)
+{
+ int ret;
+
+ /* Aneg firsly. */
+ ret = genphy_config_aneg(phydev);
+
+ /* Then we can set up the delay. */
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID) {
+ u16 reg;
+
+ /*
+ * There is no BCM5481 specification available, so down
+ * here is everything we know about "register 0x18". This
+ * at least helps BCM5481 to successfuly receive packets
+ * on MPC8360E-RDK board. Peter Barada <peterb@logicpd.com>
+ * says: "This sets delay between the RXD and RXC signals
+ * instead of using trace lengths to achieve timing".
+ */
+
+ /* Set RDX clk delay. */
+ reg = 0x7 | (0x7 << 12);
+ phy_write(phydev, 0x18, reg);
+
+ reg = phy_read(phydev, 0x18);
+ /* Set RDX-RXC skew. */
+ reg |= (1 << 8);
+ /* Write bits 14:0. */
+ reg |= (1 << 15);
+ phy_write(phydev, 0x18, reg);
+ }
+
+ return ret;
+}
+
static struct phy_driver bcm5411_driver = {
.phy_id = 0x00206070,
.phy_id_mask = 0xfffffff0,
@@ -141,6 +176,20 @@ static struct phy_driver bcm5461_driver = {
.driver = { .owner = THIS_MODULE },
};
+static struct phy_driver bcm5481_driver = {
+ .phy_id = 0x0143bca0,
+ .phy_id_mask = 0xfffffff0,
+ .name = "Broadcom BCM5481",
+ .features = PHY_GBIT_FEATURES,
+ .flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
+ .config_init = bcm54xx_config_init,
+ .config_aneg = bcm5481_config_aneg,
+ .read_status = genphy_read_status,
+ .ack_interrupt = bcm54xx_ack_interrupt,
+ .config_intr = bcm54xx_config_intr,
+ .driver = { .owner = THIS_MODULE },
+};
+
static int __init broadcom_init(void)
{
int ret;
@@ -154,8 +203,13 @@ static int __init broadcom_init(void)
ret = phy_driver_register(&bcm5461_driver);
if (ret)
goto out_5461;
+ ret = phy_driver_register(&bcm5481_driver);
+ if (ret)
+ goto out_5481;
return ret;
+out_5481:
+ phy_driver_unregister(&bcm5461_driver);
out_5461:
phy_driver_unregister(&bcm5421_driver);
out_5421:
--
1.5.2.2
^ permalink raw reply related
* Re: FW: r8169 auto-negotiation problem
From: Francois Romieu @ 2008-02-03 18:45 UTC (permalink / raw)
To: fgnijuhhu guduggurehug; +Cc: netdev
In-Reply-To: <BAY107-W4033FF1A4417D61C5177FD5310@phx.gbl>
fgnijuhhu guduggurehug <jsmiths1234@live.com> :
[...]
> I already posted my problem and what I did to solve it on
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=461429.
Have you tried anything more recent than a 2.6.18 based kernel ?
--
Ueimor
^ permalink raw reply
* FW: [Patch 2.6.24 1/3]S2io: Support for vlan_rx_kill_vid entry point
From: Ramkrishna Vepa @ 2008-02-03 21:03 UTC (permalink / raw)
To: David Miller; +Cc: Jeff Garzik, Sreenivasa Honnur, netdev
The patches failed because they were applied on the 2.6.25 branch, while
they were meant for the 2.6.24 branch (upstream-linus).
Ram
> -----Original Message-----
> From: Ramkrishna Vepa
> Sent: Friday, February 01, 2008 11:01 AM
> To: 'Jeff Garzik'; Sreenivasa Honnur
> Cc: support
> Subject: RE: [Patch 2.6.24 1/3]S2io: Support for vlan_rx_kill_vid
entry
> point
>
> > Sreenivasa Honnur wrote:
> > > - Added s2io_vlan_rx_kill_vid entry point function for
unregistering
> > vlan.
> > > - Fix to aggregate vlan packets. IP offset is incremented by
> > > 4 bytes if the packet contains vlan header.
> > >
> > > Signed-off-by: Surjit Reang <surjit.reang@neterion.com>
> > > Signed-off-by: Ramkrishna Vepa <ram.vepa@neterion.com>
> >
> > applied 1-2, patch #3 failed to apply
> [Ram] This sequence of patches were meant for 2.6.24 (upstream-linus)
and
> patch #3 was only a version update -
> -#define DRV_VERSION "2.0.26.17"
> +#define DRV_VERSION "2.0.26.18"
> I just checked upstream-linus and the version is still 2.0.26.17. Any
idea
> why the patch failed?
>
> Thanks,
> Ram
^ permalink raw reply
* Re: xfrm_input() and ->seq oddities
From: Herbert Xu @ 2008-02-03 22:00 UTC (permalink / raw)
To: Al Viro; +Cc: David Miller, netdev
In-Reply-To: <20080203110444.GR27894@ZenIV.linux.org.uk>
On Sun, Feb 03, 2008 at 11:04:44AM +0000, Al Viro wrote:
>
> So what you are saying is
> * callers of xfrm_input_resume() are in callbacks that couldn't
> have been set other than from esp_input()/esp6_input()
> * these two could have only been called via ->type->input()
> * ->type->input() is called from xfrm_input(), immediately after
> having set ->seq.input, *or* from xfrm6_input_addr(). The former is safe.
> * xfrm6_input_addr() calls ->type->input() of object it gets from
> xfrm_state_lookup_byaddr(). The protocol number passed to the latter comes
> from xfrm6_input_addr() argument.
> * the protocol numbers given to xfrm6_input_addr() by its callers
> are IPPROTO_DSTOPTS and IPPROTO_ROUTING resp; ->input() instances in their
> xfrm_type do *not* set callbacks that could lead to xfrm_input_resume(),
> so we are safe.
This doesn't look so bad if you take out the xfrm6_input_addr call.
And you can't blame that one on me :)
The xfrm6_input_addr function is really a parallel universe which has
nothing to do with IPsec. It's used by Mobile IPv6 just because it
happened to fit in the same schema.
In other words, IPsec transforms such as ESP cannot be called from
xfrm6_input_addr and as such async resumption never occurs with
xfrm6_input_addr.
> IMO that at least deserves a comment near xfrm_input()...
Sure. There is already a comment about encap_type < 0 in there, but
I think you'll probably be able to explain it much better than I can
looking in from the outside so if you have a patch... :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH 7/8] kernel-doc: fix network header warnings
From: Randy.Dunlap @ 2008-02-03 23:06 UTC (permalink / raw)
To: netdev; +Cc: davem, akpm
From: Randy Dunlap <randy.dunlap@oracle.com>
Add missing structure kernel-doc descriptions to sock.h & skbuff.h
to fix kernel-doc warnings.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
include/linux/skbuff.h | 2 ++
include/net/sock.h | 1 +
2 files changed, 3 insertions(+)
--- linux-2.6.24-git12.orig/include/linux/skbuff.h
+++ linux-2.6.24-git12/include/linux/skbuff.h
@@ -232,6 +232,8 @@ typedef unsigned char *sk_buff_data_t;
* @mark: Generic packet mark
* @nfct: Associated connection, if any
* @ipvs_property: skbuff is owned by ipvs
+ * @peeked: this packet has been seen already, so stats have been
+ * done for it, don't do them again
* @nf_trace: netfilter packet trace flag
* @nfctinfo: Relationship of this skb to the connection
* @nfct_reasm: netfilter conntrack re-assembly pointer
--- linux-2.6.24-git12.orig/include/net/sock.h
+++ linux-2.6.24-git12/include/net/sock.h
@@ -180,6 +180,7 @@ struct sock_common {
* @sk_sndmsg_off: cached offset for sendmsg
* @sk_send_head: front of stuff to transmit
* @sk_security: used by security modules
+ * @sk_mark: generic packet mark
* @sk_write_pending: a write to stream socket waits to start
* @sk_state_change: callback to indicate change in the state of the sock
* @sk_data_ready: callback to indicate there is data to be processed
^ permalink raw reply
* [PATCH 8/8] kernel-doc: fix sunrpc warnings
From: Randy.Dunlap @ 2008-02-03 23:07 UTC (permalink / raw)
To: netdev; +Cc: davem, akpm
From: Randy Dunlap <randy.dunlap@oracle.com>
Use updated file list for docbook files and
fix kernel-doc warnings in sunrpc:
Warning(linux-2.6.24-git12//net/sunrpc/rpc_pipe.c:689): No description found for parameter 'rpc_client'
Warning(linux-2.6.24-git12//net/sunrpc/rpc_pipe.c:765): No description found for parameter 'flags'
Warning(linux-2.6.24-git12//net/sunrpc/clnt.c:584): No description found for parameter 'tk_ops'
Warning(linux-2.6.24-git12//net/sunrpc/clnt.c:618): No description found for parameter 'bufsize'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
Documentation/DocBook/kernel-api.tmpl | 8 +++++++-
net/sunrpc/clnt.c | 10 +++++-----
net/sunrpc/rpc_pipe.c | 3 ++-
net/sunrpc/xprt.c | 2 +-
4 files changed, 15 insertions(+), 8 deletions(-)
--- linux-2.6.24-git12.orig/Documentation/DocBook/kernel-api.tmpl
+++ linux-2.6.24-git12/Documentation/DocBook/kernel-api.tmpl
@@ -230,8 +230,14 @@ X!Ilib/string.c
!Dnet/sunrpc/sunrpc_syms.c
-->
!Enet/sunrpc/xdr.c
-!Enet/sunrpc/svcsock.c
+!Enet/sunrpc/svc_xprt.c
+!Enet/sunrpc/xprt.c
!Enet/sunrpc/sched.c
+!Enet/sunrpc/socklib.c
+!Enet/sunrpc/stats.c
+!Enet/sunrpc/rpc_pipe.c
+!Enet/sunrpc/rpcb_clnt.c
+!Enet/sunrpc/clnt.c
</sect1>
</chapter>
--- linux-2.6.24-git12.orig/net/sunrpc/clnt.c
+++ linux-2.6.24-git12/net/sunrpc/clnt.c
@@ -464,9 +464,9 @@ rpc_release_client(struct rpc_clnt *clnt
/**
* rpc_bind_new_program - bind a new RPC program to an existing client
- * @old - old rpc_client
- * @program - rpc program to set
- * @vers - rpc program version
+ * @old: old rpc_client
+ * @program: rpc program to set
+ * @vers: rpc program version
*
* Clones the rpc client and sets up a new RPC program. This is mainly
* of use for enabling different RPC programs to share the same transport.
@@ -575,7 +575,7 @@ EXPORT_SYMBOL_GPL(rpc_call_sync);
* @clnt: pointer to RPC client
* @msg: RPC call parameters
* @flags: RPC call flags
- * @ops: RPC call ops
+ * @tk_ops: RPC call ops
* @data: user call data
*/
int
@@ -610,7 +610,7 @@ EXPORT_SYMBOL_GPL(rpc_call_start);
* rpc_peeraddr - extract remote peer address from clnt's xprt
* @clnt: RPC client structure
* @buf: target buffer
- * @size: length of target buffer
+ * @bufsize: length of target buffer
*
* Returns the number of bytes that are actually in the stored address.
*/
--- linux-2.6.24-git12.orig/net/sunrpc/xprt.c
+++ linux-2.6.24-git12/net/sunrpc/xprt.c
@@ -124,7 +124,7 @@ EXPORT_SYMBOL_GPL(xprt_register_transpor
/**
* xprt_unregister_transport - unregister a transport implementation
- * transport: transport to unregister
+ * @transport: transport to unregister
*
* Returns:
* 0: transport successfully unregistered
--- linux-2.6.24-git12.orig/net/sunrpc/rpc_pipe.c
+++ linux-2.6.24-git12/net/sunrpc/rpc_pipe.c
@@ -677,7 +677,7 @@ rpc_lookup_negative(char *path, struct n
/**
* rpc_mkdir - Create a new directory in rpc_pipefs
* @path: path from the rpc_pipefs root to the new directory
- * @rpc_clnt: rpc client to associate with this directory
+ * @rpc_client: rpc client to associate with this directory
*
* This creates a directory at the given @path associated with
* @rpc_clnt, which will contain a file named "info" with some basic
@@ -748,6 +748,7 @@ rpc_rmdir(struct dentry *dentry)
* @private: private data to associate with the pipe, for the caller's use
* @ops: operations defining the behavior of the pipe: upcall, downcall,
* release_pipe, and destroy_msg.
+ * @flags: rpc_inode flags
*
* Data is made available for userspace to read by calls to
* rpc_queue_upcall(). The actual reads will result in calls to
^ permalink raw reply
* Re: locking api self-test hanging
From: Andrew Morton @ 2008-02-03 23:07 UTC (permalink / raw)
To: netdev; +Cc: Ingo Molnar, linux-kernel
In-Reply-To: <20080203150246.50647fa4.akpm@linux-foundation.org>
On Sun, 3 Feb 2008 15:02:46 -0800 Andrew Morton <akpm@linux-foundation.org> wrote:
>
> With current mainline I'm getting intermittent hangs here:
>
> http://userweb.kernel.org/~akpm/p2033590.jpg
>
> with this config:
>
> http://userweb.kernel.org/~akpm/config-sony.txt
>
> on the Vaio. Sometimes it boots (then hits another different hang),
> sometimes it gets stuck there.
>
The second hang is in kobject_uevent_init(). All that function does is call
netlink_kernel_create().
These things make bisecting all the other bugs rather hard.
^ permalink raw reply
* Re: [PATCH] request_irq() always returns -EINVAL with a NULL handler.
From: Rusty Russell @ 2008-02-04 5:55 UTC (permalink / raw)
To: Andrew Morton; +Cc: Jeff Garzik, netdev, linux-kernel
In-Reply-To: <20080202221502.76d48ead.akpm@linux-foundation.org>
On Sunday 03 February 2008 17:15:02 Andrew Morton wrote:
> On Thu, 17 Jan 2008 17:57:58 +1100 Rusty Russell <rusty@rustcorp.com.au>
wrote:
> > I assume that these ancient network drivers were trying to find out if
> > an irq is available. eepro.c expecting +EBUSY was doubly wrong.
> >
> > I'm not sure that can_request_irq() is the right thing, but these drivers
> > are definitely wrong.
> >
> > request_irq should BUG() on bad input, and these would have been found
> > earlier.
>
> This breaks non-CONFIG_GENERIC_HARDIRQS architectures.
>
> alpha:
>
> drivers/net/3c503.c: In function 'el2_open':
> drivers/net/3c503.c:382: error: implicit declaration of function
> 'can_request_irq'
Since this code was non-functional before, should we just be removing
the "check if irq is free" check altogether?
This is Jeff's call, I think.
Rusty.
^ permalink raw reply
* radvd 1.1 released
From: Pekka Savola @ 2008-02-04 6:55 UTC (permalink / raw)
To: netdev, radvd-announce-l; +Cc: radvd-devel-l
Hi,
A new version of radvd has been released. There have been a couple of
new features.
Interfaces must now be RUNNING, not just UP, to be considered by
default radvd configuration. This is because nowadays kernels no
longer generate v6 link-local addresses if the interface is just UP,
in contrast to e.g., what earlier kernels did.
I'd like issue special thanks to Jim Paris for all the patches he has
sent :-).
Get it at: http://www.litech.org/radvd/
Changes since 1.0:
* Implement privilege separation on Linux: a master root process
(which is able to reconfigure interfaces) and the main process. There
is '-s' toggle to keep old behaviour.
* Fix Linux retrans_timer on old kernels (newer ones have
retrans_timer_ms)
* Fix stderr+syslog (default) logging on non-i386 platforms.
* Require that interface must be RUNNING instead of just UP. Note:
this could break deployments with very old kernels.
* Implement automatic interface address advertising with special
prefix ::/64.
* Relax interface naming (e.g. with VLANs) requirements.
* Fix ordering of route, prefix and RDNSS options (only matters
with RDNSS)
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
^ permalink raw reply
* [NET]: Remove further references to net-modules.txt
From: Johann Felix Soden @ 2008-02-04 7:31 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, trivial
From: Johann Felix Soden <johfel@users.sourceforge.net>
The Kconfig of igb and enc28j60 contains references to
obsolet Documentation/networking/net-modules.txt.
Signed-off-by: Johann Felix Soden <johfel@users.sourceforge.net>
---
drivers/net/Kconfig | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 389980f..87f503b 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -919,8 +919,7 @@ config ENC28J60
---help---
Support for the Microchip EN28J60 ethernet chip.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module will be
+ To compile this driver as a module, choose M here. The module will be
called enc28j60.
config ENC28J60_WRITEVERIFY
@@ -2040,8 +2039,7 @@ config IGB
More specific information on configuring the driver is in
<file:Documentation/networking/e1000.txt>.
- To compile this driver as a module, choose M here and read
- <file:Documentation/networking/net-modules.txt>. The module
+ To compile this driver as a module, choose M here. The module
will be called igb.
source "drivers/net/ixp2000/Kconfig"
--
1.5.4
^ permalink raw reply related
* [PATCH][INET]: Fix accidentally broken inet(6)_hash_connect's port offset calculations.
From: Pavel Emelyanov @ 2008-02-04 8:10 UTC (permalink / raw)
To: David Miller; +Cc: Adrian Bunk, Linux Netdev List, devel
The port offset calculations depend on the protocol family, but,
as Adrian noticed, I broke this logic with the commit
5ee31fc1ecdcbc234c8c56dcacef87c8e09909d8
[INET]: Consolidate inet(6)_hash_connect.
Return this logic back, by passing the port offset directly into
the consolidated function.
Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Noticed-by: Adrian Bunk <bunk@kernel.org>
---
diff --git a/include/net/inet_hashtables.h b/include/net/inet_hashtables.h
index 48ac620..97dc35a 100644
--- a/include/net/inet_hashtables.h
+++ b/include/net/inet_hashtables.h
@@ -389,7 +389,7 @@ static inline struct sock *inet_lookup(struct net *net,
}
extern int __inet_hash_connect(struct inet_timewait_death_row *death_row,
- struct sock *sk,
+ struct sock *sk, u32 port_offset,
int (*check_established)(struct inet_timewait_death_row *,
struct sock *, __u16, struct inet_timewait_sock **),
void (*hash)(struct sock *sk));
diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c
index 90f422c..9cac6c0 100644
--- a/net/ipv4/inet_hashtables.c
+++ b/net/ipv4/inet_hashtables.c
@@ -398,7 +398,7 @@ out:
EXPORT_SYMBOL_GPL(inet_unhash);
int __inet_hash_connect(struct inet_timewait_death_row *death_row,
- struct sock *sk,
+ struct sock *sk, u32 port_offset,
int (*check_established)(struct inet_timewait_death_row *,
struct sock *, __u16, struct inet_timewait_sock **),
void (*hash)(struct sock *sk))
@@ -413,7 +413,7 @@ int __inet_hash_connect(struct inet_timewait_death_row *death_row,
if (!snum) {
int i, remaining, low, high, port;
static u32 hint;
- u32 offset = hint + inet_sk_port_offset(sk);
+ u32 offset = hint + port_offset;
struct hlist_node *node;
struct inet_timewait_sock *tw = NULL;
@@ -502,7 +502,7 @@ EXPORT_SYMBOL_GPL(__inet_hash_connect);
int inet_hash_connect(struct inet_timewait_death_row *death_row,
struct sock *sk)
{
- return __inet_hash_connect(death_row, sk,
+ return __inet_hash_connect(death_row, sk, inet_sk_port_offset(sk),
__inet_check_established, __inet_hash_nolisten);
}
diff --git a/net/ipv6/inet6_hashtables.c b/net/ipv6/inet6_hashtables.c
index 43f3993..99fd25f 100644
--- a/net/ipv6/inet6_hashtables.c
+++ b/net/ipv6/inet6_hashtables.c
@@ -236,7 +236,7 @@ static inline u32 inet6_sk_port_offset(const struct sock *sk)
int inet6_hash_connect(struct inet_timewait_death_row *death_row,
struct sock *sk)
{
- return __inet_hash_connect(death_row, sk,
+ return __inet_hash_connect(death_row, sk, inet6_sk_port_offset(sk),
__inet6_check_established, __inet6_hash);
}
^ permalink raw reply related
* Re: LRO ip_summed
From: Jan-Bernd Themann @ 2008-02-04 9:14 UTC (permalink / raw)
To: Kostya B; +Cc: netdev
In-Reply-To: <BAY121-W366A043ECDC160494B1EFAB6320@phx.gbl>
On Sunday 03 February 2008 10:48, Kostya B wrote:
>
> Hi,
>
> The mail is related to the way LRO manipulates the ip_summed value. Could anybody (author) explain why to overwrite the original value of skb->ip_summed, when it's processing by __lro_proc_skb ?
> E.g. in out: label
>
> Why not to preserve the coherency of csum status of each incoming to LRO packet, the same way the IP defragmentation does? That means - all skb in descriptor have the same value of ip_summed.
>
Hi,
I'm not sure if I understand your proposal correctly.
Currently the driver decides via the struct net_lro_mgr
a) which ip_summed value will be used for all aggregated packets
b) which one to use for those packets that can not be aggregated
to a) this one should always be the same. The driver knows whether its HW is
capable of performing ip checksum checking for this kind of traffic (TCP)
There are two modes: aggregating SKBs or aggregating fragments.
When fragments are aggregated, there is no SKB with a filled ip_summed available.
Please outline which parts of which mode you suggest to change.
Regards,
Jan-Bernd
^ permalink raw reply
* Re: oops with ipcomp
From: Beschorner Daniel @ 2008-02-04 9:35 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <20080202044254.GA27792@gondor.apana.org.au>
>> Unable to handle kernel paging request at ffffc200000fb000 RIP:
>> [<ffffffff8031b8f0>] deflate_slow+0x40/0x400
> I'm not able to get much information out of this crash dump. Nor
> can I reproduce this bug on my 32-bit machines and I'm currently
> away from my 64-bit machines.
> How long have you been using IPComp in the past and what was the
> last kernel version which was stable with IPComp?
I've never seen this with kernels < 2.6.24 after many years of
ipsec/ipcomp usage.
I got it 18 hours after boot, since the oops it runs stable for further
72 hours.
But I cross the fingers that it was an unique issue, I'll report if it
oopses again.
Daniel
^ permalink raw reply
* include/linux/pcounter.h
From: Andrew Morton @ 2008-02-04 9:44 UTC (permalink / raw)
To: Herbert Xu, David S. Miller; +Cc: netdev, linux-kernel
e7d0362dd41e760f340c1b500646cc92522bd9d5 should have been folded into
de4d1db369785c29d68915edfee0cb70e8199f4c prior to merging. We now and for
ever have a window of breakage which screws up git bisection. Which I
just hit. Which is the only reason I discovered the file's existence.
Please do not merge pieces of generic kernel infrastructure while keeping
it all secret on the netdev list. Ever. That code has a number of deficiencies
which I and probably others would have noted had it been offered to us
for review.
^ 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