Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 27 11月, 2015 1 次提交
  3. 11 11月, 2015 2 次提交
    • 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
  5. 14 10月, 2015 10 次提交
  7. 11 9月, 2015 1 次提交
  9. 19 8月, 2015 1 次提交
  11. 01 7月, 2015 1 次提交
  13. 25 6月, 2015 1 次提交
    • I
      s390/zcrypt: Fixed reset and interrupt handling of AP queues · c50a160c
      由 Ingo Tuchscherer 提交于 
      In case of request timeouts an AP queue reset will be triggered to
recover and reinitialize the AP queue. The previous behavior was an
immediate reset execution regardless of current/pending requests.
Due to newly changed firmware behavior the reset may be delayed, based
on the priority of pending request. The device driver's waiting time
frame was limited, hence it did not received the reset response. As a
consequence interrupts would not be enabled afterwards.

The RAPQ (queue reset) and AQIC (interrupt control) commands will be
treated fully asynchronous now. The device driver will check the reset and
interrupt states periodically, thus it can handle the reinitialization
properly.
Signed-off-by: NIngo Tuchscherer <ingo.tuchscherer@linux.vnet.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      c50a160c
  15. 18 6月, 2015 1 次提交
  17. 13 5月, 2015 1 次提交
  19. 30 4月, 2015 1 次提交
  21. 25 3月, 2015 2 次提交
  23. 04 2月, 2015 1 次提交
  25. 23 1月, 2015 2 次提交
  27. 18 12月, 2014 1 次提交
    • H
      s390/zcrypt: kernel oops at insmod of the z90crypt device driver · 099eae11
      由 Harald Freudenberger 提交于 
      Kernel oops caused by invalid parameter at TAPQ instruction:
On older systems where the QCI instruction is not available
all possible domains are probed via TAPQ instruction. The
range for the probe has been extended with the > 16 domain
support now leading to a possible specification exception
when this instruction is called for probing higher values
within the new range. This may happen during insmod and/or
ap bus reset only on machines without a QCI instruction (z10,
z196, z114), zEC12 and newer systems are not affected.
The fix modifies the domain checking function to limit the
allowed range if no QCI info is available.
Signed-off-by: NHarald Freudenberger <freude@linux.vnet.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      099eae11
  29. 24 11月, 2014 1 次提交
  31. 09 10月, 2014 1 次提交
  33. 25 9月, 2014 2 次提交
  35. 16 7月, 2014 1 次提交
  37. 11 6月, 2014 1 次提交
  39. 10 6月, 2014 1 次提交
  41. 18 4月, 2014 1 次提交
  43. 01 4月, 2014 1 次提交
  45. 12 2月, 2014 1 次提交
  47. 16 1月, 2014 1 次提交
  49. 19 12月, 2013 1 次提交
  51. 24 10月, 2013 1 次提交
  53. 07 9月, 2013 1 次提交
    • H
      s390/ap_bus: use and-mask instead of a cast · 7d6c3b49
      由 Heiko Carstens 提交于 
      Let's get rid of another sparse false positive:

drivers/s390/crypto/ap_bus.c:416:64: warning:
  cast truncates bits from constant value (102030405060708 becomes 5060708)

So instead of using a cast let's use an and-mask.
That way sparse remains silent and one doesn't always have to check
if this is a valid warning/bug or just a false positive.
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      7d6c3b49