1. 31 1月, 2017 9 次提交
  2. 27 1月, 2017 2 次提交
  3. 25 1月, 2017 6 次提交
  4. 20 1月, 2017 2 次提交
  5. 19 1月, 2017 2 次提交
    • A
      lkdtm: hide stack overflow warning for corrupt-stack test · 7a11a1d1
      Arnd Bergmann 提交于
      After the latest change to make sure the compiler actually does a memset,
      it is now smart enough to flag the stack overflow at compile time,
      at least with gcc-7.0:
      
      drivers/misc/lkdtm_bugs.c: In function 'lkdtm_CORRUPT_STACK':
      drivers/misc/lkdtm_bugs.c:88:144: warning: 'memset' writing 64 bytes into a region of size 8 overflows the destination [-Wstringop-overflow=]
      
      To outsmart the compiler again, this moves the memset into a noinline
      function where (for now) it doesn't see that we intentionally write
      broken code here.
      
      Fixes: c55d2400 ("lkdtm: Prevent the compiler from optimising lkdtm_CORRUPT_STACK()")
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7a11a1d1
    • S
      eeprom: Add IDT 89HPESx EEPROM/CSR driver · cfad6425
      Serge Semin 提交于
        This driver provides an access to EEPROM of IDT PCIe-switches. IDT PCIe-
      switches expose a simple SMBus interface to perform IO-operations from/to
      EEPROM, which is located at private (so called Master) SMBus. The driver
      creates a simple binary sysfs-file to have an access to the EEPROM using
      the SMBus-slave interface in the i2c-device susfs-directory:
           /sys/bus/i2c/devices/<bus>-<devaddr>/eeprom
      In case if read-only flag is specified at dts-node of the device, User-space
      applications won't be able to write to the EEPROM sysfs-node.
      
        Additionally IDT 89HPESx SMBus interface has an ability to read/write
      values of device CSRs. This driver exposes debugfs-file to perform simple
      IO-operations using that ability for just basic debug purpose. Particularly
      the next file is created in the specific debugfs-directory:
           /sys/kernel/debug/idt_csr/
      Format of the debugfs-file value is:
           $ cat /sys/kernel/debug/idt_csr/<bus>-<devaddr>/<devname>;
           <CSR address>:<CSR value>
      So reading the content of the file gives current CSR address and it value.
      If User-space application wishes to change current CSR address, it can just
      write a proper value to the sysfs-file:
           $ echo "<CSR address>" >
               /sys/kernel/debug/idt_csr/<bus>-<devaddr>/<devname>
      If it wants to change the CSR value as well, the format of the write
      operation is:
           $ echo "<CSR address>:<CSR value>" > \
               /sys/kernel/debug/idt_csr/<bus>-<devaddr>/<devname>;
      CSR address and value can be any of hexadecimal, decimal or octal format.
      Signed-off-by: NSerge Semin <fancer.lancer@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cfad6425
  6. 11 1月, 2017 4 次提交
  7. 05 1月, 2017 2 次提交
  8. 25 12月, 2016 1 次提交
  9. 15 12月, 2016 1 次提交
  10. 14 12月, 2016 1 次提交
  11. 06 12月, 2016 3 次提交
  12. 30 11月, 2016 3 次提交
  13. 25 11月, 2016 1 次提交
  14. 23 11月, 2016 1 次提交
  15. 18 11月, 2016 2 次提交
    • F
      cxl: Fix coredump generation when cxl_get_fd() is used · bdecf76e
      Frederic Barrat 提交于
      If a process dumps core while owning a cxl file descriptor obtained
      from an AFU driver (e.g. cxlflash) through the cxl_get_fd() API, the
      following error occurs:
      
        [  868.027591] Unable to handle kernel paging request for data at address ...
        [  868.027778] Faulting instruction address: 0xc00000000035edb0
        cpu 0x8c: Vector: 300 (Data Access) at [c000003c688275e0]
            pc: c00000000035edb0: elf_core_dump+0xd60/0x1300
            lr: c00000000035ed80: elf_core_dump+0xd30/0x1300
            sp: c000003c68827860
           msr: 9000000100009033
           dar: c
        dsisr: 40000000
         current = 0xc000003c68780000
         paca    = 0xc000000001b73200   softe: 0        irq_happened: 0x01
            pid   = 46725, comm = hxesurelock
        enter ? for help
        [c000003c68827a60] c00000000036948c do_coredump+0xcec/0x11e0
        [c000003c68827c20] c0000000000ce9e0 get_signal+0x540/0x7b0
        [c000003c68827d10] c000000000017354 do_signal+0x54/0x2b0
        [c000003c68827e00] c00000000001777c do_notify_resume+0xbc/0xd0
        [c000003c68827e30] c000000000009838 ret_from_except_lite+0x64/0x68
        --- Exception: 300 (Data Access) at 00003fff98ad2918
      
      The root cause is that the address_space structure for the file
      doesn't define a 'host' member.
      
      When cxl allocates a file descriptor, it's using the anonymous inode
      to back the file, but allocates a private address_space for each
      context. The private address_space allows to track memory allocation
      for each context. cxl doesn't define the 'host' member of the address
      space, i.e. the inode. We don't want to define it as the anonymous
      inode, since there's no longer a 1-to-1 relation between address_space
      and inode.
      
      To fix it, instead of using the anonymous inode, we introduce a simple
      pseudo filesystem so that cxl can allocate its own inodes. So we now
      have one inode for each file and address_space. The pseudo filesystem
      is only mounted on the first allocation of a file descriptor by
      cxl_get_fd().
      
      Tested with cxlflash.
      Signed-off-by: NFrederic Barrat <fbarrat@linux.vnet.ibm.com>
      Reviewed-by: NMatthew R. Ochs <mrochs@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      bdecf76e
    • V
      cxl: Do adapter fence check before handling afu interrupt · abf051be
      Vaibhav Jain 提交于
      If an afu interrupt is in flight when an eeh error is triggered the
      control still reaches the function native_irq_multiplexed and the
      PE-Handle read from the CXL_PSL_PEHandle_An register is 0xffff. The
      function then erroneously assumes that the interrupt belonged to a
      detached context and generates a warning with full stack dump in the
      kernel log complaining:
      
      "Unable to demultiplex CXL PSL IRQ for PE 65535 DSISR ffffffff DAR
      ffffffff. (Possible AFU HW issue - was a term/remove acked with
      outstanding transactions"
      
      To fix this the patch adds new code to the function
      native_irq_multiplexed function to compares the read value of register
      CXL_PSL_PEHandle_An to ~0ULL. If true then logs a warning message
      saying that the interrupt is being ignored and returns IRQ_HANDLED from
      the irq handler.
      Reviewed-by: NAndrew Donnellan <andrew.donnellan@au1.ibm.com>
      Acked-by: NFrederic Barrat <fbarrat@linux.vnet.ibm.com>
      Acked-by: NIan Munsie <imunsie@au1.ibm.com>
      Signed-off-by: NVaibhav Jain <vaibhav@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      abf051be