Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 20 7月, 2021 2 次提交
  3. 08 7月, 2021 1 次提交
    • H
      s390/ap: Rework ap_dqap to deal with messages greater than recv buffer · 1f0d22de
      由 Harald Freudenberger 提交于 
      Rework of the ap_dqap() inline function with the dqap inline assembler
invocation and the caller code in ap_queue.c to be able to handle
replies which exceed the receive buffer size.

ap_dqap() now provides two additional parameters to handle together
with the caller the case where a reply in the firmware queue entry
exceeds the given message buffer size. It depends on the caller how to
exactly handle this. The behavior implemented now by ap_sm_recv() in
ap_queue.c is to simple purge this entry from the firmware queue and
let the caller 'receive' a -EMSGSIZE for the request without
delivering any reply data - not even a truncated reply message.

However, the reworked ap_dqap() could now get invoked in a way that
the message is received in multiple parts and the caller assembles the
parts into one reply message.
Signed-off-by: NHarald Freudenberger <freude@linux.ibm.com>
Suggested-by: NJuergen Christ <jchrist@linux.ibm.com>
Reviewed-by: NJuergen Christ <jchrist@linux.ibm.com>
Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>
      1f0d22de
  5. 05 7月, 2021 1 次提交
    • H
      s390/AP: support new dynamic AP bus size limit · bd39654a
      由 Harald Freudenberger 提交于 
      This patch provides support for new dynamic AP bus message limit
with the existing zcrypt device driver and AP bus core code.

There is support for a new field 'ml' from TAPQ query. The field
gives if != 0 the AP bus limit for this card in 4k chunk units.
The actual message size limit per card is shown as a new read-only
sysfs attribute. The sysfs attribute

  /sys/devices/ap/cardxx/max_msg_size

shows the upper limit in bytes used by the AP bus and zcrypt device
driver for requests and replies send to and received from this card.
Currently up to CEX7 support only max 12kB msg size and thus the field
shows 12288 meaning the upper limit of a valid msg for this card is
12kB. Please note that the usable payload is somewhat lower and
depends on the msg type and thus the header struct which is to be
prepended by the zcrypt dd.

The dispatcher responsible for choosing the right card and queue is
aware of the individual card AP bus message limit. So a request is
only assigned to a queue of a card which is able to handle the size of
the request (e.g. a 14kB request will never go to a max 12kB card).
If no such card is found the ioctl will fail with ENODEV.

The reply buffer held by the device driver is determined by the ml
field of the TAPQ for this card. If a response from the card exceeds
this limit however, the response is not truncated but the ioctl for
this request will fail with errno EMSGSIZE to indicate that the device
driver has dropped the response because it would overflow the buffer
limit.

If the request size does not indicate to the dispatcher that an
adapter with extended limit is to be used, a random card will be
chosen when no specific card is addressed (ANY addressing). This may
result in an ioctl failure when the reply size needs an adapter with
extended limit but the randomly chosen one is not capable of handling
the broader reply size. The user space application needs to use
dedicated addressing to forward such a request only to suitable cards
to get requests like this processed properly.
Signed-off-by: NHarald Freudenberger <freude@linux.ibm.com>
Reviewed-by: NIngo Tuchscherer <ingo.tuchscherer@linux.ibm.com>
Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>
      bd39654a
  7. 02 7月, 2021 1 次提交
  9. 01 7月, 2021 2 次提交
  11. 28 6月, 2021 7 次提交
  13. 25 6月, 2021 1 次提交
  15. 21 6月, 2021 1 次提交
  17. 18 6月, 2021 12 次提交
  19. 17 6月, 2021 2 次提交
    • H
      s390/ap/zcrypt: notify userspace with online, config and mode info · df6f508c
      由 Harald Freudenberger 提交于 
      This patch brings 3 reworked/new uevent changes:
* All AP uevents caused by an ap card or queue device now carry an
  additional uevent env value MODE=<accel|cca|ep11>. Here is an
  example:
    KERNEL[1267.301292] add	 /devices/ap/card0a (ap)
    ACTION=add
    DEVPATH=/devices/ap/card0a
    SUBSYSTEM=ap
    DEVTYPE=ap_card
    DEV_TYPE=000D
    MODALIAS=ap:t0D
    MODE=ep11			 <- this is new
    SEQNUM=1095
  This is true for bind, unbind, add, remove, and change uevents
  related to ap card or ap queue devices.
* On a change of the soft online attribute on a zcrypt queue or card
  device a new CHANGE uevent is sent with an env value ONLINE=<0|1>.
  Example uevent:
    KERNEL[613.067531] change	/devices/ap/card09/09.0011 (ap)
    ACTION=change
    DEVPATH=/devices/ap/card09/09.0011
    SUBSYSTEM=ap
    ONLINE=0			<- this is new
    DEVTYPE=ap_queue
    DRIVER=cex4queue
    MODE=cca
    SEQNUM=1070
- On a change of the config state of an zcrypt card device a new
  CHANGE uevent is sent with an env value CONFIG=<0|1>.
  Example uevent:
    KERNEL[876.258680] change	/devices/ap/card09 (ap)
    ACTION=change
    DEVPATH=/devices/ap/card09
    SUBSYSTEM=ap
    CONFIG=0			<- this is new
    DEVTYPE=ap_card
    DRIVER=cex4card
    DEV_TYPE=000D
    MODALIAS=ap:t0D
    MODE=cca
    SEQNUM=1073
  Setting a card config on/off causes the dependent queue devices to
  follow the config state change and thus uevents informing about the
  config state change for the queue devices are also emitted.
Signed-off-by: NHarald Freudenberger <freude@linux.ibm.com>
Reviewed-by: NIngo Franzki <ifranzki@linux.ibm.com>
Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>
      df6f508c
    • H
      s390/ap: Fix hanging ioctl caused by wrong msg counter · e73a99f3
      由 Harald Freudenberger 提交于 
      When a AP queue is switched to soft offline, all pending
requests are purged out of the pending requests list and
'received' by the upper layer like zcrypt device drivers.
This is also done for requests which are already enqueued
into the firmware queue. A request in a firmware queue
may eventually produce an response message, but there is
no waiting process any more. However, the response was
counted with the queue_counter and as this counter was
reset to 0 with the offline switch, the pending response
caused the queue_counter to get negative. The next request
increased this counter to 0 (instead of 1) which caused
the ap code to assume there is nothing to receive and so
the response for this valid request was never tried to
fetch from the firmware queue.

This all caused a queue to not work properly after a
switch offline/online and in the end processes to hang
forever when trying to send a crypto request after an
queue offline/online switch cicle.

Fixed by a) making sure the counter does not drop below 0
and b) on a successful enqueue of a message has at least
a value of 1.

Additionally a warning is emitted, when a reply can't get
assigned to a waiting process. This may be normal operation
(process had timeout or has been killed) but may give a
hint that something unexpected happened (like this odd
behavior described above).
Signed-off-by: NHarald Freudenberger <freude@linux.ibm.com>
Cc: stable@vger.kernel.org
Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>
      e73a99f3
  21. 13 6月, 2021 1 次提交
  23. 12 6月, 2021 9 次提交