* [PATCH 1/3] net: dsa: Centralise code for reading the temperature sensor
From: Andrew Lunn @ 2014-11-15 21:24 UTC (permalink / raw)
To: davem; +Cc: netdev, linux, Andrew Lunn
In-Reply-To: <1416086694-15790-1-git-send-email-andrew@lunn.ch>
The method to read the temperature used in the mve6123_61_65 driver
can also be used for other chips. Move the code into the shared code
base of mv88e6xxx.c.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/dsa/mv88e6123_61_65.c | 50 +--------------------------------------
drivers/net/dsa/mv88e6xxx.c | 48 +++++++++++++++++++++++++++++++++++++
drivers/net/dsa/mv88e6xxx.h | 1 +
3 files changed, 50 insertions(+), 49 deletions(-)
diff --git a/drivers/net/dsa/mv88e6123_61_65.c b/drivers/net/dsa/mv88e6123_61_65.c
index 9a3f9e0b0532..e9c736e1cef3 100644
--- a/drivers/net/dsa/mv88e6123_61_65.c
+++ b/drivers/net/dsa/mv88e6123_61_65.c
@@ -291,54 +291,6 @@ static int mv88e6123_61_65_setup_port(struct dsa_switch *ds, int p)
return 0;
}
-#ifdef CONFIG_NET_DSA_HWMON
-
-static int mv88e6123_61_65_get_temp(struct dsa_switch *ds, int *temp)
-{
- struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
- int ret;
- int val;
-
- *temp = 0;
-
- mutex_lock(&ps->phy_mutex);
-
- ret = mv88e6xxx_phy_write(ds, 0x0, 0x16, 0x6);
- if (ret < 0)
- goto error;
-
- /* Enable temperature sensor */
- ret = mv88e6xxx_phy_read(ds, 0x0, 0x1a);
- if (ret < 0)
- goto error;
-
- ret = mv88e6xxx_phy_write(ds, 0x0, 0x1a, ret | (1 << 5));
- if (ret < 0)
- goto error;
-
- /* Wait for temperature to stabilize */
- usleep_range(10000, 12000);
-
- val = mv88e6xxx_phy_read(ds, 0x0, 0x1a);
- if (val < 0) {
- ret = val;
- goto error;
- }
-
- /* Disable temperature sensor */
- ret = mv88e6xxx_phy_write(ds, 0x0, 0x1a, ret & ~(1 << 5));
- if (ret < 0)
- goto error;
-
- *temp = ((val & 0x1f) - 5) * 5;
-
-error:
- mv88e6xxx_phy_write(ds, 0x0, 0x16, 0x0);
- mutex_unlock(&ps->phy_mutex);
- return ret;
-}
-#endif /* CONFIG_NET_DSA_HWMON */
-
static int mv88e6123_61_65_setup(struct dsa_switch *ds)
{
struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
@@ -471,7 +423,7 @@ struct dsa_switch_driver mv88e6123_61_65_switch_driver = {
.get_ethtool_stats = mv88e6123_61_65_get_ethtool_stats,
.get_sset_count = mv88e6123_61_65_get_sset_count,
#ifdef CONFIG_NET_DSA_HWMON
- .get_temp = mv88e6123_61_65_get_temp,
+ .get_temp = mv88e6xxx_get_temp,
#endif
.get_regs_len = mv88e6xxx_get_regs_len,
.get_regs = mv88e6xxx_get_regs,
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index da558d887dad..cd6807c6b4ed 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -539,6 +539,54 @@ void mv88e6xxx_get_regs(struct dsa_switch *ds, int port,
}
}
+#ifdef CONFIG_NET_DSA_HWMON
+
+int mv88e6xxx_get_temp(struct dsa_switch *ds, int *temp)
+{
+ struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
+ int ret;
+ int val;
+
+ *temp = 0;
+
+ mutex_lock(&ps->phy_mutex);
+
+ ret = mv88e6xxx_phy_write(ds, 0x0, 0x16, 0x6);
+ if (ret < 0)
+ goto error;
+
+ /* Enable temperature sensor */
+ ret = mv88e6xxx_phy_read(ds, 0x0, 0x1a);
+ if (ret < 0)
+ goto error;
+
+ ret = mv88e6xxx_phy_write(ds, 0x0, 0x1a, ret | (1 << 5));
+ if (ret < 0)
+ goto error;
+
+ /* Wait for temperature to stabilize */
+ usleep_range(10000, 12000);
+
+ val = mv88e6xxx_phy_read(ds, 0x0, 0x1a);
+ if (val < 0) {
+ ret = val;
+ goto error;
+ }
+
+ /* Disable temperature sensor */
+ ret = mv88e6xxx_phy_write(ds, 0x0, 0x1a, ret & ~(1 << 5));
+ if (ret < 0)
+ goto error;
+
+ *temp = ((val & 0x1f) - 5) * 5;
+
+error:
+ mv88e6xxx_phy_write(ds, 0x0, 0x16, 0x0);
+ mutex_unlock(&ps->phy_mutex);
+ return ret;
+}
+#endif /* CONFIG_NET_DSA_HWMON */
+
static int __init mv88e6xxx_init(void)
{
#if IS_ENABLED(CONFIG_NET_DSA_MV88E6131)
diff --git a/drivers/net/dsa/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx.h
index a0780b08bb4c..03e397efde36 100644
--- a/drivers/net/dsa/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx.h
@@ -81,6 +81,7 @@ void mv88e6xxx_get_ethtool_stats(struct dsa_switch *ds,
int mv88e6xxx_get_regs_len(struct dsa_switch *ds, int port);
void mv88e6xxx_get_regs(struct dsa_switch *ds, int port,
struct ethtool_regs *regs, void *_p);
+int mv88e6xxx_get_temp(struct dsa_switch *ds, int *temp);
extern struct dsa_switch_driver mv88e6131_switch_driver;
extern struct dsa_switch_driver mv88e6123_61_65_switch_driver;
--
2.1.3
^ permalink raw reply related
* [PATCH net-next] device: Add dev_<level>_once variants
From: Joe Perches @ 2014-11-15 22:38 UTC (permalink / raw)
To: Florian Fainelli
Cc: Jeff Kirsher, davem, Shannon Nelson, netdev, nhorman, sassmann,
jogreene
In-Reply-To: <5467C3BA.6090003@gmail.com>
Add the equivalents to pr_<level>_once.
Suggested-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Joe Perches <joe@perches.com>
---
include/linux/device.h | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/include/linux/device.h b/include/linux/device.h
index ce1f2160..a1ee071 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -1118,6 +1118,41 @@ do { \
})
#endif
+#ifdef CONFIG_PRINTK
+#define dev_level_once(dev_level, dev, fmt, ...) \
+do { \
+ static bool __print_once __read_mostly; \
+ \
+ if (!__print_once) { \
+ __print_once = true; \
+ dev_level(dev, fmt, ##__VA_ARGS__); \
+ } \
+} while (0)
+#else
+#define dev_level_once(dev_level, dev, fmt, ...) \
+do { \
+ if (0) \
+ dev_level(dev, fmt, ##__VA_ARGS__); \
+} while (0)
+#endif
+
+#define dev_emerg_once(dev, fmt, ...) \
+ dev_level_once(dev_emerg, dev, fmt, ##__VA_ARGS__)
+#define dev_alert_once(dev, fmt, ...) \
+ dev_level_once(dev_alert, dev, fmt, ##__VA_ARGS__)
+#define dev_crit_once(dev, fmt, ...) \
+ dev_level_once(dev_crit, dev, fmt, ##__VA_ARGS__)
+#define dev_err_once(dev, fmt, ...) \
+ dev_level_once(dev_err, dev, fmt, ##__VA_ARGS__)
+#define dev_warn_once(dev, fmt, ...) \
+ dev_level_once(dev_warn, dev, fmt, ##__VA_ARGS__)
+#define dev_notice_once(dev, fmt, ...) \
+ dev_level_once(dev_notice, dev, fmt, ##__VA_ARGS__)
+#define dev_info_once(dev, fmt, ...) \
+ dev_level_once(dev_info, dev, fmt, ##__VA_ARGS__)
+#define dev_dbg_once(dev, fmt, ...) \
+ dev_level_once(dev_info, dev, fmt, ##__VA_ARGS__)
+
#define dev_level_ratelimited(dev_level, dev, fmt, ...) \
do { \
static DEFINE_RATELIMIT_STATE(_rs, \
^ permalink raw reply related
* [PATCH] qmi_wwan: Add support for HP lt4112 LTE/HSPA+ Gobi 4G Modem
From: Martin Hauke @ 2014-11-16 0:03 UTC (permalink / raw)
To: netdev; +Cc: bjorn
Added the USB VID/PID for the HP lt4112 LTE/HSPA+ Gobi 4G Modem (Huawei me906e)
---
drivers/net/usb/qmi_wwan.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 22756db..b8a82b8 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -780,6 +780,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x413c, 0x81a4, 8)}, /* Dell Wireless 5570e HSPA+ (42Mbps) Mobile Broadband Card */
{QMI_FIXED_INTF(0x413c, 0x81a8, 8)}, /* Dell Wireless 5808 Gobi(TM) 4G LTE Mobile Broadband Card */
{QMI_FIXED_INTF(0x413c, 0x81a9, 8)}, /* Dell Wireless 5808e Gobi(TM) 4G LTE Mobile Broadband Card */
+ {QMI_FIXED_INTF(0x03f0, 0x581d, 4)}, /* HP lt4112 LTE/HSPA+ Gobi 4G Module (Huawei me906e) */
/* 4. Gobi 1000 devices */
{QMI_GOBI1K_DEVICE(0x05c6, 0x9212)}, /* Acer Gobi Modem Device */
--
2.1.2
^ permalink raw reply related
* sysctl to clamp mtu on all application-initiated sockets?
From: oskar @ 2014-11-16 0:28 UTC (permalink / raw)
To: netdev
Hi!
I'm trying to setup routers that should be able to forward
jumbo-packets, but applications should not get jumbo-capable sockets.
The major brands of routers support something like this. You set mtu
for forwarding to something big (8192, 9000) but don't touch the system
mtu of 1500.
Management-traffic, routing protocols and such communicate with
<=1500byte packets, but the router can forward frames up to <big> mtu
size if other machines feel like using them.
The only ways I've found to do this is either through mss-clamping in
iptables (+ some iptables rule that drop other packets and return ICMP
Packet too big), or update each route on the router with an MTU
argument, but it feels clunky and i believe this will cause quite some
overhead which would impact forwarding-performance of the router
negatively, It's also not nice to change tcp packet values on the fly.
(The MTU on routes-path is quite a lot of work when running IPv4 DHCP
client + IPv6 RA-learned routes + full BGP table on multiple boxes, it's
easy to miss something)
So, is it possible to create something like
/proc/sys/net/ipv*/max_socket_mtu that would clamp the MTU of all
created sockets to some nice value?
It should also be possible to override this clamping on a per-socket
basis (and use up to link-layer MTU size) by setting a flag or such on
the socket, for example tunnels.
I need to solve this some how for forwarding + VXLAN, but I believe
this would also apply to and simplify management of other tunnel
techniques. The tunnel interface should be able to transmit encapsulated
packets using up to link-layer MTU size inside my datacenter/network,
but applications on the same machine shouldn't when sending data
somewhere since it would cause extra roundtrips / broken sessions when
oversize packets are being dropped somewhere else in the network / on
the Internet.
Best regards
Oskar Stenman
^ permalink raw reply
* Re: Understanding what's going on when using a Huawei E173 USB 3G web-stick (UMTS/HSPA)
From: Sedat Dilek @ 2014-11-16 1:40 UTC (permalink / raw)
To: Greg KH
Cc: Dan Williams, David S. Miller,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Aleksander Morgado
In-Reply-To: <20141115200711.GA24643-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
On Sat, Nov 15, 2014 at 9:07 PM, Greg KH <greg-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org> wrote:
> On Sat, Nov 15, 2014 at 10:23:55AM +0100, Sedat Dilek wrote:
>> On Fri, Nov 14, 2014 at 5:18 PM, Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> > On Fri, 2014-11-14 at 11:56 +0100, Sedat Dilek wrote:
>> >> On Wed, Nov 12, 2014 at 2:21 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
>> >> > On Tue, Nov 4, 2014 at 5:55 PM, Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> >> >> On Tue, 2014-11-04 at 16:11 +0100, Sedat Dilek wrote:
>> >> >>> Hi,
>> >> >>>
>> >> >>> I wanted to understand what is going on the kernel-side when
>> >> >>> connecting to the Internet via a Huawei E173 USB web-stick (3rd
>> >> >>> Generation: UMTS / HSPA).
>> >> >>>
>> >> >>> Especially the correlation between the diverse USB/NET kernel-drivers
>> >> >>> and how the networking is setup.
>> >> >>
>> >> >
>> >> > [ Sitting in front of a foreign Windows machine ]
>> >> >
>> >> > [ CC Aleksander ]
>> >> >
>> >> > Hi Dan,
>> >> >
>> >> > sorry for the late (and short) response.
>> >> >
>> >> > AFAICS you have given a "skeleton" for a "usb-wwan-networking"
>> >> > documentation :-).
>> >> >
>> >> > Personally, I would like to take into account some kernel-config
>> >> > options and some more things.
>> >> >
>> >>
>> >> I started with documenting...
>> >>
>> >> I have still some difficulties in understanding USB WWAN Networking.
>> >> So, this is what I revealed...
>> >>
>> >> ##### USB: HUAWEI E173 3G/UMTS/HSPA INTERNET STICK
>> >>
>> >> ### USB-NETWORKING AND WWAN SETUP
>> >> CONFIG_USB_USBNET=m <--- usb networking
>> >> CONFIG_USB_NET_CDCETHER=m <--- usb-wwan (net) configuration
>> >> CONFIG_USB_SERIAL_WWAN=m <--- usb-wwan (serial) configuration
>> >> CONFIG_USB_SERIAL_OPTION=m <--- usb-serial driver called "option"
>> >
>> > Most WWAN devices actually require option, because most WWAN devices
>> > have "serial" ports (even if they aren't used for PPP), and 'option' is
>> > the driver that handles this. The 'option' name is historic, but the
>> > driver should really be called something like 'wwan-serial-generic' or
>> > something like that.
>> >ö"
>>
>> Is there sth. against renaming the "option" driver to "wwan-serial-generic"?
>
> Yes, people's scripts might break that are hard-coded to use the
> "option" driver.
>
As far as I read on LKML... breaking userspace is a reason not to do
such changes.
That's really a reason not to break "handmade" scripts on some machines?
As this is new to me... is that documented?
Surely, it's fretful to change scripts, but life is change.
For me there is a more reasonable thing... Did you grep for "option"
pattern in the kernel sources?
Try.... :-).
> thanks,
>
> greg "here, have a vowel, they are cheap" k-h
Hmm, being a non-English native, I am not sure to get this...
What about languages from mostly Eastern countries having so much
consonants in a single word like Russian, Polish, etc.
Not every language is rich like German which has WOWels like "ä" (ae)
"ö" (oe) "ü" (ue).
- Sedat -
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 4/4] rhashtable: Add parent argument to mutex_is_held
From: Herbert Xu @ 2014-11-16 2:22 UTC (permalink / raw)
To: Josh Triplett; +Cc: tgraf, netdev, eric.dumazet, paulmck
In-Reply-To: <20141115191219.GA19060@thin>
Josh Triplett <josh@joshtriplett.org> wrote:
>
> - Set up the new empty table with the new set of hash parameters.
> - synchronize_rcu(). Readers will now search both old and new tables.
> - Peel nodes off the ends of the old hash table and add them to the new
We currently use a singly linked list in rhashtable. Peeling nodes
off the end would mean upgrading to a doubly linked list, which is
no different than keeping two lists in terms of cache footprint, no?
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: Understanding what's going on when using a Huawei E173 USB 3G web-stick (UMTS/HSPA)
From: Greg KH @ 2014-11-16 2:34 UTC (permalink / raw)
To: Sedat Dilek
Cc: Dan Williams, David S. Miller, netdev@vger.kernel.org, linux-usb,
Aleksander Morgado
In-Reply-To: <CA+icZUXFYYtvpKV-pOfj-pqhYD+TWBDB3SKKz_aBirrJbxvQkA@mail.gmail.com>
On Sun, Nov 16, 2014 at 02:40:15AM +0100, Sedat Dilek wrote:
> On Sat, Nov 15, 2014 at 9:07 PM, Greg KH <greg@kroah.com> wrote:
> > On Sat, Nov 15, 2014 at 10:23:55AM +0100, Sedat Dilek wrote:
> >> On Fri, Nov 14, 2014 at 5:18 PM, Dan Williams <dcbw@redhat.com> wrote:
> >> > On Fri, 2014-11-14 at 11:56 +0100, Sedat Dilek wrote:
> >> >> On Wed, Nov 12, 2014 at 2:21 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
> >> >> > On Tue, Nov 4, 2014 at 5:55 PM, Dan Williams <dcbw@redhat.com> wrote:
> >> >> >> On Tue, 2014-11-04 at 16:11 +0100, Sedat Dilek wrote:
> >> >> >>> Hi,
> >> >> >>>
> >> >> >>> I wanted to understand what is going on the kernel-side when
> >> >> >>> connecting to the Internet via a Huawei E173 USB web-stick (3rd
> >> >> >>> Generation: UMTS / HSPA).
> >> >> >>>
> >> >> >>> Especially the correlation between the diverse USB/NET kernel-drivers
> >> >> >>> and how the networking is setup.
> >> >> >>
> >> >> >
> >> >> > [ Sitting in front of a foreign Windows machine ]
> >> >> >
> >> >> > [ CC Aleksander ]
> >> >> >
> >> >> > Hi Dan,
> >> >> >
> >> >> > sorry for the late (and short) response.
> >> >> >
> >> >> > AFAICS you have given a "skeleton" for a "usb-wwan-networking"
> >> >> > documentation :-).
> >> >> >
> >> >> > Personally, I would like to take into account some kernel-config
> >> >> > options and some more things.
> >> >> >
> >> >>
> >> >> I started with documenting...
> >> >>
> >> >> I have still some difficulties in understanding USB WWAN Networking.
> >> >> So, this is what I revealed...
> >> >>
> >> >> ##### USB: HUAWEI E173 3G/UMTS/HSPA INTERNET STICK
> >> >>
> >> >> ### USB-NETWORKING AND WWAN SETUP
> >> >> CONFIG_USB_USBNET=m <--- usb networking
> >> >> CONFIG_USB_NET_CDCETHER=m <--- usb-wwan (net) configuration
> >> >> CONFIG_USB_SERIAL_WWAN=m <--- usb-wwan (serial) configuration
> >> >> CONFIG_USB_SERIAL_OPTION=m <--- usb-serial driver called "option"
> >> >
> >> > Most WWAN devices actually require option, because most WWAN devices
> >> > have "serial" ports (even if they aren't used for PPP), and 'option' is
> >> > the driver that handles this. The 'option' name is historic, but the
> >> > driver should really be called something like 'wwan-serial-generic' or
> >> > something like that.
> >> >ö"
> >>
> >> Is there sth. against renaming the "option" driver to "wwan-serial-generic"?
> >
> > Yes, people's scripts might break that are hard-coded to use the
> > "option" driver.
> >
>
> As far as I read on LKML... breaking userspace is a reason not to do
> such changes.
Exactly.
> That's really a reason not to break "handmade" scripts on some machines?
Yes.
> As this is new to me... is that documented?
It's our "culture" :)
> Surely, it's fretful to change scripts, but life is change.
> For me there is a more reasonable thing... Did you grep for "option"
> pattern in the kernel sources?
> Try.... :-).
Oh I know, I wrote the first version of this driver and named it this :)
> > greg "here, have a vowel, they are cheap" k-h
>
> Hmm, being a non-English native, I am not sure to get this...
> What about languages from mostly Eastern countries having so much
> consonants in a single word like Russian, Polish, etc.
> Not every language is rich like German which has WOWels like "ä" (ae)
> "ö" (oe) "ü" (ue).
I was referring to your "sth." abbreviation above.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 4/4] rhashtable: Add parent argument to mutex_is_held
From: Josh Triplett @ 2014-11-16 2:37 UTC (permalink / raw)
To: Herbert Xu; +Cc: tgraf, netdev, eric.dumazet, paulmck
In-Reply-To: <20141116022227.GA24541@gondor.apana.org.au>
On November 15, 2014 6:22:27 PM PST, Herbert Xu <herbert@gondor.apana.org.au> wrote:
>Josh Triplett <josh@joshtriplett.org> wrote:
>>
>> - Set up the new empty table with the new set of hash parameters.
>> - synchronize_rcu(). Readers will now search both old and new
>tables.
>> - Peel nodes off the ends of the old hash table and add them to the
>new
>
>We currently use a singly linked list in rhashtable. Peeling nodes
>off the end would mean upgrading to a doubly linked list, which is
>no different than keeping two lists in terms of cache footprint, no?
No, since each pass just handles one set of nodes from each bucket anyway, you can just do a bit more work in the rehasher instead.
^ permalink raw reply
* Re: Understanding what's going on when using a Huawei E173 USB 3G web-stick (UMTS/HSPA)
From: Sedat Dilek @ 2014-11-16 2:48 UTC (permalink / raw)
To: Greg KH
Cc: Dan Williams, David S. Miller, netdev@vger.kernel.org, linux-usb,
Aleksander Morgado
In-Reply-To: <20141116023423.GA31016@kroah.com>
On Sun, Nov 16, 2014 at 3:34 AM, Greg KH <greg@kroah.com> wrote:
> On Sun, Nov 16, 2014 at 02:40:15AM +0100, Sedat Dilek wrote:
>> On Sat, Nov 15, 2014 at 9:07 PM, Greg KH <greg@kroah.com> wrote:
>> > On Sat, Nov 15, 2014 at 10:23:55AM +0100, Sedat Dilek wrote:
>> >> On Fri, Nov 14, 2014 at 5:18 PM, Dan Williams <dcbw@redhat.com> wrote:
>> >> > On Fri, 2014-11-14 at 11:56 +0100, Sedat Dilek wrote:
>> >> >> On Wed, Nov 12, 2014 at 2:21 PM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
>> >> >> > On Tue, Nov 4, 2014 at 5:55 PM, Dan Williams <dcbw@redhat.com> wrote:
>> >> >> >> On Tue, 2014-11-04 at 16:11 +0100, Sedat Dilek wrote:
>> >> >> >>> Hi,
>> >> >> >>>
>> >> >> >>> I wanted to understand what is going on the kernel-side when
>> >> >> >>> connecting to the Internet via a Huawei E173 USB web-stick (3rd
>> >> >> >>> Generation: UMTS / HSPA).
>> >> >> >>>
>> >> >> >>> Especially the correlation between the diverse USB/NET kernel-drivers
>> >> >> >>> and how the networking is setup.
>> >> >> >>
>> >> >> >
>> >> >> > [ Sitting in front of a foreign Windows machine ]
>> >> >> >
>> >> >> > [ CC Aleksander ]
>> >> >> >
>> >> >> > Hi Dan,
>> >> >> >
>> >> >> > sorry for the late (and short) response.
>> >> >> >
>> >> >> > AFAICS you have given a "skeleton" for a "usb-wwan-networking"
>> >> >> > documentation :-).
>> >> >> >
>> >> >> > Personally, I would like to take into account some kernel-config
>> >> >> > options and some more things.
>> >> >> >
>> >> >>
>> >> >> I started with documenting...
>> >> >>
>> >> >> I have still some difficulties in understanding USB WWAN Networking.
>> >> >> So, this is what I revealed...
>> >> >>
>> >> >> ##### USB: HUAWEI E173 3G/UMTS/HSPA INTERNET STICK
>> >> >>
>> >> >> ### USB-NETWORKING AND WWAN SETUP
>> >> >> CONFIG_USB_USBNET=m <--- usb networking
>> >> >> CONFIG_USB_NET_CDCETHER=m <--- usb-wwan (net) configuration
>> >> >> CONFIG_USB_SERIAL_WWAN=m <--- usb-wwan (serial) configuration
>> >> >> CONFIG_USB_SERIAL_OPTION=m <--- usb-serial driver called "option"
>> >> >
>> >> > Most WWAN devices actually require option, because most WWAN devices
>> >> > have "serial" ports (even if they aren't used for PPP), and 'option' is
>> >> > the driver that handles this. The 'option' name is historic, but the
>> >> > driver should really be called something like 'wwan-serial-generic' or
>> >> > something like that.
>> >> >ö"
>> >>
>> >> Is there sth. against renaming the "option" driver to "wwan-serial-generic"?
>> >
>> > Yes, people's scripts might break that are hard-coded to use the
>> > "option" driver.
>> >
>>
>> As far as I read on LKML... breaking userspace is a reason not to do
>> such changes.
>
> Exactly.
>
>> That's really a reason not to break "handmade" scripts on some machines?
>
> Yes.
>
>> As this is new to me... is that documented?
>
> It's our "culture" :)
>
OK.
>> Surely, it's fretful to change scripts, but life is change.
>> For me there is a more reasonable thing... Did you grep for "option"
>> pattern in the kernel sources?
>> Try.... :-).
>
> Oh I know, I wrote the first version of this driver and named it this :)
>
Ah, IIRC the company was called so.
>> > greg "here, have a vowel, they are cheap" k-h
>>
>> Hmm, being a non-English native, I am not sure to get this...
>> What about languages from mostly Eastern countries having so much
>> consonants in a single word like Russian, Polish, etc.
>> Not every language is rich like German which has WOWels like "ä" (ae)
>> "ö" (oe) "ü" (ue).
>
> I was referring to your "sth." abbreviation above.
>
Hmm, I thought this is a "normal" abbreviation.
Maybe I should not mix IRC and Email writing styles.
Thanks for your comments.
- Sedat -
P.S.: /me was reading about the systemd transition (now default
init-system) and reading about Joey Hess leaving Debian, Damn and I
initiated the Debian systemd wiki. If I ever knew... Life is change
and neat and polite people died (I lost my parents the last two
years).
> thanks,
>
> greg k-h
^ permalink raw reply
* [PATCH] ip-link: Document IPoIB link type in the man page
From: Or Gerlitz @ 2014-11-16 7:43 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, Haggai Eran, Shachar Raindel, Or Gerlitz
Add documentation on how to create devices of type IP-over-Infiniband
in the man page.
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
---
man/man8/ip-link.8.in | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/man/man8/ip-link.8.in b/man/man8/ip-link.8.in
index 6d32f5e..a05633f 100644
--- a/man/man8/ip-link.8.in
+++ b/man/man8/ip-link.8.in
@@ -449,6 +449,23 @@ when tunneling non-IP packets. The default value is 00.
.in -8
+.TP
+IPoIB Type Support
+For a link of type
+.I IPoIB
+the following additional arguments are supported:
+
+.BI "ip link add " DEVICE " name " NAME
+.BI type " ipoib [ " pkey " PKEY ] [" mode " MODE " ]
+
+.in +8
+.sp
+.BI pkey " PKEY "
+- specifies the IB P-Key to use.
+
+.BI mode " MODE "
+- specifies the mode (datagram or connected) to use.
+
.SS ip link delete - delete virtual link
.I DEVICE
specifies the virtual device to act operate on.
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v1 net-next 1/2] bonding: Expand speed type bits of the AD Port Key
From: Jianhua Xie @ 2014-11-16 8:45 UTC (permalink / raw)
To: Veaceslav Falico; +Cc: Jay Vosburgh, David Miller, netdev, andy, Jianhua Xie
In-Reply-To: <20141112112002.GA27653@raspberrypi>
在 2014年11月12日 19:20, Veaceslav Falico 写道:
> On Wed, Nov 12, 2014 at 05:53:41PM +0800, Jianhua Xie wrote:
>> Thanks you two for the valuable comments.
>>
>> If my understanding is right, it is encouraged to use a counter
>> rather than a bitmask for the speed field, right?
>>
>> if yes, how many bits are better to use for current speed and
>> future speed (like 100Gbps/400Gbps and etc.)? I am not sure
>> that 5 bits are enough (2**5=32) or not. And I am clear to keep
>> "the duplex bit in the key " in my mind.
>>
>> if not, what's your recommendation please?
>
> As it's visible to bonding only, I guess a simple enum should do the
> trick.
> No need to invent something special, and it'll fit nicely with other
> enums
> from AD.
Thanks comments from Jay Vosburgh and Veaceslav Falico. However, my
method can also work, and also compatible with current bonding driver.
But Veaceslav Falico's method is better than mine. I am glad to take his
advice. I will use an enum to instead of AD_LINK_SPEED_BITMASK micros
which are based on bitmask.
I also thank Miller for the kindly reminder on "please don't top-post".
Thank & Best Regards,
Jianhua
>
>>
>> Thanks & Best Regards,
>> Jianhua
>>
>> 在 2014年11月12日 03:47, Jay Vosburgh 写道:
>>> David Miller <davem@davemloft.net> wrote:
>>>
>>>> From: Xie Jianhua <Jianhua.Xie@freescale.com>
>>>> Date: Mon, 10 Nov 2014 15:16:40 +0800
>>>>
>>>>> From: Jianhua Xie <Jianhua.Xie@freescale.com>
>>>>>
>>>>> Port Key was determined as 16 bits according to the link speed,
>>>>> duplex and user key (which is yet not supported), in which key
>>>>> speed was 5 bits for 1Mbps/10Mbps/100Mbps/1Gbps/10Gbps as below:
>>>>> --------------------------------------------------------------
>>>>> Port key :| User key | Speed | Duplex|
>>>>> --------------------------------------------------------------
>>>>> 16 6 1 0
>>>>> This patch is expanding speed type from 5 bits to 9 bits for other
>>>>> speed 2.5Gbps/20Gbps/40Gbps/56Gbps and shrinking user key from 10
>>>>> bits to 6 bits. New Port Key looks like below:
>>>>> --------------------------------------------------------------
>>>>> Port key :| User key | Speed | Duplex|
>>>>> --------------------------------------------------------------
>>>>> 16 10 1 0
>>>>>
>>>> Do we determine the layout of this value all ourselves?
>>> Yes, we do. The precise format of the port key is not defined
>>> by the standard; IEEE 802.1AX 5.3.5, "Capability identification":
>>>
>>> "A given Key value is meaningful only in the context of the System that
>>> allocates it; there is no global significance to Key values."
>>>
>>> and
>>>
>>> "When a System assigns an operational Key value to a set of ports, it
>>> signifies that, in the absence of other constraints, the current
>>> operational state of the set of ports allows any subset of that set of
>>> ports (including the entire set) to be aggregated together from the
>>> perspective of the System making the assignment."
>>>
>>> So, basically, it's a magic cookie that indicates that all ports
>>> on a particular system with the same key value are suitable to be
>>> aggregated together.
>>>
>>>> If not, then is it exported to anything user-visible that we
>>>> might be breaking?
>>> The key values are not user-visible, and the "user" settable
>>> portion of the key has never been implemented.
>>>
>>>> If it is private, it makes no sense to use a bitmask for the speed.
>>>> We should instead change the field to be some numerically increasing
>>>> value.
>>>>
>>>> Otherwise we'll run out of bits again and keep having to adjust the
>>>> field layout more often than we really need to.
>>> Agreed.
>>>
>>> Also note that there are some internal dependencies within
>>> bonding on the format; in particular the duplex bit in the key is used
>>> to determine if a port is LACP-capable, and that functionality needs to
>>> be preserved.
>>>
>>> -J
>>>
>>> ---
>>> -Jay Vosburgh, jay.vosburgh@canonical.com
>>
^ permalink raw reply
* Re: /proc/net/sockstat invalid memory accounting or memory leak in latest kernels? (trying to debug)
From: Denys Fedoryshchenko @ 2014-11-16 8:54 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Neal Cardwell, Yuchung Cheng, netdev
In-Reply-To: <1415813254.17262.7.camel@edumazet-glaptop2.roam.corp.google.com>
As latest findings, when servers are going crazy because of tcp memory
invalid accounting.
First of all i upgraded kernel to latest version 3.17.3 and added also
patch from upcoming kernel,
"12) Don't call sock_kfree_s() with NULL pointers, this function also
has the side effect of adjusting
the socket memory usage. From Cong Wang.", but it didnt helped.
I added printk_ratelimited to places where suspicious values might
appear, and got some more information.
First, is not very suspicious, no idea if it is a problem:
[ 1413.031622] sk ffff8817184d8680 sk_mem_charge negative -10752 by 4352
[ 1413.032027] sk ffff8817184d8680 sk_mem_charge negative -15104 by 4352
[ 1415.768465] sk ffff881666842d80 sk_mem_charge negative -9984 by 4352
[ 1415.768868] sk ffff881666842d80 sk_mem_charge negative -14336 by 4352
[ 1415.769268] sk ffff881666842d80 sk_mem_charge negative -18688 by 4352
[ 1415.769681] sk ffff881666842d80 sk_mem_charge negative -9088 by 4352
[ 1418.933799] sk ffff8816dd640000 sk_mem_charge negative -9984 by 4352
[ 1418.934205] sk ffff8816dd640000 sk_mem_charge negative -14336 by 4352
[ 1418.934604] sk ffff8816dd640000 sk_mem_charge negative -18688 by 4352
[ 1427.131310] sk ffff881731801a00 sk_mem_charge negative -11776 by 4352
[ 1428.564640] sk ffff881731801a00 sk_mem_charge negative -11008 by 4352
[ 1429.134279] sk ffff881731801a00 sk_mem_charge negative -11776 by 4352
[ 1429.134691] sk ffff881731801a00 sk_mem_charge negative -16128 by 4352
[ 1430.666541] sk ffff881731801a00 sk_mem_charge negative -10496 by 4352
[ 1431.395099] sk ffff881731801a00 sk_mem_charge negative -12032 by 4352
[ 1431.395506] sk ffff881731801a00 sk_mem_charge negative -16384 by 4352
[ 1431.877862] sk ffff881731801a00 sk_mem_charge negative -11648 by 4352
Second is always linked with crashes, it is sk_mem_uncharge and
sk_forward_alloc goes negative. Patch to show message
for sk_mem_uncharge in sock.h is very simple:
static inline void sk_mem_uncharge(struct sock *sk, int size)
@@ -1480,6 +1485,8 @@
if (!sk_has_account(sk))
return;
sk->sk_forward_alloc += size;
+ if (sk->sk_forward_alloc < -8192)
+ printk_ratelimited(KERN_WARNING"sk %p sk_mem_uncharge
negative %d by %d\n", sk, sk->sk_forward_alloc, size);
}
This is what i am usually setting before box are rebooted:
Nov 15 13:20:53 g1 user.warn kernel: [ 2002.363437] sk ffff88155e904100
sk_mem_uncharge negative -2147482496 by 2304
Nov 15 13:20:53 g1 user.warn kernel: [ 2002.363837] sk ffff88155e904100
sk_mem_uncharge negative -2147480192 by 2304
Nov 15 13:20:53 g1 user.warn kernel: [ 2002.364232] sk ffff88155e904100
sk_mem_uncharge negative -2147477888 by 2304
Nov 15 13:20:53 g1 user.warn kernel: [ 2002.364627] sk ffff88155e904100
sk_mem_uncharge negative -2147475584 by 2304
Nov 15 13:20:53 g1 user.warn kernel: [ 2002.365022] sk ffff88155e904100
sk_mem_uncharge negative -2147473280 by 2304
Nov 15 13:20:53 g1 user.warn kernel: [ 2002.365416] sk ffff88155e904100
sk_mem_uncharge negative -2147470976 by 2304
Nov 15 13:20:53 g1 user.warn kernel: [ 2002.365811] sk ffff88155e904100
sk_mem_uncharge negative -2147468672 by 2304
Nov 15 13:20:53 g1 user.warn kernel: [ 2002.366214] sk ffff88155e904100
sk_mem_uncharge negative -2147466368 by 2304
Nov 15 13:20:53 g1 user.warn kernel: [ 2002.366611] sk ffff88155e904100
sk_mem_uncharge negative -2147464064 by 2304
Nov 15 13:20:53 g1 user.warn kernel: [ 2002.367004] sk ffff88155e904100
sk_mem_uncharge negative -2147461760 by 2304
Nov 15 13:20:58 g1 user.warn kernel: [ 2007.363601] sk_mem_uncharge:
576170 callbacks suppressed
Nov 15 13:20:58 g1 user.warn kernel: [ 2007.364001] sk ffff88155e904100
sk_mem_uncharge negative -1517794432 by 2304
.....
until
...
Nov 15 13:31:58 g1 user.warn kernel: [ 2666.393667] sk ffff88170141ad80
sk_mem_uncharge negative -169088 by 2944
Nov 15 13:31:58 g1 user.warn kernel: [ 2666.394064] sk ffff88170141ad80
sk_mem_uncharge negative -166144 by 2944
Nov 15 13:31:58 g1 user.warn kernel: [ 2666.394472] sk ffff88170141ad80
sk_mem_uncharge negative -163200 by 2944
Nov 15 13:31:58 g1 user.warn kernel: [ 2666.394871] sk ffff88170141ad80
sk_mem_uncharge negative -158208 by 4992
<reboot>
Or:
Nov 15 14:55:01 g1 user.warn kernel: [ 1965.758129] sk ffff8815f8014e00
sk_mem_uncharge negative -2147483520 by 2304
Nov 15 14:55:01 g1 user.warn kernel: [ 1965.758536] sk ffff8815f8014e00
sk_mem_uncharge negative -2147481216 by 2304
Nov 15 14:55:01 g1 user.warn kernel: [ 1965.758935] sk ffff8815f8014e00
sk_mem_uncharge negative -2147478912 by 2304
Nov 15 14:55:01 g1 user.warn kernel: [ 1965.759332] sk ffff8815f8014e00
sk_mem_uncharge negative -2147476608 by 2304
Nov 15 14:55:01 g1 user.warn kernel: [ 1965.759728] sk ffff8815f8014e00
sk_mem_uncharge negative -2147474304 by 2304
Nov 15 14:55:01 g1 user.warn kernel: [ 1965.760124] sk ffff8815f8014e00
sk_mem_uncharge negative -2147472000 by 2304
Nov 15 14:55:01 g1 user.warn kernel: [ 1965.760518] sk ffff8815f8014e00
sk_mem_uncharge negative -2147469696 by 2304
...
Nov 15 15:03:27 g1 user.warn kernel: [ 2472.170857] sk ffff88163f429a00
sk_mem_uncharge negative -277169024 by 896
Nov 15 15:03:30 g1 user.warn kernel: [ 2474.611109] sk ffff88163f429a00
sk_mem_uncharge negative -277164928 by 896
Nov 15 15:03:30 g1 user.warn kernel: [ 2474.611511] sk ffff88163f429a00
sk_mem_uncharge negative -277164032 by 896
Nov 15 15:03:30 g1 user.warn kernel: [ 2474.706237] sk ffff88163f429a00
sk_mem_uncharge negative -277159936 by 2304
Nov 15 15:03:34 g1 user.warn kernel: [ 2478.889110] sk ffff88163f429a00
sk_mem_uncharge negative -277155840 by 2304
Nov 15 15:03:34 g1 user.warn kernel: [ 2478.911516] sk ffff88163f429a00
sk_mem_uncharge negative -277147648 by 1536
Nov 15 15:03:35 g1 user.warn kernel: [ 2479.320851] sk ffff88163f429a00
sk_mem_uncharge negative -277143552 by 2304
Nov 15 15:04:33 g1 user.warn kernel: [ 2537.408184] sk ffff88163f429a00
sk_mem_uncharge negative -277139456 by 2304
Nov 15 15:04:33 g1 user.warn kernel: [ 2537.409790] sk ffff88163f429a00
sk_mem_uncharge negative -277135360 by 896
(here i can see two sk at same time are like this)
Or
Nov 15 23:37:19 g1 user.warn kernel: [14137.049570] sk ffff8816b3312700
sk_mem_uncharge negative -2147481856 by 2304
Nov 15 23:37:19 g1 user.warn kernel: [14137.049973] sk ffff8816b3312700
sk_mem_uncharge negative -2147479552 by 2304
Nov 15 23:37:19 g1 user.warn kernel: [14137.050372] sk ffff8816b3312700
sk_mem_uncharge negative -2147477248 by 2304
Nov 15 23:37:19 g1 user.warn kernel: [14137.050770] sk ffff8816b3312700
sk_mem_uncharge negative -2147474944 by 2304
Nov 15 23:37:19 g1 user.warn kernel: [14137.051170] sk ffff8816b3312700
sk_mem_uncharge negative -2147472640 by 2304
Nov 15 23:37:19 g1 user.warn kernel: [14137.051572] sk ffff8816b3312700
sk_mem_uncharge negative -2147470336 by 2304
Nov 15 23:37:19 g1 user.warn kernel: [14137.051971] sk ffff8816b3312700
sk_mem_uncharge negative -2147468032 by 2304
Nov 15 23:37:19 g1 user.warn kernel: [14137.052371] sk ffff8816b3312700
sk_mem_uncharge negative -2147465728 by 2304
Nov 15 23:37:19 g1 user.warn kernel: [14137.052771] sk ffff8816b3312700
sk_mem_uncharge negative -2147463424 by 2304
Nov 15 23:37:19 g1 user.warn kernel: [14137.053169] sk ffff8816b3312700
sk_mem_uncharge negative -2147461120 by 2304
Nov 15 23:37:32 g1 user.warn kernel: [14150.526984] sk_mem_uncharge:
1083519 callbacks suppressed
Nov 15 23:37:32 g1 user.warn kernel: [14150.527384] sk ffff8816b3312700
sk_mem_uncharge negative -2147483392 by 2304
Nov 15 23:37:32 g1 user.warn kernel: [14150.527782] sk ffff8816b3312700
sk_mem_uncharge negative -2147481088 by 2304
Nov 15 23:37:32 g1 user.warn kernel: [14150.528179] sk ffff8816b3312700
sk_mem_uncharge negative -2147478784 by 2304
Nov 15 23:37:32 g1 user.warn kernel: [14150.528576] sk ffff8816b3312700
sk_mem_uncharge negative -2147476480 by 2304
Nov 15 23:37:32 g1 user.warn kernel: [14150.528975] sk ffff8816b3312700
sk_mem_uncharge negative -2147474176 by 2304
Nov 15 23:37:32 g1 user.warn kernel: [14150.529370] sk ffff8816b3312700
sk_mem_uncharge negative -2147471872 by 2304
Nov 15 23:37:32 g1 user.warn kernel: [14150.529770] sk ffff8816b3312700
sk_mem_uncharge negative -2147469568 by 2304
Nov 15 23:37:32 g1 user.warn kernel: [14150.530167] sk ffff8816b3312700
sk_mem_uncharge negative -2147467264 by 2304
Nov 15 23:37:32 g1 user.warn kernel: [14150.530572] sk ffff8816b3312700
sk_mem_uncharge negative -2147464960 by 2304
Nov 15 23:37:32 g1 user.warn kernel: [14150.530973] sk ffff8816b3312700
sk_mem_uncharge negative -2147462656 by 2304
<here it reboots much earlier, at this point>
I will try to get more info, what kind of socket it is.
On 2014-11-12 19:27, Eric Dumazet wrote:
> On Wed, 2014-11-12 at 19:07 +0200, Denys Fedoryshchenko wrote:
>> Hi
>>
>>
>> I've been able to trace invalid memory shown for sk_forward_alloc. Not
>> sure if it is related to bug when all tcp stack are wrecked on
>> highload
>> servers (i had even such crash on server with plain torrents, not that
>> much of them).
>> First they were appearing in ss output as f4294966016, but in tc it
>> shows as unsigned integer, while in kernel it is signed integer.
>> Should
>> i provide patch for iproute2?
>> After changing value to correct one, here is what is got:
>> skmem:(r0,rb359040,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb349440,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb349440,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb349440,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb357120,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb349440,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb357120,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb349440,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb357120,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb349440,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb349440,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb349440,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb349440,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb357120,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb357120,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb357120,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb357120,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb349440,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb349440,t0,tb46080,f-1280,w1280,o0,bl0)
>> skmem:(r0,rb357120,t0,tb46080,f-1280,w1280,o0,bl0)
>>
>> So as it is signed integer, it is actually appears a lot as -1280
>> bytes.
>> After placing several WARN_ON_ONCE on fall functions involving
>> sk_forward_alloc, where negative value may
>> appear i traced down at least to tcp_connect_queue_skb().
>> [ 13.094561] WARNING: CPU: 4 PID: 2855 at include/net/sock.h:1476
>> tcp_connect_queue_skb+0x9f/0xd0()
>> After adding some debug values, it was confirmed:
>>
>>
>> skb_header_release(skb);
>> __tcp_add_write_queue_tail(sk, skb);
>> sk->sk_wmem_queued += skb->truesize;
>> sk_mem_charge(sk, skb->truesize); <<<< sk->sk_forward_alloc often is
>> 0,
>> and skb->truesize is 1280, so -1280 is result
>> tp->write_seq = tcb->end_seq;
>> tp->packets_out += tcp_skb_pcount(skb);
>>
>> Maybe it should not be subtracted here? Or maybe logic are inverted
>> all
>> over the code?
>> Please help :)
>>
>
> Thanks a lot for the report, I am CCing other experts ;)
>
> AFAIK, a negative forward alloc should not be a problem, a long as the
> incursion is bound.
^ permalink raw reply
* Re: [PATCHv2 net 3/4] net/mlx4_en: Implement ndo_gso_check()
From: Or Gerlitz @ 2014-11-16 9:32 UTC (permalink / raw)
To: Joe Stringer
Cc: Linux Netdev List, sathya.perla, shahed.shaikh, Amir Vadai,
dept-gelinuxnicdev, Tom Herbert, alexander.duyck, Linux Kernel
In-Reply-To: <1415925495-59312-4-git-send-email-joestringer@nicira.com>
On Fri, Nov 14, 2014 at 2:38 AM, Joe Stringer <joestringer@nicira.com> wrote:
> Use vxlan_gso_check() to advertise offload support for this NIC.
>
> Signed-off-by: Joe Stringer <joestringer@nicira.com>
FWIW (since the patches is applied already...)
Acked-by: Or Gerlitz <ogerlitz@mellanox.com>
thanks for addressing this piece.
^ permalink raw reply
* Re: [PATCHv2 net 1/4] net: Add vxlan_gso_check() helper
From: Or Gerlitz @ 2014-11-16 9:35 UTC (permalink / raw)
To: Joe Stringer; +Cc: Linux Netdev List
In-Reply-To: <1415925495-59312-2-git-send-email-joestringer@nicira.com>
On Fri, Nov 14, 2014 at 2:38 AM, Joe Stringer <joestringer@nicira.com> wrote:
> Most NICs that report NETIF_F_GSO_UDP_TUNNEL support VXLAN, and not
> other UDP-based encapsulation protocols where the format and size of the
> header differs. This patch implements a generic ndo_gso_check() for
> VXLAN which will only advertise GSO support when the skb looks like it
> contains VXLAN (or no UDP tunnelling at all).
>
> Implementation shamelessly stolen from Tom Herbert:
> http://thread.gmane.org/gmane.linux.network/332428/focus=333111
>
> Signed-off-by: Joe Stringer <joestringer@nicira.com>
> ---
> v2: Merge helpers for be2net, mlx4, qlcnic
> Use (sizeof(struct udphdr) + sizeof(struct vxlanhdr))
> v1: Initial post
> ---
> drivers/net/vxlan.c | 13 +++++++++++++
> include/net/vxlan.h | 2 ++
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
> index fa9dc45..6b65863 100644
> --- a/drivers/net/vxlan.c
> +++ b/drivers/net/vxlan.c
> @@ -1571,6 +1571,19 @@ static bool route_shortcircuit(struct net_device *dev, struct sk_buff *skb)
> return false;
> }
>
> +bool vxlan_gso_check(struct sk_buff *skb)
> +{
> + if ((skb_shinfo(skb)->gso_type & SKB_GSO_UDP_TUNNEL) &&
> + (skb->inner_protocol_type != ENCAP_TYPE_ETHER ||
> + skb->inner_protocol != htons(ETH_P_TEB) ||
> + (skb_inner_mac_header(skb) - skb_transport_header(skb) !=
> + sizeof(struct udphdr) + sizeof(struct vxlanhdr))))
> + return false;
> +
> + return true;
> +}
> +EXPORT_SYMBOL_GPL(vxlan_gso_check);
Joe, any chance you can make the extra step and inline that in
vxlan.h? this is fast path call... you will only need to move struct
vxlanhdr there too.
Or.
^ permalink raw reply
* Re: [PATCH] brcmfmac: fix error handling of irq_of_parse_and_map
From: Arend van Spriel @ 2014-11-16 13:02 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: John W. Linville, Brett Rudley, Franky (Zhenhui) Lin,
Hante Meuleman, Pieter-Paul Giesberts,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
brcm80211-dev-list-dY08KVG/lbpWk0Htik3J/w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Hans de Goede
In-Reply-To: <20141114221221.GA35541@dtor-ws>
On 11/14/14 23:12, Dmitry Torokhov wrote:
> Return value of irq_of_parse_and_map() is unsigned int, with 0
> indicating failure, so testing for negative result never works.
Whoops, that is bad. Thanks for catching this. It probably needs to go
to stable as well for 3.17 kernel.
+Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org # v3.17
+Acked-by: Arend van Spriel <arend-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
> Signed-off-by: Dmitry Torokhov<dtor-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
> ---
>
> Not tested, found by casual code inspection.
>
> drivers/net/wireless/brcm80211/brcmfmac/of.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/brcm80211/brcmfmac/of.c b/drivers/net/wireless/brcm80211/brcmfmac/of.c
> index eb3fce82..c824570 100644
> --- a/drivers/net/wireless/brcm80211/brcmfmac/of.c
> +++ b/drivers/net/wireless/brcm80211/brcmfmac/of.c
> @@ -40,8 +40,8 @@ void brcmf_of_probe(struct brcmf_sdio_dev *sdiodev)
> return;
>
> irq = irq_of_parse_and_map(np, 0);
> - if (irq< 0) {
> - brcmf_err("interrupt could not be mapped: err=%d\n", irq);
> + if (!irq) {
> + brcmf_err("interrupt could not be mapped\n");
> devm_kfree(dev, sdiodev->pdata);
> return;
> }
--
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
* pkt_sched: Fix qdisc len in qdisc_peek_dequeued() [61c9eaf9008] - question
From: Michal Soltys @ 2014-11-16 13:04 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: Linux Netdev List
Hi,
I was wondering (probably missing some subtleties) about that particular
patch, namely:
61c9eaf90081cbe6dc4f389e0056bff76eca19ec
Why would that qlen++ change be necessary ? As far as peeked qdisc sees
things, the packet is already deqeued and gone - so not really part of
the queue anymore in this context (not ever requeued either). More
advanced qdiscs such as say fq_codel - if for example they decide to
drop head during further enqueue operation - obviously won't even
consider the peeked packet.
Increasing qlen from what I can see artificially shortens queue by 1.
For some classful schedulers (say like hfsc that instantly peeks next
packet length after dequeuing), child qdiscs will be almost all the time
formally operating at queue size decreased by 1.
^ permalink raw reply
* [PATCH net-next 00/14] net: provide common RSS key infrastructure
From: Eric Dumazet @ 2014-11-16 14:23 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Thomas Lendacky, Ariel Elior, Michael Chan,
Prashant Sreedharan, Rasesh Mody, Sathya Perla, Subbu Seetharaman,
Ajit Khaparde, Jesse Brandeburg, Jeff Kirsher, Amir Vadai,
Shradha Shah, Shreyas Bhatewara, Eric Dumazet
RSS (Receive Side Scaling) uses a 40 bytes key to provide hash for incoming
packets to select appropriate incoming queue on NIC.
Hash algo (Toeplitz) is also well known and documented by Microsoft
(search for "Verifying the RSS Hash Calculation")
Problem is that some drivers use a well known key.
It makes very easy for attackers to target one particular RX queue,
knowing that number of RX queues is a power of two, or at least some
small number.
Other drivers use a random value per port, making difficult
tuning on bonding setups.
Lets add a common infrastructure, so that host gets an unique
RSS key, and drivers do not have to worry about this.
Eric Dumazet (14):
net: provide a per host RSS key generic infrastructure
amd-xgbe: use netdev_rss_key_fill() helper
bnx2x: use netdev_rss_key_fill() helper
tg3: use netdev_rss_key_fill() helper
bna: use netdev_rss_key_fill() helper
be2net:use netdev_rss_key_fill() helper
e100e: use netdev_rss_key_fill() helper
fm10k: use netdev_rss_key_fill() helper
i40e: use netdev_rss_key_fill() helper
igb: use netdev_rss_key_fill() helper
ixgbe: use netdev_rss_key_fill() helper
mlx4: use netdev_rss_key_fill() helper
sfc: use netdev_rss_key_fill() helper
vmxnet3: use netdev_rss_key_fill() helper
Documentation/sysctl/net.txt | 22 ++++++++++++++++++++++
drivers/net/ethernet/amd/xgbe/xgbe-main.c | 2 +-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 2 +-
drivers/net/ethernet/broadcom/tg3.c | 17 ++++++-----------
drivers/net/ethernet/brocade/bna/bnad.c | 2 +-
drivers/net/ethernet/emulex/benet/be_main.c | 10 +++++-----
drivers/net/ethernet/intel/e1000e/netdev.c | 9 +++------
drivers/net/ethernet/intel/fm10k/fm10k_pci.c | 10 +++-------
drivers/net/ethernet/intel/i40e/i40e_main.c | 10 +++-------
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 11 +++--------
drivers/net/ethernet/intel/igb/igb_main.c | 9 +++------
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 7 +++----
drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 9 ++++++++-
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 6 +-----
drivers/net/ethernet/sfc/efx.c | 2 +-
drivers/net/vmxnet3/vmxnet3_drv.c | 9 +--------
include/linux/mlx4/qp.h | 4 +++-
include/linux/netdevice.h | 6 ++++++
net/core/ethtool.c | 11 +++++++++++
net/core/sysctl_net_core.c | 19 +++++++++++++++++++
20 files changed, 104 insertions(+), 73 deletions(-)
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply
* [PATCH net-next 02/14] amd-xgbe: use netdev_rss_key_fill() helper
From: Eric Dumazet @ 2014-11-16 14:23 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Thomas Lendacky, Ariel Elior, Michael Chan,
Prashant Sreedharan, Rasesh Mody, Sathya Perla, Subbu Seetharaman,
Ajit Khaparde, Jesse Brandeburg, Jeff Kirsher, Amir Vadai,
Shradha Shah, Shreyas Bhatewara, Eric Dumazet
In-Reply-To: <1416147798-16561-1-git-send-email-edumazet@google.com>
Use netdev_rss_key_fill() helper, as it provides better support for some
bonding setups.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Lendacky, Thomas <Thomas.Lendacky@amd.com>
---
drivers/net/ethernet/amd/xgbe/xgbe-main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/amd/xgbe/xgbe-main.c b/drivers/net/ethernet/amd/xgbe/xgbe-main.c
index 05fbdf96e77e..dbd3850b8b0a 100644
--- a/drivers/net/ethernet/amd/xgbe/xgbe-main.c
+++ b/drivers/net/ethernet/amd/xgbe/xgbe-main.c
@@ -338,7 +338,7 @@ static int xgbe_probe(struct platform_device *pdev)
}
/* Initialize RSS hash key and lookup table */
- get_random_bytes(pdata->rss_key, sizeof(pdata->rss_key));
+ netdev_rss_key_fill(pdata->rss_key, sizeof(pdata->rss_key));
for (i = 0; i < XGBE_RSS_MAX_TABLE_SIZE; i++)
XGMAC_SET_BITS(pdata->rss_table[i], MAC_RSSDR, DMCH,
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 03/14] bnx2x: use netdev_rss_key_fill() helper
From: Eric Dumazet @ 2014-11-16 14:23 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Thomas Lendacky, Ariel Elior, Michael Chan,
Prashant Sreedharan, Rasesh Mody, Sathya Perla, Subbu Seetharaman,
Ajit Khaparde, Jesse Brandeburg, Jeff Kirsher, Amir Vadai,
Shradha Shah, Shreyas Bhatewara, Eric Dumazet
In-Reply-To: <1416147798-16561-1-git-send-email-edumazet@google.com>
Use netdev_rss_key_fill() helper, as it provides better support for some
bonding setups.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Ariel Elior <ariel.elior@qlogic.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
index e9af4af5edba..b4d71fd909ee 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
@@ -2099,7 +2099,7 @@ int bnx2x_rss(struct bnx2x *bp, struct bnx2x_rss_config_obj *rss_obj,
if (config_hash) {
/* RSS keys */
- prandom_bytes(params.rss_key, T_ETH_RSS_KEY * 4);
+ netdev_rss_key_fill(params.rss_key, T_ETH_RSS_KEY * 4);
__set_bit(BNX2X_RSS_SET_SRCH, ¶ms.rss_flags);
}
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 04/14] tg3: use netdev_rss_key_fill() helper
From: Eric Dumazet @ 2014-11-16 14:23 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Thomas Lendacky, Ariel Elior, Michael Chan,
Prashant Sreedharan, Rasesh Mody, Sathya Perla, Subbu Seetharaman,
Ajit Khaparde, Jesse Brandeburg, Jeff Kirsher, Amir Vadai,
Shradha Shah, Shreyas Bhatewara, Eric Dumazet
In-Reply-To: <1416147798-16561-1-git-send-email-edumazet@google.com>
Use of well known RSS key increases attack surface.
Switch to a random one, using generic helper so that all
ports share a common key.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Prashant Sreedharan <prashant@broadcom.com>
Cc: Michael Chan <mchan@broadcom.com>
---
drivers/net/ethernet/broadcom/tg3.c | 17 ++++++-----------
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index dbb41c1923e6..2dc001559a97 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -10540,19 +10540,14 @@ static int tg3_reset_hw(struct tg3 *tp, bool reset_phy)
udelay(100);
if (tg3_flag(tp, ENABLE_RSS)) {
+ u32 rss_key[10];
+
tg3_rss_write_indir_tbl(tp);
- /* Setup the "secret" hash key. */
- tw32(MAC_RSS_HASH_KEY_0, 0x5f865437);
- tw32(MAC_RSS_HASH_KEY_1, 0xe4ac62cc);
- tw32(MAC_RSS_HASH_KEY_2, 0x50103a45);
- tw32(MAC_RSS_HASH_KEY_3, 0x36621985);
- tw32(MAC_RSS_HASH_KEY_4, 0xbf14c0e8);
- tw32(MAC_RSS_HASH_KEY_5, 0x1bc27a1e);
- tw32(MAC_RSS_HASH_KEY_6, 0x84f4b556);
- tw32(MAC_RSS_HASH_KEY_7, 0x094ea6fe);
- tw32(MAC_RSS_HASH_KEY_8, 0x7dda01e7);
- tw32(MAC_RSS_HASH_KEY_9, 0xc04d7481);
+ netdev_rss_key_fill(rss_key, 10 * sizeof(u32));
+
+ for (i = 0; i < 10 ; i++)
+ tw32(MAC_RSS_HASH_KEY_0 + i*4, rss_key[i]);
}
tp->rx_mode = RX_MODE_ENABLE;
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 05/14] bna: use netdev_rss_key_fill() helper
From: Eric Dumazet @ 2014-11-16 14:23 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Thomas Lendacky, Ariel Elior, Michael Chan,
Prashant Sreedharan, Rasesh Mody, Sathya Perla, Subbu Seetharaman,
Ajit Khaparde, Jesse Brandeburg, Jeff Kirsher, Amir Vadai,
Shradha Shah, Shreyas Bhatewara, Eric Dumazet
In-Reply-To: <1416147798-16561-1-git-send-email-edumazet@google.com>
Use netdev_rss_key_fill() helper, as it provides better support for some
bonding setups.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Rasesh Mody <rasesh.mody@qlogic.com>
---
drivers/net/ethernet/brocade/bna/bnad.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/brocade/bna/bnad.c b/drivers/net/ethernet/brocade/bna/bnad.c
index c3861de9dc81..323721838cf9 100644
--- a/drivers/net/ethernet/brocade/bna/bnad.c
+++ b/drivers/net/ethernet/brocade/bna/bnad.c
@@ -2054,7 +2054,7 @@ bnad_init_rx_config(struct bnad *bnad, struct bna_rx_config *rx_config)
BFI_ENET_RSS_IPV4_TCP);
rx_config->rss_config.hash_mask =
bnad->num_rxp_per_rx - 1;
- get_random_bytes(rx_config->rss_config.toeplitz_hash_key,
+ netdev_rss_key_fill(rx_config->rss_config.toeplitz_hash_key,
sizeof(rx_config->rss_config.toeplitz_hash_key));
} else {
rx_config->rss_status = BNA_STATUS_T_DISABLED;
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 06/14] be2net:use netdev_rss_key_fill() helper
From: Eric Dumazet @ 2014-11-16 14:23 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Thomas Lendacky, Ariel Elior, Michael Chan,
Prashant Sreedharan, Rasesh Mody, Sathya Perla, Subbu Seetharaman,
Ajit Khaparde, Jesse Brandeburg, Jeff Kirsher, Amir Vadai,
Shradha Shah, Shreyas Bhatewara, Eric Dumazet
In-Reply-To: <1416147798-16561-1-git-send-email-edumazet@google.com>
Use netdev_rss_key_fill() helper, as it provides better support for some
bonding setups.
Rename rss_hkey local variable to rss_key to have consistent name among
drivers.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Sathya Perla <sathya.perla@emulex.com>
Cc: Subbu Seetharaman <subbu.seetharaman@emulex.com>
Cc: Ajit Khaparde <ajit.khaparde@emulex.com>
---
drivers/net/ethernet/emulex/benet/be_main.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index 9a18e7930b31..54160cc62656 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -2853,10 +2853,10 @@ static int be_close(struct net_device *netdev)
static int be_rx_qs_create(struct be_adapter *adapter)
{
+ struct rss_info *rss = &adapter->rss_info;
+ u8 rss_key[RSS_HASH_KEY_LEN];
struct be_rx_obj *rxo;
int rc, i, j;
- u8 rss_hkey[RSS_HASH_KEY_LEN];
- struct rss_info *rss = &adapter->rss_info;
for_all_rx_queues(adapter, rxo, i) {
rc = be_queue_alloc(adapter, &rxo->q, RX_Q_LEN,
@@ -2901,15 +2901,15 @@ static int be_rx_qs_create(struct be_adapter *adapter)
rss->rss_flags = RSS_ENABLE_NONE;
}
- get_random_bytes(rss_hkey, RSS_HASH_KEY_LEN);
+ netdev_rss_key_fill(rss_key, RSS_HASH_KEY_LEN);
rc = be_cmd_rss_config(adapter, rss->rsstable, rss->rss_flags,
- 128, rss_hkey);
+ 128, rss_key);
if (rc) {
rss->rss_flags = RSS_ENABLE_NONE;
return rc;
}
- memcpy(rss->rss_hkey, rss_hkey, RSS_HASH_KEY_LEN);
+ memcpy(rss->rss_hkey, rss_key, RSS_HASH_KEY_LEN);
/* First time posting */
for_all_rx_queues(adapter, rxo, i)
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 07/14] e100e: use netdev_rss_key_fill() helper
From: Eric Dumazet @ 2014-11-16 14:23 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Thomas Lendacky, Ariel Elior, Michael Chan,
Prashant Sreedharan, Rasesh Mody, Sathya Perla, Subbu Seetharaman,
Ajit Khaparde, Jesse Brandeburg, Jeff Kirsher, Amir Vadai,
Shradha Shah, Shreyas Bhatewara, Eric Dumazet
In-Reply-To: <1416147798-16561-1-git-send-email-edumazet@google.com>
Use of well known RSS key increases attack surface.
Switch to a random one, using generic helper so that all
ports share a common key.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index 247335d2c7ec..370cfa275ddb 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -3449,15 +3449,12 @@ static void e1000e_setup_rss_hash(struct e1000_adapter *adapter)
{
struct e1000_hw *hw = &adapter->hw;
u32 mrqc, rxcsum;
+ u32 rss_key[10];
int i;
- static const u32 rsskey[10] = {
- 0xda565a6d, 0xc20e5b25, 0x3d256741, 0xb08fa343, 0xcb2bcad0,
- 0xb4307bae, 0xa32dcb77, 0x0cf23080, 0x3bb7426a, 0xfa01acbe
- };
- /* Fill out hash function seed */
+ netdev_rss_key_fill(rss_key, sizeof(rss_key));
for (i = 0; i < 10; i++)
- ew32(RSSRK(i), rsskey[i]);
+ ew32(RSSRK(i), rss_key[i]);
/* Direct all traffic to queue 0 */
for (i = 0; i < 32; i++)
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 08/14] fm10k: use netdev_rss_key_fill() helper
From: Eric Dumazet @ 2014-11-16 14:23 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Thomas Lendacky, Ariel Elior, Michael Chan,
Prashant Sreedharan, Rasesh Mody, Sathya Perla, Subbu Seetharaman,
Ajit Khaparde, Jesse Brandeburg, Jeff Kirsher, Amir Vadai,
Shradha Shah, Shreyas Bhatewara, Eric Dumazet
In-Reply-To: <1416147798-16561-1-git-send-email-edumazet@google.com>
Use of well known RSS key increases attack surface.
Switch to a random one, using generic helper so that all
ports share a common key.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
---
drivers/net/ethernet/intel/fm10k/fm10k_pci.c | 10 +++-------
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/intel/fm10k/fm10k_pci.c b/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
index a0cb74ab3dc6..4f5892cc32d7 100644
--- a/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
+++ b/drivers/net/ethernet/intel/fm10k/fm10k_pci.c
@@ -1551,15 +1551,11 @@ void fm10k_down(struct fm10k_intfc *interface)
static int fm10k_sw_init(struct fm10k_intfc *interface,
const struct pci_device_id *ent)
{
- static const u32 seed[FM10K_RSSRK_SIZE] = { 0xda565a6d, 0xc20e5b25,
- 0x3d256741, 0xb08fa343,
- 0xcb2bcad0, 0xb4307bae,
- 0xa32dcb77, 0x0cf23080,
- 0x3bb7426a, 0xfa01acbe };
const struct fm10k_info *fi = fm10k_info_tbl[ent->driver_data];
struct fm10k_hw *hw = &interface->hw;
struct pci_dev *pdev = interface->pdev;
struct net_device *netdev = interface->netdev;
+ u32 rss_key[FM10K_RSSRK_SIZE];
unsigned int rss;
int err;
@@ -1673,8 +1669,8 @@ static int fm10k_sw_init(struct fm10k_intfc *interface,
/* initialize vxlan_port list */
INIT_LIST_HEAD(&interface->vxlan_port);
- /* initialize RSS key */
- memcpy(interface->rssrk, seed, sizeof(seed));
+ netdev_rss_key_fill(rss_key, sizeof(rss_key));
+ memcpy(interface->rssrk, rss_key, sizeof(rss_key));
/* Start off interface as being down */
set_bit(__FM10K_DOWN, &interface->state);
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 09/14] i40e: use netdev_rss_key_fill() helper
From: Eric Dumazet @ 2014-11-16 14:23 UTC (permalink / raw)
To: David S. Miller
Cc: netdev, Thomas Lendacky, Ariel Elior, Michael Chan,
Prashant Sreedharan, Rasesh Mody, Sathya Perla, Subbu Seetharaman,
Ajit Khaparde, Jesse Brandeburg, Jeff Kirsher, Amir Vadai,
Shradha Shah, Shreyas Bhatewara, Eric Dumazet
In-Reply-To: <1416147798-16561-1-git-send-email-edumazet@google.com>
Use of well known RSS key increases attack surface.
Switch to a random one, using generic helper so that all
ports share a common key.
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 10 +++-------
drivers/net/ethernet/intel/i40evf/i40evf_main.c | 11 +++--------
2 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c
index de664631c807..a0bee83ab2de 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -7002,20 +7002,16 @@ static int i40e_setup_misc_vector(struct i40e_pf *pf)
**/
static int i40e_config_rss(struct i40e_pf *pf)
{
- /* Set of random keys generated using kernel random number generator */
- static const u32 seed[I40E_PFQF_HKEY_MAX_INDEX + 1] = {0x41b01687,
- 0x183cfd8c, 0xce880440, 0x580cbc3c, 0x35897377,
- 0x328b25e1, 0x4fa98922, 0xb7d90c14, 0xd5bad70d,
- 0xcd15a2c1, 0xe8580225, 0x4a1e9d11, 0xfe5731be};
+ u32 rss_key[I40E_PFQF_HKEY_MAX_INDEX + 1];
struct i40e_hw *hw = &pf->hw;
u32 lut = 0;
int i, j;
u64 hena;
u32 reg_val;
- /* Fill out hash function seed */
+ netdev_rss_key_fill(rss_key, sizeof(rss_key));
for (i = 0; i <= I40E_PFQF_HKEY_MAX_INDEX; i++)
- wr32(hw, I40E_PFQF_HKEY(i), seed[i]);
+ wr32(hw, I40E_PFQF_HKEY(i), rss_key[i]);
/* By default we enable TCP/UDP with IPv4/IPv6 ptypes */
hena = (u64)rd32(hw, I40E_PFQF_HENA(0)) |
diff --git a/drivers/net/ethernet/intel/i40evf/i40evf_main.c b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
index f0d07ad54198..489227891ffb 100644
--- a/drivers/net/ethernet/intel/i40evf/i40evf_main.c
+++ b/drivers/net/ethernet/intel/i40evf/i40evf_main.c
@@ -1434,18 +1434,12 @@ static int next_queue(struct i40evf_adapter *adapter, int j)
**/
static void i40evf_configure_rss(struct i40evf_adapter *adapter)
{
+ u32 rss_key[I40E_VFQF_HKEY_MAX_INDEX + 1];
struct i40e_hw *hw = &adapter->hw;
u32 lut = 0;
int i, j;
u64 hena;
- /* Set of random keys generated using kernel random number generator */
- static const u32 seed[I40E_VFQF_HKEY_MAX_INDEX + 1] = {
- 0x794221b4, 0xbca0c5ab, 0x6cd5ebd9, 0x1ada6127,
- 0x983b3aa1, 0x1c4e71eb, 0x7f6328b2, 0xfcdc0da0,
- 0xc135cafa, 0x7a6f7e2d, 0xe7102d28, 0x163cd12e,
- 0x4954b126 };
-
/* No RSS for single queue. */
if (adapter->num_active_queues == 1) {
wr32(hw, I40E_VFQF_HENA(0), 0);
@@ -1454,8 +1448,9 @@ static void i40evf_configure_rss(struct i40evf_adapter *adapter)
}
/* Hash type is configured by the PF - we just supply the key */
+ netdev_rss_key_fill(rss_key, sizeof(rss_key));
for (i = 0; i <= I40E_VFQF_HKEY_MAX_INDEX; i++)
- wr32(hw, I40E_VFQF_HKEY(i), seed[i]);
+ wr32(hw, I40E_VFQF_HKEY(i), rss_key[i]);
/* Enable PCTYPES for RSS, TCP/UDP with IPv4/IPv6 */
hena = I40E_DEFAULT_RSS_HENA;
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
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