* Re: [PATCH net] Revert "netfilter: conntrack: fix race in __nf_conntrack_confirm against get_next_corpse"
From: David Miller @ 2014-11-25 20:00 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev, brouer
In-Reply-To: <1416941687-25471-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Tue, 25 Nov 2014 19:54:47 +0100
> This reverts commit 5195c14c8b27cc0b18220ddbf0e5ad3328a04187.
>
> If the conntrack clashes with an existing one, it is left out of
> the unconfirmed list, thus, crashing when dropping the packet and
> releasing the conntrack since golden rule is that conntracks are
> always placed in any of the existing lists for traceability reasons.
>
> Reported-by: Daniel Borkmann <dborkman@redhat.com>
> Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=88841
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
> ---
> Hi David,
>
> Could you manually apply this to your net tree? We have a better
> candidate fix to replace this broken patch that I will pass to you
> once it gets sufficient testing.
Done, thanks Pablo.
^ permalink raw reply
* Re: [PATCH] tg3: fix ring init when there are more TX than RX channels
From: cascardo @ 2014-11-25 19:57 UTC (permalink / raw)
To: David Miller; +Cc: netdev, prashant, mchan
In-Reply-To: <20141125.143352.669361329120151757.davem@davemloft.net>
On Tue, Nov 25, 2014 at 02:33:52PM -0500, David Miller wrote:
> From: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
> Date: Tue, 25 Nov 2014 14:21:11 -0200
>
> > @@ -8563,7 +8563,8 @@ static int tg3_init_rings(struct tg3 *tp)
> > if (tnapi->rx_rcb)
> > memset(tnapi->rx_rcb, 0, TG3_RX_RCB_RING_BYTES(tp));
> >
> > - if (tg3_rx_prodring_alloc(tp, &tnapi->prodring)) {
> > + if (tnapi->prodring.rx_std &&
> > + tg3_rx_prodring_alloc(tp, &tnapi->prodring)) {
> > tg3_free_rings(tp);
> > return -ENOMEM;
>
> Maybe a better test is "i < tp->rxq_cnt"? This is what is used in
> tg3_mem_rx_acquire() to determine if tg3_rx_prodring_init() happens.
>
Well, what we have in net-next/master does:
for (i = 0; i < limit; i++) {
struct tg3_napi *tnapi = &tp->napi[i];
if (tg3_rx_prodring_init(tp, &tnapi->prodring))
goto err_out;
where limit is:
limit = tp->rxq_cnt;
if (tg3_flag(tp, ENABLE_RSS))
limit++;
So, I thought that, instead of rewriting that same logic in
tg3_init_rings, that we should better just check that the rx_std has
been allocated, which is going to happen in tg3_rx_prodring_init.
So, the alternative would be:
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index dbb41c19..51d45aa 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -8540,7 +8540,11 @@ static void tg3_free_rings(struct tg3 *tp)
*/
static int tg3_init_rings(struct tg3 *tp)
{
- int i;
+ int i, limit;
+
+ limit = tp->rxq_cnt;
+ if (tg3_flag(tp, ENABLE_RSS))
+ limit++;
/* Free up all the SKBs. */
tg3_free_rings(tp);
@@ -8563,7 +8567,8 @@ static int tg3_init_rings(struct tg3 *tp)
if (tnapi->rx_rcb)
memset(tnapi->rx_rcb, 0, TG3_RX_RCB_RING_BYTES(tp));
- if (tg3_rx_prodring_alloc(tp, &tnapi->prodring)) {
+ if (i < limit &&
+ tg3_rx_prodring_alloc(tp, &tnapi->prodring)) {
tg3_free_rings(tp);
return -ENOMEM;
}
^ permalink raw reply related
* Re: [PATCH rfc 1/4] net-timestamp: pull headers for SOCK_STREAM
From: David Miller @ 2014-11-25 19:54 UTC (permalink / raw)
To: willemb; +Cc: netdev, luto, richardcochran
In-Reply-To: <CA+FuTSdT9=Hi7K3OnMxVRiK8PmS4=DvVqLumWx74OEz3okx23A@mail.gmail.com>
From: Willem de Bruijn <willemb@google.com>
Date: Tue, 25 Nov 2014 14:52:00 -0500
> On Tue, Nov 25, 2014 at 1:42 PM, David Miller <davem@davemloft.net> wrote:
>> From: Willem de Bruijn <willemb@google.com>
>> Date: Tue, 25 Nov 2014 12:58:03 -0500
>>
>> What's the harm in exposing the headers? Either it's harmful, and
>> therefore doing so for UDP is bad too, or it's harmless and
>
> Headers may expose information not available otherwise. I don't
> immediately see critical problems, but that does not mean that they
> might not lurk there.
>
> We so far avoid exposing the sequence number, though keeping it hidden
> is more about third parties. More in general, unprivileged processes
> may start requesting timestamps only to learn tcp state that they
> should either get from tcpinfo or cannot currently get at all, likely
> for good reason. A far-fetched example is identifying admin iptables
> tos mangling rules by reading the tos bits at the driver layer. At least
> on my machine, iptables -L is privileged.
>
>> we should probably leave it alone to not risk breaking anyone.
>
> That's fair. I sent it for rfc first for that reason. I won't resubmit
> unless more serious concerns are raised.
I just worry about the potential breakage.
Your concerns are valid... I honestly don't know what we should do here.
Both choices have merit.
^ permalink raw reply
* Re: [PATCH rfc 3/4] net-timestamp: tcp sockets return v6 errors on v6 sockets
From: Willem de Bruijn @ 2014-11-25 19:53 UTC (permalink / raw)
To: David Miller; +Cc: Network Development, Andy Lutomirski, Richard Cochran
In-Reply-To: <20141125.134152.1265765328256853180.davem@davemloft.net>
On Tue, Nov 25, 2014 at 1:41 PM, David Miller <davem@davemloft.net> wrote:
> From: Willem de Bruijn <willemb@google.com>
> Date: Tue, 25 Nov 2014 12:58:05 -0500
>
>> From: Willem de Bruijn <willemb@google.com>
>>
>> TCP timestamping introduced MSG_ERRQUEUE handling for TCP sockets.
>> It always passed errorqueue requests onto ip_recv_error, but the
>> same tcp_recvmsg code may also be called for IPv6 sockets. In that
>> case, pass to ipv6_recv_error.
>>
>> Tested by asking for PKTINFO with
>>
>> Documentation/networking/timestamping/txtimestamp -I
>>
>> Before this change, IPv6 sockets would return AF_INET/IP_PKTINFO
>> after the change, these sockets return AF_INET6/IPV6_PKTINFO
>>
>> Signed-off-by: Willem de Bruijn <willemb@google.com>
>
> This looks like a bug fix to me, and is therefore probably 'net'
> material.
Okay. I'll submit it separately to net.
^ permalink raw reply
* Re: [PATCH 1/2 3.18] rtlwifi: rtl8821ae: Fix 5G detection problem
From: John W. Linville @ 2014-11-25 19:53 UTC (permalink / raw)
To: Larry Finger
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Valerio Passini
In-Reply-To: <5474DD88.7060002-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
On Tue, Nov 25, 2014 at 01:50:32PM -0600, Larry Finger wrote:
> On 11/25/2014 12:46 PM, John W. Linville wrote:
> >On Tue, Nov 25, 2014 at 10:32:06AM -0600, Larry Finger wrote:
> >>The changes associated with moving this driver from staging to the regular
> >>tree missed one section setting the allowable rates for the 5GHz band.
> >>
> >>This patch is needed to fix the regression reported in Bug #88811
> >>(https://bugzilla.kernel.org/show_bug.cgi?id=88811).
> >>
> >>Reported-by: Valerio Passini <valerio.passini-vbqOIlEVYMdeoWH0uzbU5w@public.gmane.org>
> >>Tested-by: Valerio Passini <valerio.passini-vbqOIlEVYMdeoWH0uzbU5w@public.gmane.org>
> >>Signed-off-by: Larry Finger <Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
> >>Cc: Valerio Passini <valerio.passini-vbqOIlEVYMdeoWH0uzbU5w@public.gmane.org>
> >>---
> >> drivers/net/wireless/rtlwifi/rtl8821ae/hw.c | 5 +++--
> >> 1 file changed, 3 insertions(+), 2 deletions(-)
> >>
> >>diff --git a/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c b/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c
> >>index 310d316..18f34f7 100644
> >>--- a/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c
> >>+++ b/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c
> >>@@ -3672,8 +3672,9 @@ static void rtl8821ae_update_hal_rate_mask(struct ieee80211_hw *hw,
> >> mac->opmode == NL80211_IFTYPE_ADHOC)
> >> macid = sta->aid + 1;
> >> if (wirelessmode == WIRELESS_MODE_N_5G ||
> >>- wirelessmode == WIRELESS_MODE_AC_5G)
> >>- ratr_bitmap = sta->supp_rates[NL80211_BAND_5GHZ];
> >>+ wirelessmode == WIRELESS_MODE_AC_5G ||
> >>+ wirelessmode == WIRELESS_MODE_A)
> >>+ ratr_bitmap = (sta->supp_rates[NL80211_BAND_5GHZ])<<4;
> >
> >The parenthesis seem superfluous. How about this line instead?
> >
> >+ ratr_bitmap = sta->supp_rates[NL80211_BAND_5GHZ] << 4;
> >
> >> else
> >> ratr_bitmap = sta->supp_rates[NL80211_BAND_2GHZ];
>
> Good idea. V2 is on its way.
No need -- I merged it with my version of the line. :-)
John
--
John W. Linville Someday the world will need a hero, and you
linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org might be all we have. Be ready.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH rfc 1/4] net-timestamp: pull headers for SOCK_STREAM
From: Willem de Bruijn @ 2014-11-25 19:52 UTC (permalink / raw)
To: David Miller; +Cc: Network Development, Andy Lutomirski, Richard Cochran
In-Reply-To: <20141125.134240.861582393401487675.davem@davemloft.net>
On Tue, Nov 25, 2014 at 1:42 PM, David Miller <davem@davemloft.net> wrote:
> From: Willem de Bruijn <willemb@google.com>
> Date: Tue, 25 Nov 2014 12:58:03 -0500
>
>> From: Willem de Bruijn <willemb@google.com>
>>
>> When returning timestamped packets on the error queue, only return
>> the data that the application initially sent: not the protocol
>> headers.
>>
>> This changes the ABI. The TCP interface is new enough that it should
>> be safe to do so. The UDP interface could be changed analogously with
>>
>> + else if (sk->sk_protocol == IPPROTO_UDP)
>> + skb_pull(skb, skb_transport_offset(skb) + sizeof(struct udphdr));
>>
>> Tested with Documentation/networking/timestamping/txtimestamp -l 60 -x
>>
>> Signed-off-by: Willem de Bruijn <willemb@google.com>
>
> What's the harm in exposing the headers? Either it's harmful, and
> therefore doing so for UDP is bad too, or it's harmless and
Headers may expose information not available otherwise. I don't
immediately see critical problems, but that does not mean that they
might not lurk there.
We so far avoid exposing the sequence number, though keeping it hidden
is more about third parties. More in general, unprivileged processes
may start requesting timestamps only to learn tcp state that they
should either get from tcpinfo or cannot currently get at all, likely
for good reason. A far-fetched example is identifying admin iptables
tos mangling rules by reading the tos bits at the driver layer. At least
on my machine, iptables -L is privileged.
> we should probably leave it alone to not risk breaking anyone.
That's fair. I sent it for rfc first for that reason. I won't resubmit
unless more serious concerns are raised.
^ permalink raw reply
* Re: [PATCH 1/2 3.18] rtlwifi: rtl8821ae: Fix 5G detection problem
From: Larry Finger @ 2014-11-25 19:50 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, netdev, Valerio Passini
In-Reply-To: <20141125184625.GC15476@tuxdriver.com>
On 11/25/2014 12:46 PM, John W. Linville wrote:
> On Tue, Nov 25, 2014 at 10:32:06AM -0600, Larry Finger wrote:
>> The changes associated with moving this driver from staging to the regular
>> tree missed one section setting the allowable rates for the 5GHz band.
>>
>> This patch is needed to fix the regression reported in Bug #88811
>> (https://bugzilla.kernel.org/show_bug.cgi?id=88811).
>>
>> Reported-by: Valerio Passini <valerio.passini@unicam.it>
>> Tested-by: Valerio Passini <valerio.passini@unicam.it>
>> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>> Cc: Valerio Passini <valerio.passini@unicam.it>
>> ---
>> drivers/net/wireless/rtlwifi/rtl8821ae/hw.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c b/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c
>> index 310d316..18f34f7 100644
>> --- a/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c
>> +++ b/drivers/net/wireless/rtlwifi/rtl8821ae/hw.c
>> @@ -3672,8 +3672,9 @@ static void rtl8821ae_update_hal_rate_mask(struct ieee80211_hw *hw,
>> mac->opmode == NL80211_IFTYPE_ADHOC)
>> macid = sta->aid + 1;
>> if (wirelessmode == WIRELESS_MODE_N_5G ||
>> - wirelessmode == WIRELESS_MODE_AC_5G)
>> - ratr_bitmap = sta->supp_rates[NL80211_BAND_5GHZ];
>> + wirelessmode == WIRELESS_MODE_AC_5G ||
>> + wirelessmode == WIRELESS_MODE_A)
>> + ratr_bitmap = (sta->supp_rates[NL80211_BAND_5GHZ])<<4;
>
> The parenthesis seem superfluous. How about this line instead?
>
> + ratr_bitmap = sta->supp_rates[NL80211_BAND_5GHZ] << 4;
>
>> else
>> ratr_bitmap = sta->supp_rates[NL80211_BAND_2GHZ];
Good idea. V2 is on its way.
Larry
^ permalink raw reply
* Re: [PATCHv10 ovs 00/15] Revalidate flows with unique identifiers.
From: Joe Stringer @ 2014-11-25 19:45 UTC (permalink / raw)
To: dev@openvswitch.org; +Cc: Linux Netdev List
In-Reply-To: <1415906275-3172-1-git-send-email-joestringer@nicira.com>
On 13 November 2014 at 11:17, Joe Stringer <joestringer@nicira.com> wrote:
>
> This series modifies the dpif interface for flow commands to use 128-bit unique
> identifiers as an alternative to the netlink-formatted flow key, and caches the
> mask/actions in the udpif_key. This significantly reduces the cost of
> assembling messages between revalidators and the datapath, improving
> revalidation performance by 40% or more. In a test environment of many
> short-lived flows constantly being set up in the datapath, this increases the
> number of flows that can be maintained in the linux datapath from around
> 130-140K up to 190-200K. For the userspace datapath, this decreases the time
> spent revalidating 160K flows from 250ms to 150ms.
>
> The core of the changes sits in the handler and revalidator code. Handlers take
> responsibility for creating udpif_key cache entries which now include a copy of
> the flow mask and actions. Revalidators request datapaths to dump flows using
> only the unique identifier and stats, rather than the full set of
> netlink-formatted flow key, mask and actions.
>
> In cases where full revalidation is required, revalidators will use the
> udpif_key cache of the key/mask/acts to validate the flow. The dpif will
> detect datapath support for the unique identifer "UFID" feature, and omit flow
> keys from netlink transactions if it is supported. For backwards compatibility,
> flow keys will always be serialised if UFID support is not detected in the
> datapath.
>
> Patches 1,2,3,15 are unreviewed. Patch 12 needs further review.
>
> This series is also made available here to assist review:
> https://github.com/joestringer/openvswitch/tree/submit/ufid_v10
>
<snip>
>
> Joe Stringer (15):
> tests: Add command to purge revalidators of flows.
> ovs-bugtool: Log more detail for dumped flows.
> datapath: Add 'is_mask' to ovs_nla_put_flow().
> revalidator: Use 'cmap' for storing ukeys.
> revalidator: Protect ukeys with a mutex.
> udpif: Separate udpif_key maps from revalidators.
> upcall: Rename dump_op -> ukey_op.
> upcall: Create ukeys in handler threads.
> upcall: Revalidate using cache of mask, actions.
> hash: Add 128-bit murmurhash.
> dpif: Generate flow_hash for revalidators in dpif.
> datapath: Add support for unique flow identifiers.
> dpif: Index flows using unique identifiers.
> dpif: Minimize memory copy for revalidation.
> dpctl: Add support for using UFID to add/del flows.
<snip>
I'm currently addressing feedback for the datapath patches, which also
involves minor changes to patch #13.
I've already pushed patch #1 as it provided an unrelated benefit. As
this series is fairly close, my current plan is to push patches 4-11
to master this afternoon; these are long-running unchanged patches. I
will then resend patches 2,13,14,15 and the openvswitch.h changes for
final review here. I'll rebase the datapath changes against net-next
and go through review there.
^ permalink raw reply
* Re: [PATCH net-next] gre: Set inner mac header in gro complete
From: David Miller @ 2014-11-25 19:35 UTC (permalink / raw)
To: eric.dumazet; +Cc: therbert, linux, netdev
In-Reply-To: <1416938241.29427.37.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 25 Nov 2014 09:57:21 -0800
> On Tue, 2014-11-25 at 09:30 -0800, Tom Herbert wrote:
>> Set the inner mac header to point to the GRE payload when
>> doing GRO. This is needed if we proceed to send the packet
>> through GRE GSO which now uses the inner mac header instead
>> of inner network header to determine the length of encapsulation
>> headers.
>>
>> Reported-by: Wolfgang Walter <linux@stwm.de>
>> Signed-off-by: Tom Herbert <therbert@google.com>
>> ---
>
> Please Tom, add in your bug fixes something to ease backports.
>
> Fixes: 14051f0452a2 ("gre: Use inner mac length when computing tunnel length")
Also this is extremely far reaching consequences.
The bug is in Linus's tree, so net-next is not a suitable target,
'net' is.
Also, the commit in question has been backported into -stable, so
I would need to queue it up there as well.
Please respin this against 'net', and add the Fixes: tag, thanks.
^ permalink raw reply
* Re: [PATCH v6 5/5] patch to allow arm cross-compile
From: Joe Perches @ 2014-11-25 19:35 UTC (permalink / raw)
To: Alexander Duyck, Russell King
Cc: linux-arch, netdev, linux-kernel, mathieu.desnoyers, peterz, benh,
heiko.carstens, mingo, mikey, linux, donald.c.skidmore,
matthew.vick, geert, jeffrey.t.kirsher, romieu, paulmck, nic_swsd,
arnd, will.deacon, michael, tony.luck, torvalds, oleg,
schwidefsky, fweisbec, davem
In-Reply-To: <20141125183322.1486.90766.stgit@ahduyck-server>
(adding Russell King)
On Tue, 2014-11-25 at 10:33 -0800, Alexander Duyck wrote:
> ---
> arch/arm/kernel/asm-offsets.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> diff --git a/arch/arm/kernel/asm-offsets.c b/arch/arm/kernel/asm-offsets.c
> index 2d2d608..6f8e79c 100644
> --- a/arch/arm/kernel/asm-offsets.c
> +++ b/arch/arm/kernel/asm-offsets.c
> @@ -49,10 +49,6 @@
> #error Your compiler is too buggy; it is known to miscompile kernels.
> #error Known good compilers: 3.3, 4.x
> #endif
> -#if GCC_VERSION >= 40800 && GCC_VERSION < 40803
> -#error Your compiler is too buggy; it is known to miscompile kernels
> -#error and result in filesystem corruption and oopses.
> -#endif
> #endif
^ permalink raw reply
* Re: [PATCH] tg3: fix ring init when there are more TX than RX channels
From: David Miller @ 2014-11-25 19:33 UTC (permalink / raw)
To: cascardo; +Cc: netdev, prashant, mchan
In-Reply-To: <1416932471-8744-1-git-send-email-cascardo@linux.vnet.ibm.com>
From: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Date: Tue, 25 Nov 2014 14:21:11 -0200
> @@ -8563,7 +8563,8 @@ static int tg3_init_rings(struct tg3 *tp)
> if (tnapi->rx_rcb)
> memset(tnapi->rx_rcb, 0, TG3_RX_RCB_RING_BYTES(tp));
>
> - if (tg3_rx_prodring_alloc(tp, &tnapi->prodring)) {
> + if (tnapi->prodring.rx_std &&
> + tg3_rx_prodring_alloc(tp, &tnapi->prodring)) {
> tg3_free_rings(tp);
> return -ENOMEM;
Maybe a better test is "i < tp->rxq_cnt"? This is what is used in
tg3_mem_rx_acquire() to determine if tg3_rx_prodring_init() happens.
^ permalink raw reply
* Re: [PATCH v2 01/17] new helper: skb_copy_and_csum_datagram_msg()
From: David Miller @ 2014-11-25 19:28 UTC (permalink / raw)
To: viro; +Cc: netdev, linux-kernel
In-Reply-To: <1416924151-28698-1-git-send-email-viro@ZenIV.linux.org.uk>
Al, this series looks fine to me, do you have a tree I can pull
it from?
^ permalink raw reply
* Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
From: David Miller @ 2014-11-25 19:27 UTC (permalink / raw)
To: ebiederm-aS9lmoZGLiVWk0Htik3J/w
Cc: josh-iaAMLnmF4UmaiuxdJuQwMA, rdunlap-wEGCiKHe2LqWVfeAwA7xHQ,
pieter-qeJ+1H9vRZbz+pZb47iToQ,
alexander.h.duyck-ral2JQCrhuEAvxtiuMwx3w,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn, ast-uqk4Ao+rVK5Wk0Htik3J/w,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
beber-2YnHqweIUXrk1uMJSBkQmQ,
catalina.mocanu-Re5JQEeQqe8AvxtiuMwx3w,
dborkman-H+wXaHxf7aLQT0dZR+AlfA, edumazet-hpIqsD4AKlfQT0dZR+AlfA,
fabf-AgBVmzD5pcezQB+pC5nmwQ,
fuse-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
geert-Td1EMuHUCqxL1ZNQvxDV9g, hughd-hpIqsD4AKlfQT0dZR+AlfA,
iulia.manda21-Re5JQEeQqe8AvxtiuMwx3w, JBeulich-IBi9RG/b67k,
bfields-uC3wQj2KruNg9hUCZPvPmw, jlayton-vpEMnDpepFuMZCB2o+C8xQ,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, mcgrof-IBi9RG/b67k,
mattst88-Re5JQEeQqe8AvxtiuMwx3w, mgorman-l3A5Bk7waGM,
mst-H+wXaHxf7aLQT0dZR+AlfA, miklos-sUDqSbJrdHQHWmgEVkV9KA,
netdev-u79uwXL29TY76Z2rM5mHXA, oleg-H+wXaHxf7aLQT0dZR+AlfA,
Paul.Durrant-Sxgqhf6Nn4DQT0dZR+AlfA,
paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
pefoley2-lY0TAiDIAFlBDgjK7y7TUQ, tgraf-G/eBtMaohhA,
therbert-hpIqsD4AKlfQT0dZR+AlfA,
trond.myklebust-7I+n7zu2hftEKMMhf/gKZA,
willemb-hpIqsD4AKlfQT0dZR+AlfA,
xiaoguangrong-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8, zhe
In-Reply-To: <87egsr9jkz.fsf-JOvCrm2gF+uungPnsOpG7nhyD016LWXt@public.gmane.org>
From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)
Date: Tue, 25 Nov 2014 13:16:44 -0600
> David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> writes:
>
>> From: josh-iaAMLnmF4UmaiuxdJuQwMA@public.gmane.org
>> Date: Tue, 25 Nov 2014 10:53:10 -0800
>>
>>> It's not a "slippery slope"; it's been our standard practice for ages.
>>
>> We've never put an entire class of generic system calls behind
>> a config option.
>
> CONFIG_SYSVIPC has been in the kernel as long as I can remember.
>
> I seem to remember a plan to remove that code once userspace had
> finished migrating to more unixy interfaces to ipc. But in 20 years
> that migration does does not seem to have finished, or even look
> like it ever will.
>
> But if we started a slippery slope it was long long ago.
Fair enough.
Would be amusing if these tiny systems have it enabled.
^ permalink raw reply
* [PATCH net-next 2/2] gue: Call remcsum_adjust
From: Tom Herbert @ 2014-11-25 19:21 UTC (permalink / raw)
To: davem, netdev
In-Reply-To: <1416943280-28473-1-git-send-email-therbert@google.com>
Change remote checksum offload to call remcsum_adjust. This also
eliminates the optimization to skip an IP header as part of the
adjustment (really does not seem to be much of a win).
Signed-off-by: Tom Herbert <therbert@google.com>
---
net/ipv4/fou.c | 84 ++++++++++++----------------------------------------------
1 file changed, 17 insertions(+), 67 deletions(-)
diff --git a/net/ipv4/fou.c b/net/ipv4/fou.c
index 3dfe982..b986298 100644
--- a/net/ipv4/fou.c
+++ b/net/ipv4/fou.c
@@ -64,15 +64,13 @@ static int fou_udp_recv(struct sock *sk, struct sk_buff *skb)
}
static struct guehdr *gue_remcsum(struct sk_buff *skb, struct guehdr *guehdr,
- void *data, int hdrlen, u8 ipproto)
+ void *data, size_t hdrlen, u8 ipproto)
{
__be16 *pd = data;
- u16 start = ntohs(pd[0]);
- u16 offset = ntohs(pd[1]);
- u16 poffset = 0;
- u16 plen;
- __wsum csum, delta;
- __sum16 *psum;
+ size_t start = ntohs(pd[0]);
+ size_t offset = ntohs(pd[1]);
+ size_t plen = hdrlen + max_t(size_t, offset + sizeof(u16), start);
+ __wsum delta;
if (skb->remcsum_offload) {
/* Already processed in GRO path */
@@ -80,35 +78,15 @@ static struct guehdr *gue_remcsum(struct sk_buff *skb, struct guehdr *guehdr,
return guehdr;
}
- if (start > skb->len - hdrlen ||
- offset > skb->len - hdrlen - sizeof(u16))
- return NULL;
-
- if (unlikely(skb->ip_summed != CHECKSUM_COMPLETE))
- __skb_checksum_complete(skb);
-
- plen = hdrlen + offset + sizeof(u16);
if (!pskb_may_pull(skb, plen))
return NULL;
guehdr = (struct guehdr *)&udp_hdr(skb)[1];
- if (ipproto == IPPROTO_IP && sizeof(struct iphdr) < plen) {
- struct iphdr *ip = (struct iphdr *)(skb->data + hdrlen);
-
- /* If next header happens to be IP we can skip that for the
- * checksum calculation since the IP header checksum is zero
- * if correct.
- */
- poffset = ip->ihl * 4;
- }
-
- csum = csum_sub(skb->csum, skb_checksum(skb, poffset + hdrlen,
- start - poffset - hdrlen, 0));
+ if (unlikely(skb->ip_summed != CHECKSUM_COMPLETE))
+ __skb_checksum_complete(skb);
- /* Set derived checksum in packet */
- psum = (__sum16 *)(skb->data + hdrlen + offset);
- delta = csum_sub(csum_fold(csum), *psum);
- *psum = csum_fold(csum);
+ delta = remcsum_adjust((void *)guehdr + hdrlen,
+ skb->csum, start, offset);
/* Adjust skb->csum since we changed the packet */
skb->csum = csum_add(skb->csum, delta);
@@ -158,9 +136,6 @@ static int gue_udp_recv(struct sock *sk, struct sk_buff *skb)
ip_hdr(skb)->tot_len = htons(ntohs(ip_hdr(skb)->tot_len) - len);
- /* Pull UDP header now, skb->data points to guehdr */
- __skb_pull(skb, sizeof(struct udphdr));
-
/* Pull csum through the guehdr now . This can be used if
* there is a remote checksum offload.
*/
@@ -188,7 +163,7 @@ static int gue_udp_recv(struct sock *sk, struct sk_buff *skb)
if (unlikely(guehdr->control))
return gue_control_message(skb, guehdr);
- __skb_pull(skb, hdrlen);
+ __skb_pull(skb, sizeof(struct udphdr) + hdrlen);
skb_reset_transport_header(skb);
return -guehdr->proto_ctype;
@@ -248,24 +223,17 @@ static struct guehdr *gue_gro_remcsum(struct sk_buff *skb, unsigned int off,
size_t hdrlen, u8 ipproto)
{
__be16 *pd = data;
- u16 start = ntohs(pd[0]);
- u16 offset = ntohs(pd[1]);
- u16 poffset = 0;
- u16 plen;
- void *ptr;
- __wsum csum, delta;
- __sum16 *psum;
+ size_t start = ntohs(pd[0]);
+ size_t offset = ntohs(pd[1]);
+ size_t plen = hdrlen + max_t(size_t, offset + sizeof(u16), start);
+ __wsum delta;
if (skb->remcsum_offload)
return guehdr;
- if (start > skb_gro_len(skb) - hdrlen ||
- offset > skb_gro_len(skb) - hdrlen - sizeof(u16) ||
- !NAPI_GRO_CB(skb)->csum_valid || skb->remcsum_offload)
+ if (!NAPI_GRO_CB(skb)->csum_valid)
return NULL;
- plen = hdrlen + offset + sizeof(u16);
-
/* Pull checksum that will be written */
if (skb_gro_header_hard(skb, off + plen)) {
guehdr = skb_gro_header_slow(skb, off + plen, off);
@@ -273,26 +241,8 @@ static struct guehdr *gue_gro_remcsum(struct sk_buff *skb, unsigned int off,
return NULL;
}
- ptr = (void *)guehdr + hdrlen;
-
- if (ipproto == IPPROTO_IP &&
- (hdrlen + sizeof(struct iphdr) < plen)) {
- struct iphdr *ip = (struct iphdr *)(ptr + hdrlen);
-
- /* If next header happens to be IP we can skip
- * that for the checksum calculation since the
- * IP header checksum is zero if correct.
- */
- poffset = ip->ihl * 4;
- }
-
- csum = csum_sub(NAPI_GRO_CB(skb)->csum,
- csum_partial(ptr + poffset, start - poffset, 0));
-
- /* Set derived checksum in packet */
- psum = (__sum16 *)(ptr + offset);
- delta = csum_sub(csum_fold(csum), *psum);
- *psum = csum_fold(csum);
+ delta = remcsum_adjust((void *)guehdr + hdrlen,
+ NAPI_GRO_CB(skb)->csum, start, offset);
/* Adjust skb->csum since we changed the packet */
skb->csum = csum_add(skb->csum, delta);
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 1/2] net: Add remcsum_adjust as common function for remote checksum offload
From: Tom Herbert @ 2014-11-25 19:21 UTC (permalink / raw)
To: davem, netdev
In-Reply-To: <1416943280-28473-1-git-send-email-therbert@google.com>
This function does the work to update a checksum field as part of
remote checksum offload.
remcsum_adjust does the following:
1) Subtract out the calculated checksum from the beginning of the
packet (ptr arg) to the start offset.
2) Adjust the checksum field indicated by offset based on the modified
checksum value from above step.
3) Return the difference in the old checksum field value and the
new one. The caller will use this to update skb->csum and NAPI csum.
Signed-off-by: Tom Herbert <therbert@google.com>
---
include/net/checksum.h | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/include/net/checksum.h b/include/net/checksum.h
index 6465bae..e339a95 100644
--- a/include/net/checksum.h
+++ b/include/net/checksum.h
@@ -151,4 +151,20 @@ static inline void inet_proto_csum_replace2(__sum16 *sum, struct sk_buff *skb,
(__force __be32)to, pseudohdr);
}
+static inline __wsum remcsum_adjust(void *ptr, __wsum csum,
+ int start, int offset)
+{
+ __sum16 *psum = (__sum16 *)(ptr + offset);
+ __wsum delta;
+
+ /* Subtract out checksum up to start */
+ csum = csum_sub(csum, csum_partial(ptr, start, 0));
+
+ /* Set derived checksum in packet */
+ delta = csum_sub(csum_fold(csum), *psum);
+ *psum = csum_fold(csum);
+
+ return delta;
+}
+
#endif
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply related
* [PATCH net-next 0/2] gue: Generalize remote checksum offload
From: Tom Herbert @ 2014-11-25 19:21 UTC (permalink / raw)
To: davem, netdev
The remote checksum offload is generalized by creating a common
function (remcsum_adjust) that does the work of modifying the
checksum in remote checksum offload. This function can be called
from normal or GRO path. GUE was modified to use this function.
Remote checksum offload is described in
https://tools.ietf.org/html/draft-herbert-remotecsumoffload-01
Tested by running 200 TCP_STREAM connections over GUE, did not see
any problems with remote checksum offload enabled.
Tom Herbert (2):
net: Add remcsum_adjust as common function for remote checksum offload
gue: Call remcsum_adjust
include/net/checksum.h | 16 ++++++++++
net/ipv4/fou.c | 84 ++++++++++----------------------------------------
2 files changed, 33 insertions(+), 67 deletions(-)
--
2.1.0.rc2.206.gedb03e5
^ permalink raw reply
* Re: [patch net-next v3 07/17] rocker: introduce rocker switch driver
From: Scott Feldman @ 2014-11-25 19:19 UTC (permalink / raw)
To: David Laight
Cc: Jiri Pirko, netdev@vger.kernel.org, davem@davemloft.net,
nhorman@tuxdriver.com, andy@greyhouse.net, tgraf@suug.ch,
dborkman@redhat.com, ogerlitz@mellanox.com, jesse@nicira.com,
pshelar@nicira.com, azhou@nicira.com, ben@decadent.org.uk,
stephen@networkplumber.org, jeffrey.t.kirsher@intel.com,
vyasevic@redhat.com, xiyou.wangcong@gmail.com,
john.r.fastabend@intel.com, edumazet@google.com, jhs@mojatatu.com,
"f
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1C9FB50A@AcuExch.aculab.com>
On Tue, Nov 25, 2014 at 6:13 AM, David Laight <David.Laight@aculab.com> wrote:
> From: Jiri Pirko
>>
>> This patch introduces the first driver to benefit from the switchdev
>> infrastructure and to implement newly introduced switch ndos. This is a
>> driver for emulated switch chip implemented in qemu:
>> https://github.com/sfeldma/qemu-rocker/
>
> If this driver caller 'rocker' just to get the (bad) pun 'rocker switch'?
> IMHO A more descriptive name would be a lot better.
Sorry, it's the best we could do since qla3xxx and mlx4 and fm10k were
already taken.
^ permalink raw reply
* Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
From: Eric W. Biederman @ 2014-11-25 19:16 UTC (permalink / raw)
To: David Miller
Cc: josh-iaAMLnmF4UmaiuxdJuQwMA, rdunlap-wEGCiKHe2LqWVfeAwA7xHQ,
pieter-qeJ+1H9vRZbz+pZb47iToQ,
alexander.h.duyck-ral2JQCrhuEAvxtiuMwx3w,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn, ast-uqk4Ao+rVK5Wk0Htik3J/w,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
beber-2YnHqweIUXrk1uMJSBkQmQ,
catalina.mocanu-Re5JQEeQqe8AvxtiuMwx3w,
dborkman-H+wXaHxf7aLQT0dZR+AlfA, edumazet-hpIqsD4AKlfQT0dZR+AlfA,
fabf-AgBVmzD5pcezQB+pC5nmwQ,
fuse-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
geert-Td1EMuHUCqxL1ZNQvxDV9g, hughd-hpIqsD4AKlfQT0dZR+AlfA,
iulia.manda21-Re5JQEeQqe8AvxtiuMwx3w, JBeulich-IBi9RG/b67k,
bfields-uC3wQj2KruNg9hUCZPvPmw, jlayton-vpEMnDpepFuMZCB2o+C8xQ,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, mcgrof-IBi9RG/b67k,
mattst88-Re5JQEeQqe8AvxtiuMwx3w, mgorman-l3A5Bk7waGM,
mst-H+wXaHxf7aLQT0dZR+AlfA, miklos-sUDqSbJrdHQHWmgEVkV9KA,
netdev-u79uwXL29TY76Z2rM5mHXA, oleg-H+wXaHxf7aLQT0dZR+AlfA,
Paul.Durrant-Sxgqhf6Nn4DQT0dZR+AlfA,
paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
pefoley2-lY0TAiDIAFlBDgjK7y7TUQ, tgraf-G/eBtMaohhA,
therbert-hpIqsD4AKlfQT0dZR+AlfA,
trond.myklebust-7I+n7zu2hftEKMMhf/gKZA,
willemb-hpIqsD4AKlfQT0dZR+AlfA,
xiaoguangrong-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8, zhe
In-Reply-To: <20141125.140441.401150380839514113.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> writes:
> From: josh-iaAMLnmF4UmaiuxdJuQwMA@public.gmane.org
> Date: Tue, 25 Nov 2014 10:53:10 -0800
>
>> It's not a "slippery slope"; it's been our standard practice for ages.
>
> We've never put an entire class of generic system calls behind
> a config option.
CONFIG_SYSVIPC has been in the kernel as long as I can remember.
I seem to remember a plan to remove that code once userspace had
finished migrating to more unixy interfaces to ipc. But in 20 years
that migration does does not seem to have finished, or even look
like it ever will.
But if we started a slippery slope it was long long ago.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net] net/mlx4_core: Limit count field to 24 bits in qp_alloc_res
From: David Miller @ 2014-11-25 19:16 UTC (permalink / raw)
To: ogerlitz; +Cc: netdev, matanb, amirv, jackm
In-Reply-To: <1416909271-28840-1-git-send-email-ogerlitz@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
Date: Tue, 25 Nov 2014 11:54:31 +0200
> case RES_OP_RESERVE:
> - count = get_param_l(&in_param);
> + count = get_param_l(&in_param) & 0xffffff;
I think if these high bits are set, you should be using the maximum
value rather then truncating.
^ permalink raw reply
* Re: [net PATCH 0/2] Fix outer UDP checksums for IPv6 VXLAN tunnels
From: David Miller @ 2014-11-25 19:13 UTC (permalink / raw)
To: alexander.duyck; +Cc: netdev
In-Reply-To: <20141125035808.13612.52556.stgit@ahduyck-workstation.home>
From: alexander.duyck@gmail.com
Date: Mon, 24 Nov 2014 20:08:25 -0800
> In testing against an older kernel I found a couple issues in the IPv6
> VXLAN tunnel checksum logic for the outer UDP checksum.
>
> First the default transitioned from using an outer checksum to not using
> one. Second, sometime after that the checksum inputs were changed
> resulting the checksum not being correct if it were computed.
>
> These two issues prevented a ping from the newer kernel to the older one.
> With these two changes applied I verified I was able to send traffic over
> the VXLAN tunnel to a link partner on an older kernel.
>
> The boolean flip fix can be submitted for 3.17 stable as well since the
> patch that introduced the issue was included in that kernel.
Series applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] cxgb4/cxgb4vf/csiostor: Add T4/T5 PCI ID Table
From: David Miller @ 2014-11-25 19:07 UTC (permalink / raw)
To: hariprasad
Cc: netdev, linux-scsi, JBottomley, hch, leedom, anish, nirranjan,
kumaras, praveenm, varun
In-Reply-To: <1416884638-7582-1-git-send-email-hariprasad@chelsio.com>
From: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Tue, 25 Nov 2014 08:33:58 +0530
> Add a new file t4_pci_id_tbl.h that contains T4/T5 PCI ID Table so that for all
> drivers that uses T4/T5 PCI functions changes can be done in one place.
>
> checkpatch.pl script reports following error, which if tried to fix ends up in
> compilation error.
...
> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
From: David Miller @ 2014-11-25 19:05 UTC (permalink / raw)
To: tytso-3s7WtUTddSA
Cc: paulmck-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
rdunlap-wEGCiKHe2LqWVfeAwA7xHQ, pieter-qeJ+1H9vRZbz+pZb47iToQ,
josh-iaAMLnmF4UmaiuxdJuQwMA,
alexander.h.duyck-ral2JQCrhuEAvxtiuMwx3w,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn, ast-uqk4Ao+rVK5Wk0Htik3J/w,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
beber-2YnHqweIUXrk1uMJSBkQmQ,
catalina.mocanu-Re5JQEeQqe8AvxtiuMwx3w,
dborkman-H+wXaHxf7aLQT0dZR+AlfA, edumazet-hpIqsD4AKlfQT0dZR+AlfA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, fabf-AgBVmzD5pcezQB+pC5nmwQ,
fuse-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
geert-Td1EMuHUCqxL1ZNQvxDV9g, hughd-hpIqsD4AKlfQT0dZR+AlfA,
iulia.manda21-Re5JQEeQqe8AvxtiuMwx3w, JBeulich-IBi9RG/b67k,
bfields-uC3wQj2KruNg9hUCZPvPmw, jlayton-vpEMnDpepFuMZCB2o+C8xQ,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, mcgrof-IBi9RG/b67k,
mattst88-Re5JQEeQqe8AvxtiuMwx3w, mgorman-l3A5Bk7waGM,
mst-H+wXaHxf7aLQT0dZR+AlfA, miklos-sUDqSbJrdHQHWmgEVkV9KA,
netdev-u79uwXL29TY76Z2rM5mHXA, oleg-H+wXaHxf7aLQT0dZR+AlfA,
Paul.Durrant-Sxgqhf6Nn4DQT0dZR+AlfA,
pefoley2-lY0TAiDIAFlBDgjK7y7TUQ, tgraf-G/eBtMaohhA,
therbert-hpIqsD4AKlfQT0dZR+AlfA,
trond.myklebust-7I+n7zu2hftEKMMhf/gKZA,
willemb-hpIqsD4AKlfQT0dZR+AlfA, xiaoguangrong@
In-Reply-To: <20141125185806.GA28116-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
From: Theodore Ts'o <tytso-3s7WtUTddSA@public.gmane.org>
Date: Tue, 25 Nov 2014 13:58:06 -0500
> On Tue, Nov 25, 2014 at 01:24:45PM -0500, David Miller wrote:
>>
>> And then if some fundamental part of userland (glibc, klibc, etc.) finds
>> a useful way to use splice for a fundamental operation, we're back to
>> square one.
>
> I'll note that the applications for these super-tiny kernels are
> places where it's not likely they would be using glibc at all; think
> very tiny embedded systems. The userspace tends to be highly
> restricted for the same space reasons why there is an effort to make
> the kernel as small as possible.
This is why I mentioned klibc, in order to avoid replies like your's,
it seems I have failed.
^ permalink raw reply
* Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
From: David Miller @ 2014-11-25 19:04 UTC (permalink / raw)
To: josh
Cc: rdunlap, pieter, alexander.h.duyck, viro, ast, akpm, beber,
catalina.mocanu, dborkman, edumazet, ebiederm, fabf, fuse-devel,
geert, hughd, iulia.manda21, JBeulich, bfields, jlayton,
linux-api, linux-fsdevel, linux-kernel, linux-nfs, mcgrof,
mattst88, mgorman, mst, miklos, netdev, oleg, Paul.Durrant,
paulmck, pefoley2, tgraf, therbert, trond.myklebust, willemb,
xiaoguangrong, zhe
In-Reply-To: <20141125185310.GA24891@cloud>
From: josh@joshtriplett.org
Date: Tue, 25 Nov 2014 10:53:10 -0800
> It's not a "slippery slope"; it's been our standard practice for ages.
We've never put an entire class of generic system calls behind
a config option.
^ permalink raw reply
* Re: [patch net-next v3 17/17] rocker: add ndo_bridge_setlnk/getlink support for learning policy
From: Jamal Hadi Salim @ 2014-11-25 19:00 UTC (permalink / raw)
To: Scott Feldman
Cc: Jiri Pirko, Netdev, David S. Miller, nhorman, Andy Gospodarek,
Thomas Graf, dborkman, ogerlitz, jesse, pshelar, azhou, ben,
stephen, Kirsher, Jeffrey T, vyasevic, Cong Wang,
Fastabend, John R, Eric Dumazet, Florian Fainelli, Roopa Prabhu,
John Linville, jasowang, ebiederm, Nicolas Dichtel, ryazanov.s.a,
buytenh, Aviad Raveh, nbd, Alexei Starovoitov <alexei.
In-Reply-To: <CAE4R7bBNvXFYZiOH+cNm_o6PyyQfCXAWrxU7tJzo+pJ+QQSXGg@mail.gmail.com>
On 11/25/14 13:55, Scott Feldman wrote:
> I disagree. API changes need a reference implementation to show usage
> and for testing. If you have have an alternate switch implementation
> that achieves the same goal, bring it forward.
>
Yes, point conceded ;->
/me waits for the next guy who is going to smirk at me for saying the
above and tell Jiri to fix his typo ;->
cheers,
jamal
^ permalink raw reply
* Re: [PATCH v4 0/7] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
From: josh-iaAMLnmF4UmaiuxdJuQwMA @ 2014-11-25 19:00 UTC (permalink / raw)
To: Randy Dunlap
Cc: Michael S. Tsirkin, Trond Myklebust, Bertrand Jacquin,
Oleg Nesterov, J. Bruce Fields, Eric Dumazet,
蔡正龙, Jeff Layton, Tom Herbert,
Alexei Starovoitov, Miklos Szeredi, Peter Foley, Hugh Dickins,
Xiao Guangrong, Geert Uytterhoeven, Mel Gorman, Matt Turner,
Paul E. McKenney, Alexander Duyck, Pieter Smith,
open list:FUSE: FILESYSTEM...
In-Reply-To: <5474ABB6.3030400-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
On Tue, Nov 25, 2014 at 08:17:58AM -0800, Randy Dunlap wrote:
> On 11/24/2014 03:00 PM, Pieter Smith wrote:
> >REPO: https://github.com/smipi1/linux-tinification.git
> >
> >BRANCH: tiny/config-syscall-splice
> >
> >BACKGROUND: This patch-set forms part of the Linux Kernel Tinification effort (
> > https://tiny.wiki.kernel.org/).
> >
> >GOAL: Support compiling out the splice family of syscalls (splice, vmsplice,
> > tee and sendfile) along with all supporting infrastructure if not needed.
> > Many embedded systems will not need the splice-family syscalls. Omitting them
> > saves space.
>
> Hi,
>
> Is the splice family of syscalls the only one that tiny has identified
> for optional building or can we expect similar treatment for other
> syscalls?
Pretty much any system call that you could conceive of writing a
userspace without.
There's a partial project list at https://tiny.wiki.kernel.org/projects.
> Why will many embedded systems not need these syscalls? You know
> exactly what apps they run and you are positive that those apps do
> not use splice?
Yes, precisely. We're talking about embedded systems small enough that
you're booting with init=/your/app and don't even call fork(), where you
know exactly what code you're putting in and what libraries you use.
And they're almost certainly not running glibc.
> >RESULTS: A tinyconfig bloat-o-meter score for the entire patch-set:
> >
> >add/remove: 0/41 grow/shrink: 5/7 up/down: 23/-8422 (-8399)
>
> The summary is that this patch saves around 8 KB of code space --
> is that correct?
Right. For reference, we're talking about kernels where the *total*
size is a few hundred kB.
> How much storage space do embedded systems have nowadays?
For the embedded systems we're targeting for the tinification effort, in
a first pass: 512k-2M of storage (often for an *uncompressed* kernel, to
support execute-in-place), and 128k-512k of memory. We've successfully
built useful kernels and userspaces for such environments, and we'd like
to go even smaller.
- Josh Triplett
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
^ 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