* Re: [PATCH 5/7] can: clear ctrlmode when close candev
From: Marc Kleine-Budde @ 2014-11-03 20:47 UTC (permalink / raw)
To: Dong Aisheng, linux-can
Cc: wg, varkabhadram, netdev, socketcan, linux-arm-kernel
In-Reply-To: <1414579527-31100-5-git-send-email-b29396@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1030 bytes --]
On 10/29/2014 11:45 AM, Dong Aisheng wrote:
> Currently priv->ctrlmode is not cleared when close_candev, so next time
> the driver will still use this value to set controller even user
> does not set any ctrl mode.
> e.g.
> Step 1. ip link set can0 up type can0 bitrate 1000000 loopback on
> Controller will be in loopback mode
> Step 2. ip link set can0 down
> Step 3. ip link set can0 up type can0 bitrate 1000000
> Controller will still be set to loopback mode in driver due to saved
> priv->ctrlmode.
>
> This patch clears priv->ctrlmode when the CAN interface is closed,
> and set it to correct mode according to next user setting.
>
> Signed-off-by: Dong Aisheng <b29396@freescale.com>
NACK, as discussed with Oliver.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 1/7] can: m_can: fix possible sleep in napi poll
From: Marc Kleine-Budde @ 2014-11-03 20:49 UTC (permalink / raw)
To: Oliver Hartkopp, Dong Aisheng, linux-can
Cc: wg, varkabhadram, netdev, linux-arm-kernel
In-Reply-To: <5457CB6B.3080002@hartkopp.net>
[-- Attachment #1: Type: text/plain, Size: 910 bytes --]
On 11/03/2014 07:37 PM, Oliver Hartkopp wrote:
> you can omit the 'stable' tag as this driver just emerged in 3.18 - which is
> currently in 3.18-rc3 state.
Thanks! fixed.
> If possible I would suggest to push all 7 patches via can/master as it is
> pretty bad to say "M_CAN was introduced in 3.18 but M_CAN with CAN FD is
> working since 3.19".
Sorry, probably not, as CAN FD is a new feature. However we may talk to
David, as the m_can driver was introduced in 3.18 anyways, so it's
unlikely to break anything with this patch.
> This will produce confusion as the M_CAN core has built-in CAN FD support.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 0/3] RDMA/cxgb4,cxgb4vf,cxgb4i,csiostor: Cleanup macros
From: David Miller @ 2014-11-03 20:51 UTC (permalink / raw)
To: hariprasad
Cc: netdev, linux-rdma, linux-scsi, roland, JBottomley, hch, swise,
leedom, anish, praveenm, nirranjan, kumaras
In-Reply-To: <1415017014-12701-1-git-send-email-hariprasad@chelsio.com>
From: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Mon, 3 Nov 2014 17:46:51 +0530
> This series moves the debugfs code to a new file debugfs.c, Cleans up macros so
> that they match the hardware generated one.
How does "hardware generate the macros"?
I don't understand what this means at all.
Whatever your better explanation is, you'll have include it in a respun
version of this patch series.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 5/5] stmmac: pci: remove FSF address
From: David Miller @ 2014-11-03 20:57 UTC (permalink / raw)
To: andriy.shevchenko
Cc: peppe.cavallaro, netdev, hock.leong.kweh, vbridgers2013, rayagond
In-Reply-To: <1415019737-32736-6-git-send-email-andriy.shevchenko@linux.intel.com>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Mon, 3 Nov 2014 15:02:17 +0200
> The FSF address is subject to change, thus remove it from the file.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
I cound 90t instances of this under drivers/net, therefore if this change is
appropriate I'd rather someone script this and kill it across entire
subdirectories.
Thanks.
^ permalink raw reply
* Re: [PATCH net] sfc: don't BUG_ON efx->max_channels == 0 in probe
From: David Miller @ 2014-11-03 20:58 UTC (permalink / raw)
To: ecree; +Cc: netdev, sshah, linux-net-drivers
In-Reply-To: <alpine.LFD.2.03.1411031409100.24185@solarflare.com>
From: Edward Cree <ecree@solarflare.com>
Date: Mon, 3 Nov 2014 14:14:35 +0000
> efx_ef10_probe() was BUGging out if the BAR2 size was 0. This is
> unnecessarily violent; instead we should just fail to probe the device.
> Kept a WARN_ON as this problem indicates a broken or misconfigured NIC.
>
> Signed-off-by: Edward Cree <ecree@solarflare.com>
Applied, thanks.
^ permalink raw reply
* Re: [net-next 00/11][pull request] Intel Wired LAN Driver Updates 2014-11-03
From: David Miller @ 2014-11-03 21:10 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <1415026599-16232-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 3 Nov 2014 06:56:28 -0800
> This series contains updates to i40e and i40evf.
...
> The following are changes since commit 55b42b5ca2dcf143465968697fe6c6503b05fca1:
> Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
Pulled, thanks a lot Jeff.
^ permalink raw reply
* Re: [PATCH 1/7] can: m_can: fix possible sleep in napi poll
From: Oliver Hartkopp @ 2014-11-03 21:12 UTC (permalink / raw)
To: Marc Kleine-Budde, Dong Aisheng, linux-can
Cc: wg, varkabhadram, netdev, linux-arm-kernel
In-Reply-To: <5457EA62.5040906@pengutronix.de>
On 11/03/2014 09:49 PM, Marc Kleine-Budde wrote:
> On 11/03/2014 07:37 PM, Oliver Hartkopp wrote:
>> If possible I would suggest to push all 7 patches via can/master as it is
>> pretty bad to say "M_CAN was introduced in 3.18 but M_CAN with CAN FD is
>> working since 3.19".
>
> Sorry, probably not, as CAN FD is a new feature. However we may talk to
> David, as the m_can driver was introduced in 3.18 anyways, so it's
> unlikely to break anything with this patch.
>
Yes. It's just to be 'feature complete' for the FD enabled M_CAN driver.
Hopefully it's ok for Dave ...
Thanks,
Oliver
^ permalink raw reply
* Re: [PATCH net-next] net: add rbnode to struct sk_buff
From: David Miller @ 2014-11-03 21:12 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, wygivan
In-Reply-To: <1415031593.14083.25.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 03 Nov 2014 08:19:53 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> Yaogong replaces TCP out of order receive queue by an RB tree.
>
> As netem already does a private skb->{next/prev/tstamp} union
> with a 'struct rb_node', lets do this in a cleaner way.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
This looks fine, and I'll apply it, thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/7] gue: Remote checksum offload
From: Jesse Gross @ 2014-11-03 21:26 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, netdev
In-Reply-To: <1414882683-25484-1-git-send-email-therbert@google.com>
On Sat, Nov 1, 2014 at 3:57 PM, Tom Herbert <therbert@google.com> wrote:
> This patch set implements remote checksum offload for
> GUE, which is a mechanism that provides checksum offload of
> encapsulated packets using rudimentary offload capabilities found in
> most Network Interface Card (NIC) devices. The outer header checksum
> for UDP is enabled in packets and, with some additional meta
> information in the GUE header, a receiver is able to deduce the
> checksum to be set for an inner encapsulated packet. Effectively this
> offloads the computation of the inner checksum. Enabling the outer
> checksum in encapsulation has the additional advantage that it covers
> more of the packet than the inner checksum including the encapsulation
> headers.
Tom, I have a pretty hard time squaring this with your previous
comments on hardware offload. This looks almost identical to a
protocol-specific hardware offload to me in terms of the implications
on the stack. It actually is more invasive and less likely to scale
across protocols, so the relative cost/benefit doesn't really add up
in my mind.
^ permalink raw reply
* Re: [PATCH net-next] net: add rbnode to struct sk_buff
From: Cong Wang @ 2014-11-03 21:34 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Yaogong Wang
In-Reply-To: <1415031593.14083.25.camel@edumazet-glaptop2.roam.corp.google.com>
On Mon, Nov 3, 2014 at 8:19 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> struct sk_buff {
> - /* These two members must be first. */
> - struct sk_buff *next;
> - struct sk_buff *prev;
> -
> union {
> - ktime_t tstamp;
> - struct skb_mstamp skb_mstamp;
> + struct {
> + /* These two members must be first. */
> + struct sk_buff *next;
> + struct sk_buff *prev;
> +
> + union {
> + ktime_t tstamp;
> + struct skb_mstamp skb_mstamp;
> + };
> + };
> + struct rb_node rbnode; /* used in netem & tcp stack */
> };
No objections, but this is hacky, rbnode is larger than ->next + ->prev,
this means ->tstamp is always overwritten. This is why netem saves it
to its CB. This isn't flexible.
Maybe both netem and TCP ooo queue should consider CB? Not sure
if TCP still has any space for more CB though.
^ permalink raw reply
* Re: [PATCH bluetooth-next] netdevice: add ieee802154_ptr to net_device
From: Marcel Holtmann @ 2014-11-03 21:35 UTC (permalink / raw)
To: David S. Miller
Cc: Alexander Aring, linux-wpan-u79uwXL29TY76Z2rM5mHXA,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20141103.122024.541066618529355652.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Hi Alex,
>> This patch adds an ieee802154_ptr to the net_device structure.
>> Furthermore the 802.15.4 subsystem will introduce a nl802154 framework
>> which is similar like the nl80211 framework and a wpan_dev structure.
>> The wpan_dev structure will hold additional net_device attributes like
>> address options which are 802.15.4 specific. In the upcoming nl802154
>> implementation we will introduce a NL802154_FLAG_NEED_WPAN_DEV like
>> NL80211_FLAG_NEED_WDEV. For this flag an ieee802154_ptr in net_device is
>> needed. Additional we can access the wpan_dev attributes in upper layers
>> like IEEE 802.15.4 6LoWPAN easily. Current solution is a complicated
>> callback interface and getting these values over subif data structure
>> in mac802154.
>>
>> Signed-off-by: Alexander Aring <alex.aring-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> No objections, and you can merge this via the bluetooth tree:
>
> Acked-by: David S. Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
patch has been applied to bluetooth-next tree.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: TCP NewReno and single retransmit
From: Marcelo Ricardo Leitner @ 2014-11-03 21:35 UTC (permalink / raw)
To: Neal Cardwell; +Cc: Yuchung Cheng, netdev, Eric Dumazet
In-Reply-To: <CADVnQykXpA_A87+bFOCdbb-QLTRf-5TEgspCzE-STO49N+6waw@mail.gmail.com>
On 03-11-2014 18:08, Neal Cardwell wrote:
> On Mon, Nov 3, 2014 at 11:38 AM, Marcelo Ricardo Leitner
> <mleitner@redhat.com> wrote:
>> On 31-10-2014 01:51, Yuchung Cheng wrote:
>>>>>> if (tp->snd_una == tp->high_seq && tcp_is_reno(tp)) {
>>>>>> /* Hold old state until something *above* high_seq
>>>>>> * is ACKed. For Reno it is MUST to prevent false
>>>>>> * fast retransmits (RFC2582). SACK TCP is safe. */
>>>
>>> Or we can just remove this strange state-holding logic?
>>>
>>> I couldn't find such a "MUST" statement in RFC2582. RFC2582 section 3
>>> step 5 suggests exiting the recovery procedure when an ACK acknowledges
>>> the "recover" variable (== tp->high_seq - 1).
>>>
>>> Since we've called tcp_reset_reno_sack() before tcp_try_undo_recovery(),
>>> I couldn't see how false fast retransmits can be triggered without
>>> this state-holding.
>>>
>>> Any insights?
>>
>>
>> Nice one, me neither. Neal?
>
> Since there are no literal IETF-style "MUST" statements in RFC2582, I
> think the "MUST" in the code here is expressing the design philosophy
> behind the author. :-)
>
> AFAICT the "Hold old state" code in tcp_try_undo_recovery() is a
> pretty reasonable implementation of a mechanism specified in NewReno
> RFCs to deal with the fundamental ambiguity between (1) dupacks for
> packets the receiver received above a hole above snd_una, and (2)
> dupacks for spurious retransmits below snd_una. I think the motivation
> behind the "Hold old state" code is to stay in Recovery so that we do
> not treat (2) dupacks as (1) dupacks.
>
> I find RFC 2582 not very clear on this point, and the newest NewReno
> RFC, RFC 6582, is also not so clear IMHO. But the RFC 3782 version of
> NewReno - https://tools.ietf.org/html/rfc3782 - has a reasonable
> discussion of this issue. There is a discussion in
> https://tools.ietf.org/html/rfc3782#section-11
> of this ambiguity:
>
> There are two separate scenarios in which the TCP sender could
> receive three duplicate acknowledgements acknowledging "recover" but
> no more than "recover". One scenario would be that the data sender
> transmitted four packets with sequence numbers higher than "recover",
> that the first packet was dropped in the network, and the following
> three packets triggered three duplicate acknowledgements
> acknowledging "recover". The second scenario would be that the
> sender unnecessarily retransmitted three packets below "recover", and
> that these three packets triggered three duplicate acknowledgements
> acknowledging "recover". In the absence of SACK, the TCP sender is
> unable to distinguish between these two scenarios.
>
> AFAICT RFC 3782 uses the term "recover" for the sequence number Linux
> calls tp->high_seq. The specification in RFC 3782 Sec 3 -
> https://tools.ietf.org/html/rfc3782#section-3 - of the criteria for
> entering Fast Recovery say that we shouldn't go into a new recovery if
> the cumulative ACK field doesn't cover more than high_seq/"recover":
>
> 1) Three duplicate ACKs:
> When the third duplicate ACK is received and the sender is not
> already in the Fast Recovery procedure, check to see if the
> Cumulative Acknowledgement field covers more than "recover". If
> so, go to Step 1A. Otherwise, go to Step 1B.
>
> 1A) Invoking Fast Retransmit:
> ...
> In addition, record the highest sequence number transmitted in
> the variable "recover", and go to Step 2.
>
> 1B) Not invoking Fast Retransmit:
> ...
>
> The last few slides of this presentation by Sally Floyd also talk
> about this point:
>
> http://www.icir.org/floyd/talks/newreno-Mar03.pdf
So by sticking with the recovery for a bit longer will help disambiguate the 3
dupacks on high_seq, if they ever happen, and with that avoid re-entering Fast
Retransmit if initial (2) happen. It's at the cost of leaving the fast
retransmit an ack later but if (2) happens the impact would be much worse, AFAICS.
Cool, thanks Neal. If Yuchung is okay with it, I'll proceed with just zeroing
that tstamp as initially proposed.
Marcelo
^ permalink raw reply
* Re: [PATCH net-next] net: add rbnode to struct sk_buff
From: David Miller @ 2014-11-03 21:37 UTC (permalink / raw)
To: cwang; +Cc: eric.dumazet, netdev, wygivan
In-Reply-To: <CAHA+R7M0--G=znvqQwy5Qmnm5po9yApcn4LjSSv8+-5c1D7RwQ@mail.gmail.com>
From: Cong Wang <cwang@twopensource.com>
Date: Mon, 3 Nov 2014 13:34:33 -0800
> No objections, but this is hacky, rbnode is larger than ->next + ->prev,
> this means ->tstamp is always overwritten. This is why netem saves it
> to its CB. This isn't flexible.
It's the size of next+prev+tstamp. Eric is showing exactly what is
shared with what with the struct/union layout.
^ permalink raw reply
* Re: [PATCH net-next] net: add rbnode to struct sk_buff
From: Cong Wang @ 2014-11-03 21:41 UTC (permalink / raw)
To: David Miller; +Cc: Eric Dumazet, netdev, Yaogong Wang
In-Reply-To: <20141103.163748.929657552226178600.davem@davemloft.net>
On Mon, Nov 3, 2014 at 1:37 PM, David Miller <davem@davemloft.net> wrote:
> From: Cong Wang <cwang@twopensource.com>
> Date: Mon, 3 Nov 2014 13:34:33 -0800
>
>> No objections, but this is hacky, rbnode is larger than ->next + ->prev,
>> this means ->tstamp is always overwritten. This is why netem saves it
>> to its CB. This isn't flexible.
>
> It's the size of next+prev+tstamp. Eric is showing exactly what is
> shared with what with the struct/union layout.
I knew, I meant saving tstamp is not flexible, or at least not pretty. :)
^ permalink raw reply
* Missed stable line commit (upstream 859828c0ea476b42f3a93d69d117aaba90994b6f)
From: Andrew Collins @ 2014-11-03 22:11 UTC (permalink / raw)
To: netdev@vger.kernel.org, stable, gregkh
I ran into an issue today on latest 3.10 stable line that looks to
have been resolved upstream and tagged for stable:
commit 859828c0ea476b42f3a93d69d117aaba90994b6f
Author: Jiri Pirko <jiri@resnulli.us>
Date: Thu Dec 5 16:27:37 2013 +0100
br: fix use of ->rx_handler_data in code executed on non-rx_handler path
...
Please apply to stable trees as well. Thanks.
The commit did make it into the 3.12 stable line, but seems to have
been missed in 3.10. The commit that causes the issue *did* make it
into 3.10.16 so 3.10 is exposed to the issue:
commit 960b8e5018a552f62cfbc0dfe94be7b6ba178f13
Author: Hong Zhiguo <zhiguohong@tencent.com>
Date: Sat Sep 14 22:42:28 2013 +0800
bridge: fix NULL pointer deref of br_port_get_rcu
[ Upstream commit 716ec052d2280d511e10e90ad54a86f5b5d4dcc2 ]
Any chance 859828c0ea476b42f3a93d69d117aaba90994b6f could be pulled
into the next 3.10 stable?
Thanks,
Andrew Collins
^ permalink raw reply
* Re: [PATCH net-next] net: add rbnode to struct sk_buff
From: Eric Dumazet @ 2014-11-03 22:36 UTC (permalink / raw)
To: Cong Wang; +Cc: David Miller, netdev, Yaogong Wang
In-Reply-To: <CAHA+R7P9PgkitLZAZrEoFfXT290rVr4oFibPyODPWhSVitA1WA@mail.gmail.com>
On Mon, 2014-11-03 at 13:41 -0800, Cong Wang wrote:
> On Mon, Nov 3, 2014 at 1:37 PM, David Miller <davem@davemloft.net> wrote:
> > From: Cong Wang <cwang@twopensource.com>
> > Date: Mon, 3 Nov 2014 13:34:33 -0800
> >
> >> No objections, but this is hacky, rbnode is larger than ->next + ->prev,
> >> this means ->tstamp is always overwritten. This is why netem saves it
> >> to its CB. This isn't flexible.
> >
> > It's the size of next+prev+tstamp. Eric is showing exactly what is
> > shared with what with the struct/union layout.
>
> I knew, I meant saving tstamp is not flexible, or at least not pretty. :)
Note that TCP stack doesn't care saving tstamp for packets in out of
order queue.
Even for netem, I am not sure it is needed at all.
^ permalink raw reply
* Re: [PATCH net-next 0/7] gue: Remote checksum offload
From: Tom Herbert @ 2014-11-03 22:39 UTC (permalink / raw)
To: Jesse Gross; +Cc: David Miller, netdev
In-Reply-To: <CAEP_g=88Q155PxTm9qbNVuxevqDneH3bed0nRfw1nKnZEKvMfQ@mail.gmail.com>
On Mon, Nov 3, 2014 at 1:26 PM, Jesse Gross <jesse@nicira.com> wrote:
> On Sat, Nov 1, 2014 at 3:57 PM, Tom Herbert <therbert@google.com> wrote:
>> This patch set implements remote checksum offload for
>> GUE, which is a mechanism that provides checksum offload of
>> encapsulated packets using rudimentary offload capabilities found in
>> most Network Interface Card (NIC) devices. The outer header checksum
>> for UDP is enabled in packets and, with some additional meta
>> information in the GUE header, a receiver is able to deduce the
>> checksum to be set for an inner encapsulated packet. Effectively this
>> offloads the computation of the inner checksum. Enabling the outer
>> checksum in encapsulation has the additional advantage that it covers
>> more of the packet than the inner checksum including the encapsulation
>> headers.
>
> Tom, I have a pretty hard time squaring this with your previous
> comments on hardware offload. This looks almost identical to a
> protocol-specific hardware offload to me in terms of the implications
> on the stack. It actually is more invasive and less likely to scale
> across protocols, so the relative cost/benefit doesn't really add up
> in my mind.
With this patch and checksum-unnecessary conversion we can provide
checksum offload for encapsulation on millions of already deployed
NICs without any HW or FW change. Why do you think this is not a good
cost/benefit tradeoff?
Thanks,
Tom
^ permalink raw reply
* Re: [PATCHv3 9/9] net: fec: fix regression on i.MX28 introduced by rx_copybreak support
From: Stefan Wahren @ 2014-11-03 22:58 UTC (permalink / raw)
To: netdev, "Lothar Waßmann"
Cc: linux-kernel, Frank Li, Russell King, Fabio Estevam,
David S. Miller, linux-arm-kernel
In-Reply-To: <1414502584-10583-10-git-send-email-LW@KARO-electronics.de>
Hi Lothar,
> Lothar Waßmann <LW@KARO-electronics.de> hat am 28. Oktober 2014 um 14:23
> geschrieben:
>
>
> commit 1b7bde6d659d ("net: fec: implement rx_copybreak to improve rx
> performance")
> introduced a regression for i.MX28. The swap_buffer() function doing
> the endian conversion of the received data on i.MX28 may access memory
> beyond the actual packet size in the DMA buffer. fec_enet_copybreak()
> does not copy those bytes, so that the last bytes of a packet may be
> filled with invalid data after swapping.
> This will likely lead to checksum errors on received packets.
> E.g. when trying to mount an NFS rootfs:
> UDP: bad checksum. From 192.168.1.225:111 to 192.168.100.73:44662 ulen 36
i think i experience the same problem with 3.18-rc2 on my mx28 board. I get
strange warnings about unexpected bytes from ping on my mx28 board and ping to
my mx28 board fails because of no response.
After applying the complete patch series these problems disappear. I'm looking
forward to see V4.
Thanks Stefan
^ permalink raw reply
* Re: [PATCH] ath6kl: remove incorrect reset_resume handler
From: Kalle Valo @ 2014-11-03 23:02 UTC (permalink / raw)
To: Alexey Khoroshilov
Cc: John W. Linville, linux-wireless, netdev, linux-kernel,
ldv-project
In-Reply-To: <1414180972-16413-1-git-send-email-khoroshilov@ispras.ru>
Alexey Khoroshilov <khoroshilov@ispras.ru> writes:
> Existing implementation of reset_resume handler just calls
> ath6kl_usb_remove() that deallocates all resources.
> It can lead to double free, etc. on disconnect.
>
> The patch removes reset_resume handler,
> so usb core could conservatively reset the driver.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Thanks, applied.
--
Kalle Valo
^ permalink raw reply
* Re: TCP NewReno and single retransmit
From: Neal Cardwell @ 2014-11-03 23:17 UTC (permalink / raw)
To: Marcelo Ricardo Leitner; +Cc: Yuchung Cheng, netdev, Eric Dumazet
In-Reply-To: <5457F52F.8060002@redhat.com>
On Mon, Nov 3, 2014 at 4:35 PM, Marcelo Ricardo Leitner
<mleitner@redhat.com> wrote:
> So by sticking with the recovery for a bit longer will help disambiguate the
> 3 dupacks on high_seq, if they ever happen, and with that avoid re-entering
> Fast Retransmit if initial (2) happen. It's at the cost of leaving the fast
> retransmit an ack later but if (2) happens the impact would be much worse,
> AFAICS.
Yes, that's my sense.
> Cool, thanks Neal. If Yuchung is okay with it, I'll proceed with just
> zeroing that tstamp as initially proposed.
Yes, that sounds good to me for a short-term fix for the "net" branch,
as long as it's:
+ if (!tcp_any_retrans_done(sk))
+ tp->retrans_stamp = 0;
Longer-term ("net-next"?) perhaps it makes sense to remove the hold
state and protect against this spurious FR situation at the time we
decide to enter Fast Recovery, which seems to be the model the RFC is
suggesting.
neal
^ permalink raw reply
* [PATCH] net: phy: spi_ks8995: remove sysfs bin file by registered attribute
From: Vladimir Zapolskiy @ 2014-11-03 23:25 UTC (permalink / raw)
To: netdev; +Cc: Florian Fainelli, David S. Miller
When a sysfs binary file is asked to be removed, it is found by
attribute name, so strictly speaking this change is not a fix, but
just in case when attribute name is changed in the driver or sysfs
internals are changed, it might be better to remove the previously
created file using right the same binary attribute.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: David S. Miller <davem@davemloft.net>
---
drivers/net/phy/spi_ks8995.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/spi_ks8995.c b/drivers/net/phy/spi_ks8995.c
index eab57fc..4653015 100644
--- a/drivers/net/phy/spi_ks8995.c
+++ b/drivers/net/phy/spi_ks8995.c
@@ -353,7 +353,9 @@ static int ks8995_probe(struct spi_device *spi)
static int ks8995_remove(struct spi_device *spi)
{
- sysfs_remove_bin_file(&spi->dev.kobj, &ks8995_registers_attr);
+ struct ks8995_switch *ks = spi_get_drvdata(spi);
+
+ sysfs_remove_bin_file(&spi->dev.kobj, &ks->regs_attr);
return 0;
}
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH v2] PPC: bpf_jit_comp: add SKF_AD_PKTTYPE instruction
From: Michael Ellerman @ 2014-11-03 23:43 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: David Miller, felix, Denis Kirjanov, netdev@vger.kernel.org,
linuxppc-dev, Matt Evans
In-Reply-To: <CAADnVQJYNB15cQvDi0+AcL==n+f8PAb1=Dnp_vBWku4SA-Q_6Q@mail.gmail.com>
On Mon, 2014-11-03 at 09:21 -0800, Alexei Starovoitov wrote:
> On Mon, Nov 3, 2014 at 9:06 AM, David Miller <davem@davemloft.net> wrote:
> > From: Denis Kirjanov <kda@linux-powerpc.org>
> > Date: Thu, 30 Oct 2014 09:12:15 +0300
> >
> >> Add BPF extension SKF_AD_PKTTYPE to ppc JIT to load
> >> skb->pkt_type field.
> >>
> >> Before:
> >> [ 88.262622] test_bpf: #11 LD_IND_NET 86 97 99 PASS
> >> [ 88.265740] test_bpf: #12 LD_PKTTYPE 109 107 PASS
> >>
> >> After:
> >> [ 80.605964] test_bpf: #11 LD_IND_NET 44 40 39 PASS
> >> [ 80.607370] test_bpf: #12 LD_PKTTYPE 9 9 PASS
> >>
> >> CC: Alexei Starovoitov<alexei.starovoitov@gmail.com>
> >> CC: Michael Ellerman<mpe@ellerman.id.au>
> >> Cc: Matt Evans <matt@ozlabs.org>
> >> Signed-off-by: Denis Kirjanov <kda@linux-powerpc.org>
> >>
> >> v2: Added test rusults
> >
> > So, can I apply this now?
>
> I think this question is more towards ppc folks,
> since both Daniel and myself said before that it looks ok.
Yeah sorry, as I said I don't really know enough about BPF to ack it.
> Philippe just tested the previous version of this patch on ppc64le...
> I'm guessing that Matt (original author of bpf jit for ppc) is not replying,
> because he has no objections.
Actually that might be because he works at ARM now :)
If you can CC Philippe on future BPF patches for powerpc that would probably
help.
cheers
^ permalink raw reply
* Re: [PATCH net-next 0/7] gue: Remote checksum offload
From: Jesse Gross @ 2014-11-04 0:19 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, netdev
In-Reply-To: <CA+mtBx-t2a80VhYypH8d0pjWh7FqT8GRGZt1F=o23GC3BZm-sA@mail.gmail.com>
On Mon, Nov 3, 2014 at 2:39 PM, Tom Herbert <therbert@google.com> wrote:
> On Mon, Nov 3, 2014 at 1:26 PM, Jesse Gross <jesse@nicira.com> wrote:
>> On Sat, Nov 1, 2014 at 3:57 PM, Tom Herbert <therbert@google.com> wrote:
>>> This patch set implements remote checksum offload for
>>> GUE, which is a mechanism that provides checksum offload of
>>> encapsulated packets using rudimentary offload capabilities found in
>>> most Network Interface Card (NIC) devices. The outer header checksum
>>> for UDP is enabled in packets and, with some additional meta
>>> information in the GUE header, a receiver is able to deduce the
>>> checksum to be set for an inner encapsulated packet. Effectively this
>>> offloads the computation of the inner checksum. Enabling the outer
>>> checksum in encapsulation has the additional advantage that it covers
>>> more of the packet than the inner checksum including the encapsulation
>>> headers.
>>
>> Tom, I have a pretty hard time squaring this with your previous
>> comments on hardware offload. This looks almost identical to a
>> protocol-specific hardware offload to me in terms of the implications
>> on the stack. It actually is more invasive and less likely to scale
>> across protocols, so the relative cost/benefit doesn't really add up
>> in my mind.
>
> With this patch and checksum-unnecessary conversion we can provide
> checksum offload for encapsulation on millions of already deployed
> NICs without any HW or FW change. Why do you think this is not a good
> cost/benefit tradeoff?
I just don't see how this is consistent with your previously stated
goal of keeping protocol-specific offload code out of the core stack.
Can you explain how this is different?
^ permalink raw reply
* Re: [PATCH net-next 0/7] gue: Remote checksum offload
From: Tom Herbert @ 2014-11-04 0:59 UTC (permalink / raw)
To: Jesse Gross; +Cc: David Miller, netdev
In-Reply-To: <CAEP_g=-rgL1D3kEQaCCmgArsVZQ0D=-JxDjoyZut3iykASYjNQ@mail.gmail.com>
On Mon, Nov 3, 2014 at 4:19 PM, Jesse Gross <jesse@nicira.com> wrote:
> On Mon, Nov 3, 2014 at 2:39 PM, Tom Herbert <therbert@google.com> wrote:
>> On Mon, Nov 3, 2014 at 1:26 PM, Jesse Gross <jesse@nicira.com> wrote:
>>> On Sat, Nov 1, 2014 at 3:57 PM, Tom Herbert <therbert@google.com> wrote:
>>>> This patch set implements remote checksum offload for
>>>> GUE, which is a mechanism that provides checksum offload of
>>>> encapsulated packets using rudimentary offload capabilities found in
>>>> most Network Interface Card (NIC) devices. The outer header checksum
>>>> for UDP is enabled in packets and, with some additional meta
>>>> information in the GUE header, a receiver is able to deduce the
>>>> checksum to be set for an inner encapsulated packet. Effectively this
>>>> offloads the computation of the inner checksum. Enabling the outer
>>>> checksum in encapsulation has the additional advantage that it covers
>>>> more of the packet than the inner checksum including the encapsulation
>>>> headers.
>>>
>>> Tom, I have a pretty hard time squaring this with your previous
>>> comments on hardware offload. This looks almost identical to a
>>> protocol-specific hardware offload to me in terms of the implications
>>> on the stack. It actually is more invasive and less likely to scale
>>> across protocols, so the relative cost/benefit doesn't really add up
>>> in my mind.
>>
>> With this patch and checksum-unnecessary conversion we can provide
>> checksum offload for encapsulation on millions of already deployed
>> NICs without any HW or FW change. Why do you think this is not a good
>> cost/benefit tradeoff?
>
> I just don't see how this is consistent with your previously stated
> goal of keeping protocol-specific offload code out of the core stack.
> Can you explain how this is different?
I think my request was more to avoid putting protocol-specific HW
offload code in the core stack when existing mechanisms could be used.
For instance, ntuple filtering is a more generic interface to tell a
device about special processing for a UDP port than adding an port
registration mechanism that needs to account for each possible
encapsulation protocol.
In these patches we do modify __skb_udp_tunnel_segment which I assume
is what you're referring to in touching the core stack. There are two
parts to this: 1) Allowing checksum offload of outer UDP header is
applicable to any UDP encapsulation protocol 2) When doing remote
checksum we need to avoid touching the inner checksum. The latter is
indicated by SKB_GSO_TUNNEL_REMCSUM being set by the encapsulation
layer. As I mention in the I-D, remote checksum offload can be
implemented by any encapsulation protocol that supports some
reasonable extension (for instance, this is probably something that
could be implemented in geneve). SKB_GSO_TUNNEL_REMCSUM is a generic
interface by that definition.
But, if you really have a strong objection, I suppose we can start
using at gso_segment in udp_offloads and put the remote checksum
offload processing for GSO in a GUE specific segment function.
Thanks,
Tom
^ permalink raw reply
* Re: [PATCH] ipv6: do xfrm transform after nat if necessary
From: Duan Jiong @ 2014-11-04 1:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20141103.144234.1037182010018495486.davem@davemloft.net>
On 11/04/2014 03:42 AM, David Miller wrote:
> From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
> Date: Mon, 3 Nov 2014 12:53:03 +0800
>
>>
>>
>> In function nf_nat_ipv6_out, after nat is done, nf_xfrm_me_harder()
>> will be called to look up xfrm dst.
>>
>> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>
> This is far from sufficient of a commit log message for a change that
> is as serious and has as many implications as this one.
>
> You haven't answered many questions, first of which in my mind is
> why we are bypassing all of the fragmentation checks?
>
> We're also bypassing ip6_finish_output2() which does multicast and
> hooks up the neighbour.
>
> IPV4 doesn't do this, why doesn't it have the same supposed problem
> you are trying to solve?
>
> It is not even clear to me what the problem is, because your commit
> message is way too terse.
>
Thank you for your advice, I would consider a more comprehensive
of the problem.
Thanks,
Duan
^ 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