- 10 Jun, 2016 40 commits
-
-
Eric Dumazet authored
BugLink: http://bugs.launchpad.net/bugs/1584912 [ Upstream commit fc96256c ] When multiple skb are TX-completed in a row, we might incorrectly keep a timestamp of a prior skb and cause extra work. Fixes: ec693d47 ("net/mlx4_en: Add HW timestamping (TS) support") Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: Willem de Bruijn <willemb@google.com> Reviewed-by:
Eran Ben Elisha <eranbe@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Signed-off-by:
Kamal Mostafa <kamal@canonical.com>
-
Paolo Abeni authored
BugLink: http://bugs.launchpad.net/bugs/1584912 [ Upstream commit 391a2033 ] After commit fbd40ea0 ("ipv4: Don't do expensive useless work during inetdev destroy.") when deleting an interface, fib_del_ifaddr() can be executed without any primary address present on the dead interface. The above is safe, but triggers some "bug: prim == NULL" warnings. This commit avoids warning if the in_dev is dead Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
-
Simon Horman authored
BugLink: http://bugs.launchpad.net/bugs/1584912 [ Upstream commit b4f70527 ] When using masked actions the ipv6_proto field of an action to set IPv6 fields may be zero rather than the prevailing protocol which will result in skipping checksum recalculation. This patch resolves the problem by relying on the protocol in the flow key rather than that in the set field action. Fixes: 83d2b9ba ("net: openvswitch: Support masked set actions.") Cc: Jarno Rajahalme <jrajahalme@nicira.com> Signed-off-by:
Simon Horman <simon.horman@netronome.com> Signed-off-by:
-
Daniel Borkmann authored
BugLink: http://bugs.launchpad.net/bugs/1584912 [ Upstream commit 9241e2df ] When __vlan_insert_tag() fails from skb_vlan_push() path due to the skb_cow_head(), we need to undo the __skb_push() in the error path as well that was done earlier to move skb->data pointer to mac header. Moreover, I noticed that when in the non-error path the __skb_pull() is done and the original offset to mac header was non-zero, we fixup from a wrong skb->data offset in the checksum complete processing. So the skb_postpush_rcsum() really needs to be done before __skb_pull() where skb->data still points to the mac header start and thus operates under the same conditions as in __vlan_insert_tag(). Fixes: 93515d53 ("net: move vlan pop/push functions into common code") Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Reviewed-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Daniel Borkmann authored
BugLink: http://bugs.launchpad.net/bugs/1584912 [ Upstream commit 6b83d28a ] Replace individual implementations with the recently introduced skb_postpush_rcsum() helper. Signed-off-by:
Tom Herbert <tom@herbertland.com> Acked-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
-
Bjørn Mork authored
BugLink: http://bugs.launchpad.net/bugs/1584912 [ Upstream commit c5b5343c ] We now have a positive report of another Huawei device needing this quirk: The ME906s-158 (12d1:15c1). This is an m.2 form factor modem with no obvious relationship to the E3372 (12d1:157d) we already have a quirk entry for. This is reason enough to believe the quirk might be necessary for any number of current and future Huawei devices. Applying the quirk to all Huawei devices, since it is crucial to any device affected by the firmware bug, while the impact on non-affected devices is negligible. The quirk can if necessary be disabled per-device by writing N to /sys/class/net/<iface>/cdc_ncm/ndp_to_end Reported-by:
Andreas Fett <andreas.fett@secunet.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Alexei Starovoitov authored
BugLink: http://bugs.launchpad.net/bugs/1584912 [ Upstream commit d82bccc6 ] verifier must check for reserved size bits in instruction opcode and reject BPF_LD | BPF_ABS | BPF_DW and BPF_LD | BPF_IND | BPF_DW instructions, otherwise interpreter will WARN_RATELIMIT on them during execution. Fixes: ddd872bc ("bpf: verifier: add checks for BPF_ABS | BPF_IND instructions") Signed-off-by:
-
Lars Persson authored
BugLink: http://bugs.launchpad.net/bugs/1584912 [ Upstream commit 3dcd493f ] A failure in validate_xmit_skb_list() triggered an unconditional call to dev_requeue_skb with skb=NULL. This slowly grows the queue discipline's qlen count until all traffic through the queue stops. We take the optimistic approach and continue running the queue after a failure since it is unknown if later packets also will fail in the validate path. Fixes: 55a93b3e ("qdisc: validate skb without holding lock") Signed-off-by:
Lars Persson <larper@axis.com> Acked-by:
-
Mathias Krause authored
BugLink: http://bugs.launchpad.net/bugs/1584912 [ Upstream commit 309cf37f ] Because we miss to wipe the remainder of i->addr[] in packet_mc_add(), pdiag_put_mclist() leaks uninitialized heap bytes via the PACKET_DIAG_MCLIST netlink attribute. Fix this by explicitly memset(0)ing the remaining bytes in i->addr[]. Fixes: eea68e2f ("packet: Report socket mclist info via diag module") Signed-off-by:
Mathias Krause <minipli@googlemail.com> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Pavel Emelyanov <xemul@parallels.com> Acked-by:
Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by:
-
Chris Friesen authored
BugLink: http://bugs.launchpad.net/bugs/1584912 [ Upstream commit d6d5e999 ] For local routes that require a particular output interface we do not want to cache the result. Caching the result causes incorrect behaviour when there are multiple source addresses on the interface. The end result being that if the intended recipient is waiting on that interface for the packet he won't receive it because it will be delivered on the loopback interface and the IP_PKTINFO ipi_ifindex will be set to the loopback interface as well. This can be tested by running a program such as "dhcp_release" which attempts to inject a packet on a particular interface so that it is received by another program on the same board. The receiving process should see an IP_PKTINFO ipi_ifndex value of the source interface (e.g., eth1) instead of the loopback interface (e.g., lo). The packet will still appear on the loopback interface in tcpdump but the important aspect is that the CMSG info is correct. Sample dhcp_release command line: dhcp_release eth1 192.168.204.222 02:11:33:22:44:66 Signed-off-by:
Allain Legacy <allain.legacy@windriver.com> Signed off-by: Chris Friesen <chris.friesen@windriver.com> Reviewed-by:
Julian Anastasov <ja@ssi.bg> Signed-off-by:
-
David S. Miller authored
BugLink: http://bugs.launchpad.net/bugs/1584912 [ Upstream commit a36a0d40 ] In particular, make sure we check for decnet private presence for loopback devices. Signed-off-by:
-
Wen-chien Jesse Sung authored
BugLink: https://launchpad.net/bugs/1512999 For Edge Gateway 5000/5100 only. Add code for controlling bluetooth LED via firmware, and turns the LED on and off when the interface is up and down accordingly. Base on the code found at https://chromium.googlesource.com/chromiumos/third_party/kernel/+/8300e2ccad47c5c2f10507661c10d4892211790e%5E%21/#F0Signed-off-by:
Wen-chien Jesse Sung <jesse.sung@canonical.com> Reviewed-By:
AceLan Kao <acelan.kao@canonical.com> Acked-by:
-
Wen-chien Jesse Sung authored
BugLink: https://launchpad.net/bugs/1512997 For Edge Gateway 5000/5100 only. Add code for controlling WiFi LED via firmware, and turns the LED on and off when the interface is up and down accordingly. Signed-off-by:
-
chunfan chen authored
BugLink: https://launchpad.net/bugs/1528910 The patch allows user to 1. Enable turbo mode in firmware using following command. iw dev mlan0 vendor send 0x005043 0x00 0x01 2. Download configuration data to FW using following command iw dev mlan0 vendor send 0x005043 0x01 filename Signed-off-by:
chunfan chen <jeffc@marvell.com> Signed-off-by:
Amitkumar Karwar <akarwar@marvell.com> Signed-off-by:
-
Amitkumar Karwar authored
BugLink: https://launchpad.net/bugs/1528910 It's better to use world if region code from EEPROM is unidentied instead of forcing it to FCC Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> (cherry picked from commit 19b0a710) Signed-off-by:
-
Amitkumar Karwar authored
BugLink: https://launchpad.net/bugs/1528910 This array contains list of supported region codes. It is changed to make it aligned with region code to country mapping table in driver. Signed-off-by:
-
Amitkumar Karwar authored
BugLink: https://launchpad.net/bugs/1528910 EU is not a valid country in db.txt file. Hence regulatory_hint returns failure if EEPROM provides region code as 0x30. Let's use FR for 0x30. Signed-off-by:
Cathy Luo <cluo@marvell.com> Signed-off-by:
-
Amitkumar Karwar authored
BugLink: https://launchpad.net/bugs/1528910 If device has already received country information from EEPROM, we won't parse AP's country IE and download it to firmware. We will also set regulatory flags to disable beacon hints and ignore country IE. Signed-off-by:
-
Amitkumar Karwar authored
BugLink: https://launchpad.net/bugs/1528910 Driver gets country information from EEPROM during initialization. We will call regulatory_hint to update current regulatory domain. As by default world regulatory domain is selected by cfg80211, country '00' from EEPROM is ignored. Signed-off-by:
-
Amitkumar Karwar authored
BugLink: https://launchpad.net/bugs/1528910 It's been observed that even if firmware returns an error for a configuration command, we go ahead and start AP. This patch changes the command type from async to sync so that threads waits for command response and return failure start AP. Signed-off-by:
-
Amitkumar Karwar authored
BugLink: https://launchpad.net/bugs/1528910 Even if ADHOC start or join attempt is failed, these commands are returned with success status by firmware. Actual connection result is provided inside command response. This patch parses the adhoc connection result and resets connection state variables if connection is not successful. Signed-off-by:
-
J. R. Okajima authored
UBUNTU: SAUCE: AUFS: mm/mmap: fix oopsing on remap_file_pages aufs mmap: bugfix, mainly for linux-4.5-rc5, remap_file_pages(2) emulation BugLink: http://bugs.launchpad.net/bugs/1558120 This is essentially same to the past commit for aufs3.9 f84155f 2014-06-11 aufs mmap: bugfix remap_file_pages(2) But the remap_file_pages(2) changed drastically in linux-4.0 by c8d78c18 2015-02-10 mm: replace remap_file_pages() syscall with emulation and then a bugfix was commited in linux-4.5-rc5. 48f7df32 2016-02-18 mm: fix regression in remap_file_pages() emulation After the bugfix in 4.5-rc5, Colin Ian King found and reported this aufs bug. See-also: https://github.com/sfjro/aufs4-linux/pull/1Signed-off-by:
J. R. Okajima <hooanon05g@gmail.com> (cherry picked from https://github.com/sfjro/aufs4-linux.git commit 1ecc0837923753cb234f8c3deffec3400cf78731) Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1558120 This reverts commit c7082994. Revert in favor of slightly different upstream patch. Signed-off-by:
-
Felipe Balbi authored
BugLink: http://bugs.launchpad.net/bugs/1584163 commit 4f41fc59 ("cgroup, kernfs: make mountinfo show properly scoped path for cgroup namespaces") added the following compile warning: kernel/cgroup.c: In function ‘cgroup_show_path’: kernel/cgroup.c:1634:15: warning: unused variable ‘ret’ [-Wunused-variable] int len = 0, ret = 0; ^ fix it. Fixes: 4f41fc59 ("cgroup, kernfs: make mountinfo show properly scoped path for cgroup namespaces") Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
Tejun Heo <tj@kernel.org> (cherry picked from commit 09be4c82) Cc: Serge Hallyn <serge.hallyn@ubuntu.com> Signed-off-by:
-
Serge E. Hallyn authored
BugLink: http://bugs.launchpad.net/bugs/1584163 Our caller expects 0 on success, not >0. This fixes a bug in the patch cgroup, kernfs: make mountinfo show properly scoped path for cgroup namespaces where /sys does not show up in mountinfo, breaking criu. Thanks for catching this, Andrei. Reported-by:
Andrei Vagin <avagin@gmail.com> Signed-off-by:
Serge Hallyn <serge.hallyn@ubuntu.com> Signed-off-by:
-
Serge E. Hallyn authored
BugLink: http://bugs.launchpad.net/bugs/1584163 Patch summary: When showing a cgroupfs entry in mountinfo, show the path of the mount root dentry relative to the reader's cgroup namespace root. Short explanation (courtesy of mkerrisk): If we create a new cgroup namespace, then we want both /proc/self/cgroup and /proc/self/mountinfo to show cgroup paths that are correctly virtualized with respect to the cgroup mount point. Previous to this patch, /proc/self/cgroup shows the right info, but /proc/self/mountinfo does not. Long version: When a uid 0 task which is in freezer cgroup /a/b, unshares a new cgroup namespace, and then mounts a new instance of the freezer cgroup, the new mount will be rooted at /a/b. The root dentry field of the mountinfo entry will show '/a/b'. cat > /tmp/do1 << EOF mount -t cgroup -o freezer freezer /mnt grep freezer /proc/self/mountinfo EOF unshare -Gm bash /tmp/do1 > 330 160 0:34 / /sys/fs/cgroup/freezer rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,freezer > 355 133 0:34 /a/b /mnt rw,relatime - cgroup freezer rw,freezer The task's freezer cgroup entry in /proc/self/cgroup will simply show '/': grep freezer /proc/self/cgroup 9:freezer:/ If instead the same task simply bind mounts the /a/b cgroup directory, the resulting mountinfo entry will again show /a/b for the dentry root. However in this case the task will find its own cgroup at /mnt/a/b, not at /mnt: mount --bind /sys/fs/cgroup/freezer/a/b /mnt 130 25 0:34 /a/b /mnt rw,nosuid,nodev,noexec,relatime shared:21 - cgroup cgroup rw,freezer In other words, there is no way for the task to know, based on what is in mountinfo, which cgroup directory is its own. Example (by mkerrisk): First, a little script to save some typing and verbiage: echo -e "\t/proc/self/cgroup:\t$(cat /proc/self/cgroup | grep freezer)" cat /proc/self/mountinfo | grep freezer | awk '{print "\tmountinfo:\t\t" $4 "\t" $5}' Create cgroup, place this shell into the cgroup, and look at the state of the /proc files: 2653 2653 # Our shell 14254 # cat(1) /proc/self/cgroup: 10:freezer:/a/b mountinfo: / /sys/fs/cgroup/freezer Create a shell in new cgroup and mount namespaces. The act of creating a new cgroup namespace causes the process's current cgroups directories to become its cgroup root directories. (Here, I'm using my own version of the "unshare" utility, which takes the same options as the util-linux version): Look at the state of the /proc files: /proc/self/cgroup: 10:freezer:/ mountinfo: / /sys/fs/cgroup/freezer The third entry in /proc/self/cgroup (the pathname of the cgroup inside the hierarchy) is correctly virtualized w.r.t. the cgroup namespace, which is rooted at /a/b in the outer namespace. However, the info in /proc/self/mountinfo is not for this cgroup namespace, since we are seeing a duplicate of the mount from the old mount namespace, and the info there does not correspond to the new cgroup namespace. However, trying to create a new mount still doesn't show us the right information in mountinfo: # propagating to other mountns /proc/self/cgroup: 7:freezer:/ mountinfo: /a/b /mnt/freezer The act of creating a new cgroup namespace caused the process's current freezer directory, "/a/b", to become its cgroup freezer root directory. In other words, the pathname directory of the directory within the newly mounted cgroup filesystem should be "/", but mountinfo wrongly shows us "/a/b". The consequence of this is that the process in the cgroup namespace cannot correctly construct the pathname of its cgroup root directory from the information in /proc/PID/mountinfo. With this patch, the dentry root field in mountinfo is shown relative to the reader's cgroup namespace. So the same steps as above: /proc/self/cgroup: 10:freezer:/a/b mountinfo: / /sys/fs/cgroup/freezer /proc/self/cgroup: 10:freezer:/ mountinfo: /../.. /sys/fs/cgroup/freezer /proc/self/cgroup: 10:freezer:/ mountinfo: / /mnt/freezer cgroup.clone_children freezer.parent_freezing freezer.state tasks cgroup.procs freezer.self_freezing notify_on_release 3164 2653 # First shell that placed in this cgroup 3164 # Shell started by 'unshare' 14197 # cat(1) Signed-off-by:
Michael Kerrisk <mtk.manpages@gmail.com> Acked-by:
-
Kamal Mostafa authored
BugLink: http://bugs.launchpad.net/bugs/1584163 This reverts commit d5e333e3. Cc: Serge Hallyn <serge.hallyn@ubuntu.com> Signed-off-by:
-
Kamal Mostafa authored
BugLink: http://bugs.launchpad.net/bugs/1584163 This reverts commit f7d70a0c. Cc: Serge Hallyn <serge.hallyn@ubuntu.com> Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1248289Signed-off-by:
Andy Whitcroft <apw@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
Christopher Arges <chris.j.arges@canonical.com> Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1582328 The current code path is capable of grossly overestimating the number of descriptors needed to transmit a new frame. This specifically occurs if the skb contains a number of 4K pages. The issue is that the logic for determining the descriptors needed is ((S) >> (X)) + 1. When X is 12 it means that we were indicating that we required 2 descriptors for each 4K page when we only needed one. This change corrects this by instead adding (1 << (X)) - 1 to the S value instead of adding 1 after the fact. This way we get an accurate descriptor needed count as we are essentially doing a DIV_ROUNDUP(). Reported-by:
Ivan Suzdal <isuzdal@mirantis.com> Signed-off-by:
Alexander Duyck <aduyck@mirantis.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> (cherry picked from commit 847a1d67) Signed-off-by:
-
Alexander Duyck authored
BugLink: http://bugs.launchpad.net/bugs/1582328 The 82544 has code that adds one additional descriptor per data buffer. However we weren't taking that into account when determining the descriptors needed for the next transmit at the end of the xmit_frame path. This change takes that into account by doubling the number of descriptors needed for the 82544 so that we can avoid a potential issue where we could hang the Tx ring by loading frames with xmit_more enabled and then stopping the ring without writing the tail. In addition it adds a few more descriptors to account for some additional workarounds that have been added over time. Signed-off-by:
-
Seth Forshee authored
BugLink: http://bugs.launchpad.net/bugs/1582378 s_user_ns for an mqueue super block needs to be set to the user ns which owns the ipc ns, otherwise it will not be mountable in that user ns. This is not currently the case for an unshare(CLONE_NEWIPC|CLONE_NEWUSER) as the internal mount of the super block for the new ipc ns is done before the new user namespace is installed. Since s_user_ns = ipc_ns->user_ns is the only arrangement that makes sense for mqueue, the initial kernel mount can simply pass that namespace to sget_userns(). In addition we should do the same for userspace mounts to preserve the behavior that allows a user privileged towards ipc_ns->user_ns to mount mqueue from a different user ns. The existing checks already ensure that the user has sufficient privileges for the mount. Signed-off-by:
Seth Forshee <seth.forshee@canonical.com> Acked-by:
-
Flora Cui authored
BugLink: http://bugs.launchpad.net/bugs/1580526 commit 56fc3502 upstream. Fixes the following scenario: 1. Page table bo allocated in vram and linked to man->lru. tbo->list_kref.refcount=2 2. Page table bo is swapped out and removed from man->lru. tbo->list_kref.refcount=1 3. Command submission from userspace. Page table bo is moved to vram. ttm_bo_move_to_lru_tail() link it to man->lru and don't increase the kref count. Reviewed-by:
Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by:
Flora Cui <Flora.Cui@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Alberto Milone <alberto.milone@canonical.com> Acked-by:
-
Rex Zhu authored
BugLink: http://bugs.launchpad.net/bugs/1580526 commit f9e9c08e upstream. Signed-off-by:
Rex Zhu <Rex.Zhu@amd.com> Reviewed-by:
Junwei Zhang <Jerry.Zhang@amd.com> Signed-off-by:
-
Eric Huang authored
BugLink: http://bugs.launchpad.net/bugs/1580526 commit 60123300 upstream. Set the UVD and VCE DPM flags otherwise UVD and VCE DPM won't get enabled. Reviewed-by:
Eric Huang <JinHuiEric.Huang@amd.com> Signed-off-by:
-
Dave Airlie authored
BugLink: http://bugs.launchpad.net/bugs/1580526 commit b36f7d26 upstream. The function this used changed in 092c96a8 drm/radeon: fix dp link rate selection (v2) However for MST we should just always train to the max link/rate. Though we probably need to limit this for future hw, in theory radeon won't support it. This fixes my 30" monitor with MST enabled. Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Alex Deucher authored
BugLink: http://bugs.launchpad.net/bugs/1580526 commit e5f243bd upstream. Move all the logic to radeon_fb.c and add checks to functions called frome elsewhere. bug: https://bugzilla.kernel.org/show_bug.cgi?id=112781Signed-off-by:
-
Andy Whitcroft authored
BugLink: http://bugs.launchpad.net/bugs/1121699Signed-off-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1580355Signed-off-by:
-
Nikolay Aleksandrov authored
BugLink: http://bugs.launchpad.net/bugs/1581132 We should validate the port setting that we got from the user and check if it's what we've set it to (PORT_OTHER), also add explanation that ignoring advertising is good as long as we don't have autonegotiation. Signed-off-by:
Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Acked-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
Andy Gospodarek <gospo@cumulusnetworks.com> Acked-by:
Brad Figg <brad.figg@canonical.com> Signed-off-by:
-
