* Re: [PATCH net-next v3] wireless-drivers: rtnetlink wifi simulation device
From: Sergey Matyukevich @ 2018-10-05 14:33 UTC (permalink / raw)
To: Cody Schuffelen
Cc: Johannes Berg, Kalle Valo, David S . Miller,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
kernel-team-z5hGa2qSFaRBDgjK7y7TUQ@public.gmane.org
In-Reply-To: <20181004195906.201895-1-schuffelen-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Hi Cody,
> drivers/net/wireless/Kconfig | 7 +
> drivers/net/wireless/Makefile | 2 +
> drivers/net/wireless/virt_wifi.c | 618 +++++++++++++++++++++++++++++++
> 3 files changed, 627 insertions(+)
> create mode 100644 drivers/net/wireless/virt_wifi.c
I did a quick check of your patch using checkpatch kernel tool,
here is a summary of its output:
$ ./scripts/checkpatch.pl --strict test.patch
...
total: 165 errors, 428 warnings, 9 checks, 634 lines checked
Most part of those complaints is about either whitespaces or code
idents. I am not sure whether this is a patch itself or email client.
So could you please take a look and run checkpatch on your side.
> +static void virt_wifi_scan_result(struct work_struct *work)
> +{
> + const union {
> + struct {
> + u8 tag;
> + u8 len;
> + u8 ssid[8];
> + } __packed parts;
> + u8 data[10];
> + } ssid = { .parts = {
> + .tag = WLAN_EID_SSID, .len = 8, .ssid = "VirtWifi" }
> + };
> + struct cfg80211_bss *informed_bss;
> + struct virt_wifi_priv *priv =
> + container_of(work, struct virt_wifi_priv,
> + scan_result.work);
> + struct wiphy *wiphy = priv_to_wiphy(priv);
> + struct cfg80211_inform_bss mock_inform_bss = {
> + .chan = &channel_5ghz,
> + .scan_width = NL80211_BSS_CHAN_WIDTH_20,
> + .signal = -60,
> + .boottime_ns = ktime_get_boot_ns(),
> + };
> + struct cfg80211_scan_info scan_info = {};
> +
> + informed_bss =
> + cfg80211_inform_bss_data(wiphy, &mock_inform_bss,
> + CFG80211_BSS_FTYPE_PRESP,
> + fake_router_bssid,
> + mock_inform_bss.boottime_ns,
> + WLAN_CAPABILITY_ESS, 0, ssid.data,
> + sizeof(ssid), GFP_KERNEL);
It is possible to simplify this part switching to cfg80211_inform_bss
function: this function wraps your scan data in into cfg80211_inform_bss
structure internally using some reasonable defaults, e.g. channel width.
Besides, signal strength for scan entries should be passed in mBm units,
so use DBM_TO_MBM macro. For instance, with your current code 'iw' tool
produces the following output:
$ sudo iw dev wlan0 scan
...
signal: 0.-60 dBm
...
> +static void virt_wifi_connect_complete(struct work_struct *work)
> +{
> + struct virt_wifi_priv *priv =
> + container_of(work, struct virt_wifi_priv, connect.work);
> + u8 *requested_bss = priv->connect_requested_bss;
> + bool has_addr = !is_zero_ether_addr(requested_bss);
> + bool right_addr = ether_addr_equal(requested_bss, fake_router_bssid);
> + u16 status = WLAN_STATUS_SUCCESS;
> +
> + rtnl_lock();
> + if (!priv->netdev_is_up || (has_addr && !right_addr))
> + status = WLAN_STATUS_UNSPECIFIED_FAILURE;
> + else
> + priv->is_connected = true;
> +
> + cfg80211_connect_result(priv->netdev, requested_bss, NULL, 0, NULL, 0,
> + status, GFP_KERNEL);
> + rtnl_unlock();
> +}
Carrier state for wireless device depends on its connection state.
E.g., carrier is set when wireless connection succeeds and cleared
when device disconnects. So use netif_carrier_on/netif_carrier_off
calls in connect/disconnect handlers to set correct carrier state.
IIUC the following locations look reasonable:
- netif_carrier_off on init
- netif_carrier_on in virt_wifi_connect_complete on success
- netif_carrier_off in virt_wifi_disconnect
> +static void virt_wifi_disconnect_complete(struct work_struct *work)
> +{
> + struct virt_wifi_priv *priv =
> + container_of(work, struct virt_wifi_priv, disconnect.work);
> +
> + cfg80211_disconnected(priv->netdev, priv->disconnect_reason, NULL, 0,
> + true, GFP_KERNEL);
> + priv->is_connected = false;
> +}
Why do you need delayed disconnect processing ? IIUC it can be dropped
and cfg80211_disconnected call can be moved to virt_wifi_disconnect.
> +
> +static int virt_wifi_get_station(struct wiphy *wiphy,
> + struct net_device *dev,
> + const u8 *mac,
> + struct station_info *sinfo)
> +{
> + wiphy_debug(wiphy, "get_station\n");
> +
> + if (!ether_addr_equal(mac, fake_router_bssid))
> + return -ENOENT;
> +
> + sinfo->filled = BIT(NL80211_STA_INFO_TX_PACKETS) |
> + BIT(NL80211_STA_INFO_TX_FAILED) | BIT(NL80211_STA_INFO_SIGNAL) |
> + BIT(NL80211_STA_INFO_TX_BITRATE);
Recently some of NL80211_STA_INFO_ attribute types has been modified to
use BIT_ULL macro. Could you please check commit 22d0d2fafca93ba1d92a
for details and modify your coded if needed.
> + sinfo->tx_packets = 1;
Only one packet, really ? Not sure if you plan to use the output of 'iw'
or any other tool. If yes, then it probably makes sense to use stats
from the original network link. Otherwise, your 'iw' output is
going to look like this:
$ iw dev wlan0 station dump
...
tx packets: 1
...
> + sinfo->tx_failed = 0;
...
> +static int virt_wifi_dump_station(struct wiphy *wiphy,
> + struct net_device *dev,
> + int idx,
> + u8 *mac,
> + struct station_info *sinfo)
> +{
> + wiphy_debug(wiphy, "dump_station\n");
> +
> + if (idx != 0)
> + return -ENOENT;
> +
> + ether_addr_copy(mac, fake_router_bssid);
> + return virt_wifi_get_station(wiphy, dev, fake_router_bssid, sinfo);
> +}
Callback dump_station should return AP data only when STA is connected.
Currently your driver returns fake AP data even when it is not
connected.
> +static const struct cfg80211_ops virt_wifi_cfg80211_ops = {
> + .scan = virt_wifi_scan,
> +
> + .connect = virt_wifi_connect,
> + .disconnect = virt_wifi_disconnect,
> +
> + .get_station = virt_wifi_get_station,
> + .dump_station = virt_wifi_dump_station,
> +};
Hey, this minimal cfg80211 implementation works fine with wpa_supplicant
and open AP config. By the way, if you plan to add more features, then
I would suggest to consider the following cfg80211 callbacks:
- change_station, get_channel
to provide more info in connected state, e.g. compare the output
of the following commands between your virtual interface and
actual wireless interface:
$ iw dev wlan0 link
$ iw dev wlan0 info
- stubs for add_key, del_key to enable encrypted AP simulation
Regards,
Sergey
^ permalink raw reply
* Re: [PATCH bpf-next v2 0/5] xsk: fix bug when trying to use both copy and zero-copy mode
From: Daniel Borkmann @ 2018-10-05 7:35 UTC (permalink / raw)
To: Magnus Karlsson, bjorn.topel, ast, netdev, jakub.kicinski
In-Reply-To: <1538398297-14862-1-git-send-email-magnus.karlsson@intel.com>
On 10/01/2018 02:51 PM, Magnus Karlsson wrote:
> Previously, the xsk code did not record which umem was bound to a
> specific queue id. This was not required if all drivers were zero-copy
> enabled as this had to be recorded in the driver anyway. So if a user
> tried to bind two umems to the same queue, the driver would say
> no. But if copy-mode was first enabled and then zero-copy mode (or the
> reverse order), we mistakenly enabled both of them on the same umem
> leading to buggy behavior. The main culprit for this is that we did
> not store the association of umem to queue id in the copy case and
> only relied on the driver reporting this. As this relation was not
> stored in the driver for copy mode (it does not rely on the AF_XDP
> NDOs), this obviously could not work.
>
> This patch fixes the problem by always recording the umem to queue id
> relationship in the netdev_queue and netdev_rx_queue structs. This way
> we always know what kind of umem has been bound to a queue id and can
> act appropriately at bind time. To make the bind semantics consistent
> with ethtool queue manipulations and to facilitate the implementation
> of drivers, we also forbid decreasing the number of queues/channels
> with ethtool if there is an active AF_XDP socket in the set of queues
> that are disabled.
>
> Jakub, please take a look at your patches. The last one I had to
> change slightly to make it fit with the new interface
> xdp_get_umem_from_qid(). An added bonus with this function is that we,
> in the future, can also use it from the driver to get a umem, thus
> simplifying driver implementations (and later remove the umem from the
> NDO completely). Björn will mail patches, at a later point in time,
> using this in the i40e and ixgbe drivers, that removes a good chunk of
> code from the ZC implementations. I also made your code aware of Tx
> queues. If we create a socket that only has a Tx queue, then the queue
> id will refer to a Tx queue id only and could be larger than the
> available amount of Rx queues. Please take a look at it.
>
> Differences against v1:
> * Included patches from Jakub that forbids decreasing the number of active
> queues if a queue to be deactivated has an AF_XDP socket. These have
> been adapted somewhat to the new interfaces in patch 2.
> * Removed redundant check against real_num_[rt]x_queue in xsk_bind
> * Only need to test against real_num_[rt]x_queues in
> xdp_clear_umem_at_qid.
>
> Patch 1: Introduces a umem reference in the netdev_rx_queue and
> netdev_queue structs.
> Patch 2: Records which queue_id is bound to which umem and make sure
> that you cannot bind two different umems to the same queue_id.
> Patch 3: Pre patch to ethtool_set_channels.
> Patch 4: Forbid decreasing the number of active queues if a deactivated
> queue has an AF_XDP socket.
> Patch 5: Simplify xdp_clear_umem_at_qid now when ethtool cannot deactivate
> the queue id we are running on.
>
> I based this patch set on bpf-next commit 5bf7a60b8e70 ("bpf: permit
> CGROUP_DEVICE programs accessing helper bpf_get_current_cgroup_id()")
>
> Thanks: Magnus
>
> Jakub Kicinski (2):
> ethtool: rename local variable max -> curr
> ethtool: don't allow disabling queues with umem installed
>
> Magnus Karlsson (3):
> net: add umem reference in netdev{_rx}_queue
> xsk: fix bug when trying to use both copy and zero-copy on one queue
> id
> xsk: simplify xdp_clear_umem_at_qid implementation
>
> include/linux/netdevice.h | 6 ++++
> include/net/xdp_sock.h | 7 ++++
> net/core/ethtool.c | 23 +++++++++----
> net/xdp/xdp_umem.c | 87 ++++++++++++++++++++++++++++++++---------------
> net/xdp/xdp_umem.h | 2 +-
> net/xdp/xsk.c | 7 ----
> 6 files changed, 91 insertions(+), 41 deletions(-)
>
> --
> 2.7.4
>
Applied to bpf-next, thanks everyone!
^ permalink raw reply
* Re: [PATCH net-next 20/20] net/bridge: Update br_mdb_dump for strict data checking
From: David Miller @ 2018-10-05 7:34 UTC (permalink / raw)
To: dsahern; +Cc: netdev, christian, jbenc, stephen, dsahern
In-Reply-To: <20181004213355.14899-21-dsahern@kernel.org>
From: David Ahern <dsahern@kernel.org>
Date: Thu, 4 Oct 2018 14:33:55 -0700
> @@ -162,6 +162,28 @@ static int br_mdb_fill_info(struct sk_buff *skb, struct netlink_callback *cb,
> return err;
> }
>
> +static int br_mdb_valid_dump_req(const struct nlmsghdr *nlh,
> + struct netlink_ext_ack *extack)
> +{
> + struct br_port_msg *bpm;
> +
> + if (nlh->nlmsg_len < nlmsg_msg_size(sizeof(*bpm))) {
> + NL_SET_ERR_MSG(extack, "Invalid header");
> + return -EINVAL;
> + }
> + if (bpm->ifindex) {
'bpm' is never initialized.
^ permalink raw reply
* Re: [PATCH] wil6210: fix debugfs_simple_attr.cocci warnings
From: Julia Lawall @ 2018-10-05 14:29 UTC (permalink / raw)
To: Kalle Valo
Cc: YueHaibing, Maya Erez, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
wil6210-Rm6X0d1/PG5y9aJCnZT0Uw,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <877eiw1wol.fsf-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On Fri, 5 Oct 2018, Kalle Valo wrote:
> YueHaibing <yuehaibing-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> writes:
>
> > Use DEFINE_DEBUGFS_ATTRIBUTE rather than DEFINE_SIMPLE_ATTRIBUTE
> > for debugfs files.
> >
> > Semantic patch information:
> > Rationale: DEFINE_SIMPLE_ATTRIBUTE + debugfs_create_file()
> > imposes some significant overhead as compared to
> > DEFINE_DEBUGFS_ATTRIBUTE + debugfs_create_file_unsafe().
> >
> > Generated by: scripts/coccinelle/api/debugfs/debugfs_simple_attr.cocci
>
> Just out of curiosity, what kind of overhead are we talking about here?
The log message on the commit introducing the semantic patch says the
following:
In order to protect against file removal races, debugfs files created via
debugfs_create_file() now get wrapped by a struct file_operations at their
opening.
If the original struct file_operations are known to be safe against removal
races by themselves already, the proxy creation may be bypassed by creating
the files through debugfs_create_file_unsafe().
In order to help debugfs users who use the common
DEFINE_SIMPLE_ATTRIBUTE() + debugfs_create_file()
idiom to transition to removal safe struct file_operations, the helper
macro DEFINE_DEBUGFS_ATTRIBUTE() has been introduced.
Thus, the preferred strategy is to use
DEFINE_DEBUGFS_ATTRIBUTE() + debugfs_create_file_unsafe()
now.
julia
>
> --
> Kalle Valo
>
^ permalink raw reply
* Re: [PATCH net-next] net/neigh: Extend dump filter to proxy neighbor dumps
From: David Miller @ 2018-10-05 7:29 UTC (permalink / raw)
To: dsahern; +Cc: netdev, dsahern
In-Reply-To: <20181003223312.22838-1-dsahern@kernel.org>
From: David Ahern <dsahern@kernel.org>
Date: Wed, 3 Oct 2018 15:33:12 -0700
> From: David Ahern <dsahern@gmail.com>
>
> Move the attribute parsing from neigh_dump_table to neigh_dump_info, and
> pass the filter arguments down to neigh_dump_table in a new struct. Add
> the filter option to proxy neigh dumps as well to make them consistent.
>
> Signed-off-by: David Ahern <dsahern@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] XXX PCI/AER: remove unused variables
From: Vinod @ 2018-10-05 14:26 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Bjorn Helgaas, Oza Pawandeep, Jeff Kirsher, David S. Miller,
Solarflare linux maintainers, Edward Cree, Jacob Keller,
Amritha Nambiar, Alan Brady, Alexander Duyck, Shannon Nelson,
Jesper Dangaard Brouer, dmaengine, linux-kernel, intel-wired-lan,
netdev
In-Reply-To: <20181002210426.2447078-1-arnd@arndb.de>
On 02-10-18, 23:02, Arnd Bergmann wrote:
> A couple of files now contain a function with a return
> code variable that is no longer used:
>
> drivers/net/ethernet/sfc/efx.c: In function 'efx_io_slot_reset':
> drivers/net/ethernet/sfc/efx.c:3824:6: error: unused variable 'rc' [-Werror=unused-variable]
> int rc;
> ^~
> drivers/net/ethernet/sfc/falcon/efx.c: In function 'ef4_io_slot_reset':
> Oza Pawandeep <poza@codeaurora.org>
> drivers/net/ethernet/sfc/falcon/efx.c:3163:6: error: unused variable 'rc' [-Werror=unused-variable]
> int rc;
> ^~
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c: In function 'ixgbe_io_slot_reset':
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:11143:6: error: unused variable 'err' [-Werror=unused-variable]
> int err;
> ^~~
> drivers/net/ethernet/intel/i40e/i40e_main.c: In function 'i40e_pci_error_slot_reset':
> drivers/net/ethernet/intel/i40e/i40e_main.c:14555:6: error: unused variable 'err' [-Werror=unused-variable]
> int err;
>
> drivers/dma/ioat/init.c: In function 'ioat_pcie_error_slot_reset':
> drivers/dma/ioat/init.c:1255:6: error: unused variable 'err' [-Werror=unused-variable]
> int err;
>
> This removes all the ones I found during randconfig build testing.
>
> Fixes: 6dcde3e574b2 ("XXX PCI/AER: Remove pci_cleanup_aer_uncorrect_error_status() calls")
> Cc: Oza Pawandeep <poza@codeaurora.org>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> drivers/dma/ioat/init.c | 1 -
For this:
Acked-by: Vinod Koul <vkoul@kernel.org>
--
~Vinod
^ permalink raw reply
* Re: [PATCH net 2/2] rxrpc: Fix the data_ready handler
From: David Howells @ 2018-10-05 14:18 UTC (permalink / raw)
To: Eric Dumazet; +Cc: dhowells, netdev, linux-afs, linux-kernel, Paolo Abeni
In-Reply-To: <bf1d0734-d73a-83e9-c8e5-0fa4d447bc51@gmail.com>
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> This looks a potential infinite loop to me ?
I assume that you're talking about the case where the packets are coming in so
fast that rxrpc is processing them as fast as they're coming in - or failing
to keep up. I'm not sure what's the best thing to do in that case.
If you're not talking about that case, shouldn't skb_recv_udp() eventually
empty the queue and return -EAGAIN, thereby ending the loop?
I have another patch (see attached) which I was going to submit to net-next,
but maybe I need to merge into this one, in which I take the packets from the
encap_rcv hook.
Paolo has a couple of technical points on it that I need to look at dealing
with, but it speeds things up a bit and gets rid of the loop entirely.
David
---
commit 3784732a15631345c6d33b58985a9c2f30a2047f
Author: David Howells <dhowells@redhat.com>
Date: Thu Oct 4 11:10:51 2018 +0100
rxrpc: Use the UDP encap_rcv hook
Use the UDP encap_rcv hook to cut the bit out of the rxrpc packet reception
in which a packet is placed onto the UDP receive queue and then immediately
removed again by rxrpc. Going via the queue in this manner seems like it
should be unnecessary.
This does, however, require the invention of a value to place in encap_type
as that's one of the conditions to switch packets out to the encap_rcv
hook. Possibly the value doesn't actually matter for anything other than
sockopts on the UDP socket, which aren't accessible outside of rxrpc
anyway.
This seems to cut a bit of time out of the time elapsed between each
sk_buff being timestamped and turning up in rxrpc (the final number in the
following trace excerpts). I measured this by making the rxrpc_rx_packet
trace point print the time elapsed between the skb being timestamped and
the current time (in ns), e.g.:
... 424.278721: rxrpc_rx_packet: ... ACK 25026
So doing a 512MiB DIO read from my test server, with an unmodified kernel:
N min max sum mean stddev
27605 2626 7581 7.83992e+07 2840.04 181.029
and with the patch applied:
N min max sum mean stddev
27547 1895 12165 6.77461e+07 2459.29 255.02
Signed-off-by: David Howells <dhowells@redhat.com>
diff --git a/include/uapi/linux/udp.h b/include/uapi/linux/udp.h
index 09d00f8c442b..09502de447f5 100644
--- a/include/uapi/linux/udp.h
+++ b/include/uapi/linux/udp.h
@@ -40,5 +40,6 @@ struct udphdr {
#define UDP_ENCAP_L2TPINUDP 3 /* rfc2661 */
#define UDP_ENCAP_GTP0 4 /* GSM TS 09.60 */
#define UDP_ENCAP_GTP1U 5 /* 3GPP TS 29.060 */
+#define UDP_ENCAP_RXRPC 6
#endif /* _UAPI_LINUX_UDP_H */
diff --git a/net/rxrpc/ar-internal.h b/net/rxrpc/ar-internal.h
index b79d0413b5ed..b94f3bdc66ac 100644
--- a/net/rxrpc/ar-internal.h
+++ b/net/rxrpc/ar-internal.h
@@ -966,7 +966,7 @@ void rxrpc_unpublish_service_conn(struct rxrpc_connection *);
/*
* input.c
*/
-void rxrpc_data_ready(struct sock *);
+int rxrpc_input_packet(struct sock *, struct sk_buff *);
/*
* insecure.c
diff --git a/net/rxrpc/input.c b/net/rxrpc/input.c
index ab90e60a5237..c0af023b77f4 100644
--- a/net/rxrpc/input.c
+++ b/net/rxrpc/input.c
@@ -1121,7 +1121,7 @@ int rxrpc_extract_header(struct rxrpc_skb_priv *sp, struct sk_buff *skb)
* shut down and the local endpoint from going away, thus sk_user_data will not
* be cleared until this function returns.
*/
-void rxrpc_input_packet(struct sock *udp_sk, struct sk_buff *skb)
+int rxrpc_input_packet(struct sock *udp_sk, struct sk_buff *skb)
{
struct rxrpc_connection *conn;
struct rxrpc_channel *chan;
@@ -1136,6 +1136,24 @@ void rxrpc_input_packet(struct sock *udp_sk, struct sk_buff *skb)
_enter("%p", udp_sk);
+ if (skb->tstamp == 0)
+ skb->tstamp = ktime_get_real();
+
+ rxrpc_new_skb(skb, rxrpc_skb_rx_received);
+
+ _net("recv skb %p", skb);
+
+ if (sk_filter_trim_cap(udp_sk, skb, sizeof(struct udphdr))) {
+ __UDP_INC_STATS(sock_net(udp_sk), UDP_MIB_INERRORS, IS_UDPLITE(udp_sk));
+ atomic_inc(&udp_sk->sk_drops);
+ rxrpc_free_skb(skb, rxrpc_skb_rx_freed);
+ _leave(" [filtered]");
+ return 0;
+ }
+
+ udp_csum_pull_header(skb);
+ skb_orphan(skb);
+
/* The UDP protocol already released all skb resources;
* we are free to add our own data there.
*/
@@ -1150,7 +1168,7 @@ void rxrpc_input_packet(struct sock *udp_sk, struct sk_buff *skb)
if ((lose++ & 7) == 7) {
trace_rxrpc_rx_lose(sp);
rxrpc_free_skb(skb, rxrpc_skb_rx_lost);
- return;
+ return 0;
}
}
@@ -1334,7 +1352,7 @@ void rxrpc_input_packet(struct sock *udp_sk, struct sk_buff *skb)
rxrpc_free_skb(skb, rxrpc_skb_rx_freed);
out:
trace_rxrpc_rx_done(0, 0);
- return;
+ return 0;
out_unlock:
rcu_read_unlock();
@@ -1373,38 +1391,5 @@ void rxrpc_input_packet(struct sock *udp_sk, struct sk_buff *skb)
trace_rxrpc_rx_done(skb->mark, skb->priority);
rxrpc_reject_packet(local, skb);
_leave(" [badmsg]");
-}
-
-void rxrpc_data_ready(struct sock *udp_sk)
-{
- struct sk_buff *skb;
- int ret;
-
- for (;;) {
- skb = skb_recv_udp(udp_sk, 0, 1, &ret);
- if (!skb) {
- if (ret == -EAGAIN)
- return;
-
- /* If there was a transmission failure, we get an error
- * here that we need to ignore.
- */
- _debug("UDP socket error %d", ret);
- continue;
- }
-
- rxrpc_new_skb(skb, rxrpc_skb_rx_received);
-
- /* we'll probably need to checksum it (didn't call sock_recvmsg) */
- if (skb_checksum_complete(skb)) {
- rxrpc_free_skb(skb, rxrpc_skb_rx_freed);
- __UDP_INC_STATS(sock_net(udp_sk), UDP_MIB_INERRORS, 0);
- _debug("csum failed");
- continue;
- }
-
- __UDP_INC_STATS(sock_net(udp_sk), UDP_MIB_INDATAGRAMS, 0);
-
- rxrpc_input_packet(udp_sk, skb);
- }
+ return 0;
}
diff --git a/net/rxrpc/local_object.c b/net/rxrpc/local_object.c
index 30862f44c9f1..cad0691c2bb4 100644
--- a/net/rxrpc/local_object.c
+++ b/net/rxrpc/local_object.c
@@ -19,6 +19,7 @@
#include <linux/ip.h>
#include <linux/hashtable.h>
#include <net/sock.h>
+#include <net/udp.h>
#include <net/af_rxrpc.h>
#include "ar-internal.h"
@@ -108,7 +109,7 @@ static struct rxrpc_local *rxrpc_alloc_local(struct rxrpc_net *rxnet,
*/
static int rxrpc_open_socket(struct rxrpc_local *local, struct net *net)
{
- struct sock *sock;
+ struct sock *usk;
int ret, opt;
_enter("%p{%d,%d}",
@@ -123,10 +124,26 @@ static int rxrpc_open_socket(struct rxrpc_local *local, struct net *net)
}
/* set the socket up */
- sock = local->socket->sk;
- sock->sk_user_data = local;
- sock->sk_data_ready = rxrpc_data_ready;
- sock->sk_error_report = rxrpc_error_report;
+ usk = local->socket->sk;
+ inet_sk(usk)->mc_loop = 0;
+
+ /* Enable CHECKSUM_UNNECESSARY to CHECKSUM_COMPLETE conversion */
+ inet_inc_convert_csum(usk);
+
+ rcu_assign_sk_user_data(usk, local);
+
+ udp_sk(usk)->encap_type = UDP_ENCAP_RXRPC;
+ udp_sk(usk)->encap_rcv = rxrpc_input_packet;
+ udp_sk(usk)->encap_destroy = NULL;
+ udp_sk(usk)->gro_receive = NULL;
+ udp_sk(usk)->gro_complete = NULL;
+
+ udp_encap_enable();
+#if IS_ENABLED(CONFIG_IPV6)
+ if (local->srx.transport.family == AF_INET6)
+ udpv6_encap_enable();
+#endif
+ usk->sk_error_report = rxrpc_error_report;
/* if a local address was supplied then bind it */
if (local->srx.transport_len > sizeof(sa_family_t)) {
^ permalink raw reply related
* [PATCH] net: wireless: iwlegacy: Add a lock assertion in il4965_send_rxon_assoc()
From: Jia-Ju Bai @ 2018-10-05 13:55 UTC (permalink / raw)
To: sgruszka, kvalo, davem; +Cc: linux-wireless, netdev, linux-kernel, Jia-Ju Bai
The variables il->staging.filter_flags, rxon1->filter_flags and
rxon2->filter_flags need to be protected by the mutex lock il->mutex.
This patch adds a lock assertion of il->mutex to check whether
this lock is held.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
drivers/net/wireless/intel/iwlegacy/4965.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/intel/iwlegacy/4965.c b/drivers/net/wireless/intel/iwlegacy/4965.c
index c3c638ed0ed7..ce4144a89217 100644
--- a/drivers/net/wireless/intel/iwlegacy/4965.c
+++ b/drivers/net/wireless/intel/iwlegacy/4965.c
@@ -1297,6 +1297,8 @@ il4965_send_rxon_assoc(struct il_priv *il)
const struct il_rxon_cmd *rxon1 = &il->staging;
const struct il_rxon_cmd *rxon2 = &il->active;
+ lockdep_assert_held(&il->mutex);
+
if (rxon1->flags == rxon2->flags &&
rxon1->filter_flags == rxon2->filter_flags &&
rxon1->cck_basic_rates == rxon2->cck_basic_rates &&
--
2.17.0
^ permalink raw reply related
* Re: [PATCH net-next v6 00/23] WireGuard: Secure Network Tunnel
From: Richard Weinberger @ 2018-10-05 13:53 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Richard Weinberger, Eric Biggers, Ard Biesheuvel, Herbert Xu,
LKML, Netdev, Linux Crypto Mailing List, David Miller,
Greg Kroah-Hartman
In-Reply-To: <CAHmME9rdkAG6mvkUMy9J5+8U9BQkrym7WmmtmK6o3nudykWLoA@mail.gmail.com>
Am Freitag, 5. Oktober 2018, 15:46:29 CEST schrieb Jason A. Donenfeld:
> On Fri, Oct 5, 2018 at 3:38 PM Richard Weinberger
> <richard.weinberger@gmail.com> wrote:
> > So we will have two competing crypo stacks in the kernel?
> > Having a lightweight crypto API is a good thing but I really don't like the idea
> > of having zinc parallel to the existing crypto stack.
>
> No, as you've seen in this patchset, the dynamic dispatch crypto API
> can trivially be done on top of Zinc. So each time we introduce a new
> primitive to Zinc that's also in the dynamic dispatch API, we
> reimplement the current crypto API in terms of Zinc. Check out the two
> patches in this series that do this; it's quite clean and sleek.
This is why I was asking. Your statement and the code didn't match for me.
> > And I strongly vote that Herbert Xu shall remain the maintainer of the whole
> > crypto system (including zinc!) in the kernel.
>
> No, sorry, we intend to maintain the code we've written. But I am
> amenable to taking a tree-route into upstream based on whatever makes
> most sense with merge conflicts and such.
So, you will be a sub-maintainer below Herbert's crypto, that's fine.
What you wrote sounded like a parallel world...
Thanks,
//richard
^ permalink raw reply
* Re: [PATCH net 2/2] rxrpc: Fix the data_ready handler
From: Eric Dumazet @ 2018-10-05 13:52 UTC (permalink / raw)
To: David Howells, netdev; +Cc: linux-afs, linux-kernel
In-Reply-To: <153874699086.18195.6819270943388841145.stgit@warthog.procyon.org.uk>
On 10/05/2018 06:43 AM, David Howells wrote:
> Fix the rxrpc_data_ready() function to pick up all packets and to not miss
> any. There are two problems:
>
> + for (;;) {
> + skb = skb_recv_udp(udp_sk, 0, 1, &ret);
> + if (!skb) {
> + if (ret == -EAGAIN)
> + return;
> +
> + /* If there was a transmission failure, we get an error
> + * here that we need to ignore.
> + */
> + _debug("UDP socket error %d", ret);
> + continue;
> + }
> +
> + rxrpc_new_skb(skb, rxrpc_skb_rx_received);
> +
> + /* we'll probably need to checksum it (didn't call sock_recvmsg) */
> + if (skb_checksum_complete(skb)) {
> + rxrpc_free_skb(skb, rxrpc_skb_rx_freed);
> + __UDP_INC_STATS(sock_net(udp_sk), UDP_MIB_INERRORS, 0);
> + _debug("csum failed");
> + continue;
> + }
> +
> + __UDP_INC_STATS(sock_net(udp_sk), UDP_MIB_INDATAGRAMS, 0);
> +
> + rxrpc_input_packet(udp_sk, skb);
> + }
> +}
This looks a potential infinite loop to me ?
If not, please add a comment explaining why there is no apparent limit.
^ permalink raw reply
* [PATCH] net: cxgb3_main: fix a missing-check bug
From: Wenwen Wang @ 2018-10-05 13:48 UTC (permalink / raw)
To: Wenwen Wang
Cc: Kangjie Lu, Santosh Raspatur, David S. Miller,
open list:CXGB3 ETHERNET DRIVER (CXGB3), open list
In cxgb_extension_ioctl(), the command of the ioctl is firstly copied from
the user-space buffer 'useraddr' to 'cmd' and checked through the
switch statement. If the command is not as expected, an error code
EOPNOTSUPP is returned. In the following execution, i.e., the cases of the
switch statement, the whole buffer of 'useraddr' is copied again to a
specific data structure, according to what kind of command is requested.
However, after the second copy, there is no re-check on the newly-copied
command. Given that the buffer 'useraddr' is in the user space, a malicious
user can race to change the command between the two copies. By doing so,
the attacker can supply malicious data to the kernel and cause undefined
behavior.
This patch adds a re-check in each case of the switch statement if there is
a second copy in that case, to re-check whether the command obtained in the
second copy is the same as the one in the first copy. If not, an error code
EINVAL is returned.
Signed-off-by: Wenwen Wang <wang6495@umn.edu>
---
drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
index a19172d..c34ea38 100644
--- a/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
+++ b/drivers/net/ethernet/chelsio/cxgb3/cxgb3_main.c
@@ -2159,6 +2159,8 @@ static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr)
return -EPERM;
if (copy_from_user(&t, useraddr, sizeof(t)))
return -EFAULT;
+ if (t.cmd != CHELSIO_SET_QSET_PARAMS)
+ return -EINVAL;
if (t.qset_idx >= SGE_QSETS)
return -EINVAL;
if (!in_range(t.intr_lat, 0, M_NEWTIMER) ||
@@ -2258,6 +2260,9 @@ static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr)
if (copy_from_user(&t, useraddr, sizeof(t)))
return -EFAULT;
+ if (t.cmd != CHELSIO_GET_QSET_PARAMS)
+ return -EINVAL;
+
/* Display qsets for all ports when offload enabled */
if (test_bit(OFFLOAD_DEVMAP_BIT, &adapter->open_device_map)) {
q1 = 0;
@@ -2303,6 +2308,8 @@ static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr)
return -EBUSY;
if (copy_from_user(&edata, useraddr, sizeof(edata)))
return -EFAULT;
+ if (edata.cmd != CHELSIO_SET_QSET_NUM)
+ return -EINVAL;
if (edata.val < 1 ||
(edata.val > 1 && !(adapter->flags & USING_MSIX)))
return -EINVAL;
@@ -2343,6 +2350,8 @@ static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr)
return -EPERM;
if (copy_from_user(&t, useraddr, sizeof(t)))
return -EFAULT;
+ if (t.cmd != CHELSIO_LOAD_FW)
+ return -EINVAL;
/* Check t.len sanity ? */
fw_data = memdup_user(useraddr + sizeof(t), t.len);
if (IS_ERR(fw_data))
@@ -2366,6 +2375,8 @@ static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr)
return -EBUSY;
if (copy_from_user(&m, useraddr, sizeof(m)))
return -EFAULT;
+ if (m.cmd != CHELSIO_SETMTUTAB)
+ return -EINVAL;
if (m.nmtus != NMTUS)
return -EINVAL;
if (m.mtus[0] < 81) /* accommodate SACK */
@@ -2407,6 +2418,8 @@ static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr)
return -EBUSY;
if (copy_from_user(&m, useraddr, sizeof(m)))
return -EFAULT;
+ if (m.cmd != CHELSIO_SET_PM)
+ return -EINVAL;
if (!is_power_of_2(m.rx_pg_sz) ||
!is_power_of_2(m.tx_pg_sz))
return -EINVAL; /* not power of 2 */
@@ -2440,6 +2453,8 @@ static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr)
return -EIO; /* need the memory controllers */
if (copy_from_user(&t, useraddr, sizeof(t)))
return -EFAULT;
+ if (t.cmd != CHELSIO_GET_MEM)
+ return -EINVAL;
if ((t.addr & 7) || (t.len & 7))
return -EINVAL;
if (t.mem_id == MEM_CM)
@@ -2492,6 +2507,8 @@ static int cxgb_extension_ioctl(struct net_device *dev, void __user *useraddr)
return -EAGAIN;
if (copy_from_user(&t, useraddr, sizeof(t)))
return -EFAULT;
+ if (t.cmd != CHELSIO_SET_TRACE_FILTER)
+ return -EINVAL;
tp = (const struct trace_params *)&t.sip;
if (t.config_tx)
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next v6 00/23] WireGuard: Secure Network Tunnel
From: Jason A. Donenfeld @ 2018-10-05 13:46 UTC (permalink / raw)
To: Richard Weinberger
Cc: Eric Biggers, Ard Biesheuvel, Herbert Xu, LKML, Netdev,
Linux Crypto Mailing List, David Miller, Greg Kroah-Hartman
In-Reply-To: <CAFLxGvw154vyOziRKuFf5-XTa1NcQm5ZVmgUy3=F79k=Rw2dvA@mail.gmail.com>
On Fri, Oct 5, 2018 at 3:38 PM Richard Weinberger
<richard.weinberger@gmail.com> wrote:
> So we will have two competing crypo stacks in the kernel?
> Having a lightweight crypto API is a good thing but I really don't like the idea
> of having zinc parallel to the existing crypto stack.
No, as you've seen in this patchset, the dynamic dispatch crypto API
can trivially be done on top of Zinc. So each time we introduce a new
primitive to Zinc that's also in the dynamic dispatch API, we
reimplement the current crypto API in terms of Zinc. Check out the two
patches in this series that do this; it's quite clean and sleek.
> And I strongly vote that Herbert Xu shall remain the maintainer of the whole
> crypto system (including zinc!) in the kernel.
No, sorry, we intend to maintain the code we've written. But I am
amenable to taking a tree-route into upstream based on whatever makes
most sense with merge conflicts and such.
^ permalink raw reply
* [PATCH net 2/2] rxrpc: Fix the data_ready handler
From: David Howells @ 2018-10-05 13:43 UTC (permalink / raw)
To: netdev; +Cc: dhowells, linux-afs, linux-kernel
In-Reply-To: <153874697684.18195.15264114363303320691.stgit@warthog.procyon.org.uk>
Fix the rxrpc_data_ready() function to pick up all packets and to not miss
any. There are two problems:
(1) The sk_data_ready pointer on the UDP socket is set *after* it is
bound. This means that it's open for business before we're ready to
dequeue packets and there's a tiny window exists in which a packet can
sneak onto the receive queue, but we never know about it.
Fix this by setting the pointers on the socket prior to binding it.
(2) skb_recv_udp() will return an error (such as ENETUNREACH) if there was
an error on the transmission side, even though we set the
sk_error_report hook. Because rxrpc_data_ready() returns immediately
in such a case, it never actually removes its packet from the receive
queue.
Fix this by abstracting out the UDP dequeuing and checksumming into a
separate function that keeps hammering on skb_recv_udp() until it
returns -EAGAIN, passing the packets extracted to the remainder of the
function.
and two potential problems:
(3) It might be possible in some circumstances or in the future for
packets to be being added to the UDP receive queue whilst rxrpc is
running consuming them, so the data_ready() handler might get called
less often than once per packet.
Allow for this by fully draining the queue on each call as (2).
(4) If a packet fails the checksum check, the code currently returns after
discarding the packet without checking for more.
Allow for this by fully draining the queue on each call as (2).
Fixes: 17926a79320a ("[AF_RXRPC]: Provide secure RxRPC sockets for use by userspace and kernel both")
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Paolo Abeni <pabeni@redhat.com>
---
net/rxrpc/input.c | 68 ++++++++++++++++++++++++++--------------------
net/rxrpc/local_object.c | 11 ++++---
2 files changed, 44 insertions(+), 35 deletions(-)
diff --git a/net/rxrpc/input.c b/net/rxrpc/input.c
index c5af9955665b..c3114fa66c92 100644
--- a/net/rxrpc/input.c
+++ b/net/rxrpc/input.c
@@ -1121,7 +1121,7 @@ int rxrpc_extract_header(struct rxrpc_skb_priv *sp, struct sk_buff *skb)
* shut down and the local endpoint from going away, thus sk_user_data will not
* be cleared until this function returns.
*/
-void rxrpc_data_ready(struct sock *udp_sk)
+void rxrpc_input_packet(struct sock *udp_sk, struct sk_buff *skb)
{
struct rxrpc_connection *conn;
struct rxrpc_channel *chan;
@@ -1130,39 +1130,11 @@ void rxrpc_data_ready(struct sock *udp_sk)
struct rxrpc_local *local = udp_sk->sk_user_data;
struct rxrpc_peer *peer = NULL;
struct rxrpc_sock *rx = NULL;
- struct sk_buff *skb;
unsigned int channel;
- int ret, skew = 0;
+ int skew = 0;
_enter("%p", udp_sk);
- ASSERT(!irqs_disabled());
-
- skb = skb_recv_udp(udp_sk, 0, 1, &ret);
- if (!skb) {
- if (ret == -EAGAIN)
- return;
- _debug("UDP socket error %d", ret);
- return;
- }
-
- if (skb->tstamp == 0)
- skb->tstamp = ktime_get_real();
-
- rxrpc_new_skb(skb, rxrpc_skb_rx_received);
-
- _net("recv skb %p", skb);
-
- /* we'll probably need to checksum it (didn't call sock_recvmsg) */
- if (skb_checksum_complete(skb)) {
- rxrpc_free_skb(skb, rxrpc_skb_rx_freed);
- __UDP_INC_STATS(sock_net(udp_sk), UDP_MIB_INERRORS, 0);
- _leave(" [CSUM failed]");
- return;
- }
-
- __UDP_INC_STATS(sock_net(udp_sk), UDP_MIB_INDATAGRAMS, 0);
-
/* The UDP protocol already released all skb resources;
* we are free to add our own data there.
*/
@@ -1181,6 +1153,8 @@ void rxrpc_data_ready(struct sock *udp_sk)
}
}
+ if (skb->tstamp == 0)
+ skb->tstamp = ktime_get_real();
trace_rxrpc_rx_packet(sp);
switch (sp->hdr.type) {
@@ -1398,3 +1372,37 @@ void rxrpc_data_ready(struct sock *udp_sk)
rxrpc_reject_packet(local, skb);
_leave(" [badmsg]");
}
+
+void rxrpc_data_ready(struct sock *udp_sk)
+{
+ struct sk_buff *skb;
+ int ret;
+
+ for (;;) {
+ skb = skb_recv_udp(udp_sk, 0, 1, &ret);
+ if (!skb) {
+ if (ret == -EAGAIN)
+ return;
+
+ /* If there was a transmission failure, we get an error
+ * here that we need to ignore.
+ */
+ _debug("UDP socket error %d", ret);
+ continue;
+ }
+
+ rxrpc_new_skb(skb, rxrpc_skb_rx_received);
+
+ /* we'll probably need to checksum it (didn't call sock_recvmsg) */
+ if (skb_checksum_complete(skb)) {
+ rxrpc_free_skb(skb, rxrpc_skb_rx_freed);
+ __UDP_INC_STATS(sock_net(udp_sk), UDP_MIB_INERRORS, 0);
+ _debug("csum failed");
+ continue;
+ }
+
+ __UDP_INC_STATS(sock_net(udp_sk), UDP_MIB_INDATAGRAMS, 0);
+
+ rxrpc_input_packet(udp_sk, skb);
+ }
+}
diff --git a/net/rxrpc/local_object.c b/net/rxrpc/local_object.c
index 94d234e9c685..30862f44c9f1 100644
--- a/net/rxrpc/local_object.c
+++ b/net/rxrpc/local_object.c
@@ -122,6 +122,12 @@ static int rxrpc_open_socket(struct rxrpc_local *local, struct net *net)
return ret;
}
+ /* set the socket up */
+ sock = local->socket->sk;
+ sock->sk_user_data = local;
+ sock->sk_data_ready = rxrpc_data_ready;
+ sock->sk_error_report = rxrpc_error_report;
+
/* if a local address was supplied then bind it */
if (local->srx.transport_len > sizeof(sa_family_t)) {
_debug("bind");
@@ -191,11 +197,6 @@ static int rxrpc_open_socket(struct rxrpc_local *local, struct net *net)
BUG();
}
- /* set the socket up */
- sock = local->socket->sk;
- sock->sk_user_data = local;
- sock->sk_data_ready = rxrpc_data_ready;
- sock->sk_error_report = rxrpc_error_report;
_leave(" = 0");
return 0;
^ permalink raw reply related
* [PATCH net 1/2] rxrpc: Fix some missed refs to init_net
From: David Howells @ 2018-10-05 13:43 UTC (permalink / raw)
To: netdev; +Cc: dhowells, linux-afs, linux-kernel
In-Reply-To: <153874697684.18195.15264114363303320691.stgit@warthog.procyon.org.uk>
Fix some refs to init_net that should've been changed to the appropriate
network namespace.
Fixes: 2baec2c3f854 ("rxrpc: Support network namespacing")
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Paolo Abeni <pabeni@redhat.com>
---
net/rxrpc/ar-internal.h | 10 ++++++----
net/rxrpc/call_accept.c | 2 +-
net/rxrpc/call_object.c | 4 ++--
net/rxrpc/conn_client.c | 10 ++++++----
net/rxrpc/input.c | 4 ++--
net/rxrpc/peer_object.c | 28 +++++++++++++++++-----------
6 files changed, 34 insertions(+), 24 deletions(-)
diff --git a/net/rxrpc/ar-internal.h b/net/rxrpc/ar-internal.h
index ef9554131434..63c43b3a2096 100644
--- a/net/rxrpc/ar-internal.h
+++ b/net/rxrpc/ar-internal.h
@@ -891,8 +891,9 @@ extern unsigned long rxrpc_conn_idle_client_fast_expiry;
extern struct idr rxrpc_client_conn_ids;
void rxrpc_destroy_client_conn_ids(void);
-int rxrpc_connect_call(struct rxrpc_call *, struct rxrpc_conn_parameters *,
- struct sockaddr_rxrpc *, gfp_t);
+int rxrpc_connect_call(struct rxrpc_sock *, struct rxrpc_call *,
+ struct rxrpc_conn_parameters *, struct sockaddr_rxrpc *,
+ gfp_t);
void rxrpc_expose_client_call(struct rxrpc_call *);
void rxrpc_disconnect_client_call(struct rxrpc_call *);
void rxrpc_put_client_conn(struct rxrpc_connection *);
@@ -1045,10 +1046,11 @@ void rxrpc_peer_keepalive_worker(struct work_struct *);
*/
struct rxrpc_peer *rxrpc_lookup_peer_rcu(struct rxrpc_local *,
const struct sockaddr_rxrpc *);
-struct rxrpc_peer *rxrpc_lookup_peer(struct rxrpc_local *,
+struct rxrpc_peer *rxrpc_lookup_peer(struct rxrpc_sock *, struct rxrpc_local *,
struct sockaddr_rxrpc *, gfp_t);
struct rxrpc_peer *rxrpc_alloc_peer(struct rxrpc_local *, gfp_t);
-void rxrpc_new_incoming_peer(struct rxrpc_local *, struct rxrpc_peer *);
+void rxrpc_new_incoming_peer(struct rxrpc_sock *, struct rxrpc_local *,
+ struct rxrpc_peer *);
void rxrpc_destroy_all_peers(struct rxrpc_net *);
struct rxrpc_peer *rxrpc_get_peer(struct rxrpc_peer *);
struct rxrpc_peer *rxrpc_get_peer_maybe(struct rxrpc_peer *);
diff --git a/net/rxrpc/call_accept.c b/net/rxrpc/call_accept.c
index 9c7f26d06a52..f55f67894465 100644
--- a/net/rxrpc/call_accept.c
+++ b/net/rxrpc/call_accept.c
@@ -287,7 +287,7 @@ static struct rxrpc_call *rxrpc_alloc_incoming_call(struct rxrpc_sock *rx,
(peer_tail + 1) &
(RXRPC_BACKLOG_MAX - 1));
- rxrpc_new_incoming_peer(local, peer);
+ rxrpc_new_incoming_peer(rx, local, peer);
}
/* Now allocate and set up the connection */
diff --git a/net/rxrpc/call_object.c b/net/rxrpc/call_object.c
index 799f75b6900d..0ca2c2dfd196 100644
--- a/net/rxrpc/call_object.c
+++ b/net/rxrpc/call_object.c
@@ -287,7 +287,7 @@ struct rxrpc_call *rxrpc_new_client_call(struct rxrpc_sock *rx,
/* Set up or get a connection record and set the protocol parameters,
* including channel number and call ID.
*/
- ret = rxrpc_connect_call(call, cp, srx, gfp);
+ ret = rxrpc_connect_call(rx, call, cp, srx, gfp);
if (ret < 0)
goto error;
@@ -339,7 +339,7 @@ int rxrpc_retry_client_call(struct rxrpc_sock *rx,
/* Set up or get a connection record and set the protocol parameters,
* including channel number and call ID.
*/
- ret = rxrpc_connect_call(call, cp, srx, gfp);
+ ret = rxrpc_connect_call(rx, call, cp, srx, gfp);
if (ret < 0)
goto error;
diff --git a/net/rxrpc/conn_client.c b/net/rxrpc/conn_client.c
index 8acf74fe24c0..521189f4b666 100644
--- a/net/rxrpc/conn_client.c
+++ b/net/rxrpc/conn_client.c
@@ -276,7 +276,8 @@ static bool rxrpc_may_reuse_conn(struct rxrpc_connection *conn)
* If we return with a connection, the call will be on its waiting list. It's
* left to the caller to assign a channel and wake up the call.
*/
-static int rxrpc_get_client_conn(struct rxrpc_call *call,
+static int rxrpc_get_client_conn(struct rxrpc_sock *rx,
+ struct rxrpc_call *call,
struct rxrpc_conn_parameters *cp,
struct sockaddr_rxrpc *srx,
gfp_t gfp)
@@ -289,7 +290,7 @@ static int rxrpc_get_client_conn(struct rxrpc_call *call,
_enter("{%d,%lx},", call->debug_id, call->user_call_ID);
- cp->peer = rxrpc_lookup_peer(cp->local, srx, gfp);
+ cp->peer = rxrpc_lookup_peer(rx, cp->local, srx, gfp);
if (!cp->peer)
goto error;
@@ -683,7 +684,8 @@ static int rxrpc_wait_for_channel(struct rxrpc_call *call, gfp_t gfp)
* find a connection for a call
* - called in process context with IRQs enabled
*/
-int rxrpc_connect_call(struct rxrpc_call *call,
+int rxrpc_connect_call(struct rxrpc_sock *rx,
+ struct rxrpc_call *call,
struct rxrpc_conn_parameters *cp,
struct sockaddr_rxrpc *srx,
gfp_t gfp)
@@ -696,7 +698,7 @@ int rxrpc_connect_call(struct rxrpc_call *call,
rxrpc_discard_expired_client_conns(&rxnet->client_conn_reaper);
rxrpc_cull_active_client_conns(rxnet);
- ret = rxrpc_get_client_conn(call, cp, srx, gfp);
+ ret = rxrpc_get_client_conn(rx, call, cp, srx, gfp);
if (ret < 0)
goto out;
diff --git a/net/rxrpc/input.c b/net/rxrpc/input.c
index 800f5b8a1baa..c5af9955665b 100644
--- a/net/rxrpc/input.c
+++ b/net/rxrpc/input.c
@@ -1156,12 +1156,12 @@ void rxrpc_data_ready(struct sock *udp_sk)
/* we'll probably need to checksum it (didn't call sock_recvmsg) */
if (skb_checksum_complete(skb)) {
rxrpc_free_skb(skb, rxrpc_skb_rx_freed);
- __UDP_INC_STATS(&init_net, UDP_MIB_INERRORS, 0);
+ __UDP_INC_STATS(sock_net(udp_sk), UDP_MIB_INERRORS, 0);
_leave(" [CSUM failed]");
return;
}
- __UDP_INC_STATS(&init_net, UDP_MIB_INDATAGRAMS, 0);
+ __UDP_INC_STATS(sock_net(udp_sk), UDP_MIB_INDATAGRAMS, 0);
/* The UDP protocol already released all skb resources;
* we are free to add our own data there.
diff --git a/net/rxrpc/peer_object.c b/net/rxrpc/peer_object.c
index 01a9febfa367..2d39eaf19620 100644
--- a/net/rxrpc/peer_object.c
+++ b/net/rxrpc/peer_object.c
@@ -153,8 +153,10 @@ struct rxrpc_peer *rxrpc_lookup_peer_rcu(struct rxrpc_local *local,
* assess the MTU size for the network interface through which this peer is
* reached
*/
-static void rxrpc_assess_MTU_size(struct rxrpc_peer *peer)
+static void rxrpc_assess_MTU_size(struct rxrpc_sock *rx,
+ struct rxrpc_peer *peer)
{
+ struct net *net = sock_net(&rx->sk);
struct dst_entry *dst;
struct rtable *rt;
struct flowi fl;
@@ -169,7 +171,7 @@ static void rxrpc_assess_MTU_size(struct rxrpc_peer *peer)
switch (peer->srx.transport.family) {
case AF_INET:
rt = ip_route_output_ports(
- &init_net, fl4, NULL,
+ net, fl4, NULL,
peer->srx.transport.sin.sin_addr.s_addr, 0,
htons(7000), htons(7001), IPPROTO_UDP, 0, 0);
if (IS_ERR(rt)) {
@@ -188,7 +190,7 @@ static void rxrpc_assess_MTU_size(struct rxrpc_peer *peer)
sizeof(struct in6_addr));
fl6->fl6_dport = htons(7001);
fl6->fl6_sport = htons(7000);
- dst = ip6_route_output(&init_net, NULL, fl6);
+ dst = ip6_route_output(net, NULL, fl6);
if (dst->error) {
_leave(" [route err %d]", dst->error);
return;
@@ -240,10 +242,11 @@ struct rxrpc_peer *rxrpc_alloc_peer(struct rxrpc_local *local, gfp_t gfp)
/*
* Initialise peer record.
*/
-static void rxrpc_init_peer(struct rxrpc_peer *peer, unsigned long hash_key)
+static void rxrpc_init_peer(struct rxrpc_sock *rx, struct rxrpc_peer *peer,
+ unsigned long hash_key)
{
peer->hash_key = hash_key;
- rxrpc_assess_MTU_size(peer);
+ rxrpc_assess_MTU_size(rx, peer);
peer->mtu = peer->if_mtu;
peer->rtt_last_req = ktime_get_real();
@@ -275,7 +278,8 @@ static void rxrpc_init_peer(struct rxrpc_peer *peer, unsigned long hash_key)
/*
* Set up a new peer.
*/
-static struct rxrpc_peer *rxrpc_create_peer(struct rxrpc_local *local,
+static struct rxrpc_peer *rxrpc_create_peer(struct rxrpc_sock *rx,
+ struct rxrpc_local *local,
struct sockaddr_rxrpc *srx,
unsigned long hash_key,
gfp_t gfp)
@@ -287,7 +291,7 @@ static struct rxrpc_peer *rxrpc_create_peer(struct rxrpc_local *local,
peer = rxrpc_alloc_peer(local, gfp);
if (peer) {
memcpy(&peer->srx, srx, sizeof(*srx));
- rxrpc_init_peer(peer, hash_key);
+ rxrpc_init_peer(rx, peer, hash_key);
}
_leave(" = %p", peer);
@@ -299,14 +303,15 @@ static struct rxrpc_peer *rxrpc_create_peer(struct rxrpc_local *local,
* since we've already done a search in the list from the non-reentrant context
* (the data_ready handler) that is the only place we can add new peers.
*/
-void rxrpc_new_incoming_peer(struct rxrpc_local *local, struct rxrpc_peer *peer)
+void rxrpc_new_incoming_peer(struct rxrpc_sock *rx, struct rxrpc_local *local,
+ struct rxrpc_peer *peer)
{
struct rxrpc_net *rxnet = local->rxnet;
unsigned long hash_key;
hash_key = rxrpc_peer_hash_key(local, &peer->srx);
peer->local = local;
- rxrpc_init_peer(peer, hash_key);
+ rxrpc_init_peer(rx, peer, hash_key);
spin_lock(&rxnet->peer_hash_lock);
hash_add_rcu(rxnet->peer_hash, &peer->hash_link, hash_key);
@@ -317,7 +322,8 @@ void rxrpc_new_incoming_peer(struct rxrpc_local *local, struct rxrpc_peer *peer)
/*
* obtain a remote transport endpoint for the specified address
*/
-struct rxrpc_peer *rxrpc_lookup_peer(struct rxrpc_local *local,
+struct rxrpc_peer *rxrpc_lookup_peer(struct rxrpc_sock *rx,
+ struct rxrpc_local *local,
struct sockaddr_rxrpc *srx, gfp_t gfp)
{
struct rxrpc_peer *peer, *candidate;
@@ -337,7 +343,7 @@ struct rxrpc_peer *rxrpc_lookup_peer(struct rxrpc_local *local,
/* The peer is not yet present in hash - create a candidate
* for a new record and then redo the search.
*/
- candidate = rxrpc_create_peer(local, srx, hash_key, gfp);
+ candidate = rxrpc_create_peer(rx, local, srx, hash_key, gfp);
if (!candidate) {
_leave(" = NULL [nomem]");
return NULL;
^ permalink raw reply related
* [PATCH net 0/2] rxrpc: Fixes
From: David Howells @ 2018-10-05 13:42 UTC (permalink / raw)
To: netdev; +Cc: dhowells, linux-afs, linux-kernel
Here are two fixes for AF_RXRPC:
(1) Fix some places that are doing things in the wrong net namespace.
(2) Fix the reception of UDP packets in three ways:
(a) Close the window between binding the socket and setting the
data_ready hook in which packets can come in and get lodged in the
receive queue without data_ready seeing them.
(b) Make sure the UDP receive queue is drained before returning from
the data_ready hook.
(c) Ignore Tx errors returned by skb_recv_udp().
The patches are tagged here:
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
rxrpc-fixes-20181005
and can also be found on the following branch:
http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-fixes
David
---
David Howells (2):
rxrpc: Fix some missed refs to init_net
rxrpc: Fix the data_ready handler
net/rxrpc/ar-internal.h | 10 ++++---
net/rxrpc/call_accept.c | 2 +
net/rxrpc/call_object.c | 4 +--
net/rxrpc/conn_client.c | 10 ++++---
net/rxrpc/input.c | 68 ++++++++++++++++++++++++++--------------------
net/rxrpc/local_object.c | 11 ++++---
net/rxrpc/peer_object.c | 28 ++++++++++++-------
7 files changed, 76 insertions(+), 57 deletions(-)
^ permalink raw reply
* Re: [PATCH] net: wireless: iwlegacy: Fix possible data races in il4965_send_rxon_assoc()
From: Jia-Ju Bai @ 2018-10-05 13:42 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: kvalo, davem, linux-wireless, netdev, linux-kernel
In-Reply-To: <20181005075403.GC1931@redhat.com>
On 2018/10/5 15:54, Stanislaw Gruszka wrote:
> On Thu, Oct 04, 2018 at 04:52:19PM +0800, Jia-Ju Bai wrote:
>> On 2018/10/4 15:59, Stanislaw Gruszka wrote:
>>> On Wed, Oct 03, 2018 at 10:07:45PM +0800, Jia-Ju Bai wrote:
>>>> These possible races are detected by a runtime testing.
>>>> To fix these races, the mutex lock is used in il4965_send_rxon_assoc()
>>>> to protect the data.
>>> Really ? I'm surprised by that, see below.
>> My runtime testing shows that il4965_send_rxon_assoc() and
>> il4965_configure_filter() are concurrently executed.
>> But after seeing your reply, I need to carefully check whether my
>> runtime testing is right, because I think you are right.
>> In fact, I only monitored the iwl4965 driver, but did not monitor
>> the iwlegacy driver, so I will do the testing again with monitoring
>> the lwlegacy driver.
> <snip>
>>> So I wonder how this patch did not cause the deadlock ?
>> Oh, sorry, anyway, my patch will cause double locks...
> So how those runtime test were performend such you didn't
> notice this ?
I write a tool to perform runtime testing.
This tool records the lock status during driver execution.
Some calls to mutex_lock() are in common.c that I did not handle, so the
corresponding lock status was not recorded by my tool, causing this
false positive.
Now I have handled common.c, and this false positive is not reported any
more.
Actually, I get several new reports.
I will send you these reports to you later, and hope you can have a
look, thanks in advance :)
>
>>> Anyway what can be done is adding:
>>>
>>> lockdep_assert_held(&il->mutex);
>>>
>>> il4965_commit_rxon() to check if we hold the mutex.
>> I agree.
> Care to post a patch ?
Sure :)
Best wishes,
Jia-Ju Bai
^ permalink raw reply
* Re: [PATCH net-next v6 00/23] WireGuard: Secure Network Tunnel
From: Richard Weinberger @ 2018-10-05 13:37 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: ebiggers, Ard Biesheuvel, Herbert Xu, LKML, netdev, linux-crypto,
David S. Miller, Greg KH
In-Reply-To: <CAHmME9ogY=v2Le85+_=-m++RwAzwiUmKyNzx6N2y9Ht-J7xBcQ@mail.gmail.com>
On Fri, Oct 5, 2018 at 3:14 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> On Wed, Oct 3, 2018 at 8:49 AM Eric Biggers <ebiggers@kernel.org> wrote:
> > It's not really about the name, though. It's actually about the whole way of
> > thinking about the submission. Is it a new special library with its own things
> > going on, or is it just some crypto helper functions? It's really just the
> > latter, but you've been presenting it as the former
>
> No, it really is its own thing with important differences from the
> present crypto api. Zinc's focus is on simplicity and clarity. To the
> extent that we're at all tangled with the current crypto api, the goal
> is to untangle as much as possible. It intends to be a small and
> lightweight set of routines, whose relationships are obvious, and with
> this direct and to the point organization, as well as work with the larger
> cryptography community and with academia to invite collaboration. With
> this comes a different way of maintaining it, with higher standards
> and a preference for different implementations than the current
> situation. With Zinc, you have an obvious series of C function calls
> composing the whole thing, without complicated indirection. It's
> something that could be trivially lifted out into a userspace library,
> and used broadly, for example -- something I'll probably do at some
> point. That's a bit of a design change to the current crypto api, and
> sprinkling some direct function calls within the current crypto api's
> complicated enterprise situation would only kick the can further down
> the road, as much complexity would still remain. The goal is to move
> away from behemoth enterprise APIs, and large and complex codebases to
> a simple and direct way of doing things. This desire to untangle, to
> start from a simpler base, and to generally do things differently
> means it will go into lib/zinc/ and include/zinc/ and have different
> maintainers.
So we will have two competing crypo stacks in the kernel?
Having a lightweight crypto API is a good thing but I really don't like the idea
of having zinc parallel to the existing crypto stack.
And I strongly vote that Herbert Xu shall remain the maintainer of the whole
crypto system (including zinc!) in the kernel.
--
Thanks,
//richard
^ permalink raw reply
* Re: [PATCH] SUNRPC: use cmpxchg64() in gss_seq_send64_fetch_and_inc()
From: Trond Myklebust @ 2018-10-05 13:36 UTC (permalink / raw)
To: arnd@arndb.de
Cc: linux-kernel@vger.kernel.org, jlayton@kernel.org,
bfields@fieldses.org, linux-nfs@vger.kernel.org,
james@ettle.org.uk, anna.schumaker@netapp.com,
netdev@vger.kernel.org, davem@davemloft.net,
stephen@networkplumber.org
In-Reply-To: <20181002205809.2300654-1-arnd@arndb.de>
On Tue, 2018-10-02 at 22:57 +0200, Arnd Bergmann wrote:
> The newly introduced gss_seq_send64_fetch_and_inc() fails to build on
> 32-bit architectures:
>
> net/sunrpc/auth_gss/gss_krb5_seal.c:144:14: note: in expansion of
> macro 'cmpxchg'
> seq_send = cmpxchg(&ctx->seq_send64, old, old + 1);
> ^~~~~~~
> arch/x86/include/asm/cmpxchg.h:128:3: error: call to
> '__cmpxchg_wrong_size' declared with attribute error: Bad argument
> size for cmpxchg
> __cmpxchg_wrong_size(); \
>
> As the message tells us, cmpxchg() cannot be used on 64-bit
> arguments,
> that's what cmpxchg64() does.
>
> Fixes: 571ed1fd2390 ("SUNRPC: Replace krb5_seq_lock with a lockless
> scheme")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> net/sunrpc/auth_gss/gss_krb5_seal.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/sunrpc/auth_gss/gss_krb5_seal.c
> b/net/sunrpc/auth_gss/gss_krb5_seal.c
> index 92594681d619..5775b9805bdc 100644
> --- a/net/sunrpc/auth_gss/gss_krb5_seal.c
> +++ b/net/sunrpc/auth_gss/gss_krb5_seal.c
> @@ -141,7 +141,7 @@ gss_seq_send64_fetch_and_inc(struct krb5_ctx
> *ctx)
>
> do {
> old = seq_send;
> - seq_send = cmpxchg(&ctx->seq_send64, old, old + 1);
> + seq_send = cmpxchg64(&ctx->seq_send64, old, old + 1);
> } while (old != seq_send);
> return seq_send;
> }
Thanks Arndt! Applied.
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com
^ permalink raw reply
* [PATCH] gigaset: asyncdata: mark expected switch fall-throughs
From: Gustavo A. R. Silva @ 2018-10-05 13:29 UTC (permalink / raw)
To: Paul Bolle, Karsten Keil
Cc: gigaset307x-common, netdev, linux-kernel, Gustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Notice that in this particular case, I replaced the
" --v-- fall through --v-- " comment with a proper
"fall through", which is what GCC is expecting to find.
Addresses-Coverity-ID: 1364476 ("Missing break in switch")
Addresses-Coverity-ID: 1364477 ("Missing break in switch")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/isdn/gigaset/asyncdata.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/isdn/gigaset/asyncdata.c b/drivers/isdn/gigaset/asyncdata.c
index bc20855..c0cbee0 100644
--- a/drivers/isdn/gigaset/asyncdata.c
+++ b/drivers/isdn/gigaset/asyncdata.c
@@ -65,7 +65,7 @@ static unsigned cmd_loop(unsigned numbytes, struct inbuf_t *inbuf)
cs->respdata[0] = 0;
break;
}
- /* --v-- fall through --v-- */
+ /* fall through */
case '\r':
/* end of message line, pass to response handler */
if (cbytes >= MAX_RESP_SIZE) {
@@ -100,7 +100,7 @@ static unsigned cmd_loop(unsigned numbytes, struct inbuf_t *inbuf)
goto exit;
}
/* quoted or not in DLE mode: treat as regular data */
- /* --v-- fall through --v-- */
+ /* fall through */
default:
/* append to line buffer if possible */
if (cbytes < MAX_RESP_SIZE)
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next v6 00/23] WireGuard: Secure Network Tunnel
From: Jason A. Donenfeld @ 2018-10-05 13:13 UTC (permalink / raw)
To: Eric Biggers
Cc: Ard Biesheuvel, Herbert Xu, LKML, Netdev,
Linux Crypto Mailing List, David Miller, Greg Kroah-Hartman
In-Reply-To: <20181003064951.GC745@sol.localdomain>
Hi Eric,
On Wed, Oct 3, 2018 at 8:49 AM Eric Biggers <ebiggers@kernel.org> wrote:
> It's not really about the name, though. It's actually about the whole way of
> thinking about the submission. Is it a new special library with its own things
> going on, or is it just some crypto helper functions? It's really just the
> latter, but you've been presenting it as the former
No, it really is its own thing with important differences from the
present crypto api. Zinc's focus is on simplicity and clarity. To the
extent that we're at all tangled with the current crypto api, the goal
is to untangle as much as possible. It intends to be a small and
lightweight set of routines, whose relationships are obvious, and with
this direct and to the point organization, as well as work with the larger
cryptography community and with academia to invite collaboration. With
this comes a different way of maintaining it, with higher standards
and a preference for different implementations than the current
situation. With Zinc, you have an obvious series of C function calls
composing the whole thing, without complicated indirection. It's
something that could be trivially lifted out into a userspace library,
and used broadly, for example -- something I'll probably do at some
point. That's a bit of a design change to the current crypto api, and
sprinkling some direct function calls within the current crypto api's
complicated enterprise situation would only kick the can further down
the road, as much complexity would still remain. The goal is to move
away from behemoth enterprise APIs, and large and complex codebases to
a simple and direct way of doing things. This desire to untangle, to
start from a simpler base, and to generally do things differently
means it will go into lib/zinc/ and include/zinc/ and have different
maintainers.
Jason
^ permalink raw reply
* Re: [PATCH bpf-next] bpf: emit audit messages upon successful prog load and unload
From: Jiri Olsa @ 2018-10-05 6:14 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Jesper Dangaard Brouer, Daniel Borkmann, ast, netdev, Jiri Olsa,
acme
In-Reply-To: <20181004221013.o3c5junwfyaasuxo@ast-mbp.dhcp.thefacebook.com>
On Thu, Oct 04, 2018 at 03:10:15PM -0700, Alexei Starovoitov wrote:
> On Thu, Oct 04, 2018 at 10:22:31PM +0200, Jesper Dangaard Brouer wrote:
> > On Thu, 4 Oct 2018 21:41:17 +0200 Daniel Borkmann <daniel@iogearbox.net> wrote:
> >
> > > On 10/04/2018 08:39 PM, Jesper Dangaard Brouer wrote:
> > > > On Thu, 4 Oct 2018 10:11:43 -0700 Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> > > >> On Thu, Oct 04, 2018 at 03:50:38PM +0200, Daniel Borkmann wrote:
> > [...]
> > > >>
> > > >> If the purpose of the patch is to give user space visibility into
> > > >> bpf prog load/unload as a notification, then I completely agree that
> > > >> some notification mechanism is necessary.
> > >
> > > Yeah, I did only regard it as only that, nothing more. Some means
> > > of timeline and notification that can be kept in a record in user
> > > space and later retrieved e.g. for introspection on what has been
> > > loaded.
> > >
> > > >> I've started working on such mechanism via perf ring buffer which is
> > > >> the fastest mechanism we have in the kernel so far.
> > > >> See long discussion here: https://patchwork.ozlabs.org/patch/971970/
cool, could you please CC me if there's another version
of that patchset?
> > >
> > > That one is definitely needed in any case to resolve the kallsyms
> > > limitations, and it does have overlap in that in either case we
> > > want to look at past BPF programs that have been unloaded in the
> > > meantime, so I don't have a strong preference either way, and the
> > > former is needed in any case. Though thought was that audit might
> > > be an option for those not running profiling daemons 24/7, but
> > > presumably bpftool could be extended to record these events as
> > > well if we don't want to reuse audit infra.
> >
> > Yes, exactly, I don't want to run a profiling daemon 24/7 to record
> > these events. I do acknowledge that this perf event is relevant,
> > especially for catching the kernel symbols (I need that myself), but it
> > does not cover my use-case.
> >
> > My use-case is to 24/7 collect and keep records in userspace, and have a
> > timeline of these notifications, for later retrieval. The idea is that
> > our support engineers can look at these records when troubleshooting
> > the system. And the plan is also to collect these records as part of
> > our sosreport tool, which is part of the support case.
>
> I don't think you're implying that prog load/unload should be spamming dmesg
> and auditd not even running...
I think the problem Jesper implied is that in order to collect
those logs you'll need perf tool running all the time.. which
it's not equipped for yet
jirka
> Also auditd has to be changed to support retrieving prog related info (like license)
> via sys_bpf system call when it sees prog_id.
> Since it has to change it can just as easily use perf ring buffer
> to receive notifications.
> So we solve notification problem once and all user space tools can use it.
>
^ permalink raw reply
* Re: [PATCH] net/packet: fix packet drop as of virtio gso
From: David Miller @ 2018-10-05 5:23 UTC (permalink / raw)
To: jianfeng.tan; +Cc: netdev, jasowang, mst
In-Reply-To: <20180929154127.20867-1-jianfeng.tan@linux.alibaba.com>
From: Jianfeng Tan <jianfeng.tan@linux.alibaba.com>
Date: Sat, 29 Sep 2018 15:41:27 +0000
> When we use raw socket as the vhost backend, a packet from virito with
> gso offloading information, cannot be sent out in later validaton at
> xmit path, as we did not set correct skb->protocol which is further used
> for looking up the gso function.
>
> To fix this, we set this field according to virito hdr information.
>
> Fixes: e858fae2b0b8f4 ("virtio_net: use common code for virtio_net_hdr and skb GSO conversion")
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Jianfeng Tan <jianfeng.tan@linux.alibaba.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH v2 0/5] Introducing ixgbe AF_XDP ZC support
From: Björn Töpel @ 2018-10-05 4:59 UTC (permalink / raw)
To: Jesper Dangaard Brouer, Björn Töpel
Cc: jeffrey.t.kirsher, intel-wired-lan, magnus.karlsson,
magnus.karlsson, ast, daniel, netdev, u9012063, tuc,
jakub.kicinski
In-Reply-To: <20181004231848.33efd81f@redhat.com>
On 2018-10-04 23:18, Jesper Dangaard Brouer wrote:
> I see similar performance numbers, but my system can crash with 'txonly'.
Thanks for finding this, Jesper!
Can you give me your "lspci -vvv" dump of your NIC, so I know what ixgbe
flavor you've got?
I'll dig into it right away.
Björn
^ permalink raw reply
* Re: [PATCH] openvswitch: load NAT helper
From: David Miller @ 2018-10-05 4:55 UTC (permalink / raw)
To: fbl; +Cc: netfilter-devel, netdev, dev, pshelar
In-Reply-To: <20180928175128.13126-1-fbl@redhat.com>
From: Flavio Leitner <fbl@redhat.com>
Date: Fri, 28 Sep 2018 14:51:28 -0300
> Load the respective NAT helper module if the flow uses it.
>
> Signed-off-by: Flavio Leitner <fbl@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/5] net: Consolidate metrics handling for ipv4 and ipv6
From: David Miller @ 2018-10-05 4:55 UTC (permalink / raw)
To: dsahern; +Cc: netdev, weiwan, sd, xiyou.wangcong, dsahern
In-Reply-To: <20181005030755.31217-1-dsahern@kernel.org>
From: David Ahern <dsahern@kernel.org>
Date: Thu, 4 Oct 2018 20:07:50 -0700
> From: David Ahern <dsahern@gmail.com>
>
> As part of the IPv6 fib info refactoring, the intent was to make metrics
> handling for ipv6 identical to ipv4. One oversight in ip6_dst_destroy
> led to confusion and a couple of incomplete attempts at finding and
> fixing the resulting memory leak which was ultimately resolved by
> ce7ea4af0838 ("ipv6: fix memory leak on dst->_metrics").
>
> Refactor metrics hanlding make the code really identical for v4 and v6,
> and add a few test cases.
Looks nice, series applied, thanks David.
^ 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