* OFFIZIELLE GEWINNBENACHRITIGUNG
From: LOTTERIA LOTTERIA LOTTERIA @ 2017-05-16 22:33 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 698 bytes --]
INTERNATIONALE LOTTERIE-PROMOTION
ONLINE LOTTERIE-ABTEILUNG
Referenznummer: CCX-772-876-EM
Gewinnbenachrichtigung
Wir sind verpflichtet, Ihnen mitteilen zu können das Ergebnis der gerechten abgeschlossen monatliche endgültig zieht der Internationale Online Lotterie Promotion und Ihre e-Mail unter den 20 glücklichen Gewinnern gewonnen €2.100,000.00 Euros
für Sicherheit Grund, Lesen Sie die Anlage in PDF Formant für weitere Informationen bezüglich Ihres Gewinns
Bitte kontaktieren Sie Herr Josef Feldrich über Ihren Gewinn auf joseffeldrich@gmail.com
Mit freundlichen Grüßen
HEAD, ONLINE LOTTERY DEPARTMENT
INTERNATIONALE LOTTERY PROMOTIO
[-- Attachment #2: ACHTUNG GEWINNER.pdf --]
[-- Type: application/octet-stream, Size: 659986 bytes --]
^ permalink raw reply
* Re: [PATCH v2] neighbour: update neigh timestamps iff update is effective
From: Ihar Hrachyshka @ 2017-05-16 15:44 UTC (permalink / raw)
To: davem; +Cc: ja, netdev, Ihar Hrachyshka
In-Reply-To: <20170515.131023.1878814687849300375.davem@davemloft.net>
It's a common practice to send gratuitous ARPs after moving an
IP address to another device to speed up healing of a service. To
fulfill service availability constraints, the timing of network peers
updating their caches to point to a new location of an IP address can be
particularly important.
Sometimes neigh_update calls won't touch neither lladdr nor state, for
example if an update arrives in locktime interval. The neigh->updated
value is tested by the protocol specific neigh code, which in turn
will influence whether NEIGH_UPDATE_F_OVERRIDE gets set in the
call to neigh_update() or not. As a result, we may effectively ignore
the update request, bailing out of touching the neigh entry, except that
we still bump its timestamps inside neigh_update.
This may be a problem for updates arriving in quick succession. For
example, consider the following scenario:
A service is moved to another device with its IP address. The new device
sends three gratuitous ARP requests into the network with ~1 seconds
interval between them. Just before the first request arrives to one of
network peer nodes, its neigh entry for the IP address transitions from
STALE to DELAY. This transition, among other things, updates
neigh->updated. Once the kernel receives the first gratuitous ARP, it
ignores it because its arrival time is inside the locktime interval. The
kernel still bumps neigh->updated. Then the second gratuitous ARP
request arrives, and it's also ignored because it's still in the (new)
locktime interval. Same happens for the third request. The node
eventually heals itself (after delay_first_probe_time seconds since the
initial transition to DELAY state), but it just wasted some time and
require a new ARP request/reply round trip. This unfortunate behaviour
both puts more load on the network, as well as reduces service
availability.
This patch changes neigh_update so that it bumps neigh->updated (as well
as neigh->confirmed) only once we are sure that either lladdr or entry
state will change). In the scenario described above, it means that the
second gratuitous ARP request will actually update the entry lladdr.
Ideally, we would update the neigh entry on the very first gratuitous
ARP request. The locktime mechanism is designed to ignore ARP updates in
a short timeframe after a previous ARP update was honoured by the kernel
layer. This would require tracking timestamps for state transitions
separately from timestamps when actual updates are received. This would
probably involve changes in neighbour struct. Therefore, the patch
doesn't tackle the issue of the first gratuitous APR ignored, leaving
it for a follow-up.
Signed-off-by: Ihar Hrachyshka <ihrachys@redhat.com>
---
v2: added more details to commit message to explain relation between arp
and neigh code.
---
net/core/neighbour.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 58b0bcc..d274f81 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -1132,10 +1132,6 @@ int neigh_update(struct neighbour *neigh, const u8 *lladdr, u8 new,
lladdr = neigh->ha;
}
- if (new & NUD_CONNECTED)
- neigh->confirmed = jiffies;
- neigh->updated = jiffies;
-
/* If entry was valid and address is not changed,
do not change entry state, if new one is STALE.
*/
@@ -1157,6 +1153,16 @@ int neigh_update(struct neighbour *neigh, const u8 *lladdr, u8 new,
}
}
+ /* Update timestamps only once we know we will make a change to the
+ * neighbour entry. Otherwise we risk to move the locktime window with
+ * noop updates and ignore relevant ARP updates.
+ */
+ if (new != old || lladdr != neigh->ha) {
+ if (new & NUD_CONNECTED)
+ neigh->confirmed = jiffies;
+ neigh->updated = jiffies;
+ }
+
if (new != old) {
neigh_del_timer(neigh);
if (new & NUD_PROBE)
--
2.9.3
^ permalink raw reply related
* Re: [PATCH] neighbour: update neigh timestamps iff update is effective
From: Ihar Hrachyshka @ 2017-05-16 15:47 UTC (permalink / raw)
To: David S. Miller; +Cc: Julian Anastasov, netdev, Ihar Hrachyshka
In-Reply-To: <20170515214025.28575-1-ihrachys@redhat.com>
On Mon, May 15, 2017 at 2:40 PM, Ihar Hrachyshka <ihrachys@redhat.com> wrote:
> It's a common practice to send gratuitous ARPs after moving an
> IP address to another device to speed up healing of a service. To
> fulfill service availability constraints, the timing of network peers
> updating their caches to point to a new location of an IP address can be
> particularly important.
>
> Sometimes neigh_update calls won't touch neither lladdr nor state, for
> example if an update arrives in locktime interval. The neigh->updated
> value is tested by the protocol specific neigh code, which in turn
> will influence whether NEIGH_UPDATE_F_OVERRIDE gets set in the
> call to neigh_update() or not. As a result, we may effectively ignore
> the update request, bailing out of touching the neigh entry, except that
> we still bump its timestamps inside neigh_update.
>
>
> This may be a problem for updates arriving in quick succession. For
> example, consider the following scenario:
>
> A service is moved to another device with its IP address. The new device
> sends three gratuitous ARP requests into the network with ~1 seconds
> interval between them. Just before the first request arrives to one of
> network peer nodes, its neigh entry for the IP address transitions from
> STALE to DELAY. This transition, among other things, updates
> neigh->updated. Once the kernel receives the first gratuitous ARP, it
> ignores it because its arrival time is inside the locktime interval. The
> kernel still bumps neigh->updated. Then the second gratuitous ARP
> request arrives, and it's also ignored because it's still in the (new)
> locktime interval. Same happens for the third request. The node
> eventually heals itself (after delay_first_probe_time seconds since the
> initial transition to DELAY state), but it just wasted some time and
> require a new ARP request/reply round trip. This unfortunate behaviour
> both puts more load on the network, as well as reduces service
> availability.
>
> This patch changes neigh_update so that it bumps neigh->updated (as well
> as neigh->confirmed) only once we are sure that either lladdr or entry
> state will change). In the scenario described above, it means that the
> second gratuitous ARP request will actually update the entry lladdr.
>
> Ideally, we would update the neigh entry on the very first gratuitous
> ARP request. The locktime mechanism is designed to ignore ARP updates in
> a short timeframe after a previous ARP update was honoured by the kernel
> layer. This would require tracking timestamps for state transitions
> separately from timestamps when actual updates are received. This would
> probably involve changes in neighbour struct. Therefore, the patch
> doesn't tackle the issue of the first gratuitous APR ignored, leaving
> it for a follow-up.
>
> Signed-off-by: Ihar Hrachyshka <ihrachys@redhat.com>
Please disregard this email, I forgot to update the patch version to
v2 and provide changelog. I posted (hopefully) correct version. Still
learning the process...
Ihar
^ permalink raw reply
* [PATCH net-next] cxgb4: reduce resource allocation in kdump kernel
From: Ganesh Goudar @ 2017-05-16 15:47 UTC (permalink / raw)
To: netdev, davem; +Cc: nirranjan, indranil, Ganesh Goudar
When is_kdump_kernel() is true, reduce memory footprint of
cxgb4 by using a single "Queue Set".
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 38a5c67..4249ffb 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -891,7 +891,7 @@ static u16 cxgb_select_queue(struct net_device *dev, struct sk_buff *skb,
* The skb's priority is determined via the VLAN Tag Priority Code
* Point field.
*/
- if (cxgb4_dcb_enabled(dev)) {
+ if (cxgb4_dcb_enabled(dev) && !is_kdump_kernel()) {
u16 vlan_tci;
int err;
@@ -4007,10 +4007,7 @@ static void cfg_queues(struct adapter *adap)
/* Reduce memory usage in kdump environment, disable all offload.
*/
- if (is_kdump_kernel()) {
- adap->params.offload = 0;
- adap->params.crypto = 0;
- } else if (is_uld(adap) && t4_uld_mem_alloc(adap)) {
+ if (is_kdump_kernel() || (is_uld(adap) && t4_uld_mem_alloc(adap))) {
adap->params.offload = 0;
adap->params.crypto = 0;
}
@@ -4031,7 +4028,7 @@ static void cfg_queues(struct adapter *adap)
struct port_info *pi = adap2pinfo(adap, i);
pi->first_qset = qidx;
- pi->nqsets = 8;
+ pi->nqsets = is_kdump_kernel() ? 1 : 8;
qidx += pi->nqsets;
}
#else /* !CONFIG_CHELSIO_T4_DCB */
@@ -4044,6 +4041,9 @@ static void cfg_queues(struct adapter *adap)
if (q10g > netif_get_num_default_rss_queues())
q10g = netif_get_num_default_rss_queues();
+ if (is_kdump_kernel())
+ q10g = 1;
+
for_each_port(adap, i) {
struct port_info *pi = adap2pinfo(adap, i);
--
2.1.0
^ permalink raw reply related
* Re: [PATCH v2 net-next 00/12] drivers: net: xgene: Add ethtool stats and bug fixes
From: David Miller @ 2017-05-16 15:48 UTC (permalink / raw)
To: isubramanian; +Cc: netdev, linux-arm-kernel, patches, qnguyen
In-Reply-To: <1494449110-23785-1-git-send-email-isubramanian@apm.com>
From: Iyappan Subramanian <isubramanian@apm.com>
Date: Wed, 10 May 2017 13:44:58 -0700
> This patch set,
>
> - adds ethtool extended statistics support
> - addresses errata workarounds
> - fixes bugs related to statistics
>
> Signed-off-by: Iyappan Subramanian <isubramanian@apm.com>
> Signed-off-by: Quan Nguyen <qnguyen@apm.com>
Series applied.
Please address Florian's feedback on patch #3.
^ permalink raw reply
* Re: [ISSUE: sky2 - rx error] Link stops working under heavy traffic load connected to a mv88e6176
From: Rafa Corvillo @ 2017-05-16 15:50 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Stephen Hemminger, netdev
In-Reply-To: <20170516132116.GE5456@lunn.ch>
> On Tue, May 16, 2017 at 03:09:17PM +0200, Rafa Corvillo wrote:
>>>> Adding 8 bytes (sky2->netdev->mtu + ETH_HLEN + VLAN_HLEN + 8
>>>> (EDSA_HLEN)) does not fix the error, because the interface keep
>>>> having a maximum length of 1518 bytes (sky2->netdev->mtu + ETH_HLEN
>>>> + VLAN_HLEN).
>>>
>>> Did you check the value being written to here:
>>>
>>> /*
>>> * The receiver hangs if it receives frames larger than the
>>> * packet buffer. As a workaround, truncate oversize frames, but
>>> * the register is limited to 9 bits, so if you do frames > 2052
>>> * you better get the MTU right!
>>> */
>>> thresh = sky2_get_rx_threshold(sky2);
>>> if (thresh > 0x1ff)
>>> sky2_write32(hw, SK_REG(sky2->port, RX_GMF_CTRL_T), RX_TRUNC_OFF);
>>> else {
>>> sky2_write16(hw, SK_REG(sky2->port, RX_GMF_TR_THR), thresh);
>>> sky2_write32(hw, SK_REG(sky2->port, RX_GMF_CTRL_T), RX_TRUNC_ON);
>>> }
>>>
>>>
>>> What is thresh?
>>
>> The value of thresh is 380.
>
> So that is 1528.
Yes, this is the result of the roundup function.
>
> You could hack it and try 0x1ff.
I have forced the value of thresh to 0x1ff and the rx error still appears.
>
> Also, check that in sky2_rx_add(), le->length is set to 4K.
>
The value of le->length is set to 1520.
Rafa
^ permalink raw reply
* Re: [PATCH v2 net-next] bnxt: add dma mapping attributes
From: David Miller @ 2017-05-16 15:53 UTC (permalink / raw)
To: shannon.nelson; +Cc: netdev, sparclinux, michael.chan
In-Reply-To: <1494379812-282087-1-git-send-email-shannon.nelson@oracle.com>
From: Shannon Nelson <shannon.nelson@oracle.com>
Date: Tue, 9 May 2017 18:30:12 -0700
> On the SPARC platform we need to use the DMA_ATTR_WEAK_ORDERING attribute
> in our Rx path dma mapping in order to get the expected performance out
> of the receive path. Adding it to the Tx path has little effect, so
> that's not a part of this patch.
>
> Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com>
> Reviewed-by: Tushar Dave <tushar.n.dave@oracle.com>
> Reviewed-by: Tom Saeger <tom.saeger@oracle.com>
> ---
> v2: simplify by getting rid of the driver-specific ifdef and define
Applied.
^ permalink raw reply
* Re: [PATCH net-next,v2] tools: hv: Add clean up for included files in Ubuntu net config
From: David Miller @ 2017-05-16 15:53 UTC (permalink / raw)
To: haiyangz, haiyangz; +Cc: netdev, kys, olaf, vkuznets, linux-kernel
In-Reply-To: <1494616451-30130-1-git-send-email-haiyangz@exchange.microsoft.com>
From: Haiyang Zhang <haiyangz@exchange.microsoft.com>
Date: Fri, 12 May 2017 12:14:11 -0700
> From: Haiyang Zhang <haiyangz@microsoft.com>
>
> The clean up function is updated to cover duplicate config info in
> files included by "source" key word in Ubuntu network config.
>
> Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: socket: mark socket protocol handler structs as const
From: David Miller @ 2017-05-16 15:55 UTC (permalink / raw)
To: xiaolou4617-Re5JQEeQqe8AvxtiuMwx3w
Cc: marcel-kz+m5ild9QBg9hUCZPvPmw, gustavo-THi1TnShQwVAfugRpC6u6w,
johan.hedberg-Re5JQEeQqe8AvxtiuMwx3w,
dmitry.tarnyagin-0TCahj4L2NoXWF+eFR7m5Q,
sameo-VuQAYsv1563Yd54FQh9/CA, nhorman-2XuSBdqkA4R54TAoqtyWWQ,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1494815207-9378-1-git-send-email-xiaolou4617-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: linzhang <xiaolou4617-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Mon, 15 May 2017 10:26:47 +0800
> Signed-off-by: linzhang <xiaolou4617-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Applied.
^ permalink raw reply
* [PATCH net-next] cxgb4: keep carrier off after registering netdev
From: Ganesh Goudar @ 2017-05-16 15:56 UTC (permalink / raw)
To: netdev, davem; +Cc: nirranjan, indranil, Surendra Mobiya, Ganesh Goudar
From: Surendra Mobiya <surendra@chelsio.com>
Mark carrier off after registering netdev to ensure that vlan device
picks up the correct state of the carrier
Signed-off-by: Surendra Mobiya <surendra@chelsio.com>
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
index 4249ffb..316ba8b 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
@@ -4954,6 +4954,7 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
break;
adapter->chan_map[pi->tx_chan] = i;
print_port_info(adapter->port[i]);
+ netif_carrier_off(adapter->port[i]);
}
if (i == 0) {
dev_err(&pdev->dev, "could not register any net devices\n");
--
2.1.0
^ permalink raw reply related
* Re: [PATCH] net/smc: mark as BROKEN due to remote memory exposure
From: Doug Ledford @ 2017-05-16 15:57 UTC (permalink / raw)
To: David Miller, Bart.VanAssche-XdAiOPVOjttBDgjK7y7TUQ,
Torvalds, Linus
Cc: hch-jcswGhMUV9g, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, stable-u79uwXL29TY76Z2rM5mHXA,
ubraun-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8
In-Reply-To: <20170514.204404.1844909849561204299.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Hi Linus,
I've added you to this thread. A quick synopsis: Dave sent you the
net/smc driver for 4.11. Even though it lives in net/smc, it is, for
the most part, a net<->rdma translator and so it is as much an RDMA
driver as anything else. And upon review, the rdma community does not
believe either the spec/rfc or the driver are the right way to engineer
this particular technology, and the implementation leaves much to be
desired.
On Sun, 2017-05-14 at 20:44 -0400, David Miller wrote:
> From: Bart Van Assche <Bart.VanAssche-XdAiOPVOjttBDgjK7y7TUQ@public.gmane.org>
> Date: Sun, 14 May 2017 19:08:50 +0000
>
> > What is your plan to avoid that applications start using and
> > depending on AF_SMC?
>
> The API is out there already so we are out of luck, and neither
> you nor I nor anyone else can "stop" this from happening.
That's not true at all. There's nothing that says we can't revert this
now before it goes any further. It's only been in two kernels, I'm
positive it hasn't landed in any distros yet, and it can go back to
being something people can add on the side. Futher, the "standard"
this is based on is not a real standard, it's just a publication and
has not been through a standard track. I wouldn't consider this "out
there already" until there is a standard that has gone through the
standard track.
Regardless though, I'm rather purturbed about this entire thing. If
you are right that because this got into 4.11, it's now a done deal,
then the fact that this went through 4 review cycles on netdev@ that,
as I understand it, spanned roughly one years time, and not one single
person bothered to note that this was as much an RDMA driver as
anything else, and not one person bothered to note that linux-rdma@ was
not on the Cc: list, and not one person told the submitters that they
needed to include linux-rdma@ on the Cc: list of these submissions, and
you took it without any review comments from any RDMA people in the
course of a year, or an ack from me to show that the RDMA portion of
this had at least been given some sort of review, was a collosal fuckup
of cross tree maintainer cooperation.
The SMC driver makes several mistakes that people tried to avoid with
previous RDMA standards, it only supports one out of the five possible
link layers (iWARP, IB, OPA, RoCEv1, RoCEv2), it uses a highly
discouraged and deprecated technique for memory registration that is
considered horribly insecure (handing the keys to the castle to anyone
who connects to the machine, aka, the entire memory space is registered
with one key and that key is given to remote connections, so they can
read any bit of kernel memory they want as opposed to whatever we tell
them to read), and the design as articuled in the published rfc seems
incomplete for dealing with any of the other link layers, indicating
that this should have probably stayed out until the rfc was discussed
and updated to address the shortcomings obviously present in the
current rfc. With all of these issues outstanding against it, I hope
you can see why I think the way I do about you taking it without ever
consulting any of the RDMA community.
But that leaves us with the question of what to do moving forward.
Probably the number one concern is that this protocol chose to create
a new AF as opposed to reusing the IPv4 and IPv6 address families and
adding an option similar to SCTP for enabling the new protocol on a
specific socket. The concern is that we have means of addressing all
of the link layers the RDMA subsystem supports using IPv4 or IPv6 (sort
of...it's possible to have IB or OPA without IPoIB, which leaves them
without an IPv4 or IPv6 address, in which case the rdmacm can use
native GUIDs to resolve the other side, but that only works for verbs
connections, in the case of TCP connections, we always require IPoIB to
be present, and so IPv4 or IPv6 is always sufficient). In the end,
switching this protocol to use AF_INET and AF_INET6 and a protocol
option to enable SMC may be what we need to do. That, of course,
changes the user space API. So, are we truly locked in at this point?
I would suggest that, since this is only present in 4.11 and 4.12, and
I'm sure this has not landed in any distros as of yet (except maybe
something like Fedora rawhide), we can submit a patch to both the
current kernel and the 4.11 stable to set this code as
CONFIG_EXPERIMENTAL and mark the API as possibly going to undergo
change. Then let the RDMA community work with IBM to get this properly
fixed so that this is a reasonable RDMA driver and not something the
community is ready to immediately trash, and only after we've got it
whipped into shape and the RDMA community is satisfied it is a
reasonable driver that can continue to work with future planned RDMA
subsystem updates and across various link layers, we remove the
EXPERIMENTAL marker and freeze the API for user space.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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: [ISSUE: sky2 - rx error] Link stops working under heavy traffic load connected to a mv88e6176
From: Andrew Lunn @ 2017-05-16 15:58 UTC (permalink / raw)
To: Rafa Corvillo; +Cc: Stephen Hemminger, netdev
In-Reply-To: <591B1FC2.1090402@aoifes.com>
> >Also, check that in sky2_rx_add(), le->length is set to 4K.
> >
>
> The value of le->length is set to 1520.
> Rafa
Ah.
You probably need to change sky2_get_rx_data_size() as well, to add in
the extra 8 bytes.
Andrew
^ permalink raw reply
* [PATCH net-next] cxgb4: add new T5 pci device id
From: Ganesh Goudar @ 2017-05-16 16:09 UTC (permalink / raw)
To: netdev, davem; +Cc: nirranjan, indranil, Ganesh Goudar
Signed-off-by: Ganesh Goudar <ganeshgr@chelsio.com>
---
drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h b/drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h
index a323185..9232bec 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h
+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_pci_id_tbl.h
@@ -172,6 +172,7 @@ CH_PCI_DEVICE_ID_TABLE_DEFINE_BEGIN
CH_PCI_ID_TABLE_FENTRY(0x509e), /* Custom T520-CR */
CH_PCI_ID_TABLE_FENTRY(0x509f), /* Custom T540-CR */
CH_PCI_ID_TABLE_FENTRY(0x50a0), /* Custom T540-CR */
+ CH_PCI_ID_TABLE_FENTRY(0x50a1), /* Custom T540-CR */
/* T6 adapters:
*/
--
2.1.0
^ permalink raw reply related
* Re: [PATCH] net: ethernet: broadcom: bnxt: remove dead code
From: Gustavo A. R. Silva @ 2017-05-16 16:18 UTC (permalink / raw)
To: Michael Chan; +Cc: Netdev, open list
In-Reply-To: <CACKFLimtPW-uxEUK2GaL-ZPLhLOx19Qqzr8d-pVcV3bOEXqYTA@mail.gmail.com>
Hi Michael,
Quoting Michael Chan <michael.chan@broadcom.com>:
> On Mon, May 15, 2017 at 3:28 PM, Gustavo A. R. Silva
> <garsilva@embeddedor.com> wrote:
>> Local variable _sh_ is assigned to a constant value and it is never updated
>> again. Remove this variable and the dead code it guards.
>>
>> Addresses-Coverity-ID: 1350916
>> Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com>
>> ---
>> drivers/net/ethernet/broadcom/bnxt/bnxt.c | 9 +++------
>> 1 file changed, 3 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
>> b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
>> index 1f1e54b..018674b 100644
>> --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c
>> +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c
>> @@ -7380,12 +7380,10 @@ static int bnxt_get_dflt_rings(struct bnxt
>> *bp, int *max_rx, int *max_tx,
>> static int bnxt_set_dflt_rings(struct bnxt *bp)
>> {
>> int dflt_rings, max_rx_rings, max_tx_rings, rc;
>> - bool sh = true;
>
> The point of this logic is that we can easily change the default to
> shared rings or separate rings. I think what I'll do is change it so
> that the parameter sh is passed in and let the caller decide. Thanks
> for pointing this out.
>
Sure thing, glad to help.
--
Gustavo A. R. Silva
^ permalink raw reply
* Re: [ISSUE: sky2 - rx error] Link stops working under heavy traffic load connected to a mv88e6176
From: Rafa Corvillo @ 2017-05-16 16:19 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Stephen Hemminger, netdev
In-Reply-To: <20170516155843.GE32357@lunn.ch>
>>> Also, check that in sky2_rx_add(), le->length is set to 4K.
>>>
>>
>> The value of le->length is set to 1520.
>
>> Rafa
>
> Ah.
>
> You probably need to change sky2_get_rx_data_size() as well, to add in
> the extra 8 bytes.
>
> Andrew
>
If I add the extra 8 byte in the function sky2_get_rx_data_size(), the
value of le->length is set to 1528. But the rx error still appears.
Because of that, I think it is possible the maximum length could be set
outside the sky2 code.
Rafa
^ permalink raw reply
* Re: [patch net-next v2 00/10] net: sched: introduce multichain support for filters
From: David Miller @ 2017-05-16 16:20 UTC (permalink / raw)
To: jiri
Cc: netdev, jhs, xiyou.wangcong, dsa, edumazet, stephen, daniel,
alexander.h.duyck, simon.horman, mlxsw
In-Reply-To: <20170515083857.3615-1-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Mon, 15 May 2017 10:38:47 +0200
> This patchset contains two major patches:
> 8/10 - This patch introduces the support for having multiple
> chains of filters.
> 10/10 - This patch adds new control action to allow going to specified chain
>
> The rest of the patches are smaller or bigger depencies of those 2.
> Please see individual patch descriptions for details.
I'm expecting at least some adjustments to the tests in the final
patch based upon your discussions with Daniel, and thus another
spin of this series.
^ permalink raw reply
* Re: [PATCH v3] bridge: netlink: check vlan_default_pvid range
From: Nikolay Aleksandrov @ 2017-05-16 16:23 UTC (permalink / raw)
To: Tobias Jungel, Sabrina Dubroca, Stephen Hemminger,
David S. Miller, netdev
In-Reply-To: <20170516084840.21432-1-tobias.jungel@bisdn.de>
On 5/16/17 11:48 AM, Tobias Jungel wrote:
> Currently it is allowed to set the default pvid of a bridge to a value
> above VLAN_VID_MASK (0xfff). This patch adds a check to br_validate and
> returns -EINVAL in case the pvid is out of bounds.
>
> Reproduce by calling:
>
> [root@test ~]# ip l a type bridge
> [root@test ~]# ip l a type dummy
> [root@test ~]# ip l s bridge0 type bridge vlan_filtering 1
> [root@test ~]# ip l s bridge0 type bridge vlan_default_pvid 9999
> [root@test ~]# ip l s dummy0 master bridge0
> [root@test ~]# bridge vlan
> port vlan ids
> bridge0 9999 PVID Egress Untagged
>
> dummy0 9999 PVID Egress Untagged
>
> Fixes: 0f963b7592ef ("bridge: netlink: add support for default_pvid")
> Signed-off-by: Tobias Jungel <tobias.jungel@bisdn.de>
> ---
> net/bridge/br_netlink.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
> index c5ce774..47cb95b 100644
> --- a/net/bridge/br_netlink.c
> +++ b/net/bridge/br_netlink.c
> @@ -835,6 +835,12 @@ static int br_validate(struct nlattr *tb[], struct nlattr *data[])
> return -EPROTONOSUPPORT;
> }
> }
> +
> + if (data[IFLA_BR_VLAN_DEFAULT_PVID]) {
> + __u16 defpvid = nla_get_u16(data[IFLA_BR_VLAN_DEFAULT_PVID]);
Please leave a blank line between the variable definition and the rest.
> + if (defpvid >= VLAN_VID_MASK)
> + return -EINVAL;
> + }
> #endif
>
> return 0;
>
This version looks good to me, with the above stylistic issue fixed feel
free to add my:
Acked-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Thanks!
^ permalink raw reply
* Re: [patch net-next v2 00/10] net: sched: introduce multichain support for filters
From: Jiri Pirko @ 2017-05-16 16:23 UTC (permalink / raw)
To: David Miller
Cc: netdev, jhs, xiyou.wangcong, dsa, edumazet, stephen, daniel,
alexander.h.duyck, simon.horman, mlxsw
In-Reply-To: <20170516.122021.1415036093574332123.davem@davemloft.net>
Tue, May 16, 2017 at 06:20:21PM CEST, davem@davemloft.net wrote:
>From: Jiri Pirko <jiri@resnulli.us>
>Date: Mon, 15 May 2017 10:38:47 +0200
>
>> This patchset contains two major patches:
>> 8/10 - This patch introduces the support for having multiple
>> chains of filters.
>> 10/10 - This patch adds new control action to allow going to specified chain
>>
>> The rest of the patches are smaller or bigger depencies of those 2.
>> Please see individual patch descriptions for details.
>
>I'm expecting at least some adjustments to the tests in the final
>patch based upon your discussions with Daniel, and thus another
>spin of this series.
Will send in a jiff. Thanks
^ permalink raw reply
* Re: linux-next: Tree for May 16 (net/core)
From: Randy Dunlap @ 2017-05-16 16:28 UTC (permalink / raw)
To: Stephen Rothwell, Linux-Next Mailing List
Cc: Linux Kernel Mailing List, netdev@vger.kernel.org
In-Reply-To: <20170516112125.517607f8@canb.auug.org.au>
On 05/15/17 18:21, Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20170515:
>
on i386 or x86_64:
when CONFIG_INET is not enabled:
../net/core/sock.c: In function 'skb_orphan_partial':
../net/core/sock.c:1810:2: error: implicit declaration of function 'skb_is_tcp_pure_ack' [-Werror=implicit-function-declaration]
if (skb_is_tcp_pure_ack(skb))
^
--
~Randy
^ permalink raw reply
* Re: [PATCH] net/smc: mark as BROKEN due to remote memory exposure
From: David Miller @ 2017-05-16 16:29 UTC (permalink / raw)
To: dledford
Cc: Bart.VanAssche, torvalds, hch, netdev, linux-rdma, stable, ubraun
In-Reply-To: <1494950224.3259.98.camel@redhat.com>
From: Doug Ledford <dledford@redhat.com>
Date: Tue, 16 May 2017 11:57:04 -0400
> Regardless though, I'm rather purturbed about this entire thing. If
> you are right that because this got into 4.11, it's now a done deal,
> then the fact that this went through 4 review cycles on netdev@ that,
> as I understand it, spanned roughly one years time, and not one single
> person bothered to note that this was as much an RDMA driver as
> anything else, and not one person bothered to note that linux-rdma@ was
> not on the Cc: list, and not one person told the submitters that they
> needed to include linux-rdma@ on the Cc: list of these submissions, and
> you took it without any review comments from any RDMA people in the
> course of a year, or an ack from me to show that the RDMA portion of
> this had at least been given some sort of review, was a collosal fuckup
> of cross tree maintainer cooperation.
We rely on people from various areas of expertiece to contribute to
patch review on netdev and give appropriate feedback.
If you actually look through the history, I made many semantic reviews
of the SMC changes, and kept pushing back.
And in fact I did this several times, making them go through several
revisions, in the hopes that someone would review more of the meat and
substance of the patch set.
Nobody do this for over a year.
I can't push back on people with silly coding style and small semantic
issues forever. And I think I made a serious effort to keep the
patches getting posted over and over again to make sure they got more
exposure.
I think it's unsettling that there are no RDMA experts, or at least
people remotely knowledgable about this "networking" technology,
subscribed to netdev and taking a cursory look at pactches that might
be relevant and effect that technology either directly or indirectly.
So there is a lot of blame to go around.
^ permalink raw reply
* [PATCH net-next v2 0/7] fix CRC32c in the forwarding path
From: Davide Caratti @ 2017-05-16 16:27 UTC (permalink / raw)
To: linux-sctp, netdev
Cc: Alexander Duyck, Tom Herbert, David Laight, David S. Miller,
Marcelo Ricardo Leitner
Current kernel allows offloading CRC32c computation when SCTP packets
are generated, setting skb->ip_summed to CHECKSUM_PARTIAL, if the
underlying device features have NETIF_F_SCTP_CRC set. However, after these
packets are forwarded, they may land on a device where CRC32c offloading is
not available: as a consequence, transmission is done with wrong CRC32c.
It's not possible to use sctp_compte_cksum() in the forwarding path
and in most drivers, because it needs symbols exported by libcrc32c module.
Patch 1 and 2 of this series try to solve this problem, introducing a new
helper function, namely skb_crc32c_csum_help(), that can be used to resolve
CHECKSUM_PARTIAL when crc32c is needed instead of Internet Checksum.
Currently, we need to parse the packet headers to understand what algorithm
is needed to resolve CHECKSUM_PARTIAL. We can speedup things by storing
this information in the skb metadata, and use it to call an appropriate
helper (skb_checksum_help or skb_crc32c_csum_help), or leave the packet
unmodified when the NIC is able to offload the checksum computation.
Patch 3 deprecates skb->csum_bad to free one bit in skb metadata; patch 4
introduces skb->csum_not_inet, providing skb with an indication on the
algorithm needed to resolve CHECKSUM_PARTIAL.
Patch 5 and 6 fix the kernel forwarding path and openvswitch datapath,
where skb_checksum_help was unconditionally called to resolve CHECKSUM_PARTIAL,
thus generating wrong CRC32c in forwarded SCTP packets.
Finally, patch 7 updates documentation to provide a better description of
possible values of skb->ip_summed.
Some further work is still possible:
* drivers that parse the packet header to correctly resolve CHECKSUM_PARTIAL
(e.g. ixgbe_tx_csum()) can benefit from testing skb->csum_not_inet to avoid
calling ip_hdr(skb)->protocol or ixgbe_ipv6_csum_is_sctp(skb).
* drivers that call skb_checksum_help() to resolve CHECKSUM_PARTIAL can
call skb_csum_hwoffload_help to avoid corrupting SCTP packets.
changes since RFCv4:
- patch 2/7: use WARN_ON_ONCE() instead of BUG_ON(), and avoid computing
CRC32c on the error path.
- patch 3/7: don't invert tests on the values of same_flow and
NAPI_GRO_CB(skb)->flush in dev_gro_receive(), it's useless and it breaks
GRO functionality as reported by kernel test robot.
Davide Caratti (7):
skbuff: add stub to help computing crc32c on SCTP packets
net: introduce skb_crc32c_csum_help
sk_buff: remove support for csum_bad in sk_buff
net: use skb->csum_not_inet to identify packets needing crc32c
net: more accurate checksumming in validate_xmit_skb()
openvswitch: more accurate checksumming in queue_userspace_packet()
sk_buff.h: improve description of CHECKSUM_{COMPLETE,UNNECESSARY}
Documentation/networking/checksum-offloads.txt | 11 +++--
drivers/net/ethernet/aquantia/atlantic/aq_ring.c | 2 +-
include/linux/netdevice.h | 8 ++--
include/linux/skbuff.h | 58 +++++++++--------------
net/bridge/netfilter/nft_reject_bridge.c | 5 +-
net/core/dev.c | 59 ++++++++++++++++++++++--
net/core/skbuff.c | 24 ++++++++++
net/ipv4/netfilter/nf_reject_ipv4.c | 2 +-
net/ipv6/netfilter/nf_reject_ipv6.c | 3 --
net/openvswitch/datapath.c | 2 +-
net/sched/act_csum.c | 1 +
net/sctp/offload.c | 8 ++++
net/sctp/output.c | 1 +
13 files changed, 126 insertions(+), 58 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH net-next v2 1/7] skbuff: add stub to help computing crc32c on SCTP packets
From: Davide Caratti @ 2017-05-16 16:27 UTC (permalink / raw)
To: linux-sctp, netdev
Cc: Alexander Duyck, Tom Herbert, David Laight, David S. Miller,
Marcelo Ricardo Leitner
In-Reply-To: <cover.1494946940.git.dcaratti@redhat.com>
sctp_compute_checksum requires crc32c symbol (provided by libcrc32c), so
it can't be used in net core. Like it has been done previously with other
symbols (e.g. ipv6_dst_lookup), introduce a stub struct skb_checksum_ops
to allow computation of crc32c checksum in net core after sctp.ko (and thus
libcrc32c) has been loaded.
Reviewed-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
---
include/linux/skbuff.h | 2 ++
net/core/skbuff.c | 24 ++++++++++++++++++++++++
net/sctp/offload.c | 7 +++++++
3 files changed, 33 insertions(+)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index a098d95..884a197 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -3129,6 +3129,8 @@ struct skb_checksum_ops {
__wsum (*combine)(__wsum csum, __wsum csum2, int offset, int len);
};
+extern const struct skb_checksum_ops *crc32c_csum_stub __read_mostly;
+
__wsum __skb_checksum(const struct sk_buff *skb, int offset, int len,
__wsum csum, const struct skb_checksum_ops *ops);
__wsum skb_checksum(const struct sk_buff *skb, int offset, int len,
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 346d3e8..12e3cb7 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -2243,6 +2243,30 @@ __wsum skb_copy_and_csum_bits(const struct sk_buff *skb, int offset,
}
EXPORT_SYMBOL(skb_copy_and_csum_bits);
+static __wsum warn_crc32c_csum_update(const void *buff, int len, __wsum sum)
+{
+ net_warn_ratelimited(
+ "%s: attempt to compute crc32c without libcrc32c.ko\n",
+ __func__);
+ return 0;
+}
+
+static __wsum warn_crc32c_csum_combine(__wsum csum, __wsum csum2,
+ int offset, int len)
+{
+ net_warn_ratelimited(
+ "%s: attempt to compute crc32c without libcrc32c.ko\n",
+ __func__);
+ return 0;
+}
+
+const struct skb_checksum_ops *crc32c_csum_stub __read_mostly =
+ &(struct skb_checksum_ops) {
+ .update = warn_crc32c_csum_update,
+ .combine = warn_crc32c_csum_combine,
+};
+EXPORT_SYMBOL(crc32c_csum_stub);
+
/**
* skb_zerocopy_headlen - Calculate headroom needed for skb_zerocopy()
* @from: source buffer
diff --git a/net/sctp/offload.c b/net/sctp/offload.c
index 4f5a2b5..378f462 100644
--- a/net/sctp/offload.c
+++ b/net/sctp/offload.c
@@ -98,6 +98,12 @@ static const struct net_offload sctp6_offload = {
},
};
+static const struct skb_checksum_ops *crc32c_csum_ops __read_mostly =
+ &(struct skb_checksum_ops) {
+ .update = sctp_csum_update,
+ .combine = sctp_csum_combine,
+};
+
int __init sctp_offload_init(void)
{
int ret;
@@ -110,6 +116,7 @@ int __init sctp_offload_init(void)
if (ret)
goto ipv4;
+ crc32c_csum_stub = crc32c_csum_ops;
return ret;
ipv4:
--
2.7.4
^ permalink raw reply related
* [PATCH net-next v2 4/7] net: use skb->csum_not_inet to identify packets needing crc32c
From: Davide Caratti @ 2017-05-16 16:27 UTC (permalink / raw)
To: linux-sctp, netdev
Cc: Alexander Duyck, Tom Herbert, David Laight, David S. Miller,
Marcelo Ricardo Leitner
In-Reply-To: <cover.1494946940.git.dcaratti@redhat.com>
skb->csum_not_inet carries the indication on which algorithm is needed to
compute checksum on skb in the transmit path, when skb->ip_summed is equal
to CHECKSUM_PARTIAL. If skb carries a SCTP packet and crc32c hasn't been
yet written in L4 header, skb->csum_not_inet is assigned to 1; otherwise,
assume Internet Checksum is needed and thus set skb->csum_not_inet to 0.
Suggested-by: Tom Herbert <tom@herbertland.com>
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
Acked-by: Tom Herbert <tom@herbertland.com>
---
include/linux/skbuff.h | 16 +++++++++-------
net/core/dev.c | 1 +
net/sched/act_csum.c | 1 +
net/sctp/offload.c | 1 +
net/sctp/output.c | 1 +
5 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index f98e3a6..2fefd92 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -189,12 +189,13 @@
*
* NETIF_F_SCTP_CRC - This feature indicates that a device is capable of
* offloading the SCTP CRC in a packet. To perform this offload the stack
- * will set ip_summed to CHECKSUM_PARTIAL and set csum_start and csum_offset
- * accordingly. Note the there is no indication in the skbuff that the
- * CHECKSUM_PARTIAL refers to an SCTP checksum, a driver that supports
- * both IP checksum offload and SCTP CRC offload must verify which offload
- * is configured for a packet presumably by inspecting packet headers; in
- * case, skb_crc32c_csum_help is provided to compute CRC on SCTP packets.
+ * will set set csum_start and csum_offset accordingly, set ip_summed to
+ * CHECKSUM_PARTIAL and set csum_not_inet to 1, to provide an indication in
+ * the skbuff that the CHECKSUM_PARTIAL refers to CRC32c.
+ * A driver that supports both IP checksum offload and SCTP CRC32c offload
+ * must verify which offload is configured for a packet by testing the
+ * value of skb->csum_not_inet; skb_crc32c_csum_help is provided to resolve
+ * CHECKSUM_PARTIAL on skbs where csum_not_inet is set to 1.
*
* NETIF_F_FCOE_CRC - This feature indicates that a device is capable of
* offloading the FCOE CRC in a packet. To perform this offload the stack
@@ -617,6 +618,7 @@ static inline bool skb_mstamp_after(const struct skb_mstamp *t1,
* @wifi_acked_valid: wifi_acked was set
* @wifi_acked: whether frame was acked on wifi or not
* @no_fcs: Request NIC to treat last 4 bytes as Ethernet FCS
+ * @csum_not_inet: use CRC32c to resolve CHECKSUM_PARTIAL
* @dst_pending_confirm: need to confirm neighbour
* @napi_id: id of the NAPI struct this skb came from
* @secmark: security marking
@@ -745,7 +747,7 @@ struct sk_buff {
__u8 csum_valid:1;
__u8 csum_complete_sw:1;
__u8 csum_level:2;
- __u8 __csum_bad_unused:1; /* one bit hole */
+ __u8 csum_not_inet:1;
__u8 dst_pending_confirm:1;
#ifdef CONFIG_IPV6_NDISC_NODETYPE
diff --git a/net/core/dev.c b/net/core/dev.c
index 1b9575c..2cedb0f 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2647,6 +2647,7 @@ int skb_crc32c_csum_help(struct sk_buff *skb)
crc32c_csum_stub));
*(__le32 *)(skb->data + offset) = crc32c_csum;
skb->ip_summed = CHECKSUM_NONE;
+ skb->csum_not_inet = 0;
out:
return ret;
}
diff --git a/net/sched/act_csum.c b/net/sched/act_csum.c
index ab6fdbd..3317a2f 100644
--- a/net/sched/act_csum.c
+++ b/net/sched/act_csum.c
@@ -350,6 +350,7 @@ static int tcf_csum_sctp(struct sk_buff *skb, unsigned int ihl,
sctph->checksum = sctp_compute_cksum(skb,
skb_network_offset(skb) + ihl);
skb->ip_summed = CHECKSUM_NONE;
+ skb->csum_not_inet = 0;
return 1;
}
diff --git a/net/sctp/offload.c b/net/sctp/offload.c
index 378f462..ef156ac 100644
--- a/net/sctp/offload.c
+++ b/net/sctp/offload.c
@@ -35,6 +35,7 @@
static __le32 sctp_gso_make_checksum(struct sk_buff *skb)
{
skb->ip_summed = CHECKSUM_NONE;
+ skb->csum_not_inet = 0;
return sctp_compute_cksum(skb, skb_transport_offset(skb));
}
diff --git a/net/sctp/output.c b/net/sctp/output.c
index 1409a87..e2edf2e 100644
--- a/net/sctp/output.c
+++ b/net/sctp/output.c
@@ -538,6 +538,7 @@ static int sctp_packet_pack(struct sctp_packet *packet,
} else {
chksum:
head->ip_summed = CHECKSUM_PARTIAL;
+ head->csum_not_inet = 1;
head->csum_start = skb_transport_header(head) - head->head;
head->csum_offset = offsetof(struct sctphdr, checksum);
}
--
2.7.4
^ permalink raw reply related
* [PATCH net-next v2 5/7] net: more accurate checksumming in validate_xmit_skb()
From: Davide Caratti @ 2017-05-16 16:27 UTC (permalink / raw)
To: linux-sctp, netdev
Cc: Alexander Duyck, Tom Herbert, David Laight, David S. Miller,
Marcelo Ricardo Leitner
In-Reply-To: <cover.1494946940.git.dcaratti@redhat.com>
skb_csum_hwoffload_help() uses netdev features and skb->csum_not_inet to
determine if skb needs software computation of Internet Checksum or crc32c
(or nothing, if this computation can be done by the hardware). Use it in
place of skb_checksum_help() in validate_xmit_skb() to avoid corruption
of non-GSO SCTP packets having skb->ip_summed equal to CHECKSUM_PARTIAL.
While at it, remove references to skb_csum_off_chk* functions, since they
are not present anymore in Linux _ see commit cf53b1da73bd ("Revert
"net: Add driver helper functions to determine checksum offloadability"").
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
---
Documentation/networking/checksum-offloads.txt | 11 +++++++----
include/linux/netdevice.h | 3 +++
include/linux/skbuff.h | 13 +++++--------
net/core/dev.c | 14 ++++++++++++--
4 files changed, 27 insertions(+), 14 deletions(-)
diff --git a/Documentation/networking/checksum-offloads.txt b/Documentation/networking/checksum-offloads.txt
index 56e3686..d52d191 100644
--- a/Documentation/networking/checksum-offloads.txt
+++ b/Documentation/networking/checksum-offloads.txt
@@ -35,6 +35,9 @@ This interface only allows a single checksum to be offloaded. Where
encapsulation is used, the packet may have multiple checksum fields in
different header layers, and the rest will have to be handled by another
mechanism such as LCO or RCO.
+CRC32c can also be offloaded using this interface, by means of filling
+ skb->csum_start and skb->csum_offset as described above, and setting
+ skb->csum_not_inet: see skbuff.h comment (section 'D') for more details.
No offloading of the IP header checksum is performed; it is always done in
software. This is OK because when we build the IP header, we obviously
have it in cache, so summing it isn't expensive. It's also rather short.
@@ -49,9 +52,9 @@ A driver declares its offload capabilities in netdev->hw_features; see
and csum_offset given in the SKB; if it tries to deduce these itself in
hardware (as some NICs do) the driver should check that the values in the
SKB match those which the hardware will deduce, and if not, fall back to
- checksumming in software instead (with skb_checksum_help or one of the
- skb_csum_off_chk* functions as mentioned in include/linux/skbuff.h). This
- is a pain, but that's what you get when hardware tries to be clever.
+ checksumming in software instead (with skb_csum_hwoffload_help() or one of
+ the skb_checksum_help() / skb_crc32c_csum_help functions, as mentioned in
+ include/linux/skbuff.h).
The stack should, for the most part, assume that checksum offload is
supported by the underlying device. The only place that should check is
@@ -60,7 +63,7 @@ The stack should, for the most part, assume that checksum offload is
may include other offloads besides TX Checksum Offload) and, if they are
not supported or enabled on the device (determined by netdev->features),
performs the corresponding offload in software. In the case of TX
- Checksum Offload, that means calling skb_checksum_help(skb).
+ Checksum Offload, that means calling skb_csum_hwoffload_help(skb, features).
LCO: Local Checksum Offload
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index f168edb..3e454f2 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -3926,6 +3926,9 @@ void netdev_rss_key_fill(void *buffer, size_t len);
int dev_get_nest_level(struct net_device *dev);
int skb_checksum_help(struct sk_buff *skb);
int skb_crc32c_csum_help(struct sk_buff *skb);
+int skb_csum_hwoffload_help(struct sk_buff *skb,
+ const netdev_features_t features);
+
struct sk_buff *__skb_gso_segment(struct sk_buff *skb,
netdev_features_t features, bool tx_path);
struct sk_buff *skb_mac_gso_segment(struct sk_buff *skb,
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 2fefd92..fe109fa 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -162,14 +162,11 @@
*
* NETIF_F_IP_CSUM and NETIF_F_IPV6_CSUM are being deprecated in favor of
* NETIF_F_HW_CSUM. New devices should use NETIF_F_HW_CSUM to indicate
- * checksum offload capability. If a device has limited checksum capabilities
- * (for instance can only perform NETIF_F_IP_CSUM or NETIF_F_IPV6_CSUM as
- * described above) a helper function can be called to resolve
- * CHECKSUM_PARTIAL. The helper functions are skb_csum_off_chk*. The helper
- * function takes a spec argument that describes the protocol layer that is
- * supported for checksum offload and can be called for each packet. If a
- * packet does not match the specification for offload, skb_checksum_help
- * is called to resolve the checksum.
+ * checksum offload capability.
+ * skb_csum_hwoffload_help() can be called to resolve CHECKSUM_PARTIAL based
+ * on network device checksumming capabilities: if a packet does not match
+ * them, skb_checksum_help or skb_crc32c_help (depending on the value of
+ * csum_not_inet, see item D.) is called to resolve the checksum.
*
* CHECKSUM_NONE:
*
diff --git a/net/core/dev.c b/net/core/dev.c
index 2cedb0f..242c055 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2994,6 +2994,17 @@ static struct sk_buff *validate_xmit_vlan(struct sk_buff *skb,
return skb;
}
+int skb_csum_hwoffload_help(struct sk_buff *skb,
+ const netdev_features_t features)
+{
+ if (unlikely(skb->csum_not_inet))
+ return !!(features & NETIF_F_SCTP_CRC) ? 0 :
+ skb_crc32c_csum_help(skb);
+
+ return !!(features & NETIF_F_CSUM_MASK) ? 0 : skb_checksum_help(skb);
+}
+EXPORT_SYMBOL(skb_csum_hwoffload_help);
+
static struct sk_buff *validate_xmit_skb(struct sk_buff *skb, struct net_device *dev)
{
netdev_features_t features;
@@ -3032,8 +3043,7 @@ static struct sk_buff *validate_xmit_skb(struct sk_buff *skb, struct net_device
else
skb_set_transport_header(skb,
skb_checksum_start_offset(skb));
- if (!(features & NETIF_F_CSUM_MASK) &&
- skb_checksum_help(skb))
+ if (skb_csum_hwoffload_help(skb, features))
goto out_kfree_skb;
}
}
--
2.7.4
^ permalink raw reply related
* [PATCH net-next v2 2/7] net: introduce skb_crc32c_csum_help
From: Davide Caratti @ 2017-05-16 16:27 UTC (permalink / raw)
To: linux-sctp, netdev
Cc: Alexander Duyck, Tom Herbert, David Laight, David S. Miller,
Marcelo Ricardo Leitner
In-Reply-To: <cover.1494946940.git.dcaratti@redhat.com>
skb_crc32c_csum_help is like skb_checksum_help, but it is designed for
checksumming SCTP packets using crc32c (see RFC3309), provided that
libcrc32c.ko has been loaded before. In case libcrc32c is not loaded,
invoking skb_crc32c_csum_help on a skb results in one the following
printouts:
warn_crc32c_csum_update: attempt to compute crc32c without libcrc32c.ko
warn_crc32c_csum_combine: attempt to compute crc32c without libcrc32c.ko
Signed-off-by: Davide Caratti <dcaratti@redhat.com>
---
include/linux/netdevice.h | 1 +
include/linux/skbuff.h | 3 ++-
net/core/dev.c | 41 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 44 insertions(+), 1 deletion(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 9c23bd2..8e771f1 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -3927,6 +3927,7 @@ void netdev_rss_key_fill(void *buffer, size_t len);
int dev_get_nest_level(struct net_device *dev);
int skb_checksum_help(struct sk_buff *skb);
+int skb_crc32c_csum_help(struct sk_buff *skb);
struct sk_buff *__skb_gso_segment(struct sk_buff *skb,
netdev_features_t features, bool tx_path);
struct sk_buff *skb_mac_gso_segment(struct sk_buff *skb,
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 884a197..f3cfaaf 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -193,7 +193,8 @@
* accordingly. Note the there is no indication in the skbuff that the
* CHECKSUM_PARTIAL refers to an SCTP checksum, a driver that supports
* both IP checksum offload and SCTP CRC offload must verify which offload
- * is configured for a packet presumably by inspecting packet headers.
+ * is configured for a packet presumably by inspecting packet headers; in
+ * case, skb_crc32c_csum_help is provided to compute CRC on SCTP packets.
*
* NETIF_F_FCOE_CRC - This feature indicates that a device is capable of
* offloading the FCOE CRC in a packet. To perform this offload the stack
diff --git a/net/core/dev.c b/net/core/dev.c
index d07aa5f..702ed50 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -141,6 +141,7 @@
#include <linux/hrtimer.h>
#include <linux/netfilter_ingress.h>
#include <linux/crash_dump.h>
+#include <linux/sctp.h>
#include "net-sysfs.h"
@@ -2610,6 +2611,46 @@ int skb_checksum_help(struct sk_buff *skb)
}
EXPORT_SYMBOL(skb_checksum_help);
+int skb_crc32c_csum_help(struct sk_buff *skb)
+{
+ __le32 crc32c_csum;
+ int ret = 0, offset, start;
+
+ if (skb->ip_summed != CHECKSUM_PARTIAL)
+ goto out;
+
+ if (unlikely(skb_is_gso(skb)))
+ goto out;
+
+ /* Before computing a checksum, we should make sure no frag could
+ * be modified by an external entity : checksum could be wrong.
+ */
+ if (unlikely(skb_has_shared_frag(skb))) {
+ ret = __skb_linearize(skb);
+ if (ret)
+ goto out;
+ }
+ start = skb_checksum_start_offset(skb);
+ offset = start + offsetof(struct sctphdr, checksum);
+ if (WARN_ON_ONCE(offset >= skb_headlen(skb))) {
+ ret = -EINVAL;
+ goto out;
+ }
+ if (skb_cloned(skb) &&
+ !skb_clone_writable(skb, offset + sizeof(__le32))) {
+ ret = pskb_expand_head(skb, 0, 0, GFP_ATOMIC);
+ if (ret)
+ goto out;
+ }
+ crc32c_csum = cpu_to_le32(~__skb_checksum(skb, start,
+ skb->len - start, ~(__u32)0,
+ crc32c_csum_stub));
+ *(__le32 *)(skb->data + offset) = crc32c_csum;
+ skb->ip_summed = CHECKSUM_NONE;
+out:
+ return ret;
+}
+
__be16 skb_network_protocol(struct sk_buff *skb, int *depth)
{
__be16 type = skb->protocol;
--
2.7.4
^ 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