Skip to content

L
linux
Switch branch/tag
  1. 12 May, 2015 20 commits
    • Christoph Hellwig's avatar
      3w-sas: fix command completion race · e9001146
      Christoph Hellwig authored 
      commit 579d69bc upstream.

The 3w-sas driver needs to tear down the dma mappings before returning
the command to the midlayer, as there is no guarantee the sglist and
count are valid after that point.  Also remove the dma mapping helpers
which have another inherent race due to the request_id index.
Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
Reported-by: default avatarTorsten Luettgert <ml-lkml@enda.eu>
Tested-by: default avatarBernd Kardatzki <Bernd.Kardatzki@med.uni-tuebingen.de>
Acked-by: default avatarAdam Radford <aradford@gmail.com>
Signed-off-by: default avatarJames Bottomley <JBottomley@Odin.com>
Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      e9001146
    • Mike Christie's avatar
      SCSI: add 1024 max sectors black list flag · b4fd6000
      Mike Christie authored 
      commit 35e9a9f9 upstream.

This works around a issue with qnap iscsi targets not handling large IOs
very well.

The target returns:

VPD INQUIRY: Block limits page (SBC)
  Maximum compare and write length: 1 blocks
  Optimal transfer length granularity: 1 blocks
  Maximum transfer length: 4294967295 blocks
  Optimal transfer length: 4294967295 blocks
  Maximum prefetch, xdread, xdwrite transfer length: 0 blocks
  Maximum unmap LBA count: 8388607
  Maximum unmap block descriptor count: 1
  Optimal unmap granularity: 16383
  Unmap granularity alignment valid: 0
  Unmap granularity alignment: 0
  Maximum write same length: 0xffffffff blocks
  Maximum atomic transfer length: 0
  Atomic alignment: 0
  Atomic transfer length granularity: 0

and it is *sometimes* able to handle at least one IO of size up to 8 MB. We
have seen in traces where it will sometimes work, but other times it
looks like it fails and it looks like it returns failures if we send
multiple large IOs sometimes. Also it looks like it can return 2 different
errors. It will sometimes send iscsi reject errors indicating out of
resources or it will send invalid cdb illegal requests check conditions.
And then when it sends iscsi rejects it does not seem to handle retries
when there are command sequence holes, so I could not just add code to
try and gracefully handle that error code.

The problem is that we do not have a good contact for the company,
so we are not able to determine under what conditions it returns
which error and why it sometimes works.

So, this patch just adds a new black list flag to set targets like this to
the old max safe sectors of 1024. The max_hw_sectors changes added in 3.19
caused this regression, so I also ccing stable.
Reported-by: default avatarChristian Hesse <list@eworm.de>
Signed-off-by: default avatarMike Christie <michaelc@cs.wisc.edu>
Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
Signed-off-by: default avatarJames Bottomley <JBottomley@Odin.com>
Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      b4fd6000
    • Alex Deucher's avatar
      drm/radeon: add SI DPM quirk for Sapphire R9 270 Dual-X 2G GDDR5 · 96386899
      Alex Deucher authored 
      commit cd17e02f upstream.

Seems to have problems with high mclks.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=76490Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      96386899
    • Takashi Iwai's avatar
      ALSA: emux: Fix mutex deadlock at unloading · 6f9e33f2
      Takashi Iwai authored 
      commit 07b0e5d4 upstream.

The emux-synth driver has a possible AB/BA mutex deadlock at unloading
the emu10k1 driver:

  snd_emux_free() ->
    snd_emux_detach_seq(): mutex_lock(&emu->register_mutex) ->
      snd_seq_delete_kernel_client() ->
        snd_seq_free_client(): mutex_lock(&register_mutex)

  snd_seq_release() ->
    snd_seq_free_client(): mutex_lock(&register_mutex) ->
      snd_seq_delete_all_ports() ->
        snd_emux_unuse(): mutex_lock(&emu->register_mutex)

Basically snd_emux_detach_seq() doesn't need a protection of
emu->register_mutex as it's already being unregistered.  So, we can
get rid of this for avoiding the deadlock.
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      6f9e33f2
    • Takashi Iwai's avatar
      ALSA: emu10k1: Fix card shortname string buffer overflow · e45af6c8
      Takashi Iwai authored 
      commit d0226082 upstream.

Some models provide too long string for the shortname that has 32bytes
including the terminator, and it results in a non-terminated string
exposed to the user-space.  This isn't too critical, though, as the
string is stopped at the succeeding longname string.

This patch fixes such entries by dropping "SB" prefix (it's enough to
fit within 32 bytes, so far).  Meanwhile, it also changes strcpy()
with strlcpy() to make sure that this kind of problem won't happen in
future, too.
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      e45af6c8
    • Marek Szyprowski's avatar
      arm64: dma-mapping: always clear allocated buffers · a92a43a1
      Marek Szyprowski authored 
      commit 6829e274 upstream.

Buffers allocated by dma_alloc_coherent() are always zeroed on Alpha,
ARM (32bit), MIPS, PowerPC, x86/x86_64 and probably other architectures.
It turned out that some drivers rely on this 'feature'. Allocated buffer
might be also exposed to userspace with dma_mmap() call, so clearing it
is desired from security point of view to avoid exposing random memory
to userspace. This patch unifies dma_alloc_coherent() behavior on ARM64
architecture with other implementations by unconditionally zeroing
allocated buffer.
Signed-off-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
[ luis: backported to 3.16:
  - dropped changes to __alloc_from_pool() which doesn't exist in 3.16 ]
Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      a92a43a1
    • Takashi Iwai's avatar
      ALSA: hda - Add mute-LED mode control to Thinkpad · cf62a983
      Takashi Iwai authored 
      commit 7290006d upstream.

This patch adds the missing flag to enable "Mute-LED Mode" mixer enum
ctl for Thinkpads that have also the software mute-LED control.
Reported-and-tested-by: default avatarPali Rohár <pali.rohar@gmail.com>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      cf62a983
    • Takashi Iwai's avatar
      ALSA: hda - Fix mute-LED fixed mode · 08dbb459
      Takashi Iwai authored 
      commit ee52e56e upstream.

The mute-LED mode control has the fixed on/off states that are
supposed to remain on/off regardless of the master switch.  However,
this doesn't work actually because the vmaster hook is called in the
vmaster code itself.

This patch fixes it by calling the hook indirectly after checking the
mute LED mode.
Reported-and-tested-by: default avatarPali Rohár <pali.rohar@gmail.com>
Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
[ luis: backported to 3.16: adjusted context ]
Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      08dbb459
    • Omar Sandoval's avatar
      btrfs: unlock i_mutex after attempting to delete subvolume during send · 5a4dd003
      Omar Sandoval authored 
      commit 909e26dc upstream.

Whenever the check for a send in progress introduced in commit
521e0546 (btrfs: protect snapshots from deleting during send) is
hit, we return without unlocking inode->i_mutex. This is easy to see
with lockdep enabled:

[  +0.000059] ================================================
[  +0.000028] [ BUG: lock held when returning to user space! ]
[  +0.000029] 4.0.0-rc5-00096-g3c435c1e #93 Not tainted
[  +0.000026] ------------------------------------------------
[  +0.000029] btrfs/211 is leaving the kernel with locks still held!
[  +0.000029] 1 lock held by btrfs/211:
[  +0.000023]  #0:  (&type->i_mutex_dir_key){+.+.+.}, at: [<ffffffff8135b8df>] btrfs_ioctl_snap_destroy+0x2df/0x7a0

Make sure we unlock it in the error path.
Reviewed-by: default avatarFilipe Manana <fdmanana@suse.com>
Reviewed-by: default avatarDavid Sterba <dsterba@suse.cz>
Signed-off-by: default avatarOmar Sandoval <osandov@osandov.com>
Signed-off-by: default avatarChris Mason <clm@fb.com>
Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      5a4dd003
    • Bard Liao's avatar
      ASoC: rt5677: add register patch for PLL · 44ac5963
      Bard Liao authored 
      commit 74d6ea52 upstream.

The PLL output will be unstable in some cases. We can fix it by
setting some registers.
Signed-off-by: default avatarBard Liao <bardliao@realtek.com>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      44ac5963
    • Charles Keepax's avatar
      ASoC: dapm: Enable autodisable on SOC_DAPM_SINGLE_TLV_AUTODISABLE · 21f91efb
      Charles Keepax authored 
      commit a2d97723 upstream.

Correct small copy and paste error where autodisable was not being
enabled for the SOC_DAPM_SINGLE_TLV_AUTODISABLE control.
Signed-off-by: default avatarCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: default avatarMark Brown <broonie@kernel.org>
Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      21f91efb
    • Eric W. Biederman's avatar
      mnt: Fail collect_mounts when applied to unmounted mounts · 4bcf842d
      Eric W. Biederman authored 
      commit cd4a4017 upstream.

The only users of collect_mounts are in audit_tree.c

In audit_trim_trees and audit_add_tree_rule the path passed into
collect_mounts is generated from kern_path passed an audit_tree
pathname which is guaranteed to be an absolute path.   In those cases
collect_mounts is obviously intended to work on mounted paths and
if a race results in paths that are unmounted when collect_mounts
it is reasonable to fail early.

The paths passed into audit_tag_tree don't have the absolute path
check.  But are used to play with fsnotify and otherwise interact with
the audit_trees, so again operating only on mounted paths appears
reasonable.

Avoid having to worry about what happens when we try and audit
unmounted filesystems by restricting collect_mounts to mounts
that appear in the mount tree.
Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      4bcf842d
    • hujianyang's avatar
      UBI: fix soft lockup in ubi_check_volume() · f0958ab0
      hujianyang authored 
      commit 9aa272b4 upstream.

Running mtd-utils/tests/ubi-tests/io_basic.c could cause
soft lockup or watchdog reset. It is because *updatevol*
will perform ubi_check_volume() after updating finish
and this function will full scan the updated lebs if the
volume is initialized as STATIC_VOLUME.

This patch adds *cond_resched()* in the loop of lebs scan
to avoid soft lockup.

Helped by Richard Weinberger <richard@nod.at>

[ 2158.067096] INFO: rcu_sched self-detected stall on CPU { 1}  (t=2101 jiffies g=1606 c=1605 q=56)
[ 2158.172867] CPU: 1 PID: 2073 Comm: io_basic Tainted: G           O 3.10.53 #21
[ 2158.172898] [<c000f624>] (unwind_backtrace+0x0/0x120) from [<c000c294>] (show_stack+0x10/0x14)
[ 2158.172918] [<c000c294>] (show_stack+0x10/0x14) from [<c008ac3c>] (rcu_check_callbacks+0x1c0/0x660)
[ 2158.172936] [<c008ac3c>] (rcu_check_callbacks+0x1c0/0x660) from [<c002b480>] (update_process_times+0x38/0x64)
[ 2158.172953] [<c002b480>] (update_process_times+0x38/0x64) from [<c005ff38>] (tick_sched_handle+0x54/0x60)
[ 2158.172966] [<c005ff38>] (tick_sched_handle+0x54/0x60) from [<c00601ac>] (tick_sched_timer+0x44/0x74)
[ 2158.172978] [<c00601ac>] (tick_sched_timer+0x44/0x74) from [<c003f348>] (__run_hrtimer+0xc8/0x1b8)
[ 2158.172992] [<c003f348>] (__run_hrtimer+0xc8/0x1b8) from [<c003fd9c>] (hrtimer_interrupt+0x128/0x2a4)
[ 2158.173007] [<c003fd9c>] (hrtimer_interrupt+0x128/0x2a4) from [<c0246f1c>] (arch_timer_handler_virt+0x28/0x30)
[ 2158.173022] [<c0246f1c>] (arch_timer_handler_virt+0x28/0x30) from [<c0086214>] (handle_percpu_devid_irq+0x9c/0x124)
[ 2158.173036] [<c0086214>] (handle_percpu_devid_irq+0x9c/0x124) from [<c0082bd8>] (generic_handle_irq+0x20/0x30)
[ 2158.173049] [<c0082bd8>] (generic_handle_irq+0x20/0x30) from [<c000969c>] (handle_IRQ+0x64/0x8c)
[ 2158.173060] [<c000969c>] (handle_IRQ+0x64/0x8c) from [<c0008544>] (gic_handle_irq+0x3c/0x60)
[ 2158.173074] [<c0008544>] (gic_handle_irq+0x3c/0x60) from [<c02f0f80>] (__irq_svc+0x40/0x50)
[ 2158.173083] Exception stack(0xc4043c98 to 0xc4043ce0)
[ 2158.173092] 3c80:                                                       c4043ce4 00000019
[ 2158.173102] 3ca0: 1f8a865f c050ad10 1f8a864c 00000031 c04b5970 0003ebce 00000000 f3550000
[ 2158.173113] 3cc0: bf00bc68 00000800 0003ebce c4043ce0 c0186d14 c0186cb8 80000013 ffffffff
[ 2158.173130] [<c02f0f80>] (__irq_svc+0x40/0x50) from [<c0186cb8>] (read_current_timer+0x4/0x38)
[ 2158.173145] [<c0186cb8>] (read_current_timer+0x4/0x38) from [<1f8a865f>] (0x1f8a865f)
[ 2183.927097] BUG: soft lockup - CPU#1 stuck for 22s! [io_basic:2073]
[ 2184.002229] Modules linked in: nandflash(O) [last unloaded: nandflash]
Signed-off-by: default avatarWang Kai <morgan.wang@huawei.com>
Signed-off-by: default avatarhujianyang <hujianyang@huawei.com>
Signed-off-by: default avatarRichard Weinberger <richard@nod.at>
Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f0958ab0
    • Vineet Gupta's avatar
      ARC: signal handling robustify · 4a5abf78
      Vineet Gupta authored 
      commit e4140819 upstream.

A malicious signal handler / restorer can DOS the system by fudging the
user regs saved on stack, causing weird things such as sigreturn returning
to user mode PC but cpu state still being kernel mode....

Ensure that in sigreturn path status32 always has U bit; any other bogosity
(gargbage PC etc) will be taken care of by normal user mode exceptions mechanisms.

Reproducer signal handler:

    void handle_sig(int signo, siginfo_t *info, void *context)
    {
	ucontext_t *uc = context;
	struct user_regs_struct *regs = &(uc->uc_mcontext.regs);

	regs->scratch.status32 = 0;
    }

Before the fix, kernel would go off to weeds like below:

    --------->8-----------
    [ARCLinux]$ ./signal-test
    Path: /signal-test
    CPU: 0 PID: 61 Comm: signal-test Not tainted 4.0.0-rc5+ #65
    task: 8f177880 ti: 5ffe6000 task.ti: 8f15c000

    [ECR   ]: 0x00220200 => Invalid Write @ 0x00000010 by insn @ 0x00010698
    [EFA   ]: 0x00000010
    [BLINK ]: 0x2007c1ee
    [ERET  ]: 0x10698
    [STAT32]: 0x00000000 :                                   <--------
    BTA: 0x00010680	 SP: 0x5ffe7e48	 FP: 0x00000000
    LPS: 0x20003c6c	LPE: 0x20003c70	LPC: 0x00000000
    ...
    --------->8-----------
Reported-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: default avatarVineet Gupta <vgupta@synopsys.com>
[ luis: backported to 3.16: used Vineet's backport to 3.14 ]
Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      4a5abf78
    • Matt Fleming's avatar
      x86/reboot: Add EFI reboot quirk for ACPI Hardware Reduced flag · 694b7f5f
      Matt Fleming authored 
      commit 44be28e9 upstream.

It appears that the BayTrail-T class of hardware requires EFI in order
to powerdown and reboot and no other reliable method exists.

This quirk is generally applicable to all hardware that has the ACPI
Hardware Reduced bit set, since usually ACPI would be the preferred
method.

Cc: Len Brown <len.brown@intel.com>
Cc: Mark Salter <msalter@redhat.com>
Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
[ luis: backported to 3.16:
  - move changes from quirks.c into efi.c
  - adjusted context ]
Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      694b7f5f
    • Matt Fleming's avatar
      efi/reboot: Allow powering off machines using EFI · f6c2e46d
      Matt Fleming authored 
      commit 0c5ed61a upstream.

Not only can EfiResetSystem() be used to reboot, it can also be used to
power down machines.

By and large, this functionality doesn't work very well across the range
of EFI machines in the wild, so it should definitely only be used as a
last resort. In an ideal world, this wouldn't be needed at all.

Unfortunately, we're starting to see machines where EFI is the *only*
reliable way to power down, and nothing else, not PCI, not ACPI, works.

efi_poweroff_required() should be implemented on a per-architecture
basis, since exactly when we should be using EFI runtime services is a
platform-specific decision. There's no analogue for reboot because each
architecture handles reboot very differently - the x86 code in
particular is pretty complex.

Patches to enable this for specific classes of hardware will be
submitted separately.
Tested-by: default avatarMark Salter <msalter@redhat.com>
Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      f6c2e46d
    • Matt Fleming's avatar
      efi/reboot: Add generic wrapper around EfiResetSystem() · c4bb687a
      Matt Fleming authored 
      commit 8562c99c upstream.

Implement efi_reboot(), which is really just a wrapper around the
EfiResetSystem() EFI runtime service, but it does at least allow us to
funnel all callers through a single location.

It also simplifies the callsites since users no longer need to check to
see whether EFI_RUNTIME_SERVICES are enabled.

Cc: Tony Luck <tony.luck@intel.com>
Tested-by: default avatarMark Salter <msalter@redhat.com>
Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      c4bb687a
    • Ido Shamay's avatar
      net/mlx4_en: Schedule napi when RX buffers allocation fails · ddef2b7f
      Ido Shamay authored 
      commit 07841f9d upstream.

When system is out of memory, refilling of RX buffers fails while
the driver continue to pass the received packets to the kernel stack.
At some point, when all RX buffers deplete, driver may fall into a
sleep, and not recover when memory for new RX buffers is once again
availible. This is because hardware does not have valid descriptors,
so no interrupt will be generated for the driver to return to work
in napi context. Fix it by schedule the napi poll function from
stats_task delayed workqueue, as long as the allocations fail.
Signed-off-by: default avatarIdo Shamay <idos@mellanox.com>
Signed-off-by: default avatarAmir Vadai <amirv@mellanox.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      ddef2b7f
    • Benjamin Poirier's avatar
      mlx4: Fix tx ring affinity_mask creation · 0502c51a
      Benjamin Poirier authored 
      commit 42eab005 upstream.

By default, the number of tx queues is limited by the number of online cpus
in mlx4_en_get_profile(). However, this limit no longer holds after the
ethtool .set_channels method has been called. In that situation, the driver
may access invalid bits of certain cpumask variables when queue_index >=
nr_cpu_ids.
Signed-off-by: default avatarBenjamin Poirier <bpoirier@suse.de>
Acked-by: default avatarIdo Shamay <idos@mellanox.com>
Fixes: d03a68f8 ("net/mlx4_en: Configure the XPS queue mapping on driver load")
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      0502c51a
    • Luis Henriques's avatar
      Linux 3.16.7-ckt11 · 56a11552
      Luis Henriques authored 
      Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
      56a11552
  3. 06 May, 2015 20 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7