* Re: [RFC net-next 2/4] gianfar: Clear ievent from interrupt handler for [RT]x int
From: Paul Gortmaker @ 2012-08-08 16:11 UTC (permalink / raw)
To: Claudiu Manoil; +Cc: netdev, David S. Miller
In-Reply-To: <1344428810-29923-3-git-send-email-claudiu.manoil@freescale.com>
[[RFC net-next 2/4] gianfar: Clear ievent from interrupt handler for [RT]x int] On 08/08/2012 (Wed 15:26) Claudiu Manoil wrote:
> It's the interrupt handler's job to clear ievent for the Tx/Rx paths, as soon
> as the corresponding interrupt sources have been masked.
What wasn't clear to me was whether we'd ever have an instance of
gfar_poll run without RTX_MASK being cleared (in less normal conditions,
like netconsole, KGDBoE etc), since the gfar_schedule_cleanup is only
called from rx/tx IRQ threads, and neither of those are used by
gfar_poll, it seems.
Paul.
--
>
> Signed-off-by: Claudiu Manoil <claudiu.manoil@freescale.com>
> ---
> drivers/net/ethernet/freescale/gianfar.c | 16 ++++++----------
> 1 files changed, 6 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
> index e9feeb9..ddd350a 100644
> --- a/drivers/net/ethernet/freescale/gianfar.c
> +++ b/drivers/net/ethernet/freescale/gianfar.c
> @@ -2568,12 +2568,13 @@ static void gfar_schedule_cleanup(struct gfar_priv_grp *gfargrp)
> if (napi_schedule_prep(&gfargrp->napi)) {
> gfar_write(&gfargrp->regs->imask, IMASK_RTX_DISABLED);
> __napi_schedule(&gfargrp->napi);
> - } else {
> - /* Clear IEVENT, so interrupts aren't called again
> - * because of the packets that have already arrived.
> - */
> - gfar_write(&gfargrp->regs->ievent, IEVENT_RTX_MASK);
> }
> +
> + /* Clear IEVENT, so interrupts aren't called again
> + * because of the packets that have already arrived.
> + */
> + gfar_write(&gfargrp->regs->ievent, IEVENT_RTX_MASK);
> +
> spin_unlock_irqrestore(&gfargrp->grplock, flags);
>
> }
> @@ -2837,11 +2838,6 @@ static int gfar_poll(struct napi_struct *napi, int budget)
> num_queues = gfargrp->num_rx_queues;
> budget_per_queue = budget/num_queues;
>
> - /* Clear IEVENT, so interrupts aren't called again
> - * because of the packets that have already arrived
> - */
> - gfar_write(®s->ievent, IEVENT_RTX_MASK);
> -
> while (num_queues && left_over_budget) {
> budget_per_queue = left_over_budget/num_queues;
> left_over_budget = 0;
> --
> 1.6.6
>
>
^ permalink raw reply
* Re: [RFC net-next 0/4] gianfar: Use separate NAPI for Tx confirmation processing
From: Paul Gortmaker @ 2012-08-08 16:24 UTC (permalink / raw)
To: Claudiu Manoil; +Cc: netdev, David S. Miller
In-Reply-To: <1344428810-29923-1-git-send-email-claudiu.manoil@freescale.com>
[[RFC net-next 0/4] gianfar: Use separate NAPI for Tx confirmation processing] On 08/08/2012 (Wed 15:26) Claudiu Manoil wrote:
> Hi all,
> This set of patches basically splits the existing napi poll routine into
> two separate napi functions, one for Rx processing (triggered by frame
> receive interrupts only) and one for the Tx confirmation path processing
> (triggerred by Tx confirmation interrupts only). The polling algorithm
> behind remains much the same.
>
> Important throughput improvements have been noted on low power boards with
> this set of changes.
> For instance, for the following netperf test:
> netperf -l 20 -cC -H 192.168.10.1 -t TCP_STREAM -- -m 1500
> yields a throughput gain from oscilating ~500-~700 Mbps to steady ~940 Mbps,
> (if the Rx/Tx paths are processed on different cores), w/ no increase in CPU%,
> on a p1020rdb - 2 core machine featuring etsec2.0 (Multi-Queue Multi-Group
> driver mode).
It would be interesting to know more about what was causing that large
an oscillation -- presumably you will have it reappear once one core
becomes 100% utilized. Also, any thoughts on how the change will change
performance on an older low power single core gianfar system (e.g. 83xx)?
P.
--
>
> Also, this change, which should ballance Rx and Tx processing, proves to
> be effective against Rx busy interrupt occurrences.
>
> Thanks for your review.
> Claudiu
>
>
> Claudiu Manoil (4):
> gianfar: Remove redundant programming of [rt]xic registers
> gianfar: Clear ievent from interrupt handler for [RT]x int
> gianfar: Separate out the Rx and Tx coalescing functions
> gianfar: Use separate NAPIs for Tx and Rx processing
>
> drivers/net/ethernet/freescale/gianfar.c | 220 +++++++++++++++++++++--------
> drivers/net/ethernet/freescale/gianfar.h | 16 ++-
> 2 files changed, 171 insertions(+), 65 deletions(-)
>
>
^ permalink raw reply
* Re: [RFC net-next 0/4] gianfar: Use separate NAPI for Tx confirmation processing
From: Eric Dumazet @ 2012-08-08 16:44 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: Claudiu Manoil, netdev, David S. Miller
In-Reply-To: <20120808162423.GC11043@windriver.com>
On Wed, 2012-08-08 at 12:24 -0400, Paul Gortmaker wrote:
> [[RFC net-next 0/4] gianfar: Use separate NAPI for Tx confirmation processing] On 08/08/2012 (Wed 15:26) Claudiu Manoil wrote:
>
> > Hi all,
> > This set of patches basically splits the existing napi poll routine into
> > two separate napi functions, one for Rx processing (triggered by frame
> > receive interrupts only) and one for the Tx confirmation path processing
> > (triggerred by Tx confirmation interrupts only). The polling algorithm
> > behind remains much the same.
> >
> > Important throughput improvements have been noted on low power boards with
> > this set of changes.
> > For instance, for the following netperf test:
> > netperf -l 20 -cC -H 192.168.10.1 -t TCP_STREAM -- -m 1500
> > yields a throughput gain from oscilating ~500-~700 Mbps to steady ~940 Mbps,
> > (if the Rx/Tx paths are processed on different cores), w/ no increase in CPU%,
> > on a p1020rdb - 2 core machine featuring etsec2.0 (Multi-Queue Multi-Group
> > driver mode).
>
> It would be interesting to know more about what was causing that large
> an oscillation -- presumably you will have it reappear once one core
> becomes 100% utilized. Also, any thoughts on how the change will change
> performance on an older low power single core gianfar system (e.g. 83xx)?
I also was wondering if this low performance could be caused by BQL
Since TCP stack is driven by incoming ACKS, a NAPI run could have to
handle 10 TCP acks in a row, and resulting xmits could hit BQL and
transit on qdisc (Because NAPI handler wont handle TX completions in the
middle of RX handler)
So experiments would be nice, maybe by reducing a
bit /proc/sys/net/ipv4/tcp_limit_output_bytes
(from 131072 to 65536 or 32768)
^ permalink raw reply
* Re: [PATCH] can/softing: Fix potential memory leak in softing_load_fw()
From: Marc Kleine-Budde @ 2012-08-08 17:18 UTC (permalink / raw)
To: Alexey Khoroshilov
Cc: Kurt Van Dijck, Wolfgang Grandegger, linux-can, netdev,
linux-kernel, ldv-project
In-Reply-To: <1344438901-25005-1-git-send-email-khoroshilov@ispras.ru>
[-- Attachment #1: Type: text/plain, Size: 603 bytes --]
On 08/08/2012 05:15 PM, Alexey Khoroshilov wrote:
> Do not leak memory by updating pointer with potentially NULL realloc return value.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Thanks for the work,
applied to can/master.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* Re: [PATCH v6 7/7] ARM: davinci: add support for the am1808 based enbw_cmc board
From: Sekhar Nori @ 2012-08-08 17:35 UTC (permalink / raw)
To: Heiko Schocher
Cc: Kevin Hilman,
davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/,
Wolfgang Denk, netdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ, Wolfram Sang,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, Ben Dooks, Scott Wood,
Sylwester Nawrocki, David Woodhouse,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1341492608-20597-1-git-send-email-hs-ynQEQJNshbs@public.gmane.org>
Hi Heiko,
On 7/5/2012 6:20 PM, Heiko Schocher wrote:
> - AM1808 based board
> - 64 MiB DDR ram
> - 2 MiB Nor flash
> - 128 MiB NAND flash
> - use internal RTC
> - I2C support
> - hwmon lm75 support
> - UBI/UBIFS support
> - MMC support
> - USB OTG support
>
> Signed-off-by: Heiko Schocher <hs-ynQEQJNshbs@public.gmane.org>
> Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
> Cc: davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org
> Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Cc: David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
> Cc: Ben Dooks <ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org>
> Cc: Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Cc: Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>
> Cc: Kevin Hilman <khilman-l0cyMroinI0@public.gmane.org>
> Cc: Wolfgang Denk <wd-ynQEQJNshbs@public.gmane.org>
> Cc: Scott Wood <scottwood-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> Cc: Sylwester Nawrocki <s.nawrocki-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
>
> ---
> - post this board support with USB support, even though
> USB is only working with the 10 ms "workaround", posted here:
> http://comments.gmane.org/gmane.linux.usb.general/54505
> I see this issue also on the AM1808 TMDXEXP1808L evalboard.
> - MMC and USB are not using OF support yet, ideas how to port
> this are welcome. I need for USB and MMC boards board
> specific callbacks, how to solve this with OF support?
>
> - changes for v2:
> - changes in the nand node due to comments from Scott Wood:
> - add "ti,davinci-" prefix
> - Dashes are preferred to underscores
> - rename "nandflash" to "nand"
> - introduce new "ti,davinci" specific properties for setting
> up ecc_mode, ecc_bits, options and bbt options, instead
> using linux defines
> - changes for i2c due to comments from Sylwester Nawrocki:
> - use "cell-index" instead "id"
> - OF_DEV_AUXDATA in the machine code, instead pre-define
> platform device name
> - add comment from Grant Likely for i2c:
> - removed "id" resp. "cell-index" completely
> - fixed documentation
> - use of_match_ptr()
> - use devm_kzalloc() for allocating plattform data mem
> - fixed a whitespace issue
> - add net comments from Grant Likely:
> - add prefix "ti,davinci-" to davinci specific property names
> - remove version property
> - use compatible name "ti,davinci-dm6460-emac"
> - add comment from Grant Likely:
> - rename compatible node
> - do not use cell-index
> - CONFIG_OF required for this board
> TODO:
> - create a generic board support file, as I got no
> answer to my ping to grant, maybe this could be done
> in a second step?
> - changes for v3:
> - add comments from Sergei Shtylyov:
> - rename compatible" prop to "ti,cp_intc"
> - cp_intc_init now used for Interrupt controller init
> - changes for v4:
> add comment from Nori Sekhar:
> - rename davinci emac compatible property to "ti,davinci-dm6467-emac"
> - remove "pinmux-handle" property as discussed here:
> http://www.spinics.net/lists/arm-kernel/msg175701.html
> with Nori Sekhar
>
> - changes for v5:
> add comments from Grant Likely:
> - rename compatible" prop to "ti,cp-intc"
>
> - changes for v6:
> rework this patch, as patch
> ARM: davinci: cp_intc: Add OF support for TI interrupt controller
> was changed from Nori Sekhar on Jul 03, 2012; 9:16pm
> Changes therefore in this patch:
>
> Call of_irq_init() in the generic DT board file and not in the
> interrupt controller code. See arch/arm/mach-at91/board-dt.c or
> arch/arm/mach-omap2/board-generic.c for examples.
>
> At this point the question raises, if we should rename this
> board port from arch/arm/mach-davinci/enbw_cmc.c to
> arch/arm/mach-davinci/board-dt.c ? Also the defconfig to
> davinci_of_defconfig ... ? The USB and MMC callbacks are
> currently board specific, but if other boards come in,
> that could be easily adapted for their needs ...
>
> arch/arm/boot/dts/enbw_cmc.dts | 183 +++++++++++
> arch/arm/configs/enbw_cmc_defconfig | 126 ++++++++
> arch/arm/mach-davinci/Kconfig | 9 +
> arch/arm/mach-davinci/Makefile | 1 +
> arch/arm/mach-davinci/board-enbw-cmc.c | 385 +++++++++++++++++++++++
> arch/arm/mach-davinci/include/mach/uncompress.h | 1 +
> 6 files changed, 705 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/boot/dts/enbw_cmc.dts
> create mode 100644 arch/arm/configs/enbw_cmc_defconfig
> create mode 100644 arch/arm/mach-davinci/board-enbw-cmc.c
With the move to DT, we are not going to add more board specific files
and defconfigs. I am working on adding a generic dt board file for DA850
(similar to what has been done for imx). That file is not going to do
any platform device registrations. If you are OK with it, I will add the
dts file for enbw_cmc board in the patch series I am planning to post.
Things like USB and MMC/SD will need to be converted to DT before they
can be supported on new boards.
Thanks,
Sekhar
^ permalink raw reply
* Re: [RFC PATCH] tun: don't zeroize sock->file on detach
From: Yuchung Cheng @ 2012-08-08 17:48 UTC (permalink / raw)
To: Stanislav Kinsbursky
Cc: davem@davemloft.net, netdev@vger.kernel.org,
ruanzhijie@hotmail.com, linux-kernel@vger.kernel.org,
viro@zeniv.linux.org.uk
In-Reply-To: <50226147.3010309@parallels.com>
On Wed, Aug 8, 2012 at 5:53 AM, Stanislav Kinsbursky
<skinsbursky@parallels.com> wrote:
> Hi, Dave.
> What about this patch?
>
>
> On Wed, Jul 11, 2012 at 03:48:20PM +0400, Stanislav Kinsbursky wrote:
>>
>> This is a fix for bug, introduced in 3.4 kernel by commit
>> 1ab5ecb90cb6a3df1476e052f76a6e8f6511cb3d, which, among other things,
>> replaced
>> simple sock_put() by sk_release_kernel(). Below is sequence, which leads
>> to
>> oops for non-persistent devices:
>>
>> tun_chr_close()
>> tun_detach() <== tun->socket.file = NULL
>> tun_free_netdev()
>> sk_release_sock()
>> sock_release(sock->file == NULL)
>> iput(SOCK_INODE(sock)) <== dereference on NULL pointer
>>
>> This patch just removes zeroing of socket's file from __tun_detach().
>> sock_release() will do this.
>>
>> Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
I has tested this patch and it works (so my kernel stops crashing
using tun devices).
>> ---
>> drivers/net/tun.c | 1 -
>> 1 files changed, 0 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>> index 987aeef..c1639f3 100644
>> --- a/drivers/net/tun.c
>> +++ b/drivers/net/tun.c
>> @@ -185,7 +185,6 @@ static void __tun_detach(struct tun_struct *tun)
>> netif_tx_lock_bh(tun->dev);
>> netif_carrier_off(tun->dev);
>> tun->tfile = NULL;
>> - tun->socket.file = NULL;
>> netif_tx_unlock_bh(tun->dev);
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] netvm: check for page == NULL when propogating the skb->pfmemalloc flag
From: Rik van Riel @ 2012-08-08 19:14 UTC (permalink / raw)
To: Mel Gorman
Cc: David Miller, Linux-MM, LKML, Linux-Netdev, Xen-devel,
Konrad Rzeszutek Wilk, Ian Campbell, Andrew Morton
In-Reply-To: <20120807085554.GF29814@suse.de>
On 08/07/2012 04:55 AM, Mel Gorman wrote:
> Commit [c48a11c7: netvm: propagate page->pfmemalloc to skb] is responsible
> for the following bug triggered by a xen network driver
>
> [ 1.908592] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
> [ 1.908643] IP: [<ffffffffa0037750>] xennet_poll+0x980/0xec0 [xen_netfront]
> [ 1.908703] PGD ea1df067 PUD e8ada067 PMD 0
> [ 1.908774] Oops: 0000 [#1] SMP
> [ 1.908797] Modules linked in: fbcon tileblit font radeon bitblit softcursor ttm drm_kms_helper crc32c_intel xen_blkfront xen_netfront xen_fbfront fb_sys_fops sysimgblt sysfillrect syscopyarea +xen_kbdfront xenfs xen_privcmd
> [ 1.908938] CPU 0
> [ 1.908950] Pid: 2165, comm: ip Not tainted 3.5.0upstream-08854-g444fa66 #1
> [ 1.908983] RIP: e030:[<ffffffffa0037750>] [<ffffffffa0037750>] xennet_poll+0x980/0xec0 [xen_netfront]
> [ 1.909029] RSP: e02b:ffff8800ffc03db8 EFLAGS: 00010282
> [ 1.909055] RAX: ffff8800ea010140 RBX: ffff8800f00e86c0 RCX: 000000000000009a
> [ 1.909055] RDX: 0000000000000040 RSI: 000000000000005a RDI: ffff8800fa7dee80
> [ 1.909055] RBP: ffff8800ffc03ee8 R08: ffff8800f00e86d8 R09: ffff8800ea010000
> [ 1.909055] R10: dead000000200200 R11: dead000000100100 R12: ffff8800fa7dee80
> [ 1.909055] R13: 000000000000005a R14: ffff8800fa7dee80 R15: 0000000000000200
> [ 1.909055] FS: 00007fbafc188700(0000) GS:ffff8800ffc00000(0000) knlGS:0000000000000000
> [ 1.909055] CS: e033 DS: 0000 ES: 0000 CR0: 000000008005003b
> [ 1.909055] CR2: 0000000000000010 CR3: 00000000ea108000 CR4: 0000000000002660
> [ 1.909055] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 1.909055] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 1.909055] Process ip (pid: 2165, threadinfo ffff8800ea0f2000, task ffff8800fa783040)
> [ 1.909055] Stack:
> [ 1.909055] ffff8800e27e5040 ffff8800ffc03e88 ffff8800ffc03e68 ffff8800ffc03e48
> [ 1.909055] 7fffffffffffffff ffff8800ffc03e00 ffff8800e27e5040 ffff8800f00e86d8
> [ 1.909055] ffff8800ffc03eb0 00000040ffffffff ffff8800f00e8000 00000000ffc03e30
> [ 1.909055] Call Trace:
> [ 1.909055] <IRQ>
> [ 1.909055] [<ffffffff81066028>] ? pvclock_clocksource_read+0x58/0xd0
> [ 1.909055] [<ffffffff81486352>] net_rx_action+0x112/0x240
> [ 1.909055] [<ffffffff8107f319>] __do_softirq+0xb9/0x190
> [ 1.909055] [<ffffffff815d8d7c>] call_softirq+0x1c/0x30
>
> The problem is that the xenfront driver is passing a NULL page to
> __skb_fill_page_desc() which was unexpected. This patch checks that
> there is a page before dereferencing.
>
> Reported-and-Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Signed-off-by: Mel Gorman <mgorman@suse.de>
Acked-by: Rik van Riel <riel@redhat.com>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH] rndis_wlan: Fix potential memory leak in update_pmkid()
From: Jussi Kivilinna @ 2012-08-08 19:23 UTC (permalink / raw)
To: Alexey Khoroshilov
Cc: John W. Linville, linux-wireless, netdev, linux-kernel,
ldv-project
In-Reply-To: <1344440661-32322-1-git-send-email-khoroshilov@ispras.ru>
Quoting Alexey Khoroshilov <khoroshilov@ispras.ru>:
> Do not leak memory by updating pointer with potentially NULL realloc
> return value.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Thanks!
Acked-by: Jussi Kivilinna <jussi.kivilinna@mbnet.fi>
> ---
> drivers/net/wireless/rndis_wlan.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/rndis_wlan.c
> b/drivers/net/wireless/rndis_wlan.c
> index 241162e..7a4ae9e 100644
> --- a/drivers/net/wireless/rndis_wlan.c
> +++ b/drivers/net/wireless/rndis_wlan.c
> @@ -1803,6 +1803,7 @@ static struct ndis_80211_pmkid
> *update_pmkid(struct usbnet *usbdev,
> struct cfg80211_pmksa *pmksa,
> int max_pmkids)
> {
> + struct ndis_80211_pmkid *new_pmkids;
> int i, err, newlen;
> unsigned int count;
>
> @@ -1833,11 +1834,12 @@ static struct ndis_80211_pmkid
> *update_pmkid(struct usbnet *usbdev,
> /* add new pmkid */
> newlen = sizeof(*pmkids) + (count + 1) * sizeof(pmkids->bssid_info[0]);
>
> - pmkids = krealloc(pmkids, newlen, GFP_KERNEL);
> - if (!pmkids) {
> + new_pmkids = krealloc(pmkids, newlen, GFP_KERNEL);
> + if (!new_pmkids) {
> err = -ENOMEM;
> goto error;
> }
> + pmkids = new_pmkids;
>
> pmkids->length = cpu_to_le32(newlen);
> pmkids->bssid_info_count = cpu_to_le32(count + 1);
> --
> 1.7.9.5
>
>
>
^ permalink raw reply
* Bug with IPv6-UDP address binding
From: Jesper Dangaard Brouer @ 2012-08-08 20:37 UTC (permalink / raw)
To: netdev; +Cc: Thomas Graf
Hi NetDev
I think I have found a problem/bug with IPv6-UDP address binding.
I found this problem while playing with IPVS and IPv6-UDP, but its also
present in more basic/normal situations.
If you have two IPv6 addresses, within the same IPv6 subnet, then one
of the IPv6 addrs takes precedence over the other (for UDP only).
Meaning that, if connecting to the "secondary" IPv6 via UDP, will
result in userspace see/bind the connection as being created to the
"primary" IP, even-though tcpdump shows that the IPv6-UDP packets are
dest the "secondary".
The result is; that only the first IPv6-UDP packet is delivered to
userspace, and the next packets are denied by the kernel as the UDP
socket is "established" with the "primary" IPv6 addr.
I would appreciate some hints to where in the IPv6 code I should look
for this bug. If any one else wants to fix it, I'm also fine with
that ;-)
Its quite easy to reproduce, using netcat (nc).
Add two addresses to the "server" e.g.:
ip addr add fee0:cafe::102/64 dev eth0
ip addr add fee0:cafe::bad/64 dev eth0
Run a netcat listener on "server":
nc -6 -u -l 2000
(Notice restart the listener between runs, due to limitation in nc)
On the client add an IPv6 addr e.g.:
ip addr add fee0:cafe::101/64 dev eth0
Run a netcat UDP-IPv6 producer on "client":
nc -6 -u fee0:cafe::bad 2000
Notice that first packet, will get through, but second packets will
not (nc: Write error: Connection refused). Running a tcpdump shows
that the kernel is sending back ICMP6, destination unreachable,
unreachable port.
Its also possible to see the problem, simply running "netstat -uan" on
"server", which will show that the "established" UDP connection, is
bound to the wrong "Local Address".
(Tested on both latest net-next kernel at commit 79cda75a1, and also
on RHEL6 approx 2.6.32)
^ permalink raw reply
* Re: Bug with IPv6-UDP address binding
From: Eric Dumazet @ 2012-08-08 20:59 UTC (permalink / raw)
To: Jesper Dangaard Brouer; +Cc: netdev, Thomas Graf
In-Reply-To: <1344458238.3069.13.camel@localhost>
On Wed, 2012-08-08 at 22:37 +0200, Jesper Dangaard Brouer wrote:
> Hi NetDev
>
> I think I have found a problem/bug with IPv6-UDP address binding.
>
> I found this problem while playing with IPVS and IPv6-UDP, but its also
> present in more basic/normal situations.
>
> If you have two IPv6 addresses, within the same IPv6 subnet, then one
> of the IPv6 addrs takes precedence over the other (for UDP only).
>
> Meaning that, if connecting to the "secondary" IPv6 via UDP, will
> result in userspace see/bind the connection as being created to the
> "primary" IP, even-though tcpdump shows that the IPv6-UDP packets are
> dest the "secondary".
>
> The result is; that only the first IPv6-UDP packet is delivered to
> userspace, and the next packets are denied by the kernel as the UDP
> socket is "established" with the "primary" IPv6 addr.
>
> I would appreciate some hints to where in the IPv6 code I should look
> for this bug. If any one else wants to fix it, I'm also fine with
> that ;-)
>
>
> Its quite easy to reproduce, using netcat (nc).
>
> Add two addresses to the "server" e.g.:
> ip addr add fee0:cafe::102/64 dev eth0
> ip addr add fee0:cafe::bad/64 dev eth0
>
> Run a netcat listener on "server":
> nc -6 -u -l 2000
> (Notice restart the listener between runs, due to limitation in nc)
>
> On the client add an IPv6 addr e.g.:
> ip addr add fee0:cafe::101/64 dev eth0
>
> Run a netcat UDP-IPv6 producer on "client":
> nc -6 -u fee0:cafe::bad 2000
>
> Notice that first packet, will get through, but second packets will
> not (nc: Write error: Connection refused). Running a tcpdump shows
> that the kernel is sending back ICMP6, destination unreachable,
> unreachable port.
>
> Its also possible to see the problem, simply running "netstat -uan" on
> "server", which will show that the "established" UDP connection, is
> bound to the wrong "Local Address".
>
> (Tested on both latest net-next kernel at commit 79cda75a1, and also
> on RHEL6 approx 2.6.32)
>
Hi Jesper
Thats because the "nc -6 -u -l 2000" on server does :
bind(3, {sa_family=AF_INET6, sin6_port=htons(2000), inet_pton(AF_INET6,
"::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 0
recvfrom(3, "\n", 1024, MSG_PEEK, {sa_family=AF_INET6,
sin6_port=htons(53696), inet_pton(AF_INET6, "fee0:cafe::101",
&sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 1
connect(3, {sa_family=AF_INET6, sin6_port=htons(53696),
inet_pton(AF_INET6, "fee0:cafe::101", &sin6_addr), sin6_flowinfo=0,
sin6_scope_id=0}, 28) = 0
And the kernel automatically chooses a SOURCE address (fee0:cafe::102)
that is not what you expected (fee0:cafe::bad)
So its a bug in the application.
UDP connect() is tricky : In this case, nc should learn on what IP
address the client sent the frame. (using recvmsg() and appropriate
ancillary message)
Then nc should bind a new socket on this address, then do the connect()
^ permalink raw reply
* Re: [RFC PATCH] tun: don't zeroize sock->file on detach
From: David Miller @ 2012-08-08 21:34 UTC (permalink / raw)
To: ycheng; +Cc: skinsbursky, netdev, ruanzhijie, linux-kernel, viro
In-Reply-To: <CAK6E8=cpODYa1xURk7BZBnWwx5q3OD8-xkCau7GNPn+1BS0oQQ@mail.gmail.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Wed, 8 Aug 2012 10:48:32 -0700
> On Wed, Aug 8, 2012 at 5:53 AM, Stanislav Kinsbursky
> <skinsbursky@parallels.com> wrote:
>> Hi, Dave.
>> What about this patch?
>>
>>
>> On Wed, Jul 11, 2012 at 03:48:20PM +0400, Stanislav Kinsbursky wrote:
>>>
>>> This is a fix for bug, introduced in 3.4 kernel by commit
>>> 1ab5ecb90cb6a3df1476e052f76a6e8f6511cb3d, which, among other things,
>>> replaced
>>> simple sock_put() by sk_release_kernel(). Below is sequence, which leads
>>> to
>>> oops for non-persistent devices:
>>>
>>> tun_chr_close()
>>> tun_detach() <== tun->socket.file = NULL
>>> tun_free_netdev()
>>> sk_release_sock()
>>> sock_release(sock->file == NULL)
>>> iput(SOCK_INODE(sock)) <== dereference on NULL pointer
>>>
>>> This patch just removes zeroing of socket's file from __tun_detach().
>>> sock_release() will do this.
>>>
>>> Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
> Acked-by: Yuchung Cheng <ycheng@google.com>
>
> I has tested this patch and it works (so my kernel stops crashing
> using tun devices).
This patch needs to be formally resubmitted to netdev.
^ permalink raw reply
* Re: [RESEND][PATCH] drivers: net: irda: bfin_sir: fix compile error
From: David Miller @ 2012-08-08 22:40 UTC (permalink / raw)
To: lliubbo
Cc: samuel, rmk+kernel, gregkh, kuninori.morimoto.gx, linux-kernel,
uclinux-dist-devel, netdev, sonic.zhang
In-Reply-To: <1344305316-23916-1-git-send-email-lliubbo@gmail.com>
From: Bob Liu <lliubbo@gmail.com>
Date: Tue, 7 Aug 2012 10:08:36 +0800
> From: Sonic Zhang <sonic.zhang@analog.com>
>
> Bit IREN is replaced by UMOD_IRDA and UMOD_MASK since blackfin 60x added, but
> this driver didn't update which will cause bfin_sir build error:
>
> drivers/net/irda/bfin_sir.c:161:9: error: 'IREN' undeclared (first use in this
> function)
> drivers/net/irda/bfin_sir.c:435:18: error: 'IREN' undeclared (first use in
> this function)
> drivers/net/irda/bfin_sir.c:521:11: error: 'IREN' undeclared (first use in
> this function)
>
> This patch fix it.
>
> Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
> Signed-off-by: Bob Liu <lliubbo@gmail.com>
> Acked-by: Samuel Ortiz <samuel@sortiz.org>
Applied, thanks.
^ permalink raw reply
* Re: [net 0/3][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2012-08-08 22:42 UTC (permalink / raw)
To: peter.p.waskiewicz.jr; +Cc: netdev, gospo, sassmann
In-Reply-To: <1344326657-9376-1-git-send-email-peter.p.waskiewicz.jr@intel.com>
From: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Date: Tue, 7 Aug 2012 01:04:14 -0700
> This series contains fixes to the e1000e and igb drivers.
>
> The following are changes since commit 5d299f3d3c8a2fbc732b1bf03af36333ccec3130:
>
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/ppwaskie/net master
>
> Stefan Assmann (1):
> igb: add delay to allow igb loopback test to succeed on 8086:10c9
>
> Tushar Dave (2):
> e1000e: NIC goes up and immediately goes down
> e1000e: 82571 Tx Data Corruption during Tx hang recovery
Pulled, thanks a lot.
^ permalink raw reply
* Re: [PATCH] af_packet: Quiet sparse noise about using plain integer as NULL pointer
From: David Miller @ 2012-08-08 22:43 UTC (permalink / raw)
To: ying.xue; +Cc: netdev
In-Reply-To: <1344306430-30450-1-git-send-email-ying.xue@windriver.com>
From: Ying Xue <ying.xue@windriver.com>
Date: Tue, 7 Aug 2012 10:27:10 +0800
> Quiets the sparse warning:
> warning: Using plain integer as NULL pointer
>
> Signed-off-by: Ying Xue <ying.xue@windriver.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] netvm: check for page == NULL when propogating the skb->pfmemalloc flag
From: David Miller @ 2012-08-08 22:50 UTC (permalink / raw)
To: mgorman
Cc: linux-mm, linux-kernel, netdev, xen-devel, konrad, Ian.Campbell,
akpm
In-Reply-To: <20120807085554.GF29814@suse.de>
From: Mel Gorman <mgorman@suse.de>
Date: Tue, 7 Aug 2012 09:55:55 +0100
> Commit [c48a11c7: netvm: propagate page->pfmemalloc to skb] is responsible
> for the following bug triggered by a xen network driver
...
> The problem is that the xenfront driver is passing a NULL page to
> __skb_fill_page_desc() which was unexpected. This patch checks that
> there is a page before dereferencing.
>
> Reported-and-Tested-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
> Signed-off-by: Mel Gorman <mgorman@suse.de>
That call to __skb_fill_page_desc() in xen-netfront.c looks completely bogus.
It's the only driver passing NULL here.
That whole song and dance figuring out what to do with the head
fragment page, depending upon whether the length is greater than the
RX_COPY_THRESHOLD, is completely unnecessary.
Just use something like a call to __pskb_pull_tail(skb, len) and all
that other crap around that area can simply be deleted.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: pull-request: can 2012-08-07
From: David Miller @ 2012-08-08 22:55 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can
In-Reply-To: <1344333858-11944-1-git-send-email-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Tue, 7 Aug 2012 12:04:17 +0200
> here's a fix intended for the v3.6 release cycle. Oliver noticed and
> fixed that the flags definition for the new canfd_frame contains
> redundant and confusing information.
...
> git://gitorious.org/linux-can/linux-can.git fixes-for-3.6
Pulled, thanks.
^ permalink raw reply
* Re: [PATCH] pptp: lookup route with the proper net namespace
From: David Miller @ 2012-08-08 22:57 UTC (permalink / raw)
To: gaofeng; +Cc: xeb, netdev
In-Reply-To: <1344334991-3441-1-git-send-email-gaofeng@cn.fujitsu.com>
From: Gao feng <gaofeng@cn.fujitsu.com>
Date: Tue, 7 Aug 2012 18:23:11 +0800
> pptp always use init_net as the net namespace to lookup
> route, this will cause route lookup failed in container.
>
> because we already set the correct net namespace to struct
> sock in pptp_create,so fix this by using sock_net(sk) to
> replace &init_net.
>
> Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: fib: fix incorrect call_rcu_bh()
From: David Miller @ 2012-08-08 22:57 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, paulmck
In-Reply-To: <1344336431.28967.14.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 07 Aug 2012 12:47:11 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> After IP route cache removal, I believe rcu_bh() has very little use and
> we should remove this RCU variant, since it adds some cycles in fast
> path.
>
> Anyway, the call_rcu_bh() use in fib_true is obviously wrong, since
> some users only assert rcu_read_lock().
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: force dst_default_metrics to const section
From: David Miller @ 2012-08-08 23:00 UTC (permalink / raw)
To: eric.dumazet; +Cc: bhutchings, netdev
In-Reply-To: <1344372945.28967.165.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 07 Aug 2012 22:55:45 +0200
> [PATCH v2] net: force dst_default_metrics to const section
>
> While investigating on network performance problems, I found this little
> gem :
>
> $ nm -v vmlinux | grep -1 dst_default_metrics
> ffffffff82736540 b busy.46605
> ffffffff82736560 B dst_default_metrics
> ffffffff82736598 b dst_busy_list
>
> Apparently, declaring a const array without initializer put it in
> (writeable) bss section, in middle of possibly often dirtied cache
> lines.
>
> Since we really want dst_default_metrics be const to avoid any possible
> false sharing and catch any buggy writes, I force a null initializer.
>
> ffffffff818a4c20 R dst_default_metrics
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Ben Hutchings <bhutchings@solarflare.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH RESEND] sched: add missing group change to qfq_change_class
From: David Miller @ 2012-08-08 23:03 UTC (permalink / raw)
To: paolo.valente; +Cc: shemminger, jhs, fchecconi, rizzo, netdev, linux-kernel
In-Reply-To: <20120807172724.GA13729@paolo-ThinkPad-W520>
From: Paolo Valente <paolo.valente@unimore.it>
Date: Tue, 7 Aug 2012 19:27:25 +0200
> [Resending again, as the text was corrupted by the email client]
>
> To speed up operations, QFQ internally divides classes into
> groups. Which group a class belongs to depends on the ratio between
> the maximum packet length and the weight of the class. Unfortunately
> the function qfq_change_class lacks the steps for changing the group
> of a class when the ratio max_pkt_len/weight of the class changes.
>
> For example, when the last of the following three commands is
> executed, the group of class 1:1 is not correctly changed:
>
> tc disc add dev XXX root handle 1: qfq
> tc class add dev XXX parent 1: qfq classid 1:1 weight 1
> tc class change dev XXX parent 1: classid 1:1 qfq weight 4
>
> Not changing the group of a class does not affect the long-term
> bandwidth guaranteed to the class, as the latter is independent of the
> maximum packet length, and correctly changes (only) if the weight of
> the class changes. In contrast, if the group of the class is not
> updated, the class is still guaranteed the short-term bandwidth and
> packet delay related to its old group, instead of the guarantees that
> it should receive according to its new weight and/or maximum packet
> length. This may also break service guarantees for other classes.
> This patch adds the missing operations.
>
> Signed-off-by: Paolo Valente <paolo.valente@unimore.it>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] batman-adv: Fix mem leak in the batadv_tt_local_event() function
From: David Miller @ 2012-08-08 23:04 UTC (permalink / raw)
To: ordex-GaUfNO9RBHfsrOwW+9ziJQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
siwu-MaAgPAbsBIVS8oHt8HbXEIQuADTiUCJX, jj-IYz4IdjRLj0sV2N9l4h3zg,
lindner_marek-LWAfsSFWpa4
In-Reply-To: <20120807185036.GG3891-E/2OGukznS5g9hUCZPvPmw@public.gmane.org>
From: Antonio Quartulli <ordex-GaUfNO9RBHfsrOwW+9ziJQ@public.gmane.org>
Date: Tue, 7 Aug 2012 20:50:36 +0200
> On Tue, Aug 07, 2012 at 08:32:34PM +0200, Jesper Juhl wrote:
>> Memory is allocated for 'tt_change_node' with kmalloc().
>> 'tt_change_node' may go out of scope really being used for anything
>> (except have a few members initialized) if we hit the 'del:' label.
>> This patch makes sure we free the memory in that case.
>>
>> Signed-off-by: Jesper Juhl <jj-IYz4IdjRLj0sV2N9l4h3zg@public.gmane.org>
>
> Acked-by: Antonio Quartulli <ordex-GaUfNO9RBHfsrOwW+9ziJQ@public.gmane.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] cdc-phonet: Don't leak in usbpn_open
From: David Miller @ 2012-08-08 23:05 UTC (permalink / raw)
To: remi; +Cc: jj, linux-kernel, netdev, linux-usb, gregkh
In-Reply-To: <201208081012.07772.remi@remlab.net>
From: "Rémi Denis-Courmont" <remi@remlab.net>
Date: Wed, 8 Aug 2012 10:12:06 +0300
> Le mercredi 8 août 2012 00:56:26 Jesper Juhl, vous avez écrit :
>> We allocate memory for 'req' with usb_alloc_urb() and then test
>> 'if (!req || rx_submit(pnd, req, GFP_KERNEL | __GFP_COLD))'.
>> If we enter that branch due to '!req' then there is no problem. But if
>> we enter the branch due to 'req' being != 0 and the 'rx_submit()' call
>> being false, then we'll leak the memory we allocated.
>> Deal with the leak by always calling 'usb_free_urb(req)' when entering
>> the branch. If 'req' happens to be 0 then the call is harmless, if it
>> is not 0 then we free the memory we allocated but don't need.
>>
>> Signed-off-by: Jesper Juhl <jj@chaosbits.net>
>
> Acked-by: Rémi Denis-Courmont <remi@remlab.net>
Applied.
^ permalink raw reply
* Re: [RFC net-next 0/4] gianfar: Use separate NAPI for Tx confirmation processing
From: Tomas Hruby @ 2012-08-08 23:06 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Paul Gortmaker, Claudiu Manoil, netdev, David S. Miller
In-Reply-To: <1344444267.28967.225.camel@edumazet-glaptop>
On Wed, Aug 8, 2012 at 9:44 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Wed, 2012-08-08 at 12:24 -0400, Paul Gortmaker wrote:
>> [[RFC net-next 0/4] gianfar: Use separate NAPI for Tx confirmation processing] On 08/08/2012 (Wed 15:26) Claudiu Manoil wrote:
>>
>> > Hi all,
>> > This set of patches basically splits the existing napi poll routine into
>> > two separate napi functions, one for Rx processing (triggered by frame
>> > receive interrupts only) and one for the Tx confirmation path processing
>> > (triggerred by Tx confirmation interrupts only). The polling algorithm
>> > behind remains much the same.
>> >
>> > Important throughput improvements have been noted on low power boards with
>> > this set of changes.
>> > For instance, for the following netperf test:
>> > netperf -l 20 -cC -H 192.168.10.1 -t TCP_STREAM -- -m 1500
>> > yields a throughput gain from oscilating ~500-~700 Mbps to steady ~940 Mbps,
>> > (if the Rx/Tx paths are processed on different cores), w/ no increase in CPU%,
>> > on a p1020rdb - 2 core machine featuring etsec2.0 (Multi-Queue Multi-Group
>> > driver mode).
>>
>> It would be interesting to know more about what was causing that large
>> an oscillation -- presumably you will have it reappear once one core
>> becomes 100% utilized. Also, any thoughts on how the change will change
>> performance on an older low power single core gianfar system (e.g. 83xx)?
>
> I also was wondering if this low performance could be caused by BQL
>
> Since TCP stack is driven by incoming ACKS, a NAPI run could have to
> handle 10 TCP acks in a row, and resulting xmits could hit BQL and
> transit on qdisc (Because NAPI handler wont handle TX completions in the
> middle of RX handler)
Does disabling BQL help? Is the BQL limit stable? To what value is it
set? I would be very much interested in more data if the issue is BQL
related.
^ permalink raw reply
* Re: [PATCH] net/core: Fix potential memory leak in dev_set_alias()
From: David Miller @ 2012-08-08 23:07 UTC (permalink / raw)
To: khoroshilov; +Cc: edumazet, netdev, linux-kernel, ldv-project
In-Reply-To: <1344422005-21993-1-git-send-email-khoroshilov@ispras.ru>
From: Alexey Khoroshilov <khoroshilov@ispras.ru>
Date: Wed, 8 Aug 2012 14:33:25 +0400
> Do not leak memory by updating pointer with potentially NULL realloc return value.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] lpc_eth: remove obsolete ifdefs
From: David Miller @ 2012-08-08 23:08 UTC (permalink / raw)
To: stigge
Cc: netdev, linux-kernel, edumazet, aletes.xgr, kevin.wells,
srinivas.bakki
In-Reply-To: <1344431934-16748-1-git-send-email-stigge@antcom.de>
From: Roland Stigge <stigge@antcom.de>
Date: Wed, 8 Aug 2012 15:18:54 +0200
> The #ifdefs regarding CONFIG_ARCH_LPC32XX_MII_SUPPORT and
> CONFIG_ARCH_LPC32XX_IRAM_FOR_NET are obsolete since the symbols have been
> removed from Kconfig and replaced by devicetree based configuration.
>
> Signed-off-by: Roland Stigge <stigge@antcom.de>
Applied, thanks.
^ 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