22 Jul, 2015
23 commits
-
commit b064a8fa77dfead647564c46ac8fc5b13bd1ab73 upstream.
Commit 73f7d1ca3263 "ACPI / init: Run acpi_early_init() before
timekeeping_init()" moved the ACPI subsystem initialization,
including the ACPI mode enabling, to an earlier point in the
initialization sequence, to allow the timekeeping subsystem
use ACPI early. Unfortunately, that resulted in boot regressions
on some systems and the early ACPI initialization was moved toward
its original position in the kernel initialization code by commit
c4e1acbb35e4 "ACPI / init: Invoke early ACPI initialization later".However, that turns out to be insufficient, as boot is still broken
on the Tyan S8812 mainboard.To fix that issue, split the ACPI early initialization code into
two pieces so the majority of it still located in acpi_early_init()
and the part switching over the platform into the ACPI mode goes into
a new function, acpi_subsystem_init(), executed at the original early
ACPI initialization spot.That fixes the Tyan S8812 boot problem, but still allows ACPI
tables to be loaded earlier which is useful to the EFI code in
efi_enter_virtual_mode().Link: https://bugzilla.kernel.org/show_bug.cgi?id=97141
Fixes: 73f7d1ca3263 "ACPI / init: Run acpi_early_init() before timekeeping_init()"
Reported-and-tested-by: Marius Tolzmann
Signed-off-by: Rafael J. Wysocki
Acked-by: Toshi Kani
Reviewed-by: Hanjun Guo
Reviewed-by: Lee, Chun-Yi
Signed-off-by: Greg Kroah-Hartman -
commit 4275554dccdf0afac07b2b638ba7456095629558 upstream.
Dell E7450 [0128:062e] needs the same quirk as other E7xx models.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100571
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 4df3fd1700abbb53bd874143dfd1f9ac9e7cbf4b upstream.
Fujitsu Lifebook E780 sets the sequence number 0x0f to only only of
the two headphones, thus the driver tries to assign another as the
line-out, and this results in the inconsistent mapping between the
created jack ctl and the actual I/O. Due to this, PulseAudio doesn't
handle it properly and gets the silent output.The fix is to ignore the non-HP sequencer checks.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=99681
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 7819717b11346b8a5420b223b46600e394049c66 upstream.
Acer Aspire V5 with ALC282 codec needs the similar quirk like Dell
laptops to support the headset mic. The headset mic pin is 0x19 and
it's not exposed by BIOS, thus we need to fix the pincfg as well.Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=96201
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 831bfdf9520e389357cfeee42a6174a73ce7bdb7 upstream.
Those FIXUPs were applied to the machines through pin quirks, but
recently the PCI_QUIRK makes them can't apply to the machines.Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=99851
Signed-off-by: Hui Wang
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 735c75cf4d434862e38c01dcfb2ce8d2fcb9035f upstream.
The widget power-save that was enabled in 4.1 kernel seems resulting
in the silent output on VIA codecs by some reason. Some widgets get
wrong power states.As a quick fix, turn this flag off while keeping power_down_unused
flag. This will bring back to the state of 4.0.x.Fixes: 688b12cc3ca8 ('ALSA: hda - Use the new power control for VIA codecs')
Reported-and-tested-by: Harald Dunkel
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 650474fb737c3e0ea0f6ab8e43c2cd161080ce5c upstream.
Fixes audio problems on newer asics.
Noticed by: Kelly Anderson
Signed-off-by: Alex Deucher
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit ec56af67a10a0d82b79027878a81fce08d002d50 upstream.
Thinkpad X250, when attached to a dock, has two headphone outs but
no line out. Make sure we don't try to turn this into one headphone
and one line out (since that disables the headphone amp on the dock).Alsa-info at http://www.alsa-project.org/db/?f=36f8764e1d782397928feec715d0ef90dfddd4c1
Signed-off-by: David Henningsson
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 60b93030b44a8c2cd015cebe5624fd7552ec67ec upstream.
The pcm_class sysfs of each PCM substream gives only "none" since the
recent code change to embed the struct device. Fix the code to point
directly to the embedded device object properly.Fixes: ef46c7af93f9 ('ALSA: pcm: Embed struct device')
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 2fb22a8042fe96b4220843f79241c116d90922c4 upstream.
Disable write buffering on the Toshiba ToPIC95 if it is enabled by
somebody (it is not supposed to be a power-on default according to
the datasheet). On the ToPIC95, practically no 32-bit Cardbus card
will work under heavy load without locking up the whole system if
this is left enabled. I tried about a dozen. It does not affect
16-bit cards. This is similar to the O2 bugs in early controller
revisions it seems.Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55961
Signed-off-by: Ryan C. Underwood
Signed-off-by: Dominik Brodowski
Signed-off-by: Greg Kroah-Hartman -
commit 45c44b5ff9caa743ed9c2bfd44307c536c9caf1e upstream.
Increase the default init stage change timeout from 15 seconds to 30 seconds.
This resolves issues we have seen with some adapters not transitioning
to the first init stage within 15 seconds, which results in adapter
initialization failures.Signed-off-by: Brian King
Signed-off-by: James Bottomley
Signed-off-by: Greg Kroah-Hartman -
commit 6e91f8cb138625be96070b778d9ba71ce520ea7e upstream.
If, at the time __rcu_process_callbacks() is invoked, there are callbacks
in Tiny RCU's callback list, but none of them are ready to be invoked,
the current list-management code will knit the non-ready callbacks out
of the list. This can result in hangs and possibly worse. This commit
therefore inserts a check for there being no callbacks that can be
invoked immediately.This bug is unlikely to occur -- you have to get a new callback between
the time rcu_sched_qs() or rcu_bh_qs() was called, but before we get to
__rcu_process_callbacks(). It was detected by the addition of RCU-bh
testing to rcutorture, which in turn was instigated by Iftekhar Ahmed's
mutation testing. Although this bug was made much more likely by
915e8a4fe45e (rcu: Remove fastpath from __rcu_process_callbacks()), this
did not cause the bug, but rather made it much more probable. That
said, it takes more than 40 hours of rcutorture testing, on average,
for this bug to appear, so this fix cannot be considered an emergency.Signed-off-by: Paul E. McKenney
Reviewed-by: Josh Triplett
Signed-off-by: Greg Kroah-Hartman -
commit 501ef0f95a57e7c32138733c468394a52244c85b upstream.
If an interrupt controller doesn't support wake-up configuration,
irq_set_irq_wake() returns an error code. Then any subsequent call
trying to deconfigure wake-up will cause an imbalance, and a warning
will be printed:WARNING: CPU: 1 PID: 1341 at kernel/irq/manage.c:540 irq_set_irq_wake+0x9c/0xf8()
Unbalanced IRQ 26 wake disableTo fix this, refrain from any further parent interrupt controller
(de)configuration if irq_set_irq_wake() failed.Alternative fixes would be:
- calling "gic_set_irqchip_flags(IRQCHIP_SKIP_SET_WAKE)" from the
platform code,
- setting "gic_chip.flags = IRQCHIP_SKIP_SET_WAKE" in the GIC driver
code,
but these were withheld as the GIC hardware doesn't really support
wake-up interrupts.Fixes: ab82fa7da4dce5c7 ("gpio: rcar: Prevent module clock disable when wake-up is enabled")
Signed-off-by: Geert Uytterhoeven
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman -
commit 61e749d7e1627d375156553ea0ae83c4f6bb5a9b upstream.
The CrystalCove GPIO irqchip doesn't have irq_set_wake callback defined
so we should set IRQCHIP_SKIP_SET_WAKE for it or it would cause an irq
desc's wake_depth unbalanced warning during system resume phase from the
gpio_keys driver, which is the driver for the power button of the ASUS
T100 laptop.Signed-off-by: Aaron Lu
Signed-off-by: Linus Walleij
Signed-off-by: Greg Kroah-Hartman -
commit 8c6cf9cc829fcd0b179b59f7fe288941d0e31108 upstream.
Ignore an existing mount if the locked readonly, nodev or atime
attributes are less permissive than the desired attributes
of the new mount.On success ensure the new mount locks all of the same readonly, nodev and
atime attributes as the old mount.The nosuid and noexec attributes are not checked here as this change
is destined for stable and enforcing those attributes causes a
regression in lxc and libvirt-lxc where those applications will not
start and there are no known executables on sysfs or proc and no known
way to create exectuables without code modificationsFixes: e51db73532955 ("userns: Better restrictions on when proc and sysfs can be mounted")
Signed-off-by: "Eric W. Biederman"
Signed-off-by: Greg Kroah-Hartman -
commit 1b852bceb0d111e510d1a15826ecc4a19358d512 upstream.
Fresh mounts of proc and sysfs are a very special case that works very
much like a bind mount. Unfortunately the current structure can not
preserve the MNT_LOCK... mount flags. Therefore refactor the logic
into a form that can be modified to preserve those lock bits.Add a new filesystem flag FS_USERNS_VISIBLE that requires some mount
of the filesystem be fully visible in the current mount namespace,
before the filesystem may be mounted.Move the logic for calling fs_fully_visible from proc and sysfs into
fs/namespace.c where it has greater access to mount namespace state.Signed-off-by: "Eric W. Biederman"
Signed-off-by: Greg Kroah-Hartman -
commit 7236c85e1be51a9e25ba0f6e087a66ca89605a49 upstream.
fs_fully_visible attempts to make fresh mounts of proc and sysfs give
the mounter no more access to proc and sysfs than if they could have
by creating a bind mount. One aspect of proc and sysfs that makes
this particularly tricky is that there are other filesystems that
typically mount on top of proc and sysfs. As those filesystems are
mounted on empty directories in practice it is safe to ignore them.
However testing to ensure filesystems are mounted on empty directories
has not been something the in kernel data structures have supported so
the current test for an empty directory which checks to see
if nlink i_mode) && i_nlink
Signed-off-by: Greg Kroah-Hartman -
commit f9bb48825a6b5d02f4cabcc78967c75db903dcdc upstream.
This allows for better documentation in the code and
it allows for a simpler and fully correct version of
fs_fully_visible to be written.The mount points converted and their filesystems are:
/sys/hypervisor/s390/ s390_hypfs
/sys/kernel/config/ configfs
/sys/kernel/debug/ debugfs
/sys/firmware/efi/efivars/ efivarfs
/sys/fs/fuse/connections/ fusectl
/sys/fs/pstore/ pstore
/sys/kernel/tracing/ tracefs
/sys/fs/cgroup/ cgroup
/sys/kernel/security/ securityfs
/sys/fs/selinux/ selinuxfs
/sys/fs/smackfs/ smackfsAcked-by: Greg Kroah-Hartman
Signed-off-by: "Eric W. Biederman"
Signed-off-by: Greg Kroah-Hartman -
commit 87d2846fcf88113fae2341da1ca9a71f0d916f2c upstream.
Add two functions sysfs_create_mount_point and
sysfs_remove_mount_point that hang a permanently empty directory off
of a kobject or remove a permanently emptpy directory hanging from a
kobject. Export these new functions so modular filesystems can use
them.Acked-by: Greg Kroah-Hartman
Signed-off-by: "Eric W. Biederman"
Signed-off-by: Greg Kroah-Hartman -
commit ea015218f2f7ace2dad9cedd21ed95bdba2886d7 upstream.
Add a new function kernfs_create_empty_dir that can be used to create
directory that can not be modified.Update the code to use make_empty_dir_inode when reporting a
permanently empty directory to the vfs.Update the code to not allow adding to permanently empty directories.
Signed-off-by: "Eric W. Biederman"
Signed-off-by: Greg Kroah-Hartman -
commit eb6d38d5427b3ad42f5268da0f1dd31bb0af1264 upstream.
Add a new function proc_create_mount_point that when used to creates a
directory that can not be added to.Add a new function is_empty_pde to test if a function is a mount
point.Update the code to use make_empty_dir_inode when reporting
a permanently empty directory to the vfs.Update the code to not allow adding to permanently empty directories.
Update /proc/openprom and /proc/fs/nfsd to be permanently empty directories.
Signed-off-by: "Eric W. Biederman"
Signed-off-by: Greg Kroah-Hartman -
commit f9bd6733d3f11e24f3949becf277507d422ee1eb upstream.
Add a magic sysctl table sysctl_mount_point that when used to
create a directory forces that directory to be permanently empty.Update the code to use make_empty_dir_inode when accessing permanently
empty directories.Update the code to not allow adding to permanently empty directories.
Update /proc/sys/fs/binfmt_misc to be a permanently empty directory.
Signed-off-by: "Eric W. Biederman"
Signed-off-by: Greg Kroah-Hartman -
commit fbabfd0f4ee2e8847bf56edf481249ad1bb8c44d upstream.
To ensure it is safe to mount proc and sysfs I need to check if
filesystems that are mounted on top of them are mounted on truly empty
directories. Given that some directories can gain entries over time,
knowing that a directory is empty right now is insufficient.Therefore add supporting infrastructure for permantently empty
directories that proc and sysfs can use when they create mount points
for filesystems and fs_fully_visible can use to test for permanently
empty directories to ensure that nothing will be gained by mounting a
fresh copy of proc or sysfs.Signed-off-by: "Eric W. Biederman"
Signed-off-by: Greg Kroah-Hartman
11 Jul, 2015
17 commits
-
commit e4f95517f18271b1da36cfc5d700e46844396d6e upstream.
Add last missing line in commit "cdd9eefdf905"
("fs/ufs: restore s_lock mutex")Signed-off-by: Fabian Frederick
Signed-off-by: Al Viro
Signed-off-by: Greg Kroah-Hartman -
commit 514d748f69c97a51a2645eb198ac5c6218f22ff9 upstream.
Commit e4502c63f56aeca88 (ufs: deal with nfsd/iget races) made ufs
create inodes with I_NEW flag set. However ufs_mkdir() never cleared
this flag. Thus if someone ever tried to lookup the directory by inode
number, he would deadlock waiting for I_NEW to be cleared. Luckily this
mostly happens only if the filesystem is exported over NFS since
otherwise we have the inode attached to dentry and don't look it up by
inode number. In rare cases dentry can get freed without inode being
freed and then we'd hit the deadlock even without NFS export.Fix the problem by clearing I_NEW before instantiating new directory
inode.Fixes: e4502c63f56aeca887ced37f24e0def1ef11cec8
Reported-by: Fabian Frederick
Signed-off-by: Jan Kara
Signed-off-by: Al Viro
Signed-off-by: Greg Kroah-Hartman -
commit 12ecbb4b1d765a5076920999298d9625439dbe58 upstream.
Commit e4502c63f56aeca88 (ufs: deal with nfsd/iget races) introduced
unlock_new_inode() call into ufs_add_nondir(). However that function
gets called also from ufs_link() which hands it already initialized
inode and thus unlock_new_inode() complains. The problem is harmless but
annoying.Fix the problem by opencoding necessary stuff in ufs_link()
Fixes: e4502c63f56aeca887ced37f24e0def1ef11cec8
Signed-off-by: Jan Kara
Signed-off-by: Al Viro
Signed-off-by: Greg Kroah-Hartman -
commit ceeb0e5d39fcdf4dca2c997bf225c7fc49200b37 upstream.
Limit the mounts fs_fully_visible considers to locked mounts.
Unlocked can always be unmounted so considering them adds hassle
but no security benefit.Signed-off-by: "Eric W. Biederman"
Signed-off-by: Greg Kroah-Hartman -
commit 93e3bce6287e1fb3e60d3324ed08555b5bbafa89 upstream.
The warning message in prepend_path is unclear and outdated. It was
added as a warning that the mechanism for generating names of pseudo
files had been removed from prepend_path and d_dname should be used
instead. Unfortunately the warning reads like a general warning,
making it unclear what to do with it.Remove the warning. The transition it was added to warn about is long
over, and I added code several years ago which in rare cases causes
the warning to fire on legitimate code, and the warning is now firing
and scaring people for no good reason.Reported-by: Ivan Delalande
Reported-by: Omar Sandoval
Fixes: f48cfddc6729e ("vfs: In d_path don't call d_dname on a mount point")
Signed-off-by: "Eric W. Biederman"
Signed-off-by: Greg Kroah-Hartman -
commit cdd9eefdf905e92e7fc6cc393314efe68dc6ff66 upstream.
Commit 0244756edc4b98c ("ufs: sb mutex merge + mutex_destroy") generated
deadlocks in read/write mode on mkdir.This patch partially reverts it keeping fixes by Andrew Morton and
mutex_destroy()[AV: fixed a missing bit in ufs_remount()]
Signed-off-by: Fabian Frederick
Reported-by: Ian Campbell
Suggested-by: Jan Kara
Cc: Ian Campbell
Cc: Evgeniy Dushistov
Cc: Alexey Khoroshilov
Cc: Roger Pau Monne
Cc: Ian Jackson
Cc: Al Viro
Signed-off-by: Andrew Morton
Signed-off-by: Al Viro
Signed-off-by: Greg Kroah-Hartman -
commit 13b987ea275840d74d9df9a44326632fab1894da upstream.
This reverts commit 9ef7db7f38d0 ("ufs: fix deadlocks introduced by sb
mutex merge") That patch tried to solve commit 0244756edc4b98c ("ufs: sb
mutex merge + mutex_destroy") which is itself partially reverted due to
multiple deadlocks.Signed-off-by: Fabian Frederick
Suggested-by: Jan Kara
Cc: Ian Campbell
Cc: Evgeniy Dushistov
Cc: Alexey Khoroshilov
Cc: Roger Pau Monne
Cc: Ian Jackson
Cc: Al Viro
Signed-off-by: Andrew Morton
Signed-off-by: Greg Kroah-Hartman -
commit 2426f3910069ed47c0cc58559a6d088af7920201 upstream.
file_remove_suid() could mistakenly set S_NOSEC inode bit when root was
modifying the file. As a result following writes to the file by ordinary
user would avoid clearing suid or sgid bits.Fix the bug by checking actual mode bits before setting S_NOSEC.
Signed-off-by: Jan Kara
Signed-off-by: Al Viro
Signed-off-by: Greg Kroah-Hartman -
commit 42720138b06301cc8a7ee8a495a6d021c4b6a9bc upstream.
Writes were a bit racy, but hard to turn into a bug at the same time.
(Particularly because modern Linux doesn't use this feature anymore.)Signed-off-by: Radim Krčmář
[Actually the next patch makes it much, much easier to trigger the race
so I'm including this one for stable@ as well. - Paolo]
Signed-off-by: Paolo Bonzini
Signed-off-by: Greg Kroah-Hartman -
commit db1385624c686fe99fe2d1b61a36e1537b915d08 upstream.
Legacy NMI watchdog didn't work after migration/resume, because
vapics_in_nmi_mode was left at 0.Signed-off-by: Radim Krčmář
Signed-off-by: Paolo Bonzini
Signed-off-by: Greg Kroah-Hartman -
commit 4839ddc27b7212ec58874f62c97da7400c8523be upstream.
Commit fd1d0ddf2ae9 (KVM: arm/arm64: check IRQ number on userland
injection) rightly limited the range of interrupts userspace can
inject in a guest, but failed to consider the (unlikely) case where
a guest is configured with 1024 interrupts.In this case, interrupts ranging from 1020 to 1023 are unuseable,
as they have a special meaning for the GIC CPU interface.Make sure that these number cannot be used as an IRQ. Also delete
a redundant (and similarily buggy) check in kvm_set_irq.Reported-by: Peter Maydell
Cc: Andre Przywara
Signed-off-by: Marc Zyngier
Signed-off-by: Greg Kroah-Hartman -
commit 431dae778aea4eed31bd12e5ee82edc571cd4d70 upstream.
Eric noticed problems with vhost-scsi and virtio-ccw: vhost-scsi
complained about overwriting values in the config space, which
was triggered by a broken implementation of virtio-ccw's config
get/set routines. It was probably sheer luck that we did not hit
this before.When writing a value to the config space, the WRITE_CONF ccw will
always write from the beginning of the config space up to and
including the value to be set. If the config space up to the value
has not yet been retrieved from the device, however, we'll end up
overwriting values. Keep track of the known config space and update
if needed to avoid this.Moreover, READ_CONF will only read the number of bytes it has been
instructed to retrieve, so we must not copy more than that to the
buffer, or we might overwrite trailing values.Reported-by: Eric Farman
Signed-off-by: Cornelia Huck
Reviewed-by: Eric Farman
Tested-by: Eric Farman
Signed-off-by: Christian Borntraeger
Signed-off-by: Paolo Bonzini
Signed-off-by: Greg Kroah-Hartman -
commit 3c8e5105e759e7b2d88ea8a85b1285e535bc7500 upstream.
The REGSET_VX_LOW ELF notes should contain the lower 64 bit halfes of the
first sixteen 128 bit vector registers. Unfortunately currently we copy
the upper halfes.Fix this and correctly copy the lower halfes.
Fixes: a62bc0739253 ("s390/kdump: add support for vector extension")
Signed-off-by: Michael Holzheu
Signed-off-by: Martin Schwidefsky
Signed-off-by: Greg Kroah-Hartman -
commit b035b60ded132592055c0f9bd1cc280259c7de4b upstream.
Currently all backward jumps crash for JITed s390x eBPF programs
with an illegal instruction program check and kernel panic. Because
for negative values the opcode of the jump instruction is overriden
by the negative branch offset an illegal instruction is generated
by the JIT:000003ff802da378: c01100000002 lgfi %r1,2
000003ff802da37e: fffffff52065 unknown
Signed-off-by: Martin Schwidefsky
Signed-off-by: Greg Kroah-Hartman -
commit f2ae45edbca7ba5324eef01719ede0151dc5cead upstream.
commit 6d3da24141 ("KVM: s390: deliver floating interrupts in order
of priority") introduced a regression for the reset handling.We don't clear the bitmap of pending floating interrupts
and interrupt parameters. This could result in stale interrupts
even after a reset. Let's fix this by clearing the pending bitmap
and the parameters for service and machine check interrupts.Signed-off-by: Jens Freimann
Signed-off-by: Christian Borntraeger
Signed-off-by: Paolo Bonzini
Signed-off-by: Greg Kroah-Hartman -
commit b938eacea0b6881f2116a061e6da3ec840e75137 upstream.
Commit ea5f49692575 ("KVM: s390: only one external call may be pending
at a time") introduced a bug on machines that don't have SIGP
interpretation facility installed.
The injection of an external call will now always fail with -EBUSY
(if none is already pending).This leads to the following symptoms:
- An external call will be injected but with the wrong "src cpu id",
as this id will not be remembered.
- The target vcpu will not be woken up, therefore the guest will hang if
it cannot deal with unexpected failures of the SIGP EXTERNAL CALL
instruction.
- If an external call is already pending, -EBUSY will not be reported.Reviewed-by: Christian Borntraeger
Reviewed-by: Jens Freimann
Signed-off-by: David Hildenbrand
Signed-off-by: Christian Borntraeger
Signed-off-by: Greg Kroah-Hartman
