* Re: pull request (net): ipsec 2017-04-19
From: David Miller @ 2017-04-20 20:20 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <1492578636-621-1-git-send-email-steffen.klassert@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Wed, 19 Apr 2017 07:10:34 +0200
> Two fixes for af_key:
>
> 1) Add a lock to key dump to prevent a NULL pointer dereference.
> From Yuejie Shi.
>
> 2) Fix slab-out-of-bounds in parse_ipsecrequests.
> From Herbert Xu.
>
> Please pull or let me know if there are problems.
Pulled, thanks Steffen.
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: update entry for TI's CPSW driver
From: David Miller @ 2017-04-20 20:21 UTC (permalink / raw)
To: nsekhar; +Cc: grygorii.strashko, linux-omap, netdev
In-Reply-To: <8c950dd8642b7b8d778da36ea944674c9cab587c.1492590838.git.nsekhar@ti.com>
From: Sekhar Nori <nsekhar@ti.com>
Date: Wed, 19 Apr 2017 14:08:24 +0530
> Mugunthan V N, who was reviewing TI's CPSW driver patches is
> not working for TI anymore and wont be reviewing patches for
> that driver.
>
> Drop Mugunthan as the maintiainer for this driver.
>
> Grygorii continues to be a reviewer. Dave Miller applies the
> patches directly and adding a maintainer is actually
> misleading since get_maintainer.pl script stops suggesting
> that Dave Miller be copied.
>
> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next] qede: allocate enough data for ->arfs_fltr_bmap
From: David Miller @ 2017-04-20 20:25 UTC (permalink / raw)
To: dan.carpenter
Cc: Yuval.Mintz, Chopra, Manish.Chopra, Ariel.Elior, everest-linux-l2,
netdev, kernel-janitors
In-Reply-To: <20170419095432.GA4266@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Wed, 19 Apr 2017 12:54:33 +0300
> We've got the number of longs, yes, but we should multiply by
> sizeof(long) to get the number of bytes needed.
>
> Fixes: e4917d46a653 ("qede: Add aRFS support")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net/mlx5e: IPoIB, Fix error handling in mlx5_rdma_netdev_alloc()
From: David Miller @ 2017-04-20 20:28 UTC (permalink / raw)
To: dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA
Cc: saeedm-VPRAkNaXOzVWk0Htik3J/w, matanb-VPRAkNaXOzVWk0Htik3J/w,
leonro-VPRAkNaXOzVWk0Htik3J/w, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
kernel-janitors-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170419095914.GB4266@mwanda>
From: Dan Carpenter <dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Date: Wed, 19 Apr 2017 12:59:15 +0300
> The labels were out of order, so it either could result in an Oops or a
> leak.
>
> Fixes: 48935bbb7ae8 ("net/mlx5e: IPoIB, Add netdevice profile skeleton")
> Signed-off-by: Dan Carpenter <dan.carpenter-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4] smsc95xx: Use skb_cow_head to deal with cloned skbs
From: David Miller @ 2017-04-20 20:28 UTC (permalink / raw)
To: james.hughes; +Cc: netdev, steve.glendinning, UNGLinuxDriver
In-Reply-To: <20170419101340.27929-1-james.hughes@raspberrypi.org>
From: James Hughes <james.hughes@raspberrypi.org>
Date: Wed, 19 Apr 2017 11:13:40 +0100
> The driver was failing to check that the SKB wasn't cloned
> before adding checksum data.
> Replace existing handling to extend/copy the header buffer
> with skb_cow_head.
>
> Signed-off-by: James Hughes <james.hughes@raspberrypi.org>
Applied.
^ permalink raw reply
* Re: [PATCH net 0/4] qed: Dcbx bug fixes
From: David Miller @ 2017-04-20 20:29 UTC (permalink / raw)
To: sudarsana.kalluru; +Cc: netdev, Yuval.Mintz
In-Reply-To: <20170419101955.26444-1-sudarsana.kalluru@cavium.com>
From: Sudarsana Reddy Kalluru <sudarsana.kalluru@cavium.com>
Date: Wed, 19 Apr 2017 03:19:51 -0700
> The series has set of bug fixes for dcbx implementation of qed driver.
> Please consider applying this to 'net' branch.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH v3 net] net sched actions: allocate act cookie early
From: David Miller @ 2017-04-20 20:32 UTC (permalink / raw)
To: w.bumiller; +Cc: netdev, jhs, xiyou.wangcong
In-Reply-To: <20170420120826.7641-1-w.bumiller@proxmox.com>
From: Wolfgang Bumiller <w.bumiller@proxmox.com>
Date: Thu, 20 Apr 2017 14:08:26 +0200
> Policing filters do not use the TCA_ACT_* enum and the tb[]
> nlattr array in tcf_action_init_1() doesn't get filled for
> them so we should not try to look for a TCA_ACT_COOKIE
> attribute in the then uninitialized array.
> The error handling in cookie allocation then calls
> tcf_hash_release() leading to invalid memory access later
> on.
> Additionally, if cookie allocation fails after an already
> existing non-policing filter has successfully been changed,
> tcf_action_release() should not be called, also we would
> have to roll back the changes in the error handling, so
> instead we now allocate the cookie early and assign it on
> success at the end.
>
> CVE-2017-7979
> Fixes: 1045ba77a596 ("net sched actions: Add support for user cookies")
> Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [net-next 04/14] i40e: dump VF information in debugfs
From: David Miller @ 2017-04-20 20:35 UTC (permalink / raw)
To: Yuval.Mintz
Cc: jiri, gerlitz.or, jeffrey.t.kirsher, mitch.a.williams, netdev,
nhorman, sassmann, jogreene, Chad.Dupuis, Manish.Rangankar
In-Reply-To: <BL2PR07MB23064B547F325DD002E513FC8D1B0@BL2PR07MB2306.namprd07.prod.outlook.com>
From: "Mintz, Yuval" <Yuval.Mintz@cavium.com>
Date: Thu, 20 Apr 2017 20:12:59 +0000
> I surely wouldn't want to write a million lines of code just to
> provide such a detailed abstraction.
So now the argument has gone from "it's not possible" to "it's going
to be a HUGE amount of code."
I wonder what the next argument will be when I shoot this one down.
If you simply don't want to do the hard work necessary to implement
this properly, which is fine, just say so.
^ permalink raw reply
* Re: [PATCH v2 0/3] uapi glibc compat: fix musl libc compatibility
From: David Miller @ 2017-04-20 20:36 UTC (permalink / raw)
To: dwmw2
Cc: hauke, netdev, linux-kernel, jarod, jogo, david.heidelberger,
maillist-linux, mikko.rapeli
In-Reply-To: <1492719277.8404.16.camel@infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
Date: Thu, 20 Apr 2017 21:14:37 +0100
> I agree, except I don't think you're going far enough. Those "standard
> names" you mention... some of this stuff actually depends on __GLIBC__,
> and *that* isn't right either.
Yep, that's something that needs correcting.
^ permalink raw reply
* Re: [PATCH net-next 00/16] Mellanox, mlx5 RDMA net device support
From: Doug Ledford @ 2017-04-20 20:45 UTC (permalink / raw)
To: Leon Romanovsky
Cc: David Miller, saeedm-VPRAkNaXOzVWk0Htik3J/w,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
erezsh-VPRAkNaXOzVWk0Htik3J/w,
jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/,
niranjana.vishwanathapura-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <20170420184955.GU14088-U/DQcQFIOTAAJjI8aNfphQ@public.gmane.org>
On Thu, 2017-04-20 at 21:49 +0300, Leon Romanovsky wrote:
> On Thu, Apr 20, 2017 at 02:41:17PM -0400, Doug Ledford wrote:
> >
> > On Mon, 2017-04-17 at 11:08 -0400, David Miller wrote:
> > >
> > > From: Saeed Mahameed <saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> > > Date: Thu, 13 Apr 2017 06:36:50 +0300
> > >
> > > >
> > > > This series provides the lower level mlx5 support of RDMA
> > > > netdevice
> > > > creation API [1] suggested and introduced by Intel's HFI OPA
> > > > VNIC
> > > > netdevice driver [2], to enable IPoIB mlx5 RDMA netdevice
> > > > creation.
> > >
> > > Series applied to net-next.
> >
> > I've pulled Dave's net-next into a branch in my tree for the IPoIB
> > patches to go on top of so that way it can hold the final touchup
> > patch
> > without any conflicts anywhere.
>
> Thanks,
>
> How and when do you want us to forward it?
The branch in question is already pushed for 0day and linux-next
testing, so you can send the fixup patch to linux-rdma based upon my
k.o/for-4.12-rdma-netdevice branch any time.
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [net-next 04/14] i40e: dump VF information in debugfs
From: Mintz, Yuval @ 2017-04-20 20:50 UTC (permalink / raw)
To: David Miller
Cc: jiri@resnulli.us, gerlitz.or@gmail.com,
jeffrey.t.kirsher@intel.com, mitch.a.williams@intel.com,
netdev@vger.kernel.org, nhorman@redhat.com, sassmann@redhat.com,
jogreene@redhat.com, Dupuis, Chad, Rangankar, Manish
In-Reply-To: <20170420.163548.662307112452546016.davem@davemloft.net>
> > I surely wouldn't want to write a million lines of code just to
> > provide such a detailed abstraction.
>
> So now the argument has gone from "it's not possible" to "it's going to be a
> HUGE amount of code."
Nothing here's is strictly impossible - you can always create a simulated HW
model in SW, and have a one-to-one mapping with the HW entities.
But "unreasonable amount of code" comes very close to it.
> I wonder what the next argument will be when I shoot this one down.
>
> If you simply don't want to do the hard work necessary to implement this
> properly, which is fine, just say so.
Nope, I don't mind doing the work. What I would appreciate is some
constructive suggestions on a seemingly feasible approach that might work.
I feel like I've been bashed enough for one day. :-)
^ permalink raw reply
* Re: [net-next 04/14] i40e: dump VF information in debugfs
From: David Miller @ 2017-04-20 20:54 UTC (permalink / raw)
To: Yuval.Mintz
Cc: jiri, gerlitz.or, jeffrey.t.kirsher, mitch.a.williams, netdev,
nhorman, sassmann, jogreene, Chad.Dupuis, Manish.Rangankar
In-Reply-To: <BL2PR07MB230655E4217E619BABCA54D18D1B0@BL2PR07MB2306.namprd07.prod.outlook.com>
From: "Mintz, Yuval" <Yuval.Mintz@cavium.com>
Date: Thu, 20 Apr 2017 20:50:55 +0000
> Nope, I don't mind doing the work. What I would appreciate is some
> constructive suggestions on a seemingly feasible approach that might work.
> I feel like I've been bashed enough for one day. :-)
Well, it seems like the thing that you want to do is pull items out of
an object. Start with that as an abstraction and see where it goes.
^ permalink raw reply
* Order
From: Damian Colins @ 2017-04-19 10:53 UTC (permalink / raw)
To: netdev
Hi ,
I would like to place an order for some items which I want to know the below :
Do you ship to Liechtenstein ?
Do you accept Credit Card payment
Also send me your current product price list.
Thanks
^ permalink raw reply
* Re: [PATCH] Fix values type used in test_maps
From: Daniel Borkmann @ 2017-04-20 21:24 UTC (permalink / raw)
To: David Miller, ast; +Cc: borkmann, netdev
In-Reply-To: <20170420.152016.2219427430519868937.davem@davemloft.net>
On 04/20/2017 09:20 PM, David Miller wrote:
>
> Maps of per-cpu type have their value element size adjusted to 8 if it
> is specified smaller during various map operations.
>
> This makes test_maps as a 32-bit binary fail, in fact the kernel
> writes past the end of the value's array on the user's stack.
>
> To be quite honest, I think the kernel should reject creation of a
> per-cpu map that doesn't have a value size of at least 8 if that's
> what the kernel is going to silently adjust to later.
It's unintuitive, agree, and it's in fact a round_up(value_size, 8),
so rejecting a value size smaller than 8 doesn't really help; commit
15a07b33814d ("bpf: add lookup/update support for per-cpu hash and
array maps") explained the rationale a bit. Hmm, we should probably
move at least the bpf_num_possible_cpus() and round_up(val_size, 8)
calculation as a single wrapper function to be used for determining
the array size into bpf_util.h, so that it's slightly easier to deal
with.
> If the user passed something smaller, it is a sizeof() calcualtion
> based upon the type they will actually use (just like in this testcase
> code) in later calls to the map operations.
Fixes: df570f577231 ("samples/bpf: unit test for BPF_MAP_TYPE_PERCPU_ARRAY")
> Signed-off-by: David S. Miller <davem@davemloft.net>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Thanks!
^ permalink raw reply
* Re: [PATCH] dp83640: don't recieve time stamps twice
From: Richard Cochran @ 2017-04-20 21:30 UTC (permalink / raw)
To: David Miller
Cc: Stefan.Sorensen, dan.carpenter, netdev, f.fainelli, andrew,
kernel-janitors
In-Reply-To: <20170420.160227.1855463512293087492.davem@davemloft.net>
On Thu, Apr 20, 2017 at 04:02:27PM -0400, David Miller wrote:
> Oops, I read this too late.
>
> I already applied and pushed out Dan's fix.
No problem, i'll submit a patch on top of that to move the netif calls
out of the spin-locked regions.
Thanks,
Richard
^ permalink raw reply
* [GIT] [4.12] NFC update
From: Samuel Ortiz @ 2017-04-20 21:37 UTC (permalink / raw)
To: David S. Miller; +Cc: Linux Wireless, netdev-u79uwXL29TY76Z2rM5mHXA, Linux NFC
Hi David,
This is the NFC pull request for 4.12. We have:
- Improvements for the pn533 command queue handling and device
registration order.
- Removal of platform data for the pn544 and st21nfca drivers.
- Additional device tree options to support more trf7970a hardware options.
- Support for Sony's RC-S380P through the port100 driver.
- Removal of the obsolte nfcwilink driver.
- Headers inclusion cleanups (miscdevice.h, unaligned.h) for many drivers.
The following changes since commit eefe06e8ceea88f8397a8df0880ab5ca28dcada6:
Merge branch 'bpf-prog-testing-framework' (2017-04-01 12:45:58 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sameo/nfc-next.git tags/nfc-next-4.12-1
for you to fetch changes up to 4ea206395d3aede32bab94a75ec573530486fa44:
nfc: fix get_unaligned_...() misuses (2017-04-17 00:42:22 +0200)
----------------------------------------------------------------
NFC 4.12 pull request
This is the NFC pull request for 4.12. We have:
- Improvements for the pn533 command queue handling and device
registration order.
- Removal of platform data for the pn544 and st21nfca drivers.
- Additional device tree options to support more trf7970a hardware options.
- Support for Sony's RC-S380P through the port100 driver.
- Removal of the obsolte nfcwilink driver.
- Headers inclusion cleanups (miscdevice.h, unaligned.h) for many drivers.
----------------------------------------------------------------
Al Viro (1):
nfc: fix get_unaligned_...() misuses
Andrey Rusalin (3):
NFC: pn533: change order of free_irq and dev unregistration
NFC: pn533: improve cmd queue handling
NFC: pn533: change order operations in dev registation
Andy Shevchenko (12):
NFC: pn544: Get rid of platform data
NFC: pn544: Convert to use GPIO descriptor
NFC: pn544: Convert to use devm_request_threaded_irq()
NFC: pn544: Add GPIO ACPI mapping table
NFC: pn544: Get rid of code duplication in ->probe()
NFC: st21nfca: Fix obvious typo when check error code
NFC: st21nfca: Get rid of platform data
NFC: st21nfca: Get rid of "interesting" use of interrupt polarity
NFC: st21nfca: Covert to use GPIO descriptor
NFC: st21nfca: Use unified device property API meaningfully
NFC: netlink: Use error code from nfc_activate_target()
NFC: Add nfc_dbg() macro
Christophe JAILLET (1):
NFC: st21nfca: Fix potential memory leak
Corentin Labbe (3):
nfc: nxp-nci: Remove unneeded linux/miscdevice.h include
nfc: pn544: Remove unneeded linux/miscdevice.h include
nfc: st21nfca: Remove unneeded linux/miscdevice.h include
Dan Carpenter (1):
NFC: nfcmrvl: double free on error path
Geliang Tang (1):
NFC: nfcmrvl: drop duplicate header gpio.h
Geoff Lansberry (2):
NFC: trf7970a: add device tree option for 27MHz clock
NFC: trf7970a: Add device tree option of 1.8 Volt IO voltage
Guan Ben (1):
NFC: Make EN2 pin optional in the TRF7970A driver
Guenter Roeck (1):
NFC: nxp-nci: Include unaligned.h instead of access_ok.h
Michał Mirosław (1):
NFC: pn533: use constant off-stack buffer for sending acks
Nicholas Mc Guire (1):
nfc: nxp-nci: use msleep for long delays
OGAWA Hirofumi (4):
nfc: Add support RC-S380P to port100
nfc: Send same info for both of NFC_CMD_GET_DEVICE and NFC_EVENT_DEVICE_ADDED
nfc: Fix RC-S380* needs zero-length packet
nfc: Fix hangup of RC-S380* in port100_send_ack()
Rob Herring (1):
NFC: remove TI nfcwilink driver
Samuel Ortiz (1):
MAINTAINERS: Remove Lauro and Aloisio from the NFC maintainers list
Sudip Mukherjee (1):
nfc: fdp: fix NULL pointer dereference
Tobias Klauser (1):
NFC: nfcmrvl: Include unaligned.h instead of access_ok.h
.../devicetree/bindings/net/nfc/trf7970a.txt | 8 +-
MAINTAINERS | 2 -
drivers/nfc/Kconfig | 11 -
drivers/nfc/Makefile | 1 -
drivers/nfc/fdp/i2c.c | 6 +-
drivers/nfc/nfcmrvl/fw_dnld.c | 7 +-
drivers/nfc/nfcmrvl/spi.c | 6 +-
drivers/nfc/nfcwilink.c | 578 ---------------------
drivers/nfc/nxp-nci/firmware.c | 2 +-
drivers/nfc/nxp-nci/i2c.c | 7 +-
drivers/nfc/pn533/i2c.c | 34 +-
drivers/nfc/pn533/pn533.c | 82 +--
drivers/nfc/pn533/pn533.h | 1 +
drivers/nfc/pn533/usb.c | 8 +-
drivers/nfc/pn544/i2c.c | 221 ++------
drivers/nfc/port100.c | 44 +-
drivers/nfc/st21nfca/core.c | 12 +-
drivers/nfc/st21nfca/i2c.c | 123 +----
drivers/nfc/trf7970a.c | 98 +++-
include/linux/platform_data/pn544.h | 43 --
include/linux/platform_data/st21nfca.h | 33 --
include/net/nfc/nfc.h | 1 +
net/nfc/netlink.c | 24 +-
23 files changed, 289 insertions(+), 1063 deletions(-)
delete mode 100644 drivers/nfc/nfcwilink.c
delete mode 100644 include/linux/platform_data/pn544.h
delete mode 100644 include/linux/platform_data/st21nfca.h
^ permalink raw reply
* Re: [PATCHv2 next] bonding: fix wq initialization for links created via netlink
From: Andy Gospodarek @ 2017-04-20 21:46 UTC (permalink / raw)
To: Mahesh Bandewar
Cc: Jay Vosburgh, Veaceslav Falico, Nikolay Aleksandrov, David Miller,
Eric Dumazet, Joe Stringer, netdev, Mahesh Bandewar
In-Reply-To: <20170420194924.20829-1-mahesh@bandewar.net>
On Thu, Apr 20, 2017 at 12:49:24PM -0700, Mahesh Bandewar wrote:
> From: Mahesh Bandewar <maheshb@google.com>
>
> Earlier patch 4493b81bea ("bonding: initialize work-queues during
> creation of bond") moved the work-queue initialization from bond_open()
> to bond_create(). However this caused the link those are created using
> netlink 'create bond option' (ip link add bondX type bond); create the
> new trunk without initializing work-queues. Prior to the above mentioned
> change, ndo_open was in both paths and things worked correctly. The
> consequence is visible in the report shared by Joe Stringer -
>
> I've noticed that this patch breaks bonding within namespaces if
> you're not careful to perform device cleanup correctly.
>
> Here's my repro script, you can run on any net-next with this patch
> and you'll start seeing some weird behaviour:
>
> ip netns add foo
> ip li add veth0 type veth peer name veth0+ netns foo
> ip li add veth1 type veth peer name veth1+ netns foo
> ip netns exec foo ip li add bond0 type bond
> ip netns exec foo ip li set dev veth0+ master bond0
> ip netns exec foo ip li set dev veth1+ master bond0
> ip netns exec foo ip addr add dev bond0 192.168.0.1/24
> ip netns exec foo ip li set dev bond0 up
> ip li del dev veth0
> ip li del dev veth1
>
> The second to last command segfaults, last command hangs. rtnl is now
> permanently locked. It's not a problem if you take bond0 down before
> deleting veths, or delete bond0 before deleting veths. If you delete
> either end of the veth pair as per above, either inside or outside the
> namespace, it hits this problem.
>
> Here's some kernel logs:
> [ 1221.801610] bond0: Enslaving veth0+ as an active interface with an up link
> [ 1224.449581] bond0: Enslaving veth1+ as an active interface with an up link
> [ 1281.193863] bond0: Releasing backup interface veth0+
> [ 1281.193866] bond0: the permanent HWaddr of veth0+ -
> 16:bf:fb:e0:b8:43 - is still in use by bond0 - set the HWaddr of
> veth0+ to a different address to avoid conflicts
> [ 1281.193867] ------------[ cut here ]------------
> [ 1281.193873] WARNING: CPU: 0 PID: 2024 at kernel/workqueue.c:1511
> __queue_delayed_work+0x13f/0x150
> [ 1281.193873] Modules linked in: bonding veth openvswitch nf_nat_ipv6
> nf_nat_ipv4 nf_nat autofs4 nfsd auth_rpcgss nfs_acl binfmt_misc nfs
> lockd grace sunrpc fscache ppdev vmw_balloon coretemp psmouse
> serio_raw vmwgfx ttm drm_kms_helper vmw_vmci netconsole parport_pc
> configfs drm i2c_piix4 fb_sys_fops syscopyarea sysfillrect sysimgblt
> shpchp mac_hid nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4
> nf_defrag_ipv4 nf_conntrack libcrc32c lp parport hid_generic usbhid
> hid mptspi mptscsih e1000 mptbase ahci libahci
> [ 1281.193905] CPU: 0 PID: 2024 Comm: ip Tainted: G W
> 4.10.0-bisect-bond-v0.14 #37
> [ 1281.193906] Hardware name: VMware, Inc. VMware Virtual
> Platform/440BX Desktop Reference Platform, BIOS 6.00 09/30/2014
> [ 1281.193906] Call Trace:
> [ 1281.193912] dump_stack+0x63/0x89
> [ 1281.193915] __warn+0xd1/0xf0
> [ 1281.193917] warn_slowpath_null+0x1d/0x20
> [ 1281.193918] __queue_delayed_work+0x13f/0x150
> [ 1281.193920] queue_delayed_work_on+0x27/0x40
> [ 1281.193929] bond_change_active_slave+0x25b/0x670 [bonding]
> [ 1281.193932] ? synchronize_rcu_expedited+0x27/0x30
> [ 1281.193935] __bond_release_one+0x489/0x510 [bonding]
> [ 1281.193939] ? addrconf_notify+0x1b7/0xab0
> [ 1281.193942] bond_netdev_event+0x2c5/0x2e0 [bonding]
> [ 1281.193944] ? netconsole_netdev_event+0x124/0x190 [netconsole]
> [ 1281.193947] notifier_call_chain+0x49/0x70
> [ 1281.193948] raw_notifier_call_chain+0x16/0x20
> [ 1281.193950] call_netdevice_notifiers_info+0x35/0x60
> [ 1281.193951] rollback_registered_many+0x23b/0x3e0
> [ 1281.193953] unregister_netdevice_many+0x24/0xd0
> [ 1281.193955] rtnl_delete_link+0x3c/0x50
> [ 1281.193956] rtnl_dellink+0x8d/0x1b0
> [ 1281.193960] rtnetlink_rcv_msg+0x95/0x220
> [ 1281.193962] ? __kmalloc_node_track_caller+0x35/0x280
> [ 1281.193964] ? __netlink_lookup+0xf1/0x110
> [ 1281.193966] ? rtnl_newlink+0x830/0x830
> [ 1281.193967] netlink_rcv_skb+0xa7/0xc0
> [ 1281.193969] rtnetlink_rcv+0x28/0x30
> [ 1281.193970] netlink_unicast+0x15b/0x210
> [ 1281.193971] netlink_sendmsg+0x319/0x390
> [ 1281.193974] sock_sendmsg+0x38/0x50
> [ 1281.193975] ___sys_sendmsg+0x25c/0x270
> [ 1281.193978] ? mem_cgroup_commit_charge+0x76/0xf0
> [ 1281.193981] ? page_add_new_anon_rmap+0x89/0xc0
> [ 1281.193984] ? lru_cache_add_active_or_unevictable+0x35/0xb0
> [ 1281.193985] ? __handle_mm_fault+0x4e9/0x1170
> [ 1281.193987] __sys_sendmsg+0x45/0x80
> [ 1281.193989] SyS_sendmsg+0x12/0x20
> [ 1281.193991] do_syscall_64+0x6e/0x180
> [ 1281.193993] entry_SYSCALL64_slow_path+0x25/0x25
> [ 1281.193995] RIP: 0033:0x7f6ec122f5a0
> [ 1281.193995] RSP: 002b:00007ffe69e89c48 EFLAGS: 00000246 ORIG_RAX:
> 000000000000002e
> [ 1281.193997] RAX: ffffffffffffffda RBX: 00007ffe69e8dd60 RCX: 00007f6ec122f5a0
> [ 1281.193997] RDX: 0000000000000000 RSI: 00007ffe69e89c90 RDI: 0000000000000003
> [ 1281.193998] RBP: 00007ffe69e89c90 R08: 0000000000000000 R09: 0000000000000003
> [ 1281.193999] R10: 00007ffe69e89a10 R11: 0000000000000246 R12: 0000000058f14b9f
> [ 1281.193999] R13: 0000000000000000 R14: 00000000006473a0 R15: 00007ffe69e8e450
> [ 1281.194001] ---[ end trace 713a77486cbfbfa3 ]---
>
> Fixes: 4493b81bea ("bonding: initialize work-queues during creation of bond")
> Reported-by: Joe Stringer <joe@ovn.org>
> Tested-by: Joe Stringer <joe@ovn.org>
> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
Thanks for the quick turnaround on this, Mahesh!
Acked-by: Andy Gospodarek <andy@greyhouse.net>
> ---
> v1 -> v2 : fixed 'if' condition
>
> drivers/net/bonding/bond_main.c | 2 +-
> drivers/net/bonding/bond_netlink.c | 5 +++++
> include/net/bonding.h | 1 +
> 3 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 6bd3b50faf48..e549bf6f5cac 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -3243,7 +3243,7 @@ u32 bond_xmit_hash(struct bonding *bond, struct sk_buff *skb)
>
> /*-------------------------- Device entry points ----------------------------*/
>
> -static void bond_work_init_all(struct bonding *bond)
> +void bond_work_init_all(struct bonding *bond)
> {
> INIT_DELAYED_WORK(&bond->mcast_work,
> bond_resend_igmp_join_requests_delayed);
> diff --git a/drivers/net/bonding/bond_netlink.c b/drivers/net/bonding/bond_netlink.c
> index b8df0f5e8c25..c502c139d3bc 100644
> --- a/drivers/net/bonding/bond_netlink.c
> +++ b/drivers/net/bonding/bond_netlink.c
> @@ -449,6 +449,11 @@ static int bond_newlink(struct net *src_net, struct net_device *bond_dev,
> err = register_netdevice(bond_dev);
>
> netif_carrier_off(bond_dev);
> + if (!err) {
> + struct bonding *bond = netdev_priv(bond_dev);
> +
> + bond_work_init_all(bond);
> + }
>
> return err;
> }
> diff --git a/include/net/bonding.h b/include/net/bonding.h
> index 04a21e8048be..b00508d22e0a 100644
> --- a/include/net/bonding.h
> +++ b/include/net/bonding.h
> @@ -614,6 +614,7 @@ struct bond_vlan_tag *bond_verify_device_path(struct net_device *start_dev,
> int level);
> int bond_update_slave_arr(struct bonding *bond, struct slave *skipslave);
> void bond_slave_arr_work_rearm(struct bonding *bond, unsigned long delay);
> +void bond_work_init_all(struct bonding *bond);
>
> #ifdef CONFIG_PROC_FS
> void bond_create_proc_entry(struct bonding *bond);
> --
> 2.12.2.816.g2cccc81164-goog
>
^ permalink raw reply
* [PATCH net-next 0/3] net/tcp_fastopen: Fix for various TFO firewall issues
From: Wei Wang @ 2017-04-20 21:45 UTC (permalink / raw)
To: netdev, David Miller; +Cc: Yuchung Cheng, Eric Dumazet, Wei Wang
From: Wei Wang <weiwan@google.com>
Currently there are still some firewall issues in the middlebox
which make the middlebox drop packets silently for TFO sockets.
This kind of issue is hard to be detected by the end client.
This patch series tries to detect such issues in the kernel and disable
TFO temporarily.
More details about the issues and the fixes are included in the following
patches.
Wei Wang (3):
net-tcp_fastopen: Disable active side TFO in certain scenarios
net-tcp_fastopen: Add snmp counter for blackhole detection
net-tcp_fastopen: Remove mss check in tcp_write_timeout()
Documentation/networking/ip-sysctl.txt | 8 +++
include/linux/tcp.h | 1 +
include/net/tcp.h | 6 ++
include/uapi/linux/snmp.h | 1 +
net/ipv4/proc.c | 1 +
net/ipv4/sysctl_net_ipv4.c | 21 +++++++
net/ipv4/tcp.c | 1 +
net/ipv4/tcp_fastopen.c | 102 +++++++++++++++++++++++++++++++++
net/ipv4/tcp_input.c | 23 ++++++--
net/ipv4/tcp_ipv4.c | 3 +
net/ipv4/tcp_timer.c | 7 +--
11 files changed, 166 insertions(+), 8 deletions(-)
--
2.12.2.816.g2cccc81164-goog
^ permalink raw reply
* [PATCH net-next 1/3] net/tcp_fastopen: Disable active side TFO in certain scenarios
From: Wei Wang @ 2017-04-20 21:45 UTC (permalink / raw)
To: netdev, David Miller; +Cc: Yuchung Cheng, Eric Dumazet, Wei Wang
In-Reply-To: <20170420214548.23666-1-tracywwnj@gmail.com>
From: Wei Wang <weiwan@google.com>
Middlebox firewall issues can potentially cause server's data being
blackholed after a successful 3WHS using TFO. Following are the related
reports from Apple:
https://www.nanog.org/sites/default/files/Paasch_Network_Support.pdf
Slide 31 identifies an issue where the client ACK to the server's data
sent during a TFO'd handshake is dropped.
C ---> syn-data ---> S
C <--- syn/ack ----- S
C (accept & write)
C <---- data ------- S
C ----- ACK -> X S
[retry and timeout]
https://www.ietf.org/proceedings/94/slides/slides-94-tcpm-13.pdf
Slide 5 shows a similar situation that the server's data gets dropped
after 3WHS.
C ---- syn-data ---> S
C <--- syn/ack ----- S
C ---- ack --------> S
S (accept & write)
C? X <- data ------ S
[retry and timeout]
This is the worst failure b/c the client can not detect such behavior to
mitigate the situation (such as disabling TFO). Failing to proceed, the
application (e.g., SSL library) may simply timeout and retry with TFO
again, and the process repeats indefinitely.
The proposed solution is to disable active TFO globally under the
following circumstances:
1. client side TFO socket detects out of order FIN
2. client side TFO socket receives out of order RST
We disable active side TFO globally for 1hr at first. Then if it
happens again, we disable it for 2h, then 4h, 8h, ...
And we reset the timeout to 1hr if a client side TFO sockets not opened
on loopback has successfully received data segs from server.
And we examine this condition during close().
The rational behind it is that when such firewall issue happens,
application running on the client should eventually close the socket as
it is not able to get the data it is expecting. Or application running
on the server should close the socket as it is not able to receive any
response from client.
In both cases, out of order FIN or RST will get received on the client
given that the firewall will not block them as no data are in those
frames.
And we want to disable active TFO globally as it helps if the middle box
is very close to the client and most of the connections are likely to
fail.
Also, add a debug sysctl:
tcp_fastopen_blackhole_detect_timeout_sec:
the initial timeout to use when firewall blackhole issue happens.
This can be set and read.
When setting it to 0, it means to disable the active disable logic.
Signed-off-by: Wei Wang <weiwan@google.com>
---
Documentation/networking/ip-sysctl.txt | 8 +++
include/linux/tcp.h | 1 +
include/net/tcp.h | 6 ++
net/ipv4/sysctl_net_ipv4.c | 21 +++++++
net/ipv4/tcp.c | 1 +
net/ipv4/tcp_fastopen.c | 101 +++++++++++++++++++++++++++++++++
net/ipv4/tcp_input.c | 23 ++++++--
net/ipv4/tcp_ipv4.c | 3 +
8 files changed, 160 insertions(+), 4 deletions(-)
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index b1c6500e7a8d..974ab47ae53a 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -602,6 +602,14 @@ tcp_fastopen - INTEGER
Note that that additional client or server features are only
effective if the basic support (0x1 and 0x2) are enabled respectively.
+tcp_fastopen_blackhole_timeout_sec - INTEGER
+ Initial time period in second to disable Fastopen on active TCP sockets
+ when a TFO firewall blackhole issue happens.
+ This time period will grow exponentially when more blackhole issues
+ get detected right after Fastopen is re-enabled and will reset to
+ initial value when the blackhole issue goes away.
+ By default, it is set to 1hr.
+
tcp_syn_retries - INTEGER
Number of times initial SYNs for an active TCP connection attempt
will be retransmitted. Should not be higher than 127. Default value
diff --git a/include/linux/tcp.h b/include/linux/tcp.h
index cfc2d9506ce8..cbe5b602a2d3 100644
--- a/include/linux/tcp.h
+++ b/include/linux/tcp.h
@@ -233,6 +233,7 @@ struct tcp_sock {
u8 syn_data:1, /* SYN includes data */
syn_fastopen:1, /* SYN includes Fast Open option */
syn_fastopen_exp:1,/* SYN includes Fast Open exp. option */
+ syn_fastopen_ch:1, /* Active TFO re-enabling probe */
syn_data_acked:1,/* data in SYN is acked by SYN-ACK */
save_syn:1, /* Save headers of SYN packet */
is_cwnd_limited:1;/* forward progress limited by snd_cwnd? */
diff --git a/include/net/tcp.h b/include/net/tcp.h
index cc6ae0a95201..c1abc2abbdcb 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1506,6 +1506,12 @@ struct tcp_fastopen_context {
struct rcu_head rcu;
};
+extern unsigned int sysctl_tcp_fastopen_blackhole_timeout;
+void tcp_fastopen_active_disable(void);
+bool tcp_fastopen_active_should_disable(struct sock *sk);
+void tcp_fastopen_active_disable_ofo_check(struct sock *sk);
+void tcp_fastopen_active_timeout_reset(void);
+
/* Latencies incurred by various limits for a sender. They are
* chronograph-like stats that are mutually exclusive.
*/
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index 6fb25693c00b..52fa0a6b78ff 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -347,6 +347,19 @@ static int proc_udp_early_demux(struct ctl_table *table, int write,
return ret;
}
+static int proc_tfo_blackhole_detect_timeout(struct ctl_table *table,
+ int write,
+ void __user *buffer,
+ size_t *lenp, loff_t *ppos)
+{
+ int ret;
+
+ ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
+ if (write && ret == 0)
+ tcp_fastopen_active_timeout_reset();
+ return ret;
+}
+
static struct ctl_table ipv4_table[] = {
{
.procname = "tcp_timestamps",
@@ -397,6 +410,14 @@ static struct ctl_table ipv4_table[] = {
.proc_handler = proc_tcp_fastopen_key,
},
{
+ .procname = "tcp_fastopen_blackhole_timeout_sec",
+ .data = &sysctl_tcp_fastopen_blackhole_timeout,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_tfo_blackhole_detect_timeout,
+ .extra1 = &zero,
+ },
+ {
.procname = "tcp_abort_on_overflow",
.data = &sysctl_tcp_abort_on_overflow,
.maxlen = sizeof(int),
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 04843ae77b9e..efc976ae66ae 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2296,6 +2296,7 @@ int tcp_disconnect(struct sock *sk, int flags)
tcp_clear_xmit_timers(sk);
__skb_queue_purge(&sk->sk_receive_queue);
tcp_write_queue_purge(sk);
+ tcp_fastopen_active_disable_ofo_check(sk);
skb_rbtree_purge(&tp->out_of_order_queue);
inet->inet_dport = 0;
diff --git a/net/ipv4/tcp_fastopen.c b/net/ipv4/tcp_fastopen.c
index 8ea4e9787f82..ff2d30ffc6f3 100644
--- a/net/ipv4/tcp_fastopen.c
+++ b/net/ipv4/tcp_fastopen.c
@@ -341,6 +341,13 @@ bool tcp_fastopen_cookie_check(struct sock *sk, u16 *mss,
cookie->len = -1;
return false;
}
+
+ /* Firewall blackhole issue check */
+ if (tcp_fastopen_active_should_disable(sk)) {
+ cookie->len = -1;
+ return false;
+ }
+
if (sysctl_tcp_fastopen & TFO_CLIENT_NO_COOKIE) {
cookie->len = -1;
return true;
@@ -380,3 +387,97 @@ bool tcp_fastopen_defer_connect(struct sock *sk, int *err)
return false;
}
EXPORT_SYMBOL(tcp_fastopen_defer_connect);
+
+/*
+ * The following code block is to deal with middle box issues with TFO:
+ * Middlebox firewall issues can potentially cause server's data being
+ * blackholed after a successful 3WHS using TFO.
+ * The proposed solution is to disable active TFO globally under the
+ * following circumstances:
+ * 1. client side TFO socket receives out of order FIN
+ * 2. client side TFO socket receives out of order RST
+ * We disable active side TFO globally for 1hr at first. Then if it
+ * happens again, we disable it for 2h, then 4h, 8h, ...
+ * And we reset the timeout back to 1hr when we see a successful active
+ * TFO connection with data exchanges.
+ */
+
+/* Default to 1hr */
+unsigned int sysctl_tcp_fastopen_blackhole_timeout __read_mostly = 60 * 60;
+static atomic_t tfo_active_disable_times __read_mostly = ATOMIC_INIT(0);
+static unsigned long tfo_active_disable_stamp __read_mostly;
+
+/* Disable active TFO and record current jiffies and
+ * tfo_active_disable_times
+ */
+void tcp_fastopen_active_disable(void)
+{
+ atomic_inc(&tfo_active_disable_times);
+ tfo_active_disable_stamp = jiffies;
+}
+
+/* Reset tfo_active_disable_times to 0 */
+void tcp_fastopen_active_timeout_reset(void)
+{
+ atomic_set(&tfo_active_disable_times, 0);
+}
+
+/* Calculate timeout for tfo active disable
+ * Return true if we are still in the active TFO disable period
+ * Return false if timeout already expired and we should use active TFO
+ */
+bool tcp_fastopen_active_should_disable(struct sock *sk)
+{
+ int tfo_da_times = atomic_read(&tfo_active_disable_times);
+ int multiplier;
+ unsigned long timeout;
+
+ if (!tfo_da_times)
+ return false;
+
+ /* Limit timout to max: 2^6 * initial timeout */
+ multiplier = 1 << min(tfo_da_times - 1, 6);
+ timeout = multiplier * sysctl_tcp_fastopen_blackhole_timeout * HZ;
+ if (time_before(jiffies, tfo_active_disable_stamp + timeout))
+ return true;
+
+ /* Mark check bit so we can check for successful active TFO
+ * condition and reset tfo_active_disable_times
+ */
+ tcp_sk(sk)->syn_fastopen_ch = 1;
+ return false;
+}
+
+/* Disable active TFO if FIN is the only packet in the ofo queue
+ * and no data is received.
+ * Also check if we can reset tfo_active_disable_times if data is
+ * received successfully on a marked active TFO sockets opened on
+ * a non-loopback interface
+ */
+void tcp_fastopen_active_disable_ofo_check(struct sock *sk)
+{
+ struct tcp_sock *tp = tcp_sk(sk);
+ struct rb_node *p;
+ struct sk_buff *skb;
+ struct dst_entry *dst;
+
+ if (!tp->syn_fastopen)
+ return;
+
+ if (!tp->data_segs_in) {
+ p = rb_first(&tp->out_of_order_queue);
+ if (p && !rb_next(p)) {
+ skb = rb_entry(p, struct sk_buff, rbnode);
+ if (TCP_SKB_CB(skb)->tcp_flags & TCPHDR_FIN) {
+ tcp_fastopen_active_disable();
+ return;
+ }
+ }
+ } else if (tp->syn_fastopen_ch &&
+ atomic_read(&tfo_active_disable_times)) {
+ dst = sk_dst_get(sk);
+ if (!(dst && dst->dev && (dst->dev->flags & IFF_LOOPBACK)))
+ tcp_fastopen_active_timeout_reset();
+ dst_release(dst);
+ }
+}
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 341f021f02a2..9f342a67dc74 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -5300,8 +5300,16 @@ static bool tcp_validate_incoming(struct sock *sk, struct sk_buff *skb,
if (rst_seq_match)
tcp_reset(sk);
- else
+ else {
+ /* Disable TFO if RST is out-of-order
+ * and no data has been received
+ * for current active TFO socket
+ */
+ if (tp->syn_fastopen && !tp->data_segs_in &&
+ sk->sk_state == TCP_ESTABLISHED)
+ tcp_fastopen_active_disable();
tcp_send_challenge_ack(sk, skb);
+ }
goto discard;
}
@@ -6044,9 +6052,16 @@ int tcp_rcv_state_process(struct sock *sk, struct sk_buff *skb)
break;
}
- if (tp->linger2 < 0 ||
- (TCP_SKB_CB(skb)->end_seq != TCP_SKB_CB(skb)->seq &&
- after(TCP_SKB_CB(skb)->end_seq - th->fin, tp->rcv_nxt))) {
+ if (tp->linger2 < 0) {
+ tcp_done(sk);
+ NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPABORTONDATA);
+ return 1;
+ }
+ if (TCP_SKB_CB(skb)->end_seq != TCP_SKB_CB(skb)->seq &&
+ after(TCP_SKB_CB(skb)->end_seq - th->fin, tp->rcv_nxt)) {
+ /* Receive out of order FIN after close() */
+ if (tp->syn_fastopen && th->fin)
+ tcp_fastopen_active_disable();
tcp_done(sk);
NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPABORTONDATA);
return 1;
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 20cbd2f07f28..cbbafe546c0f 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1855,6 +1855,9 @@ void tcp_v4_destroy_sock(struct sock *sk)
/* Cleanup up the write buffer. */
tcp_write_queue_purge(sk);
+ /* Check if we want to disable active TFO */
+ tcp_fastopen_active_disable_ofo_check(sk);
+
/* Cleans up our, hopefully empty, out_of_order_queue. */
skb_rbtree_purge(&tp->out_of_order_queue);
--
2.12.2.816.g2cccc81164-goog
^ permalink raw reply related
* [PATCH net-next 2/3] net/tcp_fastopen: Add snmp counter for blackhole detection
From: Wei Wang @ 2017-04-20 21:45 UTC (permalink / raw)
To: netdev, David Miller; +Cc: Yuchung Cheng, Eric Dumazet, Wei Wang
In-Reply-To: <20170420214548.23666-2-tracywwnj@gmail.com>
From: Wei Wang <weiwan@google.com>
This counter records the number of times the firewall blackhole issue is
detected and active TFO is disabled.
Signed-off-by: Wei Wang <weiwan@google.com>
---
include/net/tcp.h | 2 +-
include/uapi/linux/snmp.h | 1 +
net/ipv4/proc.c | 1 +
net/ipv4/tcp_fastopen.c | 5 +++--
net/ipv4/tcp_input.c | 4 ++--
5 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index c1abc2abbdcb..da28bef1d82b 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -1507,7 +1507,7 @@ struct tcp_fastopen_context {
};
extern unsigned int sysctl_tcp_fastopen_blackhole_timeout;
-void tcp_fastopen_active_disable(void);
+void tcp_fastopen_active_disable(struct sock *sk);
bool tcp_fastopen_active_should_disable(struct sock *sk);
void tcp_fastopen_active_disable_ofo_check(struct sock *sk);
void tcp_fastopen_active_timeout_reset(void);
diff --git a/include/uapi/linux/snmp.h b/include/uapi/linux/snmp.h
index cec0e171d20c..95cffcb21dfd 100644
--- a/include/uapi/linux/snmp.h
+++ b/include/uapi/linux/snmp.h
@@ -259,6 +259,7 @@ enum
LINUX_MIB_TCPFASTOPENPASSIVEFAIL, /* TCPFastOpenPassiveFail */
LINUX_MIB_TCPFASTOPENLISTENOVERFLOW, /* TCPFastOpenListenOverflow */
LINUX_MIB_TCPFASTOPENCOOKIEREQD, /* TCPFastOpenCookieReqd */
+ LINUX_MIB_TCPFASTOPENBLACKHOLE, /* TCPFastOpenBlackholeDetect */
LINUX_MIB_TCPSPURIOUS_RTX_HOSTQUEUES, /* TCPSpuriousRtxHostQueues */
LINUX_MIB_BUSYPOLLRXPACKETS, /* BusyPollRxPackets */
LINUX_MIB_TCPAUTOCORKING, /* TCPAutoCorking */
diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
index 4ccbf464d1ac..fa44e752a9a3 100644
--- a/net/ipv4/proc.c
+++ b/net/ipv4/proc.c
@@ -281,6 +281,7 @@ static const struct snmp_mib snmp4_net_list[] = {
SNMP_MIB_ITEM("TCPFastOpenPassiveFail", LINUX_MIB_TCPFASTOPENPASSIVEFAIL),
SNMP_MIB_ITEM("TCPFastOpenListenOverflow", LINUX_MIB_TCPFASTOPENLISTENOVERFLOW),
SNMP_MIB_ITEM("TCPFastOpenCookieReqd", LINUX_MIB_TCPFASTOPENCOOKIEREQD),
+ SNMP_MIB_ITEM("TCPFastOpenBlackhole", LINUX_MIB_TCPFASTOPENBLACKHOLE),
SNMP_MIB_ITEM("TCPSpuriousRtxHostQueues", LINUX_MIB_TCPSPURIOUS_RTX_HOSTQUEUES),
SNMP_MIB_ITEM("BusyPollRxPackets", LINUX_MIB_BUSYPOLLRXPACKETS),
SNMP_MIB_ITEM("TCPAutoCorking", LINUX_MIB_TCPAUTOCORKING),
diff --git a/net/ipv4/tcp_fastopen.c b/net/ipv4/tcp_fastopen.c
index ff2d30ffc6f3..4af82b914dd4 100644
--- a/net/ipv4/tcp_fastopen.c
+++ b/net/ipv4/tcp_fastopen.c
@@ -410,10 +410,11 @@ static unsigned long tfo_active_disable_stamp __read_mostly;
/* Disable active TFO and record current jiffies and
* tfo_active_disable_times
*/
-void tcp_fastopen_active_disable(void)
+void tcp_fastopen_active_disable(struct sock *sk)
{
atomic_inc(&tfo_active_disable_times);
tfo_active_disable_stamp = jiffies;
+ NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPFASTOPENBLACKHOLE);
}
/* Reset tfo_active_disable_times to 0 */
@@ -469,7 +470,7 @@ void tcp_fastopen_active_disable_ofo_check(struct sock *sk)
if (p && !rb_next(p)) {
skb = rb_entry(p, struct sk_buff, rbnode);
if (TCP_SKB_CB(skb)->tcp_flags & TCPHDR_FIN) {
- tcp_fastopen_active_disable();
+ tcp_fastopen_active_disable(sk);
return;
}
}
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 9f342a67dc74..5af2f04f8859 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -5307,7 +5307,7 @@ static bool tcp_validate_incoming(struct sock *sk, struct sk_buff *skb,
*/
if (tp->syn_fastopen && !tp->data_segs_in &&
sk->sk_state == TCP_ESTABLISHED)
- tcp_fastopen_active_disable();
+ tcp_fastopen_active_disable(sk);
tcp_send_challenge_ack(sk, skb);
}
goto discard;
@@ -6061,7 +6061,7 @@ int tcp_rcv_state_process(struct sock *sk, struct sk_buff *skb)
after(TCP_SKB_CB(skb)->end_seq - th->fin, tp->rcv_nxt)) {
/* Receive out of order FIN after close() */
if (tp->syn_fastopen && th->fin)
- tcp_fastopen_active_disable();
+ tcp_fastopen_active_disable(sk);
tcp_done(sk);
NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPABORTONDATA);
return 1;
--
2.12.2.816.g2cccc81164-goog
^ permalink raw reply related
* Re: net/bonding: stack-out-of-bounds in bond_enslave
From: Cong Wang @ 2017-04-20 21:46 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Jay Vosburgh, Veaceslav Falico, Andy Gospodarek, netdev, LKML,
Eric Dumazet, Dmitry Vyukov, Kostya Serebryany, syzkaller
In-Reply-To: <CAAeHK+zNAbwp3MNOq1WUSxHw2Yx-K=v1KzJH38dY=A88gFsbAg@mail.gmail.com>
On Thu, Apr 20, 2017 at 9:32 AM, Andrey Konovalov <andreyknvl@google.com> wrote:
> Hi,
>
> I've got the following error report while fuzzing the kernel with syzkaller.
>
> On linux-next commit 4f7d029b9bf009fbee76bb10c0c4351a1870d2f3 (4.11-rc7).
>
> A reproducer and .config are attached.
>
> ==================================================================
> BUG: KASAN: stack-out-of-bounds in bond_enslave+0xe0a/0x4ef0 at addr
> ffff8800666b7792
> Write of size 16 by task a.out/3894
> page:ffffea000199adc0 count:0 mapcount:0 mapping: (null) index:0x0
> flags: 0x100000000000000()
> raw: 0100000000000000 0000000000000000 0000000000000000 00000000ffffffff
> raw: 0000000000000000 ffffea000199ade0 0000000000000000 0000000000000000
> page dumped because: kasan: bad access detected
> CPU: 1 PID: 3894 Comm: a.out Not tainted 4.11.0-rc7+ #251
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:16
> dump_stack+0x292/0x398 lib/dump_stack.c:52
> kasan_report_error mm/kasan/report.c:212
> kasan_report+0x4d8/0x510 mm/kasan/report.c:347
> check_memory_region_inline mm/kasan/kasan.c:326
> check_memory_region+0x139/0x190 mm/kasan/kasan.c:333
> memcpy+0x37/0x50 mm/kasan/kasan.c:369
> bond_enslave+0xe0a/0x4ef0 drivers/net/bonding/bond_main.c:1491
> bond_do_ioctl+0xb5d/0xec0 drivers/net/bonding/bond_main.c:3449
> dev_ifsioc+0x53f/0x9f0 net/core/dev_ioctl.c:338
> dev_ioctl+0x249/0x1160 net/core/dev_ioctl.c:532
> sock_do_ioctl+0x94/0xb0 net/socket.c:913
> sock_ioctl+0x28f/0x440 net/socket.c:1004
> vfs_ioctl fs/ioctl.c:45
> do_vfs_ioctl+0x1bf/0x1780 fs/ioctl.c:685
> SYSC_ioctl fs/ioctl.c:700
> SyS_ioctl+0x8f/0xc0 fs/ioctl.c:691
IPv6 tunnels use sizeof(struct in6_addr) as dev->addr_len
but in many places we use struct sockaddr to set dev addr,
whose ->sa_data only has 14 bytes...
^ permalink raw reply
* [PATCH net-next 3/3] net/tcp_fastopen: Remove mss check in tcp_write_timeout()
From: Wei Wang @ 2017-04-20 21:45 UTC (permalink / raw)
To: netdev, David Miller; +Cc: Yuchung Cheng, Eric Dumazet, Wei Wang
In-Reply-To: <20170420214548.23666-3-tracywwnj@gmail.com>
From: Wei Wang <weiwan@google.com>
Christoph Paasch from Apple found another firewall issue for TFO:
After successful 3WHS using TFO, server and client starts to exchange
data. Afterwards, a 10s idle time occurs on this connection. After that,
firewall starts to drop every packet on this connection.
The fix for this issue is to extend existing firewall blackhole detection
logic in tcp_write_timeout() by removing the mss check.
Signed-off-by: Wei Wang <weiwan@google.com>
---
net/ipv4/tcp_timer.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/net/ipv4/tcp_timer.c b/net/ipv4/tcp_timer.c
index b2ab411c6d37..14672543cf0b 100644
--- a/net/ipv4/tcp_timer.c
+++ b/net/ipv4/tcp_timer.c
@@ -201,11 +201,10 @@ static int tcp_write_timeout(struct sock *sk)
if (retransmits_timed_out(sk, net->ipv4.sysctl_tcp_retries1, 0, 0)) {
/* Some middle-boxes may black-hole Fast Open _after_
* the handshake. Therefore we conservatively disable
- * Fast Open on this path on recurring timeouts with
- * few or zero bytes acked after Fast Open.
+ * Fast Open on this path on recurring timeouts after
+ * successful Fast Open.
*/
- if (tp->syn_data_acked &&
- tp->bytes_acked <= tp->rx_opt.mss_clamp) {
+ if (tp->syn_data_acked) {
tcp_fastopen_cache_set(sk, 0, NULL, true, 0);
if (icsk->icsk_retransmits == net->ipv4.sysctl_tcp_retries1)
NET_INC_STATS(sock_net(sk),
--
2.12.2.816.g2cccc81164-goog
^ permalink raw reply related
* Re: net/xfrm: stack-out-of-bounds in xfrm_state_find
From: Sabrina Dubroca @ 2017-04-20 21:49 UTC (permalink / raw)
To: Andrey Konovalov
Cc: Steffen Klassert, Herbert Xu, David S. Miller, netdev, LKML,
Eric Dumazet, Cong Wang, Dmitry Vyukov, Kostya Serebryany,
syzkaller
In-Reply-To: <CAAeHK+yAwS0ttN3hQFTgc8AyBx93UGtFm_nJUky0wKR+K6BRRg@mail.gmail.com>
2017-04-20, 19:30:27 +0200, Andrey Konovalov wrote:
> On Thu, Apr 20, 2017 at 6:47 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> > Hi,
> >
> > I've got the following error report while fuzzing the kernel with syzkaller.
> >
> > On linux-next commit 4f7d029b9bf009fbee76bb10c0c4351a1870d2f3 (4.11-rc7).
> >
> > A reproducer and .config are attached.
> >
> > ==================================================================
> > BUG: KASAN: stack-out-of-bounds in xfrm_state_find+0x2ce7/0x2f70 at
> > addr ffff88006654f790
> > Read of size 4 by task a.out/4065
> > page:ffffea00019953c0 count:0 mapcount:0 mapping: (null) index:0x0
> > flags: 0x100000000000000()
> > raw: 0100000000000000 0000000000000000 0000000000000000 00000000ffffffff
> > raw: 0000000000000000 ffffea00019953e0 0000000000000000 0000000000000000
> > page dumped because: kasan: bad access detected
> > CPU: 1 PID: 4065 Comm: a.out Not tainted 4.11.0-rc7+ #251
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> > Call Trace:
> > __dump_stack lib/dump_stack.c:16
> > dump_stack+0x292/0x398 lib/dump_stack.c:52
> > kasan_report_error mm/kasan/report.c:212
> > kasan_report+0x4d8/0x510 mm/kasan/report.c:347
> > __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:367
> > xfrm_state_find+0x2ce7/0x2f70 net/xfrm/xfrm_state.c:897
>
> I'm not sure if the line numbers in the report are correct.
>
> My guess is that the guilty line is actually this one:
>
> h = xfrm_dst_hash(net, daddr, saddr, tmpl->reqid, encap_family);
>
> but I might be wrong.
I think you're right. From udp_sendmsg we can get a flowi4 allocated
on the stack, and that's where saddr and daddr come from (in
xfrm_tmpl_resolve_one). Then we feed that to xfrm_dst_hash(), but we
ignore family (AF_INET) and use encap_family (AF_INET6), and then
xfrm_dst_hash treats both addresses as if they were IPv6, so we read
past the end of the flowi4.
I don't know what the correct behavior would be.
BTW, I ran into a different stack-out-of-bounds (in
xfrm_dst_update_origin), also due to a flowi4 on stack being treated
as something bigger, I'll send the patch for that one.
> > xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:1470
> > xfrm_tmpl_resolve+0x308/0xc90 net/xfrm/xfrm_policy.c:1514
> > xfrm_resolve_and_create_bundle+0x16e/0x2590 net/xfrm/xfrm_policy.c:1889
> > xfrm_lookup+0xd72/0x1170 net/xfrm/xfrm_policy.c:2253
> > xfrm_lookup_route+0x39/0x1a0 net/xfrm/xfrm_policy.c:2375
> > ip_route_output_flow+0x7f/0xa0 net/ipv4/route.c:2483
> > udp_sendmsg+0x1565/0x2cd0 net/ipv4/udp.c:1015
> > udpv6_sendmsg+0x8af/0x3500 net/ipv6/udp.c:1083
> > inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:762
> > sock_sendmsg_nosec net/socket.c:633
> > sock_sendmsg+0xca/0x110 net/socket.c:643
> > SYSC_sendto+0x660/0x810 net/socket.c:1696
> > SyS_sendto+0x40/0x50 net/socket.c:1664
> > entry_SYSCALL_64_fastpath+0x1f/0xc2 arch/x86/entry/entry_64.S:204
> > RIP: 0033:0x7f3daefd0b79
> > RSP: 002b:00007ffdb39bb0b8 EFLAGS: 00000206 ORIG_RAX: 000000000000002c
> > RAX: ffffffffffffffda RBX: 00007ffdb39bb210 RCX: 00007f3daefd0b79
> > RDX: 0000000000000000 RSI: 0000000020001000 RDI: 0000000000000003
> > RBP: 00000000004004a0 R08: 0000000020013ff0 R09: 0000000000000010
> > R10: 0000000020000000 R11: 0000000000000206 R12: 0000000000000000
> > R13: 00007ffdb39bb210 R14: 0000000000000000 R15: 0000000000000000
> > Memory state around the buggy address:
> > ffff88006654f680: f1 f1 f1 00 f2 f2 f2 f2 f2 f2 f2 f8 f2 f2 f2 f2
> > ffff88006654f700: f2 f2 f2 00 00 00 00 f2 f2 f2 f2 00 00 00 00 00
> >>ffff88006654f780: 00 00 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 00 00
> > ^
> > ffff88006654f800: f2 f2 f2 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00
> > ffff88006654f880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > ==================================================================
--
Sabrina
^ permalink raw reply
* Re: more on FP operations
From: Daniel Borkmann @ 2017-04-20 21:52 UTC (permalink / raw)
To: David Miller, ast; +Cc: borkmann, netdev
In-Reply-To: <20170420.140617.91794616324352770.davem@davemloft.net>
On 04/20/2017 08:06 PM, David Miller wrote:
>
> I'm running test_verifier for testing, and I notice in my JIT that a
> 32-bit move from the frame pointer (BPF_REG_10) ends up in the JIT.
>
> It is from this test:
>
> "unpriv: partial copy of pointer",
> .insns = {
> BPF_MOV32_REG(BPF_REG_1, BPF_REG_10),
> BPF_MOV64_IMM(BPF_REG_0, 0),
> BPF_EXIT_INSN(),
> },
> .errstr_unpriv = "R10 partial copy",
> .result_unpriv = REJECT,
> .result = ACCEPT,
>
> It seems to suggest that privileged code is allowed to do this, but I
> can't think of a legitimate usage.
One thing I could think of right now would be for use in 32 bit
archs, but that would still need to be taught to the verifier
first. Other patterns f.e. like ...
{
"unpriv: adding of fp",
.insns = {
BPF_MOV64_IMM(BPF_REG_1, 0),
BPF_ALU64_REG(BPF_ADD, BPF_REG_1, BPF_REG_10),
BPF_MOV64_IMM(BPF_REG_0, 0),
BPF_EXIT_INSN(),
},
.errstr_unpriv = "pointer arithmetic prohibited",
.result_unpriv = REJECT,
.result = ACCEPT,
},
... are currently also possible, but in the above and the partial
copy r1 is always considered as UNKNOWN_VALUE from that point onward
and there's not really much we could do with it anymore, except
perhaps passing to bpf_probe_read() for inspection in tracing for
some reason. Since there are also various other pointers, it is
really only the FP that needs to be special cased for sparc JIT,
right?
> I really want to be able to JIT anything the verifier accepts, but I
> have a hard time justifying adding 32-bit FP register move support,
> adjusting for the stack bias, etc.
>
> Thanks.
^ permalink raw reply
* Re: [PATCH 1/1] bonding: use 'M' or 'G' based on the speed
From: Stephen Hemminger @ 2017-04-20 21:53 UTC (permalink / raw)
To: Zhu Yanjun; +Cc: j.vosburgh, vfalico, andy, netdev
In-Reply-To: <1492679195-19938-1-git-send-email-yanjun.zhu@oracle.com>
On Thu, 20 Apr 2017 05:06:35 -0400
Zhu Yanjun <yanjun.zhu@oracle.com> wrote:
> If the speed of the slave netdev is more than 1000M,
> it is better to use 'G' instead of 'M'.
>
> Signed-off-by: Zhu Yanjun <yanjun.zhu@oracle.com>
> ---
> drivers/net/bonding/bond_main.c | 8 ++++++--
> drivers/net/bonding/bond_procfs.c | 6 +++++-
> 2 files changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index af9f0ce..1aad13d 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -2147,9 +2147,13 @@ static void bond_miimon_commit(struct bonding *bond)
> bond_set_backup_slave(slave);
> }
>
> - netdev_info(bond->dev, "link status definitely up for interface %s, %u Mbps %s duplex\n",
> + netdev_info(bond->dev, "link status definitely up for interface %s, %u%sbps %s duplex\n",
> slave->dev->name,
> - slave->speed == SPEED_UNKNOWN ? 0 : slave->speed,
> + slave->speed == SPEED_UNKNOWN ? 0 :
> + (slave->speed > 1000 ?
> + slave->speed / 1000 : slave->speed),
> + slave->speed > 1000 ?
> + slave->speed % 1000 ? ".5 G" : " G" : " M",
> slave->duplex ? "full" : "half");
Or drop the message all together. This is just log noise in a production system.
>
> /* notify ad that the link status has changed */
> diff --git a/drivers/net/bonding/bond_procfs.c b/drivers/net/bonding/bond_procfs.c
> index f514fe5..4c31055 100644
> --- a/drivers/net/bonding/bond_procfs.c
> +++ b/drivers/net/bonding/bond_procfs.c
> @@ -173,7 +173,11 @@ static void bond_info_show_slave(struct seq_file *seq,
> if (slave->speed == SPEED_UNKNOWN)
> seq_printf(seq, "Speed: %s\n", "Unknown");
> else
> - seq_printf(seq, "Speed: %d Mbps\n", slave->speed);
> + seq_printf(seq, "Speed: %d%sbps\n",
> + slave->speed > 1000 ?
> + slave->speed / 1000 : slave->speed,
> + slave->speed > 1000 ?
> + (slave->speed % 1000 ? ".5 G" : " G") : " M");
>
> if (slave->duplex == DUPLEX_UNKNOWN)
> seq_printf(seq, "Duplex: %s\n", "Unknown");
You can't change output formats of /proc since it technically and kernel/userspace ABI.
^ 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