5.18.15-rc1 review
Subsystems (2)
Greg Kroah-Hartman
maintainerPATCH 143/158 crypto: qat - add backlog mechanism
In reply to Greg Kroah-HartmanFrom: Giovanni Cabiddu <[email protected]>
[ Upstream commit 38682383973280e5be2802ba8a8d4a636d36cb19 ]
The implementations of the crypto algorithms (aead, skcipher, etc) in the QAT driver do not properly support requests with the CRYPTO_TFM_REQ_MAY_BACKLOG flag set. If the HW queue is full, the driver returns -EBUSY but does not enqueue the request. This can result in applications like dm-crypt waiting indefinitely for the completion of a request that was never submitted to the hardware.
Fix this by adding a software backlog queue: if the ring buffer is more than eighty percent full, then the request is enqueued to a backlog list and the error code -EBUSY is returned back to the caller. Requests in the backlog queue are resubmitted at a later time, in the context of the callback of a previously submitted request. The request for which -EBUSY is returned is then marked as -EINPROGRESS once submitted to the HW queues.
The submission loop inside the function qat_alg_send_message() has been modified to decide which submission policy to use based on the request flags. If the request does not have the CRYPTO_TFM_REQ_MAY_BACKLOG set, the previous behaviour has been preserved.
Based on a patch by
Vishnu Das Ramachandran <[email protected]>
--- drivers/crypto/qat/qat_common/adf_transport.c | 11 +++ drivers/crypto/qat/qat_common/adf_transport.h | 1 + .../qat/qat_common/adf_transport_internal.h | 1 + drivers/crypto/qat/qat_common/qat_algs.c | 24 ++++--- drivers/crypto/qat/qat_common/qat_algs_send.c | 67 ++++++++++++++++++- drivers/crypto/qat/qat_common/qat_algs_send.h | 1 + drivers/crypto/qat/qat_common/qat_asym_algs.c | 23 ++++--- drivers/crypto/qat/qat_common/qat_crypto.c | 3 + drivers/crypto/qat/qat_common/qat_crypto.h | 10 +++ 9 files changed, 123 insertions(+), 18 deletions(-)
drivers/crypto/qat/qat_common/adf_transport.c +11 -0
@@ -8,6 +8,9 @@#include "adf_cfg.h" #include "adf_common_drv.h" +#define ADF_MAX_RING_THRESHOLD 80 +#define ADF_PERCENT (tot, percent) (((tot) * (percent)) / 100) +static inline u32 adf_modulo (u32 data,u32 shift) {u32 div = data >> shift;
@@ -77,6 +80,11 @@ static void adf_disable_ring_irq(struct adf_etr_bank_data *bank, u32 ring) bank->irq_mask); } +bool adf_ring_nearly_full (struct adf_etr_ring_data *ring) +{ +return atomic_read (ring->inflights) > ring->threshold; +} +int adf_send_message (struct adf_etr_ring_data *ring,u32 *msg) {struct adf_hw_csr_ops *csr_ops =GET_CSR_OPS (ring->bank->accel_dev);
@@ -217,6 +225,7 @@ int adf_create_ring(struct adf_accel_dev *accel_dev, const char *section,struct adf_etr_bank_data *bank;struct adf_etr_ring_data *ring;char val[ADF_CFG_MAX_VAL_LEN_IN_BYTES ]; +int max_inflights;u32 ring_num;int ret;
@@ -263,6 +272,8 @@ int adf_create_ring(struct adf_accel_dev *accel_dev, const char *section, ring->ring_size =adf_verify_ring_size (msg_size, num_msgs); ring->head =0 ; ring->tail =0 ; + max_inflights =ADF_MAX_INFLIGHTS (ring->ring_size, ring->msg_size); + ring->threshold =ADF_PERCENT (max_inflights,ADF_MAX_RING_THRESHOLD );atomic_set (ring->inflights,0 ); ret =adf_init_ring (ring);if (ret)
drivers/crypto/qat/qat_common/adf_transport.h +1 -0
@@ -14,6 +14,7 @@ int adf_create_ring(struct adf_accel_dev *accel_dev, const char *section, const char *ring_name, adf_callback_fn callback, int poll_mode, struct adf_etr_ring_data **ring_ptr); +bool adf_ring_nearly_full (struct adf_etr_ring_data *ring);int adf_send_message (struct adf_etr_ring_data *ring,u32 *msg);void adf_remove_ring (struct adf_etr_ring_data *ring);#endif
drivers/crypto/qat/qat_common/adf_transport_internal.h +1 -0
@@ -22,6 +22,7 @@ struct adf_etr_ring_data {spinlock_t lock;/* protects ring data struct */ u16 head;u16 tail; +u32 threshold;u8 ring_number;u8 ring_size;u8 msg_size;
drivers/crypto/qat/qat_common/qat_algs.c +15 -9
@@ -935,19 +935,25 @@ void qat_alg_callback(void *resp)struct icp_qat_fw_la_resp *qat_resp = resp;struct qat_crypto_request *qat_req = (void *)(__force long )qat_resp->opaque_data; +struct qat_instance_backlog *backlog = qat_req->alg_req.backlog; qat_req->cb (qat_resp, qat_req); + +qat_alg_send_backlog (backlog); }static int qat_alg_send_sym_message (struct qat_crypto_request *qat_req, -struct qat_crypto_instance *inst) +struct qat_crypto_instance *inst, +struct crypto_async_request *base) { -struct qat_alg_req req; +struct qat_alg_req *alg_req = &qat_req->alg_req; - req.fw_req = (u32 *)&qat_req->req; - req.tx_ring = inst->sym_tx; + alg_req->fw_req = (u32 *)&qat_req->req; + alg_req->tx_ring = inst->sym_tx; + alg_req->base = base; + alg_req->backlog = &inst->backlog; -return qat_alg_send_message (&req); +return qat_alg_send_message (alg_req); }static int qat_alg_aead_dec (struct aead_request *areq)
@@ -987,7 +993,7 @@ static int qat_alg_aead_dec(struct aead_request *areq) auth_param->auth_off =0 ; auth_param->auth_len = areq->assoclen + cipher_param->cipher_length; - ret =qat_alg_send_sym_message (qat_req, ctx->inst); + ret =qat_alg_send_sym_message (qat_req, ctx->inst, &areq->base);if (ret == -ENOSPC )qat_alg_free_bufl (ctx->inst, qat_req);
@@ -1031,7 +1037,7 @@ static int qat_alg_aead_enc(struct aead_request *areq) auth_param->auth_off =0 ; auth_param->auth_len = areq->assoclen + areq->cryptlen; - ret =qat_alg_send_sym_message (qat_req, ctx->inst); + ret =qat_alg_send_sym_message (qat_req, ctx->inst, &areq->base);if (ret == -ENOSPC )qat_alg_free_bufl (ctx->inst, qat_req);
@@ -1212,7 +1218,7 @@ static int qat_alg_skcipher_encrypt(struct skcipher_request *req)qat_alg_set_req_iv (qat_req); - ret =qat_alg_send_sym_message (qat_req, ctx->inst); + ret =qat_alg_send_sym_message (qat_req, ctx->inst, &req->base);if (ret == -ENOSPC )qat_alg_free_bufl (ctx->inst, qat_req);
@@ -1278,7 +1284,7 @@ static int qat_alg_skcipher_decrypt(struct skcipher_request *req)qat_alg_set_req_iv (qat_req);qat_alg_update_iv (qat_req); - ret =qat_alg_send_sym_message (qat_req, ctx->inst); + ret =qat_alg_send_sym_message (qat_req, ctx->inst, &req->base);if (ret == -ENOSPC )qat_alg_free_bufl (ctx->inst, qat_req);
drivers/crypto/qat/qat_common/qat_algs_send.c +66 -1
76 lines not on this page · raw message
drivers/crypto/qat/qat_common/qat_algs_send.h +1 -0
@@ -6,5 +6,6 @@#include "qat_crypto.h" int qat_alg_send_message (struct qat_alg_req *req); +void qat_alg_send_backlog (struct qat_instance_backlog *backlog);#endif
drivers/crypto/qat/qat_common/qat_asym_algs.c +15 -8
@@ -136,17 +136,21 @@ struct qat_asym_request { } areq;int err;void (*cb)(struct icp_qat_fw_pke_resp *resp); +struct qat_alg_req alg_req; }__aligned(64) ;static int qat_alg_send_asym_message (struct qat_asym_request *qat_req, -struct qat_crypto_instance *inst) +struct qat_crypto_instance *inst, +struct crypto_async_request *base) { -struct qat_alg_req req; +struct qat_alg_req *alg_req = &qat_req->alg_req; - req.fw_req = (u32 *)&qat_req->req; - req.tx_ring = inst->pke_tx; + alg_req->fw_req = (u32 *)&qat_req->req; + alg_req->tx_ring = inst->pke_tx; + alg_req->base = base; + alg_req->backlog = &inst->backlog; -return qat_alg_send_message (&req); +return qat_alg_send_message (alg_req); }static void qat_dh_cb (struct icp_qat_fw_pke_resp *resp)
@@ -350,7 +354,7 @@ static int qat_dh_compute_value(struct kpp_request *req) msg->input_param_count = n_input_params; msg->output_param_count =1 ; - ret =qat_alg_send_asym_message (qat_req, ctx->inst); + ret =qat_alg_send_asym_message (qat_req, inst, &req->base);if (ret == -ENOSPC ) goto unmap_all;
@@ -557,8 +561,11 @@ void qat_alg_asym_callback(void *_resp) {struct icp_qat_fw_pke_resp *resp = _resp;struct qat_asym_request *areq = (void *)(__force long )resp->opaque; +struct qat_instance_backlog *backlog = areq->alg_req.backlog; areq->cb (resp); + +qat_alg_send_backlog (backlog); }#define PKE_RSA_EP_512 0x1c161b21
@@ -748,7 +755,7 @@ static int qat_rsa_enc(struct akcipher_request *req) msg->input_param_count =3 ; msg->output_param_count =1 ; - ret =qat_alg_send_asym_message (qat_req, ctx->inst); + ret =qat_alg_send_asym_message (qat_req, inst, &req->base);if (ret == -ENOSPC ) goto unmap_all;
@@ -901,7 +908,7 @@ static int qat_rsa_dec(struct akcipher_request *req) msg->output_param_count =1 ; - ret =qat_alg_send_asym_message (qat_req, ctx->inst); + ret =qat_alg_send_asym_message (qat_req, inst, &req->base);if (ret == -ENOSPC ) goto unmap_all;
drivers/crypto/qat/qat_common/qat_crypto.c +3 -0
@@ -353,6 +353,9 @@ static int qat_crypto_create_instances(struct adf_accel_dev *accel_dev) &inst->pke_rx);if (ret) goto err; + +INIT_LIST_HEAD (&inst->backlog.list); +spin_lock_init (&inst->backlog.lock); }return 0 ; err:
drivers/crypto/qat/qat_common/qat_crypto.h +10 -0
@@ -9,9 +9,17 @@#include "adf_accel_devices.h" #include "icp_qat_fw_la.h" +struct qat_instance_backlog { +struct list_head list; +spinlock_t lock;/* protects backlog list */ +}; +struct qat_alg_req {u32 *fw_req;struct adf_etr_ring_data *tx_ring; +struct crypto_async_request *base; +struct list_head list; +struct qat_instance_backlog *backlog; };struct qat_crypto_instance {
@@ -24,6 +32,7 @@ struct qat_crypto_instance {unsigned long state;int id;atomic_t refctr; +struct qat_instance_backlog backlog; };#define QAT_MAX_BUFF_DESC 4
@@ -82,6 +91,7 @@ struct qat_crypto_request {u8 iv[AES_BLOCK_SIZE ]; };bool encryption; +struct qat_alg_req alg_req; };static inline bool adf_hw_dev_has_crypto (struct adf_accel_dev *accel_dev)
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 144/158 crypto: qat - fix memory leak in RSA
In reply to Greg Kroah-HartmanFrom: Giovanni Cabiddu <[email protected]>
[ Upstream commit 80a52e1ee7757b742f96bfb0d58f0c14eb6583d0 ]
When an RSA key represented in form 2 (as defined in PKCS #1 V2.1) is used, some components of the private key persist even after the TFM is released.
Replace the explicit calls to free the buffers in qat_rsa_exit_tfm() with a call to qat_rsa_clear_ctx() which frees all buffers referenced in the TFM context.
--- drivers/crypto/qat/qat_common/qat_asym_algs.c | 12 +----------- 1 file changed, 1 insertion(+), 11 deletions(-)
drivers/crypto/qat/qat_common/qat_asym_algs.c +1 -11
@@ -1257,18 +1257,8 @@ static void qat_rsa_exit_tfm(struct crypto_akcipher *tfm)struct qat_rsa_ctx *ctx =akcipher_tfm_ctx (tfm);struct device *dev = &GET_DEV (ctx->inst->accel_dev); -if (ctx->n) -dma_free_coherent (dev, ctx->key_sz, ctx->n, ctx->dma_n); -if (ctx->e) -dma_free_coherent (dev, ctx->key_sz, ctx->e, ctx->dma_e); -if (ctx->d) { -memset (ctx->d,'\0' , ctx->key_sz); -dma_free_coherent (dev, ctx->key_sz, ctx->d, ctx->dma_d); - } +qat_rsa_clear_ctx (dev, ctx);qat_crypto_put_instance (ctx->inst); - ctx->n =NULL ; - ctx->e =NULL ; - ctx->d =NULL ; }static struct akcipher_alg rsa = {
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 145/158 crypto: qat - remove dma_free_coherent() for RSA
In reply to Greg Kroah-HartmanFrom: Giovanni Cabiddu <[email protected]>
[ Upstream commit 3dfaf0071ed74d7a9c6b3c9ea4df7a6f8e423c2a ]
After commit f5ff79fddf0e ("dma-mapping: remove CONFIG_DMA_REMAP"), if the algorithms are enabled, the driver crashes with a BUG_ON while executing vunmap() in the context of a tasklet. This is due to the fact that the function dma_free_coherent() cannot be called in an interrupt context (see Documentation/core-api/dma-api-howto.rst).
The functions qat_rsa_enc() and qat_rsa_dec() allocate memory with dma_alloc_coherent() if the source or the destination buffers are made of multiple flat buffers or of a size that is not compatible with the hardware.
This memory is then freed with dma_free_coherent() in the context of a tasklet invoked to handle the response for the corresponding request.
Replace allocations with dma_alloc_coherent() in the functions qat_rsa_enc() and qat_rsa_dec() with kmalloc() + dma_map_single().
--- drivers/crypto/qat/qat_common/qat_asym_algs.c | 137 ++++++++---------- 1 file changed, 60 insertions(+), 77 deletions(-)
drivers/crypto/qat/qat_common/qat_asym_algs.c +60 -77
@@ -529,25 +529,22 @@ static void qat_rsa_cb(struct icp_qat_fw_pke_resp *resp) err = (err ==ICP_QAT_FW_COMN_STATUS_FLAG_OK ) ?0 : -EINVAL ; -if (req->src_align) -dma_free_coherent (dev, req->ctx.rsa->key_sz, req->src_align, - req->in.rsa.enc.m); -else -dma_unmap_single (dev, req->in.rsa.enc.m, req->ctx.rsa->key_sz, -DMA_TO_DEVICE ); +kfree_sensitive (req->src_align); + +dma_unmap_single (dev, req->in.rsa.enc.m, req->ctx.rsa->key_sz, +DMA_TO_DEVICE ); areq->dst_len = req->ctx.rsa->key_sz;if (req->dst_align) {scatterwalk_map_and_copy (req->dst_align, areq->dst,0 , areq->dst_len,1 ); -dma_free_coherent (dev, req->ctx.rsa->key_sz, req->dst_align, - req->out.rsa.enc.c); - }else { -dma_unmap_single (dev, req->out.rsa.enc.c, req->ctx.rsa->key_sz, -DMA_FROM_DEVICE ); +kfree_sensitive (req->dst_align); } +dma_unmap_single (dev, req->out.rsa.enc.c, req->ctx.rsa->key_sz, +DMA_FROM_DEVICE ); +dma_unmap_single (dev, req->phy_in,sizeof (struct qat_rsa_input_params ),DMA_TO_DEVICE ); dma_unmap_single(dev, req->phy_out,
@@ -664,6 +661,7 @@ static int qat_rsa_enc(struct akcipher_request *req)struct qat_asym_request *qat_req =PTR_ALIGN (akcipher_request_ctx (req),64 );struct icp_qat_fw_pke_request *msg = &qat_req->req; +u8 *vaddr;int ret;if (unlikely (!ctx->n || !ctx->e))
@@ -701,40 +699,39 @@ static int qat_rsa_enc(struct akcipher_request *req)*/ if (sg_is_last (req->src) && req->src_len == ctx->key_sz) { qat_req->src_align =NULL ; - qat_req->in.rsa.enc.m =dma_map_single (dev,sg_virt (req->src), - req->src_len,DMA_TO_DEVICE ); -if (unlikely (dma_mapping_error (dev, qat_req->in.rsa.enc.m))) -return ret; - + vaddr =sg_virt (req->src); }else {int shift = ctx->key_sz - req->src_len; - qat_req->src_align =dma_alloc_coherent (dev, ctx->key_sz, - &qat_req->in.rsa.enc.m, -GFP_KERNEL ); + qat_req->src_align =kzalloc (ctx->key_sz,GFP_KERNEL );if (unlikely (!qat_req->src_align))return ret;scatterwalk_map_and_copy (qat_req->src_align + shift, req->src,0 , req->src_len,0 ); + vaddr = qat_req->src_align; } -if (sg_is_last (req->dst) && req->dst_len == ctx->key_sz) { - qat_req->dst_align =NULL ; - qat_req->out.rsa.enc.c =dma_map_single (dev,sg_virt (req->dst), - req->dst_len, -DMA_FROM_DEVICE ); -if (unlikely (dma_mapping_error (dev, qat_req->out.rsa.enc.c))) - goto unmap_src; + qat_req->in.rsa.enc.m =dma_map_single (dev, vaddr, ctx->key_sz, +DMA_TO_DEVICE ); +if (unlikely (dma_mapping_error (dev, qat_req->in.rsa.enc.m))) + goto unmap_src; +if (sg_is_last (req->dst) && req->dst_len == ctx->key_sz) { + qat_req->dst_align =NULL ; + vaddr =sg_virt (req->dst); }else { - qat_req->dst_align =dma_alloc_coherent (dev, ctx->key_sz, - &qat_req->out.rsa.enc.c, -GFP_KERNEL ); + qat_req->dst_align =kzalloc (ctx->key_sz,GFP_KERNEL );if (unlikely (!qat_req->dst_align)) goto unmap_src; - + vaddr = qat_req->dst_align; } + + qat_req->out.rsa.enc.c =dma_map_single (dev, vaddr, ctx->key_sz, +DMA_FROM_DEVICE ); +if (unlikely (dma_mapping_error (dev, qat_req->out.rsa.enc.c))) + goto unmap_dst; + qat_req->in.rsa.in_tab[3 ] =0 ; qat_req->out.rsa.out_tab[1 ] =0 ; qat_req->phy_in = dma_map_single(dev, &qat_req->in.rsa.enc.m,
@@ -772,21 +769,15 @@ static int qat_rsa_enc(struct akcipher_request *req)sizeof (struct qat_rsa_input_params ), DMA_TO_DEVICE); unmap_dst: -if (qat_req->dst_align) -dma_free_coherent (dev, ctx->key_sz, qat_req->dst_align, - qat_req->out.rsa.enc.c); -else -if (!dma_mapping_error (dev, qat_req->out.rsa.enc.c)) -dma_unmap_single (dev, qat_req->out.rsa.enc.c, - ctx->key_sz,DMA_FROM_DEVICE ); +if (!dma_mapping_error (dev, qat_req->out.rsa.enc.c)) +dma_unmap_single (dev, qat_req->out.rsa.enc.c, + ctx->key_sz,DMA_FROM_DEVICE ); +kfree_sensitive (qat_req->dst_align); unmap_src: -if (qat_req->src_align) -dma_free_coherent (dev, ctx->key_sz, qat_req->src_align, - qat_req->in.rsa.enc.m); -else -if (!dma_mapping_error (dev, qat_req->in.rsa.enc.m)) -dma_unmap_single (dev, qat_req->in.rsa.enc.m, - ctx->key_sz,DMA_TO_DEVICE ); +if (!dma_mapping_error (dev, qat_req->in.rsa.enc.m)) +dma_unmap_single (dev, qat_req->in.rsa.enc.m, ctx->key_sz, +DMA_TO_DEVICE ); +kfree_sensitive (qat_req->src_align);return ret; }
@@ -799,6 +790,7 @@ static int qat_rsa_dec(struct akcipher_request *req)struct qat_asym_request *qat_req =PTR_ALIGN (akcipher_request_ctx (req),64 );struct icp_qat_fw_pke_request *msg = &qat_req->req; +u8 *vaddr;int ret;if (unlikely (!ctx->n || !ctx->d))
@@ -846,40 +838,37 @@ static int qat_rsa_dec(struct akcipher_request *req)*/ if (sg_is_last (req->src) && req->src_len == ctx->key_sz) { qat_req->src_align =NULL ; - qat_req->in.rsa.dec.c =dma_map_single (dev,sg_virt (req->src), - req->dst_len,DMA_TO_DEVICE ); -if (unlikely (dma_mapping_error (dev, qat_req->in.rsa.dec.c))) -return ret; - + vaddr =sg_virt (req->src); }else {int shift = ctx->key_sz - req->src_len; - qat_req->src_align =dma_alloc_coherent (dev, ctx->key_sz, - &qat_req->in.rsa.dec.c, -GFP_KERNEL ); + qat_req->src_align =kzalloc (ctx->key_sz,GFP_KERNEL );if (unlikely (!qat_req->src_align))return ret;scatterwalk_map_and_copy (qat_req->src_align + shift, req->src,0 , req->src_len,0 ); + vaddr = qat_req->src_align; } -if (sg_is_last (req->dst) && req->dst_len == ctx->key_sz) { - qat_req->dst_align =NULL ; - qat_req->out.rsa.dec.m =dma_map_single (dev,sg_virt (req->dst), - req->dst_len, -DMA_FROM_DEVICE ); -if (unlikely (dma_mapping_error (dev, qat_req->out.rsa.dec.m))) - goto unmap_src; + qat_req->in.rsa.dec.c =dma_map_single (dev, vaddr, ctx->key_sz, +DMA_TO_DEVICE ); +if (unlikely (dma_mapping_error (dev, qat_req->in.rsa.dec.c))) + goto unmap_src; +if (sg_is_last (req->dst) && req->dst_len == ctx->key_sz) { + qat_req->dst_align =NULL ; + vaddr =sg_virt (req->dst); }else { - qat_req->dst_align =dma_alloc_coherent (dev, ctx->key_sz, - &qat_req->out.rsa.dec.m, -GFP_KERNEL ); + qat_req->dst_align =kzalloc (ctx->key_sz,GFP_KERNEL );if (unlikely (!qat_req->dst_align)) goto unmap_src; - + vaddr = qat_req->dst_align; } + qat_req->out.rsa.dec.m =dma_map_single (dev, vaddr, ctx->key_sz, +DMA_FROM_DEVICE ); +if (unlikely (dma_mapping_error (dev, qat_req->out.rsa.dec.m))) + goto unmap_dst;if (ctx->crt_mode) qat_req->in.rsa.in_tab[6 ] =0 ;
@@ -925,21 +914,15 @@ static int qat_rsa_dec(struct akcipher_request *req)sizeof (struct qat_rsa_input_params ), DMA_TO_DEVICE); unmap_dst: -if (qat_req->dst_align) -dma_free_coherent (dev, ctx->key_sz, qat_req->dst_align, - qat_req->out.rsa.dec.m); -else -if (!dma_mapping_error (dev, qat_req->out.rsa.dec.m)) -dma_unmap_single (dev, qat_req->out.rsa.dec.m, - ctx->key_sz,DMA_FROM_DEVICE ); +if (!dma_mapping_error (dev, qat_req->out.rsa.dec.m)) +dma_unmap_single (dev, qat_req->out.rsa.dec.m, + ctx->key_sz,DMA_FROM_DEVICE ); +kfree_sensitive (qat_req->dst_align); unmap_src: -if (qat_req->src_align) -dma_free_coherent (dev, ctx->key_sz, qat_req->src_align, - qat_req->in.rsa.dec.c); -else -if (!dma_mapping_error (dev, qat_req->in.rsa.dec.c)) -dma_unmap_single (dev, qat_req->in.rsa.dec.c, - ctx->key_sz,DMA_TO_DEVICE ); +if (!dma_mapping_error (dev, qat_req->in.rsa.dec.c)) +dma_unmap_single (dev, qat_req->in.rsa.dec.c, ctx->key_sz, +DMA_TO_DEVICE ); +kfree_sensitive (qat_req->src_align);return ret; }
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 146/158 crypto: qat - remove dma_free_coherent() for DH
In reply to Greg Kroah-HartmanFrom: Giovanni Cabiddu <[email protected]>
[ Upstream commit 029aa4624a7fe35233bdd3d1354dc7be260380bf ]
The functions qat_dh_compute_value() allocates memory with dma_alloc_coherent() if the source or the destination buffers are made of multiple flat buffers or of a size that is not compatible with the hardware.
This memory is then freed with dma_free_coherent() in the context of a tasklet invoked to handle the response for the corresponding request.
According to Documentation/core-api/dma-api-howto.rst, the function dma_free_coherent() cannot be called in an interrupt context.
Replace allocations with dma_alloc_coherent() in the function qat_dh_compute_value() with kmalloc() + dma_map_single().
--- drivers/crypto/qat/qat_common/qat_asym_algs.c | 83 ++++++++----------- 1 file changed, 34 insertions(+), 49 deletions(-)
drivers/crypto/qat/qat_common/qat_asym_algs.c +34 -49
@@ -164,26 +164,21 @@ static void qat_dh_cb(struct icp_qat_fw_pke_resp *resp) err = (err ==ICP_QAT_FW_COMN_STATUS_FLAG_OK ) ?0 : -EINVAL ;if (areq->src) { -if (req->src_align) -dma_free_coherent (dev, req->ctx.dh->p_size, - req->src_align, req->in.dh.in.b); -else -dma_unmap_single (dev, req->in.dh.in.b, - req->ctx.dh->p_size,DMA_TO_DEVICE ); +dma_unmap_single (dev, req->in.dh.in.b, req->ctx.dh->p_size, +DMA_TO_DEVICE ); +kfree_sensitive (req->src_align); } areq->dst_len = req->ctx.dh->p_size;if (req->dst_align) {scatterwalk_map_and_copy (req->dst_align, areq->dst,0 , areq->dst_len,1 ); - -dma_free_coherent (dev, req->ctx.dh->p_size, req->dst_align, - req->out.dh.r); - }else { -dma_unmap_single (dev, req->out.dh.r, req->ctx.dh->p_size, -DMA_FROM_DEVICE ); +kfree_sensitive (req->dst_align); } +dma_unmap_single (dev, req->out.dh.r, req->ctx.dh->p_size, +DMA_FROM_DEVICE ); +dma_unmap_single (dev, req->phy_in,sizeof (struct qat_dh_input_params ),DMA_TO_DEVICE ); dma_unmap_single(dev, req->phy_out,
@@ -231,6 +226,7 @@ static int qat_dh_compute_value(struct kpp_request *req)struct icp_qat_fw_pke_request *msg = &qat_req->req;int ret;int n_input_params =0 ; +u8 *vaddr;if (unlikely (!ctx->xa))return -EINVAL ;
@@ -287,27 +283,24 @@ static int qat_dh_compute_value(struct kpp_request *req)*/ if (sg_is_last (req->src) && req->src_len == ctx->p_size) { qat_req->src_align =NULL ; - qat_req->in.dh.in.b =dma_map_single (dev, -sg_virt (req->src), - req->src_len, -DMA_TO_DEVICE ); -if (unlikely (dma_mapping_error (dev, - qat_req->in.dh.in.b))) -return ret; - + vaddr =sg_virt (req->src); }else {int shift = ctx->p_size - req->src_len; - qat_req->src_align =dma_alloc_coherent (dev, - ctx->p_size, - &qat_req->in.dh.in.b, -GFP_KERNEL ); + qat_req->src_align =kzalloc (ctx->p_size,GFP_KERNEL );if (unlikely (!qat_req->src_align))return ret;scatterwalk_map_and_copy (qat_req->src_align + shift, req->src,0 , req->src_len,0 ); + + vaddr = qat_req->src_align; } + + qat_req->in.dh.in.b =dma_map_single (dev, vaddr, ctx->p_size, +DMA_TO_DEVICE ); +if (unlikely (dma_mapping_error (dev, qat_req->in.dh.in.b))) + goto unmap_src; }/* * dst can be of any size in valid range, but HW expects it to be the
@@ -318,20 +311,18 @@ static int qat_dh_compute_value(struct kpp_request *req)*/ if (sg_is_last (req->dst) && req->dst_len == ctx->p_size) { qat_req->dst_align =NULL ; - qat_req->out.dh.r =dma_map_single (dev,sg_virt (req->dst), - req->dst_len, -DMA_FROM_DEVICE ); - -if (unlikely (dma_mapping_error (dev, qat_req->out.dh.r))) - goto unmap_src; - + vaddr =sg_virt (req->dst); }else { - qat_req->dst_align =dma_alloc_coherent (dev, ctx->p_size, - &qat_req->out.dh.r, -GFP_KERNEL ); + qat_req->dst_align =kzalloc (ctx->p_size,GFP_KERNEL );if (unlikely (!qat_req->dst_align)) goto unmap_src; + + vaddr = qat_req->dst_align; } + qat_req->out.dh.r =dma_map_single (dev, vaddr, ctx->p_size, +DMA_FROM_DEVICE ); +if (unlikely (dma_mapping_error (dev, qat_req->out.dh.r))) + goto unmap_dst; qat_req->in.dh.in_tab[n_input_params] =0 ; qat_req->out.dh.out_tab[1 ] =0 ;
@@ -371,23 +362,17 @@ static int qat_dh_compute_value(struct kpp_request *req)sizeof (struct qat_dh_input_params ), DMA_TO_DEVICE); unmap_dst: -if (qat_req->dst_align) -dma_free_coherent (dev, ctx->p_size, qat_req->dst_align, - qat_req->out.dh.r); -else -if (!dma_mapping_error (dev, qat_req->out.dh.r)) -dma_unmap_single (dev, qat_req->out.dh.r, ctx->p_size, -DMA_FROM_DEVICE ); +if (!dma_mapping_error (dev, qat_req->out.dh.r)) +dma_unmap_single (dev, qat_req->out.dh.r, ctx->p_size, +DMA_FROM_DEVICE ); +kfree_sensitive (qat_req->dst_align); unmap_src:if (req->src) { -if (qat_req->src_align) -dma_free_coherent (dev, ctx->p_size, qat_req->src_align, - qat_req->in.dh.in.b); -else -if (!dma_mapping_error (dev, qat_req->in.dh.in.b)) -dma_unmap_single (dev, qat_req->in.dh.in.b, - ctx->p_size, -DMA_TO_DEVICE ); +if (!dma_mapping_error (dev, qat_req->in.dh.in.b)) +dma_unmap_single (dev, qat_req->in.dh.in.b, + ctx->p_size, +DMA_TO_DEVICE ); +kfree_sensitive (qat_req->src_align); }return ret; }
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 147/158 crypto: qat - add param check for RSA
In reply to Greg Kroah-HartmanFrom: Giovanni Cabiddu <[email protected]>
[ Upstream commit 9714061423b8b24b8afb31b8eb4df977c63f19c4 ]
Reject requests with a source buffer that is bigger than the size of the key. This is to prevent a possible integer underflow that might happen when copying the source scatterlist into a linear buffer.
--- drivers/crypto/qat/qat_common/qat_asym_algs.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/crypto/qat/qat_common/qat_asym_algs.c +8 -0
@@ -656,6 +656,10 @@ static int qat_rsa_enc(struct akcipher_request *req) req->dst_len = ctx->key_sz;return -EOVERFLOW ; } + +if (req->src_len > ctx->key_sz) +return -EINVAL ; +memset (msg,'\0' ,sizeof (*msg));ICP_QAT_FW_PKE_HDR_VALID_FLAG_SET (msg->pke_hdr,ICP_QAT_FW_COMN_REQ_FLAG_SET );
@@ -785,6 +789,10 @@ static int qat_rsa_dec(struct akcipher_request *req) req->dst_len = ctx->key_sz;return -EOVERFLOW ; } + +if (req->src_len > ctx->key_sz) +return -EINVAL ; +memset (msg,'\0' ,sizeof (*msg));ICP_QAT_FW_PKE_HDR_VALID_FLAG_SET (msg->pke_hdr,ICP_QAT_FW_COMN_REQ_FLAG_SET );
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 148/158 crypto: qat - add param check for DH
In reply to Greg Kroah-HartmanFrom: Giovanni Cabiddu <[email protected]>
[ Upstream commit 2acbb8771f6ac82422886e63832ee7a0f4b1635b ]
Reject requests with a source buffer that is bigger than the size of the key. This is to prevent a possible integer underflow that might happen when copying the source scatterlist into a linear buffer.
--- drivers/crypto/qat/qat_common/qat_asym_algs.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/crypto/qat/qat_common/qat_asym_algs.c +4 -0
@@ -235,6 +235,10 @@ static int qat_dh_compute_value(struct kpp_request *req) req->dst_len = ctx->p_size;return -EOVERFLOW ; } + +if (req->src_len > ctx->p_size) +return -EINVAL ; +memset (msg,'\0' ,sizeof (*msg));ICP_QAT_FW_PKE_HDR_VALID_FLAG_SET (msg->pke_hdr,ICP_QAT_FW_COMN_REQ_FLAG_SET );
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 149/158 crypto: qat - re-enable registration of algorithms
In reply to Greg Kroah-HartmanFrom: Giovanni Cabiddu <[email protected]>
[ Upstream commit d09144745959bf7852ccafd73243dd7d1eaeb163 ]
Re-enable the registration of algorithms after fixes to (1) use pre-allocated buffers in the datapath and (2) support the CRYPTO_TFM_REQ_MAY_BACKLOG flag.
This reverts commit 8893d27ffcaf6ec6267038a177cb87bcde4dd3de.
--- drivers/crypto/qat/qat_4xxx/adf_drv.c | 7 ------- drivers/crypto/qat/qat_common/qat_crypto.c | 7 ------- 2 files changed, 14 deletions(-)
drivers/crypto/qat/qat_4xxx/adf_drv.c +0 -7
@@ -75,13 +75,6 @@ static int adf_crypto_dev_config(struct adf_accel_dev *accel_dev)if (ret) goto err; -/* Temporarily set the number of crypto instances to zero to avoid -* registering the crypto algorithms. -* This will be removed when the algorithms will support the -* CRYPTO_TFM_REQ_MAY_BACKLOG flag -*/ - instances =0 ; -for (i =0 ; i < instances; i++) { val = i; bank = i *2 ;
drivers/crypto/qat/qat_common/qat_crypto.c +0 -7
@@ -161,13 +161,6 @@ int qat_crypto_dev_config(struct adf_accel_dev *accel_dev)if (ret) goto err; -/* Temporarily set the number of crypto instances to zero to avoid -* registering the crypto algorithms. -* This will be removed when the algorithms will support the -* CRYPTO_TFM_REQ_MAY_BACKLOG flag -*/ - instances =0 ; -for (i =0 ; i < instances; i++) { val = i;snprintf (key,sizeof (key),ADF_CY "%d" ADF_RING_ASYM_BANK_NUM , i);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 150/158 exfat: fix referencing wrong parent directory information after renaming
In reply to Greg Kroah-HartmanFrom: Yuezhang Mo <[email protected]>
[ Upstream commit d8dad2588addd1d861ce19e7df3b702330f0c7e3 ]
During renaming, the parent directory information maybe updated. But the file/directory still references to the old parent directory information.
This bug will cause 2 problems.
(1) The renamed file can not be written.
[10768.175172] exFAT-fs (sda1): error, failed to bmap (inode : 7afd50e4 iblock : 0, err : -5)
[10768.184285] exFAT-fs (sda1): Filesystem has been set read-only
ash: write error: Input/output error(2) Some dentries of the renamed file/directory are not set to deleted after removing the file/directory.
exfat_update_parent_info() is a workaround for the wrong parent directory information being used after renaming. Now that bug is fixed, this is no longer needed, so remove it.
--- fs/exfat/namei.c | 27 +-------------------------- 1 file changed, 1 insertion(+), 26 deletions(-)
fs/exfat/namei.c +1 -26
@@ -1080,6 +1080,7 @@ static int exfat_rename_file(struct inode *inode, struct exfat_chain *p_dir,exfat_remove_entries (inode, p_dir, oldentry,0 , num_old_entries); + ei->dir = *p_dir; ei->entry = newentry; }else {if (exfat_get_entry_type (epold) ==TYPE_FILE ) {
@@ -1167,28 +1168,6 @@ static int exfat_move_file(struct inode *inode, struct exfat_chain *p_olddir,return 0 ; } -static void exfat_update_parent_info (struct exfat_inode_info *ei, -struct inode *parent_inode) -{ -struct exfat_sb_info *sbi =EXFAT_SB (parent_inode->i_sb); -struct exfat_inode_info *parent_ei =EXFAT_I (parent_inode); -loff_t parent_isize =i_size_read (parent_inode); - -/* -* the problem that struct exfat_inode_info caches wrong parent info. -* -* because of flag-mismatch of ei->dir, -* there is abnormal traversing cluster chain. -*/ -if (unlikely (parent_ei->flags != ei->dir.flags || - parent_isize !=EXFAT_CLU_TO_B (ei->dir.size, sbi) || - parent_ei->start_clu != ei->dir.dir)) { -exfat_chain_set (&ei->dir, parent_ei->start_clu, -EXFAT_B_TO_CLU_ROUND_UP (parent_isize, sbi), - parent_ei->flags); - } -} -/* rename or move a old file into a new file */ static int __exfat_rename(struct inode *old_parent_inode, struct exfat_inode_info *ei, struct inode *new_parent_inode,
@@ -1219,8 +1198,6 @@ static int __exfat_rename(struct inode *old_parent_inode,return -ENOENT ; } -exfat_update_parent_info (ei, old_parent_inode); -exfat_chain_dup (&olddir, &ei->dir); dentry = ei->entry;
@@ -1241,8 +1218,6 @@ static int __exfat_rename(struct inode *old_parent_inode, goto out; } -exfat_update_parent_info (new_ei, new_parent_inode); - p_dir = &(new_ei->dir); new_entry = new_ei->entry; ep =exfat_get_dentry (sb, p_dir, new_entry, &new_bh);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 151/158 exfat: use updated exfat_chain directly during renaming
In reply to Greg Kroah-HartmanFrom: Sungjong Seo <[email protected]>
commit 204e6ceaa1035cb7b92b156517e88842ebb4c7ff upstream.
In order for a file to access its own directory entry set, exfat_inode_info(ei) has two copied values. One is ei->dir, which is a snapshot of exfat_chain of the parent directory, and the other is ei->entry, which is the offset of the start of the directory entry set in the parent directory.
Since the parent directory can be updated after the snapshot point, it should be used only for accessing one's own directory entry set.
However, as of now, during renaming, it could try to traverse or to allocate clusters via snapshot values, it does not make sense.
This potential problem has been revealed when exfat_update_parent_info() was removed by commit d8dad2588add ("exfat: fix referencing wrong parent directory information after renaming"). However, I don't think it's good idea to bring exfat_update_parent_info() back.
Instead, let's use the updated exfat_chain of parent directory diectly.
--- fs/exfat/namei.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
fs/exfat/namei.c +3 -1
@@ -1198,7 +1198,9 @@ static int __exfat_rename(struct inode *return -ENOENT ; } -exfat_chain_dup (&olddir, &ei->dir); +exfat_chain_set (&olddir,EXFAT_I (old_parent_inode)->start_clu, +EXFAT_B_TO_CLU_ROUND_UP (i_size_read (old_parent_inode), sbi), +EXFAT_I (old_parent_inode)->flags); dentry = ei->entry; ep =exfat_get_dentry (sb, &olddir, dentry, &old_bh);
Greg Kroah-Hartman
maintainerPATCH 152/158 x86/amd: Use IBPB for firmware calls
In reply to Greg Kroah-HartmanFrom: Peter Zijlstra <[email protected]>
commit 28a99e95f55c61855983d36a88c05c178d966bb7 upstream.
On AMD IBRS does not prevent Retbleed; as such use IBPB before a firmware call to flush the branch history state.
And because in order to do an EFI call, the kernel maps a whole lot of the kernel page table into the EFI page table, do an IBPB just in case in order to prevent the scenario of poisoning the BTB and causing an EFI call using the unprotected RET there.
[ bp: Massage. ]
--- arch/x86/include/asm/cpufeatures.h | 1 + arch/x86/include/asm/nospec-branch.h | 2 ++ arch/x86/kernel/cpu/bugs.c | 11 ++++++++++- 3 files changed, 13 insertions(+), 1 deletion(-)
arch/x86/include/asm/cpufeatures.h +1 -0
@@ -301,6 +301,7 @@#define X86_FEATURE_RETPOLINE_LFENCE (11*32+13)/* "" Use LFENCE for Spectre variant 2 */ #define X86_FEATURE_RETHUNK (11*32+14)/* "" Use REturn THUNK */ #define X86_FEATURE_UNRET (11*32+15)/* "" AMD BTB untrain return */ +#define X86_FEATURE_USE_IBPB_FW (11*32+16)/* "" Use IBPB during runtime firmware calls */ /* Intel-defined CPU features, CPUID level 0x00000007:1 (EAX), word 12 */ #define X86_FEATURE_AVX_VNNI (12*32+ 4)/* AVX VNNI instructions */
arch/x86/include/asm/nospec-branch.h +2 -0
@@ -297,6 +297,8 @@ do { \alternative_msr_write (MSR_IA32_SPEC_CTRL , \spec_ctrl_current () |SPEC_CTRL_IBRS , \X86_FEATURE_USE_IBRS_FW ); \ +alternative_msr_write (MSR_IA32_PRED_CMD ,PRED_CMD_IBPB , \ +X86_FEATURE_USE_IBPB_FW ); \ }while (0 ) #define firmware_restrict_branch_speculation_end() \
arch/x86/kernel/cpu/bugs.c +10 -1
@@ -1512,7 +1512,16 @@ static void __init spectre_v2_select_mit* the CPU supports Enhanced IBRS, kernel might un-intentionally not * enable IBRS around firmware calls. */ -if (boot_cpu_has (X86_FEATURE_IBRS ) && !spectre_v2_in_ibrs_mode (mode)) { +if (boot_cpu_has_bug (X86_BUG_RETBLEED ) && + (boot_cpu_data.x86_vendor ==X86_VENDOR_AMD || + boot_cpu_data.x86_vendor ==X86_VENDOR_HYGON )) { + +if (retbleed_cmd !=RETBLEED_CMD_IBPB ) { +setup_force_cpu_cap (X86_FEATURE_USE_IBPB_FW ); +pr_info ("Enabling Speculation Barrier for firmware calls\n" ); + } + + }else if (boot_cpu_has (X86_FEATURE_IBRS ) && !spectre_v2_in_ibrs_mode (mode)) {setup_force_cpu_cap (X86_FEATURE_USE_IBRS_FW );pr_info ("Enabling Restricted Speculation for firmware calls\n" ); }
Greg Kroah-Hartman
maintainerPATCH 153/158 x86/alternative: Report missing return thunk details
In reply to Greg Kroah-HartmanFrom: Kees Cook <[email protected]>
commit 65cdf0d623bedf0e069bb64ed52e8bb20105e2ba upstream.
Debugging missing return thunks is easier if we can see where they're happening.
--- arch/x86/kernel/alternative.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
arch/x86/kernel/alternative.c +3 -1
@@ -555,7 +555,9 @@ void __init_or_module noinline apply_ret dest = addr + insn.length + insn.immediate.value;if (__static_call_fixup (addr, op, dest) || -WARN_ON_ONCE (dest != &__x86_return_thunk)) +WARN_ONCE (dest != &__x86_return_thunk, +"missing return thunk: %pS-%pS: %*ph" , + addr, dest,5 , addr))continue ; DPRINTK("return thunk at: %pS (%px) len: %d to: %pS",
Greg Kroah-Hartman
maintainerPATCH 154/158 watchqueue: make sure to serialize wqueue->defunct properly
In reply to Greg Kroah-HartmanFrom: Linus Torvalds <[email protected]>
commit 353f7988dd8413c47718f7ca79c030b6fb62cfe5 upstream.
When the pipe is closed, we mark the associated watchqueue defunct by calling watch_queue_clear(). However, while that is protected by the watchqueue lock, new watchqueue entries aren't actually added under that lock at all: they use the pipe->rd_wait.lock instead, and looking up that pipe happens without any locking.
The watchqueue code uses the RCU read-side section to make sure that the wqueue entry itself hasn't disappeared, but that does not protect the pipe_info in any way.
So make sure to actually hold the wqueue lock when posting watch events, properly serializing against the pipe being torn down.
--- kernel/watch_queue.c | 53 +++++++++++++++++++++++++++++++++++---------------- 1 file changed, 37 insertions(+), 16 deletions(-)
kernel/watch_queue.c +37 -16
@@ -34,6 +34,27 @@ MODULE_LICENSE("GPL");#define WATCH_QUEUE_NOTE_SIZE 128#define WATCH_QUEUE_NOTES_PER_PAGE (PAGE_SIZE / WATCH_QUEUE_NOTE_SIZE) +/* +* This must be called under the RCU read-lock, which makes +* sure that the wqueue still exists. It can then take the lock, +* and check that the wqueue hasn't been destroyed, which in +* turn makes sure that the notification pipe still exists. +*/ +static inline bool lock_wqueue (struct watch_queue *wqueue) +{ +spin_lock_bh (&wqueue->lock); +if (unlikely (wqueue->defunct)) { +spin_unlock_bh (&wqueue->lock); +return false; + } +return true; +} + +static inline void unlock_wqueue (struct watch_queue *wqueue) +{ +spin_unlock_bh (&wqueue->lock); +} +static void watch_queue_pipe_buf_release (struct pipe_inode_info *pipe,struct pipe_buffer *buf) {
@@ -69,6 +90,10 @@ static const struct pipe_buf_operations/* * Post a notification to a watch queue. +* +* Must be called with the RCU lock for reading, and the +* watch_queue lock held, which guarantees that the pipe +* hasn't been released. */ static bool post_one_notification (struct watch_queue *wqueue,struct watch_notification *n)
@@ -85,9 +110,6 @@ static bool post_one_notification(structspin_lock_irq (&pipe->rd_wait.lock); -if (wqueue->defunct) - goto out; - mask = pipe->ring_size -1 ; head = pipe->head; tail = pipe->tail;
@@ -203,7 +225,10 @@ void __post_watch_notification(struct waif (security_post_notification (watch->cred, cred, n) <0 )continue ; -post_one_notification (wqueue, n); +if (lock_wqueue (wqueue)) { +post_one_notification (wqueue, n); +unlock_wqueue (wqueue);; + } }rcu_read_unlock ();
@@ -462,11 +487,12 @@ int add_watch_to_object(struct watch *wareturn -EAGAIN ; } -spin_lock_bh (&wqueue->lock); -kref_get (&wqueue->usage); -kref_get (&watch->usage); -hlist_add_head (&watch->queue_node, &wqueue->watches); -spin_unlock_bh (&wqueue->lock); +if (lock_wqueue (wqueue)) { +kref_get (&wqueue->usage); +kref_get (&watch->usage); +hlist_add_head (&watch->queue_node, &wqueue->watches); +unlock_wqueue (wqueue); + }hlist_add_head (&watch->list_node, &wlist->watchers);return 0 ;
@@ -520,20 +546,15 @@ found: wqueue =rcu_dereference (watch->queue); -/* We don't need the watch list lock for the next bit as RCU is -* protecting *wqueue from deallocation. -*/ -if (wqueue) { +if (lock_wqueue (wqueue)) {post_one_notification (wqueue, &n.watch); -spin_lock_bh (&wqueue->lock); -if (!hlist_unhashed (&watch->queue_node)) {hlist_del_init_rcu (&watch->queue_node);put_watch (watch); } -spin_unlock_bh (&wqueue->lock); +unlock_wqueue (wqueue); }if (wlist->release_watch) {
Greg Kroah-Hartman
maintainerPATCH 155/158 ASoC: SOF: pm: add explicit behavior for ACPI S1 and S2
In reply to Greg Kroah-HartmanFrom: Pierre-Louis Bossart <[email protected]>
commit a933084558c61cac8c902d2474b39444d87fba46 upstream.
The existing code only deals with S0 and S3, let's start adding S1 and S2.
No functional change.
--- sound/soc/sof/pm.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)
sound/soc/sof/pm.c +11 -1
@@ -327,8 +327,18 @@ int snd_sof_prepare(struct device *dev)return 0 ;#if defined(CONFIG_ACPI ) -if (acpi_target_system_state () ==ACPI_STATE_S0 ) +switch (acpi_target_system_state ()) { +case ACPI_STATE_S0 : sdev->system_suspend_target =SOF_SUSPEND_S0IX ; +break ; +case ACPI_STATE_S1 : +case ACPI_STATE_S2 : +case ACPI_STATE_S3 : + sdev->system_suspend_target =SOF_SUSPEND_S3 ; +break ; +default : +break ; + }#endif return 0 ;
Greg Kroah-Hartman
maintainerPATCH 156/158 ASoC: SOF: pm: add definitions for S4 and S5 states
In reply to Greg Kroah-HartmanFrom: Pierre-Louis Bossart <[email protected]>
commit 9d2d462713384538477703e68577b05131c7d97d upstream.
We currently don't have a means to differentiate between S3, S4 and S5. Add definitions so that we have select different code paths depending on the target state in follow-up patches.
--- sound/soc/sof/pm.c | 9 +++++++++ sound/soc/sof/sof-priv.h | 2 ++ 2 files changed, 11 insertions(+)
sound/soc/sof/pm.c +9 -0
@@ -23,6 +23,9 @@ static u32 snd_sof_dsp_power_target(struu32 target_dsp_state;switch (sdev->system_suspend_target) { +case SOF_SUSPEND_S5 : +case SOF_SUSPEND_S4 : +/* DSP should be in D3 if the system is suspending to S3+ */ case SOF_SUSPEND_S3 :/* DSP should be in D3 if the system is suspending to S3 */ target_dsp_state =SOF_DSP_PM_D3 ;
@@ -336,6 +339,12 @@ int snd_sof_prepare(struct device *dev)case ACPI_STATE_S3 : sdev->system_suspend_target =SOF_SUSPEND_S3 ;break ; +case ACPI_STATE_S4 : + sdev->system_suspend_target =SOF_SUSPEND_S4 ; +break ; +case ACPI_STATE_S5 : + sdev->system_suspend_target =SOF_SUSPEND_S5 ; +break ;default :break ; }
sound/soc/sof/sof-priv.h +2 -0
@@ -85,6 +85,8 @@ enum sof_system_suspend_state {SOF_SUSPEND_NONE =0 ,SOF_SUSPEND_S0IX ,SOF_SUSPEND_S3 , +SOF_SUSPEND_S4 , + SOF_SUSPEND_S5, }; enum sof_dfsentry_type {
Greg Kroah-Hartman
maintainerPATCH 157/158 ASoC: SOF: Intel: disable IMR boot when resuming from ACPI S4 and S5 states
In reply to Greg Kroah-HartmanFrom: Pierre-Louis Bossart <[email protected]>
commit 391153522d186f19a008d824bb3a05950351ce6c upstream.
The IMR was assumed to be preserved when suspending to S4 and S5 states, but community reports invalidate that assumption, the hardware seems to be powered off and the IMR memory content cleared.
Make sure regular boot with firmware download is used for S4 and S5.
--- sound/soc/sof/intel/hda-loader.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
sound/soc/sof/intel/hda-loader.c +2 -1
@@ -397,7 +397,8 @@ int hda_dsp_cl_boot_firmware(struct snd_struct firmware stripped_firmware;int ret, ret1, i; -if ((sdev->fw_ready.flags &SOF_IPC_INFO_D3_PERSISTENT ) && +if ((sdev->system_suspend_target <SOF_SUSPEND_S4 ) && + (sdev->fw_ready.flags &SOF_IPC_INFO_D3_PERSISTENT ) && !(sof_debug_check_flag (SOF_DBG_IGNORE_D3_PERSISTENT )) && !sdev->first_boot) {dev_dbg (sdev->dev,"IMR restore supported, booting from IMR directly\n" );
Greg Kroah-Hartman
maintainerPATCH 158/158 watch-queue: remove spurious double semicolon
In reply to Greg Kroah-HartmanFrom: Linus Torvalds <[email protected]>
commit 44e29e64cf1ac0cffb152e0532227ea6d002aa28 upstream.
Sedat Dilek noticed that I had an extraneous semicolon at the end of a line in the previous patch.
It's harmless, but unintentional, and while compilers just treat it as an extra empty statement, for all I know some other tooling might warn about it. So clean it up before other people notice too ;)
--- kernel/watch_queue.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/watch_queue.c +1 -1
@@ -227,7 +227,7 @@ void __post_watch_notification(struct waif (lock_wqueue (wqueue)) {post_one_notification (wqueue, n); -unlock_wqueue (wqueue);; +unlock_wqueue (wqueue); } }
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.18.15 release. There are 158 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 29 Jul 2022 16:09:50 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.18.15-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.18.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels and build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.18.15 release. There are 158 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 29 Jul 2022 16:09:50 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.18.15-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.18.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
## Build
* kernel: 5.18.15-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.18.y
* git commit: 63d1be154edd5513bff11d778954f7ec7cbf50c1
* git describe: v5.18.14-159-g63d1be154edd
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.18.y/build/v5.18.14-159-g63d1be154edd
## Test Regressions (compared to v5.18.14)
No test regressions found.
## Metric Regressions (compared to v5.18.14)
No metric regressions found.
## Test Fixes (compared to v5.18.14)
No test fixes found.
## Metric Fixes (compared to v5.18.14)
No metric fixes found.
## Test result summary
total: 131463, pass: 120143, fail: 902, skip: 9686, xfail: 732
## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 307 total, 307 passed, 0 failed
* arm64: 62 total, 60 passed, 2 failed
* i386: 52 total, 50 passed, 2 failed
* mips: 45 total, 45 passed, 0 failed
* parisc: 12 total, 12 passed, 0 failed
* powerpc: 60 total, 54 passed, 6 failed
* riscv: 27 total, 22 passed, 5 failed
* s390: 18 total, 18 passed, 0 failed
* sh: 24 total, 24 passed, 0 failed
* sparc: 12 total, 12 passed, 0 failed
* x86_64: 56 total, 54 passed, 2 failed
## Test suites summary
* fwts
* igt-gpu-tools
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-cpuhotplug
* ltp-crypto
* ltp-cve
* ltp-dio
* ltp-fcntl-locktests
* ltp-filecaps
* ltp-fs
* ltp-fs_bind
* ltp-fs_perms_simple
* ltp-fsx
* ltp-hugetlb
* ltp-io
* ltp-ipc
* ltp-math
* ltp-mm
* ltp-nptl
* ltp-open-posix-tests
* ltp-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* network-basic-tests
* packetdrill
* rcutorture
* ssuite
* v4l2-compliance
* vdso
--
Linaro LKFT
https://lkft.linaro.org
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.18.15 release. There are 158 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 29 Jul 2022 16:09:50 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.18.15-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.18.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Quoted 4 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.18.15 release. There are 158 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Successfully cross-compiled for arm64 (bcm2711_defconfig, GCC 10.2.0) and powerpc (ps3_defconfig, GCC 12.1.0).
Signature · 1 line
An old man doll... just what I always wanted! - Clara
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.18.15 release. There are 158 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Quoted 8 lines
Responses should be made by Fri, 29 Jul 2022 16:09:50 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.18.15-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.18.y
and the diffstat can be found below.
openSUSE configs¹⁾ all green.
¹⁾ armv6hl armv7hl arm64 i386 ppc64 ppc64le riscv64 s390x x86_64
Signature · 2 lines
js suse labs
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.18.15 release. There are 158 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 29 Jul 2022 16:09:50 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.18.15-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.18.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.18:
10 builds: 10 pass, 0 fail
28 boots: 28 pass, 0 fail
130 tests: 130 pass, 0 failLinux version: 5.18.15-rc1-g63d1be154edd
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra194-p3509-0000+p3668-0000,
tegra20-ventana, tegra210-p2371-2180,
tegra210-p3450-0000, tegra30-cardhu-a04Jon
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.18.15 release. There are 158 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 29 Jul 2022 16:09:50 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.18.15-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.18.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Hi Greg,
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.18.15 release. There are 158 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 29 Jul 2022 16:09:50 +0000. Anything received after that time might be too late.
Build test (gcc version 12.1.1 20220724):
mips: 59 configs -> no failure
arm: 99 configs -> no failure
arm64: 3 configs -> no failurex86_64: 4 configs -> no failure
alpha allmodconfig -> no failure
csky allmodconfig -> no failure
powerpc allmodconfig -> no failure
riscv allmodconfig -> no failure
s390 allmodconfig -> no failure
xtensa allmodconfig -> no failure
Boot test:x86_64: Booted on my test laptop. No regression.x86_64: Booted on qemu. No regression. [1]
arm64: Booted on rpi4b (4GB model). No regression. [2]
mips: Booted on ci20 board. No regression. [3]
[1]. https://openqa.qa.codethink.co.uk/tests/1574
[2]. https://openqa.qa.codethink.co.uk/tests/1578
[3]. https://openqa.qa.codethink.co.uk/tests/1580
--
Regards
Sudip
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.18.15 release. There are 158 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 29 Jul 2022 16:09:50 +0000. Anything received after that time might be too late.
Build results:
total: 154 pass: 154 fail: 0 Qemu test results: total: 489 pass: 489 fail: 0
Guenter
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.18.15 release. There are 158 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Fri, 29 Jul 2022 16:09:50 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 8 lines
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.18.15-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.18.y
and the diffstat can be found below.thanks,
greg k-h
Tested rc1 against the Fedora build system (aarch64, armv7, ppc64le, s390x, x86_64), and boot tested x86_64. No regressions noted.