- 10 Jun, 2016 37 commits
-
-
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:
Wen-chien Jesse Sung <jesse.sung@canonical.com> Reviewed-By:
AceLan Kao <acelan.kao@canonical.com> Acked-by:
Tim Gardner <tim.gardner@canonical.com> Signed-off-by:
Kamal Mostafa <kamal@canonical.com>
-
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:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> 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:
David S. Miller <davem@davemloft.net> (cherry picked from commit 0cf3ace9) Signed-off-by:
Andy Gospodarek <gospo@cumulusnetworks.com> Acked-by:
Brad Figg <brad.figg@canonical.com> Signed-off-by:
-
Nikolay Aleksandrov authored
BugLink: http://bugs.launchpad.net/bugs/1581132 This patch allows the user to set and retrieve speed and duplex of the virtio_net device via ethtool. Having this functionality is very helpful for simulating different environments and also enables the virtio_net device to participate in operations where proper speed and duplex are required (e.g. currently bonding lacp mode requires full duplex). Custom speed and duplex are not allowed, the user-supplied settings are validated before applying. Example: $ ethtool eth1 Settings for eth1: ... Speed: Unknown! Duplex: Unknown! (255) $ ethtool -s eth1 speed 1000 duplex full $ ethtool eth1 Settings for eth1: ... Speed: 1000Mb/s Duplex: Full Based on a patch by Roopa Prabhu. Signed-off-by:
-
Nikolay Aleksandrov authored
BugLink: http://bugs.launchpad.net/bugs/1581132 Devices these days can have any speed and as was recently pointed out any speed from 0 to INT_MAX is valid so adjust speed validation to accept such values. Signed-off-by:
-
Nikolay Aleksandrov authored
BugLink: http://bugs.launchpad.net/bugs/1581132 Add functions which check if the speed/duplex are defined. Signed-off-by:
-
Sukadev Bhattiprolu authored
BugLink: http://bugs.launchpad.net/bugs/1578211 Power8 supports a large number of events in each susbystem so when a user runs: perf stat -e branch-instructions sleep 1 perf stat -e L1-dcache-loads sleep 1 it is not clear as to which PMU events were monitored. Export the generic hardware and cache perf events for Power8 to sysfs, so users can precisely determine the PMU event monitored by the generic event. Eg: cat /sys/bus/event_source/devices/cpu/events/branch-instructions event=0x10068 $ cat /sys/bus/event_source/devices/cpu/events/L1-dcache-loads event=0x100ee Signed-off-by:
Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> (cherry picked from commit e0728b50) Signed-off-by:
-
Sukadev Bhattiprolu authored
BugLink: http://bugs.launchpad.net/bugs/1578211 We used the PME_ prefix earlier to avoid some macro/variable name collisions. We have since changed the way we define/use the event macros so we no longer need the prefix. By dropping the prefix, we keep the the event macros consistent with their official names. Reported-by:
Michael Ellerman <ellerman@au1.ibm.com> Signed-off-by:
-
Saeed Mahameed authored
BugLink: http://bugs.launchpad.net/bugs/1528466 Minimum MTU that can be set in Connectx4 device is 68. This fixes the case where a user wants to set invalid MTU, the driver will fail to satisfy this request and the interface will stay down. It is better to report an error and continue working with old mtu. Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
-
Saeed Mahameed authored
BugLink: http://bugs.launchpad.net/bugs/1528466 For set/query MTU port firmware commands the MTU field is 16 bits, here I changed all the "int mtu" parameters of the functions wrapping those firmware commands to be u16. Signed-off-by:
-
Achiad Shochat authored
BugLink: http://bugs.launchpad.net/bugs/1528466 All the device physical port access functions are implemented in the port.c file. We just extract the exposure of these functions from driver.h into a dedicated header file called port.h. Signed-off-by:
Achiad Shochat <achiad@mellanox.com> Signed-off-by:
-
Kamal Mostafa authored
Ignore: yes Signed-off-by:
-
- 08 Jun, 2016 3 commits
-
-
Kamal Mostafa authored
Signed-off-by: -
Jann Horn authored
BugLink: http://bugs.launchpad.net/bugs/1588871 Until now, hitting this BUG_ON caused a recursive oops (because oops handling involves do_exit(), which calls into the scheduler, which in turn raises an oops), which caused stuff below the stack to be overwritten until a panic happened (e.g. via an oops in interrupt context, caused by the overwritten CPU index in the thread_info). Just panic directly. Signed-off-by:
Jann Horn <jannh@google.com> CVE-2016-1583 Acked-by:
Tyler Hicks <tyhicks@canonical.com> Acked-by:
Luis Henriques <luis.henriques@canonical.com> Signed-off-by:
-
Jann Horn authored
BugLink: http://bugs.launchpad.net/bugs/1588871 This prevents users from triggering an exploitable stack overflow through a recursive invocation of pagefault handling on systems that allow unprivileged users to mount ecryptfs. More precisely: When a file in ecryptfs is mmap()ed, ecryptfs only uses the VFS read and write methods of the lower filesystem (using kernel_read() and kernel_write()) to interact with the lower file. This means that it is possible to mmap() the decrypted view of a lower file that normally couldn't be mmap()ed. One such file is /proc/$pid/environ. If an encrypted ecryptfs file is placed in the environment area of a process with PID $pid and /proc/$pid is mounted to /tmp/foo, /tmp/foo/environ can then be opened and mmap()ed. A pagefault in the memory area to which /tmp/foo/environ is mapped will cause a kernel_read() on /proc/$pid/environ, which in turn will cause a pagefault in the context of the process with PID $pid. By using a chain of processes in which each process has the decrypted view of the next process' environment mapped into its environment area, where the environment of the last process in the chain is an "ecryptfs matroska" (the result of encrypting some data using ecryptfs, then encrypting the result of that and so on), and then triggering a pagefault in the environment of the first process in the chain, it is possible to cause a recursive pagefault that ends up overflowing the stack. Fix it by disallowing opening anything without an mmap handler through ecryptfs. CVE-2016-1583 Signed-off-by:
-
