- 06 May, 2015 40 commits
-
-
Eric W. Biederman authored
commit ce07d891 upstream. Modify umount(MNT_DETACH) to keep mounts in the hash table that are locked to their parent mounts, when the parent is lazily unmounted. In mntput_no_expire detach the children from the hash table, depending on mnt_pin_kill in cleanup_mnt to decrement the mnt_count of the children. In __detach_mounts if there are any mounts that have been unmounted but still are on the list of mounts of a mountpoint, remove their children from the mount hash table and those children to the unmounted list so they won't linger potentially indefinitely waiting for their final mntput, now that the mounts serve no purpose. Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Eric W. Biederman authored
commit 6a46c573 upstream. For future use factor out a function umount_mnt from umount_tree. This function unhashes a mount and remembers where the mount was mounted so that eventually when the code makes it to a sleeping context the mountpoint can be dput. Signed-off-by:
-
Eric W. Biederman authored
commit 7bdb11de upstream. Create a function unhash_mnt that contains the common code between detach_mnt and umount_tree, and use unhash_mnt in place of the common code. This add a unncessary list_del_init(mnt->mnt_child) into umount_tree but given that mnt_child is already empty this extra line is a noop. Signed-off-by:
-
Eric W. Biederman authored
commit 0c56fe31 upstream. If the first mount in shared subtree is locked don't unmount the shared subtree. This is ensured by walking through the mounts parents before children and marking a mount as unmountable if it is not locked or it is locked but it's parent is marked. This allows recursive mount detach to propagate through a set of mounts when unmounting them would not reveal what is under any locked mount. Signed-off-by:
-
Eric W. Biederman authored
commit 5d88457e upstream. A prerequisite of calling umount_tree is that the point where the tree is mounted at is valid to unmount. If we are propagating the effect of the unmount clear MNT_LOCKED in every instance where the same filesystem is mounted on the same mountpoint in the mount tree, as we know (by virtue of the fact that umount_tree was called) that it is safe to reveal what is at that mountpoint. Signed-off-by:
-
Eric W. Biederman authored
commit 411a938b upstream. - Modify __lookup_mnt_hash_last to ignore mounts that have MNT_UMOUNTED set. - Don't remove mounts from the mount hash table in propogate_umount - Don't remove mounts from the mount hash table in umount_tree before the entire list of mounts to be umounted is selected. - Remove mounts from the mount hash table as the last thing that happens in the case where a mount has a parent in umount_tree. Mounts without parents are not hashed (by definition). This paves the way for delaying removal from the mount hash table even farther and fixing the MNT_LOCKED vs MNT_DETACH issue. Signed-off-by:
-
Eric W. Biederman authored
commit 590ce4bc upstream. In some instances it is necessary to know if the the unmounting process has begun on a mount. Add MNT_UMOUNT to make that reliably testable. This fix gets used in fixing locked mounts in MNT_DETACH Signed-off-by:
-
Eric W. Biederman authored
commit c003b26f upstream. umount_tree builds a list of mounts that need to be unmounted. Utilize mnt_list for this purpose instead of mnt_hash. This begins to allow keeping a mount on the mnt_hash after it is unmounted, which is necessary for a properly functioning MNT_LOCKED implementation. The fact that mnt_list is an ordinary list makding available list_move is nice bonus. Signed-off-by:
-
Eric W. Biederman authored
commit 8318e667 upstream. Invoking mount propagation from __detach_mounts is inefficient and wrong. It is inefficient because __detach_mounts already walks the list of mounts that where something needs to be done, and mount propagation walks some subset of those mounts again. It is actively wrong because if the dentry that is passed to __detach_mounts is not part of the path to a mount that mount should not be affected. change_mnt_propagation(p,MS_PRIVATE) modifies the mount propagation tree of a master mount so it's slaves are connected to another master if possible. Which means even removing a mount from the middle of a mount tree with __detach_mounts will not deprive any mount propagated mount events. Signed-off-by:
-
Eric W. Biederman authored
commit e819f152 upstream. - Remove the unneeded declaration from pnode.h - Mark umount_tree static as it has no callers outside of namespace.c - Define an enumeration of umount_tree's flags. - Pass umount_tree's flags in by name This removes the magic numbers 0, 1 and 2 making the code a little clearer and makes it possible for there to be lazy unmounts that don't propagate. Which is what __detach_mounts actually wants for example. Signed-off-by:
-
Lukas Czerner authored
commit e12fb972 upstream. Previously commit 14ece102 added a support for for syncing parent directory of newly created inodes to make sure that the inode is not lost after a power failure in no-journal mode. However this does not work in majority of cases, namely: - if the directory has inline data - if the directory is already indexed - if the directory already has at least one block and: - the new entry fits into it - or we've successfully converted it to indexed So in those cases we might lose the inode entirely even after fsync in the no-journal mode. This also includes ext2 default mode obviously. I've noticed this while running xfstest generic/321 and even though the test should fail (we need to run fsck after a crash in no-journal mode) I could not find a newly created entries even when if it was fsynced before. Fix this by adjusting the ext4_add_entry() successful exit paths to set the inode EXT4_STATE_NEWENTRY so that fsync has the chance to fsync the parent directory as well. Signed-off-by:
Lukas Czerner <lczerner@redhat.com> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Reviewed-by:
Jan Kara <jack@suse.cz> Cc: Frank Mayhar <fmayhar@google.com> Signed-off-by:
-
Marek Vasut authored
commit 9374e7d2 upstream. Add new ID for ASUS N10 WiFi dongle. Signed-off-by:
Marek Vasut <marex@denx.de> Tested-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Larry Finger authored
commit 2f92b314 upstream. USB ID 2001:330d is used for a D-Link DWA-131. Signed-off-by:
-
Christophe Ricard authored
commit d4a41d10 upstream. i2c_master_send may return many negative values different than -EREMOTEIO. In case an i2c transaction is NACK'ed, on raspberry pi B+ kernel 3.18, -EIO is generated instead. Signed-off-by:
Christophe Ricard <christophe-h.ricard@st.com> Signed-off-by:
Samuel Ortiz <sameo@linux.intel.com> Signed-off-by:
-
Nicolas Ferre authored
commit 36191897 upstream. We currently need two checks of the peripheral version in MACB_MID register. One of them got out of sync after modification by 8a013a9c (net: macb: Include multi queue support for xilinx ZynqMP ethernet version). Fix this in macb_configure_caps() so that xilinx ZynqMP will be considered as a GEM flavor. Fixes: 8a013a9c ("net: macb: Include multi queue support for xilinx ZynqMP ethernet version") Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Cc: Michal Simek <michal.simek@xilinx.com> Cc: Punnaiah Choudary Kalluri <punnaia@xilinx.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Len Brown authored
commit d7ef7671 upstream. On some Silvermont-Core/Baytrail-SOC systems, C1E latency is higher than original specifications. Although C1E is still enumerated in CPUID.MWAIT.EDX, we delete the state from intel_idle to avoid latency impact. Under some conditions, the latency of the C6N-BYT and C6S-BYT states may exceed the specified values of 40 and 140 usec, respectively. Increase those values to 300 and 500 usec; to assure that the hardware does not violate constraints that may be set by the Linux PM_QOS sub-system. Also increase the C7-BYT target residency to 4.0 ms from 1.5 ms. Signed-off-by:
Len Brown <len.brown@intel.com> Cc: Kumar P Mahesh <mahesh.kumar.p@intel.com> Cc: Alan Cox <alan@linux.intel.com> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
-
Oleg Nesterov authored
commit b72c1869 upstream. ptrace_resume() is called when the tracee is still __TASK_TRACED. We set tracee->exit_code and then wake_up_state() changes tracee->state. If the tracer's sub-thread does wait() in between, task_stopped_code(ptrace => T) wrongly looks like another report from tracee. This confuses debugger, and since wait_task_stopped() clears ->exit_code the tracee can miss a signal. Test-case: #include <stdio.h> #include <unistd.h> #include <sys/wait.h> #include <sys/ptrace.h> #include <pthread.h> #include <assert.h> int pid; void *waiter(void *arg) { int stat; for (;;) { assert(pid == wait(&stat)); assert(WIFSTOPPED(stat)); if (WSTOPSIG(stat) == SIGHUP) continue; assert(WSTOPSIG(stat) == SIGCONT); printf("ERR! extra/wrong report:%x\n", stat); } } int main(void) { pthread_t thread; pid = fork(); if (!pid) { assert(ptrace(PTRACE_TRACEME, 0,0,0) == 0); for (;;) kill(getpid(), SIGHUP); } assert(pthread_create(&thread, NULL, waiter, NULL) == 0); for (;;) ptrace(PTRACE_CONT, pid, 0, SIGCONT); return 0; } Note for stable: the bug is very old, but without 9899d11f "ptrace: ensure arch_ptrace/ptrace_request can never race with SIGKILL" the fix should use lock_task_sighand(child). Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Reported-by:
Pavel Labath <labath@google.com> Tested-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Michael Davidson authored
commit a87938b2 upstream. With CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE enabled, and a normal top-down address allocation strategy, load_elf_binary() will attempt to map a PIE binary into an address range immediately below mm->mmap_base. Unfortunately, load_elf_ binary() does not take account of the need to allocate sufficient space for the entire binary which means that, while the first PT_LOAD segment is mapped below mm->mmap_base, the subsequent PT_LOAD segment(s) end up being mapped above mm->mmap_base into the are that is supposed to be the "gap" between the stack and the binary. Since the size of the "gap" on x86_64 is only guaranteed to be 128MB this means that binaries with large data segments > 128MB can end up mapping part of their data segment over their stack resulting in corruption of the stack (and the data segment once the binary starts to run). Any PIE binary with a data segment > 128MB is vulnerable to this although address randomization means that the actual gap between the stack and the end of the binary is normally greater than 128MB. The larger the data segment of the binary the higher the probability of failure. Fix this by calculating the total size of the binary in the same way as load_elf_interp(). Signed-off-by:
Michael Davidson <md@google.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Kees Cook <keescook@chromium.org> Signed-off-by:
-
Johan Hovold authored
commit a77c50b4 upstream. Since commit 6e3f62f0 ("mfd: core: Fix platform-device id generation") we honour PLATFORM_DEVID_AUTO and PLATFORM_DEVID_NONE when registering mfd-devices. Unfortunately, some mfd-drivers rely on the old behaviour of generating platform-device ids by adding the cell id also to the special value of PLATFORM_DEVID_NONE. The resulting platform ids are not only used to generate device-unique names, but are also used instead of the cell id to identify cells when probing subdevices. These drivers should be updated to use PLATFORM_DEVID_AUTO, which would also allow more than one device to be registered without resorting to hacks (see for example wm831x), but lets fix the regression first by partially reverting the above mentioned commit with respect to PLATFORM_DEVID_NONE. Fixes: 6e3f62f0 ("mfd: core: Fix platform-device id generation") Reported-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by:
Johan Hovold <johan@kernel.org> Acked-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Hans de Goede authored
commit 6bcca19f upstream. When the left touchpad button gets pressed, and then the trackpoint is moved, and then the button is released, the following happens: 1) touchpad packet is received, touchpad evdev node reports BTN_LEFT 1 2) pointing stick packet is received, the hw will report a BTN_LEFT 1 in this packet because when the trackstick is active it communicates the combined touchpad + pointing stick buttons in the trackstick packet, since alps_report_bare_ps2_packet passes NULL (*) for the dev2 parameter to alps_report_buttons the combining is not detected and the pointing stick evdev node will also report BTN_LEFT 1 3) on release of the button a pointing stick packet with BTN_LEFT 0 is received and the pointing stick evdev node will report BTN_LEFT 0 Note how because of the passing as NULL for dev2 the touchpad evdev node will never send BTN_LEFT 0 in this scenario leading to a stuck mouse button. This is a regression in 4.0 introduced by commit 04aae283 ("Input: ALPS - do not mix trackstick and external PS/2 mouse data") This commit fixes this by passing in the touchpad evdev as dev2 parameter when calling alps_report_buttons for the pointingstick on alps v2 devices, so that alps_report_buttons correctly detect that we're already reporting the button as pressed via the touchpad evdev node, and will also send the release event there. Reported-by:
Hans de Bruin <jmdebruin@xmsnet.nl> Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Pali Rohár <pali.rohar@gmail.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Ulrik De Bie authored
commit bd884149 upstream. On ASUS TP500LN and X750JN, the touchpad absolute mode is reset each time set_rate is done. In order to fix this, we will verify the firmware version, and if it matches the one in those laptops, the set_rate function is overloaded with a function elantech_set_rate_restore_reg_07 that performs the set_rate with the original function, followed by a restore of reg_07 (the register that sets the absolute mode on elantech v4 hardware). Also the ASUS TP500LN and X750JN firmware version, capabilities, and button constellation is added to elantech.c Reported-and-tested-by:
George Moutsopoulos <gmoutso@yahoo.co.uk> Signed-off-by:
Ulrik De Bie <ulrik.debie-os@e2big.org> Signed-off-by:
-
Hui Wang authored
commit e8191a8e upstream. We have two machines with alc256 codec in the pin quirk table, so moving the common pins to ALC256_STANDARD_PINS. BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1447909Signed-off-by:
Hui Wang <hui.wang@canonical.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Kailang Yang authored
commit d32b6666 upstream. Switch default pcbeep path to Line in path. Signed-off-by:
Kailang Yang <kailang@realtek.com> Tested-by:
-
David Henningsson authored
commit 7d1b6e29 upstream. The ALC256 does not have a mixer nid at 0x0b, and there's no loopback path (the output pins are directly connected to the DACs). This commit fixes an "num_steps = 0 for NID=0xb (ctl = Beep Playback Volume)" error (and as a result, problems with amixer/alsamixer). If there's pcbeep functionality, it certainly isn't controlled by setting an amp on 0x0b, so disable beep functionality (at least for now). BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1446517Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
-
Jo-Philipp Wich authored
commit f2aa1110 upstream. The Lenovo Thinkpad T450 requires the ALC292_FIXUP_TPT440_DOCK as well in order to get working sound output on the docking stations headphone jack. Patch tested on a Thinkpad T450 (20BVCTO1WW) using kernel 4.0-rc7 in conjunction with a ThinkPad Ultradock. Signed-off-by:
Jo-Philipp Wich <jow@openwrt.org> Signed-off-by:
-
Michael Gernoth authored
commit 91bf0c2d upstream. The functions snd_emu10k1_proc_spdif_read and snd_emu1010_fpga_read acquire the emu_lock before accessing the FPGA. The function used to access the FPGA (snd_emu1010_fpga_read) also tries to take the emu_lock which causes a deadlock. Remove the outer locking in the proc-functions (guarding only the already safe fpga read) to prevent this deadlock. [removed superfluous flags variables too -- tiwai] Signed-off-by:
Michael Gernoth <michael@gernoth.net> Signed-off-by:
-
Adam Honse authored
commit eef0342c upstream. Adds Microsoft LifeCam Cinema USB ID to the snd_usb_get_sample_rate_quirk list as the Lifecam Cinema does not appear to support getting the sample rate. Fixes the issue where the LifeCam Cinema would wait for USB timeout and log the message "cannot get freq at ep 0x82" when accessed. Addresses bug report https://bugzilla.kernel.org/show_bug.cgi?id=95961. Signed-off-by:
Adam Honse <calcprogrammer1@gmail.com> Signed-off-by:
-
Yves-Alexis Perez authored
commit c0278669 upstream. This model uses the same dock port as the previous generation. Signed-off-by:
Yves-Alexis Perez <corsac@debian.org> Signed-off-by:
-
Boris Brezillon authored
commit 45912431 upstream. The at91sam9n12 and at91sam9x5 usb clocks do not propagate rate modification requests to their parents. This causes a bug when the PLLB is left uninitialized by the bootloader (PLL multiplier set to 0, or in other words, PLL rate = 0 Hz). Implement the determinate_rate method and propagate the change rate request to the parent clk. Signed-off-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Reported-by:
Bo Shen <voice.shen@atmel.com> Tested-by:
Michael Turquette <mturquette@linaro.org> Signed-off-by:
-
Felipe Balbi authored
commit bbc78c07 upstream. Make sure we're using the new macro, so our resume signaling will always pass certification. Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
Felipe Balbi authored
commit 59c9904c upstream. Make sure we're using the new macro, so our resume signaling will always pass certification. Signed-off-by:
-
Felipe Balbi authored
commit 74bd7b69 upstream. Make sure we're using the new macro, so our resume signaling will always pass certification. Signed-off-by:
-
Felipe Balbi authored
commit 08debfb1 upstream. Make sure we're using the new macro, so our resume signaling will always pass certification. Signed-off-by:
-
Felipe Balbi authored
commit ea16328f upstream. Make sure we're using the new macro, so our resume signaling will always pass certification. Signed-off-by:
-
Felipe Balbi authored
commit b9e45188 upstream. Make sure we're using the new macro, so our resume signaling will always pass certification. Acked-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Felipe Balbi authored
commit 8c0ae657 upstream. Make sure we're using the new macro, so our resume signaling will always pass certification. Signed-off-by:
-
Felipe Balbi authored
commit 7a606ac2 upstream. While this driver was already using a 50ms resume timeout, let's make sure everybody uses the same macro so it's easy to fix later should anything go wrong. It also gives a more "stable" expectation to Linux users. Signed-off-by:
-
Felipe Balbi authored
commit 7e136bb7 upstream. Make sure we're using the new macro, so our resume signaling will always pass certification. Signed-off-by:
-
Felipe Balbi authored
commit b8fb6f79 upstream. Make sure we're using the new macro, so our resume signaling will always pass certification. Signed-off-by:
-
Felipe Balbi authored
commit 595227db upstream. Make sure we're using the new macro, so our resume signaling will always pass certification. Signed-off-by:
-
