* Re: kernel BUG at include/net/netns/generic.h:41
From: Dave Jones @ 2012-04-25 22:58 UTC (permalink / raw)
To: Stanislav Kinsbursky
Cc: Myklebust, Trond, Linux Kernel, netdev@vger.kernel.org
In-Reply-To: <4F7DC4CC.9080502@parallels.com>
On Thu, Apr 05, 2012 at 08:14:04PM +0400, Stanislav Kinsbursky wrote:
> 05.04.2012 20:12, Dave Jones пишет:
> > On Thu, Apr 05, 2012 at 08:08:31PM +0400, Stanislav Kinsbursky wrote:
> >
> > > So, there are few questions to you, Dave:
> > > 1) can this happen (PipeFS mount attempt before SUNPRC module insertion has
> > > returned any value) in your case?
> >
> > I don't know enough of what systemd is doing to answer this.
> >
> > > 2) how often do you experience this problem? Not every boot, I suppose?
> > > 3) And is it easy for you to reproduce?
> >
> > It happens most the time, but not every time.
> >
>
> Ok, I'll send the patch soon.
> Hope, it will help.
>
> --
> Best regards,
> Stanislav Kinsbursky
I didn't see a follow-up patch on this, and I'm still seeing the BUG in rc4.
Dave
^ permalink raw reply
* Re: [net 1/2] e1000e: MSI interrupt test failed, using legacy interrupt
From: Prasanna Panchamukhi @ 2012-04-25 22:46 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Jeff Kirsher, davem, netdev, gospo, sassmann
In-Reply-To: <1335369547.2602.3.camel@bwh-desktop.uk.solarflarecom.com>
On 04/25/2012 08:59 AM, Ben Hutchings wrote:
> On Tue, 2012-04-24 at 22:55 -0700, Jeff Kirsher wrote:
>> From: Prasanna S Panchamukhi<ppanchamukhi@riverbed.com>
>>
>> Following logs where seen on Systems with multiple NICs,
>> while using MSI interrupts as shown below:
> [...]
>> This patch fixes this problem by increasing the msleep from 50 to 100.
> [...]
>
> It probably doesn't, in general. The out-of-tree version of the sfc
> driver used to perform an interrupt test during probe, and after fixing
> it up repeatedly I eventually had to remove it completely as there are
> so many ways to get a false negative. Also see the related commit
> 93e5dfa59b0e26a145a8adce5c9edf50bdaef4c7 ('sfc: Raise self-test
> timeouts').
>
Thanks Ben for your review.
In general Ben's approach looks good fix to avoid false negatives. To
give a little
bit of background, this issues is seen mostly with Intel 82571 Dual/quad
port Gigabit ethernet controller add-on NICs and not seen with other
Intel ethernet controller NICs. If Ben suggested
approach is the best way to go, I will provide a patch soon.
Thanks,
Prasanna
> Ben.
>
^ permalink raw reply
* Re: [PATCH] dl2k: Tighten ioctl permissions
From: Jeff Mahoney @ 2012-04-25 22:37 UTC (permalink / raw)
To: David Miller; +Cc: bhutchings, netdev
In-Reply-To: <20120425.182954.804210541527871356.davem@davemloft.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/25/2012 06:29 PM, David Miller wrote:
> From: Ben Hutchings <bhutchings@solarflare.com> Date: Wed, 25 Apr
> 2012 23:26:42 +0100
>
>> On Wed, 2012-04-25 at 15:33 -0400, Jeff Mahoney wrote:
>>> dl2k's rio_ioctl function defines several ioctls that involve
>>> operations that should be denied to regular users.
>>>
>>> SIOCDEVPRIVATE + 2 is a renumbered SIOCSMIIREG.
>>
>> There was an early convention that SIOCDEVPRIVATE + {0,1,2} were
>> MDIO operations. (This was a bad idea, because you can't safely
>> send them to an arbitrary driver... not that that stopped people
>> doing it. Now it's neither safe to send them from userland, nor
>> to implement any other semantics for these ioctl numbers in a
>> driver.)
>>
>> Please fix the numbering instead; it will make standard MII/MDIO
>> utilities work and the capability check (in dev_ioctl()) comes
>> for free.
>>
>>> SIOCDEVPRIVATE + 5 calls netif_stop_queue. SIOCDEVPRIVATE + 6
>>> calls netif_wake_queue.
>> [...]
>>
>> And SIOCDEVPRIVATE + {7,8} spam the kernel log, so they should
>> perhaps be considered privileged too.
>
> And I would also say that the netif_{stop,wake}_queue ones should
> just be deleted. There is no sane way, even as a debugging
> facility, we can let useland trigger these conditions.
>
> And if we could, it belongs in a generic facility no private
> ioctls which are heavily discouraged anyways.
>
> I seriously would suggest ditching all of these private ioctls
> from the dl2k driver, I bet no binary in the world out there even
> exists which handles these strange renumbered MII operations.
Ok. I expected this is what you'd say, but I don't usually play in the
network code or have one of these devices to do any testing with. I'll
kill off the private ioctls and switch the MDIO ones to the standard
interface.
- -Jeff
- --
Jeff Mahoney
SUSE Labs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJPmHyMAAoJEB57S2MheeWyC2YQAIiUSuC3TTQkFW0sDdrGIJtB
BSfxeSJVYN6SOmKWK9G6/AsTciB/9z/d3lQ6duJQCFTZCnUcCWcKN81iIHRJVZ32
5f97MBnPnSbZvjGyaHT3QNodH6Jq0uNQRHAXm5py7RZpDGmYCFuEr/h5QRibbiH2
IoYG3QMSGUZysOsqYqzk1aHokSfp8CTkoUKHAAyvbo911M6eFO/V6vEQs2ujojDT
PZfXGYVqkegOvC3HyGjDuQaoMpUYQC1Uz343mNB6ZJVOM7SCVfN2R4cJGCD6K78s
dxbVl68jCfdI8cB5xv1vmWCsZroRlgjxmCnwyM/ecz0IAtmeGNjQXLoQF67WXcV+
hgUgVpcFK0bqCgrtkR1wxMdmloQHlXVf53FFxhIjkJc/KuSalhqdbMdMzKbcGtU/
aqx+1rl937sr8Ffg82qzpUqsunTDmQMV1EB87CdW5ma2ZkjekA3dn8za74OlhP3M
hYzytw7Z9rQQt0v5a2FAvYopLDMWgtl8bEgJf2Dnhyrnez0E4iDzIdQq6oYbtipQ
xndTUTmHJvIGbJfhtfiUZgG3LhKbFR6a+nz+P+Pk7TRqcuFUTaak0SkCjTBUdPGO
TIO2GqFJeAQR3s8F2na2AVzXHXeQrNoWaNlhU0EOt9GARSc+WjftApDbSrB+chKm
DP+N7odTX93FIzZ2/chy
=8eUd
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] dl2k: Tighten ioctl permissions
From: David Miller @ 2012-04-25 22:29 UTC (permalink / raw)
To: bhutchings; +Cc: jeffm, netdev
In-Reply-To: <1335392802.2602.33.camel@bwh-desktop.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 25 Apr 2012 23:26:42 +0100
> On Wed, 2012-04-25 at 15:33 -0400, Jeff Mahoney wrote:
>> dl2k's rio_ioctl function defines several ioctls that involve
>> operations that should be denied to regular users.
>>
>> SIOCDEVPRIVATE + 2 is a renumbered SIOCSMIIREG.
>
> There was an early convention that SIOCDEVPRIVATE + {0,1,2} were MDIO
> operations. (This was a bad idea, because you can't safely send them to
> an arbitrary driver... not that that stopped people doing it. Now it's
> neither safe to send them from userland, nor to implement any other
> semantics for these ioctl numbers in a driver.)
>
> Please fix the numbering instead; it will make standard MII/MDIO
> utilities work and the capability check (in dev_ioctl()) comes for free.
>
>> SIOCDEVPRIVATE + 5 calls netif_stop_queue.
>> SIOCDEVPRIVATE + 6 calls netif_wake_queue.
> [...]
>
> And SIOCDEVPRIVATE + {7,8} spam the kernel log, so they should perhaps
> be considered privileged too.
And I would also say that the netif_{stop,wake}_queue ones should just
be deleted. There is no sane way, even as a debugging facility, we
can let useland trigger these conditions.
And if we could, it belongs in a generic facility no private ioctls
which are heavily discouraged anyways.
I seriously would suggest ditching all of these private ioctls from
the dl2k driver, I bet no binary in the world out there even exists
which handles these strange renumbered MII operations.
^ permalink raw reply
* Re: [PATCH] dl2k: Tighten ioctl permissions
From: Ben Hutchings @ 2012-04-25 22:26 UTC (permalink / raw)
To: Jeff Mahoney; +Cc: Network Development
In-Reply-To: <4F985197.1060607@suse.com>
On Wed, 2012-04-25 at 15:33 -0400, Jeff Mahoney wrote:
> dl2k's rio_ioctl function defines several ioctls that involve
> operations that should be denied to regular users.
>
> SIOCDEVPRIVATE + 2 is a renumbered SIOCSMIIREG.
There was an early convention that SIOCDEVPRIVATE + {0,1,2} were MDIO
operations. (This was a bad idea, because you can't safely send them to
an arbitrary driver... not that that stopped people doing it. Now it's
neither safe to send them from userland, nor to implement any other
semantics for these ioctl numbers in a driver.)
Please fix the numbering instead; it will make standard MII/MDIO
utilities work and the capability check (in dev_ioctl()) comes for free.
> SIOCDEVPRIVATE + 5 calls netif_stop_queue.
> SIOCDEVPRIVATE + 6 calls netif_wake_queue.
[...]
And SIOCDEVPRIVATE + {7,8} spam the kernel log, so they should perhaps
be considered privileged too.
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: wireless: mwifiex: initial commit for Marvell mwifiex driver
From: Bing Zhao @ 2012-04-25 22:08 UTC (permalink / raw)
To: Dan Carpenter; +Cc: netdev@vger.kernel.org
In-Reply-To: <20120425084445.GA12799@elgon.mountain>
Hi Dan,
> Hi Bing,
>
> The patch 5e6e3a92b9a4: "wireless: mwifiex: initial commit for
> Marvell mwifiex driver" from Mar 21, 2011, leads to the following
> static checker warning:
>
> drivers/net/wireless/mwifiex/sta_ioctl.c:1410
> mwifiex_set_gen_ie_helper()
> error: memcmp() 'pvendor_ie->oui' too small (3 vs 4)
Thanks for catching this error.
>
> 1390 mwifiex_set_gen_ie_helper(struct mwifiex_private *priv, u8 *ie_data_ptr,
> 1391 u16 ie_len)
> 1392 {
> 1393 int ret = 0;
> 1394 struct ieee_types_vendor_header *pvendor_ie;
> 1395 const u8 wpa_oui[] = { 0x00, 0x50, 0xf2, 0x01 };
> ^^^^^^^^^^^^^^^^^^^^^^^^^^
> 4 byte array.
The last byte 0x01 is actually the oui_type.
...
u8 oui[3];
u8 oui_type;
...
>
> 1396 const u8 wps_oui[] = { 0x00, 0x50, 0xf2, 0x04 };
> 1397
> 1398 /* If the passed length is zero, reset the buffer */
> 1399 if (!ie_len) {
> 1400 priv->gen_ie_buf_len = 0;
> 1401 priv->wps.session_enable = false;
> 1402
> 1403 return 0;
> 1404 } else if (!ie_data_ptr) {
> 1405 return -1;
> 1406 }
> 1407 pvendor_ie = (struct ieee_types_vendor_header *) ie_data_ptr;
> 1408 /* Test to see if it is a WPA IE, if not, then it is a gen IE */
> 1409 if (((pvendor_ie->element_id == WLAN_EID_WPA) &&
> 1410 (!memcmp(pvendor_ie->oui, wpa_oui, sizeof(wpa_oui)))) ||
> ^^^^^^^^^^^^^^^
> ->oui is only a 3 byte array so we're reading past the end for this
> comparison.
I will fix the misuse of memcmp's.
By the way, could you please share with me how you check for this kind of errors?
Is it coccinelle? I tried with coccicheck but got "spatch.opt unknown option -D" error.
Thanks,
Bing
>
> 1411 (pvendor_ie->element_id == WLAN_EID_RSN)) {
>
>
> There are a couple other similar warnings as well:
>
> drivers/net/wireless/mwifiex/sta_ioctl.c:1435 mwifiex_set_gen_ie_helper()
> error: memcmp() 'pvendor_ie->oui' too small (3 vs 4)
> drivers/net/wireless/mwifiex/scan.c:1177 mwifiex_update_bss_desc_with_ie()
> error: memcmp() 'vendor_ie->vend_hdr.oui' too small (3 vs 4)
> drivers/net/wireless/mwifiex/scan.c:1185 mwifiex_update_bss_desc_with_ie()
> error: memcmp() 'vendor_ie->vend_hdr.oui' too small (3 vs 4)
>
> regards,
> dan carpenter
^ permalink raw reply
* Re: pull request: wireless-next 2012-04-25
From: David Miller @ 2012-04-25 20:39 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20120425191418.GC16900@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 25 Apr 2012 15:14:19 -0400
> This is another batch of updates intended for 3.5...
...
> Please let me know if there are problems!
There are:
>From 792545c7bc5d6b922d3778dc602e557d64c83551 Mon Sep 17 00:00:00 2001
From: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>
Date: Mon, 23 Apr 2012 19:55:48 -0700
Subject: [PATCH 88/88] libertas: include sched.h on firmware.c
Do not assume we have our subsystem including this for us,
at least for older kernels this is not true. Lets just be
explicit about this requirement for the usage of wake_up().
Signed-off-by: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This is bogus, wake_up() is defined in linux/wait.h, the whole
point of the linux/sched.h split up is so that linux/sched.h
includes could be removed and replaced with actual dependencies.
Also, please don't accept any patches from Luis that add those
#undef pr_fmt things to the atheros drivers.
He tried to add it an ethernet driver, and I asked him to explain
exactly why he's doing and that if it's appropriate then it's
appropriate everywhere not just in a few specific drivers. He failed
to respond to me, and therefore failed to explain the situation and
address my concerned. And then I saw just today that he's submitting
the same patch to wireless drivers. That's not acceptable.
Thanks.
^ permalink raw reply
* RE: [PATCH 12/14 v2] usb/net: rndis: merge command codes
From: Haiyang Zhang @ 2012-04-25 20:39 UTC (permalink / raw)
To: Linus Walleij, netdev@vger.kernel.org, linux-usb@vger.kernel.org,
Greg Kroah-Hartman, David S. Miller, Felipe Balbi
Cc: Jussi Kivilinna, Wei Yongjun, Ben Hutchings
In-Reply-To: <1335368163-4792-1-git-send-email-linus.walleij@linaro.org>
> -----Original Message-----
> From: Linus Walleij [mailto:linus.walleij@linaro.org]
> Sent: Wednesday, April 25, 2012 11:36 AM
> To: netdev@vger.kernel.org; linux-usb@vger.kernel.org; Greg Kroah-Hartman;
> David S. Miller; Felipe Balbi
> Cc: Jussi Kivilinna; Haiyang Zhang; Wei Yongjun; Ben Hutchings; Linus
> Walleij
> Subject: [PATCH 12/14 v2] usb/net: rndis: merge command codes
>
> Switch the hyperv filter and rndis gadget driver to use the same command
> enumerators as the other drivers and delete the surplus command codes.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> drivers/net/hyperv/rndis_filter.c | 42 ++++++++++++++++++--------------
> ----
> drivers/usb/gadget/rndis.c | 37 +++++++++++++++----------------
> include/linux/rndis.h | 17 ---------------
> 3 files changed, 39 insertions(+), 57 deletions(-)
>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
^ permalink raw reply
* RE: [PATCH 04/14 v2] usb/net: rndis: remove ambigous status codes
From: Haiyang Zhang @ 2012-04-25 20:39 UTC (permalink / raw)
To: Linus Walleij, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Greg Kroah-Hartman, David S. Miller, Felipe Balbi
Cc: Jussi Kivilinna, Wei Yongjun, Ben Hutchings
In-Reply-To: <1335367825-4324-1-git-send-email-linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> -----Original Message-----
> From: Linus Walleij [mailto:linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org]
> Sent: Wednesday, April 25, 2012 11:30 AM
> To: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Greg Kroah-Hartman;
> David S. Miller; Felipe Balbi
> Cc: Jussi Kivilinna; Haiyang Zhang; Wei Yongjun; Ben Hutchings; Linus
> Walleij
> Subject: [PATCH 04/14 v2] usb/net: rndis: remove ambigous status codes
>
> The RNDIS status codes are redefined with much stranged ifdeffery
> and only one of these codes was used in the hyperv driver, and
> there it is very clearly referring to the RNDIS variant, not some
> other status. So clarify this by explictly using the RNDIS_*
> prefixed status code in the hyperv drivera and delete the
> duplicate defines.
>
> Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> ---
> drivers/net/hyperv/rndis_filter.c | 4 ++--
> include/linux/rndis.h | 31 +++----------------------------
> 2 files changed, 5 insertions(+), 30 deletions(-)
>
Reviewed-by: Haiyang Zhang <haiyangz-0li6OtcxBFHby3iVrkZq2A@public.gmane.org>
--
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 02/14 v2] usb/net: rndis: break out <linux/rndis.h> defines
From: Haiyang Zhang @ 2012-04-25 20:38 UTC (permalink / raw)
To: Linus Walleij, netdev@vger.kernel.org, linux-usb@vger.kernel.org,
Greg Kroah-Hartman, David S. Miller, Felipe Balbi
Cc: Jussi Kivilinna, Wei Yongjun, Ben Hutchings
In-Reply-To: <1335367808-4254-1-git-send-email-linus.walleij@linaro.org>
> -----Original Message-----
> From: Linus Walleij [mailto:linus.walleij@linaro.org]
> Sent: Wednesday, April 25, 2012 11:30 AM
> To: netdev@vger.kernel.org; linux-usb@vger.kernel.org; Greg Kroah-Hartman;
> David S. Miller; Felipe Balbi
> Cc: Jussi Kivilinna; Haiyang Zhang; Wei Yongjun; Ben Hutchings; Linus
> Walleij
> Subject: [PATCH 02/14 v2] usb/net: rndis: break out <linux/rndis.h>
> defines
>
> As a first step to consolidate the RNDIS implementations, break out
> a common file with all the #defines and move it to <linux/rndis.h>.
> The compilation screams about double-defines all over the place
> (as could be expected, this is why we're consolidating) but it
> compiles cleanly still.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> drivers/net/hyperv/hyperv_net.h | 290 +-----------------
> drivers/net/wireless/rndis_wlan.c | 49 ---
> drivers/usb/gadget/ndis.h | 164 ----------
> drivers/usb/gadget/rndis.h | 48 +---
> include/linux/rndis.h | 615
> +++++++++++++++++++++++++++++++++++++
> include/linux/usb/rndis_host.h | 66 +----
> 6 files changed, 619 insertions(+), 613 deletions(-)
> create mode 100644 include/linux/rndis.h
>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
^ permalink raw reply
* RE: [PATCH 00/14 v2] usb/net: rndis: first step toward consolidation
From: Haiyang Zhang @ 2012-04-25 20:36 UTC (permalink / raw)
To: Linus Walleij, netdev@vger.kernel.org, linux-usb@vger.kernel.org,
Greg Kroah-Hartman, David S. Miller, Felipe Balbi
Cc: Jussi Kivilinna, Wei Yongjun, Ben Hutchings, KY Srinivasan
In-Reply-To: <1335367783-4184-1-git-send-email-linus.walleij@linaro.org>
> -----Original Message-----
> From: Linus Walleij [mailto:linus.walleij@linaro.org]
> Sent: Wednesday, April 25, 2012 11:30 AM
> To: netdev@vger.kernel.org; linux-usb@vger.kernel.org; Greg Kroah-Hartman;
> David S. Miller; Felipe Balbi
> Cc: Jussi Kivilinna; Haiyang Zhang; Wei Yongjun; Ben Hutchings; Linus
> Walleij
> Subject: [PATCH 00/14 v2] usb/net: rndis: first step toward consolidation
>
> A second spin of the RNDIS unification patches.
> Jussi Kivilinna pointed out an error where I was joining
> "media" and "physical media" in patch 9, this was all wrong
> so now I've fixed it up.
>
> Please test!
>
> If this thing works I guess it should propagate through
> dmillers tree eventually.
>
> Linus Walleij (14):
> usb/net: rndis: inline the cpu_to_le32() macro
> usb/net: rndis: break out <linux/rndis.h> defines
> usb/net: rndis: remove duplicate definitions
> usb/net: rndis: remove ambigous status codes
> usb/net: rndis: eliminate first set of duplicate OIDs
> usb/net: rndis: merge duplicate 802_* OIDs
> usb/net: rndis: delete surplus defines
> usb/net: rndis: group all status codes together
> usb/net: rndis: merge media type definitions
> usb/net: rndis: delete duplicate packet types
> usb/net: rndis: move and namespace PnP defines
> usb/net: rndis: merge command codes
> usb/net: rndis: fixup a few name prefixes
> usb/net: rndis: move bus message definition
>
> drivers/net/hyperv/hyperv_net.h | 290 +---------------------------
> drivers/net/hyperv/rndis_filter.c | 46 +++---
> drivers/net/usb/rndis_host.c | 52 +++---
> drivers/net/wireless/rndis_wlan.c | 295 ++++++++++++----------------
> drivers/usb/gadget/f_rndis.c | 6 +-
> drivers/usb/gadget/ndis.h | 164 ----------------
> drivers/usb/gadget/rndis.c | 271 +++++++++++++-------------
> drivers/usb/gadget/rndis.h | 48 +-----
> include/linux/rndis.h | 390
> +++++++++++++++++++++++++++++++++++++
> include/linux/usb/rndis_host.h | 66 +------
> 10 files changed, 706 insertions(+), 922 deletions(-)
> create mode 100644 include/linux/rndis.h
>
> --
> 1.7.7.6
>
I tested Hyper-V netvsc driver, it works fine with the patches.
Thanks,
- Haiyang
^ permalink raw reply
* Re: [PATCH 1/2] ss: fix the incorrect value of total UNIX_DIAG_* number
From: Stephen Hemminger @ 2012-04-25 20:21 UTC (permalink / raw)
To: Shan Wei; +Cc: xemul, NetDev
In-Reply-To: <4F97A484.2040300@gmail.com>
On Wed, 25 Apr 2012 15:15:16 +0800
Shan Wei <shanwei88@gmail.com> wrote:
> From: Shan Wei <davidshan@tencent.com>
>
> UNIX_DIAG_MAX is included in enum type.
> It is equal to the total number of enum element.
>
> But lots of enum MAX value is defined as the max enum element, e.g. INET_DIAG_MAX, XFRMA_MAX.
> The right fixing way seems to define UNIX_DIAG_MAX as UNIX_DIAG_MEMINFO,
> but this way will break other user application.
>
> So, just fix it on user application.
>
>
> Signed-off-by: Shan Wei <davidshan@tencent.com>
> ---
> misc/ss.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/misc/ss.c b/misc/ss.c
> index 4017918..5f70a26 100644
> --- a/misc/ss.c
> +++ b/misc/ss.c
> @@ -2011,12 +2011,12 @@ void unix_list_print(struct unixstat *list, struct filter *f)
> static int unix_show_sock(struct nlmsghdr *nlh, struct filter *f)
> {
> struct unix_diag_msg *r = NLMSG_DATA(nlh);
> - struct rtattr *tb[UNIX_DIAG_MAX+1];
> + struct rtattr *tb[UNIX_DIAG_MAX];
> char name[128];
> int peer_ino;
> int rqlen;
>
> - parse_rtattr(tb, UNIX_DIAG_MAX, (struct rtattr*)(r+1),
> + parse_rtattr(tb, UNIX_DIAG_MAX-1, (struct rtattr*)(r+1),
> nlh->nlmsg_len - NLMSG_LENGTH(sizeof(*r)));
>
> if (netid_width)
Ok, I'll put this in but with a big juicy comment so that nobody
else is surprised by the fact we got it wrong here.
^ permalink raw reply
* Re: [patch v3, iproute2 version 3.2.0] Source mode for macvlan interface
From: Stephen Hemminger @ 2012-04-25 20:17 UTC (permalink / raw)
To: Stefan Gula; +Cc: netdev
In-Reply-To: <10839102.1251327929240954.JavaMail.root@5-MeO-DMT.ynet.sk>
On Mon, 30 Jan 2012 14:14:00 +0100 (CET)
Stefan Gula <steweg@ynet.sk> wrote:
> From: Stefan Gula <steweg@gmail.com>
>
> Adjusting iproute2 utility to support new macvlan link type mode
> called "source". Example of commands that can be applied:
> ip link add link eth0 name macvlan0 type macvlan mode source
> ip link set link macvlan0 type macvlan macaddr add 00:11:11:11:11:11
> ip link set link macvlan0 type macvlan macaddr del 00:11:11:11:11:11
> ip link set link macvlan0 type macvlan macaddr flush
>
> Signed-off-by: Stefan Gula <steweg@gmail.com>
>
Please resubmit with man page, after the kernel header changes are in
Linus's tree (ie. 3.5 merge window).
^ permalink raw reply
* Re: [PATCH iproute2] pedit action: add mask for changing bits.
From: Stephen Hemminger @ 2012-04-25 20:15 UTC (permalink / raw)
To: jhs; +Cc: hadi, Anton 'EvilMan' Danilov, netdev
In-Reply-To: <1330524080.18226.21.camel@mojatatu>
On Wed, 29 Feb 2012 09:01:20 -0500
jamal <hadi@cyberus.ca> wrote:
> Hi Anton,
>
> On Wed, 2012-02-29 at 16:12 +0300, Anton 'EvilMan' Danilov wrote:
>
> >
> > You are right, mask option isn't needed. Retain option must be used instead it.
> >
>
> Thanks for verifying.
>
> > Action to work on Vlans is fine idea. I'm very interested in this
> > action. I'll be grateful for any help.
>
> Lets start by defining the interface to be seen by user space
> such as vlan editing/popping/pushing etc. Then i will help you
> build it slowly until you are comfortable with moving with it.
>
> As a matter of fact, lets talk offline so we dont add more noise
> to the list; you can always post the RFC to the list when you are
> ready.
>
> cheers,
> jamal
Did you come to a conclusion, should it be applied as is?
^ permalink raw reply
* Re: [PATCH 1/2] iproute2: allow IPv6 addresses for l2tp local and remote parameters
From: Stephen Hemminger @ 2012-04-25 20:13 UTC (permalink / raw)
To: James Chapman; +Cc: netdev, Chris Elston
In-Reply-To: <1334921383-32109-2-git-send-email-jchapman@katalix.com>
On Fri, 20 Apr 2012 12:29:42 +0100
James Chapman <jchapman@katalix.com> wrote:
> From: Chris Elston <celston@katalix.com>
>
> Adds support for parsing IPv6 addresses to the parameters local and
> remote in the l2tp commands. Requires netlink attributes L2TP_ATTR_IP6_SADDR
> and L2TP_ATTR_IP6_DADDR, added in a required kernel patch already submitted
> to netdev.
>
> Also enables printing of IPv6 addresses returned by the L2TP_CMD_TUNNEL_GET
> request.
>
> Signed-off-by: Chris Elston <celston@katalix.com>
> Signed-off-by: James Chapman <jchapman@katalix.com>
Accepted.
^ permalink raw reply
* Re: [PATCH] unix_diag: use netlink attribute MAX convention
From: David Miller @ 2012-04-25 20:12 UTC (permalink / raw)
To: shemminger; +Cc: shanwei88, xemul, netdev
In-Reply-To: <20120425130906.7a090d22@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 25 Apr 2012 13:09:06 -0700
> That doesn't work, not asking original submitter to resubmit.
It works every single time for me.
If they don't resubmit, they don't really care about their work being
included, and therefore neither should you.
End of story.
^ permalink raw reply
* Re: [PATCH 2/2] iproute2: add ip-l2tp man page
From: Stephen Hemminger @ 2012-04-25 20:11 UTC (permalink / raw)
To: James Chapman; +Cc: netdev
In-Reply-To: <1334921383-32109-3-git-send-email-jchapman@katalix.com>
On Fri, 20 Apr 2012 12:29:43 +0100
James Chapman <jchapman@katalix.com> wrote:
> Add a man page to cover the "ip l2tp" commands. Add a reference to it
> in the main ip page.
>
> Signed-off-by: James Chapman <jchapman@katalix.com>
> ---
> man/man8/ip-l2tp.8 | 350 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> man/man8/ip.8 | 3 +-
> 2 files changed, 352 insertions(+), 1 deletions(-)
> create mode 100644 man/man8/ip-l2tp.8
>
> diff --git a/man/man8/ip-l2tp.8 b/man/man8/ip-l2tp.8
> new file mode 100644
> index 0000000..c115e7c
> --- /dev/null
> +++ b/man/man8/ip-l2tp.8
> @@ -0,0 +1,350 @@
> +.TH IP\-L2TP 8 "19 Apr 2012" "iproute2" "Linux"
> +.SH "NAME"
> +ip-l2tp - L2TPv3 static unmanaged tunnel configuration
> +.SH "SYNOPSIS"
> +.sp
> +.ad l
> +.in +8
> +.ti -8
> +.B ip
> +.RI "[ " OPTIONS " ]"
> +.B l2tp
> +.RI " { " COMMAND " | "
> +.BR help " }"
> +.sp
> +.ti -8
> +.BR "ip l2tp add tunnel"
> +.br
> +.B remote
> +.RI "[ " ADDR " ]"
> +.B local
> +.RI "[ " ADDR " ]"
> +.br
> +.B tunnel_id
> +.IR ID
> +.B peer_tunnel_id
> +.IR ID
> +.br
> +.RB "[ " encap " { " ip " | " udp " } ]"
> +.br
> +.RB "[ " udp_sport
> +.IR PORT
> +.RB " ] [ " udp_dport
> +.IR PORT
> +.RB " ]"
> +.br
> +.ti -8
> +.BR "ip l2tp add session"
> +.RB "[ " name
> +.IR NAME
> +.RB " ]"
> +.br
> +.B tunnel_id
> +.IR ID
> +.B session_id
> +.IR ID
> +.B peer_session_id
> +.IR ID
> +.br
> +.RB "[ " cookie
> +.IR HEXSTR
> +.RB " ] [ " peer_cookie
> +.IR HEXSTR
> +.RB " ]"
> +.br
> +.RB "[ " offset
> +.IR OFFSET
> +.RB " ] [ " peer_offset
> +.IR OFFSET
> +.RB " ]"
> +.br
> +.ti -8
> +.BR "ip l2tp del tunnel"
> +.B tunnel_id
> +.IR ID
> +.br
> +.ti -8
> +.BR "ip l2tp del session"
> +.B tunnel_id
> +.IR ID
> +.B session_id
> +.IR ID
> +.br
> +.ti -8
> +.BR "ip l2tp show tunnel"
> +.B "[" tunnel_id
> +.IR ID
> +.B "]"
> +.br
> +.ti -8
> +.BR "ip l2tp show session"
> +.B "[" tunnel_id
> +.IR ID
> +.B "] [" session_id
> +.IR ID
> +.B "]"
> +.br
> +.ti -8
> +.IR NAME " := "
> +.IR STRING
> +.ti -8
> +.IR ADDR " := { " IP_ADDRESS " }"
> +.ti -8
> +.IR PORT " := { " NUMBER " }"
> +.ti -8
> +.IR ID " := { " NUMBER " }"
> +.ti -8
> +.ti -8
> +.IR HEXSTR " := { 8 or 16 hex digits (4 / 8 bytes) }"
> +.SH DESCRIPTION
> +The
> +.B ip l2tp
> +commands are used to establish static, or so-called
> +.I unmanaged
> +L2TPv3 ethernet tunnels. For unmanaged tunnels, there is no L2TP
> +control protocol so no userspace daemon is required - tunnels are
> +manually created by issuing commands at a local system and at a remote
> +peer.
> +.PP
> +L2TPv3 is suitable for Layer-2 tunnelling. Static tunnels are useful
> +to establish network links across IP networks when the tunnels are
> +fixed. L2TPv3 tunnels can carry data of more than one session. Each
> +session is identified by a session_id and its parent tunnel's
> +tunnel_id. A tunnel must be created before a session can be created in
> +the tunnel.
> +.PP
> +When creating an L2TP tunnel, the IP address of the remote peer is
> +specified, which can be either an IPv4 or IPv6 address. The local IP
> +address to be used to reach the peer must also be specified. This is
> +the address on which the local system will listen for and accept
> +received L2TP data packets from the peer.
> +.PP
> +L2TPv3 defines two packet encapsulation formats: UDP or IP. UDP
> +encapsulation is most common. IP encapsulation uses a dedicated IP
> +protocol value to carry L2TP data without the overhead of UDP. Use IP
> +encapsulation only when there are no NAT devices or firewalls in the
> +network path.
> +.PP
> +When an L2TPv3 ethernet session is created, a virtual network
> +interface is created for the session, which must then be configured
> +and brought up, just like any other network interface. When data is
> +passed through the interface, it is carried over the L2TP tunnel to
> +the peer. By configuring the system's routing tables or adding the
> +interface to a bridge, the L2TP interface is like a virtual wire
> +(pseudowire) connected to the peer.
> +.PP
> +Establishing an unmanaged L2TPv3 ethernet pseudowire involves manually
> +creating L2TP contexts on the local system and at the peer. Parameters
> +used at each site must correspond or no data will be passed. No
> +consistency checks are possible since there is no control protocol
> +used to establish unmanaged L2TP tunnels. Once the virtual network
> +interface of a given L2TP session is configured and enabled, data can
> +be transmitted, even if the peer isn't yet configured. If the peer
> +isn't configured, the L2TP data packets will be discarded by
> +the peer.
> +.PP
> +To establish an unmanaged L2TP tunnel, use
> +.B l2tp add tunnel
> +and
> +.B l2tp add session
> +commands described in this document. Then configure and enable the
> +tunnel's virtual network interface, as required.
> +.PP
> +Note that unmanaged tunnels carry only ethernet frames. If you need to
> +carry PPP traffic (L2TPv2) or your peer doesn't support unmanaged
> +L2TPv3 tunnels, you will need an L2TP server which implements the L2TP
> +control protocol. The L2TP control protocol allows dynamic L2TP
> +tunnels and sessions to be established and provides for detecting and
> +acting upon network failures.
> +.SS ip l2tp add tunnel - add a new tunnel
> +.TP
> +.BI name " NAME "
> +sets the session network interface name. Default is l2tpethN.
> +.TP
> +.BI tunnel_id " ID"
> +set the tunnel id, which is a 32-bit integer value. Uniquely
> +identifies the tunnel. The value used must match the peer_tunnel_id
> +value being used at the peer.
> +.TP
> +.BI peer_tunnel_id " ID"
> +set the peer tunnel id, which is a 32-bit integer value assigned to
> +the tunnel by the peer. The value used must match the tunnel_id value
> +being used at the peer.
> +.TP
> +.BI remote " ADDR"
> +set the IP address of the remote peer. May be specified as an IPv4
> +address or an IPv6 address.
> +.TP
> +.BI local " ADDR"
> +set the IP address of the local interface to be used for the
> +tunnel. This address must be the address of a local interface. May be
> +specified as an IPv4 address or an IPv6 address.
> +.TP
> +.BI encap " ENCAP"
> +set the encapsulation type of the tunnel.
> +.br
> +Valid values for encapsulation are:
> +.BR udp ", " ip "."
> +.TP
> +.BI udp_sport " PORT"
> +set the UDP source port to be used for the tunnel. Must be present
> +when udp encapsulation is selected. Ignored when ip encapsulation is
> +selected.
> +.TP
> +.BI udp_dport " PORT"
> +set the UDP destination port to be used for the tunnel. Must be
> +present when udp encapsulation is selected. Ignored when ip
> +encapsulation is selected.
> +.SS ip l2tp del tunnel - destroy a tunnel
> +.TP
> +.BI tunnel_id " ID"
> +set the tunnel id of the tunnel to be deleted. All sessions within the
> +tunnel must be deleted first.
> +.SS ip l2tp show tunnel - show information about tunnels
> +.TP
> +.BI tunnel_id " ID"
> +set the tunnel id of the tunnel to be shown. If not specified,
> +information about all tunnels is printed.
> +.SS ip l2tp add session - add a new session to a tunnel
> +.TP
> +.BI name " NAME "
> +sets the session network interface name. Default is l2tpethN.
> +.TP
> +.BI tunnel_id " ID"
> +set the tunnel id, which is a 32-bit integer value. Uniquely
> +identifies the tunnel into which the session will be created. The
> +tunnel must already exist.
> +.TP
> +.BI session_id " ID"
> +set the session id, which is a 32-bit integer value. Uniquely
> +identifies the session being created. The value used must match the
> +peer_session_id value being used at the peer.
> +.TP
> +.BI peer_session_id " ID"
> +set the peer session id, which is a 32-bit integer value assigned to
> +the session by the peer. The value used must match the session_id
> +value being used at the peer.
> +.TP
> +.BI cookie " HEXSTR"
> +sets an optional cookie value to be assigned to the session. This is a
> +4 or 8 byte value, specified as 8 or 16 hex digits,
> +e.g. 014d3636deadbeef. The value must match the peer_cookie value set
> +at the peer. The cookie value is carried in L2TP data packets and is
> +checked for expected value at the peer. Default is to use no cookie.
> +.TP
> +.BI peer_cookie " HEXSTR"
> +sets an optional peer cookie value to be assigned to the session. This
> +is a 4 or 8 byte value, specified as 8 or 16 hex digits,
> +e.g. 014d3636deadbeef. The value must match the cookie value set at
> +the peer. It tells the local system what cookie value to expect to
> +find in received L2TP packets. Default is to use no cookie.
> +.TP
> +.BI offset " OFFSET"
> +sets the byte offset from the L2TP header where user data starts in
> +transmitted L2TP data packets. This is hardly ever used. If set, the
> +value must match the peer_offset value used at the peer. Default is 0.
> +.TP
> +.BI peer_offset " OFFSET"
> +sets the byte offset from the L2TP header where user data starts in
> +received L2TP data packets. This is hardly ever used. If set, the
> +value must match the offset value used at the peer. Default is 0.
> +.SS ip l2tp del session - destroy a session
> +.TP
> +.BI tunnel_id " ID"
> +set the tunnel id in which the session to be deleted is located.
> +.TP
> +.BI session_id " ID"
> +set the session id of the session to be deleted.
> +.SS ip l2tp show session - show information about sessions
> +.TP
> +.BI tunnel_id " ID"
> +set the tunnel id of the session(s) to be shown. If not specified,
> +information about sessions in all tunnels is printed.
> +.TP
> +.BI session_id " ID"
> +set the session id of the session to be shown. If not specified,
> +information about all sessions is printed.
> +.SH EXAMPLES
> +.PP
> +.SS Setup L2TP tunnels and sessions
> +.nf
> +site-A:# ip l2tp add tunnel tunnel_id 3000 peer_tunnel_id 4000 \\
> + encap udp local 1.2.3.4 remote 5.6.7.8 \\
> + udp_sport 5000 udp_dport 6000
> +site-A:# ip l2tp add session tunnel_id 3000 session_id 1000 \\
> + peer_session_id 2000
> +
> +site-B:# ip l2tp add tunnel tunnel_id 4000 peer_tunnel_id 3000 \\
> + encap udp local 5.6.7.8 remote 1.2.3.4 \\
> + udp_sport 6000 udp_dport 5000
> +site-B:# ip l2tp add session tunnel_id 4000 session_id 2000 \\
> + peer_session_id 1000
> +
> +site-A:# ip link set l2tpeth0 up mtu 1488
> +
> +site-B:# ip link set l2tpeth0 up mtu 1488
> +.fi
> +.PP
> +Notice that the IP addresses, UDP ports and tunnel / session ids are
> +matched and reversed at each site.
> +.SS Configure as IP interfaces
> +The two interfaces can be configured with IP addresses if only IP data
> +is to be carried. This is perhaps the simplest configuration.
> +.PP
> +.nf
> +site-A:# ip addr add 10.42.1.1 peer 10.42.1.2 dev l2tpeth0
> +
> +site-B:# ip addr add 10.42.1.2 peer 10.42.1.1 dev l2tpeth0
> +
> +site-A:# ping 10.42.1.2
> +.fi
> +.PP
> +Now the link should be usable. Add static routes as needed to have
> +data sent over the new link.
> +.PP
> +.SS Configure as bridged interfaces
> +To carry non-IP data, the L2TP network interface is added to a bridge
> +instead of being assigned its own IP address, using standard Linux
> +utilities.
> +.PP
> +.nf
> +site-A:# brctl addbr br0
> +site-A:# brctl addif br0 l2tpeth0
> +site-A:# brctl addif br0 eth0
> +site-A:# ip link set br0 up promisc on
> +.fi
> +.PP
> +If you are using VLANs, setup a bridge per VLAN and bridge each VLAN
> +over a separate L2TP session. For example, to bridge VLAN ID 5 on eth1
> +over an L2TP pseudowire:
> +.PP
> +.nf
> +site-A:# brctl addbr brvlan5
> +site-A:# brctl addif brvlan5 l2tpeth0.5
> +site-A:# brctl addif brvlan5 eth1.5
> +site-A:# ip link set brvlan5 up promisc on
The bridge manages promiscuous itself, setting it manually is not required.
If it is required, the the implementation of the device is buggy
and should be fixed.
^ permalink raw reply
* This will make you smile ;)
From: Shannon Lavenia @ 2012-04-25 18:07 UTC (permalink / raw)
To: netdev
Hi,
Thanks for taking a minute to read this message.
I know your time is valuable and I appreciate it. That's
why I'm sending you this note. You will benefit from it,
I promise.
http://www.boldstatementmarketing.com/video3
Like you, I am self-employed. I've had a lot
of success and have done millions in sales but it's
been a roller coaster. There's been huge wins and
big losses. The wins drive me further and the losses...
well, they keep me humble and keep me learning ;)
I've felt the frustration of trying to find new
clients and customers and it's gotten down-right
dirty online...
the competition is stiff, Google's just slapping
everyone (yep...I've been spanked by Google too)
and it was getting harder and harder to grow my lists and
customer base.
Not to mention expensive. About a year ago, I transitioned
everything to offline marketing and that was just tedious, slow
and, I have to admit, boring.
I was determined to figure out how to get the same or better
lead flow that I was getting back in 2007 with Google before
they got spank happy.
It took us almost a year, but we figured it out. I can't believe
it even took us that long because this is so ridiculously simple...
It was right under our noses the entire time. Every major brand
is doing it. All the big marketers are doing it.
And now we're doing it and it is bringing in a flood of traffic,
leads and sales faster than anything we've done before.
Our results now are blowing away what we saw back with Google
Adwords before they got all funky.
You might already be using this to grow your business...if you are
congratulations, because I know you're killing it!
If not, learn how now (for fr.ee).
http://www.boldstatementmarketing.com/video3
Just click the link and sign up to get instant access to the fast start
course for fr.ee and you'll know exactly how to get more leads,
more customers and a freakin' flood of sales.
I'm excited for you to watch the training. The playing field is wide
open with this...I'm still shocked by how few business are actually
using this strategy because it's so darn easy and the results are
shocking.
Have fun ;)
Shannon Lavenia
PS: John (my husband) and I are driven by the comments we get
so leave me a note about the training on the site...I appreciate it and
love to hear how your succeeding with this training.
Peace.
http://www.boldstatementmarketing.com/video3
^ permalink raw reply
* Re: [PATCH] unix_diag: use netlink attribute MAX convention
From: Stephen Hemminger @ 2012-04-25 20:09 UTC (permalink / raw)
To: David Miller; +Cc: shanwei88, xemul, netdev
In-Reply-To: <20120425.155717.2099319998110521099.davem@davemloft.net>
On Wed, 25 Apr 2012 15:57:17 -0400 (EDT)
David Miller <davem@davemloft.net> wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Wed, 25 Apr 2012 12:47:43 -0700
>
> > On Wed, 25 Apr 2012 15:07:16 -0400 (EDT)
> > David Miller <davem@davemloft.net> wrote:
> >
> >> Either you apply them as soon as possible, or you mark them
> >> appropriately as "Changes Requested" or "Deferred" so that the
> >> submitter makes appropriate fixes you've asked for, or resubmits when
> >> it's more appropriate for the change to go in.
> >>
> >> "Under Review" doesn't mean, "I'm waiting for a kernel release with
> >> the feature". But that's how you use it.
> >
> > Ok. What is the suggested tag for that.
>
> As I said above, "Deferred", with a note sent to the submitter to resubmit
> the patch at the appropriate time.
That doesn't work, not asking original submitter to resubmit.
I tried a branch, but git doesn't like branches coming and going
on remote repos.
Probably better to just have an ephemeral iproute2-next repo on kernel.org.
^ permalink raw reply
* Re: [PATCH] unix_diag: use netlink attribute MAX convention
From: David Miller @ 2012-04-25 19:57 UTC (permalink / raw)
To: shemminger; +Cc: shanwei88, xemul, netdev
In-Reply-To: <20120425124743.5b4fb8a3@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 25 Apr 2012 12:47:43 -0700
> On Wed, 25 Apr 2012 15:07:16 -0400 (EDT)
> David Miller <davem@davemloft.net> wrote:
>
>> Either you apply them as soon as possible, or you mark them
>> appropriately as "Changes Requested" or "Deferred" so that the
>> submitter makes appropriate fixes you've asked for, or resubmits when
>> it's more appropriate for the change to go in.
>>
>> "Under Review" doesn't mean, "I'm waiting for a kernel release with
>> the feature". But that's how you use it.
>
> Ok. What is the suggested tag for that.
As I said above, "Deferred", with a note sent to the submitter to resubmit
the patch at the appropriate time.
^ permalink raw reply
* Re: [PATCH] unix_diag: use netlink attribute MAX convention
From: Stephen Hemminger @ 2012-04-25 19:47 UTC (permalink / raw)
To: David Miller; +Cc: shanwei88, xemul, netdev
In-Reply-To: <20120425.150716.1476178549121153876.davem@davemloft.net>
On Wed, 25 Apr 2012 15:07:16 -0400 (EDT)
David Miller <davem@davemloft.net> wrote:
> From: Stephen Hemminger <shemminger@vyatta.com>
> Date: Wed, 25 Apr 2012 11:56:09 -0700
>
> > Do you expect the one utility to use it to have a workaround for
> > a broken initial version.
>
> I'm not taking that risk.
>
> They thought the same exact thing when they did the autofs struct size
> compat fix, and it turned out to break things.
>
> Stephen I have an awesome suggestion for you if you want to avoid this
> in the future, review iproute2 patches more aggressively so you can
> catch things like this earlier. Like, when we can actually still
> safely change things.
Sorry it was more of cross project issue in this case. The original
kernel patch had the problem and was lost in the fog of the other
issues like the unix diag implementation not building.
A community works best if multiple people look at the code.
Don't think I would have spotted it unless I compared it to
other places.
> Because currently you let patches rot in patchwork. There's an
> iproute2 patch in there assigned to you which is 3 months old, that
> simply isn't how this is supposed to work.
>
> I hate to keep beating a dead horse, but you don't stay on top of
> patchwork like you should. The object is not to let patches just
> rot in "Under Review" state for months.
I keep patches that are for -next in that state.
> Either you apply them as soon as possible, or you mark them
> appropriately as "Changes Requested" or "Deferred" so that the
> submitter makes appropriate fixes you've asked for, or resubmits when
> it's more appropriate for the change to go in.
>
> "Under Review" doesn't mean, "I'm waiting for a kernel release with
> the feature". But that's how you use it.
Ok. What is the suggested tag for that.
^ permalink raw reply
* [PATCH] dl2k: Tighten ioctl permissions
From: Jeff Mahoney @ 2012-04-25 19:33 UTC (permalink / raw)
To: Network Development
dl2k's rio_ioctl function defines several ioctls that involve
operations that should be denied to regular users.
SIOCDEVPRIVATE + 2 is a renumbered SIOCSMIIREG.
SIOCDEVPRIVATE + 5 calls netif_stop_queue.
SIOCDEVPRIVATE + 6 calls netif_wake_queue.
Reported-by: Stephan Mueller <stephan.mueller@atsec.com>
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
---
drivers/net/ethernet/dlink/dl2k.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/drivers/net/ethernet/dlink/dl2k.c
+++ b/drivers/net/ethernet/dlink/dl2k.c
@@ -1264,6 +1264,14 @@ rio_ioctl (struct net_device *dev, struc
struct netdev_desc *desc;
int i;
+ switch (cmd) {
+ case SIOCDEVPRIVATE + 2:
+ case SIOCDEVPRIVATE + 5:
+ case SIOCDEVPRIVATE + 6:
+ if (!capable(CAP_NET_ADMIN))
+ return -EPERM;
+ };
+
phy_addr = np->phy_addr;
switch (cmd) {
case SIOCDEVPRIVATE:
--
Jeff Mahoney
SUSE Labs
^ permalink raw reply
* pull request: wireless-next 2012-04-25
From: John W. Linville @ 2012-04-25 19:14 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev
[-- Attachment #1: Type: text/plain, Size: 14527 bytes --]
commit 77ae367f6496b067b9ba53fbb6e8356bd71b6e3e
Dave,
This is another batch of updates intended for 3.5...
Nothing too special this round -- highlights include some iwlwifi
refactoring, some ath9k refactoring, some rtlwifi refactoring, and
some mac80211 mesh refactoring. It must be Springtime! Along with
all the refactoring, there is the usual variety of random tweaks here
and there in the wireless stack.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 872f24dbc604ef585ea7eec73020dcdfaffd1956:
tipc: remove inline instances from C source files. (2012-04-24 00:41:03 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next.git for-davem
Amitkumar Karwar (1):
mwifiex: add support for Marvell USB8797 chipset
Andrei Emeltchenko (1):
mac80211: Adds clean sdata helper
Anisse Astier (2):
rt2800: debugfs register access: BBP is 256 bytes big
rt2800: add chipset revision RT5390R support
Bala Shanmugam (1):
cfg80211: Validate legacy rateset.
Ben Greear (2):
mac80211: Support on-channel scan option.
ath9k: Fix compile warnings when DEBUGFS is disabled.
Daniel Drake (1):
libertas CS: convert to asynchronous firmware loading
David Spinadel (4):
iwlwifi: Change disable calibration bit-set to enum
iwlwifi: Added foreward declaration for iwl_cfg in op_mode
iwlwifi: Remove inconsistent and redundant declaration
iwlwifi: Added debugfs calib disabled write
Don Fry (1):
iwlwifi: revert workaround to restore 1000 rx throughput
Emmanuel Grumbach (16):
iwlwifi: kill shrd->drv, driver points to transport
iwlwifi: op_mode holds its pointer to the transport
iwlwifi: op_mode holds its pointer to the config
iwlwifi: driver holds its pointer to the config
iwlwifi: transport holds its pointer to the config
iwlwifi: driver holds its pointer to the transport
iwlwifi: don't use shared for the logger any more
iwlwifi: remove the shared area
iwlwifi: remove unneeded includes
iwlwifi: split between AGG_ON and AGG_STARTING
iwlwifi: move iwl_rxon_context_id to user
iwlwifi: make a static inline to read the RF kill register
iwlwifi: first enable RF kill interrupt, then check register
iwlwifi: enable RF kill interrupt in start_hw
iwlwifi: check RF kill register when interrupts have been disabled
iwlwifi: provide proper API to disable all interrupts
Felix Fietkau (12):
ath9k: add possible wiphy interface combinations
libertas: add missing include
ath9k_hw: use standard SIFS time as reference for half/quarter channels
ath9k_hw: increase ACK timeout for half/quarter channels
ath9k_hw: set the PHY mode for half/quarter channels on AR9003
ath9k_hw: increase symbol overlap window for half/quarter channels
ath9k_hw: fix and clean up PHY activation delay
ath9k_hw: disable Tx IQ calibration on half/quarter channels
ath9k_hw: disable fast channel change when changing from/to half/quarter mode
ath9k_hw: increase tx abort timeout for half/quarter channels
mac80211: rename AP variable num_sta_authorized to num_mcast_sta
mac80211: fix num_mcast_sta counting issues
Gabor Juhos (1):
ath9k: fix TX power reporting on AR9003 chips
Helmut Schaa (1):
rt2x00: Use GFP_KERNEL for rx buffer allocation on USB devices
Javier Cardona (1):
mac80211: fixup for mesh TSF adjustment latency in Toffset setpoint
Johannes Berg (22):
iwlwifi: improve TX cache footprint
iwlwifi: properly set basic rates
iwlwifi: remove debugfs logspam
iwlwifi: move debugfs registration function declarations
iwlwifi: move iwl_have_debug_level
iwlwifi: clean up iwl-shared.h includes
iwlwifi: remove bt_siso_mode declaration
iwlwifi: move TIME_UNIT
iwlwifi: move iwl_cmd_echo_test
iwlwifi: remove traffic log
iwlwifi: remove TX/RX frame statistics
iwlwifi: remove duplicate iwlagn_mod_params declaration
iwlwifi: move driver defines to iwl-drv.h
iwlwifi: move PLCP defines to config
iwlwifi: move watchdog definitions to config
iwlwifi: move eeprom versions to HW files
iwlwifi: move antenna definitions to config
iwlwifi: move OTP defines
iwlwifi: clean up some hw file includes
iwlwifi: use direct calls for transport free
iwlwifi: clean up module parameters
iwlwifi: use new mac80211 queue scheme
John W. Linville (1):
Merge branch 'master' of git://git.kernel.org/.../linville/wireless-next into for-davem
Larry Finger (6):
rtlwifi: Move dig_t and ps_t structs
rtlwifi: Add dm structs to private structure
rtlwifi: rtl8192c: Convert driver to use private dm structs
rtlwifi: rtl8192c: Convert driver to use private ps_t struct
rtlwifi: rtl8192de: Convert driver to use private dm structs
rtlwifi: rtl8192se: Convert driver to use private dm struct
Luis R. Rodriguez (1):
libertas: include sched.h on firmware.c
Michael Liang (1):
ath9k: don't strip mic on non-encrypted frames in tkip
Rajkumar Manoharan (2):
ath9k: simplify beacon configuration for beaconing vifs
ath9k_hw: remove ATH_BTCOEX_CFG_MCI
Sujith Manoharan (1):
ath9k: Fix IDLE Powersave
Thomas Pedersen (4):
mac80211: refactor mesh peer initialization
mac80211: refactor mesh peer rate handling
mac80211: don't set mesh peer ht caps if ht disabled
mac80211: fix STA channel width field
Wey-Yi Guy (3):
mac80211: declare ieee80211_ave_rssi as EXPORT
iwlwifi: include net/mac80211.h to avoid compiler error
mac80211: check for non-managed interface
Xose Vazquez Perez (2):
wireless: rt2x00: rt2800usb add more devices ids
wireless: rt2x00: rt2800usb more devices were identified
Zefir Kurtisi (2):
ath9k: make DFS detector pools SMP safe
ath9k: extend DFS detector stats in dfs_debugfs
drivers/net/wireless/ath/ath9k/ar5008_phy.c | 17 +-
drivers/net/wireless/ath/ath9k/ar9003_calib.c | 10 +-
drivers/net/wireless/ath/ath9k/ar9003_eeprom.c | 64 +-
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 28 +-
drivers/net/wireless/ath/ath9k/ar9003_phy.h | 3 +
drivers/net/wireless/ath/ath9k/beacon.c | 4 +-
drivers/net/wireless/ath/ath9k/btcoex.c | 14 +-
drivers/net/wireless/ath/ath9k/btcoex.h | 1 -
drivers/net/wireless/ath/ath9k/dfs.c | 4 +
drivers/net/wireless/ath/ath9k/dfs_debug.c | 46 +
drivers/net/wireless/ath/ath9k/dfs_debug.h | 45 +-
drivers/net/wireless/ath/ath9k/dfs_pri_detector.c | 130 ++-
drivers/net/wireless/ath/ath9k/gpio.c | 21 +-
drivers/net/wireless/ath/ath9k/hw.c | 42 +-
drivers/net/wireless/ath/ath9k/hw.h | 5 +-
drivers/net/wireless/ath/ath9k/init.c | 21 +
drivers/net/wireless/ath/ath9k/mac.c | 10 +-
drivers/net/wireless/ath/ath9k/main.c | 105 +--
drivers/net/wireless/ath/ath9k/recv.c | 3 +-
drivers/net/wireless/iwlwifi/Makefile | 2 +-
drivers/net/wireless/iwlwifi/iwl-1000.c | 8 +-
drivers/net/wireless/iwlwifi/iwl-2000.c | 8 +-
drivers/net/wireless/iwlwifi/iwl-5000.c | 9 +-
drivers/net/wireless/iwlwifi/iwl-6000.c | 17 +-
drivers/net/wireless/iwlwifi/iwl-agn-calib.c | 9 +-
drivers/net/wireless/iwlwifi/iwl-agn-calib.h | 1 -
drivers/net/wireless/iwlwifi/iwl-agn-devices.c | 25 +-
drivers/net/wireless/iwlwifi/iwl-agn-hw.h | 11 +
drivers/net/wireless/iwlwifi/iwl-agn-lib.c | 42 +-
drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 12 +-
drivers/net/wireless/iwlwifi/iwl-agn-rs.h | 36 +-
drivers/net/wireless/iwlwifi/iwl-agn-rx.c | 22 +-
drivers/net/wireless/iwlwifi/iwl-agn-rxon.c | 128 ++-
drivers/net/wireless/iwlwifi/iwl-agn-sta.c | 1 -
drivers/net/wireless/iwlwifi/iwl-agn-tt.c | 18 +-
drivers/net/wireless/iwlwifi/iwl-agn-tx.c | 61 +-
drivers/net/wireless/iwlwifi/iwl-agn.c | 308 ++----
drivers/net/wireless/iwlwifi/iwl-agn.h | 26 +-
drivers/net/wireless/iwlwifi/iwl-config.h | 28 +
drivers/net/wireless/iwlwifi/iwl-core.c | 297 ------
drivers/net/wireless/iwlwifi/iwl-core.h | 133 ---
drivers/net/wireless/iwlwifi/iwl-debug.c | 1 +
drivers/net/wireless/iwlwifi/iwl-debug.h | 34 +-
drivers/net/wireless/iwlwifi/iwl-debugfs.c | 309 ++-----
drivers/net/wireless/iwlwifi/iwl-dev.h | 99 +--
drivers/net/wireless/iwlwifi/iwl-drv.c | 151 +++-
drivers/net/wireless/iwlwifi/iwl-drv.h | 25 +-
drivers/net/wireless/iwlwifi/iwl-eeprom.c | 64 +-
drivers/net/wireless/iwlwifi/iwl-eeprom.h | 53 -
drivers/net/wireless/iwlwifi/iwl-fw.h | 1 +
drivers/net/wireless/iwlwifi/iwl-io.h | 1 -
drivers/net/wireless/iwlwifi/iwl-led.c | 21 +-
drivers/net/wireless/iwlwifi/iwl-mac80211.c | 88 +-
.../iwlwifi/{iwl-shared.h => iwl-modparams.h} | 78 +--
drivers/net/wireless/iwlwifi/iwl-op-mode.h | 2 +
drivers/net/wireless/iwlwifi/iwl-pci.c | 60 +-
drivers/net/wireless/iwlwifi/iwl-phy-db.c | 5 +-
drivers/net/wireless/iwlwifi/iwl-phy-db.h | 4 +-
drivers/net/wireless/iwlwifi/iwl-power.c | 19 +-
drivers/net/wireless/iwlwifi/iwl-power.h | 9 -
drivers/net/wireless/iwlwifi/iwl-scan.c | 13 +-
drivers/net/wireless/iwlwifi/iwl-testmode.c | 27 +-
drivers/net/wireless/iwlwifi/iwl-trans-pcie-int.h | 43 +-
drivers/net/wireless/iwlwifi/iwl-trans-pcie-rx.c | 11 +-
drivers/net/wireless/iwlwifi/iwl-trans-pcie-tx.c | 35 +-
drivers/net/wireless/iwlwifi/iwl-trans-pcie.c | 184 ++--
drivers/net/wireless/iwlwifi/iwl-trans.h | 49 +-
drivers/net/wireless/iwlwifi/iwl-ucode.c | 25 +-
drivers/net/wireless/libertas/firmware.c | 2 +
drivers/net/wireless/libertas/if_cs.c | 88 +-
drivers/net/wireless/mwifiex/11n_aggr.c | 36 +-
drivers/net/wireless/mwifiex/Kconfig | 11 +
drivers/net/wireless/mwifiex/Makefile | 3 +
drivers/net/wireless/mwifiex/cmdevt.c | 63 +-
drivers/net/wireless/mwifiex/decl.h | 1 +
drivers/net/wireless/mwifiex/fw.h | 5 +
drivers/net/wireless/mwifiex/init.c | 64 +-
drivers/net/wireless/mwifiex/main.c | 26 +-
drivers/net/wireless/mwifiex/main.h | 20 +-
drivers/net/wireless/mwifiex/sta_cmd.c | 2 +-
drivers/net/wireless/mwifiex/sta_rx.c | 15 +-
drivers/net/wireless/mwifiex/sta_tx.c | 12 +-
drivers/net/wireless/mwifiex/txrx.c | 21 +-
drivers/net/wireless/mwifiex/usb.c | 1052 ++++++++++++++++++++
drivers/net/wireless/mwifiex/usb.h | 99 ++
drivers/net/wireless/mwifiex/util.c | 22 +
drivers/net/wireless/mwifiex/wmm.c | 18 +-
drivers/net/wireless/rt2x00/rt2800.h | 3 +-
drivers/net/wireless/rt2x00/rt2800lib.c | 12 +
drivers/net/wireless/rt2x00/rt2800usb.c | 25 +-
drivers/net/wireless/rt2x00/rt2x00.h | 2 +-
drivers/net/wireless/rt2x00/rt2x00dev.c | 4 +-
drivers/net/wireless/rt2x00/rt2x00lib.h | 2 +-
drivers/net/wireless/rt2x00/rt2x00pci.c | 2 +-
drivers/net/wireless/rt2x00/rt2x00queue.c | 6 +-
drivers/net/wireless/rt2x00/rt2x00usb.c | 2 +-
drivers/net/wireless/rtlwifi/rtl8192c/dm_common.c | 290 +++---
drivers/net/wireless/rtlwifi/rtl8192c/dm_common.h | 35 -
drivers/net/wireless/rtlwifi/rtl8192c/phy_common.c | 1 +
drivers/net/wireless/rtlwifi/rtl8192ce/dm.h | 35 -
drivers/net/wireless/rtlwifi/rtl8192de/dm.c | 185 ++--
drivers/net/wireless/rtlwifi/rtl8192de/dm.h | 51 -
drivers/net/wireless/rtlwifi/rtl8192de/phy.c | 7 +-
drivers/net/wireless/rtlwifi/rtl8192se/dm.c | 156 ++--
drivers/net/wireless/rtlwifi/rtl8192se/dm.h | 44 -
drivers/net/wireless/rtlwifi/rtl8192se/phy.c | 7 +-
drivers/net/wireless/rtlwifi/wifi.h | 63 ++
include/net/mac80211.h | 8 +
net/mac80211/cfg.c | 19 +
net/mac80211/debugfs_netdev.c | 4 +-
net/mac80211/ieee80211_i.h | 5 +-
net/mac80211/iface.c | 19 +-
net/mac80211/main.c | 4 +-
net/mac80211/mesh.c | 19 +-
net/mac80211/mesh.h | 14 +-
net/mac80211/mesh_plink.c | 138 ++--
net/mac80211/mesh_sync.c | 2 +-
net/mac80211/rx.c | 2 +
net/mac80211/scan.c | 95 ++-
net/mac80211/sta_info.c | 12 +-
net/mac80211/tx.c | 2 +-
net/mac80211/util.c | 9 +-
net/wireless/nl80211.c | 3 +
123 files changed, 3468 insertions(+), 2565 deletions(-)
delete mode 100644 drivers/net/wireless/iwlwifi/iwl-core.c
delete mode 100644 drivers/net/wireless/iwlwifi/iwl-core.h
rename drivers/net/wireless/iwlwifi/{iwl-shared.h => iwl-modparams.h} (66%)
create mode 100644 drivers/net/wireless/mwifiex/usb.c
create mode 100644 drivers/net/wireless/mwifiex/usb.h
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: pull request: wireless 2012-04-25
From: David Miller @ 2012-04-25 19:14 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20120425180639.GA16900-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Wed, 25 Apr 2012 14:06:39 -0400
> This is a batch of fixes intended for 3.4.
>
> The brcmsmac patch from Eldad Zack eliminates some log spam.
> The mac80211 patch from Eliad Peller fixes a WARNING when removing
> an interface. The two patches from Gabor Juhos combine to address
> a regression with some bad tx power settings for an Atheros chip.
> Johannes Berg gives us a fix for some bad hardware initializtion in
> iwlwifi, which resulted in hardware lockups. Larry Finger gives us
> a fix for an oops when unloading the rtlwifi modules. Meenakshi
> Venkataraman fixes some firmware version values in iwlwifi that
> result in attempts to load firmware that does not exist in the wild.
> Stanislav Yakovlev fixes a race condition in the ipw2200 driver.
> Finally, Stanislaw Gruszka provides an iwlwifi fix to avoid a NULL
> pointer access.
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] unix_diag: use netlink attribute MAX convention
From: David Miller @ 2012-04-25 19:07 UTC (permalink / raw)
To: shemminger; +Cc: shanwei88, xemul, netdev
In-Reply-To: <20120425115609.4ef9ece0@nehalam.linuxnetplumber.net>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Wed, 25 Apr 2012 11:56:09 -0700
> Do you expect the one utility to use it to have a workaround for
> a broken initial version.
I'm not taking that risk.
They thought the same exact thing when they did the autofs struct size
compat fix, and it turned out to break things.
Stephen I have an awesome suggestion for you if you want to avoid this
in the future, review iproute2 patches more aggressively so you can
catch things like this earlier. Like, when we can actually still
safely change things.
Because currently you let patches rot in patchwork. There's an
iproute2 patch in there assigned to you which is 3 months old, that
simply isn't how this is supposed to work.
I hate to keep beating a dead horse, but you don't stay on top of
patchwork like you should. The object is not to let patches just
rot in "Under Review" state for months.
Either you apply them as soon as possible, or you mark them
appropriately as "Changes Requested" or "Deferred" so that the
submitter makes appropriate fixes you've asked for, or resubmits when
it's more appropriate for the change to go in.
"Under Review" doesn't mean, "I'm waiting for a kernel release with
the feature". But that's how you use it.
^ 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