* Re: [PATCH 0/6] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
From: Josh Triplett @ 2014-11-23 19:43 UTC (permalink / raw)
To: David Miller
Cc: 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,
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, 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, willemb-hpIqsD4AKlfQT0dZR+AlfA,
xiaoguangrong-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
zhenglong.cai-TJRtMXcVgQTM1kAEIRd3EQ
In-Reply-To: <20141123.134623.2061031332250984539.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Sun, Nov 23, 2014 at 01:46:23PM -0500, David Miller wrote:
> Truly removing sendfile/sendpage means that you can't even compile NFS
> into the tree.
If you mean the in-kernel nfsd (CONFIG_NFSD), that already has a large
stack of "select" and "depends on", both directly and indirectly; adding
a "select SPLICE_SYSCALL" to it seems fine. (That select does need
adding, though. Pieter, you need to test-compile more than just
tinyconfig and defconfig. Try an allyesconfig with *just* splice turned
off, and make sure that compiles.)
Given the requirements of running a file server in the kernel, I'd
expect CONFIG_NFSD to end up with several more selects of optional
functionality in the future. It seems rather likely that the average
embedded system will be compiling out NFS. :)
Also, this patch series compiles out splice and sendfile, including
several *users* of sendpage; it doesn't compile out the sendpage
support/infrastructure itself.
- Josh Triplett
^ permalink raw reply
* Re: [PATCH 4/6] solos-pci: fix error return code
From: David Miller @ 2014-11-23 19:30 UTC (permalink / raw)
To: Julia.Lawall
Cc: chas, kernel-janitors, linux-atm-general, netdev, linux-kernel
In-Reply-To: <1416667159-9808-5-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <Julia.Lawall@lip6.fr>
Date: Sat, 22 Nov 2014 15:39:17 +0100
> From: Julia Lawall <Julia.Lawall@lip6.fr>
>
> Return a negative error code on failure.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
...
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Applied, thanks Julia.
^ permalink raw reply
* Re: [PATCH net-next] ipv6: coding style improvements (remove assignment in if statements)
From: David Miller @ 2014-11-23 19:29 UTC (permalink / raw)
To: ipm; +Cc: netdev
In-Reply-To: <1416657725-7829-1-git-send-email-ipm@chirality.org.uk>
From: Ian Morris <ipm@chirality.org.uk>
Date: Sat, 22 Nov 2014 12:02:05 +0000
> diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
> index 7226697..7d7733a 100644
> --- a/net/ipv6/ip6mr.c
> +++ b/net/ipv6/ip6mr.c
> @@ -2410,8 +2410,7 @@ static int mr6_msgsize(bool unresolved, int maxvif)
> + nla_total_size(0) /* RTA_MULTIPATH */
> + maxvif * NLA_ALIGN(sizeof(struct rtnexthop))
> /* RTA_MFC_STATS */
> - + nla_total_size(sizeof(struct rta_mfc_stats))
> - ;
> + + nla_total_size(sizeof(struct rta_mfc_stats));
>
> return len;
> }
This first of all has absolutely nothing to do with your patch, it is
not eliminating an assignment from an if statement.
Second of all, this layout is absolutely intentional.
It makes it such that when new netlink attributed are added, the
patch to add them to this calculation is minimized to one line.
Therefore, please keep that semicolon on a line all by itself.
^ permalink raw reply
* Re: [net 3/3] igb: Fixes needed for surprise removal support
From: David Miller @ 2014-11-23 19:27 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: carolyn.wyborny, netdev, nhorman, sassmann, jogreene,
yanirx.lubetkin
In-Reply-To: <1416642774-17077-3-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 21 Nov 2014 23:52:54 -0800
> From: Carolyn Wyborny <carolyn.wyborny@intel.com>
>
> This patch adds some checks in order to prevent panic's on surprise
> removal of devices during S0, S3, S4. Without this patch, Thunderbolt
> type device removal will panic the system.
>
> Signed-off-by: Yanir Lubetkin <yanirx.lubetkin@intel.com>
> Signed-off-by: Carolyn Wyborny <carolyn.wyborny@intel.com>
> Tested-by: Aaron Brown <aaron.f.brown@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net 2/3] ixgbe: fix use after free adapter->state test in ixgbe_remove/ixgbe_probe
From: David Miller @ 2014-11-23 19:27 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: dborkman, netdev, nhorman, sassmann, jogreene, stable,
mark.d.rustad
In-Reply-To: <1416642774-17077-2-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 21 Nov 2014 23:52:53 -0800
> From: Daniel Borkmann <dborkman@redhat.com>
>
> While working on a different issue, I noticed an annoying use
> after free bug on my machine when unloading the ixgbe driver:
...
> The issue is that test_and_set_bit() done on adapter->state is being
> performed *after* the netdevice has been freed via free_netdev().
>
> When netdev is being allocated on initialization time, it allocates
> a private area, here struct ixgbe_adapter, that resides after the
> net_device structure. In ixgbe_probe(), the device init routine,
> we set up the adapter after alloc_etherdev_mq() on the private area
> and add a reference for the pci_dev as well via pci_set_drvdata().
>
> Both in the error path of ixgbe_probe(), but also on module unload
> when ixgbe_remove() is being called, commit 41c62843eb6a ("ixgbe:
> Fix rcu warnings induced by LER") accesses adapter after free_netdev().
> The patch stores the result in a bool and thus fixes above oops on my
> side.
>
> Fixes: 41c62843eb6a ("ixgbe: Fix rcu warnings induced by LER")
> Cc: stable <stable@vger.kernel.org>
> Cc: Mark Rustad <mark.d.rustad@intel.com>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net 1/3] ixgbe: Correctly disable VLAN filter in promiscuous mode
From: David Miller @ 2014-11-23 19:26 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: vyasevich, netdev, nhorman, sassmann, jogreene, stable,
jacob.e.keller, vyasevic
In-Reply-To: <1416642774-17077-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 21 Nov 2014 23:52:52 -0800
> From: Vlad Yasevich <vyasevich@gmail.com>
>
> IXGBE adapter seems to require that VLAN filtering be enabled if
> VMDQ or SRIOV are enabled. When those functions are disabled,
> VLAN filtering may be disabled in promiscuous mode.
>
> Prior to commit a9b8943ee129 ("ixgbe: remove vlan_filter_disable
> and enable functions")
>
> The logic was correct. However, after the commit the logic
> got reversed and VLAN filtered in now turned on when VMDQ/SRIOV
> is disabled.
>
> This patch changes the condition to enable hw vlan filtered
> when VMDQ or SRIOV is enabled.
>
> Fixes: a9b8943ee129 ("ixgbe: remove vlan_filter_disable and enable functions")
> Cc: stable <stable@vger.kernel.org>
> CC: Jacob Keller <jacob.e.keller@intel.com>
> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
> Acked-by: Emil Tantilov <emil.s.tantilov@intel.com>
> Tested-by: Phil Schmitt <phillip.j.schmitt@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/1] fix return code from fib_rules_lookup()
From: David Miller @ 2014-11-23 19:24 UTC (permalink / raw)
To: ani; +Cc: maze, edumazet, netdev, fruggeri
In-Reply-To: <1416637521-20173-1-git-send-email-ani@arista.com>
From: Ani Sinha <ani@arista.com>
Date: Fri, 21 Nov 2014 22:25:21 -0800
> fib_lookup() api returns two different types of error
> codes. When no custom FIB rules are installed and
> lookup fails, it returns ENETUNREACH. However, when
> custom rules are installed, __fib_lookup() calls
> fib_rules_lookup() which returns ESRCH when the rule
> lookup fails. This patch makes both code paths return
> identical error codes under lookup failure.
>
> Signed-off-by: Ani Sinha <ani@arista.com>
How does this relate to the already committed:
commit 49dd18ba4615eaa72f15c9087dea1c2ab4744cf5
Author: Panu Matilainen <pmatilai@redhat.com>
Date: Fri Nov 14 13:14:32 2014 +0200
ipv4: Fix incorrect error code when adding an unreachable route
Trying to add an unreachable route incorrectly returns -ESRCH if
if custom FIB rules are present:
[root@localhost ~]# ip route add 74.125.31.199 dev eth0 via 1.2.3.4
RTNETLINK answers: Network is unreachable
[root@localhost ~]# ip rule add to 55.66.77.88 table 200
[root@localhost ~]# ip route add 74.125.31.199 dev eth0 via 1.2.3.4
RTNETLINK answers: No such process
[root@localhost ~]#
Commit 83886b6b636173b206f475929e58fac75c6f2446 ("[NET]: Change "not found"
return value for rule lookup") changed fib_rules_lookup()
to use -ESRCH as a "not found" code internally, but for user space it
should be translated into -ENETUNREACH. Handle the translation centrally in
ipv4-specific fib_lookup(), leaving the DECnet case alone.
On a related note, commit b7a71b51ee37d919e4098cd961d59a883fd272d8
("ipv4: removed redundant conditional") removed a similar translation from
ip_route_input_slow() prematurely AIUI.
Fixes: b7a71b51ee37 ("ipv4: removed redundant conditional")
Signed-off-by: Panu Matilainen <pmatilai@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/net/ipv4/fib_rules.c b/net/ipv4/fib_rules.c
index f2e1573..8f7bd56 100644
--- a/net/ipv4/fib_rules.c
+++ b/net/ipv4/fib_rules.c
@@ -62,6 +62,10 @@ int __fib_lookup(struct net *net, struct flowi4 *flp, struct fib_result *res)
else
res->tclassid = 0;
#endif
+
+ if (err == -ESRCH)
+ err = -ENETUNREACH;
+
return err;
}
EXPORT_SYMBOL_GPL(__fib_lookup);
^ permalink raw reply related
* Re: [net-next 00/17][pull request] Intel Wired LAN Driver Updates 2014-11-21
From: David Miller @ 2014-11-23 19:22 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <1416635708-4765-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 21 Nov 2014 21:54:50 -0800
> This series contains updates to i40e and i40evf.
As Ben mentioned, patches #13 and #14 at a minimum need to add a NULL
check against 'indir' in the ethtool handlers in question.
^ permalink raw reply
* Re: [net PATCH] ipv6: Do not treat a GSO_TCPV4 request from UDP tunnel over IPv6 as invalid
From: David Miller @ 2014-11-23 19:18 UTC (permalink / raw)
To: alexander.h.duyck; +Cc: netdev
In-Reply-To: <20141122033603.22361.28896.stgit@ahduyck-server>
From: Alexander Duyck <alexander.h.duyck@redhat.com>
Date: Fri, 21 Nov 2014 19:37:09 -0800
> This patch adds SKB_GSO_TCPV4 to the list of supported GSO types handled by
> the IPv6 GSO offloads. Without this change VXLAN tunnels running over IPv6
> do not currently handle IPv4 TCP TSO requests correctly and end up handing
> the non-segmented frame off to the device.
>
> Below is the before and after for a simple netperf TCP_STREAM test between
> two endpoints tunneling IPv4 over a VXLAN tunnel running on IPv6 on top of
> a 1Gb/s network adapter.
>
> Recv Send Send
> Socket Socket Message Elapsed
> Size Size Size Time Throughput
> bytes bytes bytes secs. 10^6bits/sec
>
> 87380 16384 16384 10.29 0.88 Before
> 87380 16384 16384 10.03 895.69 After
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@redhat.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next] vlan: Pass ethtool get_ts_info queries to real device.
From: Ben Hutchings @ 2014-11-23 19:04 UTC (permalink / raw)
To: David Miller; +Cc: richardcochran, netdev, stefan.sorensen
In-Reply-To: <20141123.134809.1311687203339230014.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1502 bytes --]
On Sun, 2014-11-23 at 13:48 -0500, David Miller wrote:
> From: Richard Cochran <richardcochran@gmail.com>
> Date: Sun, 23 Nov 2014 17:05:35 +0100
>
> > On Sun, Nov 23, 2014 at 03:15:12AM +0000, Ben Hutchings wrote:
> >> This assumes that the same PTP capabilities apply to VLAN-tagged frames.
> >> I don't think it's at all safe to assume that RX filter modes other than
> >> HWTSTAMP_FILTER_ALL will include VLAN-tagged frames. I think it is
> >> necessary to define additional modes that explicitly include VLAN-tagged
> >> frames.
> >
> > Unsafe? How?
> >
> > Do you mean that some HW cannot identify and time stamp PTP frames
> > when VLAN tagged? That is surely disappointing for people who shell
> > out money for such cards, but it is hardly unsafe.
>
> Ben, you will have to provide a concrete example of a chip that will
> do the wrong thing with Richard's change.
>
> Hypotheticals won't cut it.
The two datasheets I've looked at so far (EG20T for pch_gbe driver,
BF518 for bfin_mac driver) mention support for 802.1q but not 802.1ad.
I already mentioned ptp_classify.c doesn't support 802.1ad, and I can't
see how it would ever make sense to run PTP directly over 802.1ad
anyway.
I'll read some more datasheets to see whether 802.1q is generally
supported, but for 802.1ad VLAN devices I think we should pass-through
only the NONE and ALL filter capabilities.
Ben.
--
Ben Hutchings
Never put off till tomorrow what you can avoid all together.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] mlx4: fix mlx4_en_set_rxfh()
From: David Miller @ 2014-11-23 18:49 UTC (permalink / raw)
To: eric.dumazet; +Cc: ben, netdev, amirv
In-Reply-To: <1416705859.17888.7.camel@edumazet-glaptop2.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sat, 22 Nov 2014 17:24:19 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> mlx4_en_set_rxfh() can crash if no RSS indir table is provided.
>
> While we are at it, allow RSS key to be changed with ethtool -X
>
> Tested:
...
> Reported-by: Ben Hutchings <ben@decadent.org.uk>
> Fixes: b9d1ab7eb42e ("mlx4: use netdev_rss_key_fill() helper")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next] vlan: Pass ethtool get_ts_info queries to real device.
From: David Miller @ 2014-11-23 18:48 UTC (permalink / raw)
To: richardcochran; +Cc: ben, netdev, stefan.sorensen
In-Reply-To: <20141123160533.GA4562@netboy>
From: Richard Cochran <richardcochran@gmail.com>
Date: Sun, 23 Nov 2014 17:05:35 +0100
> On Sun, Nov 23, 2014 at 03:15:12AM +0000, Ben Hutchings wrote:
>> This assumes that the same PTP capabilities apply to VLAN-tagged frames.
>> I don't think it's at all safe to assume that RX filter modes other than
>> HWTSTAMP_FILTER_ALL will include VLAN-tagged frames. I think it is
>> necessary to define additional modes that explicitly include VLAN-tagged
>> frames.
>
> Unsafe? How?
>
> Do you mean that some HW cannot identify and time stamp PTP frames
> when VLAN tagged? That is surely disappointing for people who shell
> out money for such cards, but it is hardly unsafe.
Ben, you will have to provide a concrete example of a chip that will
do the wrong thing with Richard's change.
Hypotheticals won't cut it.
Thanks.
^ permalink raw reply
* Re: [PATCH 0/6] kernel tinification: optionally compile out splice family of syscalls (splice, vmsplice, tee and sendfile)
From: David Miller @ 2014-11-23 18:46 UTC (permalink / raw)
To: pieter-qeJ+1H9vRZbz+pZb47iToQ
Cc: 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, 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, willemb-hpIqsD4AKlfQT0dZR+AlfA,
xiaoguangrong-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8,
zhenglong.cai-TJRtMXcVgQTM1kAEIRd3EQ
In-Reply-To: <1416752468-1626-1-git-send-email-pieter-qeJ+1H9vRZbz+pZb47iToQ@public.gmane.org>
Truly removing sendfile/sendpage means that you can't even compile NFS
into the tree.
I cannot take this patch series seriously, sorry.
^ permalink raw reply
* Re: [PATCH net-net 0/4] Increase the limit of tuntap queues
From: David Miller @ 2014-11-23 18:43 UTC (permalink / raw)
To: mst
Cc: pagupta, linux-kernel, netdev, jasowang, dgibson, vfalico,
edumazet, vyasevic, hkchu, wuzhy, xemul, therbert, bhutchings,
xii, stephen, jiri, sergei.shtylyov
In-Reply-To: <20141123104623.GA31915@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Sun, 23 Nov 2014 12:46:23 +0200
> At the moment attaching/detaching queues is an unpriveledged operation.
>
> Shouldn't we worry that an application can cause large
> allocations, and provide a way to limit these?
>
> David, could you comment on this please?
I don't want arbitrary limits imposed.
Where does this "application" run? If it's in the host, then who
cares? If they suck up all of their available memory with queue
resources, it's their problem.
^ permalink raw reply
* Re: [PATCH net-next] vlan: Pass ethtool get_ts_info queries to real device.
From: Richard Cochran @ 2014-11-23 18:38 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, David Miller, Stefan Sørensen
In-Reply-To: <1416763199.7215.53.camel@decadent.org.uk>
On Sun, Nov 23, 2014 at 05:19:59PM +0000, Ben Hutchings wrote:
> > Unsafe? How?
>
> I mean that the assumption is wrong in general. So these changes will
> result in silent failure to enable RX timestamps, on some devices.
Silent failure is dissapointing, yes, but not unsafe. Nothing breaks.
> > The whole filter list with every last combination (at least, the ones
> > at the time) came directly from a early, limited HW design. Sane,
> > modern PTP hardware provides time stamps regardless of whether a frame
> > is VLAN tagged or not.
>
> I would hope so. However, this is non-standard - IEEE802.1AS
> *explicitly forbids* the use of VLAN tags.
Yes, but still people are using them. People fail to understand that
VLAN tags are not meant for end stations. The power industry has
created IEEE 61850 which actually requires end stations to send and
receive VLAN tagged frames with VID!=0, in violation of 802.1. Then
they published a PTP profile running on VLAN tagged Layer2.
(For this reason alone, most hardware does handle tagged frames, and
that is also why the linuxptp stack accepts vlan tags when using Layer2
transport.)
Setting up vlan interfaces on an end station is already somewhat
fishy. People who do that can surely take care that their cards do
correctly handle vlan tagged frames.
Concerning this patch, I needed get_ts_info to work on a VLAN interface
in order to implement a grand master clock on a managed switch. I think
that is valid use case, and implementing a Linux based Transparent
Clock will also need this.
> Linux's software PTP
> classifier also doesn't yet handle 802.1ad VLAN tags.
As soon as someone wants this, I don't see why it cannot be added.
> > I don't see any reason not to make our stack even more ugly just to cater
> > to broken hardware.
>
> So failure to implement a non-standard extension is now 'broken'?
If your PTP traffic flows through a managed, transparent switch with
VLANs enabled, then the device will have to provide time stamps. This
is really a standard use case. Also the power profile mandates vlan.
> This is progress for some devices, false advertising for others.
And where do we draw the line with describing the limitations of poorly
made hardware classifiers? What if a card can time stamp IPv4 packets,
but not in the presence of IPv4 options?
Again, I don't mind if someone wants to add a bunch more combinations
to the rx_filters. But they are useless in the end. In practice, user
space software will ignore them anyhow, unless the software somehow
caters to hardware limitations. Really, look at the list in rx_filters,
and think about this. What is the stack supposed to do if SIOCGHWTSTAMP
returns HWTSTAMP_FILTER_PTP_V2_DELAY_REQ? It is madness, really.
Thanks,
Richard
^ permalink raw reply
* Re: net: Hyper-V: Deletion of an unnecessary check before the function call "vfree"
From: David Miller @ 2014-11-23 18:37 UTC (permalink / raw)
To: elfring
Cc: netdev, haiyangz, kernel-janitors, linux-kernel, julia.lawall,
devel
In-Reply-To: <54718A47.20301@users.sourceforge.net>
From: SF Markus Elfring <elfring@users.sourceforge.net>
Date: Sun, 23 Nov 2014 08:18:31 +0100
>> Whereas if you learn how to base your changes cleanly on the correct
>> base now, all of your future submissions will go quickly and smoothly
>> into my tree.
>
> My reluctance to work with more Linux repositories will evolve
> over time. The faster affected software versions can be rebuilt
> the more it will become interesting to try even more source
> code improvements out, won't it?
>
> I find it nice that you could accept update suggestions for
> a few other Linux components already.
You are seriously starting to waste our time.
Either resubmit your changes against a clean base, or more on.
Seriously, all I am purely interested in is seeing properly submitted
patches, reviewing them, and then integrating them. Anything else is
pure noise to me.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] vlan: Pass ethtool get_ts_info queries to real device.
From: Ben Hutchings @ 2014-11-23 17:19 UTC (permalink / raw)
To: Richard Cochran; +Cc: netdev, David Miller, Stefan Sørensen
In-Reply-To: <20141123160533.GA4562@netboy>
[-- Attachment #1: Type: text/plain, Size: 2397 bytes --]
On Sun, 2014-11-23 at 17:05 +0100, Richard Cochran wrote:
> On Sun, Nov 23, 2014 at 03:15:12AM +0000, Ben Hutchings wrote:
> > This assumes that the same PTP capabilities apply to VLAN-tagged frames.
> > I don't think it's at all safe to assume that RX filter modes other than
> > HWTSTAMP_FILTER_ALL will include VLAN-tagged frames. I think it is
> > necessary to define additional modes that explicitly include VLAN-tagged
> > frames.
>
> Unsafe? How?
I mean that the assumption is wrong in general. So these changes will
result in silent failure to enable RX timestamps, on some devices.
> Do you mean that some HW cannot identify and time stamp PTP frames
> when VLAN tagged? That is surely disappointing for people who shell
> out money for such cards, but it is hardly unsafe.
>
> > I also disagree in general that reconfiguring a VLAN device should make
> > changes to the underlying device that affect more than just that VLAN,
> > i.e. SIOCSHWTSTAMP should not be passed through. SIOCGHWTSTAMP could be
> > passed through, but rx_filter would need adjustment (VLAN-tagged modes
> > on the underlying devices become untagged modes on the VLAN device).
>
> The whole filter list with every last combination (at least, the ones
> at the time) came directly from a early, limited HW design. Sane,
> modern PTP hardware provides time stamps regardless of whether a frame
> is VLAN tagged or not.
I would hope so. However, this is non-standard - IEEE802.1AS
*explicitly forbids* the use of VLAN tags. Linux's software PTP
classifier also doesn't yet handle 802.1ad VLAN tags.
> I don't see any reason not to make our stack even more ugly just to cater
> to broken hardware.
So failure to implement a non-standard extension is now 'broken'?
> I have nothing against adding VLAN to the SIOCGHWTSTAMP list, because
> the hardware people *really* use all have:
>
> HWTSTAMP_TX_ON, and
> HWTSTAMP_FILTER_ALL, or
> HWTSTAMP_FILTER_PTP_V2_EVENT,
>
> So adding more won't hurt. (But it won't help either. If your HW
> cannot time stamp Layer2 and you transmit Layer2, you simply never get
> a time stamp.)
>
> But please don't hold up progress just for this sort of thing.
This is progress for some devices, false advertising for others.
Ben.
--
Ben Hutchings
Never put off till tomorrow what you can avoid all together.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] mlx4: fix mlx4_en_set_rxfh()
From: Eric Dumazet @ 2014-11-23 17:05 UTC (permalink / raw)
To: Amir Vadai; +Cc: Ben Hutchings, David S. Miller, netdev
In-Reply-To: <547210EF.9030800@mellanox.com>
On Sun, 2014-11-23 at 18:53 +0200, Amir Vadai wrote:
> > */
> > for (i = 0; i < priv->rx_ring_num; i++) {
> > + if (!ring_index)
> > + continue;
>
> Why didn't you put the whole loop under the 'if'?
To avoid adding one indentation on the block, and ease this code review.
This is hardly fast path, and compiler does the optim for us anyway.
^ permalink raw reply
* Re: [PATCH] net/mlx4: Fix EEH recovery failure
From: Amir Vadai @ 2014-11-23 16:21 UTC (permalink / raw)
To: Gavin Shan, netdev, Or Gerlitz; +Cc: davem, yishaih
In-Reply-To: <1416653807-4859-1-git-send-email-gwshan@linux.vnet.ibm.com>
On 11/22/2014 12:56 PM, Gavin Shan wrote:
> The patch fixes couple of EEH recovery failures on PPC PowerNV
> platform:
>
> * Release reserved memory regions in mlx4_pci_err_detected().
> Otherwise, __mlx4_init_one() fails because of reserving
> same memory regions recursively.
> * Disable PCI device in mlx4_pci_err_detected(). Otherwise,
> pci_enable_device() in __mlx4_init_one() doesn't enable
> the PCI device because it's already in enabled state indicated
> by struct pci_dev::enable_cnt.
> * Don't clear struct mlx4_priv instance in mlx4_pci_err_detected().
> Otherwise, __mlx4_init_one() runs into kernel crash because
> of dereferencing to NULL pointer.
>
> With the patch applied, EEH recovery for mlx4 adapter succeeds on PPC
> PowerNV platform.
>
> # lspci
> 0003:0f:00.0 Network controller: Mellanox Technologies \
> MT27500 Family [ConnectX-3]
>
> Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
Hi Gavin,
Yishai (added to the CC) is few days before sending a patchset to fix
the reset flow and inside it there is a fix to EEH recovery.
I would be happy if you could wait for the whole reset flow fix by Yishai.
If you'd like, I can send you the patchset to try. Currently it is under
review inside Mellanox before being sent to the mailing list.
Thanks,
Amir
^ permalink raw reply
* Re: [PATCH net-next] mlx4: fix mlx4_en_set_rxfh()
From: Amir Vadai @ 2014-11-23 16:53 UTC (permalink / raw)
To: Eric Dumazet, Ben Hutchings; +Cc: David S. Miller, netdev
In-Reply-To: <1416705859.17888.7.camel@edumazet-glaptop2.roam.corp.google.com>
On 11/23/2014 3:24 AM, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> mlx4_en_set_rxfh() can crash if no RSS indir table is provided.
>
> While we are at it, allow RSS key to be changed with ethtool -X
>
> Tested:
>
> myhost:~# cat /proc/sys/net/core/netdev_rss_key
> b6:89:91:f3:b2:c3:c2:90:11:e8:ce:45:e8:a9:9d:1c:f2:f6:d4:53:61:8b:26:3a:b3:9a:57:97:c3:b6:79:4d:2e:d9:66:5c:72:ed:b6:8e:c5:5d:4d:8c:22:67:30:ab:8a:6e:c3:6a
>
> myhost:~# ethtool -x eth0
> RX flow hash indirection table for eth0 with 8 RX ring(s):
> 0: 0 1 2 3 4 5 6 7
> RSS hash key:
> b6:89:91:f3:b2:c3:c2:90:11:e8:ce:45:e8:a9:9d:1c:f2:f6:d4:53:61:8b:26:3a:b3:9a:57:97:c3:b6:79:4d:2e:d9:66:5c:72:ed:b6:8e
>
> myhost:~# ethtool -X eth0 hkey \
> 03:0e:e2:43:fa:82:0e:73:14:2d:c0:68:21:9e:82:99:b9:84:d0:22:e2:b3:64:9f:4a:af:00:fa:cc:05:b4:4a:17:05:14:73:76:58:bd:2f
>
> myhost:~# ethtool -x eth0
> RX flow hash indirection table for eth0 with 8 RX ring(s):
> 0: 0 1 2 3 4 5 6 7
> RSS hash key:
> 03:0e:e2:43:fa:82:0e:73:14:2d:c0:68:21:9e:82:99:b9:84:d0:22:e2:b3:64:9f:4a:af:00:fa:cc:05:b4:4a:17:05:14:73:76:58:bd:2f
>
>
> Reported-by: Ben Hutchings <ben@decadent.org.uk>
> Fixes: b9d1ab7eb42e ("mlx4: use netdev_rss_key_fill() helper")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Amir Vadai <amirv@mellanox.com>
> ---
> drivers/net/ethernet/mellanox/mlx4/en_ethtool.c | 10 +++++++---
> drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 1 +
> drivers/net/ethernet/mellanox/mlx4/en_rx.c | 3 +--
> drivers/net/ethernet/mellanox/mlx4/mlx4_en.h | 1 +
> 4 files changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
> index bdff834a2a7e..c45e06abc073 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_ethtool.c
> @@ -994,7 +994,7 @@ static int mlx4_en_get_rxfh(struct net_device *dev, u32 *ring_index, u8 *key)
> rss_map->base_qpn;
> }
> if (key)
> - netdev_rss_key_fill(key, MLX4_EN_RSS_KEY_SIZE);
> + memcpy(key, priv->rss_key, MLX4_EN_RSS_KEY_SIZE);
> return err;
> }
>
> @@ -1012,6 +1012,8 @@ static int mlx4_en_set_rxfh(struct net_device *dev, const u32 *ring_index,
> * between rings
> */
> for (i = 0; i < priv->rx_ring_num; i++) {
> + if (!ring_index)
> + continue;
Why didn't you put the whole loop under the 'if'?
> if (i > 0 && !ring_index[i] && !rss_rings)
> rss_rings = i;
>
[...]
Amir
^ permalink raw reply
* Re: [PATCH net-next] vlan: Pass ethtool get_ts_info queries to real device.
From: Richard Cochran @ 2014-11-23 16:05 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, David Miller, Stefan Sørensen
In-Reply-To: <1416712512.7215.34.camel@decadent.org.uk>
On Sun, Nov 23, 2014 at 03:15:12AM +0000, Ben Hutchings wrote:
> This assumes that the same PTP capabilities apply to VLAN-tagged frames.
> I don't think it's at all safe to assume that RX filter modes other than
> HWTSTAMP_FILTER_ALL will include VLAN-tagged frames. I think it is
> necessary to define additional modes that explicitly include VLAN-tagged
> frames.
Unsafe? How?
Do you mean that some HW cannot identify and time stamp PTP frames
when VLAN tagged? That is surely disappointing for people who shell
out money for such cards, but it is hardly unsafe.
> I also disagree in general that reconfiguring a VLAN device should make
> changes to the underlying device that affect more than just that VLAN,
> i.e. SIOCSHWTSTAMP should not be passed through. SIOCGHWTSTAMP could be
> passed through, but rx_filter would need adjustment (VLAN-tagged modes
> on the underlying devices become untagged modes on the VLAN device).
The whole filter list with every last combination (at least, the ones
at the time) came directly from a early, limited HW design. Sane,
modern PTP hardware provides time stamps regardless of whether a frame
is VLAN tagged or not. I don't see any reason not to make our stack
even more ugly just to cater to broken hardware.
I have nothing against adding VLAN to the SIOCGHWTSTAMP list, because
the hardware people *really* use all have:
HWTSTAMP_TX_ON, and
HWTSTAMP_FILTER_ALL, or
HWTSTAMP_FILTER_PTP_V2_EVENT,
So adding more won't hurt. (But it won't help either. If your HW
cannot time stamp Layer2 and you transmit Layer2, you simply never get
a time stamp.)
But please don't hold up progress just for this sort of thing.
Thanks,
Richard
^ permalink raw reply
* Charity Work
From: luv2charitys @ 2014-11-23 15:12 UTC (permalink / raw)
To: netdev
Hello,this is Mr Paul N,i sent you an email on charity work but i am yet to hear fom you,do reply with this code CHA-2015 to my email address paulcharity@qq.com i Look forward to hearing from you this time,God bless Brother Paul
^ permalink raw reply
* Re: [RFC PATCH 1/4] rtnetlink: new flag NLM_F_HW_OFFLOAD to indicate kernel object offload to hardware
From: Roopa Prabhu @ 2014-11-23 15:00 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: jiri, sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen,
linville, nhorman, nicolas.dichtel, vyasevic, f.fainelli, buytenh,
aviadr, netdev, davem, shrijeet, gospo
In-Reply-To: <5470ED34.4090809@cogentembedded.com>
On 11/22/14, 12:08 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 11/22/2014 1:49 AM, roopa@cumulusnetworks.com wrote:
>
>> From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
>> This patch adds new flags in netlink header nlmsg_flags to signal if the
>> message is for the kernel, hw or both.
>
>> This can be used to indicate hw offload for all kind of objects
>> routes, fdb entries, neighs, link objects like bonds, bridges, vxlan.
>
>> Adding it in the header makes it possible to use it accross all
>> objects and
>> across all messages (sets/gets/deletes).
>
>> Other alternative to this is a per kernel object netlink attribute/flag.
>> But that leads to duplicating the attribute in different subsystems.
>
>> Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
>> ---
>> include/uapi/linux/netlink.h | 2 ++
>> 1 file changed, 2 insertions(+)
>
>> diff --git a/include/uapi/linux/netlink.h b/include/uapi/linux/netlink.h
>> index 1a85940..f78522d 100644
>> --- a/include/uapi/linux/netlink.h
>> +++ b/include/uapi/linux/netlink.h
>> @@ -54,6 +54,8 @@ struct nlmsghdr {
>> #define NLM_F_ACK 4 /* Reply with ack, with zero or error
>> code */
>> #define NLM_F_ECHO 8 /* Echo this request */
>> #define NLM_F_DUMP_INTR 16 /* Dump was inconsistent due
>> to sequence change */
>> ++#define NLM_F_KERNEL 32 /* This msg is only for the
>> kernel */
>
> I don't think you really meant double '+'.
certainly not. will fix it. thanks.
>
>> +#define NLM_F_HW_OFFLOAD 64 /* offload this msg to hw */
> [...]
>
> WBR, Sergei
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 6/6] fs/splice: full support for compiling out splice
From: Pieter Smith @ 2014-11-23 14:20 UTC (permalink / raw)
To: pieter-qeJ+1H9vRZbz+pZb47iToQ
Cc: Michael S. Tsirkin, 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,
open list:FUSE: FILESYSTEM..., Luis R. Rodriguez, Josh Triplett
In-Reply-To: <1416752468-1626-1-git-send-email-pieter-qeJ+1H9vRZbz+pZb47iToQ@public.gmane.org>
Entirely compile out splice translation unit when the system is configured
without splice family of syscalls (i.e. CONFIG_SYSCALL_SPLICE is undefined).
Exported fs/splice functions are transparently mocked out with static inlines.
Because userspace support for splice has already been removed by this
patch-set, the exported functions cannot be called anyway. Mocking them out
prevents a maintenance burden on file system drivers.
The bloat score resulting from this patch given a tinyconfig is:
add/remove: 0/25 grow/shrink: 0/5 up/down: 0/-4845 (-4845)
function old new delta
pipe_to_null 4 - -4
generic_pipe_buf_nosteal 6 - -6
spd_release_page 10 - -10
PageUptodate 22 11 -11
lock_page 36 24 -12
page_cache_pipe_buf_release 16 - -16
splice_write_null 24 4 -20
page_cache_pipe_buf_ops 20 - -20
nosteal_pipe_buf_ops 20 - -20
default_pipe_buf_ops 20 - -20
generic_splice_sendpage 24 - -24
splice_shrink_spd 27 - -27
direct_splice_actor 47 - -47
default_file_splice_write 49 - -49
wakeup_pipe_writers 54 - -54
write_pipe_buf 71 - -71
page_cache_pipe_buf_confirm 80 - -80
splice_grow_spd 87 - -87
splice_from_pipe 93 - -93
splice_from_pipe_next 106 - -106
pipe_to_sendpage 109 - -109
page_cache_pipe_buf_steal 114 - -114
generic_file_splice_read 131 8 -123
do_splice_direct 148 - -148
__splice_from_pipe 246 - -246
splice_direct_to_actor 416 - -416
splice_to_pipe 417 - -417
default_file_splice_read 688 - -688
iter_file_splice_write 702 4 -698
__generic_file_splice_read 1109 - -1109
The bloat score for the entire CONFIG_SYSCALL_SPLICE patch-set is:
add/remove: 0/41 grow/shrink: 5/7 up/down: 23/-8422 (-8399)
function old new delta
sys_pwritev 115 122 +7
sys_preadv 115 122 +7
fdput_pos 29 36 +7
sys_pwrite64 115 116 +1
sys_pread64 115 116 +1
pipe_to_null 4 - -4
generic_pipe_buf_nosteal 6 - -6
spd_release_page 10 - -10
fdput 11 - -11
PageUptodate 22 11 -11
lock_page 36 24 -12
signal_pending 39 26 -13
fdget 56 42 -14
page_cache_pipe_buf_release 16 - -16
user_page_pipe_buf_ops 20 - -20
splice_write_null 24 4 -20
page_cache_pipe_buf_ops 20 - -20
nosteal_pipe_buf_ops 20 - -20
default_pipe_buf_ops 20 - -20
generic_splice_sendpage 24 - -24
user_page_pipe_buf_steal 25 - -25
splice_shrink_spd 27 - -27
pipe_to_user 43 - -43
direct_splice_actor 47 - -47
default_file_splice_write 49 - -49
wakeup_pipe_writers 54 - -54
wakeup_pipe_readers 54 - -54
write_pipe_buf 71 - -71
page_cache_pipe_buf_confirm 80 - -80
splice_grow_spd 87 - -87
do_splice_to 87 - -87
ipipe_prep.part 92 - -92
splice_from_pipe 93 - -93
splice_from_pipe_next 107 - -107
pipe_to_sendpage 109 - -109
page_cache_pipe_buf_steal 114 - -114
opipe_prep.part 119 - -119
sys_sendfile 122 - -122
generic_file_splice_read 131 8 -123
sys_sendfile64 126 - -126
sys_vmsplice 137 - -137
do_splice_direct 148 - -148
vmsplice_to_user 205 - -205
__splice_from_pipe 246 - -246
splice_direct_to_actor 348 - -348
splice_to_pipe 371 - -371
do_sendfile 492 - -492
sys_tee 497 - -497
vmsplice_to_pipe 558 - -558
default_file_splice_read 688 - -688
iter_file_splice_write 702 4 -698
sys_splice 1075 - -1075
__generic_file_splice_read 1109 - -1109
Signed-off-by: Pieter Smith <pieter-qeJ+1H9vRZbz+pZb47iToQ@public.gmane.org>
---
fs/Makefile | 3 ++-
fs/splice.c | 2 --
include/linux/fs.h | 26 ++++++++++++++++++++++++++
include/linux/splice.h | 42 ++++++++++++++++++++++++++++++++++++++++++
4 files changed, 70 insertions(+), 3 deletions(-)
diff --git a/fs/Makefile b/fs/Makefile
index fb7646e..9395622 100644
--- a/fs/Makefile
+++ b/fs/Makefile
@@ -10,7 +10,7 @@ obj-y := open.o read_write.o file_table.o super.o \
ioctl.o readdir.o select.o dcache.o inode.o \
attr.o bad_inode.o file.o filesystems.o namespace.o \
seq_file.o xattr.o libfs.o fs-writeback.o \
- pnode.o splice.o sync.o utimes.o \
+ pnode.o sync.o utimes.o \
stack.o fs_struct.o statfs.o fs_pin.o
ifeq ($(CONFIG_BLOCK),y)
@@ -22,6 +22,7 @@ endif
obj-$(CONFIG_PROC_FS) += proc_namespace.o
obj-$(CONFIG_FSNOTIFY) += notify/
+obj-$(CONFIG_SYSCALL_SPLICE) += splice.o
obj-$(CONFIG_EPOLL) += eventpoll.o
obj-$(CONFIG_ANON_INODES) += anon_inodes.o
obj-$(CONFIG_SIGNALFD) += signalfd.o
diff --git a/fs/splice.c b/fs/splice.c
index 7c4c695..44b201b 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -1316,7 +1316,6 @@ long do_splice_direct(struct file *in, loff_t *ppos, struct file *out,
return ret;
}
-#ifdef CONFIG_SYSCALL_SPLICE
static int splice_pipe_to_pipe(struct pipe_inode_info *ipipe,
struct pipe_inode_info *opipe,
size_t len, unsigned int flags);
@@ -2201,5 +2200,4 @@ COMPAT_SYSCALL_DEFINE4(sendfile64, int, out_fd, int, in_fd,
return do_sendfile(out_fd, in_fd, NULL, count, 0);
}
#endif
-#endif
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 04c0975..9b3054e 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2449,6 +2449,7 @@ extern void block_sync_page(struct page *page);
#define __splice_p(x) NULL
#endif
+#ifdef CONFIG_SYSCALL_SPLICE
/* fs/splice.c */
extern ssize_t generic_file_splice_read(struct file *, loff_t *,
struct pipe_inode_info *, size_t, unsigned int);
@@ -2458,6 +2459,31 @@ extern ssize_t iter_file_splice_write(struct pipe_inode_info *,
struct file *, loff_t *, size_t, unsigned int);
extern ssize_t generic_splice_sendpage(struct pipe_inode_info *pipe,
struct file *out, loff_t *, size_t len, unsigned int flags);
+#else
+static inline ssize_t generic_file_splice_read(struct file *in, loff_t *ppos,
+ struct pipe_inode_info *pipe, size_t len, unsigned int flags)
+{
+ return -EPERM;
+}
+
+static inline ssize_t default_file_splice_read(struct file *in, loff_t *ppos,
+ struct pipe_inode_info *pipe, size_t len, unsigned int flags)
+{
+ return -EPERM;
+}
+
+static inline ssize_t iter_file_splice_write(struct pipe_inode_info *pipe,
+ struct file *out, loff_t *ppos, size_t len, unsigned int flags)
+{
+ return -EPERM;
+}
+
+static inline ssize_t generic_splice_sendpage(struct pipe_inode_info *pipe,
+ struct file *out, loff_t *ppos, size_t len, unsigned int flags)
+{
+ return -EPERM;
+}
+#endif
extern void
file_ra_state_init(struct file_ra_state *ra, struct address_space *mapping);
diff --git a/include/linux/splice.h b/include/linux/splice.h
index da2751d..5097a79 100644
--- a/include/linux/splice.h
+++ b/include/linux/splice.h
@@ -65,6 +65,7 @@ typedef int (splice_actor)(struct pipe_inode_info *, struct pipe_buffer *,
typedef int (splice_direct_actor)(struct pipe_inode_info *,
struct splice_desc *);
+#ifdef CONFIG_SYSCALL_SPLICE
extern ssize_t splice_from_pipe(struct pipe_inode_info *, struct file *,
loff_t *, size_t, unsigned int,
splice_actor *);
@@ -74,13 +75,54 @@ extern ssize_t splice_to_pipe(struct pipe_inode_info *,
struct splice_pipe_desc *);
extern ssize_t splice_direct_to_actor(struct file *, struct splice_desc *,
splice_direct_actor *);
+#else /* #ifdef CONFIG_SYSCALL_SPLICE */
+static inline ssize_t splice_from_pipe(struct pipe_inode_info *pipe, struct file *out,
+ loff_t *ppos, size_t len, unsigned int flags,
+ splice_actor *actor)
+{
+ return -EPERM;
+}
+
+static inline ssize_t __splice_from_pipe(struct pipe_inode_info *pipe, struct splice_desc *sd,
+ splice_actor *actor)
+{
+ return -EPERM;
+}
+
+static inline ssize_t splice_to_pipe(struct pipe_inode_info *pipe,
+ struct splice_pipe_desc *spd)
+{
+ return -EPERM;
+}
+
+static inline ssize_t splice_direct_to_actor(struct file *in, struct splice_desc *sd,
+ splice_direct_actor *actor)
+{
+ return -EPERM;
+}
+#endif /* #ifdef CONFIG_SYSCALL_SPLICE */
/*
* for dynamic pipe sizing
*/
+#ifdef CONFIG_SYSCALL_SPLICE
extern int splice_grow_spd(const struct pipe_inode_info *, struct splice_pipe_desc *);
extern void splice_shrink_spd(struct splice_pipe_desc *);
extern void spd_release_page(struct splice_pipe_desc *, unsigned int);
+#else /* #ifdef CONFIG_SYSCALL_SPLICE */
+static inline int splice_grow_spd(const struct pipe_inode_info *pipe, struct splice_pipe_desc *spd)
+{
+ return -EPERM;
+}
+
+static inline void splice_shrink_spd(struct splice_pipe_desc *spd)
+{
+}
+
+static inline void spd_release_page(struct splice_pipe_desc *spd, unsigned int i)
+{
+}
+#endif /* #ifdef CONFIG_SYSCALL_SPLICE */
extern const struct pipe_buf_operations page_cache_pipe_buf_ops;
#endif
--
2.1.0
------------------------------------------------------------------------------
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 related
* [PATCH 5/6] net/core: support compiling out splice
From: Pieter Smith @ 2014-11-23 14:20 UTC (permalink / raw)
To: pieter-qeJ+1H9vRZbz+pZb47iToQ
Cc: Michael S. Tsirkin, 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,
open list:FUSE: FILESYSTEM..., Luis R. Rodriguez, Josh Triplett
In-Reply-To: <1416752468-1626-1-git-send-email-pieter-qeJ+1H9vRZbz+pZb47iToQ@public.gmane.org>
To implement splice support, net/core makes use of nosteal_pipe_buf_ops. This
struct is exported by fs/splice. The goal of the larger patch set is to
completely compile out fs/splice, so uses of the exported struct need to be
compiled out along with fs/splice.
This patch therefore compiles out splice support in net/core when
CONFIG_SYSCALL_SPLICE is undefined. The compiled out function skb_splice_bits
is transparently mocked out with a static inline. The greater patch set removes
userspace splice support so it cannot be called anyway.
Signed-off-by: Pieter Smith <pieter-qeJ+1H9vRZbz+pZb47iToQ@public.gmane.org>
---
include/linux/skbuff.h | 9 +++++++++
net/core/skbuff.c | 9 ++++++---
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index a59d934..54a50c1 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -2640,9 +2640,18 @@ int skb_copy_bits(const struct sk_buff *skb, int offset, void *to, int len);
int skb_store_bits(struct sk_buff *skb, int offset, const void *from, int len);
__wsum skb_copy_and_csum_bits(const struct sk_buff *skb, int offset, u8 *to,
int len, __wsum csum);
+#ifdef CONFIG_SYSCALL_SPLICE
int skb_splice_bits(struct sk_buff *skb, unsigned int offset,
struct pipe_inode_info *pipe, unsigned int len,
unsigned int flags);
+#else
+static inline int skb_splice_bits(struct sk_buff *skb, unsigned int offset,
+ struct pipe_inode_info *pipe, unsigned int len,
+ unsigned int flags)
+{
+ return -EPERM;
+}
+#endif
void skb_copy_and_csum_dev(const struct sk_buff *skb, u8 *to);
unsigned int skb_zerocopy_headlen(const struct sk_buff *from);
int skb_zerocopy(struct sk_buff *to, struct sk_buff *from,
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 61059a0..74fad8a 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -1781,9 +1781,9 @@ static bool __splice_segment(struct page *page, unsigned int poff,
* Map linear and fragment data from the skb to spd. It reports true if the
* pipe is full or if we already spliced the requested length.
*/
-static bool __skb_splice_bits(struct sk_buff *skb, struct pipe_inode_info *pipe,
- unsigned int *offset, unsigned int *len,
- struct splice_pipe_desc *spd, struct sock *sk)
+static bool __maybe_unused __skb_splice_bits(struct sk_buff *skb, struct pipe_inode_info *pipe,
+ unsigned int *offset, unsigned int *len,
+ struct splice_pipe_desc *spd, struct sock *sk)
{
int seg;
@@ -1821,6 +1821,7 @@ static bool __skb_splice_bits(struct sk_buff *skb, struct pipe_inode_info *pipe,
* the frag list, if such a thing exists. We'd probably need to recurse to
* handle that cleanly.
*/
+#ifdef CONFIG_SYSCALL_SPLICE
int skb_splice_bits(struct sk_buff *skb, unsigned int offset,
struct pipe_inode_info *pipe, unsigned int tlen,
unsigned int flags)
@@ -1876,6 +1877,8 @@ done:
return ret;
}
+#endif /* #ifdef CONFIG_SYSCALL_SPLICE */
+
/**
* skb_store_bits - store bits from kernel buffer to skb
--
2.1.0
------------------------------------------------------------------------------
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 related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox