1. 26 Mar, 2016 1 commit
    • Al Viro's avatar
      orangefs: fix orangefs_superblock locking · 45996492
      Al Viro authored
      * switch orangefs_remount() to taking ORANGEFS_SB(sb) instead of sb
      * remove from the list _before_ orangefs_unmount() - request_mutex
      in the latter will make sure that nothing observed in the loop in
      ORANGEFS_DEV_REMOUNT_ALL handling will get freed until the end
      of loop
      * on removal, keep the forward pointer and zero the back one.  That
      way we can drop and regain the spinlock in the loop body (again,
      ORANGEFS_DEV_REMOUNT_ALL one) and still be able to get to the
      rest of the list.
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarMike Marshall <hubcap@omnibond.com>
  2. 25 Mar, 2016 7 commits
  3. 23 Mar, 2016 11 commits
  4. 17 Mar, 2016 5 commits
  5. 14 Mar, 2016 4 commits
  6. 13 Mar, 2016 6 commits
  7. 12 Mar, 2016 6 commits
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.dk/linux-block · f414ca64
      Linus Torvalds authored
      Pull block merge fix from Jens Axboe.
      This fixes the block segment counting bug and resulting sg overrun
      reported by Kent Overstreet, introduced with the last block pull.
      * 'for-linus' of git://git.kernel.dk/linux-block:
        block: don't optimize for non-cloned bio in bio_get_last_bvec()
    • Linus Torvalds's avatar
      Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip · 2f51c820
      Linus Torvalds authored
      Pull x86 fixes from Ingo Molnar:
       "This fixes 3 FPU handling related bugs, an EFI boot crash and a
        runtime warning.
        The EFI fix arrived late but I didn't want to delay it to after v4.5
        because the effects are pretty bad for the systems that are affected
        by it"
      [ Actually, I don't think the EFI fix really matters yet, because we
        haven't switched to the separate EFI page tables in mainline yet ]
      * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
        x86/efi: Fix boot crash by always mapping boot service regions into new EFI page tables
        x86/fpu: Fix eager-FPU handling on legacy FPU machines
        x86/delay: Avoid preemptible context checks in delay_mwaitx()
        x86/fpu: Revert ("x86/fpu: Disable AVX when eagerfpu is off")
        x86/fpu: Fix 'no387' regression
    • Linus Torvalds's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending · fda604a4
      Linus Torvalds authored
      Pull SCSI target bug fix from Nicholas Bellinger:
       "Here is an outstanding target-core bug-fix for v4.5 code."
        This patch addresses a recent Task Management (TMR) regression related
        to larger set of multi-port LUN_RESET bug-fixes in v4.5-rc5.
        It drops a left-over target_put_sess_cmd() of se_cmd->cmd_kref within
        ABORT_TASK failure path, once a se_cmd descriptor has already
        completed posting response to fabric driver logic, and must be skipped
        during normal ABORT_TASK se_cmd->tag lookup"
      * git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending:
        target: Drop incorrect ABORT_TASK put for completed commands
    • Ming Lei's avatar
      block: don't optimize for non-cloned bio in bio_get_last_bvec() · 90d0f0f1
      Ming Lei authored
      For !BIO_CLONED bio, we can use .bi_vcnt safely, but it
      doesn't mean we can just simply return .bi_io_vec[.bi_vcnt - 1]
      because the start postion may have been moved in the middle of
      the bvec, such as splitting in the middle of bvec.
      Fixes: 7bcd79ac(block: bio: introduce helpers to get the 1st and last bvec)
      Cc: stable@vger.kernel.org
      Reported-by: default avatarKent Overstreet <kent.overstreet@gmail.com>
      Signed-off-by: default avatarMing Lei <ming.lei@canonical.com>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
    • Matt Fleming's avatar
      x86/efi: Fix boot crash by always mapping boot service regions into new EFI page tables · 452308de
      Matt Fleming authored
      Some machines have EFI regions in page zero (physical address
      0x00000000) and historically that region has been added to the e820
      map via trim_bios_range(), and ultimately mapped into the kernel page
      tables. It was not mapped via efi_map_regions() as one would expect.
      Alexis reports that with the new separate EFI page tables some boot
      services regions, such as page zero, are not mapped. This triggers an
      oops during the SetVirtualAddressMap() runtime call.
      For the EFI boot services quirk on x86 we need to memblock_reserve()
      boot services regions until after SetVirtualAddressMap(). Doing that
      while respecting the ownership of regions that may have already been
      reserved by the kernel was the motivation behind this commit:
        7d68dc3f ("x86, efi: Do not reserve boot services regions within reserved areas")
      That patch was merged at a time when the EFI runtime virtual mappings
      were inserted into the kernel page tables as described above, and the
      trick of setting ->numpages (and hence the region size) to zero to
      track regions that should not be freed in efi_free_boot_services()
      meant that we never mapped those regions in efi_map_regions(). Instead
      we were relying solely on the existing kernel mappings.
      Now that we have separate page tables we need to make sure the EFI
      boot services regions are mapped correctly, even if someone else has
      already called memblock_reserve(). Instead of stashing a tag in
      ->numpages, set the EFI_MEMORY_RUNTIME bit of ->attribute. Since it
      generally makes no sense to mark a boot services region as required at
      runtime, it's pretty much guaranteed the firmware will not have
      already set this bit.
      For the record, the specific circumstances under which Alexis
      triggered this bug was that an EFI runtime driver on his machine was
      responding to the EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE event during
      The event handler for this driver looks like this,
        sub rsp,0x28
        lea rdx,[rip+0x2445] # 0xaa948720
        mov ecx,0x4
        call func_aa9447c0  ; call to ConvertPointer(4, & 0xaa948720)
        mov r11,QWORD PTR [rip+0x2434] # 0xaa948720
        xor eax,eax
        mov BYTE PTR [r11+0x1],0x1
        add rsp,0x28
      Which is pretty typical code for an EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE
      handler. The "mov r11, QWORD PTR [rip+0x2424]" was the faulting
      instruction because ConvertPointer() was being called to convert the
      address 0x0000000000000000, which when converted is left unchanged and
      remains 0x0000000000000000.
      The output of the oops trace gave the impression of a standard NULL
      pointer dereference bug, but because we're accessing physical
      addresses during ConvertPointer(), it wasn't. EFI boot services code
      is stored at that address on Alexis' machine.
      Reported-by: default avatarAlexis Murzeau <amurzeau@gmail.com>
      Signed-off-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Raphael Hertzog <hertzog@debian.org>
      Cc: Roger Shimizu <rogershimizu@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/1457695163-29632-2-git-send-email-matt@codeblueprint.co.uk
      Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815125Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
    • Borislav Petkov's avatar
      x86/fpu: Fix eager-FPU handling on legacy FPU machines · 6e686709
      Borislav Petkov authored
      i486 derived cores like Intel Quark support only the very old,
      legacy x87 FPU (FSAVE/FRSTOR, CPUID bit FXSR is not set), and
      our FPU code wasn't handling the saving and restoring there
      properly in the 'eagerfpu' case.
      So after we made eagerfpu the default for all CPU types:
        58122bf1 x86/fpu: Default eagerfpu=on on all CPUs
      these old FPU designs broke. First, Andy Shevchenko reported a splat:
        WARNING: CPU: 0 PID: 823 at arch/x86/include/asm/fpu/internal.h:163 fpu__clear+0x8c/0x160
      which was us trying to execute FXRSTOR on those machines even though
      they don't support it.
      After taking care of that, Bryan O'Donoghue reported that a simple FPU
      test still failed because we weren't initializing the FPU state properly
      on those machines.
      Take care of all that.
      Reported-and-tested-by: default avatarBryan O'Donoghue <pure.logic@nexus-software.ie>
      Reported-by: default avatarAndy Shevchenko <andy.shevchenko@gmail.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Acked-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Quentin Casasnovas <quentin.casasnovas@oracle.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Yu-cheng <yu-cheng.yu@intel.com>
      Link: http://lkml.kernel.org/r/20160311113206.GD4312@pd.tnicSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>