* Re: [PATCH] iproute: "ip mroute show" doesn't show all output interfaces
From: Stephen Hemminger @ 2009-12-02 0:16 UTC (permalink / raw)
To: Andreas Henriksson; +Cc: netdev, Mark Borst
In-Reply-To: <20091123095231.GA14210@amd64.fatal.se>
On Mon, 23 Nov 2009 10:52:31 +0100
Andreas Henriksson <andreas@fatal.se> wrote:
> From: Mark Borst <mark@borst.org>
>
> The command "ip mroute show" will only show the first Oif.
>
> mark@flappie:~$ ip mroute show
> (192.168.1.1, 224.0.0.123) Iif: _rename Oifs: eth1
>
> mark@flappie:~$ cat /proc/net/ip_mr_cache
> Group Origin Iif Pkts Bytes Wrong Oifs
> 7B0000E0 0101A8C0 2 0 0 0 0:1 1:1
>
> This shows 2 Oifs here. However, ipmroute.c, function read_mroute_list(), uses sscanf() with a %s mask for oiflist, which stops after the first whitespace (i.e. after Oif 0:1). The patch below fixes this to read until the newline (though I'm not sure whether this is the proper way to fix it).
>
> After this patch:
> mark@flappie:~/iproute-20090324/ip$ ./ip mroute show
> (192.168.1.1, 224.0.0.123) Iif: _rename Oifs: eth1 eth0
>
>
> This patch originally submitted as http://bugs.debian.org/550097
>
> Signed-off-by: Andreas Henriksson <andreas@fatal.se>
Applied with small modification, sscanf... %u%[^\n] would not
skip leading whitespace like the original %u%s but adding a blank
in the format will correct that.
--
^ permalink raw reply
* Re: [PATCH] ipv6: Add IFA_F_DADFAILED flag
From: Stephen Hemminger @ 2009-12-02 0:01 UTC (permalink / raw)
To: Brian Haley
Cc: Jens Rosenboom, david Miller, netdev@vger.kernel.org,
YOSHIFUJI Hideaki
In-Reply-To: <4AA9500E.8020309@hp.com>
On Thu, 10 Sep 2009 15:14:22 -0400
Brian Haley <brian.haley@hp.com> wrote:
> Hi Jens,
>
> Jens Rosenboom wrote:
> >> Ok, how does this look? I changed it to set the tentative flag as it did
> >> before, plus clear the dad_failed flag if the device got restarted,
> >> triggering DAD to happen again for any tentative address, that was an
> >> oversight on my part.
> >
> > Looks fine to me so far, can you also send the patch for userspace? That
> > would making testing this a bit easier. ;-)
>
> Iproute2 patch below, I'll re-post both once you have a chance to test.
>
> >> I'd still like to know if using this last ifa_flag is going to be an issue,
> >> I actually finished a similar patch that uses a new IFA_ADDRFLAGS structure
> >> to pass in/out this additional info.
> >
> > IMHO you should stick to this version, if any future feature needs
> > another bit, it may happen also to need two of them and so will need a
> > new structure then anyway, but why not keep it simple for now?
>
> I'll leave it for now, I might just post as an RFC to get some feedback on it.
>
> Thanks,
>
> -Brian
>
>
> diff --git a/include/linux/if_addr.h b/include/linux/if_addr.h
> index a60c821..fd97404 100644
> --- a/include/linux/if_addr.h
> +++ b/include/linux/if_addr.h
> @@ -41,6 +41,7 @@ enum
>
> #define IFA_F_NODAD 0x02
> #define IFA_F_OPTIMISTIC 0x04
> +#define IFA_F_DADFAILED 0x08
> #define IFA_F_HOMEADDRESS 0x10
> #define IFA_F_DEPRECATED 0x20
> #define IFA_F_TENTATIVE 0x40
> diff --git a/ip/ipaddress.c b/ip/ipaddress.c
> index 267ecb3..97c7a8b 100644
> --- a/ip/ipaddress.c
> +++ b/ip/ipaddress.c
> @@ -508,6 +508,10 @@ int print_addrinfo(const struct sockaddr_nl *who, struct nlmsghdr *n,
> fprintf(fp, "dynamic ");
> } else
> ifa->ifa_flags &= ~IFA_F_PERMANENT;
> + if (ifa->ifa_flags&IFA_F_DADFAILED) {
> + ifa->ifa_flags &= ~IFA_F_DADFAILED;
> + fprintf(fp, "dadfailed ");
> + }
> if (ifa->ifa_flags)
> fprintf(fp, "flags %02x ", ifa->ifa_flags);
> if (rta_tb[IFA_LABEL])
Applied to iproute (for 2.6.32) with original message changelog
^ permalink raw reply
* Re: [PATCH] iproute2: Add ll_index_to_addr function
From: Stephen Hemminger @ 2009-12-01 23:54 UTC (permalink / raw)
To: David Ward; +Cc: netdev, David Ward
In-Reply-To: <1255632793-17779-1-git-send-email-david.ward@ll.mit.edu>
On Thu, 15 Oct 2009 14:53:13 -0400
David Ward <david.ward@ll.mit.edu> wrote:
> After calling ll_init_map, all of the information stored in the link-layer map
> can be retrieved by function calls (ll_index_to_*), except for the link-layer
> address. This patch fills the gap by adding a ll_index_to_addr function.
> Changes welcome.
>
> Signed-off-by: David Ward <david.ward@ll.mit.edu>
> ---
applied, thanks
--
^ permalink raw reply
* Re: Bridge + Conntrack + SKB Recycle: Fragment Reassembly Errors
From: David Miller @ 2009-12-01 23:54 UTC (permalink / raw)
To: kaber; +Cc: ben, netdev
In-Reply-To: <4B154337.8060702@trash.net>
From: Patrick McHardy <kaber@trash.net>
Date: Tue, 01 Dec 2009 17:24:23 +0100
> Dave, attached is the patch again with a proper changelog.
Applied to net-2.6, thanks a lot everyone.
I'll queue this up for -stable as well.
^ permalink raw reply
* Re: [PATCH] iproute2 add hoplimit parsing and update usage and documentation
From: Stephen Hemminger @ 2009-12-01 23:53 UTC (permalink / raw)
To: Gilad Ben-Yossef; +Cc: netdev, Ori Finkelman, Andreas Henriksson
In-Reply-To: <1254836434.544524.27946.nullmailer@watson.codefidence.com>
On Tue, 06 Oct 2009 15:40:34 +0200
Gilad Ben-Yossef <gilad@codefidence.com> wrote:
> diff --git a/ip/iproute.c b/ip/iproute.c
> index bf0f31b..aeea93d 100644
> --- a/ip/iproute.c
> +++ b/ip/iproute.c
> @@ -13,6 +13,8 @@
> *
> * Rani Assaf <rani@magic.metawire.com> 980929: resolve addresses
> * Kunihiro Ishiguro <kunihiro@zebra.org> 001102: rtnh_ifindex was not initialized
> + * Gilad Ben-Yossef <gilad@codefidence.com> 091006: Add hoplimit option parsing
> + * and correct usage
> */
>
Applied except I removed the comment changelogs from all of iproute now
to discourage individual source attribution. The contributor information
exists in the git data.
--
^ permalink raw reply
* Re: [PATCH] crypto: gmac - Add RFC4543 wrapper for GCM
From: David Miller @ 2009-12-01 23:51 UTC (permalink / raw)
To: tobias; +Cc: herbert, netdev, linux-crypto
In-Reply-To: <4B154918.7070008@strongswan.org>
From: Tobias Brunner <tobias@strongswan.org>
Date: Tue, 01 Dec 2009 17:49:28 +0100
> This patch adds the RFC4543 (GMAC) wrapper for GCM similar to the
> existing RFC4106 wrapper. The main differences between GCM and GMAC are
> the contents of the AAD and that the plaintext is empty for the latter.
>
> Signed-off-by: Tobias Brunner <tobias@strongswan.org>
Herbert, you got this one?
Thanks.
^ permalink raw reply
* Re: [PATCH] iproute2: Support 20-byte link layer address in idxmap
From: Stephen Hemminger @ 2009-12-01 23:42 UTC (permalink / raw)
To: David Ward; +Cc: netdev, David Ward
In-Reply-To: <1255632801-17802-1-git-send-email-david.ward@ll.mit.edu>
On Thu, 15 Oct 2009 14:53:21 -0400
David Ward <david.ward@ll.mit.edu> wrote:
> Extend the link-layer address field from 8 to 20 bytes to support InfiniBand.
>
> Signed-off-by: David Ward <david.ward@ll.mit.edu>
> ---
> lib/ll_map.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/lib/ll_map.c b/lib/ll_map.c
> index 7c0bea2..5addf4a 100644
> --- a/lib/ll_map.c
> +++ b/lib/ll_map.c
> @@ -31,7 +31,7 @@ struct idxmap
> int type;
> int alen;
> unsigned flags;
> - unsigned char addr[8];
> + unsigned char addr[20];
> char name[16];
> };
>
makes sense applied
--
^ permalink raw reply
* Re: [Bugme-new] [Bug 14702] New: via_rhine: Extremaly drop speed after days of work
From: Andrew Morton @ 2009-12-01 23:38 UTC (permalink / raw)
To: Roger Luethi; +Cc: bugzilla-daemon, bbugme-daemon, netdev, rom_as
In-Reply-To: <bug-14702-10286@http.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Fri, 27 Nov 2009 19:42:39 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=14702
>
> Summary: via_rhine: Extremaly drop speed after days of work
> Product: Drivers
> Version: 2.5
> Kernel Version: 2.6.29-2.6.30
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: high
> Priority: P1
> Component: Network
> AssignedTo: drivers_network@kernel-bugs.osdl.org
> ReportedBy: rom_as@oscada.org
> Regression: No
>
>
> Hardware is embeded device LP-8781 which have two identical VIA Rhine III
> cards:
> [root@localhost ~]# lspci
> 00:01.0 Host bridge: Advanced Micro Devices [AMD] CS5536 [Geode companion] Host
> Bridge (rev 33)
> 00:01.1 VGA compatible controller: Advanced Micro Devices [AMD] Geode LX Video
> 00:01.2 Entertainment encryption device: Advanced Micro Devices [AMD] Geode LX
> AES Security Block
> 00:0c.0 Ethernet controller: VIA Technologies, Inc. VT6105/VT6106S [Rhine-III]
> (rev 86)
> 00:0d.0 Ethernet controller: VIA Technologies, Inc. VT6105/VT6106S [Rhine-III]
> (rev 86)
> 00:0e.0 ISA bridge: Integrated Technology Express, Inc. IT8888F/G PCI to ISA
> Bridge with SMB [Golden Gate] (rev 03)
> 00:0f.0 ISA bridge: Advanced Micro Devices [AMD] CS5536 [Geode companion] ISA
> (rev 03)
> 00:0f.2 IDE interface: Advanced Micro Devices [AMD] CS5536 [Geode companion]
> IDE (rev 01)
> 00:0f.4 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode companion]
> OHC (rev 02)
> 00:0f.5 USB Controller: Advanced Micro Devices [AMD] CS5536 [Geode companion]
> EHC (rev 02)
>
> via_rhine driver loaded correct and work some days fine but for next it drop
> speed to x10. No errors into logs and dmesg present, no one attribute for it
> reason detection.
> Problem is fixed only after call command service network restart and to next
> case time. If through interface going regular data then this problem repeated
> often.
>
> Like problem is public here: https://bugzilla.redhat.com/show_bug.cgi?id=129304
>
> And this problem had real fix only from use rhinefet driver from VIA. For build
> this module on last kernels created patch:
> http://wiki.oscada.org/Doc/ICPDAS/files?get=build_2.6.29.patch
>
^ permalink raw reply
* Re: [patch][ipsec] can not add camellia cipher algorithm when using "ip xfrm state" command
From: David Miller @ 2009-12-01 23:35 UTC (permalink / raw)
To: lyw; +Cc: netdev-owner, netdev
In-Reply-To: <4B132251.5060806@cn.fujitsu.com>
From: Li Yewang <lyw@cn.fujitsu.com>
Date: Mon, 30 Nov 2009 09:39:29 +0800
> can not add camellia cipher algorithm when using "ip xfrm state" command.
>
> Signed-off-by: Li Yewang <lyw@cn.fujitsu.com>
Applied, thank you very much.
^ permalink raw reply
* Re: warning: massive change to conditional coding style in net?
From: David Miller @ 2009-12-01 23:28 UTC (permalink / raw)
To: william.allen.simpson; +Cc: linux-kernel, netdev
In-Reply-To: <4B1558D8.4010804@gmail.com>
From: William Allen Simpson <william.allen.simpson@gmail.com>
Date: Tue, 01 Dec 2009 12:56:40 -0500
> Heck, changes to comments!
Comments help people understand your code. Long after you're gone and
no longer around, other people will need to read your code, maintain
it, and fix bugs in it.
That's why well written and properly formatted comments are important.
Again, nobody is picking on your specifically, everyone goes through
this review process. What is unique about you is that you're the only
one who throws rotten tomatoes back at the reviewers instead of simply
fixing up your patch set and resubmitting.
If the changes requested are so simple and trivial, then it should
take you but a few minutes to respin your patches with the fixes
included.
It definitely takes you more effort to write all of these angry
emails, but how you spend your time is your choice.
^ permalink raw reply
* Re: [RFC] sk_nulls_next_rcu
From: Arnaldo Carvalho de Melo @ 2009-12-01 0:59 UTC (permalink / raw)
To: Octavian Purdila; +Cc: netdev
In-Reply-To: <200912010219.29340.opurdila@ixiacom.com>
Em Tue, Dec 01, 2009 at 02:19:29AM +0200, Octavian Purdila escreveu:
>
> I am trying to convert the LLC code to RCU, and it appears that for proc
> support a sk_nulls_next_rcu would be required.
I find it amusing, and give you a carte blanche on that! :-)
- Arnaldo
^ permalink raw reply
* Re: [PATCH net-next-2.6] bonding: allow arp_ip_targets to be on a separate vlan from bond device
From: Andy Gospodarek @ 2009-12-01 23:07 UTC (permalink / raw)
To: Jay Vosburgh; +Cc: netdev
In-Reply-To: <21331.1259702893@death.nxdomain.ibm.com>
On Tue, Dec 01, 2009 at 01:28:13PM -0800, Jay Vosburgh wrote:
> Andy Gospodarek <andy@greyhouse.net> wrote:
> [...]
> >I am using arp_validate, actually. I forgot that the arp_validate
> >option doesn't show up in the output of /proc/net/bonding/bondX and I
> >intended to have that in the subject, but somehow dropped it.
>
> Ok, I was doing it wrong earlier; it works with arp_validate.
> I'm seeing one problem with tcpdump, though, which I'll get to in a
> minute.
>
> Could you update the summary / changelog message to mention that
> this patch fixes the specific case of arp_validate + arp_ip_target on
> VLAN?
>
Yep, I would be glad to do that.
> Second, in regards to this:
>
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -2439,8 +2439,8 @@ int netif_receive_skb(struct sk_buff *skb)
> skb->skb_iif = skb->dev->ifindex;
>
> null_or_orig = NULL;
> - orig_dev = skb->dev;
> - if (orig_dev->master) {
> + orig_dev = __dev_get_by_index(dev_net(skb->dev),skb->skb_iif);
> + if (orig_dev->master && !(skb->dev->priv_flags & IFF_802_1Q_VLAN)) {
> if (skb_bond_should_drop(skb))
> null_or_orig = orig_dev; /* deliver only exact match */
> else
>
> Would it be useful to add a comment to the effect that VLAN
> packets are run through skb_bond_should_drop at the VLAN layer?
>
> Lastly, in regards to this:
>
> @@ -2492,7 +2492,7 @@ ncls:
> &ptype_base[ntohs(type) & PTYPE_HASH_MASK], list) {
> if (ptype->type == type &&
> (ptype->dev == null_or_orig || ptype->dev == skb->dev ||
> - ptype->dev == orig_dev)) {
> + ptype->dev == orig_dev || ptype->dev == orig_dev->master)) {
> if (pt_prev)
> ret = deliver_skb(skb, pt_prev, orig_dev);
> pt_prev = ptype;
>
> This is presumably here because orig_dev will now be the actual
> slave the packet arrived on, but we want to additionally deliver to the
> master, correct?
Yes, that is exactly right.
>
> Lastly, tcpdump.
>
> This patch appears to affect what traffic tcpdump of a slave or
> the bonding master itself will capture. Previously, tcpdump of the
> active slave would see only the transmitted packets sent over the bond,
> and tcpdump of the inactive slave would see incoming Ethernet-layer
> multicast or broadcasts sent to its switch port. Tcpdump on the master
> would see all sent and non-VLAN received traffic, and tcpdump of the
> VLAN interface over the master would see just the VLAN traffic.
>
> After this change, tcpdump of the active slave or of the bonding
> master (bond0) sees both sent and received traffic for the VLAN, but
> nothing for the non-VLAN traffic other than incoming broadcast /
> multicasts. This holds true whether or not a VLAN is configured.
>
> I added a "ptype->dev == orig_dev->master" test to the ptype_all
> receive block in netif_receive_skb, but it didn't help. At the moment,
> I'm not exactly sure why tcpdump breaks.
>
This is interesting; I'll investigate.
> -J
>
> ---
> -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [patch 1/2] net/ps3: Cleanup gelic enums
From: Geoff Levand @ 2009-12-01 22:15 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, cbe-oss-dev@ozlabs.org
Cleanup of the gelic driver enumerations:
o Add some missing commas.
o Add an Ether port post fix (PS3 currently only supports PORT_0).
o Add a new enum gelic_lv1_phy to use when interacting with the PHY.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
Hi Jeff,
This patch does some cleanup needed by the 2nd patch
[patch 2/2] net/ps3: Add support for gelic link negotiation.
Please apply for 2.3.33.
-Geoff
drivers/net/ps3_gelic_net.c | 26 +++++++++++++-------------
drivers/net/ps3_gelic_net.h | 19 ++++++++++++-------
2 files changed, 25 insertions(+), 20 deletions(-)
--- a/drivers/net/ps3_gelic_net.c
+++ b/drivers/net/ps3_gelic_net.c
@@ -95,11 +95,11 @@ static void gelic_card_get_ether_port_st
lv1_net_control(bus_id(card), dev_id(card),
GELIC_LV1_GET_ETH_PORT_STATUS,
- GELIC_LV1_VLAN_TX_ETHERNET, 0, 0,
+ GELIC_LV1_VLAN_TX_ETHERNET_0, 0, 0,
&card->ether_port_status, &v2);
if (inform) {
- ether_netdev = card->netdev[GELIC_PORT_ETHERNET];
+ ether_netdev = card->netdev[GELIC_PORT_ETHERNET_0];
if (card->ether_port_status & GELIC_LV1_ETHER_LINK_UP)
netif_carrier_on(ether_netdev);
else
@@ -451,14 +451,14 @@ static void gelic_descr_release_tx(struc
static void gelic_card_stop_queues(struct gelic_card *card)
{
- netif_stop_queue(card->netdev[GELIC_PORT_ETHERNET]);
+ netif_stop_queue(card->netdev[GELIC_PORT_ETHERNET_0]);
if (card->netdev[GELIC_PORT_WIRELESS])
netif_stop_queue(card->netdev[GELIC_PORT_WIRELESS]);
}
static void gelic_card_wake_queues(struct gelic_card *card)
{
- netif_wake_queue(card->netdev[GELIC_PORT_ETHERNET]);
+ netif_wake_queue(card->netdev[GELIC_PORT_ETHERNET_0]);
if (card->netdev[GELIC_PORT_WIRELESS])
netif_wake_queue(card->netdev[GELIC_PORT_WIRELESS]);
@@ -999,7 +999,7 @@ static int gelic_card_decode_one_descr(s
goto refill;
}
} else
- netdev = card->netdev[GELIC_PORT_ETHERNET];
+ netdev = card->netdev[GELIC_PORT_ETHERNET_0];
if ((status == GELIC_DESCR_DMA_RESPONSE_ERROR) ||
(status == GELIC_DESCR_DMA_PROTECTION_ERROR) ||
@@ -1369,7 +1369,7 @@ static void gelic_net_tx_timeout_task(st
{
struct gelic_card *card =
container_of(work, struct gelic_card, tx_timeout_task);
- struct net_device *netdev = card->netdev[GELIC_PORT_ETHERNET];
+ struct net_device *netdev = card->netdev[GELIC_PORT_ETHERNET_0];
dev_info(ctodev(card), "%s:Timed out. Restarting... \n", __func__);
@@ -1531,10 +1531,10 @@ static struct gelic_card * __devinit gel
/* gelic_port */
port->netdev = *netdev;
port->card = card;
- port->type = GELIC_PORT_ETHERNET;
+ port->type = GELIC_PORT_ETHERNET_0;
/* gelic_card */
- card->netdev[GELIC_PORT_ETHERNET] = *netdev;
+ card->netdev[GELIC_PORT_ETHERNET_0] = *netdev;
INIT_WORK(&card->tx_timeout_task, gelic_net_tx_timeout_task);
init_waitqueue_head(&card->waitq);
@@ -1554,9 +1554,9 @@ static void __devinit gelic_card_get_vla
int tx;
int rx;
} vlan_id_ix[2] = {
- [GELIC_PORT_ETHERNET] = {
- .tx = GELIC_LV1_VLAN_TX_ETHERNET,
- .rx = GELIC_LV1_VLAN_RX_ETHERNET
+ [GELIC_PORT_ETHERNET_0] = {
+ .tx = GELIC_LV1_VLAN_TX_ETHERNET_0,
+ .rx = GELIC_LV1_VLAN_RX_ETHERNET_0
},
[GELIC_PORT_WIRELESS] = {
.tx = GELIC_LV1_VLAN_TX_WIRELESS,
@@ -1601,7 +1601,7 @@ static void __devinit gelic_card_get_vla
i, card->vlan[i].tx, card->vlan[i].rx);
}
- if (card->vlan[GELIC_PORT_ETHERNET].tx) {
+ if (card->vlan[GELIC_PORT_ETHERNET_0].tx) {
BUG_ON(!card->vlan[GELIC_PORT_WIRELESS].tx);
card->vlan_required = 1;
} else
@@ -1790,7 +1790,7 @@ static int ps3_gelic_driver_remove(struc
gelic_card_free_chain(card, card->tx_top);
gelic_card_free_chain(card, card->rx_top);
- netdev0 = card->netdev[GELIC_PORT_ETHERNET];
+ netdev0 = card->netdev[GELIC_PORT_ETHERNET_0];
/* disconnect event port */
free_irq(card->irq, card);
netdev0->irq = NO_IRQ;
--- a/drivers/net/ps3_gelic_net.h
+++ b/drivers/net/ps3_gelic_net.h
@@ -186,7 +186,7 @@ enum gelic_lv1_net_control_code {
GELIC_LV1_GET_CHANNEL = 6,
GELIC_LV1_POST_WLAN_CMD = 9,
GELIC_LV1_GET_WLAN_CMD_RESULT = 10,
- GELIC_LV1_GET_WLAN_EVENT = 11
+ GELIC_LV1_GET_WLAN_EVENT = 11,
};
/* for GELIC_LV1_SET_WOL */
@@ -217,24 +217,29 @@ enum gelic_lv1_ether_port_status {
GELIC_LV1_ETHER_SPEED_10 = 0x0000000000000010L,
GELIC_LV1_ETHER_SPEED_100 = 0x0000000000000020L,
GELIC_LV1_ETHER_SPEED_1000 = 0x0000000000000040L,
- GELIC_LV1_ETHER_SPEED_MASK = 0x0000000000000070L
+ GELIC_LV1_ETHER_SPEED_MASK = 0x0000000000000070L,
};
enum gelic_lv1_vlan_index {
/* for outgoing packets */
- GELIC_LV1_VLAN_TX_ETHERNET = 0x0000000000000002L,
+ GELIC_LV1_VLAN_TX_ETHERNET_0 = 0x0000000000000002L,
GELIC_LV1_VLAN_TX_WIRELESS = 0x0000000000000003L,
+
/* for incoming packets */
- GELIC_LV1_VLAN_RX_ETHERNET = 0x0000000000000012L,
- GELIC_LV1_VLAN_RX_WIRELESS = 0x0000000000000013L
+ GELIC_LV1_VLAN_RX_ETHERNET_0 = 0x0000000000000012L,
+ GELIC_LV1_VLAN_RX_WIRELESS = 0x0000000000000013L,
+};
+
+enum gelic_lv1_phy {
+ GELIC_LV1_PHY_ETHERNET_0 = 0x0000000000000002L,
};
/* size of hardware part of gelic descriptor */
#define GELIC_DESCR_SIZE (32)
enum gelic_port_type {
- GELIC_PORT_ETHERNET = 0,
- GELIC_PORT_WIRELESS = 1,
+ GELIC_PORT_ETHERNET_0 = 0,
+ GELIC_PORT_WIRELESS = 1,
GELIC_PORT_MAX
};
^ permalink raw reply
* [patch 2/2] net/ps3: Add support for gelic link negotiation
From: Geoff Levand @ 2009-12-01 22:15 UTC (permalink / raw)
To: jgarzik; +Cc: netdev, cbe-oss-dev@ozlabs.org
From: Hideyuki Sasaki <Hideyuki_Sasaki@hq.scei.sony.co.jp>
Add ethtool_ops.set_settings support to the PS3 gelic network driver.
Allows manual setting of ethernet link speed.
Signed-off-by: Hideyuki Sasaki <xhide@rd.scei.sony.co.jp>
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
---
drivers/net/ps3_gelic_net.c | 72 ++++++++++++++++++++++++++++++++++++++++++--
drivers/net/ps3_gelic_net.h | 2 +
2 files changed, 72 insertions(+), 2 deletions(-)
--- a/drivers/net/ps3_gelic_net.c
+++ b/drivers/net/ps3_gelic_net.c
@@ -107,6 +107,24 @@ static void gelic_card_get_ether_port_st
}
}
+static int gelic_card_set_link_mode(struct gelic_card *card, int mode)
+{
+ int status;
+ u64 v1, v2;
+
+ status = lv1_net_control(bus_id(card), dev_id(card),
+ GELIC_LV1_SET_NEGOTIATION_MODE,
+ GELIC_LV1_PHY_ETHERNET_0, mode, 0, &v1, &v2);
+ if (status) {
+ pr_info("%s: failed setting negotiation mode %d\n", __func__,
+ status);
+ return -EBUSY;
+ }
+
+ card->link_mode = mode;
+ return 0;
+}
+
void gelic_card_up(struct gelic_card *card)
{
pr_debug("%s: called\n", __func__);
@@ -1244,14 +1262,58 @@ static int gelic_ether_get_settings(stru
cmd->supported = SUPPORTED_TP | SUPPORTED_Autoneg |
SUPPORTED_10baseT_Half | SUPPORTED_10baseT_Full |
SUPPORTED_100baseT_Half | SUPPORTED_100baseT_Full |
- SUPPORTED_1000baseT_Half | SUPPORTED_1000baseT_Full;
+ SUPPORTED_1000baseT_Full;
cmd->advertising = cmd->supported;
- cmd->autoneg = AUTONEG_ENABLE; /* always enabled */
+ if (card->link_mode & GELIC_LV1_ETHER_AUTO_NEG) {
+ cmd->autoneg = AUTONEG_ENABLE;
+ } else {
+ cmd->autoneg = AUTONEG_DISABLE;
+ cmd->advertising &= ~ADVERTISED_Autoneg;
+ }
cmd->port = PORT_TP;
return 0;
}
+static int gelic_ether_set_settings(struct net_device *netdev,
+ struct ethtool_cmd *cmd)
+{
+ struct gelic_card *card = netdev_card(netdev);
+ u64 mode;
+ int ret;
+
+ if (cmd->autoneg == AUTONEG_ENABLE) {
+ mode = GELIC_LV1_ETHER_AUTO_NEG;
+ } else {
+ switch (cmd->speed) {
+ case SPEED_10:
+ mode = GELIC_LV1_ETHER_SPEED_10;
+ break;
+ case SPEED_100:
+ mode = GELIC_LV1_ETHER_SPEED_100;
+ break;
+ case SPEED_1000:
+ mode = GELIC_LV1_ETHER_SPEED_1000;
+ break;
+ default:
+ return -EINVAL;
+ }
+ if (cmd->duplex == DUPLEX_FULL)
+ mode |= GELIC_LV1_ETHER_FULL_DUPLEX;
+ else if (cmd->speed == SPEED_1000) {
+ pr_info("1000 half duplex is not supported.\n");
+ return -EINVAL;
+ }
+ }
+
+ ret = gelic_card_set_link_mode(card, mode);
+
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
u32 gelic_net_get_rx_csum(struct net_device *netdev)
{
struct gelic_card *card = netdev_card(netdev);
@@ -1349,6 +1411,7 @@ done:
static const struct ethtool_ops gelic_ether_ethtool_ops = {
.get_drvinfo = gelic_net_get_drvinfo,
.get_settings = gelic_ether_get_settings,
+ .set_settings = gelic_ether_set_settings,
.get_link = ethtool_op_get_link,
.get_tx_csum = ethtool_op_get_tx_csum,
.set_tx_csum = ethtool_op_set_tx_csum,
@@ -1657,6 +1720,8 @@ static int __devinit ps3_gelic_driver_pr
/* get internal vlan info */
gelic_card_get_vlan_info(card);
+ card->link_mode = GELIC_LV1_ETHER_AUTO_NEG;
+
/* setup interrupt */
result = lv1_net_set_interrupt_status_indicator(bus_id(card),
dev_id(card),
@@ -1773,6 +1838,9 @@ static int ps3_gelic_driver_remove(struc
struct net_device *netdev0;
pr_debug("%s: called\n", __func__);
+ /* set auto-negotiation */
+ gelic_card_set_link_mode(card, GELIC_LV1_ETHER_AUTO_NEG);
+
#ifdef CONFIG_GELIC_WIRELESS
gelic_wl_driver_remove(card);
#endif
--- a/drivers/net/ps3_gelic_net.h
+++ b/drivers/net/ps3_gelic_net.h
@@ -307,6 +307,8 @@ struct gelic_card {
atomic_t users;
u64 ether_port_status;
+ int link_mode;
+
/* original address returned by kzalloc */
void *unalign;
^ permalink raw reply
* Re: [linux-pm] intermittent suspend problem again
From: Rafael J. Wysocki @ 2009-12-01 21:32 UTC (permalink / raw)
To: Ferenc Wagner; +Cc: linux-pm, Andrew Morton, LKML, netdev
In-Reply-To: <877ht68u4h.fsf@tac.ki.iif.hu>
On Tuesday 01 December 2009, Ferenc Wagner wrote:
> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
>
> > On Tuesday 01 December 2009, Ferenc Wagner wrote:
> >> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> >>
> >>> On Sunday 29 November 2009, Ferenc Wagner wrote:
> >>>
> >>>> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> >>>>
> >>>>> On Saturday 28 November 2009, Ferenc Wagner wrote:
> >>>>>
> >>>>>> "Rafael J. Wysocki" <rjw@sisk.pl> writes:
> >>>>>>
> >>>>>>> Compile with CONFIG_PM_VERBOSE (it does mean exactly that).
> >>>>>>
> >>>>>> The last message now was:
> >>>>>>
> >>>>>> e100: 0000:02:08.0: hibernate, may wakeup
> >>>>>>
> >>>>>> Looks like hibernating the e100 driver is unstable.
> >>>>>
> >>>>> Can you verify that by trying to hibernate without the e100 driver?
> >>>>
> >>>> Not really, as I still can't reliable reproduce the issue. Since I'm
> >>>> running with suspend loglevel = 8, it's happened only twice (in a row),
> >>>> with seemingly exact same console output. Some earlier freezes also
> >>>> happened in dpm_suspend_start, at least. However, I can certainly add
> >>>> e100 to SUSPEND_MODULES under /etc/pm/config.d, and continue running
> >>>> with that.
> >>>
> >>> That's what I'd do.
> >>
> >> That worked out mosty OK (no freeze in quite some hibernation cycles),
> >> but I'm continuing testing it.
> >
> > Great, please let me know how it works out.
>
> Will do. On the negative side, this tends to confuse NetworkManager.
>
> >> On the other hand, I reverted 8fbd962e3, recompiled and replaced the
> >> module, and got the freeze during hibernation. And that was the bulk of
> >> the changes since 2.6.31... I'll revert the rest and test again, but
> >> that seems purely cosmetic, so no high hopes.
> >>
> >>> In addition to that, you can run multiple hibernation/resume cycles in
> >>> a tight loop using the RTC wakealarm.
> >>
> >> I'll do so, as soon as I find a way to automatically supply the dm-crypt
> >> passphrase... or even better, learn to hibernate to ramdisk from the
> >> initramfs. :)
> >
> > Well, you don't need to use swap encryption for _testing_. :-)
>
> I use partition encryption, everything except for /boot is encrypted.
If /boot is big enough, you could use a swap file in /boot for the testing.
> Apropos: does s2disk perform encryption with a temporary key even if I
> don't supply and RSA key, to protect mlocked application data from being
> present in the swap after restore?
It can do that, but you need to provide a key during suspend and resume.
Otherwise it doesn't use a random key, because it would have to store it in
the clear in the image header.
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH net-next-2.6] bonding: allow arp_ip_targets to be on a separate vlan from bond device
From: Jay Vosburgh @ 2009-12-01 21:28 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: netdev
In-Reply-To: <20091201144410.GI1639@gospo.rdu.redhat.com>
Andy Gospodarek <andy@greyhouse.net> wrote:
[...]
>I am using arp_validate, actually. I forgot that the arp_validate
>option doesn't show up in the output of /proc/net/bonding/bondX and I
>intended to have that in the subject, but somehow dropped it.
Ok, I was doing it wrong earlier; it works with arp_validate.
I'm seeing one problem with tcpdump, though, which I'll get to in a
minute.
Could you update the summary / changelog message to mention that
this patch fixes the specific case of arp_validate + arp_ip_target on
VLAN?
Second, in regards to this:
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2439,8 +2439,8 @@ int netif_receive_skb(struct sk_buff *skb)
skb->skb_iif = skb->dev->ifindex;
null_or_orig = NULL;
- orig_dev = skb->dev;
- if (orig_dev->master) {
+ orig_dev = __dev_get_by_index(dev_net(skb->dev),skb->skb_iif);
+ if (orig_dev->master && !(skb->dev->priv_flags & IFF_802_1Q_VLAN)) {
if (skb_bond_should_drop(skb))
null_or_orig = orig_dev; /* deliver only exact match */
else
Would it be useful to add a comment to the effect that VLAN
packets are run through skb_bond_should_drop at the VLAN layer?
Lastly, in regards to this:
@@ -2492,7 +2492,7 @@ ncls:
&ptype_base[ntohs(type) & PTYPE_HASH_MASK], list) {
if (ptype->type == type &&
(ptype->dev == null_or_orig || ptype->dev == skb->dev ||
- ptype->dev == orig_dev)) {
+ ptype->dev == orig_dev || ptype->dev == orig_dev->master)) {
if (pt_prev)
ret = deliver_skb(skb, pt_prev, orig_dev);
pt_prev = ptype;
This is presumably here because orig_dev will now be the actual
slave the packet arrived on, but we want to additionally deliver to the
master, correct?
Lastly, tcpdump.
This patch appears to affect what traffic tcpdump of a slave or
the bonding master itself will capture. Previously, tcpdump of the
active slave would see only the transmitted packets sent over the bond,
and tcpdump of the inactive slave would see incoming Ethernet-layer
multicast or broadcasts sent to its switch port. Tcpdump on the master
would see all sent and non-VLAN received traffic, and tcpdump of the
VLAN interface over the master would see just the VLAN traffic.
After this change, tcpdump of the active slave or of the bonding
master (bond0) sees both sent and received traffic for the VLAN, but
nothing for the non-VLAN traffic other than incoming broadcast /
multicasts. This holds true whether or not a VLAN is configured.
I added a "ptype->dev == orig_dev->master" test to the ptype_all
receive block in netif_receive_skb, but it didn't help. At the moment,
I'm not exactly sure why tcpdump breaks.
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: scp stalls mysteriously
From: Ilpo Järvinen @ 2009-12-01 20:27 UTC (permalink / raw)
To: Frederic Leroy; +Cc: Netdev, Asdo
In-Reply-To: <20091201211945.505d3c98@houba>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1178 bytes --]
On Tue, 1 Dec 2009, Frederic Leroy wrote:
> Le Mon, 30 Nov 2009 23:37:56 +0200 (EET),
> "Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi> a écrit :
>
> > On Mon, 30 Nov 2009, Frederic Leroy wrote:
> >
> > Could you try btw to disable frto (set tcp_frto sysctl to zero), in
> > theory it could cause zero cwnd if something else is wrong too (I
> > haven't yet read them all through so there might be other places
> > where a zero cwnd can be set). Also I'm interested what happens if
> > you disable timestamps, is the problem still reproducable.
>
> I made 3 new traces and put it in the usual place.
> One with frto set to 0, one just after with frto set to 2.
>
> And the last with timestamp disabled.
>
> All stream has stalled.
Thanks, I'll hopefully have some time tomorrow to go through all the new
ones. In the meantime, can you provide your tso configuration on houba
(ethtool -k dev). If tso is on it might be worth to try without it
(set with -K), however, I don't expect it to change anything. Also,
I wonder if you have had some working (past) kernel version?
No need for additional traces atm, I'll get back to this once I've gone
through the logs.
--
i.
^ permalink raw reply
* Re: scp stalls mysteriously
From: Frederic Leroy @ 2009-12-01 20:19 UTC (permalink / raw)
To: Ilpo Järvinen; +Cc: Netdev, Asdo
In-Reply-To: <alpine.DEB.2.00.0911302244160.9826@melkinpaasi.cs.helsinki.fi>
Le Mon, 30 Nov 2009 23:37:56 +0200 (EET),
"Ilpo Järvinen" <ilpo.jarvinen@helsinki.fi> a écrit :
> On Mon, 30 Nov 2009, Frederic Leroy wrote:
>
> Could you try btw to disable frto (set tcp_frto sysctl to zero), in
> theory it could cause zero cwnd if something else is wrong too (I
> haven't yet read them all through so there might be other places
> where a zero cwnd can be set). Also I'm interested what happens if
> you disable timestamps, is the problem still reproducable.
I made 3 new traces and put it in the usual place.
One with frto set to 0, one just after with frto set to 2.
And the last with timestamp disabled.
All stream has stalled.
--
Frédéric Leroy
^ permalink raw reply
* Re: [PATCH] sch_htb: ix the deficit overflows
From: Jarek Poplawski @ 2009-12-01 19:18 UTC (permalink / raw)
To: Changli Gao; +Cc: Jamal Hadi Salim, David S. Miller, netdev, Martin Devera
In-Reply-To: <4B156A94.9030409@gmail.com>
Jarek Poplawski wrote, On 12/01/2009 08:12 PM:
> So, as I wrote before, your proposal based on the first variant is
> acceptable to me, but please reconsider the second idea too, e.g.
> done like this:
>
> }
> /* this used to be after charge_class but this constelation
> gives us slightly better performance */
> if (!cl->un.leaf.q->q.qlen) {
> htb_deactivate(q, cl);
> + if (unlikely(cl->un.leaf.deficit[level] < cl->quantum)) {
Should be:
+ if (unlikely(cl->un.leaf.deficit[level] < -cl->quantum)) {
Jarek P.
> + { a warning }
> + cl->un.leaf.deficit[level] = 0;
> + }
> }
> htb_charge_class(q, cl, level, skb);
> }
> return skb;
> }
>
^ permalink raw reply
* Re: [PATCH] sch_htb: ix the deficit overflows
From: Jarek Poplawski @ 2009-12-01 19:12 UTC (permalink / raw)
To: Changli Gao; +Cc: Jamal Hadi Salim, David S. Miller, netdev, Martin Devera
In-Reply-To: <20091201084332.GB6408@ff.dom.local>
Jarek Poplawski wrote, On 12/01/2009 09:43 AM:
> And, again, there are less invasive ways to fix such overflow, like
>
> htb_dequeue_tree()
> {
> ...
> if (likely(skb != NULL)) {
> cl->un.leaf.deficit[level] -= qdisc_pkt_len(skb);
> if (cl->un.leaf.deficit[level] < 0) {
> cl->un.leaf.deficit[level] += cl->quantum;
>
> + if (cl->un.leaf.deficit[level] < 0)
> + cl->un.leaf.deficit[level] = -cl->quantum;
> + /* or other limit */
>
> htb_next_rb_node((level ? cl->parent->un.inner.ptr : q->
> ptr[0]) + prio);
> }
> /* this used to be after charge_class but this constelation
> gives us slightly better performance */
> if (!cl->un.leaf.q->q.qlen)
> htb_deactivate(q, cl);
> htb_charge_class(q, cl, level, skb);
> }
> return skb;
> }
>
> or even always zeroing cl->un.leaf.deficit[level] on activation or
> deactivation (it's seems unlikely one activity period is enough for
> such an overflow).
So, as I wrote before, your proposal based on the first variant is
acceptable to me, but please reconsider the second idea too, e.g.
done like this:
}
/* this used to be after charge_class but this constelation
gives us slightly better performance */
if (!cl->un.leaf.q->q.qlen) {
htb_deactivate(q, cl);
+ if (unlikely(cl->un.leaf.deficit[level] < cl->quantum)) {
+ { a warning }
+ cl->un.leaf.deficit[level] = 0;
+ }
}
htb_charge_class(q, cl, level, skb);
}
return skb;
}
Jarek P.
^ permalink raw reply
* [PATCH 1/1] net: compat_mmsghdr must be used in sys_recvmmsg
From: Arnaldo Carvalho de Melo @ 2009-12-01 18:47 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Jean-Mickael Guerin, Arnaldo Carvalho de Melo
From: Jean-Mickael Guerin <jean-mickael.guerin@6wind.com>
Both to traverse the entries and to set the msg_len field.
Commiter note: folded two patches and avoided one branch repeating the
compat test.
Signed-off-by: Jean-Mickael Guerin <jean-mickael.guerin@6wind.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
net/socket.c | 24 ++++++++++++++++++------
1 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/net/socket.c b/net/socket.c
index 402abb3..b94c3dd 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -2144,6 +2144,7 @@ int __sys_recvmmsg(int fd, struct mmsghdr __user *mmsg, unsigned int vlen,
int fput_needed, err, datagrams;
struct socket *sock;
struct mmsghdr __user *entry;
+ struct compat_mmsghdr __user *compat_entry;
struct msghdr msg_sys;
struct timespec end_time;
@@ -2163,19 +2164,30 @@ int __sys_recvmmsg(int fd, struct mmsghdr __user *mmsg, unsigned int vlen,
goto out_put;
entry = mmsg;
+ compat_entry = (struct compat_mmsghdr __user *)mmsg;
while (datagrams < vlen) {
/*
* No need to ask LSM for more than the first datagram.
*/
- err = __sys_recvmsg(sock, (struct msghdr __user *)entry,
- &msg_sys, flags, datagrams);
- if (err < 0)
- break;
- err = put_user(err, &entry->msg_len);
+ if (MSG_CMSG_COMPAT & flags) {
+ err = __sys_recvmsg(sock, (struct msghdr __user *)compat_entry,
+ &msg_sys, flags, datagrams);
+ if (err < 0)
+ break;
+ err = __put_user(err, &compat_entry->msg_len);
+ ++compat_entry;
+ } else {
+ err = __sys_recvmsg(sock, (struct msghdr __user *)entry,
+ &msg_sys, flags, datagrams);
+ if (err < 0)
+ break;
+ err = put_user(err, &entry->msg_len);
+ ++entry;
+ }
+
if (err)
break;
- ++entry;
++datagrams;
if (timeout) {
--
1.6.2.5
^ permalink raw reply related
* Re: warning: massive change to conditional coding style in net?
From: Eric Dumazet @ 2009-12-01 18:30 UTC (permalink / raw)
To: William Allen Simpson; +Cc: David Miller, linux-kernel, netdev
In-Reply-To: <4B1558D8.4010804@gmail.com>
William Allen Simpson a écrit :
> If these changes had been mentioned a month or two ago, as part of a
> thorough review, it could have been discussed earlier. Instead, it's
> like being nibbled by mice.
William,
This is absolutely _not_ possible to comment a 1000+ lines patches in one shot,
being your patch or not.
It would take _hours_ of work, even for David.
We use a step-by-step process, with limited feedbacks, because nobody is paid
to make your life easier. We patiently gave you a lot of advices and yet
you complain again and again.
After 15/30 minutes of reviewing patches, and collecting some suggestions,
the average reviewer stops its review, sends a feedback, and waits for next
patch submission. [hoping patch author will be pro_active and check all its
patches, not the precise points that were specificaly raised.]
Yes, sometime we notice a point at round eleven, instead of first/second round,
because more important things were noticed at prior rounds.
I honestly hope you change your mind, or I wont even read your next patch
submissions, wait for the official RFC and code the damn thing myself or wait for
some kind developper willing to do the job, in the normal process.
You can copy this mail to all man kind, it wont make your patches magically
ready for inclusion.
Respectfully,
Eric
^ permalink raw reply
* Re: warning: massive change to conditional coding style in net?
From: William Allen Simpson @ 2009-12-01 17:56 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, netdev
In-Reply-To: <20091130.123644.203668577.davem@davemloft.net>
David Miller wrote:
> William, you're unreasonable.
>
I've waited a day before replying to this message, so that my anger
at your false and misleading statements could be carefully removed.
Maybe you're smiling and genial as you write your responses, but it
comes across as throwing a temper tantrum.
Meantime, I brought this topic to a broader audience to see whether
there was some general consensus that could be documented.
Your personal /ad hominem/ attacks are not appreciated.
> We asked you to follow a certain style, and then you immediately
> complain that the style isn't followed consistently in the tree, and
> therefore as a consequence you shouldn't be required to follow it.
>
Whenever you've asked for an arbitrary and capricious change, I've
pointed to existing code -- not _com_plaining, *ex*plaining.
Before beginning, I read the Documentation. I started with an existing
patch that had already been approved by you during its RFC review, and
carefully followed the existing coding practices.
In each section of code, I've followed its *existing* style. Because
different sections of the code often have different styles, that means
the patch will be cleaner. IMnsHO, clean patches are easier to review.
Where the code section was entirely new, I followed a style that is
well represented in the Linux tree as a whole (and the TCP code in
particular), although it is not a majority style.
> Then Joe comes and submits patches making the tree follow the style
> more consistently. See, instead of merely complaining like you did,
> he proactively did something positive.
>
First of all, this is not *THE* style. Your style is not documented in
CodingStyle. It may be your preference, but there is no agreement, not
even in patches that you've approved and applied in recent months.
Secondly, Joe was not "proactive". You solicited the patches:
http://patchwork.ozlabs.org/patch/39072/
Thirdly, there is disagreement about the "positive" nature. For example:
"Rather than playing with the dangling operator format which seems to
be a coding style that only David cares about...."
http://patchwork.kernel.org/patch/63847/
> Now you're complaining because this makes your patches harder to
> maintain.
>
You betcha! And I'm quite sure I'm not the only contributor impacted.
> Whereas if you had merely fixed up the coding style as I and others
> have asked you, your code would be in my tree weeks ago.
>
NOT TRUE! This was a *recent* request by you, and a change to code
previous Ack'd weeks ago by other reviewers.
Another recent example is initializing a sysctl (present in every patch
for TWO MONTHS) that you've suddenly declared "extremely non-intuitive",
and "doesn't make any sense." As I pointed to the origin in syncookies,
you changed syncookies.... (Andi Kleen, such a bad coder.)
An example from a few iterations ago: you required the "const" be
removed from my inline functions, notwithstanding that EVERY OTHER
FUNCTION in the linux/tcp.h header uses that form. Of course, using
const there is standard C.
Over and over, I've followed existing coding practices. Over and over,
you've thrown roadblocks into the process, since your comment that this
was "some odd-ball feature" back in early October....
Each time I've posted a patch series, one or two usually trivial changes
are requested. Heck, changes to comments!
If these changes had been mentioned a month or two ago, as part of a
thorough review, it could have been discussed earlier. Instead, it's
like being nibbled by mice.
^ permalink raw reply
* [PATCH 1/1] net: compat_sys_recvmmsg user timespec arg can be NULL
From: Arnaldo Carvalho de Melo @ 2009-12-01 17:52 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Jean-Mickael Guerin, Arnaldo Carvalho de Melo
From: Jean-Mickael Guerin <jean-mickael.guerin@6wind.com>
We must test if user timespec is non-NULL before copying from userpace,
same as sys_recvmmsg().
Commiter note: changed it so that we have just one branch.
Signed-off-by: Jean-Mickael Guerin <jean-mickael.guerin@6wind.com>
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
net/compat.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/net/compat.c b/net/compat.c
index 6a2f75f..e1a56ad 100644
--- a/net/compat.c
+++ b/net/compat.c
@@ -758,9 +758,13 @@ asmlinkage long compat_sys_recvmmsg(int fd, struct compat_mmsghdr __user *mmsg,
{
int datagrams;
struct timespec ktspec;
- struct compat_timespec __user *utspec =
- (struct compat_timespec __user *)timeout;
+ struct compat_timespec __user *utspec;
+ if (timeout == NULL)
+ return __sys_recvmmsg(fd, (struct mmsghdr __user *)mmsg, vlen,
+ flags | MSG_CMSG_COMPAT, NULL);
+
+ utspec = (struct compat_timespec __user *)timeout;
if (get_user(ktspec.tv_sec, &utspec->tv_sec) ||
get_user(ktspec.tv_nsec, &utspec->tv_nsec))
return -EFAULT;
--
1.6.2.5
^ permalink raw reply related
* Re: seeing strange values for tcp sk_rmem_alloc
From: Eric Dumazet @ 2009-12-01 17:52 UTC (permalink / raw)
To: Chris Friesen; +Cc: netdev, Linux kernel
In-Reply-To: <4B155252.1040604@nortel.com>
Chris Friesen a écrit :
> I realize this. I sent the data from a socket to itself. It could just
> as easily be done with two tcp sockets. The important thing is that I
> control both the tx and rx sides, so I know how much data should be
> present in the rx queue at any point in time.
>
> The part that surprised me was that I could send multiple chunks of data
> without sk_rmem_alloc changing on the socket to which the data was being
> sent. Then it would jump up by a large amount (up to 20K) all at once.
>
> I'm starting to suspect that the discrepency might have something to do
> with the skb_copy_datagram_iovec() call in tcp_data_queue(), and how
> skb_set_owner_r() is only called if "eaten" is <= 0. This could be
> totally off-base though.
>
If you dont read() your socket, then skb_copy_datagram_iovec() is not called
But be careful of sender tcp stack : It might be delayed a bit,
because it waits for receiver to open its window (slow start)
You probably need something like
while (1) {
send(fd1, buffer, 2Kbytes);
sleep(2); // let tcp stack flush its write buffers
display_sk_rmem_alloc(fd2);
}
^ 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