* Re: Problematic commits in the ipsec tree
From: Steffen Klassert @ 2013-08-26 9:41 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: David Miller, netdev
In-Reply-To: <20130823124911.GD808@order.stressinduktion.org>
On Fri, Aug 23, 2013 at 02:49:11PM +0200, Hannes Frederic Sowa wrote:
>
> This could be the replacement for patch 1/2 to reassemble old behaviour
> without touching ip6_skb_dst_mtu if the socket type is not an IPv6 one.
>
> I would still like to look if we could correctly handle *_PMTUDISC_PROBE one
> day and fallback to dst_mtu(dst->path) if possible. So I don't know if
> removing xfrm_skb_dst_mtu is good style and would just make churn in the git
> history. What do you think?
Currently I think we can call dst_mtu() unconditionally from
__xfrm6_output(), then we would not need xfrm_skb_dst_mtu().
But this needs further investigation, IPsec pmtu discovery
was frequently broken in the past and I don't want to break
it again.
>
> [PATCH ipsec 1/2] xfrm: revert ipv4 mtu determination to dst_mtu
>
> In commit 0ea9d5e3e0e03a63b11392f5613378977dae7eca ("xfrm: introduce
> helper for safe determination of mtu") I switched the determination of
> ipv4 mtus from dst_mtu to ip_skb_dst_mtu. This was an error because in
> case of IP_PMTUDISC_PROBE we fall back to the interface mtu, which is
> never correct for ipv4 ipsec.
>
> This patch partly reverts 0ea9d5e3e0e03a63b11392f5613378977dae7eca
> ("xfrm: introduce helper for safe determination of mtu").
>
I think with this and you other patch, we get the all the
interfamily tunnel problems fixed for now. Everything else
should be done in ipsec-next.
Please resend the whole patchset, so we can get it fixed soon.
Tanks a lot!
^ permalink raw reply
* Re: Do you guys think add link test to offline test is reasonable?
From: Ben Hutchings @ 2013-08-26 9:17 UTC (permalink / raw)
To: Hui-Zhi Zhao; +Cc: netdev
In-Reply-To: <CAOhdcN_QPtfQK87LCmoS2k=7_W9Wzwke21PdvZUi9znZ3Si54Q@mail.gmail.com>
On Mon, 2013-08-26 at 15:47 +0800, Hui-Zhi Zhao wrote:
> Hi Guys,
>
>
> I have a query about the ethtool offline test.
>
>
> From the man page of "ethtool" I see the offline test should be
> "offline (default) means to perform full set of tests possibly causing
> normal operation interruption during the tests". In my opinion, it
> should just do something like inner loopback tests, offline should be
> no relative with live network connection.
I agree that an offline test should not depend on having a network link.
> Since it is impractical to expect these ports to be connected to a
> live network during production test (due to limited network
> resources, a machine maybe have lots of ports), some of the tests will
> fail, even the cards have no problem.
>
> So, do you guys think add link test to offline test is reasonable?
You can do it but it shouldn't affect the overall pass/fail result.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH] net/cadence/macb: fix kernel Oops if no PHY were discovered during probe
From: Bo Shen @ 2013-08-26 9:09 UTC (permalink / raw)
To: Boris BREZILLON; +Cc: Nicolas Ferre, netdev, linux-kernel, linux-arm-kernel
In-Reply-To: <1377372065-8938-1-git-send-email-b.brezillon@overkiz.com>
Hi Boris,
On 08/25/2013 03:21 AM, Boris BREZILLON wrote:
> Test the presence of a PHY device before printing attached PHY
> informations.
>
> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
> ---
> drivers/net/ethernet/cadence/macb.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
> index e866608..fd3b67f 100644
> --- a/drivers/net/ethernet/cadence/macb.c
> +++ b/drivers/net/ethernet/cadence/macb.c
> @@ -1868,8 +1868,10 @@ static int __init macb_probe(struct platform_device *pdev)
> dev->irq, dev->dev_addr);
>
> phydev = bp->phy_dev;
> - netdev_info(dev, "attached PHY driver [%s] (mii_bus:phy_addr=%s, irq=%d)\n",
> - phydev->drv->name, dev_name(&phydev->dev), phydev->irq);
> + if (phydev)
> + netdev_info(dev, "attached PHY driver [%s] (mii_bus:phy_addr=%s, irq=%d)\n",
> + phydev->drv->name, dev_name(&phydev->dev),
> + phydev->irq);
Actually no need this check, if PHY is attached failed, the macb driver
probe will fail, then it won't show this message.
> return 0;
>
>
Best Regards,
Bo Shen
^ permalink raw reply
* Re: [PATCH v6 2/5] net: ethernet: cpsw: add optional third memory region for CONTROL module
From: Tony Lindgren @ 2013-08-26 9:04 UTC (permalink / raw)
To: Daniel Mack
Cc: netdev, bcousson, nsekhar, sergei.shtylyov, davem, ujhelyi.m,
mugunthanvnm, vaibhav.bedia, d-gerlach, linux-arm-kernel,
linux-omap, devicetree
In-Reply-To: <1377286330-29663-3-git-send-email-zonque@gmail.com>
* Daniel Mack <zonque@gmail.com> [130823 12:39]:
> At least the AM33xx SoC has a control module register to configure
> details such as the hardware ethernet interface mode.
>
> I'm not sure whether all SoCs which feature the cpsw block have such a
> register, so that third memory region is considered optional for now.
Assuming you're talking about omap SCM registers here..
This should be in a separate driver module so the control module
parts can eventually be children of the SCM driver as they are
really separate devices on the bus. See how the USB PHY parts were done
for example.
What do these control module registers do? If it's just multiplexing
and pinconf, then you can use pinctrl-single,bits most likely for it and
access it using the named modes.
However, if the register also contains comparators and control for
regulators, you should only use pinctrl-single for the multiplexing
and pinconf parts.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH] net/cadence/macb: fix kernel Oops if no PHY were discovered during probe
From: Nicolas Ferre @ 2013-08-26 7:43 UTC (permalink / raw)
To: Boris BREZILLON; +Cc: netdev, linux-kernel, linux-arm-kernel
In-Reply-To: <1377372065-8938-1-git-send-email-b.brezillon@overkiz.com>
On 24/08/2013 21:21, Boris BREZILLON :
> Test the presence of a PHY device before printing attached PHY
> informations.
>
> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> drivers/net/ethernet/cadence/macb.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
> index e866608..fd3b67f 100644
> --- a/drivers/net/ethernet/cadence/macb.c
> +++ b/drivers/net/ethernet/cadence/macb.c
> @@ -1868,8 +1868,10 @@ static int __init macb_probe(struct platform_device *pdev)
> dev->irq, dev->dev_addr);
>
> phydev = bp->phy_dev;
> - netdev_info(dev, "attached PHY driver [%s] (mii_bus:phy_addr=%s, irq=%d)\n",
> - phydev->drv->name, dev_name(&phydev->dev), phydev->irq);
> + if (phydev)
> + netdev_info(dev, "attached PHY driver [%s] (mii_bus:phy_addr=%s, irq=%d)\n",
> + phydev->drv->name, dev_name(&phydev->dev),
> + phydev->irq);
>
> return 0;
>
>
--
Nicolas Ferre
^ permalink raw reply
* Re: [PATCH 6/6] vhost_net: remove the max pending check
From: Jason Wang @ 2013-08-26 7:00 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, linux-kernel, kvm, virtualization
In-Reply-To: <20130825115344.GB1829@redhat.com>
On 08/25/2013 07:53 PM, Michael S. Tsirkin wrote:
> On Fri, Aug 23, 2013 at 04:55:49PM +0800, Jason Wang wrote:
>> On 08/20/2013 10:48 AM, Jason Wang wrote:
>>> On 08/16/2013 06:02 PM, Michael S. Tsirkin wrote:
>>>>> On Fri, Aug 16, 2013 at 01:16:30PM +0800, Jason Wang wrote:
>>>>>>> We used to limit the max pending DMAs to prevent guest from pinning too many
>>>>>>> pages. But this could be removed since:
>>>>>>>
>>>>>>> - We have the sk_wmem_alloc check in both tun/macvtap to do the same work
>>>>>>> - This max pending check were almost useless since it was one done when there's
>>>>>>> no new buffers coming from guest. Guest can easily exceeds the limitation.
>>>>>>> - We've already check upend_idx != done_idx and switch to non zerocopy then. So
>>>>>>> even if all vq->heads were used, we can still does the packet transmission.
>>>>> We can but performance will suffer.
>>> The check were in fact only done when no new buffers submitted from
>>> guest. So if guest keep sending, the check won't be done.
>>>
>>> If we really want to do this, we should do it unconditionally. Anyway, I
>>> will do test to see the result.
>> There's a bug in PATCH 5/6, the check:
>>
>> nvq->upend_idx != nvq->done_idx
>>
>> makes the zerocopy always been disabled since we initialize both
>> upend_idx and done_idx to zero. So I change it to:
>>
>> (nvq->upend_idx + 1) % UIO_MAXIOV != nvq->done_idx.
> But what I would really like to try is limit ubuf_info to VHOST_MAX_PEND.
> I think this has a chance to improve performance since
> we'll be using less cache.
Maybe, but it in fact decrease the vq size to VHOST_MAX_PEND.
> Of course this means we must fix the code to really never submit
> more than VHOST_MAX_PEND requests.
>
> Want to try?
Ok, sure.
>> With this change on top, I didn't see performance difference w/ and w/o
>> this patch.
> Did you try small message sizes btw (like 1K)? Or just netperf
> default of 64K?
>
I just test multiple sessions of TCP_RR. Will test TCP_STREAM also.
^ permalink raw reply
* Re: [PATCH v4 3/5] net: ethernet: cpsw: introduce ti,am3352-cpsw compatible string
From: Sekhar Nori @ 2013-08-26 6:45 UTC (permalink / raw)
To: Mugunthan V N
Cc: Santosh Shilimkar, Daniel Mack, netdev, bcousson, sergei.shtylyov,
davem, ujhelyi.m, vaibhav.bedia, d-gerlach, linux-arm-kernel,
linux-omap, devicetree, Grant Likely, Rob Herring
In-Reply-To: <521AEECF.8060606@ti.com>
On Monday 26 August 2013 11:29 AM, Mugunthan V N wrote:
> On Saturday 24 August 2013 01:24 AM, Santosh Shilimkar wrote:
>> On Friday 23 August 2013 02:29 PM, Mugunthan V N wrote:
>>> On Friday 23 August 2013 11:40 PM, Santosh Shilimkar wrote:
>>>> On Friday 23 August 2013 01:39 PM, Sekhar Nori wrote:
>>>>> On 8/23/2013 10:58 PM, Santosh Shilimkar wrote:
>>>>>> On Friday 23 August 2013 01:24 PM, Daniel Mack wrote:
>>>>>>> On 23.08.2013 19:19, Santosh Shilimkar wrote:
>>>>>>>> On Friday 23 August 2013 01:09 PM, Sekhar Nori wrote:
>>>>>>>>> On 8/23/2013 10:26 PM, Santosh Shilimkar wrote:
>>>>>>>>>> So just stick the IP version or call it cpsw-v1... cpsw-v2 etc.
>>>>>>>>> If this could be handled using IP version then the right way would be to
>>>>>>>>> just read the IP version from hardware and use it. No need of DT property.
>>>>>>>>>
>>>>>>>> Thats fine as well but I thought the patch needed additional properties like
>>>>>>>> CM reg-address come from DT and hence the separate compatible. If you can
>>>>>>>> manage without that, thats even better.
>>>>>>> We can't, that's the whole point :)
>>>>>>>
>>>>>> I saw that from the patch :)
>>>>>>
>>>>>>> Well, theoretically, we could for now, but that's not a clean solution.
>>>>>>> Again: the problem here is that the control port is separated from the
>>>>>>> cpsw core, and so we have to implement something specific for the AM3352
>>>>>>> SoC. I know that's a violation of clean and generic driver ideas, but
>>>>>>> there's no way we can assume that every cpsw v2 ip block has a control
>>>>>>> port that is compatible to the one found on am335x chips.
>>>>>>>
>>>>>> But there is a possibility that other SOC will just use the same
>>>>>> control module approach. So using a revision IP is just fine. BTW,
>>>>> But this is misleading because it makes appear like the same compatible
>>>>> can be used on on another SoC like DRA7 which probably has the same
>>>>> version of IP but a different control module implementation, when in
>>>>> practice it cannot.
>>>>>
>>>>> The fact is we are doing something SoC specific in the driver and we
>>>>> cannot hide that behind IP versions. If really in practice there comes
>>>>> another SoC with the same control module definition then it can always
>>>>> use ti,am3352-cpsw compatible as well. The compatible name does not
>>>>> preclude its usage.
>>>>>
>>>> My point was the CPSW needs a feature which is implemented using
>>>> control module rather than within the IP itself. Its an implementation
>>>> detail. As such the additional feature makes sense for that IP. O.w
>>>> there was no need to do any monkeying with control module.
>>>>
>>>> E.g
>>>> MMC card detect is a basic functionality, implemented by various types
>>>> like control module, PMIC or MMC IP itself. As such the driver need
>>>> that support and all the implementation details needs to still handled
>>>> to make that part work.
>>>>
>>>>
>>> CPSW core as such understands only GMII/MII signals, there is an
>>> additional module which converts GMII/MII signals to RGMII/RMII signals
>>> respectively which is called as CPRGMII/CPRMII as specified in the
>>> AM335x TRM in Figure 14-1. Ethernet Switch Integration.
>>>
>>> So to control this sub-module, the control register is used and this has
>>> to be configured according to the EVM design like what mode of phy is
>>> connected. CPRGMII and CPRMII is no way related to CPSW core.
>>>
>> Ok then why are you polluting cpsw driver with that code which
>> not realted to CPSW as you said above. You are contradicting what
>> you said by supporting the SOC usage in the core CPSW driver.
> This patch series is not from me and because of the reason I mentioned
> about control module driver, so that cpsw driver can make use control
> module apis to select phy mode and control module driver takes care of
> SoC specific register offsets and definitions, but now it is not
> possible as it is not acceptable in mainline. So other way is to keep
> these in driver itself as it is done in this patch series with SoC
> compatibilities.
What is done in this patch is _not_ "SoC compatibilities". SoC
compatibility would be what was done in v1 of this patch ie, explicit
check for
of_machine_is_compatible("ti,am33xx")
"ti,am3352-cpsw" says "CPSW as implemented on AM3352". This is not the
same as checking if SoC is AM3352.
The example quoted on ePAPR spec for a compatible string is:
compatible = “fsl,mpc8641-uart”, “ns16550";
MPC8641 is freescale PowerPC based SoC[1]. This shows that it is not
unnatural to use SoC names in compatibles for IPs. That, or the ePAPR
specification needs to be updated to show the right example of how a
compatible could be defined. Until then I see no reason of changing what
is implemented in this patch.
In short, even if there was no control module handling in the driver,
using "ti,am3352-cpsw" would be just fine.
I have also CCed the DT maintainers for their opinion. They should have
been explicitly CCed anyway.
Thanks,
Sekhar
[1] http://www.freescale.com/files/32bit/doc/data_sheet/MPC8641DEC.pdf
^ permalink raw reply
* Re: [PATCH 1/2] genl: Fix genl dumpit() locking.
From: Johannes Berg @ 2013-08-26 6:06 UTC (permalink / raw)
To: Pravin Shelar; +Cc: netdev, Jesse Gross
In-Reply-To: <CALnjE+qn8THcPABZojWoE3OW2Y2TKZGSjB24ZWLC5AGM5yKm9w@mail.gmail.com>
On Fri, 2013-08-23 at 13:52 -0700, Pravin Shelar wrote:
> > I'm still missing something. Kernel 3.4 had cb_mutex assign to the
> > genl_mutex, but we saw the original crash there, apparently dumpit
> > *wasn't* (always) locked with it?
> Can you point me to original crash on 3.4?
Sure, below.
johannes
[1389854.965295] cfg80211: Calling CRDA to update world regulatory domain
[1389854.973801] Intel(R) Wireless WiFi driver for Linux, in-tree:d
[1389854.973804] Copyright(c) 2003-2013 Intel Corporation
[1389854.982900] cfg80211: World regulatory domain updated:
[1389854.982908] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[1389854.982913] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[1389854.982919] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[1389854.982923] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[1389854.982928] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[1389854.982932] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[1389857.247719] BUG: unable to handle kernel paging request at f8467360
[1389857.249716] IP: [<c14c56bb>] ctrl_dumpfamily+0x6b/0xe0
[1389857.251798] *pde = 2ffd7067 *pte = 00000000
[1389857.253903] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
[1389857.256002] Modules linked in: cfg80211(O) ...
[1389857.265729]
[1389857.268159] Pid: 20081, comm: wpa_supplicant Tainted: G W O 3.4.47-dev #1 Dell Inc. Latitude E6430/0CPWYR
[1389857.270726] EIP: 0060:[<c14c56bb>] EFLAGS: 00210297 CPU: 2
[1389857.273291] EIP is at ctrl_dumpfamily+0x6b/0xe0
[1389857.275829] EAX: f8467378 EBX: f8467340 ECX: 00000000 EDX: ec1610c4
[1389857.278365] ESI: 00000001 EDI: c2077cc0 EBP: c46c3c00 ESP: c46c3bd4
[1389857.280921] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
[1389857.283508] CR0: 80050033 CR2: f8467360 CR3: 26e54000 CR4: 001407d0
[1389857.286130] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[1389857.288770] DR6: ffff0ff0 DR7: 00000400
[1389857.291363] Process wpa_supplicant (pid: 20081, ti=c46c2000 task=c44640b0 task.ti=c46c2000)
[1389857.294044] Stack:
[1389857.296668] 00000002 caef8000 00000001 caef8000 00000000 e6ccc3c0 c1861f00 00000000
[1389857.299377] e73cd910 e6ccc3c0 caef8000 c46c3c28 c14c20bc 000000d0 00200246 00200246
[1389857.302077] e73cd910 e6ccc3c0 e73cd910 e6ccc3c0 00000000 c46c3c48 c14c3450 d0757b00
[1389857.304794] Call Trace:
[1389857.307443] [<c14c20bc>] netlink_dump+0x5c/0x200
[1389857.310110] [<c14c3450>] __netlink_dump_start+0x140/0x160
[1389857.312779] [<c14c5650>] ? ctrl_fill_info+0x370/0x370
[1389857.315442] [<c14c5172>] genl_rcv_msg+0x102/0x270
[1389857.318096] [<c14c5034>] ? genl_lock+0x14/0x20
[1389857.320765] [<c15acdb2>] ? mutex_lock_nested+0x222/0x2f0
[1389857.323424] [<c15acdc2>] ? mutex_lock_nested+0x232/0x2f0
[1389857.326026] [<c14c5034>] ? genl_lock+0x14/0x20
[1389857.328621] [<c14c5650>] ? ctrl_fill_info+0x370/0x370
[1389857.331224] [<c14c5070>] ? genl_rcv+0x30/0x30
[1389857.333822] [<c14c4b5e>] netlink_rcv_skb+0x8e/0xb0
[1389857.336420] [<c14c505c>] genl_rcv+0x1c/0x30
[1389857.339014] [<c14c456b>] netlink_unicast+0x17b/0x1c0
[1389857.341617] [<c14c47d4>] netlink_sendmsg+0x224/0x370
[1389857.344215] [<c1485adf>] sock_sendmsg+0xff/0x120
[1389857.346812] [<c112ad04>] ? might_fault+0x54/0xb0
[1389857.349403] [<c112ad4e>] ? might_fault+0x9e/0xb0
[1389857.351982] [<c12de3c2>] ? _copy_from_user+0x42/0x60
[1389857.354558] [<c14926e4>] ? verify_iovec+0x44/0xb0
[1389857.357086] [<c1486b0a>] __sys_sendmsg+0x24a/0x260
[1389857.359563] [<c12e39de>] ? do_raw_spin_unlock+0x4e/0x90
[1389857.362025] [<c110af35>] ? unlock_page+0x45/0x50
[1389857.364443] [<c112aff8>] ? __do_fault+0x298/0x450
[1389857.366858] [<c112db01>] ? handle_pte_fault+0xe1/0x7d0
[1389857.369178] [<c15b3b8b>] ? do_page_fault+0xcb/0x4b0
[1389857.371403] [<c1150b45>] ? fget_light+0x1d5/0x470
[1389857.373618] [<c1487fdb>] sys_sendmsg+0x3b/0x60
[1389857.375827] [<c1488683>] sys_socketcall+0x283/0x2e0
[1389857.377946] [<c15b072d>] ? restore_all+0xf/0xf
[1389857.379981] [<c15b3ac0>] ? vmalloc_fault+0x114/0x114
[1389857.381927] [<c12ddea8>] ? trace_hardirqs_on_thunk+0xc/0x10
[1389857.383796] [<c15b7c1f>] sysenter_do_call+0x12/0x38
[1389857.385644] Code: 8d 3c c5 c0 7c 07 c2 8b 04 c5 c0 7c 07 c2 39 c7 8d 58 c8 75 16 eb 71 90 81 7d ec 00 1f 86 c1 74 10 8b 43 38 39 c7 8d 58 c8 74 5d <80> 7b 20 00 74 e7 83 c6 01 3b 75 f0 7c e8 8b 55 e8 8b 42 04 8b
[1389857.389897] EIP: [<c14c56bb>] ctrl_dumpfamily+0x6b/0xe0 SS:ESP 0068:c46c3bd4
[1389857.391949] CR2: 00000000f8467360
[1389857.496970] ---[ end trace 52efe903d218886a ]---
[1389857.496977] BUG: sleeping function called from invalid context at kernel/rwsem.c:20
[1389857.496982] in_atomic(): 0, irqs_disabled(): 1, pid: 20081, name: wpa_supplicant
[1389857.496986] INFO: lockdep is turned off.
[1389857.496989] irq event stamp: 0
[1389857.496992] hardirqs last enabled at (0): [< (null)>] (null)
[1389857.496997] hardirqs last disabled at (0): [<c1031aa8>] copy_process+0x468/0x1280
[1389857.497006] softirqs last enabled at (0): [<c1031aa8>] copy_process+0x468/0x1280
[1389857.497012] softirqs last disabled at (0): [< (null)>] (null)
[1389857.497019] Pid: 20081, comm: wpa_supplicant Tainted: G D W O 3.4.47-dev #1
[1389857.497022] Call Trace:
[1389857.497031] [<c1067322>] __might_sleep+0x162/0x200
[1389857.497038] [<c15add80>] down_read+0x20/0x8b
[1389857.497046] [<c1049f5e>] exit_signals+0x1e/0x110
[1389857.497053] [<c10381b7>] do_exit+0x97/0x9b0
[1389857.497059] [<c1035753>] ? kmsg_dump+0x193/0x270
[1389857.497065] [<c1035630>] ? kmsg_dump+0x70/0x270
[1389857.497073] [<c15a60e2>] ? printk+0x2d/0x2f
[1389857.497079] [<c15b1646>] oops_end+0x96/0xd0
[1389857.497086] [<c15a5aac>] no_context+0x18c/0x194
[1389857.497098] [<c15a5bf8>] __bad_area_nosemaphore+0x144/0x14c
[1389857.497106] [<c10960bb>] ? trace_hardirqs_on+0xb/0x10
[1389857.497114] [<c148c7cf>] ? sock_rmalloc+0x3f/0x90
[1389857.497122] [<c15b3ac0>] ? vmalloc_fault+0x114/0x114
[1389857.497128] [<c15a5c17>] bad_area_nosemaphore+0x17/0x19
[1389857.497135] [<c15b3d9f>] do_page_fault+0x2df/0x4b0
[1389857.497141] [<c14c2049>] ? __nlmsg_put+0x59/0x70
[1389857.497149] [<c12ec362>] ? __nla_reserve+0x42/0x60
[1389857.497154] [<c15b0e54>] ? error_code+0x68/0x74
[1389857.497160] [<c15b3ac0>] ? vmalloc_fault+0x114/0x114
[1389857.497167] [<c1093adf>] ? trace_hardirqs_off_caller+0x1f/0x130
[1389857.497176] [<c15b3ac0>] ? vmalloc_fault+0x114/0x114
[1389857.497181] [<c15b0e58>] error_code+0x6c/0x74
[1389857.497191] [<c14c56bb>] ? ctrl_dumpfamily+0x6b/0xe0
[1389857.497197] [<c14c20bc>] netlink_dump+0x5c/0x200
[1389857.497204] [<c14c3450>] __netlink_dump_start+0x140/0x160
[1389857.497210] [<c14c5650>] ? ctrl_fill_info+0x370/0x370
[1389857.497216] [<c14c5172>] genl_rcv_msg+0x102/0x270
[1389857.497222] [<c14c5034>] ? genl_lock+0x14/0x20
[1389857.497229] [<c15acdb2>] ? mutex_lock_nested+0x222/0x2f0
[1389857.497236] [<c15acdc2>] ? mutex_lock_nested+0x232/0x2f0
[1389857.497242] [<c14c5034>] ? genl_lock+0x14/0x20
[1389857.497248] [<c14c5650>] ? ctrl_fill_info+0x370/0x370
[1389857.497254] [<c14c5070>] ? genl_rcv+0x30/0x30
[1389857.497260] [<c14c4b5e>] netlink_rcv_skb+0x8e/0xb0
[1389857.497267] [<c14c505c>] genl_rcv+0x1c/0x30
[1389857.497273] [<c14c456b>] netlink_unicast+0x17b/0x1c0
[1389857.497279] [<c14c47d4>] netlink_sendmsg+0x224/0x370
[1389857.497286] [<c1485adf>] sock_sendmsg+0xff/0x120
[1389857.497294] [<c112ad04>] ? might_fault+0x54/0xb0
[1389857.497301] [<c112ad4e>] ? might_fault+0x9e/0xb0
[1389857.497308] [<c12de3c2>] ? _copy_from_user+0x42/0x60
[1389857.497313] [<c14926e4>] ? verify_iovec+0x44/0xb0
[1389857.497320] [<c1486b0a>] __sys_sendmsg+0x24a/0x260
[1389857.497326] [<c12e39de>] ? do_raw_spin_unlock+0x4e/0x90
[1389857.497333] [<c110af35>] ? unlock_page+0x45/0x50
[1389857.497340] [<c112aff8>] ? __do_fault+0x298/0x450
[1389857.497346] [<c112db01>] ? handle_pte_fault+0xe1/0x7d0
[1389857.497353] [<c15b3b8b>] ? do_page_fault+0xcb/0x4b0
[1389857.497359] [<c1150b45>] ? fget_light+0x1d5/0x470
[1389857.497366] [<c1487fdb>] sys_sendmsg+0x3b/0x60
[1389857.497372] [<c1488683>] sys_socketcall+0x283/0x2e0
[1389857.497378] [<c15b072d>] ? restore_all+0xf/0xf
[1389857.497384] [<c15b3ac0>] ? vmalloc_fault+0x114/0x114
[1389857.497391] [<c12ddea8>] ? trace_hardirqs_on_thunk+0xc/0x10
[1389857.497397] [<c15b7c1f>] sysenter_do_call+0x12/0x38
^ permalink raw reply
* Re: [PATCH RFC net-next] net: epoll support for busy poll
From: Eliezer Tamir @ 2013-08-26 6:03 UTC (permalink / raw)
To: Amir Vadai
Cc: Eliezer Tamir, Willem de Bruijn, Eilon Greenstein, Eric Wong,
netdev, e1000-devel, Eric Dumazet, linux-kernel, David Miller
In-Reply-To: <CAPcc5PhQGB195pMsMGOEE8BhZTvfXOf+Fh+3PdPbuOS0t1SULQ@mail.gmail.com>
On 26/08/2013 00:30, Amir Vadai wrote:
> I'm on vacation, will test and have some inputs later this week when I be
> back.
>
Hello Amir,
Ping me when you get back and I will send you my latest so you can
play with it.
^ permalink raw reply
* Re: [PATCH v4 3/5] net: ethernet: cpsw: introduce ti,am3352-cpsw compatible string
From: Mugunthan V N @ 2013-08-26 5:59 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: devicetree, sergei.shtylyov, d-gerlach, netdev, Sekhar Nori,
vaibhav.bedia, Daniel Mack, bcousson, ujhelyi.m, linux-omap,
davem, linux-arm-kernel
In-Reply-To: <5217BDFA.5040904@ti.com>
On Saturday 24 August 2013 01:24 AM, Santosh Shilimkar wrote:
> On Friday 23 August 2013 02:29 PM, Mugunthan V N wrote:
>> On Friday 23 August 2013 11:40 PM, Santosh Shilimkar wrote:
>>> On Friday 23 August 2013 01:39 PM, Sekhar Nori wrote:
>>>> On 8/23/2013 10:58 PM, Santosh Shilimkar wrote:
>>>>> On Friday 23 August 2013 01:24 PM, Daniel Mack wrote:
>>>>>> On 23.08.2013 19:19, Santosh Shilimkar wrote:
>>>>>>> On Friday 23 August 2013 01:09 PM, Sekhar Nori wrote:
>>>>>>>> On 8/23/2013 10:26 PM, Santosh Shilimkar wrote:
>>>>>>>>> So just stick the IP version or call it cpsw-v1... cpsw-v2 etc.
>>>>>>>> If this could be handled using IP version then the right way would be to
>>>>>>>> just read the IP version from hardware and use it. No need of DT property.
>>>>>>>>
>>>>>>> Thats fine as well but I thought the patch needed additional properties like
>>>>>>> CM reg-address come from DT and hence the separate compatible. If you can
>>>>>>> manage without that, thats even better.
>>>>>> We can't, that's the whole point :)
>>>>>>
>>>>> I saw that from the patch :)
>>>>>
>>>>>> Well, theoretically, we could for now, but that's not a clean solution.
>>>>>> Again: the problem here is that the control port is separated from the
>>>>>> cpsw core, and so we have to implement something specific for the AM3352
>>>>>> SoC. I know that's a violation of clean and generic driver ideas, but
>>>>>> there's no way we can assume that every cpsw v2 ip block has a control
>>>>>> port that is compatible to the one found on am335x chips.
>>>>>>
>>>>> But there is a possibility that other SOC will just use the same
>>>>> control module approach. So using a revision IP is just fine. BTW,
>>>> But this is misleading because it makes appear like the same compatible
>>>> can be used on on another SoC like DRA7 which probably has the same
>>>> version of IP but a different control module implementation, when in
>>>> practice it cannot.
>>>>
>>>> The fact is we are doing something SoC specific in the driver and we
>>>> cannot hide that behind IP versions. If really in practice there comes
>>>> another SoC with the same control module definition then it can always
>>>> use ti,am3352-cpsw compatible as well. The compatible name does not
>>>> preclude its usage.
>>>>
>>> My point was the CPSW needs a feature which is implemented using
>>> control module rather than within the IP itself. Its an implementation
>>> detail. As such the additional feature makes sense for that IP. O.w
>>> there was no need to do any monkeying with control module.
>>>
>>> E.g
>>> MMC card detect is a basic functionality, implemented by various types
>>> like control module, PMIC or MMC IP itself. As such the driver need
>>> that support and all the implementation details needs to still handled
>>> to make that part work.
>>>
>>>
>> CPSW core as such understands only GMII/MII signals, there is an
>> additional module which converts GMII/MII signals to RGMII/RMII signals
>> respectively which is called as CPRGMII/CPRMII as specified in the
>> AM335x TRM in Figure 14-1. Ethernet Switch Integration.
>>
>> So to control this sub-module, the control register is used and this has
>> to be configured according to the EVM design like what mode of phy is
>> connected. CPRGMII and CPRMII is no way related to CPSW core.
>>
> Ok then why are you polluting cpsw driver with that code which
> not realted to CPSW as you said above. You are contradicting what
> you said by supporting the SOC usage in the core CPSW driver.
This patch series is not from me and because of the reason I mentioned
about control module driver, so that cpsw driver can make use control
module apis to select phy mode and control module driver takes care of
SoC specific register offsets and definitions, but now it is not
possible as it is not acceptable in mainline. So other way is to keep
these in driver itself as it is done in this patch series with SoC
compatibilities.
Regards
Mugunthan V N
^ permalink raw reply
* Re: [GLIBC Patch v2] inet: avoid redefinition of some structs in kernel
From: Mike Frysinger @ 2013-08-26 5:26 UTC (permalink / raw)
To: libc-alpha
Cc: Cong Wang, netdev, David S. Miller, Thomas Backlund,
YOSHIFUJI Hideaki, Carlos O'Donell
In-Reply-To: <1376558891-26221-2-git-send-email-amwang@redhat.com>
[-- Attachment #1: Type: Text/Plain, Size: 985 bytes --]
On Thursday 15 August 2013 05:28:11 Cong Wang wrote:
> From: Carlos O'Donell <carlos@redhat.com>
>
> - Synchronize linux's `include/uapi/linux/in6.h'
> with glibc's `inet/netinet/in.h'.
> - Synchronize glibc's `inet/netinet/in.h with linux's
> `include/uapi/linux/in6.h'.
> - Allow including the headers in either other.
> - First header included defines the structures and macros.
>
> Notes:
> - You want netinet/in.h to include bits/in.h as early as possible,
> but it needs in_addr so define in_addr early.
> - You want bits/in.h included as early as possible so you can use
> the linux specific code to define __USE_KERNEL_DEFS based on
> the _UAPI_* macro definition and use those to cull in.h.
> - glibc was missing IPPROTO_MH, added here.
can we get something better documented here in a central location ? having
the names laid out in a git commit message and in a few leaf headers does not
lend itself to being easily discoverable.
-mike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* RE: [PATCH v4 3/5] net: ethernet: cpsw: introduce ti,am3352-cpsw compatible string
From: Gupta, Pekon @ 2013-08-26 5:22 UTC (permalink / raw)
To: N, Mugunthan V, Shilimkar, Santosh, bcousson@baylibre.com,
Daniel Mack, Nori, Sekhar
Cc: devicetree@vger.kernel.org, sergei.shtylyov@cogentembedded.com,
Gerlach, Dave, netdev@vger.kernel.org, Bedia, Vaibhav,
ujhelyi.m@gmail.com, linux-omap@vger.kernel.org,
davem@davemloft.net, linux-arm-kernel@lists.infradead.org
In-Reply-To: <52179AA5.3060408@ti.com>
>
> On Friday 23 August 2013 10:26 PM, Santosh Shilimkar wrote:
> > On Friday 23 August 2013 12:30 PM, Daniel Mack wrote:
> >> On 23.08.2013 16:23, Santosh Shilimkar wrote:
> >>> On Friday 23 August 2013 10:16 AM, Daniel Mack wrote:
> >>>> +static const struct of_device_id cpsw_of_mtable[] = {
> >>>> + {
> >>>> + .compatible = "ti,am3352-cpsw",
> >>> I didn't notice this earlier, but can't you use the IP version
> >>> as a compatible instead of using a SOC name. Whats really SOC specific
> >>> on this IP ? Sorry i have missed any earlier discussion on this but
> >>> this approach doesn't seem good. Its like adding SOC checks in the
> >>> driver subsystem.
> >> As I already mentioned in the cover letter and in the commit message, I
> >> just don't know which criteria makes most sense here.
> >>
> >> On a general note, I would say that chances that this exactly IP core
> >> with the same version number will appear on some other silicon which
> >> doesn't support the control mode register in an AM33xx fashion, is not
> >> necessarily negligible.
> >>
> >> So what that new compatible string denotes is the cpsw in a version as
> >> found on am3352 SoCs, which is actually exactly what it does.
> >>
> >> I don't have a strong opinion here, but see your point. I just don't
> >> have a better idea on how to treat that.
> >>
> > So just stick the IP version or call it cpsw-v1... cpsw-v2 etc.
> > That way if in future if someone uses those features, they can use
> > this compatible if they don't they use the one which suites that
> > SOC.
> >
> We cannot map control module register with CPSW IP version as both comes
> from different design team and CPSW ip version can be same across SoC
> and gmii sel register definition can be different. Control module
> defines may vary in different SoC as per SoC requirements.
>
> Adding Pekon Gupta who had worked in Silicon team before.
>
[Pekon]: My opinion here..
Uniformity in control module cannot be guaranteed, neither in register
offsets nor their functionality. Uniformity is usually maintained till the
point same person is writing the spec, or it’s a derivative device.
Control-module should not be categorized as IP, instead it’s a group of
miscellaneous logic usually consisting of following:
(a) SoC bug-fixes across silicon revisions.
(b) SoC specific logic like device_type, JTAG-ID.
(c) IP bug fixes which could not be accommodated in IP address-map.
(d) IP logic which depends on SoC configurations.
Due to this un-deterministic composition of control-module, having
a dedicated driver for control module might not work either, as it
has to be updated | re-written for every new device.
So, Following can be used as guideline to determine compatibility
string for DT bindings..
- If binding maps to (a) and (c), .i.e., bug-fixes for SoC or IP,
then its most likely that these would change either in next silicon
revision or in next devices. Hence such bindings should use *not*
use IP compatibility strings, they _may_ use SoC-name based
compatibility string.
- Else if binding maps to (b),.i.e., SoC specific configurations.
then their offsets and functionality should remain same across the
family of devices at-least, so it should use SoC-name based
compatibility string.
- And if binding maps to (d), .i.e., IP feature but depending on SoC
Then it can use IP based compatibility string, along with IP version.
(same approach can be used for CPSW binding used here,
with regards, pekon
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 net-next] tcp: TSO packets automatic sizing
From: Eric Dumazet @ 2013-08-26 4:26 UTC (permalink / raw)
To: David Miller
Cc: netdev, Neal Cardwell, Yuchung Cheng, Van Jacobson, Tom Herbert
In-Reply-To: <1377304192.8828.43.camel@edumazet-glaptop>
From: Eric Dumazet <edumazet@google.com>
After hearing many people over past years complaining against TSO being
bursty or even buggy, we are proud to present automatic sizing of TSO
packets.
One part of the problem is that tcp_tso_should_defer() uses an heuristic
relying on upcoming ACKS instead of a timer, but more generally, having
big TSO packets makes little sense for low rates, as it tends to create
micro bursts on the network, and general consensus is to reduce the
buffering amount.
This patch introduces a per socket sk_pacing_rate, that approximates
the current sending rate, and allows us to size the TSO packets so
that we try to send one packet every ms.
This field could be set by other transports.
Patch has no impact for high speed flows, where having large TSO packets
makes sense to reach line rate.
For other flows, this helps better packet scheduling and ACK clocking.
This patch increases performance of TCP flows in lossy environments.
A new sysctl (tcp_min_tso_segs) is added, to specify the
minimal size of a TSO packet (default being 2).
A follow-up patch will provide a new packet scheduler (FQ), using
sk_pacing_rate as an input to perform optional per flow pacing.
This explains why we chose to set sk_pacing_rate to twice the current
rate, allowing 'slow start' ramp up.
sk_pacing_rate = 2 * cwnd * mss / srtt
v2: Neal Cardwell reported a suspect deferring of last two segments on
initial write of 10 MSS, I had to change tcp_tso_should_defer() to take
into account tp->xmit_size_goal_segs
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Cc: Yuchung Cheng <ycheng@google.com>
Cc: Van Jacobson <vanj@google.com>
Cc: Tom Herbert <therbert@google.com>
---
Documentation/networking/ip-sysctl.txt | 9 ++++++
include/net/sock.h | 2 +
include/net/tcp.h | 1
net/ipv4/sysctl_net_ipv4.c | 10 +++++++
net/ipv4/tcp.c | 28 +++++++++++++++++---
net/ipv4/tcp_input.c | 31 ++++++++++++++++++++++-
net/ipv4/tcp_output.c | 2 -
7 files changed, 76 insertions(+), 7 deletions(-)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index debfe85..ce5bb43 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -482,6 +482,15 @@ tcp_syn_retries - INTEGER
tcp_timestamps - BOOLEAN
Enable timestamps as defined in RFC1323.
+tcp_min_tso_segs - INTEGER
+ Minimal number of segments per TSO frame.
+ Since linux-3.12, TCP does an automatic sizing of TSO frames,
+ depending on flow rate, instead of filling 64Kbytes packets.
+ For specific usages, it's possible to force TCP to build big
+ TSO frames. Note that TCP stack might split too big TSO packets
+ if available window is too small.
+ Default: 2
+
tcp_tso_win_divisor - INTEGER
This allows control over what percentage of the congestion window
can be consumed by a single TSO frame.
diff --git a/include/net/sock.h b/include/net/sock.h
index e4bbcbf..6ba2e7b 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -232,6 +232,7 @@ struct cg_proto;
* @sk_napi_id: id of the last napi context to receive data for sk
* @sk_ll_usec: usecs to busypoll when there is no data
* @sk_allocation: allocation mode
+ * @sk_pacing_rate: Pacing rate (if supported by transport/packet scheduler)
* @sk_sndbuf: size of send buffer in bytes
* @sk_flags: %SO_LINGER (l_onoff), %SO_BROADCAST, %SO_KEEPALIVE,
* %SO_OOBINLINE settings, %SO_TIMESTAMPING settings
@@ -361,6 +362,7 @@ struct sock {
kmemcheck_bitfield_end(flags);
int sk_wmem_queued;
gfp_t sk_allocation;
+ u32 sk_pacing_rate; /* bytes per second */
netdev_features_t sk_route_caps;
netdev_features_t sk_route_nocaps;
int sk_gso_type;
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 09cb5c1..73fcd7c 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -281,6 +281,7 @@ extern int sysctl_tcp_early_retrans;
extern int sysctl_tcp_limit_output_bytes;
extern int sysctl_tcp_challenge_ack_limit;
extern unsigned int sysctl_tcp_notsent_lowat;
+extern int sysctl_tcp_min_tso_segs;
extern atomic_long_t tcp_memory_allocated;
extern struct percpu_counter tcp_sockets_allocated;
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index 8ed7c32..540279f 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -29,6 +29,7 @@
static int zero;
static int one = 1;
static int four = 4;
+static int gso_max_segs = GSO_MAX_SEGS;
static int tcp_retr1_max = 255;
static int ip_local_port_range_min[] = { 1, 1 };
static int ip_local_port_range_max[] = { 65535, 65535 };
@@ -761,6 +762,15 @@ static struct ctl_table ipv4_table[] = {
.extra2 = &four,
},
{
+ .procname = "tcp_min_tso_segs",
+ .data = &sysctl_tcp_min_tso_segs,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_minmax,
+ .extra1 = &zero,
+ .extra2 = &gso_max_segs,
+ },
+ {
.procname = "udp_mem",
.data = &sysctl_udp_mem,
.maxlen = sizeof(sysctl_udp_mem),
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index ab64eea..e1714ee 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -283,6 +283,8 @@
int sysctl_tcp_fin_timeout __read_mostly = TCP_FIN_TIMEOUT;
+int sysctl_tcp_min_tso_segs __read_mostly = 2;
+
struct percpu_counter tcp_orphan_count;
EXPORT_SYMBOL_GPL(tcp_orphan_count);
@@ -785,12 +787,28 @@ static unsigned int tcp_xmit_size_goal(struct sock *sk, u32 mss_now,
xmit_size_goal = mss_now;
if (large_allowed && sk_can_gso(sk)) {
- xmit_size_goal = ((sk->sk_gso_max_size - 1) -
- inet_csk(sk)->icsk_af_ops->net_header_len -
- inet_csk(sk)->icsk_ext_hdr_len -
- tp->tcp_header_len);
+ u32 gso_size, hlen;
+
+ /* Maybe we should/could use sk->sk_prot->max_header here ? */
+ hlen = inet_csk(sk)->icsk_af_ops->net_header_len +
+ inet_csk(sk)->icsk_ext_hdr_len +
+ tp->tcp_header_len;
+
+ /* Goal is to send at least one packet per ms,
+ * not one big TSO packet every 100 ms.
+ * This preserves ACK clocking and is consistent
+ * with tcp_tso_should_defer() heuristic.
+ */
+ gso_size = sk->sk_pacing_rate / (2 * MSEC_PER_SEC);
+ gso_size = max_t(u32, gso_size,
+ sysctl_tcp_min_tso_segs * mss_now);
+
+ xmit_size_goal = min_t(u32, gso_size,
+ sk->sk_gso_max_size - 1 - hlen);
- /* TSQ : try to have two TSO segments in flight */
+ /* TSQ : try to have at least two segments in flight
+ * (one in NIC TX ring, another in Qdisc)
+ */
xmit_size_goal = min_t(u32, xmit_size_goal,
sysctl_tcp_limit_output_bytes >> 1);
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index ec492ea..3d63db7 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -688,6 +688,33 @@ static void tcp_rtt_estimator(struct sock *sk, const __u32 mrtt)
}
}
+/* Set sk_pacing_rate to allow proper sizing of TSO packets.
+ * Note: TCP stack does not yet implement pacing.
+ * FQ packet scheduler can be used to implement cheap but effective
+ * TCP pacing, to smooth the burst on large writes when packets
+ * in flight is significantly lower than cwnd (or rwin)
+ */
+static void tcp_update_pacing_rate(struct sock *sk)
+{
+ const struct tcp_sock *tp = tcp_sk(sk);
+ u64 rate;
+
+ /* set sk_pacing_rate to 200 % of current rate (mss * cwnd / rtt) */
+ rate = (u64)tp->mss_cache * 8 * 2 * USEC_PER_SEC;
+
+ rate *= max(tp->snd_cwnd, tp->packets_out);
+
+ do_div(rate, jiffies_to_usecs(tp->srtt));
+
+ /* Correction for small srtt : minimum srtt being 8 (1 jiffy),
+ * be conservative and assume rtt = 1/(8*HZ) instead of 1/HZ s
+ * We probably need usec resolution in the future.
+ */
+ if (tp->srtt <= 8 + 2)
+ rate <<= 3;
+ sk->sk_pacing_rate = min_t(u64, rate, ~0U);
+}
+
/* Calculate rto without backoff. This is the second half of Van Jacobson's
* routine referred to above.
*/
@@ -3278,7 +3305,7 @@ static int tcp_ack(struct sock *sk, const struct sk_buff *skb, int flag)
u32 ack_seq = TCP_SKB_CB(skb)->seq;
u32 ack = TCP_SKB_CB(skb)->ack_seq;
bool is_dupack = false;
- u32 prior_in_flight;
+ u32 prior_in_flight, prior_cwnd = tp->snd_cwnd, prior_rtt = tp->srtt;
u32 prior_fackets;
int prior_packets = tp->packets_out;
const int prior_unsacked = tp->packets_out - tp->sacked_out;
@@ -3383,6 +3410,8 @@ static int tcp_ack(struct sock *sk, const struct sk_buff *skb, int flag)
if (icsk->icsk_pending == ICSK_TIME_RETRANS)
tcp_schedule_loss_probe(sk);
+ if (tp->srtt != prior_rtt || tp->snd_cwnd != prior_cwnd)
+ tcp_update_pacing_rate(sk);
return 1;
no_queue:
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 884efff..e63ae4c 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1631,7 +1631,7 @@ static bool tcp_tso_should_defer(struct sock *sk, struct sk_buff *skb)
/* If a full-sized TSO skb can be sent, do it. */
if (limit >= min_t(unsigned int, sk->sk_gso_max_size,
- sk->sk_gso_max_segs * tp->mss_cache))
+ tp->xmit_size_goal_segs * tp->mss_cache))
goto send_now;
/* Middle in queue won't get any more data, full sendable already? */
^ permalink raw reply related
* Re: [PATCH net-next] tcp: TSO packets automatic sizing
From: Eric Dumazet @ 2013-08-26 3:58 UTC (permalink / raw)
To: Yuchung Cheng
Cc: Neal Cardwell, David Miller, netdev, Van Jacobson, Tom Herbert
In-Reply-To: <1377483759.8828.104.camel@edumazet-glaptop>
On Sun, 2013-08-25 at 19:22 -0700, Eric Dumazet wrote:
> On Sun, 2013-08-25 at 17:37 -0700, Eric Dumazet wrote:
> > On Sun, 2013-08-25 at 15:01 -0700, Yuchung Cheng wrote:
> >
> > > Any idea to get rid of this undesirable extra RTT delay?
> >
> > Its probably a bug in the push code.
>
> For exact write/send of a multiple of MSS, I think following patch
> should fix the bug.
>
> If we filled a packet, we must send it.
>
> For the other problem, I think its related to Nagle.
Oh well, thats the tcp_tso_should_defer() again.
/* If a full-sized TSO skb can be sent, do it. */
if (limit >= min_t(unsigned int, sk->sk_gso_max_size,
sk->sk_gso_max_segs * tp->mss_cache))
goto send_now;
I'll send a V2 of the patch
^ permalink raw reply
* Re: [systemd-devel] [PATCH] netns: unix: only allow to find out unix socket in same net namespace
From: James Bottomley @ 2013-08-26 3:53 UTC (permalink / raw)
To: Gao feng
Cc: systemd-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
libvir-list-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux Containers,
Kay Sievers, Eric W. Biederman,
lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org
In-Reply-To: <521ACCEF.4050101-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
On Mon, 2013-08-26 at 11:35 +0800, Gao feng wrote:
> On 08/26/2013 11:19 AM, James Bottomley wrote:
> > Yes, we are discussing this problem in this whole thread.
I wasn't really watching that bit, since the problem looks solved to me.
I was just reacting against the unfortunate notion that a container
should run init.
> If so, OpenVZ
> > has never suffered from that problem and I thought it was fixed
> > upstream. I've not tested lxc tools, but the latest vzctl from the
> > openvz website will bring up a container on the vanilla 3.9 kernel
> > (provided you have USER_NS compiled in) can also be used to reboot the
> > container, so I see no reason it wouldn't work for lxc as well.
> >
>
> I'm using libvirt lxc not lxc-tools.
> Not all of users enable user namespace, I trust these container
> management
> tools can have right/proper setting which inhibit this reboot-problem
> occur.
> but I don't think this reboot-problem won't happen in any
> configuration.
It sounds like you're setting up your containers wrongly. If a
container can reboot the system it means that host root capabilities
have leaked into the container, which is a big security no-no. The
upstream way of avoiding this is USER_NS (because root in the container
is now not root in the host). The OpenVZ kernel uses a different
mechanism to solve the problem, but we think USER_NS is the better way
to go on this.
James
^ permalink raw reply
* Re: [systemd-devel] [PATCH] netns: unix: only allow to find out unix socket in same net namespace
From: Gao feng @ 2013-08-26 3:35 UTC (permalink / raw)
To: James Bottomley
Cc: systemd-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
libvir-list-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux Containers,
Kay Sievers, Eric W. Biederman,
lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org
In-Reply-To: <1377487159.2341.4.camel@dabdike>
On 08/26/2013 11:19 AM, James Bottomley wrote:
> On Mon, 2013-08-26 at 09:06 +0800, Gao feng wrote:
>> On 08/26/2013 02:16 AM, James Bottomley wrote:
>>> On Sun, 2013-08-25 at 19:37 +0200, Kay Sievers wrote:
>>>> On Sun, Aug 25, 2013 at 7:16 PM, James Bottomley
>>>> <jbottomley-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> wrote:
>>>>> On Wed, 2013-08-21 at 11:51 +0200, Kay Sievers wrote:
>>>>>> On Wed, Aug 21, 2013 at 9:22 AM, Gao feng <gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org> wrote:
>>>>>>> On 08/21/2013 03:06 PM, Eric W. Biederman wrote:
>>>>>>
>>>>>>>> I suspect libvirt should simply not share /run or any other normally
>>>>>>>> writable directory with the host. Sharing /run /var/run or even /tmp
>>>>>>>> seems extremely dubious if you want some kind of containment, and
>>>>>>>> without strange things spilling through.
>>>>>>
>>>>>> Right, /run or /var cannot be shared. It's not only about sockets,
>>>>>> many other things will also go really wrong that way.
>>>>>
>>>>> This is very narrow thinking about what a container might be and will
>>>>> cause trouble as people start to create novel uses for containers in the
>>>>> cloud if you try to impose this on our current infrastructure.
>>>>>
>>>>> One of the cgroup only container uses we see at Parallels (so no
>>>>> separate filesystem and no net namespaces) is pure apache load balancer
>>>>> type shared hosting. In this scenario, base apache is effectively
>>>>> brought up in the host environment, but then spawned instances are
>>>>> resource limited using cgroups according to what the customer has paid.
>>>>> Obviously all apache instances are sharing /var and /run from the host
>>>>> (mostly for logging and pid storage and static pages). The reason some
>>>>> hosters do this is that it allows much higher density simple web serving
>>>>> (either static pages from quota limited chroots or dynamic pages limited
>>>>> by database space constraints) because each "instance" shares so much
>>>>> from the host. The service is obviously much more basic than giving
>>>>> each customer a container running apache, but it's much easier for the
>>>>> hoster to administer and it serves the customer just as well for a large
>>>>> cross section of use cases and for those it doesn't serve, the hoster
>>>>> usually has separate container hosting (for a higher price, of course).
>>>>
>>>> The "container" as we talk about has it's own init, and no, it cannot
>>>> share /var or /run.
>>>
>>> This is what we would call an IaaS container: bringing up init and
>>> effectively a new OS inside a container is the closest containers come
>>> to being like hypervisors. It's the most common use case of Parallels
>>> containers in the field, so I'm certainly not telling you it's a bad
>>> idea.
>>>
>>>> The stuff you talk about has nothing to do with that, it's not
>>>> different from all services or a multi-instantiated service on the
>>>> host sharing the same /run and /var.
>>>
>>> I gave you one example: a really simplistic one. A more sophisticated
>>> example is a PaaS or SaaS container where you bring the OS up in the
>>> host but spawn a particular application into its own container (this is
>>> essentially similar to what Docker does). Often in this case, you do
>>> add separate mount and network namespaces to make the application
>>> isolated and migrateable with its own IP address. The reason you share
>>> init and most of the OS from the host is for elasticity and density,
>>> which are fast becoming a holy grail type quest of cloud orchestration
>>> systems: if you don't have to bring up the OS from init and you can just
>>> start the application from a C/R image (orders of magnitude smaller than
>>> a full system image) and slap on the necessary namespaces as you clone
>>> it, you have something that comes online in miliseconds which is a feat
>>> no hypervisor based virtualisation can match.
>>>
>>> I'm not saying don't pursue the IaaS case, it's definitely useful ...
>>> I'm just saying it would be a serious mistake to think that's the only
>>> use case for containers and we certainly shouldn't adjust Linux to serve
>>> only that use case.
>>>
>>
>> The feature you said above VS contianer-reboot-host bug, I prefer to
>> fix
>> the bug.
>
> What bug?
>
>> and this feature can be achieved even container unshares /run
>> directory
>> with host by default, for libvirt, user can set the container
>> configuration to
>> make the container shares the /run directory with host.
>>
>> I would like to say, the reboot from container bug is more urgent and
>> need
>> to be fixed.
>
> Are you talking about the old bug where trying to reboot an lxc
> container from within it would reboot the entire system?
Yes, we are discussing this problem in this whole thread.
If so, OpenVZ
> has never suffered from that problem and I thought it was fixed
> upstream. I've not tested lxc tools, but the latest vzctl from the
> openvz website will bring up a container on the vanilla 3.9 kernel
> (provided you have USER_NS compiled in) can also be used to reboot the
> container, so I see no reason it wouldn't work for lxc as well.
>
I'm using libvirt lxc not lxc-tools.
Not all of users enable user namespace, I trust these container management
tools can have right/proper setting which inhibit this reboot-problem occur.
but I don't think this reboot-problem won't happen in any configuration.
^ permalink raw reply
* [PATCH] net: xilinx: fix memleak
From: Libo Chen @ 2013-08-26 3:30 UTC (permalink / raw)
To: David Miller, anirudh, John.Linn; +Cc: netdev, LKML, Li Zefan
decrease device_node refcount np1 in err case.
Signed-off-by: Libo Chen <libo.chen@huawei.com>
---
drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c b/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c
index e90e1f4..64b4639 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_mdio.c
@@ -175,6 +175,7 @@ int axienet_mdio_setup(struct axienet_local *lp, struct device_node *np)
printk(KERN_WARNING "Setting MDIO clock divisor to "
"default %d\n", DEFAULT_CLOCK_DIVISOR);
clk_div = DEFAULT_CLOCK_DIVISOR;
+ of_node_put(np1);
goto issue;
}
--
1.7.1
^ permalink raw reply related
* Re: [systemd-devel] [PATCH] netns: unix: only allow to find out unix socket in same net namespace
From: James Bottomley @ 2013-08-26 3:19 UTC (permalink / raw)
To: Gao feng
Cc: systemd-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
libvir-list-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux Containers,
Kay Sievers, Eric W. Biederman,
lxc-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org,
davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org
In-Reply-To: <521AAA23.9050604-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
On Mon, 2013-08-26 at 09:06 +0800, Gao feng wrote:
> On 08/26/2013 02:16 AM, James Bottomley wrote:
> > On Sun, 2013-08-25 at 19:37 +0200, Kay Sievers wrote:
> >> On Sun, Aug 25, 2013 at 7:16 PM, James Bottomley
> >> <jbottomley-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> wrote:
> >>> On Wed, 2013-08-21 at 11:51 +0200, Kay Sievers wrote:
> >>>> On Wed, Aug 21, 2013 at 9:22 AM, Gao feng <gaofeng-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org> wrote:
> >>>>> On 08/21/2013 03:06 PM, Eric W. Biederman wrote:
> >>>>
> >>>>>> I suspect libvirt should simply not share /run or any other normally
> >>>>>> writable directory with the host. Sharing /run /var/run or even /tmp
> >>>>>> seems extremely dubious if you want some kind of containment, and
> >>>>>> without strange things spilling through.
> >>>>
> >>>> Right, /run or /var cannot be shared. It's not only about sockets,
> >>>> many other things will also go really wrong that way.
> >>>
> >>> This is very narrow thinking about what a container might be and will
> >>> cause trouble as people start to create novel uses for containers in the
> >>> cloud if you try to impose this on our current infrastructure.
> >>>
> >>> One of the cgroup only container uses we see at Parallels (so no
> >>> separate filesystem and no net namespaces) is pure apache load balancer
> >>> type shared hosting. In this scenario, base apache is effectively
> >>> brought up in the host environment, but then spawned instances are
> >>> resource limited using cgroups according to what the customer has paid.
> >>> Obviously all apache instances are sharing /var and /run from the host
> >>> (mostly for logging and pid storage and static pages). The reason some
> >>> hosters do this is that it allows much higher density simple web serving
> >>> (either static pages from quota limited chroots or dynamic pages limited
> >>> by database space constraints) because each "instance" shares so much
> >>> from the host. The service is obviously much more basic than giving
> >>> each customer a container running apache, but it's much easier for the
> >>> hoster to administer and it serves the customer just as well for a large
> >>> cross section of use cases and for those it doesn't serve, the hoster
> >>> usually has separate container hosting (for a higher price, of course).
> >>
> >> The "container" as we talk about has it's own init, and no, it cannot
> >> share /var or /run.
> >
> > This is what we would call an IaaS container: bringing up init and
> > effectively a new OS inside a container is the closest containers come
> > to being like hypervisors. It's the most common use case of Parallels
> > containers in the field, so I'm certainly not telling you it's a bad
> > idea.
> >
> >> The stuff you talk about has nothing to do with that, it's not
> >> different from all services or a multi-instantiated service on the
> >> host sharing the same /run and /var.
> >
> > I gave you one example: a really simplistic one. A more sophisticated
> > example is a PaaS or SaaS container where you bring the OS up in the
> > host but spawn a particular application into its own container (this is
> > essentially similar to what Docker does). Often in this case, you do
> > add separate mount and network namespaces to make the application
> > isolated and migrateable with its own IP address. The reason you share
> > init and most of the OS from the host is for elasticity and density,
> > which are fast becoming a holy grail type quest of cloud orchestration
> > systems: if you don't have to bring up the OS from init and you can just
> > start the application from a C/R image (orders of magnitude smaller than
> > a full system image) and slap on the necessary namespaces as you clone
> > it, you have something that comes online in miliseconds which is a feat
> > no hypervisor based virtualisation can match.
> >
> > I'm not saying don't pursue the IaaS case, it's definitely useful ...
> > I'm just saying it would be a serious mistake to think that's the only
> > use case for containers and we certainly shouldn't adjust Linux to serve
> > only that use case.
> >
>
> The feature you said above VS contianer-reboot-host bug, I prefer to
> fix
> the bug.
What bug?
> and this feature can be achieved even container unshares /run
> directory
> with host by default, for libvirt, user can set the container
> configuration to
> make the container shares the /run directory with host.
>
> I would like to say, the reboot from container bug is more urgent and
> need
> to be fixed.
Are you talking about the old bug where trying to reboot an lxc
container from within it would reboot the entire system? If so, OpenVZ
has never suffered from that problem and I thought it was fixed
upstream. I've not tested lxc tools, but the latest vzctl from the
openvz website will bring up a container on the vanilla 3.9 kernel
(provided you have USER_NS compiled in) can also be used to reboot the
container, so I see no reason it wouldn't work for lxc as well.
James
^ permalink raw reply
* [PATCH] iproute2: ip-route.8.in: minor fixes
From: Richard Godbee @ 2013-08-26 2:40 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger
In SYNOPSIS section:
- Add 'reordering'
- Add missing '[' before 'quickack'
Signed-off-by: Richard Godbee <richard@godbee.net>
---
man/man8/ip-route.8.in | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/man/man8/ip-route.8.in b/man/man8/ip-route.8.in
index 7191bce..79bc7f1 100644
--- a/man/man8/ip-route.8.in
+++ b/man/man8/ip-route.8.in
@@ -97,6 +97,8 @@ replace " } "
.IR TIME " ] [ "
.B rttvar
.IR TIME " ] [ "
+.B reordering
+.IR NUMBER " ] [ "
.B window
.IR NUMBER " ] [ "
.B cwnd
@@ -110,7 +112,7 @@ replace " } "
.B initcwnd
.IR NUMBER " ] [ "
.B initrwnd
-.IR NUMBER " ]"
+.IR NUMBER " ] [ "
.B quickack
.IR BOOL " ]"
--
1.8.2.2
^ permalink raw reply related
* [PATCH] iproute2: spelling: noptmudisc -> nopmtudisc
From: Richard Godbee @ 2013-08-26 2:40 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger
Signed-off-by: Richard Godbee <richard@godbee.net>
---
ip/iptunnel.c | 2 +-
ip/link_iptnl.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/ip/iptunnel.c b/ip/iptunnel.c
index 43f8585..40186d3 100644
--- a/ip/iptunnel.c
+++ b/ip/iptunnel.c
@@ -280,7 +280,7 @@ static int do_add(int cmd, int argc, char **argv)
return -1;
if (p.iph.ttl && p.iph.frag_off == 0) {
- fprintf(stderr, "ttl != 0 and noptmudisc are incompatible\n");
+ fprintf(stderr, "ttl != 0 and nopmtudisc are incompatible\n");
return -1;
}
diff --git a/ip/link_iptnl.c b/ip/link_iptnl.c
index 394254d..d5324f8 100644
--- a/ip/link_iptnl.c
+++ b/ip/link_iptnl.c
@@ -233,7 +233,7 @@ get_failed:
}
if (ttl && pmtudisc == 0) {
- fprintf(stderr, "ttl != 0 and noptmudisc are incompatible\n");
+ fprintf(stderr, "ttl != 0 and nopmtudisc are incompatible\n");
exit(-1);
}
--
1.8.2.2
^ permalink raw reply related
* Re: Re: Re: [PATCH] USB2NET : SR9700 : One chip USB 1.1 USB2NETSR9700Device Driver Support
From: liujunliang_ljl @ 2013-08-26 2:28 UTC (permalink / raw)
To: Joe Perches
Cc: davem, horms, romieu, gregkh, netdev, linux-usb, linux-kernel,
sunhecheng
In-Reply-To: <1377483571.1782.25.camel@joe-AO722>
Dear all :
Thanks a lot.
2013-08-26
liujunliang_ljl
发件人： Joe Perches
发送时间： 2013-08-26 10:19:35
收件人： liujunliang_ljl
抄送： davem; horms; romieu; gregkh; netdev; linux-usb; linux-kernel; sunhecheng
主题： Re: Re: [PATCH] USB2NET : SR9700 : One chip USB 1.1 USB2NETSR9700Device Driver Support
On Mon, 2013-08-26 at 10:14 +0800, liujunliang_ljl wrote:
> do you need me to merge the patch and re-send it again.
I do not.
> And which version of kernel will release this driver.
No idea.
That's up to David Miller or Greg KH to pick
up the driver and maybe take the follow-on
patch I sent.
I just sent the patch because you seemed to
have a bit of difficulty integrating the
suggestions others were giving you.
> Thanks a lot and apologizing for making you trouble.
Oh, no worries. It was a trifle.
cheers, Joe
.
^ permalink raw reply
* [PATCH] iproute2: iproute.c: fix usage() spacing problems
From: Richard Godbee @ 2013-08-26 2:19 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger
Fix two spacing problems around square brackets in usage text.
Signed-off-by: Richard Godbee <richard@godbee.net>
---
ip/iproute.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/ip/iproute.c b/ip/iproute.c
index b069f1e..25a56d1 100644
--- a/ip/iproute.c
+++ b/ip/iproute.c
@@ -63,7 +63,7 @@ static void usage(void)
fprintf(stderr, " ip route restore\n");
fprintf(stderr, " ip route showdump\n");
fprintf(stderr, " ip route get ADDRESS [ from ADDRESS iif STRING ]\n");
- fprintf(stderr, " [ oif STRING ] [ tos TOS ]\n");
+ fprintf(stderr, " [ oif STRING ] [ tos TOS ]\n");
fprintf(stderr, " [ mark NUMBER ]\n");
fprintf(stderr, " ip route { add | del | change | append | replace } ROUTE\n");
fprintf(stderr, "SELECTOR := [ root PREFIX ] [ match PREFIX ] [ exact PREFIX ]\n");
@@ -76,7 +76,7 @@ static void usage(void)
fprintf(stderr, "INFO_SPEC := NH OPTIONS FLAGS [ nexthop NH ]...\n");
fprintf(stderr, "NH := [ via ADDRESS ] [ dev STRING ] [ weight NUMBER ] NHFLAGS\n");
fprintf(stderr, "OPTIONS := FLAGS [ mtu NUMBER ] [ advmss NUMBER ]\n");
- fprintf(stderr, " [ rtt TIME ] [ rttvar TIME ] [reordering NUMBER ]\n");
+ fprintf(stderr, " [ rtt TIME ] [ rttvar TIME ] [ reordering NUMBER ]\n");
fprintf(stderr, " [ window NUMBER] [ cwnd NUMBER ] [ initcwnd NUMBER ]\n");
fprintf(stderr, " [ ssthresh NUMBER ] [ realms REALM ] [ src ADDRESS ]\n");
fprintf(stderr, " [ rto_min TIME ] [ hoplimit NUMBER ] [ initrwnd NUMBER ]\n");
--
1.8.2.2
^ permalink raw reply related
* Re: [PATCH net-next] tcp: TSO packets automatic sizing
From: Eric Dumazet @ 2013-08-26 2:22 UTC (permalink / raw)
To: Yuchung Cheng
Cc: Neal Cardwell, David Miller, netdev, Van Jacobson, Tom Herbert
In-Reply-To: <1377477425.8828.101.camel@edumazet-glaptop>
On Sun, 2013-08-25 at 17:37 -0700, Eric Dumazet wrote:
> On Sun, 2013-08-25 at 15:01 -0700, Yuchung Cheng wrote:
>
> > Any idea to get rid of this undesirable extra RTT delay?
>
> Its probably a bug in the push code.
For exact write/send of a multiple of MSS, I think following patch
should fix the bug.
If we filled a packet, we must send it.
For the other problem, I think its related to Nagle.
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index ab64eea..dd326f4 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1187,7 +1187,8 @@ new_segment:
from += copy;
copied += copy;
- if ((seglen -= copy) == 0 && iovlen == 0)
+ seglen -= copy;
+ if (seglen == 0 && iovlen == 0 && skb->len < max)
goto out;
if (skb->len < max || (flags & MSG_OOB) || unlikely(tp->repair))
^ permalink raw reply related
* Re: Re: [PATCH] USB2NET : SR9700 : One chip USB 1.1 USB2NET SR9700Device Driver Support
From: Joe Perches @ 2013-08-26 2:19 UTC (permalink / raw)
To: liujunliang_ljl
Cc: davem, horms, romieu, gregkh, netdev, linux-usb, linux-kernel,
sunhecheng
In-Reply-To: <201308261014331251822@163.com>
On Mon, 2013-08-26 at 10:14 +0800, liujunliang_ljl wrote:
> do you need me to merge the patch and re-send it again.
I do not.
> And which version of kernel will release this driver.
No idea.
That's up to David Miller or Greg KH to pick
up the driver and maybe take the follow-on
patch I sent.
I just sent the patch because you seemed to
have a bit of difficulty integrating the
suggestions others were giving you.
> Thanks a lot and apologizing for making you trouble.
Oh, no worries. It was a trifle.
cheers, Joe
^ permalink raw reply
* Re: Re: [PATCH] USB2NET : SR9700 : One chip USB 1.1 USB2NET SR9700Device Driver Support
From: liujunliang_ljl @ 2013-08-26 2:14 UTC (permalink / raw)
To: Joe Perches
Cc: davem, horms, romieu, gregkh, netdev, linux-usb, linux-kernel,
sunhecheng
In-Reply-To: <1377368111.1757.2.camel@joe-AO722>
Dear Joe :
I'm sorry to ask you that, do you need me to merge the patch and re-send it again.
And which version of kernel will release this driver.
Thanks a lot and apologizing for making you trouble.
Thanks again.
2013-08-26
liujunliang_ljl
发件人： Joe Perches
发送时间： 2013-08-25 02:15:19
收件人： liujunliang_ljl
抄送： davem; horms; romieu; gregkh; netdev; linux-usb; linux-kernel; sunhecheng
主题： Re: [PATCH] USB2NET : SR9700 : One chip USB 1.1 USB2NET SR9700Device Driver Support
Some whitespace and neatening fixups.
Some conversions from 4 indent tabs to normal tabs
Signed-off-by: Joe Perches <joe@perches.com>
---
Just doing this instead of commenting about spacing
again.
drivers/net/usb/sr9700.c | 127 +++++++++++++++++++++++++----------------------
1 file changed, 67 insertions(+), 60 deletions(-)
diff --git a/drivers/net/usb/sr9700.c b/drivers/net/usb/sr9700.c
index 27c86ec..4262b9d 100644
--- a/drivers/net/usb/sr9700.c
+++ b/drivers/net/usb/sr9700.c
@@ -29,7 +29,7 @@ static int sr_read(struct usbnet *dev, u8 reg, u16 length, void *data)
int err;
err = usbnet_read_cmd(dev, SR_RD_REGS, SR_REQ_RD_REG,
- 0, reg, data, length);
+ 0, reg, data, length);
if ((err != length) && (err >= 0))
err = -EINVAL;
return err;
@@ -40,7 +40,7 @@ static int sr_write(struct usbnet *dev, u8 reg, u16 length, void *data)
int err;
err = usbnet_write_cmd(dev, SR_WR_REGS, SR_REQ_WR_REG,
- 0, reg, data, length);
+ 0, reg, data, length);
if ((err >= 0) && (err < length))
err = -EINVAL;
return err;
@@ -54,19 +54,19 @@ static int sr_read_reg(struct usbnet *dev, u8 reg, u8 *value)
static int sr_write_reg(struct usbnet *dev, u8 reg, u8 value)
{
return usbnet_write_cmd(dev, SR_WR_REGS, SR_REQ_WR_REG,
- value, reg, NULL, 0);
+ value, reg, NULL, 0);
}
static void sr_write_async(struct usbnet *dev, u8 reg, u16 length, void *data)
{
usbnet_write_cmd_async(dev, SR_WR_REGS, SR_REQ_WR_REG,
- 0, reg, data, length);
+ 0, reg, data, length);
}
static void sr_write_reg_async(struct usbnet *dev, u8 reg, u8 value)
{
usbnet_write_cmd_async(dev, SR_WR_REGS, SR_REQ_WR_REG,
- value, reg, NULL, 0);
+ value, reg, NULL, 0);
}
static int wait_phy_eeprom_ready(struct usbnet *dev, int phy)
@@ -89,7 +89,7 @@ static int wait_phy_eeprom_ready(struct usbnet *dev, int phy)
if (i >= SR_SHARE_TIMEOUT) {
netdev_err(dev->net, "%s write timed out!\n",
- phy ? "phy" : "eeprom");
+ phy ? "phy" : "eeprom");
ret = -EIO;
goto out;
}
@@ -98,7 +98,8 @@ out:
return ret;
}
-static int sr_share_read_word(struct usbnet *dev, int phy, u8 reg, __le16 *value)
+static int sr_share_read_word(struct usbnet *dev, int phy, u8 reg,
+ __le16 *value)
{
int ret;
@@ -115,14 +116,15 @@ static int sr_share_read_word(struct usbnet *dev, int phy, u8 reg, __le16 *value
ret = sr_read(dev, EPDR, 2, value);
netdev_dbg(dev->net, "read shared %d 0x%02x returned 0x%04x, %d\n",
- phy, reg, *value, ret);
+ phy, reg, *value, ret);
out:
mutex_unlock(&dev->phy_mutex);
return ret;
}
-static int sr_share_write_word(struct usbnet *dev, int phy, u8 reg, __le16 value)
+static int sr_share_write_word(struct usbnet *dev, int phy, u8 reg,
+ __le16 value)
{
int ret;
@@ -156,7 +158,8 @@ static int sr9700_get_eeprom_len(struct net_device *dev)
return SR_EEPROM_LEN;
}
-static int sr9700_get_eeprom(struct net_device *net, struct ethtool_eeprom *eeprom, u8 *data)
+static int sr9700_get_eeprom(struct net_device *net,
+ struct ethtool_eeprom *eeprom, u8 *data)
{
struct usbnet *dev = netdev_priv(net);
__le16 *ebuf = (__le16 *)data;
@@ -168,7 +171,8 @@ static int sr9700_get_eeprom(struct net_device *net, struct ethtool_eeprom *eepr
return -EINVAL;
for (i = 0; i < eeprom->len / 2; i++)
- ret = sr_read_eeprom_word(dev, eeprom->offset / 2 + i, &ebuf[i]);
+ ret = sr_read_eeprom_word(dev, eeprom->offset / 2 + i,
+ &ebuf[i]);
return ret;
}
@@ -199,12 +203,13 @@ static int sr_mdio_read(struct net_device *netdev, int phy_id, int loc)
res = le16_to_cpu(res) & ~BMSR_LSTATUS;
netdev_dbg(dev->net, "sr_mdio_read() phy_id=0x%02x, loc=0x%02x, returns=0x%04x\n",
- phy_id, loc, res);
+ phy_id, loc, res);
return res;
}
-static void sr_mdio_write(struct net_device *netdev, int phy_id, int loc, int val)
+static void sr_mdio_write(struct net_device *netdev, int phy_id, int loc,
+ int val)
{
struct usbnet *dev = netdev_priv(netdev);
__le16 res = cpu_to_le16(val);
@@ -215,7 +220,7 @@ static void sr_mdio_write(struct net_device *netdev, int phy_id, int loc, int va
}
netdev_dbg(dev->net, "sr_mdio_write() phy_id=0x%02x, loc=0x%02x, val=0x%04x\n",
- phy_id, loc, val);
+ phy_id, loc, val);
sr_share_write_word(dev, 1, loc, res);
}
@@ -242,15 +247,15 @@ static int sr9700_ioctl(struct net_device *net, struct ifreq *rq, int cmd)
}
static const struct ethtool_ops sr9700_ethtool_ops = {
- .get_drvinfo = usbnet_get_drvinfo,
- .get_link = sr9700_get_link,
- .get_msglevel = usbnet_get_msglevel,
- .set_msglevel = usbnet_set_msglevel,
- .get_eeprom_len = sr9700_get_eeprom_len,
- .get_eeprom = sr9700_get_eeprom,
- .get_settings = usbnet_get_settings,
- .set_settings = usbnet_set_settings,
- .nway_reset = usbnet_nway_reset,
+ .get_drvinfo = usbnet_get_drvinfo,
+ .get_link = sr9700_get_link,
+ .get_msglevel = usbnet_get_msglevel,
+ .set_msglevel = usbnet_set_msglevel,
+ .get_eeprom_len = sr9700_get_eeprom_len,
+ .get_eeprom = sr9700_get_eeprom,
+ .get_settings = usbnet_get_settings,
+ .set_settings = usbnet_set_settings,
+ .nway_reset = usbnet_nway_reset,
};
static void sr9700_set_multicast(struct net_device *net)
@@ -269,7 +274,7 @@ static void sr9700_set_multicast(struct net_device *net)
if (net->flags & IFF_PROMISC) {
rx_ctl |= RCR_PRMSC;
} else if (net->flags & IFF_ALLMULTI ||
- netdev_mc_count(net) > SR_MCAST_MAX) {
+ netdev_mc_count(net) > SR_MCAST_MAX) {
rx_ctl |= RCR_RUNT;
} else if (!netdev_mc_empty(net)) {
struct netdev_hw_addr *ha;
@@ -290,7 +295,7 @@ static int sr9700_set_mac_address(struct net_device *net, void *p)
if (!is_valid_ether_addr(addr->sa_data)) {
netdev_err(net, "not setting invalid mac address %pM\n",
- addr->sa_data);
+ addr->sa_data);
return -EINVAL;
}
@@ -301,15 +306,15 @@ static int sr9700_set_mac_address(struct net_device *net, void *p)
}
static const struct net_device_ops sr9700_netdev_ops = {
- .ndo_open = usbnet_open,
- .ndo_stop = usbnet_stop,
- .ndo_start_xmit = usbnet_start_xmit,
- .ndo_tx_timeout = usbnet_tx_timeout,
- .ndo_change_mtu = usbnet_change_mtu,
- .ndo_validate_addr = eth_validate_addr,
- .ndo_do_ioctl = sr9700_ioctl,
- .ndo_set_rx_mode = sr9700_set_multicast,
- .ndo_set_mac_address = sr9700_set_mac_address,
+ .ndo_open = usbnet_open,
+ .ndo_stop = usbnet_stop,
+ .ndo_start_xmit = usbnet_start_xmit,
+ .ndo_tx_timeout = usbnet_tx_timeout,
+ .ndo_change_mtu = usbnet_change_mtu,
+ .ndo_validate_addr = eth_validate_addr,
+ .ndo_do_ioctl = sr9700_ioctl,
+ .ndo_set_rx_mode = sr9700_set_multicast,
+ .ndo_set_mac_address = sr9700_set_mac_address,
};
static int sr9700_bind(struct usbnet *dev, struct usb_interface *intf)
@@ -360,7 +365,8 @@ static int sr9700_bind(struct usbnet *dev, struct usb_interface *intf)
sr_mdio_write(dev->net, dev->mii.phy_id, MII_BMCR, BMCR_RESET);
sr_mdio_write(dev->net, dev->mii.phy_id,
- MII_ADVERTISE, ADVERTISE_ALL | ADVERTISE_CSMA | ADVERTISE_PAUSE_CAP);
+ (MII_ADVERTISE, ADVERTISE_ALL |
+ ADVERTISE_CSMA | ADVERTISE_PAUSE_CAP));
mii_nway_restart(&dev->mii);
out:
@@ -373,11 +379,11 @@ static int sr9700_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
int len;
/* skb content (packets) format :
- * p0 p1 p2 ...... pm
- * / \
- * / \
- * / \
- * / \
+ * p0 p1 p2 ...... pm
+ * / \
+ * / \
+ * / \
+ * / \
* p0b0 p0b1 p0b2 p0b3 ...... p0b(n-4) p0b(n-3)...p0bn
*
* p0 : packet 0
@@ -431,7 +437,8 @@ static int sr9700_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
return 0;
}
-static struct sk_buff *sr9700_tx_fixup(struct usbnet *dev, struct sk_buff *skb, gfp_t flags)
+static struct sk_buff *sr9700_tx_fixup(struct usbnet *dev, struct sk_buff *skb,
+ gfp_t flags)
{
int len;
@@ -508,40 +515,40 @@ static int sr9700_link_reset(struct usbnet *dev)
mii_ethtool_gset(&dev->mii, &ecmd);
netdev_dbg(dev->net, "link_reset() speed: %d duplex: %d\n",
- ecmd.speed, ecmd.duplex);
+ ecmd.speed, ecmd.duplex);
return 0;
}
static const struct driver_info sr9700_driver_info = {
- .description = "CoreChip SR9700 USB Ethernet",
- .flags = FLAG_ETHER,
- .bind = sr9700_bind,
- .rx_fixup = sr9700_rx_fixup,
- .tx_fixup = sr9700_tx_fixup,
- .status = sr9700_status,
- .link_reset = sr9700_link_reset,
- .reset = sr9700_link_reset,
+ .description = "CoreChip SR9700 USB Ethernet",
+ .flags = FLAG_ETHER,
+ .bind = sr9700_bind,
+ .rx_fixup = sr9700_rx_fixup,
+ .tx_fixup = sr9700_tx_fixup,
+ .status = sr9700_status,
+ .link_reset = sr9700_link_reset,
+ .reset = sr9700_link_reset,
};
static const struct usb_device_id products[] = {
{
- USB_DEVICE(0x0fe6, 0x9700), /* SR9700 device */
- .driver_info = (unsigned long)&sr9700_driver_info,
- },
+ USB_DEVICE(0x0fe6, 0x9700), /* SR9700 device */
+ .driver_info = (unsigned long)&sr9700_driver_info,
+ },
{}, /* END */
};
MODULE_DEVICE_TABLE(usb, products);
static struct usb_driver sr9700_usb_driver = {
- .name = "sr9700",
- .id_table = products,
- .probe = usbnet_probe,
- .disconnect = usbnet_disconnect,
- .suspend = usbnet_suspend,
- .resume = usbnet_resume,
- .disable_hub_initiated_lpm = 1,
+ .name = "sr9700",
+ .id_table = products,
+ .probe = usbnet_probe,
+ .disconnect = usbnet_disconnect,
+ .suspend = usbnet_suspend,
+ .resume = usbnet_resume,
+ .disable_hub_initiated_lpm = 1,
};
module_usb_driver(sr9700_usb_driver);
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox