1. 15 12月, 2015 2 次提交
  2. 11 11月, 2015 3 次提交
    • S
      s390/zcrypt: Fix initialisation when zcrypt is built-in · 121a868d
      Sascha Silbe 提交于
      ap_bus and zcrypt_api assumed module information to always be present
      and initialisation to be done in module loading order (symbol
      dependencies). These assumptions don't hold if zcrypt is built-in;
      THIS_MODULE will be NULL in this case and init call order is linker
      order, i.e. Makefile order.
      
      Fix initialisation order by ordering the object files in the Makefile
      according to their dependencies, like the module loader would do.
      
      Fix message type registration by using a dedicated "name" field rather
      than piggy-backing on the module ("owner") information. There's no
      change to the requirement that module name and msgtype name are
      identical. The existing name macros are used.
      
      We don't need any special code for dealing with the drivers being
      built-in; the generic module support code already does the right
      thing.
      
      Test results:
      1. CONFIG_MODULES=y, CONFIG_ZCRYPT=y
      
         KVM: boots, no /sys/bus/ap (expected)
         LPAR with CEX5: boots, /sys/bus/ap/devices/card*/type present
      
      2. CONFIG_MODULES=y, CONFIG_ZCRYPT=m=:
      
         KVM: boots, loading zcrypt_cex4 (and ap) fails (expected)
         LPAR with CEX5: boots, loading =zcrypt_cex4= succeeds,
         /sys/bus/ap/devices/card*/type present after explicit module
         loading
      
      3. CONFIG_MODULES unset, CONFIG_ZCRYPT=y:
         KVM: boots, no /sys/bus/ap (expected)
         LPAR with CEX5: boots, /sys/bus/ap/devices/card*/type present
      
      No further testing (user-space functionality) was done.
      
      Fixes: 3b6245fd303f ("s390/zcrypt: Separate msgtype implementation from card modules.")
      Signed-off-by: NSascha Silbe <silbe@linux.vnet.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      121a868d
    • S
      s390/zcrypt: Fix kernel crash on systems without AP bus support · e387753c
      Sascha Silbe 提交于
      On systems without AP bus (e.g. KVM) the kernel crashes during init
      calls when zcrypt is built-in:
      
      kernel BUG at drivers/base/driver.c:153!
      illegal operation: 0001 ilc:1 [#1] SMP
      Modules linked in:
      CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.2.0+ #221
      task: 0000000010a40000 ti: 0000000010a48000 task.ti:0000000010a48000
      Krnl PSW : 0704c00180000000 0000000000592bd6(driver_register+0x106/0x140)
                 R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3
                 0000000000000012 0000000000000000 0000000000c45328 0000000000c44e30
                 00000000009ef63c 000000000067f598 0000000000cf3c58 0000000000000000
                 000000000000007b 0000000000cb1030 0000000000000002 0000000000000000
                 0000000000ca8580 0000000010306700 00000000001001d8 0000000010a4bd88
      Krnl Code: 0000000000592bc6: f0b00004ebcf	srp 4(12,%r0),3023(%r14),0
                 0000000000592bcc: f0a0000407f4       srp     4(11,%r0),2036,0
                #0000000000592bd2: a7f40001           brc     15,592bd4
                >0000000000592bd6: e330d0000004       lg      %r3,0(%r13)
                 0000000000592bdc: c0200021edfd       larl    %r2,9d07d6
                 0000000000592be2: c0e500126d8f       brasl   %r14,7e0700
                 0000000000592be8: e330d0080004       lg      %r3,8(%r13)
                 0000000000592bee: a7f4ffab           brc     15,592b44
      Call Trace:
      ([<00000000001001c8>] do_one_initcall+0x90/0x1d0)
       [<0000000000c6dd34>] kernel_init_freeable+0x1e4/0x2a0
       [<00000000007db53a>] kernel_init+0x2a/0x120
       [<00000000007e8ece>] kernel_thread_starter+0x6/0xc
       [<00000000007e8ec8>] kernel_thread_starter+0x0/0xc
      Last Breaking-Event-Address:
       [<0000000000592bd2>] driver_register+0x102/0x140
      
      When zcrypt is built as a module, the module loader ensures that the
      driver modules cannot be loaded if the AP bus module returns an error
      during initialisation. But if zcrypt and the driver are built-in, the
      driver is getting initialised even if the AP bus initialisation
      failed. The driver invokes ap_driver_register() during initialisation,
      which then causes operations on uninitialised data structures to be
      performed.
      
      Explicitly protect ap_driver_register() by introducing an
      "initialised" flag that gets set iff the AP bus initialisation was
      successful. When the AP bus initialisation failed,
      ap_driver_register() will error out with -ENODEV, causing the driver
      initialisation to fail as well.
      
      Test results:
      1. Inside KVM (no AP bus), zcrypt built-in
      
         Boots. /sys/bus/ap not present (expected).
      
      2. Inside KVM (no AP bus), zcrypt as module
      
         Boots. Loading zcrypt_cex4 fails because loading ap_bus fails
         (expected).
      
      3. On LPAR with CEX5, zcrypt built-in
      
         Boots. /sys/bus/ap/devices/card* present but .../card*/type missing
         (i.e. zcrypt_device_register() fails, unrelated issue).
      
      4. On LPAR with CEX5, zcrypt as module
      
         Boots. Loading zcrypt_cex4 successful,
         /sys/bus/ap/devices/card*/type present. No further testing
         (user-space functionality) was done.
      Signed-off-by: NSascha Silbe <silbe@linux.vnet.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      e387753c
    • S
      s390: add support for ipl devices in subchannel sets > 0 · 18e22a17
      Sebastian Ott 提交于
      Allow to ipl from CCW based devices residing in any subchannel set.
      Reviewed-by: NMichael Holzheu <holzheu@linux.vnet.ibm.com>
      Signed-off-by: NSebastian Ott <sebott@linux.vnet.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      18e22a17
  3. 09 11月, 2015 1 次提交
  4. 08 11月, 2015 1 次提交
  5. 03 11月, 2015 5 次提交
  6. 27 10月, 2015 3 次提交
  7. 15 10月, 2015 1 次提交
    • S
      s390/dasd: fix list_del corruption after lcu changes · 6933c35a
      Stefan Haberland 提交于
      A summary unit check occurs when the lcu updates the PAV configuration
      e.g. base PAV assignment or PAV mode at all. This requires the reset
      of the drivers internal pavgroups. Therefore the alias devices are
      flushed and moved via a temporary list to the active_devices list
      where they are not associated with a pavgroup. In conjunction with
      updates to the base device the pavgroup may be removed since both
      base_list and alias_list are empty. Unfortunately during alias flush
      and move to the active_device list from alias_list the pavgroup
      pointer is not deleted in the device private structure. This leads to
      a list del_corruption if another lcu_update tries to move the device
      in the non existent pavgroup.
      
      Fix by removing the pavgroup pointer after the alias device was moved
      to the active_devices list.
      Signed-off-by: NStefan Haberland <stefan.haberland@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      6933c35a
  8. 14 10月, 2015 21 次提交
  9. 07 10月, 2015 3 次提交