* Re: [RFC PATCHv2 bridge 2/7] bridge: Add vlan to unicast fdb entries
From: Ben Hutchings @ 2012-09-22 17:17 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: netdev, shemminger
In-Reply-To: <1348058536-22607-3-git-send-email-vyasevic@redhat.com>
On Wed, 2012-09-19 at 08:42 -0400, Vlad Yasevich wrote:
> This patch adds vlan to unicast fdb entries that are created for
> learned addresses (not the manually configured ones). It adds
> vlan id into the hash mix and uses vlan as an addditional parameter
> for an entry match.
[...]
> diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
> index 9ce430b..e17f9f2 100644
> --- a/net/bridge/br_fdb.c
> +++ b/net/bridge/br_fdb.c
[...]
> @@ -67,11 +68,12 @@ static inline int has_expired(const struct net_bridge *br,
> time_before_eq(fdb->updated + hold_time(br), jiffies);
> }
>
> -static inline int br_mac_hash(const unsigned char *mac)
> +static inline int br_mac_hash(const unsigned char *mac, __u16 vlan_tci)
> {
> - /* use 1 byte of OUI cnd 3 bytes of NIC */
> + /* use 1 byte of OUI and 3 bytes of NIC */
> u32 key = get_unaligned((u32 *)(mac + 2));
> - return jhash_1word(key, fdb_salt) & (BR_HASH_SIZE - 1);
> + return jhash_2words(key, (vlan_tci & VLAN_VID_MASK),
> + fdb_salt) & (BR_HASH_SIZE - 1);
> }
Why do you add a vlan_tci parameter to so many functions, which they
then mask to get the VID? Would it not make more sense to pass only
VIDs around?
[...]
> @@ -628,11 +640,12 @@ int br_fdb_add(struct ndmsg *ndm, struct net_device *dev,
>
> if (ndm->ndm_flags & NTF_USE) {
> rcu_read_lock();
> - br_fdb_update(p->br, p, addr);
> + br_fdb_update(p->br, p, addr, 0);
> rcu_read_unlock();
> } else {
> spin_lock_bh(&p->br->hash_lock);
> - err = fdb_add_entry(p, addr, ndm->ndm_state, nlh_flags);
> + err = fdb_add_entry(p, addr, ndm->ndm_state, nlh_flags,
> + 0);
> spin_unlock_bh(&p->br->hash_lock);
> }
>
> @@ -642,10 +655,10 @@ int br_fdb_add(struct ndmsg *ndm, struct net_device *dev,
> static int fdb_delete_by_addr(struct net_bridge_port *p, u8 *addr)
> {
> struct net_bridge *br = p->br;
> - struct hlist_head *head = &br->hash[br_mac_hash(addr)];
> + struct hlist_head *head = &br->hash[br_mac_hash(addr, 0)];
> struct net_bridge_fdb_entry *fdb;
>
> - fdb = fdb_find(head, addr);
> + fdb = fdb_find(head, addr, 0);
> if (!fdb)
> return -ENOENT;
>
So current tools will only be able to manipulate forwarding entries for
untagged frames? Surely they should still insert and delete forwarding
entries that affect all VLANs, and new tools will be able to restrict
forwarding entries to specific VLANs?
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [RFC PATCHv2 bridge 4/7] bridge: Add netlink interface to configure vlans on bridge ports
From: Ben Hutchings @ 2012-09-22 17:17 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: netdev, shemminger
In-Reply-To: <1348058536-22607-5-git-send-email-vyasevic@redhat.com>
On Wed, 2012-09-19 at 08:42 -0400, Vlad Yasevich wrote:
> Add a netlink interface to add and remove vlan configuration on bridge port.
> The interface uses the RTM_SETLINK message and encodes the vlan
> configuration inside the IFLA_AF_SPEC. It is possble to include multiple
> vlans to either add or remove in a single message.
[...]
> --- a/net/bridge/br_if.c
> +++ b/net/bridge/br_if.c
> @@ -23,6 +23,7 @@
> #include <linux/if_ether.h>
> #include <linux/slab.h>
> #include <net/sock.h>
> +#include <linux/if_vlan.h>
>
> #include "br_private.h"
>
> @@ -445,6 +446,79 @@ int br_del_if(struct net_bridge *br, struct net_device *dev)
> return 0;
> }
>
> +/* Called with RTNL */
> +int br_set_port_vlan(struct net_bridge_port *p, unsigned short vlan)
> +{
> + unsigned long table_size = BITS_TO_LONGS(br_vid(VLAN_N_VID));
> + unsigned long *vid_map = NULL;
> + __u16 vid = br_vid(vlan);
> + int ret = 0;
> +
> + /* The vlan map is indexed by vid+1. This way we can store
> + * vid 0 (untagged) into the map as well.
> + */
So bit 1 is for untagged, bits 2-4096 are for tagged, and bit 0 is
for...?
> + if (!p->vlan_map) {
> + vid_map = kzalloc(table_size, GFP_KERNEL);
> + if (!vid_map) {
> + return -ENOMEM;
> + }
> +
> + set_bit(vid, vid_map);
> + rcu_assign_pointer(p->vlan_map, vid_map);
> + synchronize_net();
> + } else {
> + /* Map is already allocated */
> + set_bit(vid, rcu_dereference_rtnl(p->vlan_map));
> + }
> +
> + return ret;
> +}
> +
> +
> +/* Called with RTNL */
> +int br_del_port_vlan(struct net_bridge_port *p, unsigned short vlan)
> +{
> + unsigned long first_bit;
> + unsigned long next_bit;
> + __u16 vid = br_vid(vlan);
Which is the bit number, not really the VID - a little confusing...
> + unsigned long tbl_len = BITS_TO_LONGS(br_vid(VLAN_N_VID));
> +
> + if (!p->vlan_map) {
> + return -EINVAL;
> + }
> +
> + if (!test_bit(vlan, p->vlan_map)) {
> + return -EINVAL;
> + }
> +
> + /* Check to see if any other vlans are in this table. If this
> + * is the last vlan, delete the whole table. If this is not the
> + * last vlan, just clear the bit.
> + */
> + first_bit = find_first_bit(p->vlan_map, tbl_len);
> + next_bit = find_next_bit(p->vlan_map, tbl_len, (tbl_len - vid));
[...]
Last parameter to find_next_bit is the starting offset, which should
presumably be vid + 1.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH V3 net-next 3/4] ptp: link the phc device to its parent device
From: Ben Hutchings @ 2012-09-22 17:18 UTC (permalink / raw)
To: Richard Cochran
Cc: netdev, David Miller, Jacob Keller, Jeff Kirsher, John Stultz,
Matthew Vick
In-Reply-To: <5cbf85cdd74396119af11ba00b4b0bcd93f23ba0.1348332941.git.richardcochran@gmail.com>
On Sat, 2012-09-22 at 19:02 +0200, Richard Cochran wrote:
> PTP Hardware Clock devices appear as class devices in sysfs. This patch
> changes the registration API to use the parent device, clarifying the
> clock's relationship to the underlying device.
>
> Signed-off-by: Richard Cochran <richardcochran@gmail.com>
[...]
Acked-by: Ben Hutchings <bhutchings@solarflare.com>
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH V3 net-next 4/4] ptp: clarify the clock_name sysfs attribute
From: Ben Hutchings @ 2012-09-22 17:20 UTC (permalink / raw)
To: Richard Cochran
Cc: netdev, David Miller, Jacob Keller, Jeff Kirsher, John Stultz,
Matthew Vick
In-Reply-To: <149b5cc1b5813bb4052f8dff4cbe0b5be62d086e.1348332941.git.richardcochran@gmail.com>
On Sat, 2012-09-22 at 19:02 +0200, Richard Cochran wrote:
> There has been some confusion among PHC driver authors about the
> intended purpose of the clock_name attribute. This patch expands the
> documation in order to clarify how the clock_name field should be
> understood.
>
> Signed-off-by: Richard Cochran <richardcochran@gmail.com>
[...]
Looks good, thanks.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [RFC PATCHv2 bridge 7/7] bridge: Add the ability to show dump the vlan map from a bridge port
From: David Miller @ 2012-09-22 17:27 UTC (permalink / raw)
To: bhutchings; +Cc: vyasevic, netdev, shemminger
In-Reply-To: <1348334132.2521.100.camel@bwh-desktop.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Sat, 22 Sep 2012 18:15:32 +0100
> On Wed, 2012-09-19 at 08:42 -0400, Vlad Yasevich wrote:
>> Using the RTM_GETLINK dump the vlan map of a given bridge port.
> [...]
>
> This enlarges the RTM_GETLINK response quite a bit. I think perhaps
> this should be optional, like IFLA_VFINFO_LIST is now.
Completely agreed.
^ permalink raw reply
* Re: [PATCH v3] lxt PHY: Support for the buggy LXT973 rev A2
From: Richard Cochran @ 2012-09-22 17:32 UTC (permalink / raw)
To: Christophe Leroy; +Cc: David S Miller, netdev, linux-kernel
In-Reply-To: <201209221616.q8MGGnRc019864@localhost.localdomain>
On Sat, Sep 22, 2012 at 06:16:49PM +0200, Christophe Leroy wrote:
> This patch adds proper handling of the buggy revision A2 of LXT973 phy, adding
> precautions linked to ERRATA Item 4:
>
> Revision A2 of LXT973 chip randomly returns the contents of the previous even
> register when you read a odd register regularly
This patch does not apply to net-next.
Also, I have just a few stylistic comments, below.
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>
> diff -u linux-3.5-vanilla/drivers/net/phy/lxt.c linux-3.5/drivers/net/phy/lxt.c
> --- linux-3.5-vanilla/drivers/net/phy/lxt.c 2012-07-21 22:58:29.000000000 +0200
> +++ linux-3.5/drivers/net/phy/lxt.c 2012-09-15 19:20:34.000000000 +0200
...
> +int lxt973a2_read_status(struct phy_device *phydev)
> +{
> + int adv;
> + int err;
> + int lpa;
> + int lpagb = 0;
> +
> + /* Update the link, but return if there was an error */
> + err = lxt973a2_update_link(phydev);
> + if (err)
> + return err;
> +
> + if (AUTONEG_ENABLE == phydev->autoneg) {
> + int retry = 1;
> +
> + adv = phy_read(phydev, MII_ADVERTISE);
> +
> + if (adv < 0)
> + return adv;
> +
> + do {
> + lpa = phy_read(phydev, MII_LPA);
> +
> + if (lpa < 0)
> + return lpa;
> +
> + /* If both registers are equal, it is suspect but not
> + * impossible, hence a new try
> + */
> + } while (lpa == adv && retry--);
> +
> + lpa &= adv;
> +
> + phydev->speed = SPEED_10;
> + phydev->duplex = DUPLEX_HALF;
> + phydev->pause = phydev->asym_pause = 0;
> +
> + if (lpagb & (LPA_1000FULL | LPA_1000HALF)) {
> + phydev->speed = SPEED_1000;
> +
> + if (lpagb & LPA_1000FULL)
> + phydev->duplex = DUPLEX_FULL;
> + } else if (lpa & (LPA_100FULL | LPA_100HALF)) {
> + phydev->speed = SPEED_100;
> +
> + if (lpa & LPA_100FULL)
> + phydev->duplex = DUPLEX_FULL;
> + } else
> + if (lpa & LPA_10FULL)
> + phydev->duplex = DUPLEX_FULL;
This last 'else' could use braces.
> +
> + if (phydev->duplex == DUPLEX_FULL) {
> + phydev->pause = lpa & LPA_PAUSE_CAP ? 1 : 0;
> + phydev->asym_pause = lpa & LPA_PAUSE_ASYM ? 1 : 0;
> + }
> + } else {
> + int bmcr = phy_read(phydev, MII_BMCR);
> +
> + if (bmcr < 0)
> + return bmcr;
> +
> + if (bmcr & BMCR_FULLDPLX)
> + phydev->duplex = DUPLEX_FULL;
> + else
> + phydev->duplex = DUPLEX_HALF;
> +
> + if (bmcr & BMCR_SPEED1000)
> + phydev->speed = SPEED_1000;
> + else if (bmcr & BMCR_SPEED100)
> + phydev->speed = SPEED_100;
> + else
> + phydev->speed = SPEED_10;
> +
> + phydev->pause = phydev->asym_pause = 0;
> + }
> +
> + return 0;
> +}
> +
> +static int lxt973_read_status(struct phy_device *phydev)
> +{
> + return (int)phydev->priv&PHYDEV_PRIV_REVA2 ?
> + lxt973a2_read_status(phydev) :
> + genphy_read_status(phydev);
Needs spacing, like this:
return (int) phydev->priv & PHYDEV_PRIV_REVA2 ?
lxt973a2_read_status(phydev) : genphy_read_status(phydev);
> +}
> +
> static int lxt973_probe(struct phy_device *phydev)
> {
> int val = phy_read(phydev, MII_LXT973_PCR);
> + int priv = 0;
> +
> + phydev->priv = NULL;
> +
> + if (val < 0)
> + return val;
>
> if (val & PCR_FIBER_SELECT) {
> /*
> @@ -136,17 +272,26 @@
> val &= ~BMCR_ANENABLE;
> phy_write(phydev, MII_BMCR, val);
> /* Remember that the port is in fiber mode. */
> - phydev->priv = lxt973_probe;
> - } else {
> - phydev->priv = NULL;
> + priv |= PHYDEV_PRIV_FIBER;
> + }
> + val = phy_read(phydev, MII_PHYSID2);
> +
> + if (val < 0)
> + return val;
> +
> + if ((val & 0xf) == 0) { /* rev A2 */
> + dev_info(&phydev->dev, " LXT973 revision A2 has bugs\n");
> + priv |= PHYDEV_PRIV_REVA2;
> }
> + phydev->priv = (void *)priv;
One space after cast, please: (void *) priv;
> return 0;
> }
>
> static int lxt973_config_aneg(struct phy_device *phydev)
> {
> /* Do nothing if port is in fiber mode. */
> - return phydev->priv ? 0 : genphy_config_aneg(phydev);
> + return (int)phydev->priv&PHYDEV_PRIV_FIBER ?
> + 0 : genphy_config_aneg(phydev);
Same spacing issue again.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH V3 net-next 3/4] ptp: link the phc device to its parent device
From: Jeff Kirsher @ 2012-09-22 17:32 UTC (permalink / raw)
To: Richard Cochran
Cc: netdev, Ben Hutchings, David Miller, Jacob Keller, John Stultz,
Matthew Vick
In-Reply-To: <5cbf85cdd74396119af11ba00b4b0bcd93f23ba0.1348332941.git.richardcochran@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 382 bytes --]
On Sat, 2012-09-22 at 19:02 +0200, Richard Cochran wrote:
> PTP Hardware Clock devices appear as class devices in sysfs. This
> patch
> changes the registration API to use the parent device, clarifying the
> clock's relationship to the underlying device.
>
> Signed-off-by: Richard Cochran <richardcochran@gmail.com>
Acked-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] rds: Error on offset mismatch if not loopback
From: David Miller @ 2012-09-22 19:25 UTC (permalink / raw)
To: jjolly; +Cc: linux-kernel, venkat.x.venkatsubra, netdev
In-Reply-To: <20120921213239.GJ14393@linux-tkdk.sfcn.org>
From: John Jolly <jjolly@suse.com>
Date: Fri, 21 Sep 2012 15:32:40 -0600
> Attempting an rds connection from the IP address of an IPoIB interface
> to itself causes a kernel panic due to a BUG_ON() being triggered.
> Making the test less strict allows rds-ping to work without crashing
> the machine.
>
> A local unprivileged user could use this flaw to crash the system.
>
> Signed-off-by: John Jolly <jjolly@suse.com>
Besides the questions being asked of you by Venkat Venkatsubra, this
patch has another issue.
It has been completely corrupted by your email client, it has
turned all TAB characters into spaces, making the patch useless.
Please learn how to send a patch unmolested in the body of your
email. Test it by emailing the patch to yourself, and verifying
that you can in fact apply the patch you receive in that email.
Then, and only then, should you consider making a new submission
of this patch.
Use Documentation/email-clients.txt for guidance.
^ permalink raw reply
* Re: pull-request: can-next 2012-09-22
From: David Miller @ 2012-09-22 19:26 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can
In-Reply-To: <505CE91C.1070504@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Sat, 22 Sep 2012 00:24:28 +0200
> this pull request is intended for net-next (v3.7 cycle), it consist of
> 5 patches by AnilKumar bringing device tree support, runtime PM, suspend
> resume and pinctrl support to the c_can/d_can driver.
>
> Andreas Larsson improves the sja1000 driver (one-shot, listen only).
> Randy Dunlap fixes a function name conflict in the peak driver.
> Wei Yongjun fixes a return value check in the mscan-mpc5xxx driver.
Pulled, thanks Marc.
^ permalink raw reply
* Re: [PATCH 1/3 V3] phy/micrel: Implement support for KSZ8021
From: David Miller @ 2012-09-22 19:31 UTC (permalink / raw)
To: marex; +Cc: netdev, david.choi, nobuhiro.iwamatsu.yj
In-Reply-To: <1348278110-11603-1-git-send-email-marex@denx.de>
From: Marek Vasut <marex@denx.de>
Date: Sat, 22 Sep 2012 03:41:47 +0200
> + .name = "Micrel KSZ8021",
> + .features = (PHY_BASIC_FEATURES | SUPPORTED_Pause |
> + SUPPORTED_Asym_Pause),
You only fixed one of the two coding style problems I pointed out.
>From my original email:
====================
This is similarly not styled properly.
Besies being indented imporperly on the second line, the final "|"
character should be at the end of the first line, rather than
start the second line.
====================
Note "indented improperly on the second line"
Which is a clear reference to the first piece of
feedback I gave earlier in the same reply:
====================
This is not indented properly. The goal is not to exclusively use
TAB characters to indent code until it sort-of looks fine.
Rather, the goal is to properly line up function arguments with
the first column after the openning parenthesis on the previous
line. Using TAB and SPACE characters, as needed.
====================
^ permalink raw reply
* Re: [PATCH] net/phy/bcm87xx: Add MODULE_LICENSE("GPL") to GPL driver
From: David Miller @ 2012-09-22 19:34 UTC (permalink / raw)
To: peterhuewe; +Cc: jacmet, david.daney, chohnstaedt, netdev, linux-kernel, stable
In-Reply-To: <1348281858-24366-1-git-send-email-peterhuewe@gmx.de>
From: Peter Huewe <peterhuewe@gmx.de>
Date: Sat, 22 Sep 2012 04:44:18 +0200
> Currently the driver has no MODULE_LICENSE attribute in its source which
> results in a kernel taint if I load this:
>
> root@(none):~# modprobe bcm87xx
> bcm87xx: module license 'unspecified' taints kernel.
>
> Since the first lines of the source code clearly state:
> * This file is subject to the terms and conditions of the GNU General
> * Public License. See the file "COPYING" in the main directory of this
> * archive for more details.
> I think it's safe to add the MODULE_LICENSE("GPL") macro and thus remove
> the kernel taint.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Peter Huewe <peterhuewe@gmx.de>
Good catch, applied, thanks.
^ permalink raw reply
* Re: [PATCH] ipv4: raw: fix icmp_filter()
From: David Miller @ 2012-09-22 19:35 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1348308509.2669.1105.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 22 Sep 2012 12:08:29 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> icmp_filter() should not modify its input, or else its caller
> would need to recompute ip_hdr() if skb->head is reallocated.
>
> Use skb_header_pointer() instead of pskb_may_pull() and
> change the prototype to make clear both sk and skb are const.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied and queued up for -stable, thanks Eric.
^ permalink raw reply
* URGENT ASSISTANCE NEEDED.
From: LEGAL PRIVATE TRANSACTION @ 2012-09-22 17:47 UTC (permalink / raw)
To: Recipients
I am Mr. Michael WU Wei Kuo, I have a private legal business proposal for you reply me for more details via (mwwkbox7@w.cn).
^ permalink raw reply
* Re: [net-next 0/7][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2012-09-22 19:39 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1348309836-7107-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Sat, 22 Sep 2012 03:30:29 -0700
> This series contains updates to igb only.
>
> The following are changes since commit abb17e6c0c7b27693201dc85f75dbb184279fd10:
> netlink: use <linux/export.h> instead of <linux/module.h>
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
>
> Alexander Duyck (5):
> igb: Remove logic that was doing NUMA pseudo-aware allocations
> igb: Change Tx cleanup loop to do/while instead of for
> igb: Change how we populate the RSS indirection table
> igb: Simplify how we populate the RSS key
> igb: Use dma_unmap_addr and dma_unmap_len defines
>
> Carolyn Wyborny (1):
> igb: Fix stats output on i210/i211 parts.
>
> Stefan Assmann (1):
> igb: Change how we check for pre-existing and assigned VFs
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH V3 net-next 0/4] Two new PTP Hardware Clock features
From: David Miller @ 2012-09-22 19:43 UTC (permalink / raw)
To: richardcochran
Cc: netdev, bhutchings, jacob.e.keller, jeffrey.t.kirsher,
john.stultz, matthew.vick
In-Reply-To: <cover.1348332940.git.richardcochran@gmail.com>
From: Richard Cochran <richardcochran@gmail.com>
Date: Sat, 22 Sep 2012 19:02:00 +0200
> This patch series adds two new features to the PHC code.
>
> * ChangeLog
> ** V3
> - Use the correct parent device in the solarflare driver.
> - Expand the sysfs documentation of clock_name.
> - Also document the clock_name field in the header file.
> ** V2
> - Preserves the clock_name attribute as it was meant to be, instead
> of making any changes to it.
> - Covers the registration API change in the brand new solarflare phc
> device, which was overlooked in V1.
>
> The first two patches let a user program find out the previously
> dialed frequency adjustment. This is primarily useful when restarting
> a PTP service, since without this information, the presumably correct
> adjustment will bias the new frequency estimation.
>
> The third patch links the phc class device to its parent device within
> the driver model and sysfs.
>
> The fourth patch adds a bit more documentation of the sysfs clock_name
> attribute. This should help clarify the naming scheme.
All applied, with a minor coding style correction made to patch #2
Thanks.
^ permalink raw reply
* Re: [patch net] team: send port changed when added
From: David Miller @ 2012-09-22 19:45 UTC (permalink / raw)
To: jiri; +Cc: netdev
In-Reply-To: <1348333673-29860-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Sat, 22 Sep 2012 19:07:53 +0200
> On some hw, link is not up during adding iface to team. That causes event
> not being sent to userspace and that may cause confusion.
> Fix this bug by sending port changed event once it's added to team.
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
I'll apply this, thanks Jiri.
^ permalink raw reply
* Re: [PATCH net-next 1/4] tcp: extract code to compute SYNACK RTT
From: David Miller @ 2012-09-22 19:47 UTC (permalink / raw)
To: ncardwell; +Cc: netdev, edumazet, ycheng, hkchu
In-Reply-To: <1348323537-30310-1-git-send-email-ncardwell@google.com>
From: Neal Cardwell <ncardwell@google.com>
Date: Sat, 22 Sep 2012 10:18:54 -0400
> In preparation for adding another spot where we compute the SYNACK
> RTT, extract this code so that it can be shared.
>
> Signed-off-by: Neal Cardwell <ncardwell@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/4] tcp: TCP Fast Open Server - take SYNACK RTT after completing 3WHS
From: David Miller @ 2012-09-22 19:47 UTC (permalink / raw)
To: ncardwell; +Cc: netdev, edumazet, ycheng, hkchu
In-Reply-To: <1348323537-30310-2-git-send-email-ncardwell@google.com>
From: Neal Cardwell <ncardwell@google.com>
Date: Sat, 22 Sep 2012 10:18:55 -0400
> When taking SYNACK RTT samples for servers using TCP Fast Open, fix
> the code to ensure that we only call tcp_valid_rtt_meas() after we
> receive the ACK that completes the 3-way handshake.
>
> Previously we were always taking an RTT sample in
> tcp_v4_syn_recv_sock(). However, for TCP Fast Open connections
> tcp_v4_conn_req_fastopen() calls tcp_v4_syn_recv_sock() at the time we
> receive the SYN. So for TFO we must wait until tcp_rcv_state_process()
> to take the RTT sample.
>
> To fix this, we wait until after TFO calls tcp_v4_syn_recv_sock()
> before we set the snt_synack timestamp, since tcp_synack_rtt_meas()
> already ensures that we only take a SYNACK RTT sample if snt_synack is
> non-zero. To be careful, we only take a snt_synack timestamp when
> a SYNACK transmit or retransmit succeeds.
>
> Signed-off-by: Neal Cardwell <ncardwell@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 3/4] tcp: TCP Fast Open Server - note timestamps and retransmits for SYNACK RTT
From: David Miller @ 2012-09-22 19:47 UTC (permalink / raw)
To: ncardwell; +Cc: netdev, edumazet, ycheng, hkchu
In-Reply-To: <1348323537-30310-3-git-send-email-ncardwell@google.com>
From: Neal Cardwell <ncardwell@google.com>
Date: Sat, 22 Sep 2012 10:18:56 -0400
> Previously, when using TCP Fast Open a server would return from
> tcp_check_req() before updating snt_synack based on TCP timestamp echo
> replies and whether or not we've retransmitted the SYNACK. The result
> was that (a) for TFO connections using timestamps we used an incorrect
> baseline SYNACK send time (tcp_time_stamp of SYNACK send instead of
> rcv_tsecr), and (b) for TFO connections that do not have TCP
> timestamps but retransmit the SYNACK we took a SYNACK RTT sample when
> we should not take a sample.
>
> This fix merely moves the snt_synack update logic a bit earlier in the
> function, so that connections using TCP Fast Open will properly do
> these updates when the ACK for the SYNACK arrives.
>
> Moving this snt_synack update logic means that with TCP_DEFER_ACCEPT
> enabled we do a few instructions of wasted work on each bare ACK, but
> that seems OK.
>
> Signed-off-by: Neal Cardwell <ncardwell@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 4/4] tcp: TCP Fast Open Server - call tcp_validate_incoming() for all packets
From: David Miller @ 2012-09-22 19:48 UTC (permalink / raw)
To: ncardwell; +Cc: netdev, edumazet, ycheng, hkchu
In-Reply-To: <1348323537-30310-4-git-send-email-ncardwell@google.com>
From: Neal Cardwell <ncardwell@google.com>
Date: Sat, 22 Sep 2012 10:18:57 -0400
> A TCP Fast Open (TFO) passive connection must call both
> tcp_check_req() and tcp_validate_incoming() for all incoming ACKs that
> are attempting to complete the 3WHS.
>
> This is needed to parallel all the action that happens for a non-TFO
> connection, where for an ACK that is attempting to complete the 3WHS
> we call both tcp_check_req() and tcp_validate_incoming().
>
> For example, upon receiving the ACK that completes the 3WHS, we need
> to call tcp_fast_parse_options() and update ts_recent based on the
> incoming timestamp value in the ACK.
>
> One symptom of the problem with the previous code was that for passive
> TFO connections using TCP timestamps, the outgoing TS ecr values
> ignored the incoming TS val value on the ACK that completed the 3WHS.
>
> Signed-off-by: Neal Cardwell <ncardwell@google.com>
Applied.
^ permalink raw reply
* Re: pull request: wireless 2012-09-22
From: David Miller @ 2012-09-22 19:51 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20120922171341.GB2101-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Sat, 22 Sep 2012 13:13:42 -0400
> Please pull this last(?) batch of fixes intended for 3.6...
>
> For the Bluetooth bits, Gustavo says this:
>
> "Here goes probably my last update to 3.6. It includes the two patches
> you were ok last week(from Andrzej Kaczmarek), those are critical
> ones, and two other fixes one for a system crash and the other for
> a missing lockdep annotation."
>
> The referenced fixes from Andrzej prevent attempts to configure devices
> that are powered-off.
>
> Along with the Bluetooth fixes, there are a couple of 802.11 fixes.
> Emmanuel Grumbach gives us an iwlwifi fix to prevent releasing an
> interrupt twice. Luis R. Rodriguez provides a fix for a possible
> circular lock dependency in the cfg80211 regulatory enforcement code.
>
> All of these have been in linux-next for a few days. I hope they are
> not too late to make the 3.6 release!
Pulled, thanks John.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] pppoe: drop PPPOX_ZOMBIEs in pppoe_release
From: David Miller @ 2012-09-22 19:51 UTC (permalink / raw)
To: stid.smth; +Cc: linux-kernel, netdev
In-Reply-To: <CANEcBPR8EvBTsJ0tG+kqvn578qXnqTMwdciS_WChe9sm5yKdaw@mail.gmail.com>
From: Xiaodong Xu <stid.smth@gmail.com>
Date: Sat, 22 Sep 2012 18:09:32 +0800
> From: Xiaodong Xu <stid.smth@gmail.com>
>
> When PPPOE is running over a virtual ethernet interface (e.g., a
> bonding interface) and the user tries to delete the interface in case
> the PPPOE state is ZOMBIE, the kernel will loop forever while
> unregistering net_device for the reference count is not decreased to
> zero which should have been done with dev_put().
>
> Signed-off-by: Xiaodong Xu <stid.smth@gmail.com>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next v1] net: use a per task frag allocator
From: David Miller @ 2012-09-22 19:52 UTC (permalink / raw)
To: eric.dumazet
Cc: subramanian.vijay, linux-kernel, netdev, bhutchings,
alexander.h.duyck
In-Reply-To: <1348261871.2669.962.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 21 Sep 2012 23:11:11 +0200
> On Fri, 2012-09-21 at 13:27 -0700, Vijay Subramanian wrote:
>> I get the following compile error with the newer version of the patch
>>
>> net/sched/em_meta.c: In function ‘meta_int_sk_sendmsg_off’:
>> net/sched/em_meta.c:464: error: ‘struct sock’ has no member named
>> ‘sk_sndmsg_off’
>> make[1]: *** [net/sched/em_meta.o] Error 1
>> make: *** [net/sched/em_meta.o] Error 2
>>
>>
>>
>> Vijay
>
> Oh well, I wonder what's the expected use of this crap...
>
> Thanks, I'll fix this on v3 !
So many aspects of the meta match are an extreme burdon on development
because the keys it allows unnecessarily exposes internals of our
implementation.
Who really uses it? Maybe we can schedule it for removal.
^ permalink raw reply
* Re: linux-next: build failure after merge of the final tree (net-next tree related)
From: David Miller @ 2012-09-22 20:00 UTC (permalink / raw)
To: benh
Cc: sfr, paulus, linuxppc-dev, mika.westerberg, netdev, linux-next,
linux-kernel
In-Reply-To: <1348264000.1132.63.camel@pasglop>
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Date: Sat, 22 Sep 2012 07:46:40 +1000
> Right, but on ppc, GFP_DMA is a nop (no separate ZONE_DMA, or rather all
> of memory is ZONE_DMA). It's always been like that afaik.
>
> We could support ISA device limited addressability using the iommu but
> that would involve a map/unmap type API (which I remember we did support
> in the old days by passing NULL to pci_map_*, but we dropped that along
> the way).
I think I'm going to just end up restricting this driver to X86
as was originally suggested.
There seems to be no real consistent Kconfig protection for users
of isa_virt_to_bus() and friends.
We know that ISA_DMA_API doesn't do it, and ISA doesn't do it either
as powerpc also allows that to bet set for CHRP and friends.
Thanks.
^ permalink raw reply
* Re: [RFC PATCHv2 bridge 7/7] bridge: Add the ability to show dump the vlan map from a bridge port
From: Stephen Hemminger @ 2012-09-22 20:05 UTC (permalink / raw)
To: David Miller; +Cc: bhutchings, vyasevic, netdev
In-Reply-To: <20120922.132747.1937291269030903700.davem@davemloft.net>
On Sat, 22 Sep 2012 13:27:47 -0400 (EDT)
David Miller <davem@davemloft.net> wrote:
> From: Ben Hutchings <bhutchings@solarflare.com>
> Date: Sat, 22 Sep 2012 18:15:32 +0100
>
> > On Wed, 2012-09-19 at 08:42 -0400, Vlad Yasevich wrote:
> >> Using the RTM_GETLINK dump the vlan map of a given bridge port.
> > [...]
> >
> > This enlarges the RTM_GETLINK response quite a bit. I think perhaps
> > this should be optional, like IFLA_VFINFO_LIST is now.
>
> Completely agreed.
Since most users won't use it, it should be not necessary to include
it if the map is blank.
^ 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