* [net-next PATCH v2 1/8] udp: Record gso_segs when supporting UDP segmentation offload
From: Alexander Duyck @ 2018-05-04 18:28 UTC (permalink / raw)
To: netdev, willemb, davem
In-Reply-To: <20180504182537.5194.72775.stgit@localhost.localdomain>
From: Alexander Duyck <alexander.h.duyck@intel.com>
We need to record the number of segments that will be generated when this
frame is segmented. The expectation is that if gso_size is set then
gso_segs is set as well. Without this some drivers such as ixgbe get
confused if they attempt to offload this as they record 0 segments for the
entire packet instead of the correct value.
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
net/ipv4/udp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index dd3102a37ef9..e07db83b311e 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -793,6 +793,8 @@ static int udp_send_skb(struct sk_buff *skb, struct flowi4 *fl4,
skb_shinfo(skb)->gso_size = cork->gso_size;
skb_shinfo(skb)->gso_type = SKB_GSO_UDP_L4;
+ skb_shinfo(skb)->gso_segs = DIV_ROUND_UP(len - sizeof(uh),
+ cork->gso_size);
goto csum_partial;
}
^ permalink raw reply related
* [net-next PATCH v2 2/8] udp: Verify that pulling UDP header in GSO segmentation doesn't fail
From: Alexander Duyck @ 2018-05-04 18:29 UTC (permalink / raw)
To: netdev, willemb, davem
In-Reply-To: <20180504182537.5194.72775.stgit@localhost.localdomain>
From: Alexander Duyck <alexander.h.duyck@intel.com>
We should verify that we can pull the UDP header before we attempt to do
so. Otherwise if this fails we have no way of knowing and GSO will not work
correctly.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
v2: New break-out patch based on one patch from earlier series
net/ipv4/udp_offload.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
index 006257092f06..8303fff42940 100644
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c
@@ -191,14 +191,17 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
netdev_features_t features,
unsigned int mss, __sum16 check)
{
+ struct sk_buff *seg, *segs = ERR_PTR(-EINVAL);
struct sock *sk = gso_skb->sk;
unsigned int sum_truesize = 0;
- struct sk_buff *segs, *seg;
unsigned int hdrlen;
struct udphdr *uh;
if (gso_skb->len <= sizeof(*uh) + mss)
- return ERR_PTR(-EINVAL);
+ goto out;
+
+ if (!pskb_may_pull(gso_skb, sizeof(*uh)))
+ goto out;
hdrlen = gso_skb->data - skb_mac_header(gso_skb);
skb_pull(gso_skb, sizeof(*uh));
@@ -230,7 +233,7 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
}
refcount_add(sum_truesize - gso_skb->truesize, &sk->sk_wmem_alloc);
-
+out:
return segs;
}
EXPORT_SYMBOL_GPL(__udp_gso_segment);
^ permalink raw reply related
* [net-next PATCH v2 3/8] udp: Do not pass MSS as parameter to GSO segmentation
From: Alexander Duyck @ 2018-05-04 18:29 UTC (permalink / raw)
To: netdev, willemb, davem
In-Reply-To: <20180504182537.5194.72775.stgit@localhost.localdomain>
From: Alexander Duyck <alexander.h.duyck@intel.com>
There is no point in passing MSS as a parameter for for the GSO
segmentation call as it is already available via the shared info for the
skb itself.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
v2: New break-out patch based on one patch from earlier series
include/net/udp.h | 2 +-
net/ipv4/udp_offload.c | 6 ++++--
net/ipv6/udp_offload.c | 2 +-
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/include/net/udp.h b/include/net/udp.h
index 05990746810e..8bd83b044ecd 100644
--- a/include/net/udp.h
+++ b/include/net/udp.h
@@ -176,7 +176,7 @@ struct sk_buff **udp_gro_receive(struct sk_buff **head, struct sk_buff *skb,
struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
netdev_features_t features,
- unsigned int mss, __sum16 check);
+ __sum16 check);
static inline struct udphdr *udp_gro_udphdr(struct sk_buff *skb)
{
diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
index 8303fff42940..f21b63adcbbc 100644
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c
@@ -189,14 +189,16 @@ struct sk_buff *skb_udp_tunnel_segment(struct sk_buff *skb,
struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
netdev_features_t features,
- unsigned int mss, __sum16 check)
+ __sum16 check)
{
struct sk_buff *seg, *segs = ERR_PTR(-EINVAL);
struct sock *sk = gso_skb->sk;
unsigned int sum_truesize = 0;
unsigned int hdrlen;
struct udphdr *uh;
+ unsigned int mss;
+ mss = skb_shinfo(gso_skb)->gso_size;
if (gso_skb->len <= sizeof(*uh) + mss)
goto out;
@@ -247,7 +249,7 @@ static struct sk_buff *__udp4_gso_segment(struct sk_buff *gso_skb,
if (!can_checksum_protocol(features, htons(ETH_P_IP)))
return ERR_PTR(-EIO);
- return __udp_gso_segment(gso_skb, features, mss,
+ return __udp_gso_segment(gso_skb, features,
udp_v4_check(sizeof(struct udphdr) + mss,
iph->saddr, iph->daddr, 0));
}
diff --git a/net/ipv6/udp_offload.c b/net/ipv6/udp_offload.c
index f7b85b1e6b3e..dea03ec09715 100644
--- a/net/ipv6/udp_offload.c
+++ b/net/ipv6/udp_offload.c
@@ -26,7 +26,7 @@ static struct sk_buff *__udp6_gso_segment(struct sk_buff *gso_skb,
if (!can_checksum_protocol(features, htons(ETH_P_IPV6)))
return ERR_PTR(-EIO);
- return __udp_gso_segment(gso_skb, features, mss,
+ return __udp_gso_segment(gso_skb, features,
udp_v6_check(sizeof(struct udphdr) + mss,
&ip6h->saddr, &ip6h->daddr, 0));
}
^ permalink raw reply related
* [net-next PATCH v2 4/8] udp: Do not pass checksum as a parameter to GSO segmentation
From: Alexander Duyck @ 2018-05-04 18:30 UTC (permalink / raw)
To: netdev, willemb, davem
In-Reply-To: <20180504182537.5194.72775.stgit@localhost.localdomain>
From: Alexander Duyck <alexander.h.duyck@intel.com>
This patch is meant to allow us to avoid having to recompute the checksum
from scratch and have it passed as a parameter.
Instead of taking that approach we can take advantage of the fact that the
length that was used to compute the existing checksum is included in the
UDP header. If we cancel that out by adding the value XOR with 0xFFFF we
can then just add the new length in and fold that into the new result.
I think this may be fixing a checksum bug in the original code as well
since the checksum that was passed included the UDP header in the checksum
computation, but then excluded it for the adjustment on the last frame. I
believe this may have an effect on things in the cases where the two differ
by bits that would result in things crossing the byte boundaries.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
v2: New break-out patch based on one patch from earlier series
include/net/udp.h | 3 +--
net/ipv4/udp_offload.c | 35 +++++++++++++++++++++--------------
net/ipv6/udp_offload.c | 7 +------
3 files changed, 23 insertions(+), 22 deletions(-)
diff --git a/include/net/udp.h b/include/net/udp.h
index 8bd83b044ecd..9289b6425032 100644
--- a/include/net/udp.h
+++ b/include/net/udp.h
@@ -175,8 +175,7 @@ struct sk_buff **udp_gro_receive(struct sk_buff **head, struct sk_buff *skb,
int udp_gro_complete(struct sk_buff *skb, int nhoff, udp_lookup_t lookup);
struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
- netdev_features_t features,
- __sum16 check);
+ netdev_features_t features);
static inline struct udphdr *udp_gro_udphdr(struct sk_buff *skb)
{
diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
index f21b63adcbbc..5c4bb8b9e83e 100644
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c
@@ -188,8 +188,7 @@ struct sk_buff *skb_udp_tunnel_segment(struct sk_buff *skb,
EXPORT_SYMBOL(skb_udp_tunnel_segment);
struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
- netdev_features_t features,
- __sum16 check)
+ netdev_features_t features)
{
struct sk_buff *seg, *segs = ERR_PTR(-EINVAL);
struct sock *sk = gso_skb->sk;
@@ -197,6 +196,8 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
unsigned int hdrlen;
struct udphdr *uh;
unsigned int mss;
+ __sum16 check;
+ __be16 newlen;
mss = skb_shinfo(gso_skb)->gso_size;
if (gso_skb->len <= sizeof(*uh) + mss)
@@ -218,17 +219,28 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
return segs;
}
+ uh = udp_hdr(segs);
+
+ /* compute checksum adjustment based on old length versus new */
+ newlen = htons(sizeof(*uh) + mss);
+ check = ~csum_fold((__force __wsum)((__force u32)uh->check +
+ ((__force u32)uh->len ^ 0xFFFF) +
+ (__force u32)newlen));
+
for (seg = segs; seg; seg = seg->next) {
uh = udp_hdr(seg);
- uh->len = htons(seg->len - hdrlen);
- uh->check = check;
/* last packet can be partial gso_size */
- if (!seg->next)
- csum_replace2(&uh->check, htons(mss),
- htons(seg->len - hdrlen - sizeof(*uh)));
+ if (!seg->next) {
+ newlen = htons(seg->len - hdrlen);
+ check = ~csum_fold((__force __wsum)((__force u32)uh->check +
+ ((__force u32)uh->len ^ 0xFFFF) +
+ (__force u32)newlen));
+ }
+
+ uh->len = newlen;
+ uh->check = check;
- uh->check = ~uh->check;
seg->destructor = sock_wfree;
seg->sk = sk;
sum_truesize += seg->truesize;
@@ -243,15 +255,10 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
static struct sk_buff *__udp4_gso_segment(struct sk_buff *gso_skb,
netdev_features_t features)
{
- const struct iphdr *iph = ip_hdr(gso_skb);
- unsigned int mss = skb_shinfo(gso_skb)->gso_size;
-
if (!can_checksum_protocol(features, htons(ETH_P_IP)))
return ERR_PTR(-EIO);
- return __udp_gso_segment(gso_skb, features,
- udp_v4_check(sizeof(struct udphdr) + mss,
- iph->saddr, iph->daddr, 0));
+ return __udp_gso_segment(gso_skb, features);
}
static struct sk_buff *udp4_ufo_fragment(struct sk_buff *skb,
diff --git a/net/ipv6/udp_offload.c b/net/ipv6/udp_offload.c
index dea03ec09715..61e34f1d2fa2 100644
--- a/net/ipv6/udp_offload.c
+++ b/net/ipv6/udp_offload.c
@@ -20,15 +20,10 @@
static struct sk_buff *__udp6_gso_segment(struct sk_buff *gso_skb,
netdev_features_t features)
{
- const struct ipv6hdr *ip6h = ipv6_hdr(gso_skb);
- unsigned int mss = skb_shinfo(gso_skb)->gso_size;
-
if (!can_checksum_protocol(features, htons(ETH_P_IPV6)))
return ERR_PTR(-EIO);
- return __udp_gso_segment(gso_skb, features,
- udp_v6_check(sizeof(struct udphdr) + mss,
- &ip6h->saddr, &ip6h->daddr, 0));
+ return __udp_gso_segment(gso_skb, features);
}
static struct sk_buff *udp6_ufo_fragment(struct sk_buff *skb,
^ permalink raw reply related
* [net-next PATCH v2 5/8] udp: Partially unroll handling of first segment and last segment
From: Alexander Duyck @ 2018-05-04 18:30 UTC (permalink / raw)
To: netdev, willemb, davem
In-Reply-To: <20180504182537.5194.72775.stgit@localhost.localdomain>
From: Alexander Duyck <alexander.h.duyck@intel.com>
This patch allows us to take care of unrolling the first segment and the
last segment of the loop for processing the segmented skb. Part of the
motivation for this is that it makes it easier to process the fact that the
first fame and all of the frames in between should be mostly identical
in terms of header data, and the last frame has differences in the length
and partial checksum.
In addition I am dropping the header length calculation since we don't
really need it for anything but the last frame and it can be easily
obtained by just pulling the data_len and offset of tail from the transport
header.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
v2: New break-out patch based on one patch from earlier series
net/ipv4/udp_offload.c | 35 ++++++++++++++++++++---------------
1 file changed, 20 insertions(+), 15 deletions(-)
diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
index 5c4bb8b9e83e..946d06d2aa0c 100644
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c
@@ -193,7 +193,6 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
struct sk_buff *seg, *segs = ERR_PTR(-EINVAL);
struct sock *sk = gso_skb->sk;
unsigned int sum_truesize = 0;
- unsigned int hdrlen;
struct udphdr *uh;
unsigned int mss;
__sum16 check;
@@ -206,7 +205,6 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
if (!pskb_may_pull(gso_skb, sizeof(*uh)))
goto out;
- hdrlen = gso_skb->data - skb_mac_header(gso_skb);
skb_pull(gso_skb, sizeof(*uh));
/* clear destructor to avoid skb_segment assigning it to tail */
@@ -219,7 +217,8 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
return segs;
}
- uh = udp_hdr(segs);
+ seg = segs;
+ uh = udp_hdr(seg);
/* compute checksum adjustment based on old length versus new */
newlen = htons(sizeof(*uh) + mss);
@@ -227,25 +226,31 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
((__force u32)uh->len ^ 0xFFFF) +
(__force u32)newlen));
- for (seg = segs; seg; seg = seg->next) {
- uh = udp_hdr(seg);
+ for (;;) {
+ seg->destructor = sock_wfree;
+ seg->sk = sk;
+ sum_truesize += seg->truesize;
- /* last packet can be partial gso_size */
- if (!seg->next) {
- newlen = htons(seg->len - hdrlen);
- check = ~csum_fold((__force __wsum)((__force u32)uh->check +
- ((__force u32)uh->len ^ 0xFFFF) +
- (__force u32)newlen));
- }
+ if (!seg->next)
+ break;
uh->len = newlen;
uh->check = check;
- seg->destructor = sock_wfree;
- seg->sk = sk;
- sum_truesize += seg->truesize;
+ seg = seg->next;
+ uh = udp_hdr(seg);
}
+ /* last packet can be partial gso_size, account for that in checksum */
+ newlen = htons(skb_tail_pointer(seg) - skb_transport_header(seg) +
+ seg->data_len);
+ check = ~csum_fold((__force __wsum)((__force u32)uh->check +
+ ((__force u32)uh->len ^ 0xFFFF) +
+ (__force u32)newlen));
+ uh->len = newlen;
+ uh->check = check;
+
+ /* update refcount for the packet */
refcount_add(sum_truesize - gso_skb->truesize, &sk->sk_wmem_alloc);
out:
return segs;
^ permalink raw reply related
* [net-next PATCH v2 6/8] udp: Add support for software checksum and GSO_PARTIAL with GSO offload
From: Alexander Duyck @ 2018-05-04 18:31 UTC (permalink / raw)
To: netdev, willemb, davem
In-Reply-To: <20180504182537.5194.72775.stgit@localhost.localdomain>
From: Alexander Duyck <alexander.h.duyck@intel.com>
This patch adds support for a software provided checksum and GSO_PARTIAL
segmentation support. With this we can offload UDP segmentation on devices
that only have partial support for tunnels.
Since we are no longer needing the hardware checksum we can drop the checks
in the segmentation code that were verifying if it was present.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
net/ipv4/udp_offload.c | 28 ++++++++++++++++++----------
net/ipv6/udp_offload.c | 11 +----------
2 files changed, 19 insertions(+), 20 deletions(-)
diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
index 946d06d2aa0c..fd94bbb369b2 100644
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c
@@ -217,6 +217,13 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
return segs;
}
+ /* GSO partial and frag_list segmentation only requires splitting
+ * the frame into an MSS multiple and possibly a remainder, both
+ * cases return a GSO skb. So update the mss now.
+ */
+ if (skb_is_gso(segs))
+ mss *= skb_shinfo(segs)->gso_segs;
+
seg = segs;
uh = udp_hdr(seg);
@@ -237,6 +244,11 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
uh->len = newlen;
uh->check = check;
+ if (seg->ip_summed == CHECKSUM_PARTIAL)
+ gso_reset_checksum(seg, ~check);
+ else
+ uh->check = gso_make_checksum(seg, ~check);
+
seg = seg->next;
uh = udp_hdr(seg);
}
@@ -250,6 +262,11 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
uh->len = newlen;
uh->check = check;
+ if (seg->ip_summed == CHECKSUM_PARTIAL)
+ gso_reset_checksum(seg, ~check);
+ else
+ uh->check = gso_make_checksum(seg, ~check);
+
/* update refcount for the packet */
refcount_add(sum_truesize - gso_skb->truesize, &sk->sk_wmem_alloc);
out:
@@ -257,15 +274,6 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
}
EXPORT_SYMBOL_GPL(__udp_gso_segment);
-static struct sk_buff *__udp4_gso_segment(struct sk_buff *gso_skb,
- netdev_features_t features)
-{
- if (!can_checksum_protocol(features, htons(ETH_P_IP)))
- return ERR_PTR(-EIO);
-
- return __udp_gso_segment(gso_skb, features);
-}
-
static struct sk_buff *udp4_ufo_fragment(struct sk_buff *skb,
netdev_features_t features)
{
@@ -289,7 +297,7 @@ static struct sk_buff *udp4_ufo_fragment(struct sk_buff *skb,
goto out;
if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_L4)
- return __udp4_gso_segment(skb, features);
+ return __udp_gso_segment(skb, features);
mss = skb_shinfo(skb)->gso_size;
if (unlikely(skb->len <= mss))
diff --git a/net/ipv6/udp_offload.c b/net/ipv6/udp_offload.c
index 61e34f1d2fa2..03a2ff3fe1e6 100644
--- a/net/ipv6/udp_offload.c
+++ b/net/ipv6/udp_offload.c
@@ -17,15 +17,6 @@
#include <net/ip6_checksum.h>
#include "ip6_offload.h"
-static struct sk_buff *__udp6_gso_segment(struct sk_buff *gso_skb,
- netdev_features_t features)
-{
- if (!can_checksum_protocol(features, htons(ETH_P_IPV6)))
- return ERR_PTR(-EIO);
-
- return __udp_gso_segment(gso_skb, features);
-}
-
static struct sk_buff *udp6_ufo_fragment(struct sk_buff *skb,
netdev_features_t features)
{
@@ -58,7 +49,7 @@ static struct sk_buff *udp6_ufo_fragment(struct sk_buff *skb,
goto out;
if (skb_shinfo(skb)->gso_type & SKB_GSO_UDP_L4)
- return __udp6_gso_segment(skb, features);
+ return __udp_gso_segment(skb, features);
/* Do software UFO. Complete and fill in the UDP checksum as HW cannot
* do checksum of UDP packets sent as multiple IP fragments.
^ permalink raw reply related
* [net-next PATCH v2 7/8] udp: Do not copy destructor if one is not present
From: Alexander Duyck @ 2018-05-04 18:31 UTC (permalink / raw)
To: netdev, willemb, davem
In-Reply-To: <20180504182537.5194.72775.stgit@localhost.localdomain>
From: Alexander Duyck <alexander.h.duyck@intel.com>
This patch makes it so that if a destructor is not present we avoid trying
to update the skb socket or any reference counting that would be associated
with the NULL socket and/or descriptor. By doing this we can support
traffic coming from another namespace without any issues.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
v2: Do not overwrite destructor if not sock_wfree as per Eric
Drop WARN_ON as per Eric
net/ipv4/udp_offload.c | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/net/ipv4/udp_offload.c b/net/ipv4/udp_offload.c
index fd94bbb369b2..e802f6331589 100644
--- a/net/ipv4/udp_offload.c
+++ b/net/ipv4/udp_offload.c
@@ -195,6 +195,7 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
unsigned int sum_truesize = 0;
struct udphdr *uh;
unsigned int mss;
+ bool copy_dtor;
__sum16 check;
__be16 newlen;
@@ -208,12 +209,14 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
skb_pull(gso_skb, sizeof(*uh));
/* clear destructor to avoid skb_segment assigning it to tail */
- WARN_ON_ONCE(gso_skb->destructor != sock_wfree);
- gso_skb->destructor = NULL;
+ copy_dtor = gso_skb->destructor == sock_wfree;
+ if (copy_dtor)
+ gso_skb->destructor = NULL;
segs = skb_segment(gso_skb, features);
if (unlikely(IS_ERR_OR_NULL(segs))) {
- gso_skb->destructor = sock_wfree;
+ if (copy_dtor)
+ gso_skb->destructor = sock_wfree;
return segs;
}
@@ -234,9 +237,11 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
(__force u32)newlen));
for (;;) {
- seg->destructor = sock_wfree;
- seg->sk = sk;
- sum_truesize += seg->truesize;
+ if (copy_dtor) {
+ seg->destructor = sock_wfree;
+ seg->sk = sk;
+ sum_truesize += seg->truesize;
+ }
if (!seg->next)
break;
@@ -268,7 +273,9 @@ struct sk_buff *__udp_gso_segment(struct sk_buff *gso_skb,
uh->check = gso_make_checksum(seg, ~check);
/* update refcount for the packet */
- refcount_add(sum_truesize - gso_skb->truesize, &sk->sk_wmem_alloc);
+ if (copy_dtor)
+ refcount_add(sum_truesize - gso_skb->truesize,
+ &sk->sk_wmem_alloc);
out:
return segs;
}
^ permalink raw reply related
* [net-next PATCH v2 8/8] net: Add NETIF_F_GSO_UDP_L4 to list of GSO offloads with fallback
From: Alexander Duyck @ 2018-05-04 18:31 UTC (permalink / raw)
To: netdev, willemb, davem
In-Reply-To: <20180504182537.5194.72775.stgit@localhost.localdomain>
From: Alexander Duyck <alexander.h.duyck@intel.com>
Enable UDP offload as a generic software offload since we can now handle it
for multiple cases including if the checksum isn't present and via
gso_partial in the case of tunnels.
Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
---
include/linux/netdev_features.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
index c87c3a3453c1..efbd8b2c0197 100644
--- a/include/linux/netdev_features.h
+++ b/include/linux/netdev_features.h
@@ -184,7 +184,8 @@ enum {
/* List of features with software fallbacks. */
#define NETIF_F_GSO_SOFTWARE (NETIF_F_ALL_TSO | \
- NETIF_F_GSO_SCTP)
+ NETIF_F_GSO_SCTP| \
+ NETIF_F_GSO_UDP_L4)
/*
* If one device supports one of these features, then enable them
^ permalink raw reply related
* Re: [RFC PATCH 2/2] net: mac808211: mac802154: use lockdep_assert_in_softirq() instead own warning
From: Peter Zijlstra @ 2018-05-04 18:32 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: linux-kernel, tglx, Ingo Molnar, David S. Miller, Johannes Berg,
Alexander Aring, Stefan Schmidt, netdev, linux-wireless,
linux-wpan, Anna-Maria Gleixner
In-Reply-To: <20180504175144.12179-3-bigeasy@linutronix.de>
On Fri, May 04, 2018 at 07:51:44PM +0200, Sebastian Andrzej Siewior wrote:
> From: Anna-Maria Gleixner <anna-maria@linutronix.de>
>
> The warning in ieee802154_rx() and ieee80211_rx_napi() is there to ensure
> the softirq context for the subsequent netif_receive_skb() call.
That's not in fact what it does though; so while that might indeed be
the intent that's not what it does.
^ permalink raw reply
* Re: [RFC PATCH 2/2] net: mac808211: mac802154: use lockdep_assert_in_softirq() instead own warning
From: Sebastian Andrzej Siewior @ 2018-05-04 18:45 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-kernel, tglx, Ingo Molnar, David S. Miller, Johannes Berg,
Alexander Aring, Stefan Schmidt, netdev, linux-wireless,
linux-wpan, Anna-Maria Gleixner
In-Reply-To: <20180504183249.GU12217@hirez.programming.kicks-ass.net>
On 2018-05-04 20:32:49 [+0200], Peter Zijlstra wrote:
> On Fri, May 04, 2018 at 07:51:44PM +0200, Sebastian Andrzej Siewior wrote:
> > From: Anna-Maria Gleixner <anna-maria@linutronix.de>
> >
> > The warning in ieee802154_rx() and ieee80211_rx_napi() is there to ensure
> > the softirq context for the subsequent netif_receive_skb() call.
>
> That's not in fact what it does though; so while that might indeed be
> the intent that's not what it does.
It was introduced in commit d20ef63d3246 ("mac80211: document
ieee80211_rx() context requirement"):
mac80211: document ieee80211_rx() context requirement
ieee80211_rx() must be called with softirqs disabled
since the networking stack requires this for netif_rx()
and some code in mac80211 can assume that it can not
be processing its own tasklet and this call at the same
time.
It may be possible to remove this requirement after a
careful audit of mac80211 and doing any needed locking
improvements in it along with disabling softirqs around
netif_rx(). An alternative might be to push all packet
processing to process context in mac80211, instead of
to the tasklet, and add other synchronisation.
Sebastian
^ permalink raw reply
* Re: [RFC PATCH 2/2] net: mac808211: mac802154: use lockdep_assert_in_softirq() instead own warning
From: Peter Zijlstra @ 2018-05-04 18:51 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: linux-kernel, tglx, Ingo Molnar, David S. Miller, Johannes Berg,
Alexander Aring, Stefan Schmidt, netdev, linux-wireless,
linux-wpan, Anna-Maria Gleixner
In-Reply-To: <20180504184538.gavk7e2vtm73e32w@linutronix.de>
On Fri, May 04, 2018 at 08:45:39PM +0200, Sebastian Andrzej Siewior wrote:
> On 2018-05-04 20:32:49 [+0200], Peter Zijlstra wrote:
> > On Fri, May 04, 2018 at 07:51:44PM +0200, Sebastian Andrzej Siewior wrote:
> > > From: Anna-Maria Gleixner <anna-maria@linutronix.de>
> > >
> > > The warning in ieee802154_rx() and ieee80211_rx_napi() is there to ensure
> > > the softirq context for the subsequent netif_receive_skb() call.
> >
> > That's not in fact what it does though; so while that might indeed be
> > the intent that's not what it does.
>
> It was introduced in commit d20ef63d3246 ("mac80211: document
> ieee80211_rx() context requirement"):
>
> mac80211: document ieee80211_rx() context requirement
>
> ieee80211_rx() must be called with softirqs disabled
softirqs disabled, ack that is exactly what it checks.
But afaict the assertion you introduced tests that we are _in_ softirq
context, which is not the same.
^ permalink raw reply
* Re: [RFC PATCH 2/2] net: mac808211: mac802154: use lockdep_assert_in_softirq() instead own warning
From: Sebastian Andrzej Siewior @ 2018-05-04 19:07 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-kernel, tglx, Ingo Molnar, David S. Miller, Johannes Berg,
Alexander Aring, Stefan Schmidt, netdev, linux-wireless,
linux-wpan, Anna-Maria Gleixner
In-Reply-To: <20180504185132.GV12217@hirez.programming.kicks-ass.net>
On 2018-05-04 20:51:32 [+0200], Peter Zijlstra wrote:
> On Fri, May 04, 2018 at 08:45:39PM +0200, Sebastian Andrzej Siewior wrote:
> > On 2018-05-04 20:32:49 [+0200], Peter Zijlstra wrote:
> > > On Fri, May 04, 2018 at 07:51:44PM +0200, Sebastian Andrzej Siewior wrote:
> > > > From: Anna-Maria Gleixner <anna-maria@linutronix.de>
> > > >
> > > > The warning in ieee802154_rx() and ieee80211_rx_napi() is there to ensure
> > > > the softirq context for the subsequent netif_receive_skb() call.
> > >
> > > That's not in fact what it does though; so while that might indeed be
> > > the intent that's not what it does.
> >
> > It was introduced in commit d20ef63d3246 ("mac80211: document
> > ieee80211_rx() context requirement"):
> >
> > mac80211: document ieee80211_rx() context requirement
> >
> > ieee80211_rx() must be called with softirqs disabled
>
> softirqs disabled, ack that is exactly what it checks.
>
> But afaict the assertion you introduced tests that we are _in_ softirq
> context, which is not the same.
indeed, now it clicked. Given what I wrote in the cover letter would you
be in favour of (a proper) lockdep_assert_BH_disabled() or the cheaper
local_bh_enable() (assuming the network folks don't mind the cheaper
version)?
Sebastian
^ permalink raw reply
* Re: [PATCH] net/mlx5: fix spelling mistake: "modfiy" -> "modify"
From: Saeed Mahameed @ 2018-05-04 19:09 UTC (permalink / raw)
To: davem@davemloft.net, colin.king@canonical.com
Cc: Matan Barak, netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
linux-kernel@vger.kernel.org, leon@kernel.org,
kernel-janitors@vger.kernel.org
In-Reply-To: <20180503.144440.629738993491549851.davem@davemloft.net>
On Thu, 2018-05-03 at 14:44 -0400, David Miller wrote:
> From: Colin King <colin.king@canonical.com>
> Date: Thu, 3 May 2018 14:35:03 +0100
>
> > From: Colin Ian King <colin.king@canonical.com>
> >
> > Trivial fix to spelling mistake in netdev_warn warning message
> >
> > Signed-off-by: Colin Ian King <colin.king@canonical.com>
>
> Saeed, please send this to me in your next pull request.
>
Applied to mlx5-next, Thanks Colin and Dave !
^ permalink raw reply
* Re: [PATCH net-next v8 1/7] sched: Add Common Applications Kept Enhanced (cake) qdisc
From: Toke Høiland-Jørgensen @ 2018-05-04 19:10 UTC (permalink / raw)
To: Cong Wang; +Cc: Linux Kernel Network Developers, Cake List
In-Reply-To: <CAM_iQpUEaYN+ziMF1CUaGkYR-sTH1hc9vPdQ5RQLvSMZJGdrVg@mail.gmail.com>
Thank you for the review! A few comments below, I'll fix the rest.
> [...]
>
> So sch_cake doesn't accept normal tc filters? Is this intentional?
> If so, why?
For two reasons:
- The two-level scheduling used in CAKE (tins / diffserv classes, and
flow hashing) does not map in an obvious way to the classification
index of tc filters.
- No one has asked for it. We have done our best to accommodate the
features people want in a home router qdisc directly in CAKE, and the
ability to integrate tc filters has never been requested.
>> +static u16 quantum_div[CAKE_QUEUES + 1] = {0};
>> +
>> +#define REC_INV_SQRT_CACHE (16)
>> +static u32 cobalt_rec_inv_sqrt_cache[REC_INV_SQRT_CACHE] = {0};
>> +
>> +/* http://en.wikipedia.org/wiki/Methods_of_computing_square_roots
>> + * new_invsqrt = (invsqrt / 2) * (3 - count * invsqrt^2)
>> + *
>> + * Here, invsqrt is a fixed point number (< 1.0), 32bit mantissa, aka Q0.32
>> + */
>> +
>> +static void cobalt_newton_step(struct cobalt_vars *vars)
>> +{
>> + u32 invsqrt = vars->rec_inv_sqrt;
>> + u32 invsqrt2 = ((u64)invsqrt * invsqrt) >> 32;
>> + u64 val = (3LL << 32) - ((u64)vars->count * invsqrt2);
>> +
>> + val >>= 2; /* avoid overflow in following multiply */
>> + val = (val * invsqrt) >> (32 - 2 + 1);
>> +
>> + vars->rec_inv_sqrt = val;
>> +}
>> +
>> +static void cobalt_invsqrt(struct cobalt_vars *vars)
>> +{
>> + if (vars->count < REC_INV_SQRT_CACHE)
>> + vars->rec_inv_sqrt = cobalt_rec_inv_sqrt_cache[vars->count];
>> + else
>> + cobalt_newton_step(vars);
>> +}
>
> Looks pretty much duplicated with codel...
Cobalt is derived from CoDel, and so naturally shares some features with
it. However, it is quite different in other respects, so we can't just
use the existing CoDel code for the parts that are similar. We don't
feel quite confident enough in Cobalt (yet) to propose it replace CoDel
everywhere else in the kernel; so we have elected to keep it internal to
CAKE instead.
>> [...]
>>
>> +static int cake_init(struct Qdisc *sch, struct nlattr *opt,
>> + struct netlink_ext_ack *extack)
>> +{
>> + struct cake_sched_data *q = qdisc_priv(sch);
>> + int i, j;
>> +
>> + sch->limit = 10240;
>> + q->tin_mode = CAKE_DIFFSERV_BESTEFFORT;
>> + q->flow_mode = CAKE_FLOW_TRIPLE;
>> +
>> + q->rate_bps = 0; /* unlimited by default */
>> +
>> + q->interval = 100000; /* 100ms default */
>> + q->target = 5000; /* 5ms: codel RFC argues
>> + * for 5 to 10% of interval
>> + */
>> +
>> + q->cur_tin = 0;
>> + q->cur_flow = 0;
>> +
>> + if (opt) {
>> + int err = cake_change(sch, opt, extack);
>> +
>> + if (err)
>> + return err;
>
>
> Not sure if you really want to reallocate q->tines below for this
> case.
I'm not sure what you mean here? If there's an error we return it and
the qdisc is not created. If there's not, we allocate and on subsequent
changes cake_change() will be called directly, or? Can the init function
ever be called again during the lifetime of the qdisc?
-Toke
^ permalink raw reply
* Re: [PATCH v5 0/6] firmware_loader: cleanups for v4.18
From: Krzysztof Halasa @ 2018-05-04 19:17 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: gregkh, akpm, keescook, josh, teg, wagi, hdegoede, andresx7,
zohar, kubakici, shuah, mfuzzey, dhowells, pali.rohar, tiwai,
kvalo, arend.vanspriel, zajec5, nbroeking, markivx, broonie,
dmitry.torokhov, dwmw2, torvalds, Abhay_Salunke, bjorn.andersson,
jewalt, oneukum, cantabile.desu, ast, hare, jejb, martin.petersen,
davem, maco, arve, tkjos
In-Reply-To: <20180504174356.13227-1-mcgrof@kernel.org>
"Luis R. Rodriguez" <mcgrof@kernel.org> writes:
> * CONFIG_WANXL --> CONFIG_WANXL_BUILD_FIRMWARE
> * CONFIG_SCSI_AIC79XX --> CONFIG_AIC79XX_BUILD_FIRMWARE
>
> To this day both of these drivers are building driver *firmwares* when
> the option CONFIG_PREVENT_FIRMWARE_BUILD is disabled, and they don't
> even make use of the firmware API at all.
Don't know for sure about Adaptec, but wanXL firmware fits every
definition of "stable". BTW it's a 1997 or so early PCI card, built
around the PLX PCI9060 bus mastering PCI bridge and Motorola 68360
(the original QUICC) processor. Maximum bit rate of 2 Mb/s on each sync
serial port.
It's more about delivering the .S source for the firmware, I guess.
Nobody is expected to build it. The fw is about 2.5 KB and is directly
linked with the driver.
--
Krzysztof Halasa
^ permalink raw reply
* Re: [PATCH v2 bpf-next 0/3] bpf: cleanups on managing subprog information
From: Daniel Borkmann @ 2018-05-04 19:20 UTC (permalink / raw)
To: Jiong Wang, alexei.starovoitov, borkmann
Cc: john.fastabend, ecree, netdev, oss-drivers
In-Reply-To: <1525292239-1309-1-git-send-email-jiong.wang@netronome.com>
On 05/02/2018 10:17 PM, Jiong Wang wrote:
> This patch set clean up some code logic related with managing subprog
> information.
>
> Part of the set are inspried by Edwin's code in his RFC:
>
> "bpf/verifier: subprog/func_call simplifications"
>
> but with clearer separation so it could be easier to review.
>
> - Path 1 unifies main prog and subprogs. All of them are registered in
> env->subprog_starts.
>
> - After patch 1, it is clear that subprog_starts and subprog_stack_depth
> could be merged as both of them now have main and subprog unified.
> Patch 2 therefore does the merge, all subprog information are centred
> at bpf_subprog_info.
>
> - Patch 3 goes further to introduce a new fake "exit" subprog which
> serves as an ending marker to the subprog list. We could then turn the
> following code snippets across verifier:
>
> if (env->subprog_cnt == cur_subprog + 1)
> subprog_end = insn_cnt;
> else
> subprog_end = env->subprog_info[cur_subprog + 1].start;
>
> into:
> subprog_end = env->subprog_info[cur_subprog + 1].start;
>
> There is no functional change by this patch set.
> No bpf selftest (both non-jit and jit) regression found after this set.
>
> v2:
> - fixed adjust_subprog_starts to also update fake "exit" subprog start.
> - for John's suggestion on renaming subprog to prog, I could work on
> a follow-up patch if it is recognized as worth the change.
>
> Jiong Wang (3):
> bpf: unify main prog and subprog
> bpf: centre subprog information fields
> bpf: add faked "ending" subprog
>
> include/linux/bpf_verifier.h | 9 ++--
> kernel/bpf/verifier.c | 121 ++++++++++++++++++++++---------------------
> 2 files changed, 67 insertions(+), 63 deletions(-)
>
LGTM, applied to bpf-next, thanks Jiong!
^ permalink raw reply
* Re: [PATCH 04/15] media: pxa_camera: remove the dmaengine compat need
From: Mauro Carvalho Chehab @ 2018-05-04 19:29 UTC (permalink / raw)
To: Hans Verkuil
Cc: Ulf Hansson, alsa-devel, Takashi Iwai, linux-ide, Pravin Shedge,
netdev, linux-mtd, Laurent Pinchart, Robert Jarzmik, devel,
Boris Brezillon, dmaengine, Vinod Koul, Richard Weinberger,
Robert Jarzmik, Marek Vasut, Ezequiel Garcia, linux-media,
Samuel Ortiz, Arnd Bergmann, Bartlomiej Zolnierkiewicz,
Haojian Zhuang, Flavio Ceolin, Mark
In-Reply-To: <89f3e97c-08a4-33b6-8fd3-0c1b4dea2065@xs4all.nl>
Em Sun, 22 Apr 2018 13:06:12 +0200
Hans Verkuil <hverkuil@xs4all.nl> escreveu:
> On 04/02/2018 04:26 PM, Robert Jarzmik wrote:
> > From: Robert Jarzmik <robert.jarzmik@renault.com>
> >
> > As the pxa architecture switched towards the dmaengine slave map, the
> > old compatibility mechanism to acquire the dma requestor line number and
> > priority are not needed anymore.
> >
> > This patch simplifies the dma resource acquisition, using the more
> > generic function dma_request_slave_channel().
> >
> > Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
>
> Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
I'm assuming that you'll be applying it together with other PXA patches.
So:
Acked-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Regards,
Mauro
>
> Regards,
>
> Hans
>
> > ---
> > drivers/media/platform/pxa_camera.c | 22 +++-------------------
> > 1 file changed, 3 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/media/platform/pxa_camera.c b/drivers/media/platform/pxa_camera.c
> > index c71a00736541..4c82d1880753 100644
> > --- a/drivers/media/platform/pxa_camera.c
> > +++ b/drivers/media/platform/pxa_camera.c
> > @@ -2357,8 +2357,6 @@ static int pxa_camera_probe(struct platform_device *pdev)
> > .src_maxburst = 8,
> > .direction = DMA_DEV_TO_MEM,
> > };
> > - dma_cap_mask_t mask;
> > - struct pxad_param params;
> > char clk_name[V4L2_CLK_NAME_SIZE];
> > int irq;
> > int err = 0, i;
> > @@ -2432,34 +2430,20 @@ static int pxa_camera_probe(struct platform_device *pdev)
> > pcdev->base = base;
> >
> > /* request dma */
> > - dma_cap_zero(mask);
> > - dma_cap_set(DMA_SLAVE, mask);
> > - dma_cap_set(DMA_PRIVATE, mask);
> > -
> > - params.prio = 0;
> > - params.drcmr = 68;
> > - pcdev->dma_chans[0] =
> > - dma_request_slave_channel_compat(mask, pxad_filter_fn,
> > - ¶ms, &pdev->dev, "CI_Y");
> > + pcdev->dma_chans[0] = dma_request_slave_channel(&pdev->dev, "CI_Y");
> > if (!pcdev->dma_chans[0]) {
> > dev_err(&pdev->dev, "Can't request DMA for Y\n");
> > return -ENODEV;
> > }
> >
> > - params.drcmr = 69;
> > - pcdev->dma_chans[1] =
> > - dma_request_slave_channel_compat(mask, pxad_filter_fn,
> > - ¶ms, &pdev->dev, "CI_U");
> > + pcdev->dma_chans[1] = dma_request_slave_channel(&pdev->dev, "CI_U");
> > if (!pcdev->dma_chans[1]) {
> > dev_err(&pdev->dev, "Can't request DMA for Y\n");
> > err = -ENODEV;
> > goto exit_free_dma_y;
> > }
> >
> > - params.drcmr = 70;
> > - pcdev->dma_chans[2] =
> > - dma_request_slave_channel_compat(mask, pxad_filter_fn,
> > - ¶ms, &pdev->dev, "CI_V");
> > + pcdev->dma_chans[2] = dma_request_slave_channel(&pdev->dev, "CI_V");
> > if (!pcdev->dma_chans[2]) {
> > dev_err(&pdev->dev, "Can't request DMA for V\n");
> > err = -ENODEV;
> >
>
Thanks,
Mauro
^ permalink raw reply
* Re: Hello My Dear Friend!!!!
From: SISTER DOROTHY KENT @ 2018-05-04 19:39 UTC (permalink / raw)
Hello Dear
I am Sister Dorothy Kent I really need your assistance to help me discuss a project .
Thanks,
Sister Dorothy Kent
^ permalink raw reply
* Re: [PATCH v2 0/4] Introduce LSM-hook for socketpair(2)
From: James Morris @ 2018-05-04 19:51 UTC (permalink / raw)
To: David Herrmann
Cc: linux-kernel, Paul Moore, teg, Stephen Smalley, selinux,
linux-security-module, Eric Paris, serge, Casey Schaufler, davem,
netdev
In-Reply-To: <20180504142822.15233-1-dh.herrmann@gmail.com>
On Fri, 4 May 2018, David Herrmann wrote:
> Hi
>
> This is v2 of the socketpair(2) LSM hook introduction.
Thanks, all applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-general
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH v2 net-next 1/4] umh: introduce fork_usermode_blob() helper
From: Luis R. Rodriguez @ 2018-05-04 19:56 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: davem, daniel, torvalds, gregkh, luto, netdev, linux-kernel,
kernel-team, Al Viro, David Howells, Mimi Zohar, Kees Cook,
Andrew Morton, Dominik Brodowski, Hugh Dickins, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, David Airlie, Rafael J. Wysocki,
Luis R. Rodriguez, Linux FS Devel
In-Reply-To: <20180503043604.1604587-2-ast@kernel.org>
What a mighty short list of reviewers. Adding some more. My review below.
I'd appreciate a Cc on future versions of these patches.
On Wed, May 02, 2018 at 09:36:01PM -0700, Alexei Starovoitov wrote:
> Introduce helper:
> int fork_usermode_blob(void *data, size_t len, struct umh_info *info);
> struct umh_info {
> struct file *pipe_to_umh;
> struct file *pipe_from_umh;
> pid_t pid;
> };
>
> that GPLed kernel modules (signed or unsigned) can use it to execute part
> of its own data as swappable user mode process.
>
> The kernel will do:
> - mount "tmpfs"
Actually its a *shared* vfsmount tmpfs for all umh blobs.
> - allocate a unique file in tmpfs
> - populate that file with [data, data + len] bytes
> - user-mode-helper code will do_execve that file and, before the process
> starts, the kernel will create two unix pipes for bidirectional
> communication between kernel module and umh
> - close tmpfs file, effectively deleting it
> - the fork_usermode_blob will return zero on success and populate
> 'struct umh_info' with two unix pipes and the pid of the user process
But since its using UMH_WAIT_EXEC, all we can guarantee currently is the
inception point was intended, well though out, and will run, but the return
value in no way reflects the success or not of the execution. More below.
> As the first step in the development of the bpfilter project
> the fork_usermode_blob() helper is introduced to allow user mode code
> to be invoked from a kernel module. The idea is that user mode code plus
> normal kernel module code are built as part of the kernel build
> and installed as traditional kernel module into distro specified location,
> such that from a distribution point of view, there is
> no difference between regular kernel modules and kernel modules + umh code.
> Such modules can be signed, modprobed, rmmod, etc. The use of this new helper
> by a kernel module doesn't make it any special from kernel and user space
> tooling point of view.
>
> Such approach enables kernel to delegate functionality traditionally done
> by the kernel modules into the user space processes (either root or !root) and
> reduces security attack surface of the new code. The buggy umh code would crash
> the user process, but not the kernel. Another advantage is that umh code
> of the kernel module can be debugged and tested out of user space
> (e.g. opening the possibility to run clang sanitizers, fuzzers or
> user space test suites on the umh code).
> In case of the bpfilter project such architecture allows complex control plane
> to be done in the user space while bpf based data plane stays in the kernel.
>
> Since umh can crash, can be oom-ed by the kernel, killed by the admin,
> the kernel module that uses them (like bpfilter) needs to manage life
> time of umh on its own via two unix pipes and the pid of umh.
>
> The exit code of such kernel module should kill the umh it started,
> so that rmmod of the kernel module will cleanup the corresponding umh.
> Just like if the kernel module does kmalloc() it should kfree() it in the exit code.
>
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
> ---
> fs/exec.c | 38 ++++++++---
> include/linux/binfmts.h | 1 +
> include/linux/umh.h | 12 ++++
> kernel/umh.c | 176 +++++++++++++++++++++++++++++++++++++++++++++++-
> 4 files changed, 215 insertions(+), 12 deletions(-)
>
> diff --git a/fs/exec.c b/fs/exec.c
> index 183059c427b9..30a36c2a39bf 100644
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -1706,14 +1706,13 @@ static int exec_binprm(struct linux_binprm *bprm)
> /*
> * sys_execve() executes a new program.
> */
> -static int do_execveat_common(int fd, struct filename *filename,
> - struct user_arg_ptr argv,
> - struct user_arg_ptr envp,
> - int flags)
> +static int __do_execve_file(int fd, struct filename *filename,
> + struct user_arg_ptr argv,
> + struct user_arg_ptr envp,
> + int flags, struct file *file)
> {
> char *pathbuf = NULL;
> struct linux_binprm *bprm;
> - struct file *file;
> struct files_struct *displaced;
> int retval;
Keeping in mind a fuzzer...
Note, right below this, and not shown here in the hunk, is:
if (IS_ERR(filename))
return PTR_ERR(filename)
>
> @@ -1752,7 +1751,8 @@ static int do_execveat_common(int fd, struct filename *filename,
> check_unsafe_exec(bprm);
> current->in_execve = 1;
>
> - file = do_open_execat(fd, filename, flags);
> + if (!file)
> + file = do_open_execat(fd, filename, flags);
Here we now seem to allow !file and open the file with the passed fd as in
the old days. This is an expected change.
> retval = PTR_ERR(file);
> if (IS_ERR(file))
> goto out_unmark;
> @@ -1760,7 +1760,9 @@ static int do_execveat_common(int fd, struct filename *filename,
> sched_exec();
>
> bprm->file = file;
> - if (fd == AT_FDCWD || filename->name[0] == '/') {
> + if (!filename) {
If anything shouldn't this be:
if (IS_ERR(filename))
But, wouldn't the above first branch in the routine catch this?
> + bprm->filename = "none";
Given this seems like a desirable branch which was tested, wonder how this
ever got set if the above branch in the first hunk I noted hit true?
In any case, we seem to have two cases, can we rule out the exact requirements
at the top so we can bail out with an error code if one or the other way to
call this function does not align with expectations?
> + } else if (fd == AT_FDCWD || filename->name[0] == '/') {
> bprm->filename = filename->name;
> } else {
> if (filename->name[0] == '\0')
> @@ -1826,7 +1828,8 @@ static int do_execveat_common(int fd, struct filename *filename,
> task_numa_free(current);
> free_bprm(bprm);
> kfree(pathbuf);
> - putname(filename);
> + if (filename)
> + putname(filename);
> if (displaced)
> put_files_struct(displaced);
> return retval;
> @@ -1849,10 +1852,27 @@ static int do_execveat_common(int fd, struct filename *filename,
> if (displaced)
> reset_files_struct(displaced);
> out_ret:
> - putname(filename);
> + if (filename)
> + putname(filename);
> return retval;
> }
>
> +static int do_execveat_common(int fd, struct filename *filename,
Further signs the filename is now optional. But I don't understand how these
branches ever be true, but perhaps I'm missing something?
> + struct user_arg_ptr argv,
> + struct user_arg_ptr envp,
> + int flags)
> +{
> + return __do_execve_file(fd, filename, argv, envp, flags, NULL);
> +}
> +
> +int do_execve_file(struct file *file, void *__argv, void *__envp)
> +{
> + struct user_arg_ptr argv = { .ptr.native = __argv };
> + struct user_arg_ptr envp = { .ptr.native = __envp };
> +
> + return __do_execve_file(AT_FDCWD, NULL, argv, envp, 0, file);
> +}
Or maybe do the semantics expectations checks here, so we don't clutter
do_execveat_common() with them?
> +
> int do_execve(struct filename *filename,
> const char __user *const __user *__argv,
> const char __user *const __user *__envp)
> diff --git a/include/linux/binfmts.h b/include/linux/binfmts.h
> index 4955e0863b83..c05f24fac4f6 100644
> --- a/include/linux/binfmts.h
> +++ b/include/linux/binfmts.h
> @@ -150,5 +150,6 @@ extern int do_execveat(int, struct filename *,
> const char __user * const __user *,
> const char __user * const __user *,
> int);
> +int do_execve_file(struct file *file, void *__argv, void *__envp);
>
> #endif /* _LINUX_BINFMTS_H */
> diff --git a/include/linux/umh.h b/include/linux/umh.h
> index 244aff638220..5c812acbb80a 100644
> --- a/include/linux/umh.h
> +++ b/include/linux/umh.h
> @@ -22,8 +22,10 @@ struct subprocess_info {
> const char *path;
> char **argv;
> char **envp;
> + struct file *file;
> int wait;
> int retval;
> + pid_t pid;
> int (*init)(struct subprocess_info *info, struct cred *new);
> void (*cleanup)(struct subprocess_info *info);
> void *data;
While at it, can you kdocify struct subprocess_info and add new docs for at
least these two entires you are adding ?
> @@ -38,6 +40,16 @@ call_usermodehelper_setup(const char *path, char **argv, char **envp,
> int (*init)(struct subprocess_info *info, struct cred *new),
> void (*cleanup)(struct subprocess_info *), void *data);
>
> +struct subprocess_info *call_usermodehelper_setup_file(struct file *file,
> + int (*init)(struct subprocess_info *info, struct cred *new),
> + void (*cleanup)(struct subprocess_info *), void *data);
Likewise but on the umc.c file.
> +struct umh_info {
> + struct file *pipe_to_umh;
> + struct file *pipe_from_umh;
> + pid_t pid;
> +};
Likewise.
> +int fork_usermode_blob(void *data, size_t len, struct umh_info *info);
Likewise but on the umc.c files.
> +
> extern int
> call_usermodehelper_exec(struct subprocess_info *info, int wait);
>
> diff --git a/kernel/umh.c b/kernel/umh.c
> index f76b3ff876cf..c3f418d7d51a 100644
> --- a/kernel/umh.c
> +++ b/kernel/umh.c
> @@ -25,6 +25,8 @@
> #include <linux/ptrace.h>
> #include <linux/async.h>
> #include <linux/uaccess.h>
> +#include <linux/shmem_fs.h>
> +#include <linux/pipe_fs_i.h>
>
> #include <trace/events/module.h>
>
> @@ -97,9 +99,13 @@ static int call_usermodehelper_exec_async(void *data)
>
> commit_creds(new);
>
> - retval = do_execve(getname_kernel(sub_info->path),
> - (const char __user *const __user *)sub_info->argv,
> - (const char __user *const __user *)sub_info->envp);
> + if (sub_info->file)
> + retval = do_execve_file(sub_info->file,
> + sub_info->argv, sub_info->envp);
> + else
> + retval = do_execve(getname_kernel(sub_info->path),
> + (const char __user *const __user *)sub_info->argv,
> + (const char __user *const __user *)sub_info->envp);
> out:
> sub_info->retval = retval;
> /*
> @@ -185,6 +191,8 @@ static void call_usermodehelper_exec_work(struct work_struct *work)
> if (pid < 0) {
> sub_info->retval = pid;
> umh_complete(sub_info);
> + } else {
> + sub_info->pid = pid;
> }
> }
> }
> @@ -393,6 +401,168 @@ struct subprocess_info *call_usermodehelper_setup(const char *path, char **argv,
> }
> EXPORT_SYMBOL(call_usermodehelper_setup);
>
> +struct subprocess_info *call_usermodehelper_setup_file(struct file *file,
> + int (*init)(struct subprocess_info *info, struct cred *new),
> + void (*cleanup)(struct subprocess_info *info), void *data)
Should be static, no other users outside of this file.
Please use umh_setup_file().
> +{
> + struct subprocess_info *sub_info;
Considering a possible fuzzer triggering random data we should probably
return NULL early and avoid the kzalloc if:
if (!file || !init || !cleanup)
return NULL;
Is data optional? The kdoc could clarify this.
> +
> + sub_info = kzalloc(sizeof(struct subprocess_info), GFP_KERNEL);
> + if (!sub_info)
> + return NULL;
> +
> + INIT_WORK(&sub_info->work, call_usermodehelper_exec_work);
> + sub_info->path = "none";
> + sub_info->file = file;
> + sub_info->init = init;
> + sub_info->cleanup = cleanup;
> + sub_info->data = data;
> + return sub_info;
> +}
> +
> +static struct vfsmount *umh_fs;
> +
> +static int init_tmpfs(void)
Please use umh_init_tmpfs(). Also see init/main.c do_basic_setup() which calls
usermodehelper_enable() prior to do_initcalls(). Now, fortunately TMPFS is only
bool, saving us from some races and we do call tmpfs's init first shmem_init():
static void __init do_basic_setup(void)
{
cpuset_init_smp();
shmem_init();
driver_init();
init_irq_proc();
do_ctors();
usermodehelper_enable();
do_initcalls();
}
But it also means we're enabling your new call call fork_usermode_blob() on
early init code even if we're not setup. Since this umh tmpfs vfsmount is
shared I'd say just call this init right before usermodehelper_enable()
on do_basic_setup().
> +{
> + struct file_system_type *type;
> +
> + if (umh_fs)
> + return 0;
> + type = get_fs_type("tmpfs");
> + if (!type)
> + return -ENODEV;
> + umh_fs = kern_mount(type);
> + if (IS_ERR(umh_fs)) {
> + int err = PTR_ERR(umh_fs);
> +
> + put_filesystem(type);
> + umh_fs = NULL;
> + return err;
> + }
> + return 0;
> +}
> +
> +static int alloc_tmpfs_file(size_t size, struct file **filp)
Please use umh_alloc_tmpfs_file()
> +{
> + struct file *file;
> + int err;
> +
> + err = init_tmpfs();
> + if (err)
> + return err;
> + file = shmem_file_setup_with_mnt(umh_fs, "umh", size, VM_NORESERVE);
> + if (IS_ERR(file))
> + return PTR_ERR(file);
> + *filp = file;
> + return 0;
> +}
> +
> +static int populate_file(struct file *file, const void *data, size_t size)
Please use umh_populate_file()
> +{
> + size_t offset = 0;
> + int err;
> +
> + do {
> + unsigned int len = min_t(typeof(size), size, PAGE_SIZE);
> + struct page *page;
> + void *pgdata, *vaddr;
> +
> + err = pagecache_write_begin(file, file->f_mapping, offset, len,
> + 0, &page, &pgdata);
> + if (err < 0)
> + goto fail;
> +
> + vaddr = kmap(page);
> + memcpy(vaddr, data, len);
> + kunmap(page);
> +
> + err = pagecache_write_end(file, file->f_mapping, offset, len,
> + len, page, pgdata);
> + if (err < 0)
> + goto fail;
> +
> + size -= len;
> + data += len;
> + offset += len;
> + } while (size);
Character for character, this looks like a wonderful copy and paste from
i915_gem_object_create_from_data()'s own loop which does the same exact
thing. Perhaps its time for a helper on mm/filemap.c with an export so
if a bug is fixed in one place its fixed in both places.
> + return 0;
> +fail:
> + return err;
> +}
> +
> +static int umh_pipe_setup(struct subprocess_info *info, struct cred *new)
The function name umh_pipe_setup() is also used on fs/coredump.c, with the same
prototype, perhaps rename that before we take this on, even if both are static.
> +{
> + struct umh_info *umh_info = info->data;
> + struct file *from_umh[2];
> + struct file *to_umh[2];
> + int err;
> +
> + /* create pipe to send data to umh */
> + err = create_pipe_files(to_umh, 0);
> + if (err)
> + return err;
> + err = replace_fd(0, to_umh[0], 0);
> + fput(to_umh[0]);
> + if (err < 0) {
> + fput(to_umh[1]);
> + return err;
> + }
> +
> + /* create pipe to receive data from umh */
> + err = create_pipe_files(from_umh, 0);
> + if (err) {
> + fput(to_umh[1]);
> + replace_fd(0, NULL, 0);
> + return err;
> + }
> + err = replace_fd(1, from_umh[1], 0);
> + fput(from_umh[1]);
> + if (err < 0) {
> + fput(to_umh[1]);
> + replace_fd(0, NULL, 0);
> + fput(from_umh[0]);
> + return err;
> + }
> +
> + umh_info->pipe_to_umh = to_umh[1];
> + umh_info->pipe_from_umh = from_umh[0];
> + return 0;
> +}
> +
> +static void umh_save_pid(struct subprocess_info *info)
> +{
> + struct umh_info *umh_info = info->data;
> +
> + umh_info->pid = info->pid;
> +}
> +
> +int fork_usermode_blob(void *data, size_t len, struct umh_info *info)
Please use umh_fork_blob()
> +{
> + struct subprocess_info *sub_info;
> + struct file *file = NULL;
> + int err;
> +
> + err = alloc_tmpfs_file(len, &file);
> + if (err)
> + return err;
> +
> + err = populate_file(file, data, len);
> + if (err)
> + goto out;
> +
> + err = -ENOMEM;
> + sub_info = call_usermodehelper_setup_file(file, umh_pipe_setup,
> + umh_save_pid, info);
> + if (!sub_info)
> + goto out;
> +
> + err = call_usermodehelper_exec(sub_info, UMH_WAIT_EXEC);
Alright, neat, so to be clear, we're just glad to try inception, we have no
clue or idea what the real return value would be, its up to the caller to track
the progress somehow?
Can you add a kdoc entry for this and clarify requirements?
Also, can you extend lib/test_kmod.c with a test case for this with its own
demo and try to blow it up?
I hadn't tried suspend/resume during a kmod test, but since we're using a
kernel_thread() I wouldn't be surprised if we barf while stress testing the
module loader. Its surely a corner case, but better mention that now than cry
later if we get heavy umh modules and all of a sudden we start using this for
whatever reason close to suspend.
Luis
> +out:
> + fput(file);
> + return err;
> +}
> +EXPORT_SYMBOL_GPL(fork_usermode_blob);
> +
> /**
> * call_usermodehelper_exec - start a usermode application
> * @sub_info: information about the subprocessa
> --
> 2.9.5
--
Do not panic
^ permalink raw reply
* Re: [PATCH v5 0/6] firmware_loader: cleanups for v4.18
From: Luis R. Rodriguez @ 2018-05-04 19:58 UTC (permalink / raw)
To: Krzysztof Halasa
Cc: Luis R. Rodriguez, gregkh, akpm, keescook, josh, teg, wagi,
hdegoede, andresx7, zohar, kubakici, shuah, mfuzzey, dhowells,
pali.rohar, tiwai, kvalo, arend.vanspriel, zajec5, nbroeking,
markivx, broonie, dmitry.torokhov, dwmw2, torvalds, Abhay_Salunke,
bjorn.andersson, jewalt, oneukum, cantabile.desu, ast, hare, jejb,
martin.petersen, davem, maco
In-Reply-To: <m3lgczcjt7.fsf@pm.waw.pl>
On Fri, May 04, 2018 at 09:17:08PM +0200, Krzysztof Halasa wrote:
> "Luis R. Rodriguez" <mcgrof@kernel.org> writes:
>
> > * CONFIG_WANXL --> CONFIG_WANXL_BUILD_FIRMWARE
> > * CONFIG_SCSI_AIC79XX --> CONFIG_AIC79XX_BUILD_FIRMWARE
> >
> > To this day both of these drivers are building driver *firmwares* when
> > the option CONFIG_PREVENT_FIRMWARE_BUILD is disabled, and they don't
> > even make use of the firmware API at all.
>
> Don't know for sure about Adaptec, but wanXL firmware fits every
> definition of "stable". BTW it's a 1997 or so early PCI card, built
> around the PLX PCI9060 bus mastering PCI bridge and Motorola 68360
> (the original QUICC) processor. Maximum bit rate of 2 Mb/s on each sync
> serial port.
So we can nuke CONFIG_WANXL_BUILD_FIRMWARE now?
> It's more about delivering the .S source for the firmware, I guess.
> Nobody is expected to build it. The fw is about 2.5 KB and is directly
> linked with the driver.
:P Future work I guess would be to just use the firmware API and stuff
it into linux-firmware?
Luis
^ permalink raw reply
* Re: [net-next PATCH v2 2/8] udp: Verify that pulling UDP header in GSO segmentation doesn't fail
From: Eric Dumazet @ 2018-05-04 20:07 UTC (permalink / raw)
To: Alexander Duyck, netdev, willemb, davem
In-Reply-To: <20180504182857.5194.45504.stgit@localhost.localdomain>
On 05/04/2018 11:29 AM, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> We should verify that we can pull the UDP header before we attempt to do
> so. Otherwise if this fails we have no way of knowing and GSO will not work
> correctly.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> ---
Reviewed-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [net-next PATCH v2 3/8] udp: Do not pass MSS as parameter to GSO segmentation
From: Eric Dumazet @ 2018-05-04 20:08 UTC (permalink / raw)
To: Alexander Duyck, netdev, willemb, davem
In-Reply-To: <20180504182941.5194.49667.stgit@localhost.localdomain>
On 05/04/2018 11:29 AM, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> There is no point in passing MSS as a parameter for for the GSO
> segmentation call as it is already available via the shared info for the
> skb itself.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> ---
Reviewed-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [RFC PATCH 2/2] net: mac808211: mac802154: use lockdep_assert_in_softirq() instead own warning
From: Peter Zijlstra @ 2018-05-04 20:09 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: linux-kernel, tglx, Ingo Molnar, David S. Miller, Johannes Berg,
Alexander Aring, Stefan Schmidt, netdev, linux-wireless,
linux-wpan, Anna-Maria Gleixner
In-Reply-To: <20180504190735.izmzibhb66gjb5wr@linutronix.de>
On Fri, May 04, 2018 at 09:07:35PM +0200, Sebastian Andrzej Siewior wrote:
> On 2018-05-04 20:51:32 [+0200], Peter Zijlstra wrote:
> > softirqs disabled, ack that is exactly what it checks.
> >
> > But afaict the assertion you introduced tests that we are _in_ softirq
> > context, which is not the same.
>
> indeed, now it clicked. Given what I wrote in the cover letter would you
> be in favour of (a proper) lockdep_assert_BH_disabled() or the cheaper
> local_bh_enable() (assuming the network folks don't mind the cheaper
> version)?
Depends a bit on what the code wants I suppose. If the code is in fact
fine with the stronger in-softirq assertion, that'd be best. Otherwise I
don't object to a lockdep_assert_bh_disabled() to accompany the
lockdep_assert_irq_disabled() we already have either.
^ permalink raw reply
* Product Inquiry
From: Gerhard Kahmann @ 2018-05-05 3:17 UTC (permalink / raw)
?Dear Sir,
We recently visited your website, we were recommended by one of your customer and we are interested in your models, We will like to place an order from the list of your products. However, we would like to see your company's latest catalogs with the; minimum order quantity, delivery time/FOB, payment terms etc. Official order placement will follow as soon as possible.
Awaiting your prompt reply
Best Regards
Gerhard Kahmann
Purchasing Dept
*****************************
^ 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