* Re: [PATCH net V2 2/2] virtio-net: refill only when device is up during setting queues
From: David Miller @ 2013-10-17 19:55 UTC (permalink / raw)
To: jasowang; +Cc: netdev, virtualization, linux-kernel, mst
In-Reply-To: <1381807139-3450-2-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Tue, 15 Oct 2013 11:18:59 +0800
> We used to schedule the refill work unconditionally after changing the
> number of queues. This may lead an issue if the device is not
> up. Since we only try to cancel the work in ndo_stop(), this may cause
> the refill work still work after removing the device. Fix this by only
> schedule the work when device is up.
>
> The bug were introduce by commit 9b9cd8024a2882e896c65222aa421d461354e3f2.
> (virtio-net: fix the race between channels setting and refill)
>
> Cc: Rusty Russell <rusty@rustcorp.com.au>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Applied and queued up for -stable, thanks Jason.
^ permalink raw reply
* Re: [PATCH net V2 1/2] virtio-net: don't respond to cpu hotplug notifier if we're not ready
From: David Miller @ 2013-10-17 19:55 UTC (permalink / raw)
To: jasowang; +Cc: mst, netdev, linux-kernel, virtualization
In-Reply-To: <1381807139-3450-1-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Tue, 15 Oct 2013 11:18:58 +0800
> We're trying to re-configure the affinity unconditionally in cpu hotplug
> callback. This may lead the issue during resuming from s3/s4 since
>
> - virt queues haven't been allocated at that time.
> - it's unnecessary since thaw method will re-configure the affinity.
>
> Fix this issue by checking the config_enable and do nothing is we're not ready.
>
> The bug were introduced by commit 8de4b2f3ae90c8fc0f17eeaab87d5a951b66ee17
> (virtio-net: reset virtqueue affinity when doing cpu hotplug).
>
> Cc: Rusty Russell <rusty@rustcorp.com.au>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Cc: Wanlong Gao <gaowanlong@cn.fujitsu.com>
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
> Reviewed-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [patch] yam: remove a no-op in yam_ioctl()
From: David Miller @ 2013-10-17 19:54 UTC (permalink / raw)
To: dan.carpenter; +Cc: jpr, linux-hams, netdev, kernel-janitors
In-Reply-To: <20131014123726.GA17034@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon, 14 Oct 2013 15:46:15 +0300
> We overwrite the ->bitrate with the user supplied information on the
> next line.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied.
^ permalink raw reply
* Re: [patch] yam: integer underflow in yam_ioctl()
From: David Miller @ 2013-10-17 19:54 UTC (permalink / raw)
To: dan.carpenter; +Cc: jpr, linux-hams, netdev, kernel-janitors
In-Reply-To: <20131014121931.GI6247@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon, 14 Oct 2013 15:28:38 +0300
> We cap bitrate at YAM_MAXBITRATE in yam_ioctl(), but it could also be
> negative. I don't know the impact of using a negative bitrate but let's
> prevent it.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] fib_trie: Send RTM_DELROUTE when link goes down
From: Julian Anastasov @ 2013-10-17 19:52 UTC (permalink / raw)
To: Kristian Evensen; +Cc: netdev
In-Reply-To: <1382028894-14236-1-git-send-email-kristian.evensen@gmail.com>
Hello,
On Thu, 17 Oct 2013, Kristian Evensen wrote:
> From: Kristian Evensen <kristian.evensen@gmail.com>
>
> When a link is set as down using for example "ip link set dev X down", routes
> are deleted, but RTM_DELROUTE messages are not sent to RTNLGRP_IPV4_ROUTE. This
> patch makes trie_flush_list() send a RTM_DELROUTE for each route that is
> removed, and makes rtnelink route deletion behavior consistent across commands.
> The parameter lists for trie_flush_list() and trie_flush_leaf() are expanded to
> include required information otherwise unavailable in trie_flush_list().
>
> One use case that is simplified by this patch is IPv4 WAN connection monitoring.
> Instead of listening for and handling both RTM_*ROUTE and RTM_*LINK-messages, it
> is sufficient to handle RTM_*ROUTE.
IIRC, such notifications were not implemented
to avoid storms to routing daemons. Not sure if this is
still true.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH] net/ethernet: cpsw: Bugfix interrupts before enabling napi
From: David Miller @ 2013-10-17 19:48 UTC (permalink / raw)
To: mpa; +Cc: florian, mugunthanvnm, peter, linux-arm-kernel, netdev, kernel
In-Reply-To: <1381691821-25498-1-git-send-email-mpa@pengutronix.de>
From: Markus Pargmann <mpa@pengutronix.de>
Date: Sun, 13 Oct 2013 21:17:01 +0200
> If interrupts happen before napi_enable was called, the driver will not
> work as expected. Network transmissions are impossible in this state.
> This bug can be reproduced easily by restarting the network interface in
> a loop. After some time any network transmissions on the network
> interface will fail.
>
> This patch fixes the bug by enabling napi before enabling the network
> interface interrupts.
>
> Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/1] net: fix cipso packet validation when !NETLABEL
From: David Miller @ 2013-10-17 19:47 UTC (permalink / raw)
To: paul; +Cc: seif, netdev, thomas.petazzoni, dima
In-Reply-To: <3511324.zOrNRFllMJ@sifl>
From: Paul Moore <paul@paul-moore.com>
Date: Mon, 14 Oct 2013 11:12:47 -0400
> On Saturday, October 12, 2013 10:21:50 PM Seif Mazareeb wrote:
>> When CONFIG_NETLABEL is disabled, the cipso_v4_validate() function could
>> loop forever in the main loop if opt[opt_iter +1] == 0, this will causing a
>> kernel crash in an SMP system, since the CPU executing this function will
>> stall /not respond to IPIs.
>>
>> This problem can be reproduced by running the IP Stack Integrity Checker
>> (http://isic.sourceforge.net) using the following command on a Linux machine
>> connected to DUT:
>>
>> "icmpsic -s rand -d <DUT IP address> -r 123456"
>> wait (1-2 min)
>>
>> Signed-off-by: Seif Mazareeb <seif@marvell.com>
>
> Thanks for sticking with this.
>
> Acked-by: Paul Moore <paul@paul-moore.com>
This patch, like all the others Seif submitted, has been corrupted by
his email client and is this unusable.
^ permalink raw reply
* Re: [PATCH v2 net-next] net: refactor sk_page_frag_refill()
From: David Miller @ 2013-10-17 19:46 UTC (permalink / raw)
To: eric.dumazet
Cc: mwdalton, dborkman, netdev, ffusco, ycheng, ncardwell,
digitaleric
In-Reply-To: <1381639591.3392.31.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 12 Oct 2013 21:46:31 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> While working on virtio_net new allocation strategy to increase
> payload/truesize ratio, we found that refactoring sk_page_frag_refill()
> was needed.
>
> This patch splits sk_page_frag_refill() into two parts, adding
> page_frag_refill() which can be used without a socket.
>
> While we are at it, add a minimum frag size of 32 for
> sk_page_frag_refill()
>
> Michael will either use netdev_alloc_frag() from softirq context,
> or page_frag_refill() from process context in refill_work() (GFP_KERNEL
> allocations)
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Please rename this to something like "skb_page_frag_refill" so that it
is clear that this is a networking interface.
Thanks Eric.
^ permalink raw reply
* Re: [PATCH] bnx2x: record rx queue for LRO packets
From: David Miller @ 2013-10-17 19:43 UTC (permalink / raw)
To: dmitry; +Cc: eric.dumazet, netdev, eilong, willemb
In-Reply-To: <504C9EFCA2D0054393414C9CB605C37F20DD4605@SJEXCHMB06.corp.ad.broadcom.com>
From: "Dmitry Kravkov" <dmitry@broadcom.com>
Date: Sun, 13 Oct 2013 06:23:31 +0000
>> -----Original Message-----
>> From: netdev-owner@vger.kernel.org [mailto:netdev-
>> owner@vger.kernel.org] On Behalf Of Eric Dumazet
>> Sent: Sunday, October 13, 2013 12:09 AM
>> To: David Miller
>> Cc: netdev; Eilon Greenstein; Willem de Bruijn
>> Subject: [PATCH] bnx2x: record rx queue for LRO packets
>>
>> From: Eric Dumazet <edumazet@google.com>
>>
>> RPS support is kind of broken on bnx2x, because only non LRO packets get
>> proper rx queue information. This triggers reorders, as it seems bnx2x like to
>> generate a non LRO packet for segment including TCP PUSH flag : (this might
>> be pure coincidence, but all the reorders I've seen involve segments with a
>> PUSH)
>>
>> 11:13:34.335847 IP A > B: . 415808:447136(31328) ack 1 win 457
>> <nop,nop,timestamp 3789336 3985797>
>> 11:13:34.335992 IP A > B: . 447136:448560(1424) ack 1 win 457
>> <nop,nop,timestamp 3789336 3985797>
>> 11:13:34.336391 IP A > B: . 448560:479888(31328) ack 1 win 457
>> <nop,nop,timestamp 3789337 3985797>
>> 11:13:34.336425 IP A > B: P 511216:512640(1424) ack 1 win 457
>> <nop,nop,timestamp 3789337 3985798>
>> 11:13:34.336423 IP A > B: . 479888:511216(31328) ack 1 win 457
>> <nop,nop,timestamp 3789337 3985798>
>> 11:13:34.336924 IP A > B: . 512640:543968(31328) ack 1 win 457
>> <nop,nop,timestamp 3789337 3985798>
>> 11:13:34.336963 IP A > B: . 543968:575296(31328) ack 1 win 457
>> <nop,nop,timestamp 3789337 3985798>
>>
>> We must call skb_record_rx_queue() to properly give to RPS (and more
>> generally for TX queue selection on forward path) the receive queue
>> information.
>>
>> Similar fix is needed for skb_mark_napi_id(), but will be handled in a
>> separate patch to ease stable backports.
>>
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
...
> Acked-by: Dmitry Kravkov <dmitry@broadcom.com>
>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH] usbnet: fix error return code in usbnet_probe()
From: David Miller @ 2013-10-17 19:40 UTC (permalink / raw)
To: weiyj.lk-Re5JQEeQqe8AvxtiuMwx3w
Cc: oneukum-l3A5Bk7waGM, yongjun_wei-zrsr2BFq86L20UzCJQGyNP8+0UxHXcjY,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAPgLHd9jQfT2Kzi5o+3KPy0hFrkHL135K2aYp7OXcbLX4Cmkcg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
From: Wei Yongjun <weiyj.lk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Sat, 12 Oct 2013 14:24:08 +0800
> From: Wei Yongjun <yongjun_wei-zrsr2BFq86L20UzCJQGyNP8+0UxHXcjY@public.gmane.org>
>
> Fix to return -ENOMEM in the padding pkt alloc fail error handling
> case instead of 0, as done elsewhere in this function.
>
> Signed-off-by: Wei Yongjun <yongjun_wei-zrsr2BFq86L20UzCJQGyNP8+0UxHXcjY@public.gmane.org>
Applied, thanks Wei.
--
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 v2] Stmmac: fix a bug when clk_csr is euqal to 0x0
From: David Miller @ 2013-10-17 19:39 UTC (permalink / raw)
To: mcuos.com; +Cc: netdev, peppe.cavallaro
In-Reply-To: <CAKT61h9Cv=g5stPBnp25XiUyfPy_NxBKxtAABUHm+GajCHMGWA@mail.gmail.com>
From: Wan ZongShun <mcuos.com@gmail.com>
Date: Sat, 12 Oct 2013 10:04:20 +0800
> According to spec, if csr clock freq is 60-100Mhz, we have to set CR[5:2] = 0000
> but when I set the 'plat_dat.clk_csr = 0',acctually, this value is not used
> since the driver code judge 'if (!priv->plat->clk_csr)' then go to dynamic tune
> the MDC clock. So this patch is to add other judge condition.
>
> Signed-off-by: Wan Zongshun <mcuos.com@gmail.com>
There are still many problems with this patch.
Do not capitalize "Stmmac" in the subject prefix, use plain "stmmac: "
There is a typo in "equal" in the subject line.
> @@ -148,6 +149,8 @@ Where:
> GMAC also enables the 4xPBL by default.
> o fixed_burst/mixed_burst/burst_len
> o clk_csr: fixed CSR Clock range selection.
> + o dynamic_mdc_clk_en: If it is set to >=1 MDC clk will be selected
> dynamically,
> + or else you must set a fixed CSR Clock range to clk_src.
> o has_gmac: uses the GMAC core.
> o enh_desc: if sets the MAC will use the enhanced descriptor structure.
> o tx_coe: core is able to perform the tx csum in HW.
The patch has been corrupted by your email client.
^ permalink raw reply
* Re: [PATCH net-next v5 0/5] xen-netback: IPv6 offload support
From: David Miller @ 2013-10-17 19:36 UTC (permalink / raw)
To: paul.durrant; +Cc: xen-devel, netdev
In-Reply-To: <1381942232-26268-1-git-send-email-paul.durrant@citrix.com>
From: Paul Durrant <paul.durrant@citrix.com>
Date: Wed, 16 Oct 2013 17:50:27 +0100
> This patch series adds support for checksum and large packet offloads into
> xen-netback.
> Testing has mainly been done using the Microsoft network hardware
> certification suite running in Server 2008R2 VMs with Citrix PV frontends.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 0/3] bonding: patchset for rcu use in bonding
From: David Miller @ 2013-10-17 19:32 UTC (permalink / raw)
To: dingtianhong; +Cc: fubar, andy, nikolay, vfalico, netdev
In-Reply-To: <525CFCAF.2000605@huawei.com>
From: Ding Tianhong <dingtianhong@huawei.com>
Date: Tue, 15 Oct 2013 16:28:31 +0800
> The Patch Set convert the xmit of 3ad and alb mode to use rcu lock.
> dd rtnl lock and remove read lock for bond sysfs.
>
> v2 because the bond_for_each_slave_rcu without rcu_read_lock() will occurs one warming, so
> add new function for alb xmit path to avoid warming.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] veth: Showing peer of veth type dev in ip link (kernel side)
From: Eric W. Biederman @ 2013-10-17 19:28 UTC (permalink / raw)
To: nicolas.dichtel; +Cc: Stephen Hemminger, David Miller, yamato, netdev
In-Reply-To: <52600ABC.1030701@6wind.com>
Nicolas Dichtel <nicolas.dichtel@6wind.com> writes:
> Le 16/10/2013 21:53, Eric W. Biederman a écrit :
>> The age old question why can't we have global identifiers for
>> namespaces?
>>
>> The answer is that I don't want to implement a namespace for namespaces.
> Sorry, but I don't understand the problem. This ID is owned by the kernel, like
> the netns list (for_each_net()) is owned by it.
The scenario where problem are likely to show up is something like this.
For testing it would be reasonable to setup two linux containers that
look like full linux systems. In those containers you run one instance
of your virtual router managment daemons, and you arrange to synchronize
between the two linux containers for testing.
It becomes even more interesting when we want to migrate one of those
linux containers to another physical machine.
Global identifiers start breaking the first scenario, and really trash
the second scenario.
At the same time migration of configuration and replication of
configuration are essentially the same problem, so it would be very
silly to design such that will cause problems.
>> While the proc inode does work today across different mounts of proc, I
>> reserve the right at some future date (if it solves a technical problem)
>> to give each namespace a different inode number in each different mount
>> of proc. So the inode number is not quite the unique identifier you
>> want. The inode number is a close as I am willing to get to a namespace
>> of namespaces.
>>
>> I think the simplest solution is to just not worry about which namespace
>> the other half of a veth pair is in. But I have not encountered the
>> problem where I need to know exactly which namespace we are worrying
>> about.
> Ok, let's start by explaining our usecase.
>
> We are using namespaces only to implement virtual routers (VR), ie only
> the networking stack is virtualized. We don't care about other namespaces, we
> just want to run several network stacks and beeing able to manage them.
>
> For example, providers use this feature to isolate clients, one VR is opened
> for each client. You can have a large number of clients (+10 000) and thus the
> same number of netns.
> Considering these numbers, we don't want to run one instance per VR for all of
> our network daemons, but have only one instance that manage all VR.
>
> You also have daemons that monitor the system and synchronize network objects
> (interfaces, routes, etc.) on another linux. Goal is to implement an high
> availablity system: it's possible to switch to the other linux to avoid service
> interruption.
> This kind of daemon wants to have the full information about interfaces to be
> able to build/configure them on the other linux.
>
>>
>> Global identifiers are easy until you hit the cases where they make
>> things impossible.
> I don't want specially to use ID, but I fear that the solution with file
> descriptors will be a nightmare.
I can certainly see challenges. In asking for symmetry between set and
get the solution with file descriptors is the obvious answer and the
first answer I have been able to come up with so far.
My original answer was that the ifindex happened to be unique across
namespaces but that actually turned out to be a problem for migration
so that abandoned.
Namespace file descriptors are the solution that I know semantically
will work. Beyond that I don't have any good ideas right now.
I just know that local names (aka file descriptors) are much easier to
work with semantically than global names.
Eric
^ permalink raw reply
* Re: [PATCH v4 net 0/3] sctp: Use software checksum under certain
From: David Miller @ 2013-10-17 19:26 UTC (permalink / raw)
To: vyasevich; +Cc: netdev, linux-sctp, fan.du
In-Reply-To: <1381888891-31186-1-git-send-email-vyasevich@gmail.com>
From: Vlad Yasevich <vyasevich@gmail.com>
Date: Tue, 15 Oct 2013 22:01:28 -0400
> There are some cards that support SCTP checksum offloading. When using
> these cards with IPSec or forcing IP fragmentation of SCTP traffic,
> the checksum is computed incorrectly due to the fact that xfrm and IP/IPv6
> fragmentation code do not know that this is SCTP traffic and do not
> know that checksum has to be computed differently.
>
> To fix this, we let SCTP detect these conditions and perform software
> checksum calculation.
Series applied, thanks Vlad.
^ permalink raw reply
* Re: [PATCH 00/17] netfilter updates: nf_tables pull request
From: David Miller @ 2013-10-17 19:23 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, kaber, netdev
In-Reply-To: <1381768738-17739-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Mon, 14 Oct 2013 18:38:41 +0200
> The following patchset contains the current original nf_tables tree
> condensed in 17 patches. I have organized them by chronogical order
> since the original nf_tables code was released in 2009 and by
> dependencies between the different patches.
...
> There is still work to do to fully replace x_tables [4] [5] but that can
> be done incrementally by extending our netlink API. Moreover, looking at
> netfilter-devel and the amount of contributions to nf_tables we've been
> getting, I think it would be good to have it mainstream to avoid accumulating
> large patchsets skip continuous rebases.
>
> I tried to provide a reasonable patchset, we have more than 100 accumulated
> patches in the original nf_tables tree, so I collapsed many of the small
> fixes to the main patch we had since 2009 and provide a small batch for
> review to netdev, while trying to retain part of the history.
>
> For those who didn't give a try to nf_tables yet, there's a quick howto
> available from Eric Leblond that describes how to get things working [6].
>
> Comments/reviews welcome.
This looks great, pulled, thanks a lot!!
^ permalink raw reply
* Re: [PATCH] irda: update comment mentioning IRQF_DISABLED
From: David Miller @ 2013-10-17 19:15 UTC (permalink / raw)
To: michael.opdenacker; +Cc: samuel, netdev, linux-kernel
In-Reply-To: <1381645591-9565-1-git-send-email-michael.opdenacker@free-electrons.com>
From: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date: Sun, 13 Oct 2013 08:26:31 +0200
> This patch removes a comment mentioning IRQF_DISABLED,
> which is deprecated.
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] isdn: remove deprecated IRQF_DISABLED
From: David Miller @ 2013-10-17 19:14 UTC (permalink / raw)
To: michael.opdenacker; +Cc: mac, isdn, netdev, linux-kernel
In-Reply-To: <1381641869-7709-1-git-send-email-michael.opdenacker@free-electrons.com>
From: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date: Sun, 13 Oct 2013 07:24:29 +0200
> This patch proposes to remove the use of the IRQF_DISABLED flag
>
> It's a NOOP since 2.6.35 and it will be removed one day.
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH net-next 0/4] net/mlx4: Mellanox driver update 15-10-2013
From: David Miller @ 2013-10-17 19:13 UTC (permalink / raw)
To: amirv; +Cc: netdev, eyalpe
In-Reply-To: <1381848924-18992-1-git-send-email-amirv@mellanox.com>
From: Amir Vadai <amirv@mellanox.com>
Date: Tue, 15 Oct 2013 16:55:20 +0200
> This patchset contains small code cleaning patches, and a patch to make
> mlx4_core use module_request() in order to load the relevant link layer module
> (mlx4_en or mlx4_ib) according to the port type.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v3 7/9] qlcnic: Validate Tx queue only for 82xx adapters.
From: David Miller @ 2013-10-17 19:07 UTC (permalink / raw)
To: himanshu.madhani; +Cc: netdev, Dept_NX_Linux_NIC_Driver
In-Reply-To: <21b377dba7708434c344a9204afd460c9b43af3c.1381882600.git.himanshu.madhani@qlogic.com>
From: Himanshu Madhani <himanshu.madhani@qlogic.com>
Date: Tue, 15 Oct 2013 12:57:52 -0400
> From: Himanshu Madhani <himanshu.madhani@qlogic.com>
>
> o validate Tx queue only in case of adapters which supports
> multi Tx queue.
>
> This patch is to fix regression introduced in commit
> aa4a1f7df7cbb98797c9f4edfde3c726e2b3841f
> "qlcnic: Enable Tx queue changes using ethtool for 82xx Series adapter"
>
> Signed-off-by: Himanshu Madhani <himanshu.madhani@qlogic.com>
Do not submit bug fixes for "net-next" if they are for problems
that exist in 'net'.
What do several driver maintainers do this repeatedly?
Are you scared I'll reject the submission? If it's really a bug fix
I won't, 'net' is where it really belongs.
I'm not applying this series, submit it properly.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] inet_diag: use sock_gen_put()
From: David Miller @ 2013-10-17 19:02 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1381506889.4971.104.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 11 Oct 2013 08:54:49 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> TCP listener refactoring, part 6 :
>
> Use sock_gen_put() from inet_diag_dump_one_icsk() for future
> SYN_RECV support.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH] sctp: Do not trigger BUG_ON when deleting assoc without primary path
From: Daniel Borkmann @ 2013-10-17 18:52 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: netdev, linux-sctp, Mark Thomas, Neil Horman
In-Reply-To: <52602E0C.6000300@gmail.com>
On 10/17/2013 08:35 PM, Vlad Yasevich wrote:
> On 10/17/2013 02:25 PM, Daniel Borkmann wrote:
>> On 10/17/2013 08:01 PM, Daniel Borkmann wrote:
>>> On 10/17/2013 07:30 PM, Vlad Yasevich wrote:
>>>> It is possible to enter sctp_cmd_delete_tcb() without having a
>>>> primary path. The situations this most often happens in is
>>>> when duplication cookie processing is triggered. In this
>>>> case, we are deleting a temporarily created association that
>>>> is not fully populated. Additially, at the time we
>>>> are deleting the offending association, it is really too
>>>> late to issue a BUG!
>>>>
>>>> This was introduced by:
>>>> commit f9e42b853523cda0732022c2e0473c183f7aec65
>>>> net: sctp: sideeffect: throw BUG if primary_path is NULL
>>>
>>> Sure, lets remove it, but then we could still get a WARN() [sure,
>>> better than BUG], if the user at the very same time checks procfs
>>> through sctp_seq_dump_local_addrs(), see discussion we had here [1]:
>>>
>>> It may trigger the crash later if the user performs some action on the
>>> association that touches the primary. That's the reason why I was
>>> proposing the checks below.
>>>
>>> With the checks in command interpreter, we are only left with the
>>> possibility that primary_path changes to NULL during the association
>>> lifetime, which code audit doesn't support right now. If that ever
>>> changes we would at least have a bit more information to go on.
>>>
>>> [1] http://patchwork.ozlabs.org/patch/251099/
>>
>> Meaning, all I'm saying is that with f9e42b853 we wanted to find exactly
>> such a case we have right now, that is, that an assoc could enter the
>> hashtable w/o primary path, no?
>
> But it didn't enter a hash table in this case. SCTP_CMD_NEW_ASOC
> was never issued. The sequence was:
> SCTP_CMD_SET_ASOC
> SCTP_CMD_DELETE_TCB
>
> Such association would never be found through /proc since it was never
> hashed. Such association would never be found the user since it
> is only really alive while the packet is processed. By all rights
> it should be marked as 'temp', but it isn't due to cookie processing.
>
> May be we should update cookie processing function to allow it
> to create temp associations if so desired.
Yes, I think that might be the better way to move on.
> -vlad
^ permalink raw reply
* Re: [PATCH] x86: Run checksumming in parallel accross multiple alu's
From: Eric Dumazet @ 2013-10-17 18:48 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Ingo Molnar, Neil Horman, linux-kernel, sebastien.dugue,
Thomas Gleixner, Ingo Molnar, x86, netdev
In-Reply-To: <52602A29.506@zytor.com>
On Thu, 2013-10-17 at 11:19 -0700, H. Peter Anvin wrote:
> Seriously, though, how much does it matter? All the above seems likely
> to do is to drown the signal by adding noise.
I don't think so.
>
> If the parallel (threaded) checksumming is faster, which theory says it
> should and microbenchmarking confirms, how important are the
> macrobenchmarks?
Seriously, micro benchmarks are very misleading.
I spent time on this patch, and found no changes on real workloads.
I was excited first, then disappointed.
I hope we will find the real issue, as I really don't care of micro
benchmarks.
^ permalink raw reply
* Re: [PATCH net 2/9] bnx2x: Prevent an illegal pointer dereference during panic
From: Eilon Greenstein @ 2013-10-17 18:47 UTC (permalink / raw)
To: David Miller; +Cc: yuvalmin, netdev, ariele, dmitry
In-Reply-To: <20131017.142134.1058688642083607743.davem@davemloft.net>
On Thu, 2013-10-17 at 14:21 -0400, David Miller wrote:
> From: "Yuval Mintz" <yuvalmin@broadcom.com>
> Date: Tue, 15 Oct 2013 16:28:48 +0200
>
> > @@ -775,6 +775,15 @@ void bnx2x_fw_dump_lvl(struct bnx2x *bp, const char *lvl)
> > trace_shmem_base = bp->common.shmem_base;
> > else
> > trace_shmem_base = SHMEM2_RD(bp, other_shmem_base_addr);
> > +
> > + /* sanity */
> > + if (trace_shmem_base < MCPR_SCRATCH_BASE(bp) ||
> > + trace_shmem_base > MCPR_SCRATCH_BASE(bp) + 0x28000) {
>
> I would say that this second test should be ">=" rather than ">".
>
> Actually, there are a lot of holes still remaining here.
>
> trace_shmem_base is validated, but then you access the signature at
> 0x800 bytes before trace_shmem_base value. That should be accounted
> for in the test above too.
>
> And what about that 'mark' value you read? Any validations needed on
> that?
>
> And then you read from "addr" to "mark", and I see no checks that this
> range makes any sense either.
The failure that we saw was due to PCI read failure, so we could have
checked that we did not read all 1's, but then we thought about a
stronger validation to make sure this address is not being overrun for
some unknown reason (maybe stack overflow of the FW, after all, we are
at a FW bug handling routine) so this added condition validate that the
address is within the scratchpad limitation. To make it more precious,
we should account for the differences between the different silicon
revisions, but we did not really see such a failure - the failure we saw
was reading all 1's, the extra sanity will catch some more failure, but
obviously not all.
I guess we should really re-spin and check for all 1's, or add some more
code to make it really accurate, or at least fix the ">" to ">=". We
will send a revised series with a fix.
Thanks,
Eilon
^ permalink raw reply
* Re: [PATCH] sctp: Do not trigger BUG_ON when deleting assoc without primary path
From: Vlad Yasevich @ 2013-10-17 18:35 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: netdev, linux-sctp, Mark Thomas, Neil Horman
In-Reply-To: <52602BA3.5020405@redhat.com>
On 10/17/2013 02:25 PM, Daniel Borkmann wrote:
> On 10/17/2013 08:01 PM, Daniel Borkmann wrote:
>> On 10/17/2013 07:30 PM, Vlad Yasevich wrote:
>>> It is possible to enter sctp_cmd_delete_tcb() without having a
>>> primary path. The situations this most often happens in is
>>> when duplication cookie processing is triggered. In this
>>> case, we are deleting a temporarily created association that
>>> is not fully populated. Additially, at the time we
>>> are deleting the offending association, it is really too
>>> late to issue a BUG!
>>>
>>> This was introduced by:
>>> commit f9e42b853523cda0732022c2e0473c183f7aec65
>>> net: sctp: sideeffect: throw BUG if primary_path is NULL
>>
>> Sure, lets remove it, but then we could still get a WARN() [sure,
>> better than BUG], if the user at the very same time checks procfs
>> through sctp_seq_dump_local_addrs(), see discussion we had here [1]:
>>
>> It may trigger the crash later if the user performs some action on the
>> association that touches the primary. That's the reason why I was
>> proposing the checks below.
>>
>> With the checks in command interpreter, we are only left with the
>> possibility that primary_path changes to NULL during the association
>> lifetime, which code audit doesn't support right now. If that ever
>> changes we would at least have a bit more information to go on.
>>
>> [1] http://patchwork.ozlabs.org/patch/251099/
>
> Meaning, all I'm saying is that with f9e42b853 we wanted to find exactly
> such a case we have right now, that is, that an assoc could enter the
> hashtable w/o primary path, no?
But it didn't enter a hash table in this case. SCTP_CMD_NEW_ASOC
was never issued. The sequence was:
SCTP_CMD_SET_ASOC
SCTP_CMD_DELETE_TCB
Such association would never be found through /proc since it was never
hashed. Such association would never be found the user since it
is only really alive while the packet is processed. By all rights
it should be marked as 'temp', but it isn't due to cookie processing.
May be we should update cookie processing function to allow it
to create temp associations if so desired.
-vlad
^ 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