* Re: which stable usb wlan device
From: maximilian attems @ 2010-04-22 22:39 UTC (permalink / raw)
To: Markus Feldmann; +Cc: netdev
In-Reply-To: <hqqilh$7rd$1@dough.gmane.org>
On Fri, Apr 23, 2010 at 12:30:09AM +0200, Markus Feldmann wrote:
>
> i am searching for a wlan device. This should work as AP on Debian
> Lenny(current kernel 2.6.32.11). So here are my requirements for this
> device:
Lenny is our current stable release with 2.6.26, Squeeze the upcoming
has 2.6.32. good that you are already running it. :)
^ permalink raw reply
* Re: [PATCHv2] Socket filter ancilliary data access for skb->dev->type
From: David Miller @ 2010-04-22 23:06 UTC (permalink / raw)
To: leonerd; +Cc: netdev
In-Reply-To: <20100422133222.GU19334@cel.leo>
From: Paul LeoNerd Evans <leonerd@leonerd.org.uk>
Date: Thu, 22 Apr 2010 14:32:22 +0100
> Add an SKF_AD_HATYPE field to the packet ancilliary data area, giving
> access to skb->dev->type, as reported in the sll_hatype field.
>
> When capturing packets on a PF_PACKET/SOCK_RAW socket bound to all
> interfaces, there doesn't appear to be a way for the filter program to
> actually find out the underlying hardware type the packet was captured
> on. This patch adds such ability.
>
> This patch also handles the case where skb->dev can be NULL, such as on
> netlink sockets.
>
> Signed-off-by: Paul Evans <leonerd@leonerd.org.uk>
Looks good, applied to net-next-2.6, thanks!
^ permalink raw reply
* Re: [net-next PATCH 1/2] add iovnl netlink support
From: David Miller @ 2010-04-22 23:04 UTC (permalink / raw)
To: scofeldm; +Cc: netdev, chrisw
In-Reply-To: <C7F60C62.2AC93%scofeldm@cisco.com>
From: Scott Feldman <scofeldm@cisco.com>
Date: Thu, 22 Apr 2010 14:23:30 -0700
> On 4/21/10 11:48 PM, "David Miller" <davem@davemloft.net> wrote:
>
>> From: Scott Feldman <scofeldm@cisco.com>
>> Date: Mon, 19 Apr 2010 12:18:07 -0700
>>
>>> +#define IOVNL_PROTO_VERSION 1
>>> +
>>
>> Please delete this in the final version, the macro isn't even used by
>> the code.
>>
>> We don't do protocol versioning in netlink. Instead we get the base
>> stuff solid from the beginning, and then if something needs fixing up
>> we handle this using new attributes in a way which is both backward
>> and forward compatible.
>
> Sounds good to me, was a cut-and-paste from dcbnl.h. How about:
This is perfectly fine except it got whitespace damanged by your
email client and needs a proper commit message and signoff :-)
^ permalink raw reply
* Re: [PATCH v2] tcp: fix outsegs stat for TSO segments
From: David Miller @ 2010-04-22 23:00 UTC (permalink / raw)
To: therbert; +Cc: netdev
In-Reply-To: <alpine.DEB.1.00.1004220956080.28813@pokey.mtv.corp.google.com>
From: Tom Herbert <therbert@google.com>
Date: Thu, 22 Apr 2010 10:00:24 -0700 (PDT)
> Account for TSO segments of an skb in TCP_MIB_OUTSEGS counter. Without
> doing this, the counter can be off by orders of magnitude from the
> actual number of segments sent.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
Applied to net-next-2.6, thanks Tom.
^ permalink raw reply
* Re: [patch] wimax: checking ERR_PTR vs null
From: Inaky Perez-Gonzalez @ 2010-04-22 22:56 UTC (permalink / raw)
To: Dan Carpenter
Cc: netdev@vger.kernel.org, wimax@linuxwimax.org,
kernel-janitors@vger.kernel.org, David S. Miller,
Paulius Zaleckas, Alexey Dobriyan
In-Reply-To: <20100422095010.GN29647@bicker>
On Thu, 2010-04-22 at 02:50 -0700, Dan Carpenter wrote:
> stch_skb is allocated with wimax_gnl_re_state_change_alloc(). That
> function returns ERR_PTRs on failure and doesn't return NULL.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
ACK, thanks [and thanks to davem for reminding me]
^ permalink raw reply
* Re: [patch] rdma: potential ERR_PTR dereference
From: David Miller @ 2010-04-22 22:57 UTC (permalink / raw)
To: error27; +Cc: andy.grover, rds-devel, netdev, kernel-janitors
In-Reply-To: <20100422095527.GQ29647@bicker>
From: Dan Carpenter <error27@gmail.com>
Date: Thu, 22 Apr 2010 11:55:27 +0200
> In the original code, the "goto out" calls "rdma_destroy_id(cm_id);"
> That isn't needed here and would cause problems because "cm_id" is an
> ERR_PTR. The new code just returns directly.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Applied.
^ permalink raw reply
* Re: [patch] rtnetlink: potential ERR_PTR dereference
From: David Miller @ 2010-04-22 22:57 UTC (permalink / raw)
To: error27
Cc: netdev, eric.dumazet, kaber, ebiederm, mitch.a.williams,
kernel-janitors
In-Reply-To: <20100422095327.GP29647@bicker>
From: Dan Carpenter <error27@gmail.com>
Date: Thu, 22 Apr 2010 11:53:27 +0200
> In the original code, if rtnl_create_link() returned an ERR_PTR then that
> would get passed to rtnl_configure_link() which dereferences it.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Applied.
^ permalink raw reply
* Re: [patch] wimax: wimax_msg_alloc() returns ERR_PTR not null
From: David Miller @ 2010-04-22 22:56 UTC (permalink / raw)
To: inaky; +Cc: error27, netdev, andre.goddard, kernel-janitors, wimax,
linux-wimax
In-Reply-To: <1271973596.2867.3.camel@localhost.localdomain>
From: Inaky Perez-Gonzalez <inaky@linux.intel.com>
Date: Thu, 22 Apr 2010 14:59:56 -0700
> On Thu, 2010-04-22 at 11:46 +0200, Dan Carpenter wrote:
>> wimax_msg_alloc() returns an ERR_PTR and not null. I changed it to test
>> for ERR_PTR instead of null. I also added a check in front of the
>> kfree() because kfree() can handle null but not ERR_PTR.
>>
>> Signed-off-by: Dan Carpenter <error27@gmail.com>
>
> Good catch thank you!
>
> Will merge ASAP in preparation for the next push
There was another wimax fix from Dan, subject:
[patch] wimax: checking ERR_PTR vs null
make sure you integrate that one too.
^ permalink raw reply
* Re: [PATCH] NIU support for skb->rxhash
From: David Miller @ 2010-04-22 22:53 UTC (permalink / raw)
To: netdev
In-Reply-To: <20100422.042157.99869295.davem@davemloft.net>
Ok, based upon Stephen's feedback I added the ethtool bits,
here is the final version I committed to net-next-2.6:
--------------------
niu: Add skb->rxhash support.
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/niu.c | 52 ++++++++++++++++++++++++++++++++++++++++------------
drivers/net/niu.h | 7 +++++--
2 files changed, 45 insertions(+), 14 deletions(-)
diff --git a/drivers/net/niu.c b/drivers/net/niu.c
index 493e25c..30abb4e 100644
--- a/drivers/net/niu.c
+++ b/drivers/net/niu.c
@@ -36,8 +36,8 @@
#include "niu.h"
#define DRV_MODULE_NAME "niu"
-#define DRV_MODULE_VERSION "1.0"
-#define DRV_MODULE_RELDATE "Nov 14, 2008"
+#define DRV_MODULE_VERSION "1.1"
+#define DRV_MODULE_RELDATE "Apr 22, 2010"
static char version[] __devinitdata =
DRV_MODULE_NAME ".c:v" DRV_MODULE_VERSION " (" DRV_MODULE_RELDATE ")\n";
@@ -3444,6 +3444,7 @@ static int niu_process_rx_pkt(struct napi_struct *napi, struct niu *np,
struct rx_ring_info *rp)
{
unsigned int index = rp->rcr_index;
+ struct rx_pkt_hdr1 *rh;
struct sk_buff *skb;
int len, num_rcr;
@@ -3477,9 +3478,6 @@ static int niu_process_rx_pkt(struct napi_struct *napi, struct niu *np,
if (num_rcr == 1) {
int ptype;
- off += 2;
- append_size -= 2;
-
ptype = (val >> RCR_ENTRY_PKT_TYPE_SHIFT);
if ((ptype == RCR_PKT_TYPE_TCP ||
ptype == RCR_PKT_TYPE_UDP) &&
@@ -3488,8 +3486,7 @@ static int niu_process_rx_pkt(struct napi_struct *napi, struct niu *np,
skb->ip_summed = CHECKSUM_UNNECESSARY;
else
skb->ip_summed = CHECKSUM_NONE;
- }
- if (!(val & RCR_ENTRY_MULTI))
+ } else if (!(val & RCR_ENTRY_MULTI))
append_size = len - skb->len;
niu_rx_skb_append(skb, page, off, append_size);
@@ -3510,8 +3507,17 @@ static int niu_process_rx_pkt(struct napi_struct *napi, struct niu *np,
}
rp->rcr_index = index;
- skb_reserve(skb, NET_IP_ALIGN);
- __pskb_pull_tail(skb, min(len, VLAN_ETH_HLEN));
+ len += sizeof(*rh);
+ len = min_t(int, len, sizeof(*rh) + VLAN_ETH_HLEN);
+ __pskb_pull_tail(skb, len);
+
+ rh = (struct rx_pkt_hdr1 *) skb->data;
+ if (np->dev->features & NETIF_F_RXHASH)
+ skb->rxhash = ((u32)rh->hashval2_0 << 24 |
+ (u32)rh->hashval2_1 << 16 |
+ (u32)rh->hashval1_1 << 8 |
+ (u32)rh->hashval1_2 << 0);
+ skb_pull(skb, sizeof(*rh));
rp->rx_packets++;
rp->rx_bytes += skb->len;
@@ -4946,7 +4952,9 @@ static int niu_init_one_rx_channel(struct niu *np, struct rx_ring_info *rp)
RX_DMA_CTL_STAT_RCRTO |
RX_DMA_CTL_STAT_RBR_EMPTY));
nw64(RXDMA_CFIG1(channel), rp->mbox_dma >> 32);
- nw64(RXDMA_CFIG2(channel), (rp->mbox_dma & 0x00000000ffffffc0));
+ nw64(RXDMA_CFIG2(channel),
+ ((rp->mbox_dma & RXDMA_CFIG2_MBADDR_L) |
+ RXDMA_CFIG2_FULL_HDR));
nw64(RBR_CFIG_A(channel),
((u64)rp->rbr_table_size << RBR_CFIG_A_LEN_SHIFT) |
(rp->rbr_dma & (RBR_CFIG_A_STADDR_BASE | RBR_CFIG_A_STADDR)));
@@ -7910,6 +7918,18 @@ static int niu_phys_id(struct net_device *dev, u32 data)
return 0;
}
+static int niu_set_flags(struct net_device *dev, u32 data)
+{
+ if (data & (ETH_FLAG_LRO | ETH_FLAG_NTUPLE))
+ return -EOPNOTSUPP;
+
+ if (data & ETH_FLAG_RXHASH)
+ dev->features |= NETIF_F_RXHASH;
+ else
+ dev->features &= ~NETIF_F_RXHASH;
+ return 0;
+}
+
static const struct ethtool_ops niu_ethtool_ops = {
.get_drvinfo = niu_get_drvinfo,
.get_link = ethtool_op_get_link,
@@ -7926,6 +7946,8 @@ static const struct ethtool_ops niu_ethtool_ops = {
.phys_id = niu_phys_id,
.get_rxnfc = niu_get_nfc,
.set_rxnfc = niu_set_nfc,
+ .set_flags = niu_set_flags,
+ .get_flags = ethtool_op_get_flags,
};
static int niu_ldg_assign_ldn(struct niu *np, struct niu_parent *parent,
@@ -9754,6 +9776,12 @@ static void __devinit niu_device_announce(struct niu *np)
}
}
+static void __devinit niu_set_basic_features(struct net_device *dev)
+{
+ dev->features |= (NETIF_F_SG | NETIF_F_HW_CSUM |
+ NETIF_F_GRO | NETIF_F_RXHASH);
+}
+
static int __devinit niu_pci_init_one(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
@@ -9838,7 +9866,7 @@ static int __devinit niu_pci_init_one(struct pci_dev *pdev,
}
}
- dev->features |= (NETIF_F_SG | NETIF_F_HW_CSUM | NETIF_F_GRO);
+ niu_set_basic_features(dev);
np->regs = pci_ioremap_bar(pdev, 0);
if (!np->regs) {
@@ -10080,7 +10108,7 @@ static int __devinit niu_of_probe(struct of_device *op,
goto err_out_free_dev;
}
- dev->features |= (NETIF_F_SG | NETIF_F_HW_CSUM);
+ niu_set_basic_features(dev);
np->regs = of_ioremap(&op->resource[1], 0,
resource_size(&op->resource[1]),
diff --git a/drivers/net/niu.h b/drivers/net/niu.h
index 3bd0b59..d671546 100644
--- a/drivers/net/niu.h
+++ b/drivers/net/niu.h
@@ -2706,7 +2706,7 @@ struct rx_pkt_hdr0 {
#if defined(__LITTLE_ENDIAN_BITFIELD)
u8 inputport:2,
maccheck:1,
- class:4;
+ class:5;
u8 vlan:1,
llcsnap:1,
noport:1,
@@ -2715,7 +2715,7 @@ struct rx_pkt_hdr0 {
tres:2,
tzfvld:1;
#elif defined(__BIG_ENDIAN_BITFIELD)
- u8 class:4,
+ u8 class:5,
maccheck:1,
inputport:2;
u8 tzfvld:1,
@@ -2775,6 +2775,9 @@ struct rx_pkt_hdr1 {
/* Bits 7:0 of hash value, H1. */
u8 hashval1_2;
+ u8 hwrsvd5;
+ u8 hwrsvd6;
+
u8 usrdata_0; /* Bits 39:32 of user data. */
u8 usrdata_1; /* Bits 31:24 of user data. */
u8 usrdata_2; /* Bits 23:16 of user data. */
--
1.7.0.4
^ permalink raw reply related
* which stable usb wlan device
From: Markus Feldmann @ 2010-04-22 22:30 UTC (permalink / raw)
To: netdev
Hi All,
i am searching for a wlan device. This should work as AP on Debian
Lenny(current kernel 2.6.32.11). So here are my requirements for this
device:
1.stable open source driver included in the kernel, not from an extern
source. I want to use this device as AP!
2.USB2 compatible
3.WPA2 compliant for more savety
4.adjustable transmission power to reduce the maximum range
5.A low power sonsumption as low as possible, a reference value is 1watt
6.price should under 40€=60$ as much as possible
I just found your new device side:
http://linuxwireless.org/en/users/Drivers/ath9k/devices
but are these devices who works well or not? If i buy such a device, is
only the Atheros Chip number important for me, or should i watch for the
Subvendor ans Subsystem number too?
Further on i only found PCI devices. Is there a supported usb device
list too?
regards Markus
^ permalink raw reply
* Re: Subject: re-submit4 [ANNOUNCEMENT] NET: usb: sierra_net.c driver
From: Greg KH @ 2010-04-22 22:27 UTC (permalink / raw)
To: Dan Williams; +Cc: Elina Pasheva, dbrownell, davem, rfiler, linux-usb, netdev
In-Reply-To: <1271970906.26097.72.camel@localhost.localdomain>
On Thu, Apr 22, 2010 at 02:15:06PM -0700, Dan Williams wrote:
> On Thu, 2010-04-22 at 12:44 -0700, Greg KH wrote:
> > On Thu, Apr 22, 2010 at 12:19:33PM -0700, Elina Pasheva wrote:
> > > +static void sierra_net_send_cmd(struct usbnet *dev,
> > > + u8 *cmd, int cmdlen, const char * cmd_name)
> > > +{
> > > + struct sierra_net_data *priv = sierra_net_get_private(dev);
> > > + int status;
> > > +
> > > + status = usb_control_msg(dev->udev, usb_sndctrlpipe(dev->udev, 0),
> > > + USB_CDC_SEND_ENCAPSULATED_COMMAND,
> > > + USB_DIR_OUT|USB_TYPE_CLASS|USB_RECIP_INTERFACE, 0,
> > > + priv->ifnum, cmd, cmdlen, 0);
> >
> > No timeout?
> >
> > > + ifnum = priv->ifnum;
> > > + len = usb_control_msg(dev->udev, usb_rcvctrlpipe(dev->udev, 0),
> > > + USB_CDC_GET_ENCAPSULATED_RESPONSE,
> > > + USB_DIR_IN|USB_TYPE_CLASS|USB_RECIP_INTERFACE,
> > > + 0, ifnum, buf, SIERRA_NET_USBCTL_BUF_LEN, 0);
> >
> > No timeout?
> >
> > > + if (unlikely(len < 0)) {
> > > + netdev_err(dev->net,
> > > + "usb_control_msg failed, status %d\n", len);
> >
> > You don't need "unlikely", this is an extreemly slow path here.
> > Also, what happens for a "short read"? You don't handle that properly.
>
> Is the code doc for usb_unlink_urb() in urb.c the best thing to look at
> for how to handle short reads? I assume that involves checking if the
> returned error is -EREMOTEIO and if so, ignoring it? I spent about an
> hour googling and poking around in the kernel sources and couldn't find
> much about how to handle short reads. The only non-host-side driver
> that cares about EREMOTEIO is misc/rio500.c, the rest is all under host/
> or gadget/.
Well, if the return value is less than what you expect it to be,
something went wrong and you should error out. Some of the calls handle
this properly in this driver, some do not. Consistency is key :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] IPv6: Generic TTL Security Mechanism (final version)
From: David Miller @ 2010-04-22 22:27 UTC (permalink / raw)
To: shemminger; +Cc: pekkas, yoshfuji, nick, netdev
In-Reply-To: <20100422151846.710a6d17@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 22 Apr 2010 15:18:46 -0700
> This patch adds IPv6 support for RFC5082 Generalized TTL Security Mechanism.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] NIU support for skb->rxhash
From: David Miller @ 2010-04-22 22:24 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20100422151140.01f19059@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 22 Apr 2010 15:11:40 -0700
> On Thu, 22 Apr 2010 14:36:06 -0700 (PDT)
> David Miller <davem@davemloft.net> wrote:
>
>> From: Stephen Hemminger <shemminger@vyatta.com>
>> Date: Thu, 22 Apr 2010 09:21:20 -0700
>>
>> > P.s: where is that patch seems lost in patchwork
>>
>> I marked it as RFC since that's what it was.
>
>
> It works fine, put it net-next
There is nothing CONFIG_RPS dependent about ->rxhash, we could
use it for many other things.
Please take away that CONFIG_RPS ifdef and I'll apply it.
^ permalink raw reply
* [PATCH] IPv6: Generic TTL Security Mechanism (final version)
From: Stephen Hemminger @ 2010-04-22 22:18 UTC (permalink / raw)
To: David Miller; +Cc: pekkas, yoshfuji, nick, netdev
In-Reply-To: <20100422.143805.95887767.davem@davemloft.net>
This patch adds IPv6 support for RFC5082 Generalized TTL Security Mechanism.
Not to users of mapped address; the IPV6 and IPV4 socket options are seperate.
The server does have to deal with both IPv4 and IPv6 socket options
and the client has to handle the different for each family.
On client:
int ttl = 255;
getaddrinfo(argv[1], argv[2], &hint, &result);
for (rp = result; rp != NULL; rp = rp->ai_next) {
s = socket(rp->ai_family, rp->ai_socktype, rp->ai_protocol);
if (s < 0) continue;
if (rp->ai_family == AF_INET) {
setsockopt(s, IPPROTO_IP, IP_TTL, &ttl, sizeof(ttl));
} else if (rp->ai_family == AF_INET6) {
setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
&ttl, sizeof(ttl)))
}
if (connect(s, rp->ai_addr, rp->ai_addrlen) == 0) {
...
On server:
int minttl = 255 - maxhops;
getaddrinfo(NULL, port, &hints, &result);
for (rp = result; rp != NULL; rp = rp->ai_next) {
s = socket(rp->ai_family, rp->ai_socktype, rp->ai_protocol);
if (s < 0) continue;
if (rp->ai_family == AF_INET6)
setsockopt(s, IPPROTO_IPV6, IPV6_MINHOPCOUNT,
&minttl, sizeof(minttl));
setsockopt(s, IPPROTO_IP, IP_MINTTL, &minttl, sizeof(minttl));
if (bind(s, rp->ai_addr, rp->ai_addrlen) == 0)
break
...
Same as v1 (except commit message)
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
include/linux/in6.h | 3 +++
include/linux/ipv6.h | 1 +
net/ipv6/ipv6_sockglue.c | 12 ++++++++++++
net/ipv6/tcp_ipv6.c | 14 +++++++++++++-
4 files changed, 29 insertions(+), 1 deletion(-)
--- a/net/ipv6/tcp_ipv6.c 2010-04-22 09:32:39.845447496 -0700
+++ b/net/ipv6/tcp_ipv6.c 2010-04-22 09:32:47.395758592 -0700
@@ -353,6 +353,11 @@ static void tcp_v6_err(struct sk_buff *s
if (sk->sk_state == TCP_CLOSE)
goto out;
+ if (ipv6_hdr(skb)->hop_limit < inet6_sk(sk)->min_hopcount) {
+ NET_INC_STATS_BH(net, LINUX_MIB_TCPMINTTLDROP);
+ goto out;
+ }
+
tp = tcp_sk(sk);
seq = ntohl(th->seq);
if (sk->sk_state != TCP_LISTEN &&
@@ -1675,6 +1680,7 @@ ipv6_pktoptions:
static int tcp_v6_rcv(struct sk_buff *skb)
{
struct tcphdr *th;
+ struct ipv6hdr *hdr;
struct sock *sk;
int ret;
struct net *net = dev_net(skb->dev);
@@ -1701,12 +1707,13 @@ static int tcp_v6_rcv(struct sk_buff *sk
goto bad_packet;
th = tcp_hdr(skb);
+ hdr = ipv6_hdr(skb);
TCP_SKB_CB(skb)->seq = ntohl(th->seq);
TCP_SKB_CB(skb)->end_seq = (TCP_SKB_CB(skb)->seq + th->syn + th->fin +
skb->len - th->doff*4);
TCP_SKB_CB(skb)->ack_seq = ntohl(th->ack_seq);
TCP_SKB_CB(skb)->when = 0;
- TCP_SKB_CB(skb)->flags = ipv6_get_dsfield(ipv6_hdr(skb));
+ TCP_SKB_CB(skb)->flags = ipv6_get_dsfield(hdr);
TCP_SKB_CB(skb)->sacked = 0;
sk = __inet6_lookup_skb(&tcp_hashinfo, skb, th->source, th->dest);
@@ -1717,6 +1724,11 @@ process:
if (sk->sk_state == TCP_TIME_WAIT)
goto do_time_wait;
+ if (hdr->hop_limit < inet6_sk(sk)->min_hopcount) {
+ NET_INC_STATS_BH(net, LINUX_MIB_TCPMINTTLDROP);
+ goto discard_and_relse;
+ }
+
if (!xfrm6_policy_check(sk, XFRM_POLICY_IN, skb))
goto discard_and_relse;
--- a/include/linux/in6.h 2010-04-22 09:32:39.855445952 -0700
+++ b/include/linux/in6.h 2010-04-22 09:32:47.395758592 -0700
@@ -265,6 +265,9 @@ struct in6_flowlabel_req {
#define IPV6_PREFER_SRC_CGA 0x0008
#define IPV6_PREFER_SRC_NONCGA 0x0800
+/* RFC5082: Generalized Ttl Security Mechanism */
+#define IPV6_MINHOPCOUNT 73
+
/*
* Multicast Routing:
* see include/linux/mroute6.h.
--- a/include/linux/ipv6.h 2010-04-22 09:32:39.865447950 -0700
+++ b/include/linux/ipv6.h 2010-04-22 09:32:47.395758592 -0700
@@ -348,6 +348,7 @@ struct ipv6_pinfo {
* 010: prefer public address
* 100: prefer care-of address
*/
+ __u8 min_hopcount;
__u8 tclass;
__u32 dst_cookie;
--- a/net/ipv6/ipv6_sockglue.c 2010-04-22 09:32:39.835445583 -0700
+++ b/net/ipv6/ipv6_sockglue.c 2010-04-22 09:32:47.405760414 -0700
@@ -767,6 +767,14 @@ pref_skip_coa:
break;
}
+ case IPV6_MINHOPCOUNT:
+ if (optlen < sizeof(int))
+ goto e_inval;
+ if (val < 0 || val > 255)
+ goto e_inval;
+ np->min_hopcount = val;
+ retv = 0;
+ break;
}
release_sock(sk);
@@ -1116,6 +1124,10 @@ static int do_ipv6_getsockopt(struct soc
val |= IPV6_PREFER_SRC_HOME;
break;
+ case IPV6_MINHOPCOUNT:
+ val = np->min_hopcount;
+ break;
+
default:
return -ENOPROTOOPT;
}
^ permalink raw reply
* Re: [PATCH] NIU support for skb->rxhash
From: Stephen Hemminger @ 2010-04-22 22:11 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20100422.143606.56183045.davem@davemloft.net>
On Thu, 22 Apr 2010 14:36:06 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Thu, 22 Apr 2010 09:21:20 -0700
>
> > P.s: where is that patch seems lost in patchwork
>
> I marked it as RFC since that's what it was.
It works fine, put it net-next
^ permalink raw reply
* Re: [patch] wimax: wimax_msg_alloc() returns ERR_PTR not null
From: Inaky Perez-Gonzalez @ 2010-04-22 21:59 UTC (permalink / raw)
To: Dan Carpenter
Cc: netdev, André Goddard Rosa, kernel-janitors, wimax,
linux-wimax
In-Reply-To: <20100422094632.GM29647@bicker>
On Thu, 2010-04-22 at 11:46 +0200, Dan Carpenter wrote:
> wimax_msg_alloc() returns an ERR_PTR and not null. I changed it to test
> for ERR_PTR instead of null. I also added a check in front of the
> kfree() because kfree() can handle null but not ERR_PTR.
>
> Signed-off-by: Dan Carpenter <error27@gmail.com>
Good catch thank you!
Will merge ASAP in preparation for the next push
^ permalink raw reply
* Re: [PATCH] WAN: flush tx_queue in hdlc_ppp to prevent panic on rmmod hw_driver.
From: Michael Barkowski @ 2010-04-22 21:55 UTC (permalink / raw)
To: David Miller; +Cc: khc@pm.waw.pl, netdev@vger.kernel.org
In-Reply-To: <20100422.144339.128290761.davem@davemloft.net>
David Miller wrote:
> From: Michael Barkowski <michaelbarkowski@ruggedcom.com>
> Date: Thu, 22 Apr 2010 15:17:13 -0400
>
>> Krzysztof Halasa wrote:
>>> tx_queue is used as a temporary queue when not allowed to queue skb
>>> directly to the hw device driver (which may sleep). Most paths flush
>>> it before returning, but ppp_start() currently cannot. Make sure we
>>> don't leave skbs pointing to a non-existent device.
>>>
>>> Thanks to Michael Barkowski for reporting this problem.
>> Great - thanks. Will this be going into -stable?
>
> When I think it's cooked long enough in Linus's tree and
> I submit it there. That can take a few weeks.
>
Super. By the way, should have mentioned - tested and works for me
--
Michael Barkowski
^ permalink raw reply
* Re: [PATCH] WAN: flush tx_queue in hdlc_ppp to prevent panic on rmmod hw_driver.
From: David Miller @ 2010-04-22 21:43 UTC (permalink / raw)
To: michaelbarkowski; +Cc: khc, netdev
In-Reply-To: <4BD0A0B9.2070709@ruggedcom.com>
From: Michael Barkowski <michaelbarkowski@ruggedcom.com>
Date: Thu, 22 Apr 2010 15:17:13 -0400
> Krzysztof Halasa wrote:
>> tx_queue is used as a temporary queue when not allowed to queue skb
>> directly to the hw device driver (which may sleep). Most paths flush
>> it before returning, but ppp_start() currently cannot. Make sure we
>> don't leave skbs pointing to a non-existent device.
>>
>> Thanks to Michael Barkowski for reporting this problem.
>
> Great - thanks. Will this be going into -stable?
When I think it's cooked long enough in Linus's tree and
I submit it there. That can take a few weeks.
^ permalink raw reply
* Re: [PATCH 1/3] IPv6: Generic TTL Security Mechanism (original version)
From: David Miller @ 2010-04-22 21:38 UTC (permalink / raw)
To: shemminger; +Cc: pekkas, yoshfuji, nick, netdev
In-Reply-To: <20100422092305.0e45f547@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 22 Apr 2010 09:23:05 -0700
> Dave: Yoshifuji and I agree this is the best solution, how come the patch
> hasn't been applied?
You supplied 3 different implementations, that puts all of them
into "RFC" state in patchwork.
When you figure out which one is best you make a new explicit
submission of the implementation you think should actually
go into the tree.
^ permalink raw reply
* Re: [PATCH] NIU support for skb->rxhash
From: David Miller @ 2010-04-22 21:37 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20100422092120.603e83b8@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 22 Apr 2010 09:21:20 -0700
> Could you make configurable via ethtool like I did for sky2.
I'd much rather not.
I don't want to have two code different paths, extra conditionals,
etc. here. And there's no need to really, it's cheap enough.
I think drivers should unconditionally provide ->rxhash if they
reasonably can, otherwide don't bother at all.
^ permalink raw reply
* Re: [PATCH] NIU support for skb->rxhash
From: David Miller @ 2010-04-22 21:36 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20100422092120.603e83b8@nehalam>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 22 Apr 2010 09:21:20 -0700
> P.s: where is that patch seems lost in patchwork
I marked it as RFC since that's what it was.
^ permalink raw reply
* [PATCH net-next-2.6] dst: rcu check refinement
From: Eric Dumazet @ 2010-04-22 21:30 UTC (permalink / raw)
To: David Miller; +Cc: netdev
__sk_dst_get() might be called from softirq, with socket lock held.
[ 159.026180] include/net/sock.h:1200 invoked rcu_dereference_check()
without protection!
[ 159.026261]
[ 159.026261] other info that might help us debug this:
[ 159.026263]
[ 159.026425]
[ 159.026426] rcu_scheduler_active = 1, debug_locks = 0
[ 159.026552] 2 locks held by swapper/0:
[ 159.026609] #0: (&icsk->icsk_retransmit_timer){+.-...}, at:
[<ffffffff8104fc15>] run_timer_softirq+0x105/0x350
[ 159.026839] #1: (slock-AF_INET){+.-...}, at: [<ffffffff81392b8f>]
tcp_write_timer+0x2f/0x1e0
[ 159.027063]
[ 159.027064] stack backtrace:
[ 159.027172] Pid: 0, comm: swapper Not tainted
2.6.34-rc5-03707-gde498c8-dirty #36
[ 159.027252] Call Trace:
[ 159.027306] <IRQ> [<ffffffff810718ef>] lockdep_rcu_dereference
+0xaf/0xc0
[ 159.027411] [<ffffffff8138e4f7>] tcp_current_mss+0xa7/0xb0
[ 159.027537] [<ffffffff8138fa49>] tcp_write_wakeup+0x89/0x190
[ 159.027600] [<ffffffff81391936>] tcp_send_probe0+0x16/0x100
[ 159.027726] [<ffffffff81392cd9>] tcp_write_timer+0x179/0x1e0
[ 159.027790] [<ffffffff8104fca1>] run_timer_softirq+0x191/0x350
[ 159.027980] [<ffffffff810477ed>] __do_softirq+0xcd/0x200
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
diff --git a/include/net/sock.h b/include/net/sock.h
index 8ab0514..86a8ca1 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -1197,7 +1197,8 @@ static inline struct dst_entry *
__sk_dst_get(struct sock *sk)
{
return rcu_dereference_check(sk->sk_dst_cache, rcu_read_lock_held() ||
- sock_owned_by_user(sk));
+ sock_owned_by_user(sk) ||
+ lockdep_is_held(&sk->sk_lock.slock));
}
static inline struct dst_entry *
^ permalink raw reply related
* Re: DDoS attack causing bad effect on conntrack searches
From: Jesper Dangaard Brouer @ 2010-04-22 21:28 UTC (permalink / raw)
To: Eric Dumazet
Cc: Patrick McHardy, hawk, Linux Kernel Network Hackers,
Netfilter Developers
In-Reply-To: <1271970199.7895.6482.camel@edumazet-laptop>
On Thu, 22 Apr 2010, Eric Dumazet wrote:
> What exact version of kernel are you running ?
2.6.31.7-pvlan2G #3 SMP PREEMPT
32-bit kernel with 2G kernel mem (you showed me that trick).
I have some patches on top (which are accepted upstream), but I originate
from commit f8ebcb2ebc49a Linux 2.6.31.7.
Cheers,
Jesper Brouer
--
-------------------------------------------------------------------
MSc. Master of Computer Science
Dept. of Computer Science, University of Copenhagen
Author of http://www.adsl-optimizer.dk
-------------------------------------------------------------------
^ permalink raw reply
* Re: [net-next PATCH 1/2] add iovnl netlink support
From: Scott Feldman @ 2010-04-22 21:23 UTC (permalink / raw)
To: David Miller; +Cc: netdev, chrisw
In-Reply-To: <20100421.234849.51685723.davem@davemloft.net>
On 4/21/10 11:48 PM, "David Miller" <davem@davemloft.net> wrote:
> From: Scott Feldman <scofeldm@cisco.com>
> Date: Mon, 19 Apr 2010 12:18:07 -0700
>
>> +#define IOVNL_PROTO_VERSION 1
>> +
>
> Please delete this in the final version, the macro isn't even used by
> the code.
>
> We don't do protocol versioning in netlink. Instead we get the base
> stuff solid from the beginning, and then if something needs fixing up
> we handle this using new attributes in a way which is both backward
> and forward compatible.
Sounds good to me, was a cut-and-paste from dcbnl.h. How about:
diff --git a/include/linux/dcbnl.h b/include/linux/dcbnl.h
index b7cdbb4..8723491 100644
--- a/include/linux/dcbnl.h
+++ b/include/linux/dcbnl.h
@@ -22,8 +22,6 @@
#include <linux/types.h>
-#define DCB_PROTO_VERSION 1
-
struct dcbmsg {
__u8 dcb_family;
__u8 cmd;
-scott
^ permalink raw reply related
* Re: [PATCH] NIU support for skb->rxhash
From: David Miller @ 2010-04-22 21:19 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1271936598.7895.5304.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 22 Apr 2010 13:43:18 +0200
> Then, our stack also touch all 256 bytes of skb structure itself.
>
> offsetof(struct sk_buff, next) =0x0
> offsetof(struct sk_buff, rxhash) =0xa8
> offsetof(struct sk_buff, dev) =0x20
> offsetof(struct sk_buff, len) =0x68
> offsetof(struct sk_buff, protocol)=0x7e
> offsetof(struct sk_buff, network_header)=0xc0
> offsetof(struct sk_buff, data) =0xd8
> offsetof(struct sk_buff, head) =0xd0
>
> Time for a reordering I guess ;)
Indeed.
Also I have some ideas about what we can do if we have
just the rxhash. It seems we can avoid the type_trans
overhead on the interrupting cpu.
Things like eth_type_trans() become a netdev operation rather than
something drivers statically call by hand. ->ndo_type_trans or
similar.
SKB has a state bit saying whether ->ndo_type_trans has been invoked
yet on RX.
Drivers pass raw SKBs up into the stack.
We defer the ->ndo_type_trans as far as possible, for RPS when we have
->rxhash we can defer this all the way to the destination RPS cpu.
If we lack ->rxhash, the source cpu will need to invoke
->ndo_type_trans before it can begin parsing the packet.
Anyways, something like that.
^ 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