* RE: [PATCH v1 RFC 1/7] Replace license with GPL
From: Tristram.Ha @ 2017-10-09 18:40 UTC (permalink / raw)
To: David.Laight
Cc: muvarov, nathan.leigh.conrad, vivien.didelot, UNGLinuxDriver,
netdev, linux-kernel, andrew, f.fainelli, pavel, ruediger.schmitt
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DD008D3F0@AcuExch.aculab.com>
> From: Tristram.Ha@microchip.com
> > Sent: 06 October 2017 21:33
> > Replace license with GPL.
>
> Don't you need permission from all the people who have updated
> the files in order to make this change?
>
> David
I am a little confused by your comment. The 4 original KSZ9477 DSA
driver files were written by Woojung at Microchip Technology Inc.
There was a complaint the "AS IS" license is not exactly GPL.
It should be submitted formally to net-next instead of a RFC, but it
is probably pointless to do that when there is no code change.
I am hoping these drastic changes of KSZ9477 driver can be accepted
so that the patches can be submitted formally to net-next.
^ permalink raw reply
* linux-next: manual merge of the cgroup tree with the net-next tree
From: Mark Brown @ 2017-10-09 18:38 UTC (permalink / raw)
To: Tejun Heo, Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau,
David S. Miller
Cc: netdev, Linux-Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]
Hi Tejun,
Today's linux-next merge of the cgroup tree got a conflict in:
kernel/cgroup/cgroup.c
between commit:
324bda9e6c5ad ("bpf: multi program support for cgroup+bpf")
from the net-next tree and commit:
041cd640b2f3c ("cgroup: Implement cgroup2 basic CPU usage accounting")
from the cgroup tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --cc kernel/cgroup/cgroup.c
index 00f5b358aeac,c3421ee0d230..000000000000
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@@ -4765,8 -4785,9 +4788,11 @@@ static struct cgroup *cgroup_create(str
return cgrp;
+out_idr_free:
+ cgroup_idr_remove(&root->cgroup_idr, cgrp->id);
+ out_stat_exit:
+ if (cgroup_on_dfl(parent))
+ cgroup_stat_exit(cgrp);
out_cancel_ref:
percpu_ref_exit(&cgrp->self.refcnt);
out_free_cgrp:
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* RE: [PATCH v1 RFC 1/1] Add Microchip KSZ8795 DSA driver
From: Tristram.Ha @ 2017-10-09 18:24 UTC (permalink / raw)
To: muvarov
Cc: andrew, f.fainelli, pavel, ruediger.schmitt, nathan.leigh.conrad,
vivien.didelot, UNGLinuxDriver, netdev, linux-kernel
In-Reply-To: <CAJGZr0+E=esM1s086QYr8q3J3UeKvFKBFHt7ydUtC91rALCsjw@mail.gmail.com>
> in previous version I see that transit traffic (ping) goes to cpu,
> then from cpu back to destination port. I.e. it works but with cpu
> involving. Is this version supposed to work like that?
Yes, it works in the old DSA way such that a software bridge is
responsible to forward every packet.
Now if the ksz_update_port_member function is called inside
the ksz8795_port_stp_state_set function the switch will forward
packets itself. Because of that the offload_fwd_mark bit should be
set in the socket buffer so that the software bridge does not
forward the packet (mostly multicast) again. However, that
indication cannot be set in the switch driver but in the tail tag code
in tag_ksz.c. Right now there is no easy way for that code to know
the bit should be set because the switch is in forwarding mode.
^ permalink raw reply
* Re: [PATCH] net: can: Convert timers to use timer_setup()
From: Marc Kleine-Budde @ 2017-10-09 18:10 UTC (permalink / raw)
To: Kees Cook
Cc: LKML, Oliver Hartkopp, David S. Miller, linux-can,
Network Development, Thomas Gleixner
In-Reply-To: <CAGXu5jKcQ0ez7dEma5fJv3DjWABAoEm+9P_G6aMcdBv6MHnsdQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1486 bytes --]
On 10/09/2017 08:09 PM, Kees Cook wrote:
> On Mon, Oct 9, 2017 at 10:53 AM, Marc Kleine-Budde <mkl@pengutronix.de> wrote:
>> On 10/05/2017 02:51 AM, Kees Cook wrote:
>>> In preparation for unconditionally passing the struct timer_list pointer to
>>> all timer callbacks, switch to using the new timer_setup() and from_timer()
>>> to pass the timer pointer explicitly.
>>>
>>> Cc: Oliver Hartkopp <socketcan@hartkopp.net>
>>> Cc: Marc Kleine-Budde <mkl@pengutronix.de>
>>> Cc: "David S. Miller" <davem@davemloft.net>
>>> Cc: linux-can@vger.kernel.org
>>> Cc: netdev@vger.kernel.org
>>> Cc: Thomas Gleixner <tglx@linutronix.de>
>>> Signed-off-by: Kees Cook <keescook@chromium.org>
>>> ---
>>> This requires commit 686fef928bba ("timer: Prepare to change timer
>>> callback argument type") in v4.14-rc3, but should be otherwise
>>> stand-alone.
>>
>> Are you taking the patch or should I apply it?
>>
>> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
>
> If you have -rc3 in your tree, please take it. If you want the timers
> tree to carry it instead, we can do that too.
I think it will hit mainline faster via your tree, as it will go via
net-next. You've my acked-by.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] net: can: Convert timers to use timer_setup()
From: Kees Cook @ 2017-10-09 18:09 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: LKML, Oliver Hartkopp, David S. Miller, linux-can,
Network Development, Thomas Gleixner
In-Reply-To: <04d30a39-3e88-e46b-ad94-686da16e571e@pengutronix.de>
On Mon, Oct 9, 2017 at 10:53 AM, Marc Kleine-Budde <mkl@pengutronix.de> wrote:
> On 10/05/2017 02:51 AM, Kees Cook wrote:
>> In preparation for unconditionally passing the struct timer_list pointer to
>> all timer callbacks, switch to using the new timer_setup() and from_timer()
>> to pass the timer pointer explicitly.
>>
>> Cc: Oliver Hartkopp <socketcan@hartkopp.net>
>> Cc: Marc Kleine-Budde <mkl@pengutronix.de>
>> Cc: "David S. Miller" <davem@davemloft.net>
>> Cc: linux-can@vger.kernel.org
>> Cc: netdev@vger.kernel.org
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Signed-off-by: Kees Cook <keescook@chromium.org>
>> ---
>> This requires commit 686fef928bba ("timer: Prepare to change timer
>> callback argument type") in v4.14-rc3, but should be otherwise
>> stand-alone.
>
> Are you taking the patch or should I apply it?
>
> Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
If you have -rc3 in your tree, please take it. If you want the timers
tree to carry it instead, we can do that too.
Thanks!
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply
* net-next: WARNING: CPU: 0 PID: 1544 at net/ipv4/tcp_input.c:889
From: Andrei Vagin @ 2017-10-09 18:07 UTC (permalink / raw)
To: Linux Kernel Network Developers
Hello,
We run CRIU tests on a daily basis for net-next and today they
triggered a following warning:
[ 58.827039] ------------[ cut here ]------------
[ 58.827078] WARNING: CPU: 0 PID: 1544 at net/ipv4/tcp_input.c:889
tcp_update_reordering+0x9f/0xb0
[ 58.827083] Modules linked in:
[ 58.827095] CPU: 0 PID: 1544 Comm: sshd Not tainted 4.14.0-rc3+ #1
[ 58.827101] Hardware name: Google Google Compute Engine/Google
Compute Engine, BIOS Google 01/01/2011
[ 58.827106] task: ffff90f2633dcc80 task.stack: ffffb0e302800000
[ 58.827112] RIP: 0010:tcp_update_reordering+0x9f/0xb0
[ 58.827117] RSP: 0018:ffffb0e302803b28 EFLAGS: 00010282
[ 58.827126] RAX: 00000000fffffffd RBX: ffff90f29136e840 RCX: 0000000000000003
[ 58.827131] RDX: 0000000000000000 RSI: 00000000fffffffd RDI: ffff90f29136de80
[ 58.827136] RBP: ffffb0e302803b28 R08: 0000000000000044 R09: 00000000e59da6c6
[ 58.827142] R10: ffffb0e302803b68 R11: 00000000e59da70a R12: 00000000e59da6c6
[ 58.827147] R13: ffff90f29136e848 R14: ffff90f29136de80 R15: 0000000000000002
[ 58.827153] FS: 00007f52e8452840(0000) GS:ffff90f29fc00000(0000)
knlGS:0000000000000000
[ 58.827158] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 58.827163] CR2: 000014727db10a10 CR3: 00000001d0967000 CR4: 00000000001406f0
[ 58.827172] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 58.827177] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 58.827182] Call Trace:
[ 58.827191] tcp_sacktag_write_queue+0x54d/0x860
[ 58.827206] tcp_ack+0xa71/0x1360
[ 58.827229] tcp_rcv_established+0x1da/0x560
[ 58.827241] tcp_v4_do_rcv+0x139/0x1d0
[ 58.827251] __release_sock+0x6d/0x110
[ 58.827260] release_sock+0x30/0xb0
[ 58.827267] tcp_sendmsg+0x37/0x50
[ 58.827276] inet_sendmsg+0x45/0x1e0
[ 58.827287] sock_sendmsg+0x38/0x50
[ 58.827295] sock_write_iter+0x7e/0xd0
[ 58.827311] __vfs_write+0xd4/0x150
[ 58.827325] vfs_write+0xcd/0x1d0
[ 58.827332] ? trace_hardirqs_on_caller+0x11f/0x190
[ 58.827341] SyS_write+0x49/0xa0
[ 58.827353] entry_SYSCALL_64_fastpath+0x23/0xc2
[ 58.827360] RIP: 0033:0x7f52e6186710
[ 58.827365] RSP: 002b:00007fffd37723b8 EFLAGS: 00000246 ORIG_RAX:
0000000000000001
[ 58.827375] RAX: ffffffffffffffda RBX: 000000002e3e9273 RCX: 00007f52e6186710
[ 58.827380] RDX: 0000000000000044 RSI: 0000557474a3e160 RDI: 0000000000000003
[ 58.827385] RBP: 00007f52e7237240 R08: 0000000000000006 R09: 0000000000000001
[ 58.827390] R10: 0000000000004da8 R11: 0000000000000246 R12: 000000005bb2be1e
[ 58.827396] R13: 00000000e9218d7d R14: 0000000059b77fb7 R15: 00000000505bdd2c
[ 58.827414] Code: b8 1d 00 00 00 c0 ea 04 84 d2 74 0b 89 d0 c1 e0
1e c1 f8 1f 83 c0 1c 48 8b 57 30 48 98 48 8b 92 00 02 00 00 65 48 ff
04 c2 5d c3 <0f> ff 5d c3 0f 1f 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f
44 00
[ 58.827724] ---[ end trace b8d78168bbc71c1f ]---
Here is a fill log:
https://travis-ci.org/avagin/linux/jobs/285457708
^ permalink raw reply
* Re: [net-next V5 PATCH 1/5] bpf: introduce new bpf cpu map type BPF_MAP_TYPE_CPUMAP
From: Jesper Dangaard Brouer @ 2017-10-09 17:59 UTC (permalink / raw)
To: Daniel Borkmann
Cc: netdev, jakub.kicinski, Michael S. Tsirkin, pavel.odintsov,
Jason Wang, mchan, John Fastabend, peter.waskiewicz.jr,
Daniel Borkmann, Alexei Starovoitov, Andy Gospodarek, brouer
In-Reply-To: <59DB7A29.5050906@iogearbox.net>
On Mon, 09 Oct 2017 15:31:21 +0200
Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 10/06/2017 06:12 PM, Jesper Dangaard Brouer wrote:
> [...]
> > +static struct bpf_map *cpu_map_alloc(union bpf_attr *attr)
> > +{
> > + struct bpf_cpu_map *cmap;
> > + int err = -ENOMEM;
>
> err init here is basically not needed since overriden later anyway
> w/o being read, but ...
Thank you for catching this! Guess, I'll send a V6 tomorrow.
[...]
> > + /* Notice returns -EPERM on if map size is larger than memlock limit */
> > + err = bpf_map_precharge_memlock(cmap->map.pages);
> > + if (err)
> > + goto free_cmap;
>
> ... here, you need to set err = -ENOMEM.
Yes, I see my mistake of assigning "err" here.
[...]
> > +static void *cpu_map_lookup_elem(struct bpf_map *map, void *key)
> > +{
> > + struct bpf_cpu_map_entry *rcpu =
> > + __cpu_map_lookup_elem(map, *(u32 *)key);
> > +
> > + return rcpu ? &rcpu->qsize : NULL;
>
> I still think from my prior email/comment that we should use per-cpu
> scratch buffer here. Would be nice to keep the guarantee that noone
> can modify it, it's just a tiny change.
Well, it's no-longer really needed, right(?), as this patchset update,
change that bpf-side cannot invoke this. The userspace-side reading
this will get a copy.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* linux-next: manual merge of the drivers-x86 tree with the net-next tree
From: Mark Brown @ 2017-10-09 17:56 UTC (permalink / raw)
To: Darren Hart, Mario Limonciello, Mika Westerberg, Yehezkel Bernat,
Andy Shevchenko, Amir Levy, Michael Jamet, David S. Miller
Cc: netdev, Linux-Next Mailing List, Linux Kernel Mailing List
[-- Attachment #1: Type: text/plain, Size: 3130 bytes --]
Hi Darren,
[Apologies for multiple copies - for some reason vger seems to eat mails
I send from scripts, still trying to figure this out]
Today's linux-next merge of the drivers-x86 tree got a conflict in:
Documentation/admin-guide/thunderbolt.rst
between commit:
e69b6c02b4c3b ("net: Add support for networking over Thunderbolt cable")
from the net-next tree and commit:
ce6a90027c10f ("platform/x86: Add driver to force WMI Thunderbolt controller power status")
from the drivers-x86 tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
diff --cc Documentation/admin-guide/thunderbolt.rst
index 5c62d11d77e8,dadcd66ee12f..000000000000
--- a/Documentation/admin-guide/thunderbolt.rst
+++ b/Documentation/admin-guide/thunderbolt.rst
@@@ -198,26 -198,17 +198,41 @@@ information is missing
To recover from this mode, one needs to flash a valid NVM image to the
host host controller in the same way it is done in the previous chapter.
+Networking over Thunderbolt cable
+---------------------------------
+Thunderbolt technology allows software communication across two hosts
+connected by a Thunderbolt cable.
+
+It is possible to tunnel any kind of traffic over Thunderbolt link but
+currently we only support Apple ThunderboltIP protocol.
+
+If the other host is running Windows or macOS only thing you need to
+do is to connect Thunderbolt cable between the two hosts, the
+``thunderbolt-net`` is loaded automatically. If the other host is also
+Linux you should load ``thunderbolt-net`` manually on one host (it does
+not matter which one)::
+
+ # modprobe thunderbolt-net
+
+This triggers module load on the other host automatically. If the driver
+is built-in to the kernel image, there is no need to do anything.
+
+The driver will create one virtual ethernet interface per Thunderbolt
+port which are named like ``thunderbolt0`` and so on. From this point
+you can either use standard userspace tools like ``ifconfig`` to
+configure the interface or let your GUI to handle it automatically.
++
+ Forcing power
+ -------------
+ Many OEMs include a method that can be used to force the power of a
+ thunderbolt controller to an "On" state even if nothing is connected.
+ If supported by your machine this will be exposed by the WMI bus with
+ a sysfs attribute called "force_power".
+
+ For example the intel-wmi-thunderbolt driver exposes this attribute in:
+ /sys/devices/platform/PNP0C14:00/wmi_bus/wmi_bus-PNP0C14:00/86CCFD48-205E-4A77-9C48-2021CBEDE341/force_power
+
+ To force the power to on, write 1 to this attribute file.
+ To disable force power, write 0 to this attribute file.
+
+ Note: it's currently not possible to query the force power state of a platform.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] net: can: Convert timers to use timer_setup()
From: Marc Kleine-Budde @ 2017-10-09 17:53 UTC (permalink / raw)
To: Kees Cook, linux-kernel
Cc: Oliver Hartkopp, David S. Miller, linux-can, netdev,
Thomas Gleixner
In-Reply-To: <20171005005126.GA23416@beast>
[-- Attachment #1.1: Type: text/plain, Size: 1091 bytes --]
On 10/05/2017 02:51 AM, Kees Cook wrote:
> In preparation for unconditionally passing the struct timer_list pointer to
> all timer callbacks, switch to using the new timer_setup() and from_timer()
> to pass the timer pointer explicitly.
>
> Cc: Oliver Hartkopp <socketcan@hartkopp.net>
> Cc: Marc Kleine-Budde <mkl@pengutronix.de>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: linux-can@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> This requires commit 686fef928bba ("timer: Prepare to change timer
> callback argument type") in v4.14-rc3, but should be otherwise
> stand-alone.
Are you taking the patch or should I apply it?
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* usb/net/rt2x00: warning in rt2800_eeprom_word_index
From: Andrey Konovalov @ 2017-10-09 17:50 UTC (permalink / raw)
To: Stanislaw Gruszka, Helmut Schaa, Kalle Valo, linux-wireless,
netdev, LKML
Cc: Dmitry Vyukov, Kostya Serebryany, syzkaller
Hi!
I've got the following report while fuzzing the kernel with syzkaller.
On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4).
I'm not sure whether this is a bug in the driver, or just a way to
report misbehaving device. In the latter case this shouldn't be a
WARN() call, since WARN() means bug in the kernel.
phy2: invalid access of EEPROM word 39
------------[ cut here ]------------
WARNING: CPU: 1 PID: 5591 at
drivers/net/wireless/ralink/rt2x00/rt2800lib.c:399
rt2800_eeprom_word_index.isra.15+0x149/0x1c0
Modules linked in:
CPU: 1 PID: 5591 Comm: syz-executor Not tainted
4.14.0-rc4-43423-g7263a3720c3f #392
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff880069933180 task.stack: ffff88005aee8000
RIP: 0010:rt2800_eeprom_word_index.isra.15+0x149/0x1c0
drivers/net/wireless/ralink/rt2x00/rt2800lib.c:397
RSP: 0018:ffff88005aeed960 EFLAGS: 00010282
RAX: 0000000000000026 RBX: ffff88005af0c5c0 RCX: 0000000000000000
RDX: 0000000000000026 RSI: ffffffff813292c9 RDI: ffffed000b5ddb1e
RBP: ffff88005aeed978 R08: ffff88005aeecd90 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000027
R13: ffff880068631018 R14: 0000000000000052 R15: 0000000000000000
FS: 0000000001c60940(0000) GS:ffff88006c700000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000001967000 CR3: 0000000068089000 CR4: 00000000000006e0
Call Trace:
rt2800_eeprom_addr drivers/net/wireless/ralink/rt2x00/rt2800lib.c:409
rt2800_probe_hw_mode drivers/net/wireless/ralink/rt2x00/rt2800lib.c:9321
rt2800_probe_hw+0x19ef/0x27b0
drivers/net/wireless/ralink/rt2x00/rt2800lib.c:9456
rt2800usb_probe_hw+0x6e/0x200
drivers/net/wireless/ralink/rt2x00/rt2800usb.c:768
rt2x00lib_probe_dev+0x9e5/0x2800
drivers/net/wireless/ralink/rt2x00/rt2x00dev.c:1427
rt2x00usb_probe+0x67b/0x990 drivers/net/wireless/ralink/rt2x00/rt2x00usb.c:837
rt2800usb_probe+0x21/0x30 drivers/net/wireless/ralink/rt2x00/rt2800usb.c:1410
usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
really_probe drivers/base/dd.c:413
driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
__device_attach_driver+0x230/0x290 drivers/base/dd.c:653
bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
__device_attach+0x26e/0x3d0 drivers/base/dd.c:710
device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
device_add+0xd0b/0x1660 drivers/base/core.c:1835
usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
really_probe drivers/base/dd.c:413
driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
__device_attach_driver+0x230/0x290 drivers/base/dd.c:653
bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
__device_attach+0x26e/0x3d0 drivers/base/dd.c:710
device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
device_add+0xd0b/0x1660 drivers/base/core.c:1835
usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2538
hub_port_connect drivers/usb/core/hub.c:4984
hub_port_connect_change drivers/usb/core/hub.c:5090
port_event drivers/usb/core/hub.c:5196
hub_event_impl+0x1971/0x3760 drivers/usb/core/hub.c:5310
gfs_hub_events_handle+0x881/0xae0 drivers/usb/core/hub.c:1853
hub_ioctl+0x53d/0x680 drivers/usb/core/hub.c:1903
proc_ioctl+0x435/0x680 drivers/usb/core/devio.c:2175
proc_ioctl_default drivers/usb/core/devio.c:2198
usbdev_do_ioctl+0xee9/0x3790 drivers/usb/core/devio.c:2512
usbdev_ioctl+0x2a/0x40 drivers/usb/core/devio.c:2556
vfs_ioctl fs/ioctl.c:45
do_vfs_ioctl+0x1c4/0x15c0 fs/ioctl.c:685
SYSC_ioctl fs/ioctl.c:700
SyS_ioctl+0x94/0xc0 fs/ioctl.c:691
entry_SYSCALL_64_fastpath+0x23/0xc2 arch/x86/entry/entry_64.S:202
RIP: 0033:0x447707
RSP: 002b:00007ffd565109b8 EFLAGS: 00000206 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00000000ffffffff RCX: 0000000000447707
RDX: 00007ffd565109d0 RSI: 00000000c0105512 RDI: 0000000000000015
RBP: 0000000000000005 R08: 0000000001c60940 R09: 0000000001c60940
R10: 00000000004a8e59 R11: 0000000000000206 R12: 0000000000000015
R13: 0000000000000000 R14: 00007ffd56510888 R15: 00007ffd565108f8
Code: ea 03 80 3c 02 00 75 72 4c 8b ab 70 01 00 00 4d 85 ed 74 3a e8
29 c5 9b fd 44 89 e2 4c 89 ee 48 c7 c7 e0 4d d5 86 e8 f1 6d 84 fd <0f>
ff 31 db e9 4c ff ff ff 48 89 df e8 36 f2 cd fd e9 34 ff ff
---[ end trace a71f41162bce05c3 ]---
^ permalink raw reply
* usb/irda: global-out-of-bounds in irda_qos_bits_to_value
From: Andrey Konovalov @ 2017-10-09 17:50 UTC (permalink / raw)
To: Samuel Ortiz, Greg Kroah-Hartman, David S. Miller, netdev, devel,
LKML
Cc: Dmitry Vyukov, Kostya Serebryany, syzkaller
Hi!
I've got the following report while fuzzing the kernel with syzkaller.
On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4).
It seems that qos->baud_rate.bits value is taken from USB descriptor
and then used as a array index without any checks.
==================================================================
BUG: KASAN: global-out-of-bounds in irda_qos_bits_to_value+0x55a/0x5a0
Read of size 4 at addr ffffffff881f655c by task syz-executor/5582
CPU: 1 PID: 5582 Comm: syz-executor Not tainted
4.14.0-rc4-43423-g7263a3720c3f #392
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/0x395 lib/dump_stack.c:52
print_address_description+0x1d9/0x280 mm/kasan/report.c:252
kasan_report_error mm/kasan/report.c:351
kasan_report+0x23d/0x350 mm/kasan/report.c:409
__asan_report_load4_noabort+0x19/0x20 mm/kasan/report.c:429
irda_qos_bits_to_value+0x55a/0x5a0 drivers/staging/irda/net/qos.c:751
irda_usb_init_qos drivers/staging/irda/drivers/irda-usb.c:1389
irda_usb_open drivers/staging/irda/drivers/irda-usb.c:1411
irda_usb_probe+0x14ea/0x2ca0 drivers/staging/irda/drivers/irda-usb.c:1736
usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
really_probe drivers/base/dd.c:413
driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
__device_attach_driver+0x230/0x290 drivers/base/dd.c:653
bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
__device_attach+0x26e/0x3d0 drivers/base/dd.c:710
device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
device_add+0xd0b/0x1660 drivers/base/core.c:1835
usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
really_probe drivers/base/dd.c:413
driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
__device_attach_driver+0x230/0x290 drivers/base/dd.c:653
bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
__device_attach+0x26e/0x3d0 drivers/base/dd.c:710
device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
device_add+0xd0b/0x1660 drivers/base/core.c:1835
usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2538
hub_port_connect drivers/usb/core/hub.c:4984
hub_port_connect_change drivers/usb/core/hub.c:5090
port_event drivers/usb/core/hub.c:5196
hub_event_impl+0x1971/0x3760 drivers/usb/core/hub.c:5310
gfs_hub_events_handle+0x881/0xae0 drivers/usb/core/hub.c:1853
hub_ioctl+0x53d/0x680 drivers/usb/core/hub.c:1903
proc_ioctl+0x435/0x680 drivers/usb/core/devio.c:2175
proc_ioctl_default drivers/usb/core/devio.c:2198
usbdev_do_ioctl+0xee9/0x3790 drivers/usb/core/devio.c:2512
usbdev_ioctl+0x2a/0x40 drivers/usb/core/devio.c:2556
vfs_ioctl fs/ioctl.c:45
do_vfs_ioctl+0x1c4/0x15c0 fs/ioctl.c:685
SYSC_ioctl fs/ioctl.c:700
SyS_ioctl+0x94/0xc0 fs/ioctl.c:691
entry_SYSCALL_64_fastpath+0x23/0xc2 arch/x86/entry/entry_64.S:202
RIP: 0033:0x447707
RSP: 002b:00007ffd24fe61a8 EFLAGS: 00000202 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00000000ffffffff RCX: 0000000000447707
RDX: 00007ffd24fe61c0 RSI: 00000000c0105512 RDI: 0000000000000015
RBP: 0000000000000005 R08: 000000000265c940 R09: 000000000265c940
R10: 00000000004a8e59 R11: 0000000000000202 R12: 0000000000000015
R13: 0000000000000000 R14: 00007ffd24fe6078 R15: 00007ffd24fe60e8
The buggy address belongs to the variable:
baud_rates+0x3c/0x60
Memory state around the buggy address:
ffffffff881f6400: 00 00 00 00 00 00 00 fa fa fa fa fa 00 00 00 00
ffffffff881f6480: fa fa fa fa 00 00 fa fa fa fa fa fa 00 00 00 fa
>ffffffff881f6500: fa fa fa fa 00 00 00 00 00 fa fa fa fa fa fa fa
^
ffffffff881f6580: 00 00 00 00 fa fa fa fa 04 fa fa fa fa fa fa fa
ffffffff881f6600: 04 fa fa fa fa fa fa fa 04 fa fa fa fa fa fa fa
==================================================================
^ permalink raw reply
* usb/net/rtlwifi: trying to register non-static key in rtl_c2hcmd_launcher
From: Andrey Konovalov @ 2017-10-09 17:50 UTC (permalink / raw)
To: Larry Finger, Chaoming Li, Kalle Valo, linux-wireless, netdev,
LKML
Cc: Dmitry Vyukov, Kostya Serebryany, syzkaller
Hi!
I've got the following report while fuzzing the kernel with syzkaller.
On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4).
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted
4.14.0-rc4-43418-g43a3f84d2109-dirty #391
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
__dump_stack lib/dump_stack.c:16
dump_stack+0x292/0x395 lib/dump_stack.c:52
register_lock_class+0x6c4/0x1a00 kernel/locking/lockdep.c:769
__lock_acquire+0x27e/0x4550 kernel/locking/lockdep.c:3385
lock_acquire+0x259/0x620 kernel/locking/lockdep.c:4002
__raw_spin_lock_irqsave ./include/linux/spinlock_api_smp.h:110
_raw_spin_lock_irqsave+0xcc/0x110 kernel/locking/spinlock.c:159
rtl_c2hcmd_launcher+0x3ca/0x5d0
drivers/net/wireless/realtek/rtlwifi/base.c:2052
rtl_deinit_core+0x79/0x350 drivers/net/wireless/realtek/rtlwifi/base.c:590
rtl_usb_probe+0x1ca3/0x2470 drivers/net/wireless/realtek/rtlwifi/usb.c:1128
rtl8192cu_probe+0x29/0x30
drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c:398
usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
really_probe drivers/base/dd.c:413
driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
__device_attach_driver+0x230/0x290 drivers/base/dd.c:653
bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
__device_attach+0x26e/0x3d0 drivers/base/dd.c:710
device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
device_add+0xd0b/0x1660 drivers/base/core.c:1835
usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
really_probe drivers/base/dd.c:413
driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
__device_attach_driver+0x230/0x290 drivers/base/dd.c:653
bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
__device_attach+0x26e/0x3d0 drivers/base/dd.c:710
device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
device_add+0xd0b/0x1660 drivers/base/core.c:1835
usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
hub_port_connect drivers/usb/core/hub.c:4903
hub_port_connect_change drivers/usb/core/hub.c:5009
port_event drivers/usb/core/hub.c:5115
hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
worker_thread+0x221/0x1850 kernel/workqueue.c:2253
kthread+0x3a1/0x470 kernel/kthread.c:231
ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
^ permalink raw reply
* Re: [net PATCH] macvlan: Only deliver one copy of the frame to the macvlan interface
From: Alexander Duyck @ 2017-10-09 17:50 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Netdev, David Miller
In-Reply-To: <CAKgT0Ueb8O_Exh6ERaQev7kE-xv89Dqkn4C2uWNtmLaqQXZrKw@mail.gmail.com>
On Mon, Oct 9, 2017 at 10:30 AM, Alexander Duyck
<alexander.duyck@gmail.com> wrote:
> On Sun, Oct 8, 2017 at 6:07 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>> On Sun, 2017-10-08 at 15:54 -0700, Alexander Duyck wrote:
>>> From: Alexander Duyck <alexander.h.duyck@intel.com>
>>>
>>> This patch intoduces a slight adjustment for macvlan to address the fact
>>> that in source mode I was seeing two copies of any packet addressed to the
>>> macvlan interface being delivered where there should have been only one.
>>>
>>> The issue appears to be that one copy was delivered based on the source MAC
>>> address and then the second copy was being delivered based on the
>>> destination MAC address. To fix it I am just freeing the second copy
>>> instead of delivering it up the stack using the same netdev as was already
>>> delivered to.
>>>
>>> Fixes: 79cf79abce71 ("macvlan: add source mode")
>>> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
>>> ---
>>> drivers/net/macvlan.c | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
>>> index d2aea961e0f4..744b0fe6dc78 100644
>>> --- a/drivers/net/macvlan.c
>>> +++ b/drivers/net/macvlan.c
>>> @@ -484,7 +484,8 @@ static rx_handler_result_t macvlan_handle_frame(struct sk_buff **pskb)
>>> return RX_HANDLER_PASS;
>>>
>>> dev = vlan->dev;
>>> - if (unlikely(!(dev->flags & IFF_UP))) {
>>> + if ((vlan->mode == MACVLAN_MODE_SOURCE) ||
>>> + unlikely(!(dev->flags & IFF_UP))) {
>>> kfree_skb(skb);
>>> return RX_HANDLER_CONSUMED;
>>> }
>>>
>>
>>
>> Shouldn't we have a consume_skb() then instead of kfree_skb() ?
>>
>> We are not really dropping a packet here, only avoiding some artifact
>> cause by the cited commit.
>
> The cited commit basically introduced an issue where we are cloning it
> and sending the clone to the correct device and then are stuck with
> the original. The way I fixed it is currently consistent with how
> broadcast is already being handled for macvlan since they are calling
> kfree_skb() on the clone that they end up enqueueing for broadcast.
>
> My thought is to look at rewriting this in relation to some other work
> I am doing, but I wanted to have a fix for net and stable kernels that
> prevents this frame duplication from occurring. Really in order to
> handle this correctly my thought is that we should probably be doing a
> vlan_prev similar to how we have a pt_prev in
> __netif_receive_skb_core. Then that way when a packet is meant to be
> handled by one interface, as is the case for most unicast traffic with
> VLAN regardless of source mode or not we can then just jump back in
> using RX_HANDLER_ANOTHER.
>
> - Alex
Actually, now that I am thinking it over again maybe us calling
kfree_skb() isn't the correct answer. It might make more sense to just
return RX_HANDLER_PASS. Then we can defer it to the original interface
to drop it.
- Alex
^ permalink raw reply
* usb/net/ath6kl: GPF in ath6kl_usb_alloc_urb_from_pipe
From: Andrey Konovalov @ 2017-10-09 17:50 UTC (permalink / raw)
To: Kalle Valo, linux-wireless, netdev, LKML
Cc: Dmitry Vyukov, Kostya Serebryany, syzkaller
Hi!
I've got the following report while fuzzing the kernel with syzkaller.
On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4).
usb 1-1: New USB device found, idVendor=0cf3, idProduct=9375
usb 1-1: New USB device strings: Mfr=2, Product=255, SerialNumber=8
usb 1-1: Product: a
usb 1-1: Manufacturer: a
usb 1-1: SerialNumber: a
gadgetfs: configuration #9
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
Modules linked in:
CPU: 1 PID: 1494 Comm: kworker/1:1 Not tainted
4.14.0-rc4-43418-g43a3f84d2109 #379
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
task: ffff880068e9ca40 task.stack: ffff880068948000
RIP: 0010:__lock_acquire+0xe18/0x4550 kernel/locking/lockdep.c:3376
RSP: 0018:ffff88006894d788 EFLAGS: 00010006
RAX: dffffc0000000000 RBX: dffffc0000000000 RCX: 0000000000000000
RDX: 0000000000000003 RSI: 0000000000000000 RDI: 1ffff1000d129b3c
RBP: ffff88006894dd08 R08: 0000000000000001 R09: 0000000000000001
R10: 0000000000000000 R11: ffffffff89789760 R12: ffff880068e9ca40
R13: dffffc0000000000 R14: 0000000000000001 R15: 0000000000000018
FS: 0000000000000000(0000) GS:ffff88006c500000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f9558dca000 CR3: 0000000066dc4000 CR4: 00000000000006e0
Call Trace:
lock_acquire+0x259/0x620 kernel/locking/lockdep.c:4002
__raw_spin_lock_irqsave ./include/linux/spinlock_api_smp.h:110
_raw_spin_lock_irqsave+0xcc/0x110 kernel/locking/spinlock.c:159
ath6kl_usb_alloc_urb_from_pipe+0x103/0x4c0
drivers/net/wireless/ath/ath6kl/usb.c:135
ath6kl_usb_post_recv_transfers.constprop.10+0x228/0x420
drivers/net/wireless/ath/ath6kl/usb.c:410
ath6kl_usb_start_recv_pipes drivers/net/wireless/ath/ath6kl/usb.c:484
hif_start drivers/net/wireless/ath/ath6kl/usb.c:682
ath6kl_usb_power_on+0x8a/0x120 drivers/net/wireless/ath/ath6kl/usb.c:1041
ath6kl_hif_power_on drivers/net/wireless/ath/ath6kl/hif-ops.h:136
ath6kl_core_init+0x180/0x1190 drivers/net/wireless/ath/ath6kl/core.c:97
ath6kl_usb_probe+0xdf4/0x1420 drivers/net/wireless/ath/ath6kl/usb.c:1147
usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
really_probe drivers/base/dd.c:413
driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
__device_attach_driver+0x230/0x290 drivers/base/dd.c:653
bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
__device_attach+0x26e/0x3d0 drivers/base/dd.c:710
device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
device_add+0xd0b/0x1660 drivers/base/core.c:1835
usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
really_probe drivers/base/dd.c:413
driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
__device_attach_driver+0x230/0x290 drivers/base/dd.c:653
bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
__device_attach+0x26e/0x3d0 drivers/base/dd.c:710
device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
device_add+0xd0b/0x1660 drivers/base/core.c:1835
usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
hub_port_connect drivers/usb/core/hub.c:4903
hub_port_connect_change drivers/usb/core/hub.c:5009
port_event drivers/usb/core/hub.c:5115
hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
worker_thread+0x221/0x1850 kernel/workqueue.c:2253
kthread+0x3a1/0x470 kernel/kthread.c:231
ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
Code: 89 f0 c7 07 00 00 00 00 48 81 c4 58 05 00 00 5b 41 5c 41 5d 41
5e 41 5f 5d c3 48 b8 00 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 <80>
3c 02 00 0f 85 b2 36 00 00 49 81 3f 00 52 bb 88 41 be 00 00
RIP: __lock_acquire+0xe18/0x4550 RSP: ffff88006894d788
---[ end trace 56dead20dbd7b387 ]---
^ permalink raw reply
* usb/net/ar5523: warning in ar5523_submit_rx_cmd/usb_submit_urb
From: Andrey Konovalov @ 2017-10-09 17:49 UTC (permalink / raw)
To: Pontus Fuchs, Kalle Valo, linux-wireless, netdev, LKML
Cc: Dmitry Vyukov, Kostya Serebryany, syzkaller
Hi!
I've got the following report while fuzzing the kernel with syzkaller.
On commit 8a5776a5f49812d29fe4b2d0a2d71675c3facf3f (4.14-rc4).
It seems that the driver doesn't check the endpoint type provided in
the USB descriptor.
usb 1-1: BOGUS urb xfer, pipe 3 != type 1
------------[ cut here ]------------
WARNING: CPU: 1 PID: 2265 at drivers/usb/core/urb.c:449
usb_submit_urb+0xf8a/0x11d0
Modules linked in:
CPU: 1 PID: 2265 Comm: kworker/1:2 Not tainted
4.14.0-rc4-43418-g43a3f84d2109 #379
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
task: ffff88006abc8000 task.stack: ffff880063e08000
RIP: 0010:usb_submit_urb+0xf8a/0x11d0 drivers/usb/core/urb.c:448
RSP: 0000:ffff880063e0ded0 EFLAGS: 00010286
RAX: 0000000000000029 RBX: ffff8800694cbf00 RCX: 0000000000000000
RDX: 0000000000000029 RSI: ffffffff86a76d40 RDI: ffffed000c7c1bcc
RBP: ffff880063e0dfd0 R08: 1ffff1000c7c1a72 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 1ffff1000c7c1be1
R13: 0000000000000001 R14: 0000000000000003 R15: ffff88006bb47e10
FS: 0000000000000000(0000) GS:ffff88006c500000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f43b3d37000 CR3: 00000000695d4000 CR4: 00000000000006e0
Call Trace:
ar5523_submit_rx_cmd+0x20a/0x320 drivers/net/wireless/ath/ar5523/ar5523.c:208
ar5523_probe+0x1683/0x3af0 drivers/net/wireless/ath/ar5523/ar5523.c:1643
usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
really_probe drivers/base/dd.c:413
driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
__device_attach_driver+0x230/0x290 drivers/base/dd.c:653
bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
__device_attach+0x26e/0x3d0 drivers/base/dd.c:710
device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
device_add+0xd0b/0x1660 drivers/base/core.c:1835
usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
really_probe drivers/base/dd.c:413
driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
__device_attach_driver+0x230/0x290 drivers/base/dd.c:653
bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
__device_attach+0x26e/0x3d0 drivers/base/dd.c:710
device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
device_add+0xd0b/0x1660 drivers/base/core.c:1835
usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
hub_port_connect drivers/usb/core/hub.c:4903
hub_port_connect_change drivers/usb/core/hub.c:5009
port_event drivers/usb/core/hub.c:5115
hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
worker_thread+0x221/0x1850 kernel/workqueue.c:2253
kthread+0x3a1/0x470 kernel/kthread.c:231
ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
Code: 48 8b 85 30 ff ff ff 48 8d b8 98 00 00 00 e8 6e df c7 fe 45 89
e8 44 89 f1 4c 89 fa 48 89 c6 48 c7 c7 c0 ce 04 87 e8 50 6d 16 fd <0f>
ff e9 9b f7 ff ff e8 9a f1 5f fd e9 80 f7 ff ff e8 60 c4 2d
---[ end trace 4ec8ea7915652acc ]---
^ permalink raw reply
* Re: [PATCH net-next 0/2] ipv6: addrlabel: avoid dirtying ip6addrlbl_entry
From: David Miller @ 2017-10-09 17:47 UTC (permalink / raw)
To: kafai; +Cc: edumazet, netdev, eric.dumazet, yoshfuji
In-Reply-To: <20171009174417.gpfghoxctgksdzaz@kafai-mbp.dhcp.thefacebook.com>
From: Martin KaFai Lau <kafai@fb.com>
Date: Mon, 9 Oct 2017 10:44:17 -0700
> On Mon, Oct 09, 2017 at 04:52:23PM +0000, Eric Dumazet wrote:
>> The refcount on ip6addrlbl_entry is only used to make sure ip6addrlbl_entry
>> does not disappear while ip6addrlbl_get() is allocating an skb.
>>
>> We can instead allocate skb first, then use RCU, so that we no longer need
>> to refcount these structures.
> Acked-by: Martin KaFai Lau <kafai@fb.com>
Series applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH net-next 0/2] ipv6: addrlabel: avoid dirtying ip6addrlbl_entry
From: Martin KaFai Lau @ 2017-10-09 17:44 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S . Miller, netdev, Eric Dumazet, Hideaki YOSHIFUJI
In-Reply-To: <20171009165225.7008-1-edumazet@google.com>
On Mon, Oct 09, 2017 at 04:52:23PM +0000, Eric Dumazet wrote:
> The refcount on ip6addrlbl_entry is only used to make sure ip6addrlbl_entry
> does not disappear while ip6addrlbl_get() is allocating an skb.
>
> We can instead allocate skb first, then use RCU, so that we no longer need
> to refcount these structures.
Acked-by: Martin KaFai Lau <kafai@fb.com>
^ permalink raw reply
* Re: [PATCH] net: thunderx: mark expected switch fall-throughs in nicvf_main()
From: David Miller @ 2017-10-09 17:43 UTC (permalink / raw)
To: gustavo; +Cc: sgoutham, rric, linux-arm-kernel, netdev, linux-kernel
In-Reply-To: <20171009164453.GA4889@embeddedor.com>
From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
Date: Mon, 9 Oct 2017 11:44:53 -0500
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> Cc: Sunil Goutham <sgoutham@cavium.com>
> Cc: Robert Richter <rric@kernel.org>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: netdev@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Applied.
^ permalink raw reply
* Re: [PATCH 00/12] Netfilter/IPVS fixes for net
From: David Miller @ 2017-10-09 17:40 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1507566346-32553-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Mon, 9 Oct 2017 18:25:34 +0200
> The following patchset contains Netfilter/IPVS fixes for your net tree,
> they are:
...
> You can pull these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git
Pulled, thanks!
^ permalink raw reply
* Re: [net 0/5][pull request] Intel Wired LAN Driver Updates 2017-10-09
From: David Miller @ 2017-10-09 17:36 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <20171009151251.53939-1-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Mon, 9 Oct 2017 08:12:46 -0700
> This series contains updates to ixgbe and arch/Kconfig.
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH v2] isdn/gigaset: Convert timers to use timer_setup()
From: Kees Cook @ 2017-10-09 17:36 UTC (permalink / raw)
To: David Laight
Cc: Paul Bolle, Karsten Keil, David S. Miller, Johan Hovold, LKML,
gigaset307x-common@lists.sourceforge.net, Network Development
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DD008D392@AcuExch.aculab.com>
On Mon, Oct 9, 2017 at 2:15 AM, David Laight <David.Laight@aculab.com> wrote:
> From: Kees Cook
>> Sent: 06 October 2017 20:40
> ...
>> I'm in no rush for any specific change. There are about 900 call sites
>> I'm making my way through, about 2/3rd are pretty trivial, and the
>> less obvious is what I've started sending out now, since I expect some
>> will need some more careful review.
>
> Is it worth adding a structure that contains a timer and an extra 'long'
> than can be used to maintain the existing API logic for the 'difficult'
> cases?
I didn't want to have this available in the general case, since I'd
like to get all the conversions actually finished. There are a couple
very special cases that need this, and they have one-off structs that
do this.
-Kees
--
Kees Cook
Pixel Security
^ permalink raw reply
* Re: [PATCH net-next 0/3] Fix mlx4 static checker warnings
From: David Miller @ 2017-10-09 17:33 UTC (permalink / raw)
To: tariqt; +Cc: netdev, eranbe
In-Reply-To: <1507557590-17747-1-git-send-email-tariqt@mellanox.com>
From: Tariq Toukan <tariqt@mellanox.com>
Date: Mon, 9 Oct 2017 16:59:47 +0300
> This patchset contains fixes for static checker warnings
> in the mlx4 Core and Eth drivers.
>
> Patch 1 fixes an actual bug discovered by the checker.
> Patches 2 and 3 fix the warnings without functional changes.
>
> Series generated against net-next commit:
> c49c777f9c87 qed: Delete redundant check on dcb_app priority
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] thunderbolt: Initialize Thunderbolt bus earlier
From: David Miller @ 2017-10-09 17:30 UTC (permalink / raw)
To: mika.westerberg
Cc: andreas.noever, michael.jamet, yehezkel.bernat, fengguang.wu,
gregkh, andriy.shevchenko, netdev, linux-kernel
In-Reply-To: <20171009132234.65540-1-mika.westerberg@linux.intel.com>
From: Mika Westerberg <mika.westerberg@linux.intel.com>
Date: Mon, 9 Oct 2017 16:22:34 +0300
> The 0day kbuild robot reports following crash:
...
> The reason is that both Thunderbolt bus and thunderbolt-net are build
> into the kernel image, and the latter is linked first because
> drivers/net comes before drivers/thunderbolt. Since both use
> module_init() thunderbolt-net ends up calling Thunderbolt bus functions
> too early triggering the above crash.
>
> Fix this by moving Thunderbolt bus initialization to happen earlier to
> make sure all the data structures are ready when Thunderbolt service
> drivers are initialized. To be on the safe side also add a check for
> properly initialized xdomain_property_dir to tb_register_property_dir().
>
> Reported-by: kernel test robot <fengguang.wu@intel.com>
> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [net PATCH] macvlan: Only deliver one copy of the frame to the macvlan interface
From: Alexander Duyck @ 2017-10-09 17:30 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Netdev, David Miller
In-Reply-To: <1507511262.14419.32.camel@edumazet-glaptop3.roam.corp.google.com>
On Sun, Oct 8, 2017 at 6:07 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Sun, 2017-10-08 at 15:54 -0700, Alexander Duyck wrote:
>> From: Alexander Duyck <alexander.h.duyck@intel.com>
>>
>> This patch intoduces a slight adjustment for macvlan to address the fact
>> that in source mode I was seeing two copies of any packet addressed to the
>> macvlan interface being delivered where there should have been only one.
>>
>> The issue appears to be that one copy was delivered based on the source MAC
>> address and then the second copy was being delivered based on the
>> destination MAC address. To fix it I am just freeing the second copy
>> instead of delivering it up the stack using the same netdev as was already
>> delivered to.
>>
>> Fixes: 79cf79abce71 ("macvlan: add source mode")
>> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
>> ---
>> drivers/net/macvlan.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
>> index d2aea961e0f4..744b0fe6dc78 100644
>> --- a/drivers/net/macvlan.c
>> +++ b/drivers/net/macvlan.c
>> @@ -484,7 +484,8 @@ static rx_handler_result_t macvlan_handle_frame(struct sk_buff **pskb)
>> return RX_HANDLER_PASS;
>>
>> dev = vlan->dev;
>> - if (unlikely(!(dev->flags & IFF_UP))) {
>> + if ((vlan->mode == MACVLAN_MODE_SOURCE) ||
>> + unlikely(!(dev->flags & IFF_UP))) {
>> kfree_skb(skb);
>> return RX_HANDLER_CONSUMED;
>> }
>>
>
>
> Shouldn't we have a consume_skb() then instead of kfree_skb() ?
>
> We are not really dropping a packet here, only avoiding some artifact
> cause by the cited commit.
The cited commit basically introduced an issue where we are cloning it
and sending the clone to the correct device and then are stuck with
the original. The way I fixed it is currently consistent with how
broadcast is already being handled for macvlan since they are calling
kfree_skb() on the clone that they end up enqueueing for broadcast.
My thought is to look at rewriting this in relation to some other work
I am doing, but I wanted to have a fix for net and stable kernels that
prevents this frame duplication from occurring. Really in order to
handle this correctly my thought is that we should probably be doing a
vlan_prev similar to how we have a pt_prev in
__netif_receive_skb_core. Then that way when a packet is meant to be
handled by one interface, as is the case for most unicast traffic with
VLAN regardless of source mode or not we can then just jump back in
using RX_HANDLER_ANOTHER.
- Alex
^ permalink raw reply
* [PATCH net-next v2 7/7] bpf: write back the verifier log buffer as it gets filled
From: Jakub Kicinski @ 2017-10-09 17:30 UTC (permalink / raw)
To: netdev; +Cc: oss-drivers, alexei.starovoitov, daniel, Jakub Kicinski
In-Reply-To: <20171009173015.23520-1-jakub.kicinski@netronome.com>
Verifier log buffer can be quite large (up to 16MB currently).
As Eric Dumazet points out if we allow multiple verification
requests to proceed simultaneously, malicious user may use the
verifier as a way of allocating large amounts of unswappable
memory to OOM the host.
Switch to a strategy of allocating a smaller buffer (1024B)
and writing it out into the user buffer after every print.
While at it remove the old BUG_ON().
This is in preparation of the global verifier lock removal.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Simon Horman <simon.horman@netronome.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
---
include/linux/bpf_verifier.h | 4 +++-
kernel/bpf/verifier.c | 41 +++++++++++++++++++----------------------
2 files changed, 22 insertions(+), 23 deletions(-)
diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
index 5ddb9a626a51..f00ef751c1c5 100644
--- a/include/linux/bpf_verifier.h
+++ b/include/linux/bpf_verifier.h
@@ -115,9 +115,11 @@ struct bpf_insn_aux_data {
#define MAX_USED_MAPS 64 /* max number of maps accessed by one eBPF program */
+#define BPF_VERIFIER_TMP_LOG_SIZE 1024
+
struct bpf_verifer_log {
u32 level;
- char *kbuf;
+ char kbuf[BPF_VERIFIER_TMP_LOG_SIZE];
char __user *ubuf;
u32 len_used;
u32 len_total;
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 511602969c5e..8d08a266aa42 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -165,15 +165,26 @@ static __printf(2, 3) void verbose(struct bpf_verifier_env *env,
const char *fmt, ...)
{
struct bpf_verifer_log *log = &env->log;
+ unsigned int n;
va_list args;
- if (!log->level || bpf_verifier_log_full(log))
+ if (!log->level || !log->ubuf || bpf_verifier_log_full(log))
return;
va_start(args, fmt);
- log->len_used += vscnprintf(log->kbuf + log->len_used,
- log->len_total - log->len_used, fmt, args);
+ n = vscnprintf(log->kbuf, BPF_VERIFIER_TMP_LOG_SIZE, fmt, args);
va_end(args);
+
+ WARN_ONCE(n >= BPF_VERIFIER_TMP_LOG_SIZE - 1,
+ "verifier log line truncated - local buffer too short\n");
+
+ n = min(log->len_total - log->len_used - 1, n);
+ log->kbuf[n] = '\0';
+
+ if (!copy_to_user(log->ubuf + log->len_used, log->kbuf, n + 1))
+ log->len_used += n;
+ else
+ log->ubuf = NULL;
}
static bool type_is_pkt_pointer(enum bpf_reg_type type)
@@ -4258,11 +4269,6 @@ int bpf_check(struct bpf_prog **prog, union bpf_attr *attr)
if (log->len_total < 128 || log->len_total > UINT_MAX >> 8 ||
!log->level || !log->ubuf)
goto err_unlock;
-
- ret = -ENOMEM;
- log->kbuf = vmalloc(log->len_total);
- if (!log->kbuf)
- goto err_unlock;
}
env->strict_alignment = !!(attr->prog_flags & BPF_F_STRICT_ALIGNMENT);
@@ -4299,18 +4305,11 @@ int bpf_check(struct bpf_prog **prog, union bpf_attr *attr)
if (ret == 0)
ret = fixup_bpf_calls(env);
- if (log->level && bpf_verifier_log_full(log)) {
- BUG_ON(log->len_used >= log->len_total);
- /* verifier log exceeded user supplied buffer */
+ if (log->level && bpf_verifier_log_full(log))
ret = -ENOSPC;
- /* fall through to return what was recorded */
- }
-
- /* copy verifier log back to user space including trailing zero */
- if (log->level && copy_to_user(log->ubuf, log->kbuf,
- log->len_used + 1) != 0) {
+ if (log->level && !log->ubuf) {
ret = -EFAULT;
- goto free_log_buf;
+ goto err_release_maps;
}
if (ret == 0 && env->used_map_cnt) {
@@ -4321,7 +4320,7 @@ int bpf_check(struct bpf_prog **prog, union bpf_attr *attr)
if (!env->prog->aux->used_maps) {
ret = -ENOMEM;
- goto free_log_buf;
+ goto err_release_maps;
}
memcpy(env->prog->aux->used_maps, env->used_maps,
@@ -4334,9 +4333,7 @@ int bpf_check(struct bpf_prog **prog, union bpf_attr *attr)
convert_pseudo_ld_imm64(env);
}
-free_log_buf:
- if (log->level)
- vfree(log->kbuf);
+err_release_maps:
if (!env->prog->aux->used_maps)
/* if we didn't copy map pointers into bpf_prog_info, release
* them now. Otherwise free_bpf_prog_info() will release them.
--
2.14.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox