1. 21 Apr, 2016 2 commits
    • Hari Bathini's avatar
      powerpc/book3s64: Remove __end_handlers marker · 057b6d7e
      Hari Bathini authored
      The __end_handlers marker was intended to mark down upto code that gets
      called from exception prologs. But that hasn't kept pace with code
      changes. Case in point, slb_miss_realmode being called from exception
      prolog code but isn't below __end_handlers marker. So, __end_handlers
      marker is as good as a comment but could be misleading at times if it
      isn't in sync with the code, as is the case now. So, let us avoid this
      confusion by having a better comment and removing __end_handlers marker
      altogether.
      Signed-off-by: default avatarHari Bathini <hbathini@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      057b6d7e
    • Hari Bathini's avatar
      powerpc/book3s64: Fix branching to OOL handlers in relocatable kernel · 8ed8ab40
      Hari Bathini authored
      Some of the interrupt vectors on 64-bit POWER server processors are only
      32 bytes long (8 instructions), which is not enough for the full
      first-level interrupt handler. For these we need to branch to an
      out-of-line (OOL) handler. But when we are running a relocatable kernel,
      interrupt vectors till __end_interrupts marker are copied down to real
      address 0x100. So, branching to labels (ie. OOL handlers) outside this
      section must be handled differently (see LOAD_HANDLER()), considering
      relocatable kernel, which would need at least 4 instructions.
      
      However, branching from interrupt vector means that we corrupt the
      CFAR (come-from address register) on POWER7 and later processors as
      mentioned in commit 1707dd16. So, EXCEPTION_PROLOG_0 (6 instructions)
      that contains the part up to the point where the CFAR is saved in the
      PACA should be part of the short interrupt vectors before we branch out
      to OOL handlers.
      
      But as mentioned already, there are interrupt vectors on 64-bit POWER
      server processors that are only 32 bytes long (like vectors 0x4f00,
      0x4f20, etc.), which cannot accomodate the above two cases at the same
      time owing to space constraint. Currently, in these interrupt vectors,
      we simply branch out to OOL handlers, without using LOAD_HANDLER(),
      which leaves us vulnerable when running a relocatable kernel (eg. kdump
      case). While this has been the case for sometime now and kdump is used
      widely, we were fortunate not to see any problems so far, for three
      reasons:
      
        1. In almost all cases, production kernel (relocatable) is used for
           kdump as well, which would mean that crashed kernel's OOL handler
           would be at the same place where we end up branching to, from short
           interrupt vector of kdump kernel.
        2. Also, OOL handler was unlikely the reason for crash in almost all
           the kdump scenarios, which meant we had a sane OOL handler from
           crashed kernel that we branched to.
        3. On most 64-bit POWER server processors, page size is large enough
           that marking interrupt vector code as executable (see commit
           429d2e83) leads to marking OOL handler code from crashed kernel,
           that sits right below interrupt vector code from kdump kernel, as
           executable as well.
      
      Let us fix this by moving the __end_interrupts marker down past OOL
      handlers to make sure that we also copy OOL handlers to real address
      0x100 when running a relocatable kernel.
      
      This fix has been tested successfully in kdump scenario, on an LPAR with
      4K page size by using different default/production kernel and kdump
      kernel.
      
      Also tested by manually corrupting the OOL handlers in the first kernel
      and then kdump'ing, and then causing the OOL handlers to fire - mpe.
      
      Fixes: c1fb6816 ("powerpc: Add relocation on exception vector handlers")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarHari Bathini <hbathini@linux.vnet.ibm.com>
      Signed-off-by: default avatarMahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      8ed8ab40
  2. 18 Apr, 2016 1 commit
  3. 14 Apr, 2016 5 commits
    • Michael Ellerman's avatar
      powerpc/livepatch: Add live patching support on ppc64le · 85baa095
      Michael Ellerman authored
      Add the kconfig logic & assembly support for handling live patched
      functions. This depends on DYNAMIC_FTRACE_WITH_REGS, which in turn
      depends on the new -mprofile-kernel ftrace ABI, which is only supported
      currently on ppc64le.
      
      Live patching is handled by a special ftrace handler. This means it runs
      from ftrace_caller(). The live patch handler modifies the NIP so as to
      redirect the return from ftrace_caller() to the new patched function.
      
      However there is one particularly tricky case we need to handle.
      
      If a function A calls another function B, and it is known at link time
      that they share the same TOC, then A will not save or restore its TOC,
      and will call the local entry point of B.
      
      When we live patch B, we replace it with a new function C, which may
      not have the same TOC as A. At live patch time it's too late to modify A
      to do the TOC save/restore, so the live patching code must interpose
      itself between A and C, and do the TOC save/restore that A omitted.
      
      An additionaly complication is that the livepatch code can not create a
      stack frame in order to save the TOC. That is because if C takes > 8
      arguments, or is varargs, A will have written the arguments for C in
      A's stack frame.
      
      To solve this, we introduce a "livepatch stack" which grows upward from
      the base of the regular stack, and is used to store the TOC & LR when
      calling a live patched function.
      
      When the patched function returns, we retrieve the real LR & TOC from
      the livepatch stack, restore them, and pop the livepatch "stack frame".
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Reviewed-by: default avatarTorsten Duwe <duwe@suse.de>
      Reviewed-by: default avatarBalbir Singh <bsingharora@gmail.com>
      85baa095
    • Michael Ellerman's avatar
      powerpc/livepatch: Add livepatch stack to struct thread_info · 5d31a96e
      Michael Ellerman authored
      In order to support live patching we need to maintain an alternate
      stack of TOC & LR values. We use the base of the stack for this, and
      store the "live patch stack pointer" in struct thread_info.
      
      Unlike the other fields of thread_info, we can not statically initialise
      that value, so it must be done at run time.
      
      This patch just adds the code to support that, it is not enabled until
      the next patch which actually adds live patch support.
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Acked-by: default avatarBalbir Singh <bsingharora@gmail.com>
      5d31a96e
    • Michael Ellerman's avatar
      powerpc/livepatch: Add livepatch header · f63e6d89
      Michael Ellerman authored
      Add the powerpc specific livepatch definitions. In particular we provide
      a non-default implementation of klp_get_ftrace_location().
      
      This is required because the location of the mcount call is not constant
      when using -mprofile-kernel (which we always do for live patching).
      Signed-off-by: default avatarTorsten Duwe <duwe@suse.de>
      Signed-off-by: default avatarBalbir Singh <bsingharora@gmail.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      f63e6d89
    • Michael Ellerman's avatar
      livepatch: Allow architectures to specify an alternate ftrace location · 28e7cbd3
      Michael Ellerman authored
      When livepatch tries to patch a function it takes the function address
      and asks ftrace to install the livepatch handler at that location.
      ftrace will look for an mcount call site at that exact address.
      
      On powerpc the mcount location is not the first instruction of the
      function, and in fact it's not at a constant offset from the start of
      the function. To accommodate this add a hook which arch code can
      override to customise the behaviour.
      Signed-off-by: default avatarTorsten Duwe <duwe@suse.de>
      Signed-off-by: default avatarBalbir Singh <bsingharora@gmail.com>
      Signed-off-by: default avatarPetr Mladek <pmladek@suse.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      28e7cbd3
    • Michael Ellerman's avatar
      ftrace: Make ftrace_location_range() global · 04cf31a7
      Michael Ellerman authored
      In order to support live patching on powerpc we would like to call
      ftrace_location_range(), so make it global.
      Signed-off-by: default avatarTorsten Duwe <duwe@suse.de>
      Signed-off-by: default avatarBalbir Singh <bsingharora@gmail.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      04cf31a7
  4. 12 Apr, 2016 5 commits
  5. 11 Apr, 2016 21 commits
  6. 10 Apr, 2016 1 commit
    • Linus Torvalds's avatar
      Revert "ext4: allow readdir()'s of large empty directories to be interrupted" · 9f2394c9
      Linus Torvalds authored
      This reverts commit 1028b55b.
      
      It's broken: it makes ext4 return an error at an invalid point, causing
      the readdir wrappers to write the the position of the last successful
      directory entry into the position field, which means that the next
      readdir will now return that last successful entry _again_.
      
      You can only return fatal errors (that terminate the readdir directory
      walk) from within the filesystem readdir functions, the "normal" errors
      (that happen when the readdir buffer fills up, for example) happen in
      the iterorator where we know the position of the actual failing entry.
      
      I do have a very different patch that does the "signal_pending()"
      handling inside the iterator function where it is allowable, but while
      that one passes all the sanity checks, I screwed up something like four
      times while emailing it out, so I'm not going to commit it today.
      
      So my track record is not good enough, and the stars will have to align
      better before that one gets committed.  And it would be good to get some
      review too, of course, since celestial alignments are always an iffy
      debugging model.
      
      IOW, let's just revert the commit that caused the problem for now.
      Reported-by: default avatarGreg Thelen <gthelen@google.com>
      Cc: Theodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9f2394c9
  7. 09 Apr, 2016 5 commits
    • Linus Torvalds's avatar
      Merge branch 'parisc-4.6-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux · 5b5b7fd1
      Linus Torvalds authored
      Pull parisc fixes from Helge Deller:
       "Since commit 0de79858 ("parisc: Use generic extable search and
        sort routines") module loading is boken on parisc, because the parisc
        module loader wasn't prepared for the new R_PARISC_PCREL32 relocations.
      
        In addition, due to that breakage, Mikulas Patocka noticed that
        handling exceptions from modules probably never worked on parisc.  It
        was just masked by the fact that exceptions from modules don't happen
        during normal use.
      
        This patch series fixes those issues and survives the tests of the
        lib/test_user_copy kernel module test.  Some patches are tagged for
        stable"
      
      * 'parisc-4.6-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
        parisc: Update comment regarding relative extable support
        parisc: Unbreak handling exceptions from kernel modules
        parisc: Fix kernel crash with reversed copy_from_user()
        parisc: Avoid function pointers for kernel exception routines
        parisc: Handle R_PARISC_PCREL32 relocations in kernel modules
      5b5b7fd1
    • Linus Torvalds's avatar
      Merge branch 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm · 239467e8
      Linus Torvalds authored
      Pull libnvdimm fixes from Dan Williams:
       "Three fixes, the first two are tagged for -stable:
      
         - The ndctl utility/library gained expanded unit tests illuminating a
           long standing bug in the libnvdimm SMART data retrieval
           implementation.
      
           It has been broken since its initial implementation, now fixed.
      
         - Another one line fix for the detection of stale info blocks.
      
           Without this change userspace can get into a situation where it is
           unable to reconfigure a namespace.
      
         - Fix the badblock initialization path in the presence of the new (in
           v4.6-rc1) section alignment workarounds.
      
           Without this change badblocks will be reported at the wrong offset.
      
        These have received a build success report from the kbuild robot and
        have appeared in -next with no reported issues"
      
      * 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
        libnvdimm, pfn: fix nvdimm_namespace_add_poison() vs section alignment
        libnvdimm, pfn: fix uuid validation
        libnvdimm: fix smart data retrieval
      239467e8
    • Linus Torvalds's avatar
      Merge tag 'gpio-v4.6-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio · 289b7bfd
      Linus Torvalds authored
      Pull GPIO fixes from Linus Walleij:
       "Here is a set of four GPIO fixes.  The two fixes to the core are
        serious as they are regressing minor architectures.
      
        Core fixes:
      
         - Defer GPIO device setup until after gpiolib is initialized.
      
           It turns out that a few very tightly integrated GPIO platform
           drivers initialize so early (befor core_initcall()) so that the
           gpiolib isn't even initialized itself.  That limits what the
           library can do, and we cannot reference uninitialized fields until
           later.
      
           Defer some of the initialization until right after the gpiolib is
           initialized in these (rare) cases.
      
         - As a consequence: do not use devm_* resources when allocating the
           states in the initial set-up of the gpiochip.
      
        Driver fixes:
      
         - In ACPI retrieveal: ignore GpioInt when looking for output GPIOs.
      
         - Fix legacy builds on the PXA without a backing pin controller.
      
         - Use correct datatype on pca953x register writes"
      
      * tag 'gpio-v4.6-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
        gpio: pca953x: Use correct u16 value for register word write
        gpiolib: Defer gpio device setup until after gpiolib initialization
        gpiolib: Do not use devm functions when registering gpio chip
        gpio: pxa: fix legacy non pinctrl aware builds
        gpio / ACPI: ignore GpioInt() GPIOs when requesting GPIO_OUT_*
      289b7bfd
    • Linus Torvalds's avatar
      Merge tag 'tty-4.6-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty · 183c948a
      Linus Torvalds authored
      Pull tty fixes from Greg KH:
       "Here are two tty fixes for issues found.
      
        One was due to a merge error in 4.6-rc1, and the other a regression
        fix for UML consoles that broke in 4.6-rc1.
      
        Both have been in linux-next for a while"
      
      * tag 'tty-4.6-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
        tty: Fix merge of "tty: Refactor tty_open()"
        tty: Fix UML console breakage
      183c948a
    • Linus Torvalds's avatar
      Merge tag 'usb-4.6-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb · ffb927d1
      Linus Torvalds authored
      Pull USB fixes from Greg KH:
       "Here are some USB fixes and new device ids for 4.6-rc3.
      
        Nothing major, the normal USB gadget fixes and usb-serial driver ids,
        along with some other fixes mixed in.  All except the USB serial ids
        have been tested in linux-next, the id additions should be fine as
        they are 'trivial'"
      
      * tag 'usb-4.6-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (25 commits)
        USB: option: add "D-Link DWM-221 B1" device id
        USB: serial: cp210x: Adding GE Healthcare Device ID
        USB: serial: ftdi_sio: Add support for ICP DAS I-756xU devices
        usb: dwc3: keystone: drop dma_mask configuration
        usb: gadget: udc-core: remove manual dma configuration
        usb: dwc3: pci: add ID for one more Intel Broxton platform
        usb: renesas_usbhs: fix to avoid using a disabled ep in usbhsg_queue_done()
        usb: dwc2: do not override forced dr_mode in gadget setup
        usb: gadget: f_midi: unlock on error
        USB: digi_acceleport: do sanity checking for the number of ports
        USB: cypress_m8: add endpoint sanity check
        USB: mct_u232: add sanity checking in probe
        usb: fix regression in SuperSpeed endpoint descriptor parsing
        USB: usbip: fix potential out-of-bounds write
        usb: renesas_usbhs: disable TX IRQ before starting TX DMAC transfer
        usb: renesas_usbhs: avoid NULL pointer derefernce in usbhsf_pkt_handler()
        usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize
        usb: phy: qcom-8x16: fix regulator API abuse
        usb: ch9: Fix SSP Device Cap wFunctionalitySupport type
        usb: gadget: composite: Access SSP Dev Cap fields properly
        ...
      ffb927d1