6.0.3-rc1 review
Subsystems (10)
Greg Kroah-Hartman
maintainerPATCH 826/862 scsi: tracing: Fix compile error in trace_array calls when TRACING is disabled
In reply to Greg Kroah-HartmanFrom: Arun Easi <[email protected]>
[ Upstream commit 1a77dd1c2bb5d4a58c16d198cf593720787c02e4 ]
Fix this compilation error seen when CONFIG_TRACING is not enabled:
drivers/scsi/qla2xxx/qla_os.c: In function 'qla_trace_init':drivers/scsi/qla2xxx/qla_os.c:2854:25: error: implicit declaration of function 'trace_array_get_by_name'; did you mean 'trace_array_set_clr_event'? [-Werror=implicit-function-declaration]
2854 | qla_trc_array = trace_array_get_by_name("qla2xxx");
| ^~~~~~~~~~~~~~~~~~~~~~~
| trace_array_set_clr_eventdrivers/scsi/qla2xxx/qla_os.c: In function 'qla_trace_uninit':drivers/scsi/qla2xxx/qla_os.c:2869:9: error: implicit declaration of function 'trace_array_put' [-Werror=implicit-function-declaration]
2869 | trace_array_put(qla_trc_array);
| ^~~~~~~~~~~~~~~--- include/linux/trace.h | 36 ++++++++++++++++++++++++++++++++++-- 1 file changed, 34 insertions(+), 2 deletions(-)
include/linux/trace.h +34 -2
@@ -2,8 +2,6 @@#ifndef _LINUX_TRACE_H#define _LINUX_TRACE_H -#ifdef CONFIG_TRACING -#define TRACE_EXPORT_FUNCTION BIT(0)#define TRACE_EXPORT_EVENT BIT(1)#define TRACE_EXPORT_MARKER BIT(2)
@@ -28,6 +26,8 @@ struct trace_export {int flags; }; +#ifdef CONFIG_TRACING +int register_ftrace_export (struct trace_export *export);int unregister_ftrace_export (struct trace_export *export);
@@ -48,6 +48,38 @@ void osnoise_arch_unregister(void);void osnoise_trace_irq_entry (int id);void osnoise_trace_irq_exit (int id,const char *desc); +#else /* CONFIG_TRACING */ +static inline int register_ftrace_export (struct trace_export *export) +{ +return -EINVAL ; +} +static inline int unregister_ftrace_export (struct trace_export *export) +{ +return 0 ; +} +static inline void trace_printk_init_buffers (void ) +{ +} +static inline int trace_array_printk (struct trace_array *tr,unsigned long ip, +const char *fmt, ...) +{ +return 0 ; +} +static inline int trace_array_init_printk (struct trace_array *tr) +{ +return -EINVAL ; +} +static inline void trace_array_put (struct trace_array *tr) +{ +} +static inline struct trace_array *trace_array_get_by_name (const char *name) +{ +return NULL ; +} +static inline int trace_array_destroy (struct trace_array *tr) +{ +return 0 ; +}#endif /* CONFIG_TRACING */ #endif /* _LINUX_TRACE_H */
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 827/862 ext2: Use kvmalloc() for group descriptor array
In reply to Greg Kroah-HartmanFrom: Jan Kara <[email protected]>
[ Upstream commit e7c7fbb9a8574ebd89cc05db49d806c7476863ad ]
Array of group descriptor block buffers can get rather large. In theory in can reach 1MB for perfectly valid filesystem and even more for maliciously crafted ones. Use kvmalloc() to allocate the array to avoid straining memory allocator with large order allocations unnecessarily.
--- fs/ext2/super.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
fs/ext2/super.c +3 -3
@@ -163,7 +163,7 @@ static void ext2_put_super (struct super_block * sb) db_count = sbi->s_gdb_count;for (i =0 ; i < db_count; i++)brelse (sbi->s_group_desc[i]); -kfree (sbi->s_group_desc); +kvfree (sbi->s_group_desc);kfree (sbi->s_debts);percpu_counter_destroy (&sbi->s_freeblocks_counter);percpu_counter_destroy (&sbi->s_freeinodes_counter);
@@ -1092,7 +1092,7 @@ static int ext2_fill_super(struct super_block *sb, void *data, int silent) } db_count = (sbi->s_groups_count +EXT2_DESC_PER_BLOCK (sb) -1 ) /EXT2_DESC_PER_BLOCK (sb); - sbi->s_group_desc =kmalloc_array (db_count, + sbi->s_group_desc =kvmalloc_array (db_count,sizeof (struct buffer_head *),GFP_KERNEL );if (sbi->s_group_desc ==NULL ) {
@@ -1218,7 +1218,7 @@ static int ext2_fill_super(struct super_block *sb, void *data, int silent)for (i =0 ; i < db_count; i++)brelse (sbi->s_group_desc[i]); failed_mount_group_desc: -kfree (sbi->s_group_desc); +kvfree (sbi->s_group_desc);kfree (sbi->s_debts); failed_mount:brelse (bh);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 828/862 nvme: handle effects after freeing the request
In reply to Greg Kroah-HartmanFrom: Keith Busch <[email protected]>
[ Upstream commit bc8fb906b0ff9339b4286698cb7cd9cd5b8c53eb ]
If a reset occurs after the scan work attempts to issue a command, the reset may quisce the admin queue, which blocks the scan work's command from dispatching. The scan work will not be able to complete while the queue is quiesced.
Meanwhile, the reset work will cancel all outstanding admin tags and wait until all requests have transitioned to idle, which includes the passthrough request. But the passthrough request won't be set to idle until after the scan_work flushes, so we're deadlocked.
Fix this by handling the end effects after the request has been freed.
--- drivers/nvme/host/core.c | 17 ++++++----------- drivers/nvme/host/ioctl.c | 9 ++++++++- drivers/nvme/host/nvme.h | 4 +++- drivers/nvme/target/passthru.c | 7 ++++++- 4 files changed, 23 insertions(+), 14 deletions(-)
drivers/nvme/host/core.c +6 -11
@@ -1111,8 +1111,8 @@ static u32 nvme_passthru_start(struct nvme_ctrl *ctrl, struct nvme_ns *ns,return effects; } -static void nvme_passthru_end (struct nvme_ctrl *ctrl,u32 effects, -struct nvme_command *cmd,int status) +void nvme_passthru_end (struct nvme_ctrl *ctrl,u32 effects, +struct nvme_command *cmd,int status) {if (effects &NVME_CMD_EFFECTS_CSE_MASK ) {nvme_unfreeze (ctrl);
@@ -1148,21 +1148,16 @@ static void nvme_passthru_end(struct nvme_ctrl *ctrl, u32 effects,break ; } } +EXPORT_SYMBOL_NS_GPL (nvme_passthru_end,NVME_TARGET_PASSTHRU ); -int nvme_execute_passthru_rq (struct request *rq) +int nvme_execute_passthru_rq (struct request *rq,u32 *effects) {struct nvme_command *cmd =nvme_req (rq)->cmd;struct nvme_ctrl *ctrl =nvme_req (rq)->ctrl;struct nvme_ns *ns = rq->q->queuedata; -u32 effects; -int ret; - effects =nvme_passthru_start (ctrl, ns, cmd->common.opcode); - ret =nvme_execute_rq (rq, false); -if (effects)/* nothing to be done for zero cmd effects */ -nvme_passthru_end (ctrl, effects, cmd, ret); - -return ret; + *effects =nvme_passthru_start (ctrl, ns, cmd->common.opcode); +return nvme_execute_rq (rq, false); }EXPORT_SYMBOL_NS_GPL (nvme_execute_passthru_rq,NVME_TARGET_PASSTHRU );
drivers/nvme/host/ioctl.c +8 -1
@@ -136,9 +136,11 @@ static int nvme_submit_user_cmd(struct request_queue *q, unsigned bufflen, void __user *meta_buffer, unsigned meta_len, u32 meta_seed, u64 *result, unsigned timeout, bool vec) { + struct nvme_ctrl *ctrl;struct request *req;void *meta =NULL ;struct bio *bio; +u32 effects;int ret; req = nvme_alloc_user_request(q, cmd, ubuffer, bufflen, meta_buffer,
@@ -147,8 +149,9 @@ static int nvme_submit_user_cmd(struct request_queue *q,return PTR_ERR (req); bio = req->bio; + ctrl =nvme_req (req)->ctrl; - ret =nvme_execute_passthru_rq (req); + ret =nvme_execute_passthru_rq (req, &effects);if (result) *result =le64_to_cpu (nvme_req (req)->result.u64);
@@ -158,6 +161,10 @@ static int nvme_submit_user_cmd(struct request_queue *q,if (bio)blk_rq_unmap_user (bio);blk_mq_free_request (req); + +if (effects) +nvme_passthru_end (ctrl, effects, cmd, ret); +return ret; }
drivers/nvme/host/nvme.h +3 -1
@@ -1023,7 +1023,9 @@ static inline void nvme_auth_free(struct nvme_ctrl *ctrl) {};u32 nvme_command_effects (struct nvme_ctrl *ctrl,struct nvme_ns *ns,u8 opcode); -int nvme_execute_passthru_rq (struct request *rq); +int nvme_execute_passthru_rq (struct request *rq,u32 *effects); +void nvme_passthru_end (struct nvme_ctrl *ctrl,u32 effects, +struct nvme_command *cmd,int status);struct nvme_ctrl *nvme_ctrl_from_file (struct file *file);struct nvme_ns *nvme_find_get_ns (struct nvme_ctrl *ctrl,unsigned nsid);void nvme_put_ns (struct nvme_ns *ns);
drivers/nvme/target/passthru.c +6 -1
@@ -215,9 +215,11 @@ static void nvmet_passthru_execute_cmd_work(struct work_struct *w) { struct nvmet_req *req = container_of(w, struct nvmet_req, p.work);struct request *rq = req->p.rq; +struct nvme_ctrl *ctrl =nvme_req (rq)->ctrl; +u32 effects;int status; - status =nvme_execute_passthru_rq (rq); + status =nvme_execute_passthru_rq (rq, &effects);if (status ==NVME_SC_SUCCESS && req->cmd->common.opcode == nvme_admin_identify) {
@@ -238,6 +240,9 @@ static void nvmet_passthru_execute_cmd_work(struct work_struct *w) req->cqe->result =nvme_req (rq)->result;nvmet_req_complete (req, status);blk_mq_free_request (rq); + +if (effects) +nvme_passthru_end (ctrl, effects, req->cmd, status); } static void nvmet_passthru_req_done(struct request *rq,
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 829/862 nvme: copy firmware_rev on each init
In reply to Greg Kroah-HartmanFrom: Keith Busch <[email protected]>
[ Upstream commit a8eb6c1ba48bddea82e8d74cbe6e119f006be97d ]
The firmware revision can change on after a reset so copy the most recent info each time instead of just the first time, otherwise the sysfs firmware_rev entry may contain stale data.
--- drivers/nvme/host/core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/nvme/host/core.c +2 -1
@@ -2889,7 +2889,6 @@ static int nvme_init_subsystem(struct nvme_ctrl *ctrl, struct nvme_id_ctrl *id)nvme_init_subnqn (subsys, ctrl, id);memcpy (subsys->serial, id->sn,sizeof (subsys->serial));memcpy (subsys->model, id->mn,sizeof (subsys->model)); -memcpy (subsys->firmware_rev, id->fr,sizeof (subsys->firmware_rev)); subsys->vendor_id =le16_to_cpu (id->vid); subsys->cmic = id->cmic;
@@ -3108,6 +3107,8 @@ static int nvme_init_identify(struct nvme_ctrl *ctrl) ctrl->quirks |= core_quirks[i].quirks; } } +memcpy (ctrl->subsys->firmware_rev, id->fr, +sizeof (ctrl->subsys->firmware_rev));if (force_apst && (ctrl->quirks &NVME_QUIRK_NO_DEEPEST_PS )) {dev_warn (ctrl->device,"forcibly allowing all power states due to nvme_core.force_apst -- use at your own risk\n" );
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 830/862 nvmet-tcp: add bounds check on Transfer Tag
In reply to Greg Kroah-HartmanFrom: Varun Prakash <[email protected]>
[ Upstream commit b6a545ffa2c192b1e6da4a7924edac5ba9f4ea2b ]
ttag is used as an index to get cmd in nvmet_tcp_handle_h2c_data_pdu(), add a bounds check to avoid out-of-bounds access.
--- drivers/nvme/target/tcp.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)
drivers/nvme/target/tcp.c +9 -2
@@ -935,10 +935,17 @@ static int nvmet_tcp_handle_h2c_data_pdu(struct nvmet_tcp_queue *queue)struct nvme_tcp_data_pdu *data = &queue->pdu.data;struct nvmet_tcp_cmd *cmd; -if (likely (queue->nr_cmds)) +if (likely (queue->nr_cmds)) { +if (unlikely (data->ttag >= queue->nr_cmds)) { +pr_err ("queue %d: received out of bound ttag %u, nr_cmds %u\n" , + queue->idx, data->ttag, queue->nr_cmds); +nvmet_tcp_fatal_error (queue); +return -EPROTO ; + } cmd = &queue->cmds[data->ttag]; -else + }else { cmd = &queue->connect; + }if (le32_to_cpu (data->data_offset) != cmd->rbytes_done) { pr_err("ttag %u unexpected data offset %u (expected %u)\n",
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 831/862 usb: idmouse: fix an uninit-value in idmouse_open
In reply to Greg Kroah-HartmanFrom: Dongliang Mu <[email protected]>
[ Upstream commit bce2b0539933e485d22d6f6f076c0fcd6f185c4c ]
In idmouse_create_image, if any ftip_command fails, it will go to the reset label. However, this leads to the data in bulk_in_buffer[HEADER..IMGSIZE] uninitialized. And the check for valid image incurs an uninitialized dereference.
Fix this by moving the check before reset label since this check only be valid if the data after bulk_in_buffer[HEADER] has concrete data.
Note that this is found by KMSAN, so only kernel compilation is tested.
--- drivers/usb/misc/idmouse.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/usb/misc/idmouse.c +4 -4
@@ -177,10 +177,6 @@ static int idmouse_create_image(struct usb_idmouse *dev) bytes_read += bulk_read; } -/* reset the device */ -reset: -ftip_command (dev,FTIP_RELEASE ,0 ,0 ); -/* check for valid image */ /* right border should be black (0x00) */ for (bytes_read =sizeof (HEADER )-1 +WIDTH -1 ; bytes_read <IMGSIZE ; bytes_read +=WIDTH )
@@ -192,6 +188,10 @@ static int idmouse_create_image(struct usb_idmouse *dev)if (dev->bulk_in_buffer[bytes_read] !=0xFF )return -EAGAIN ; +/* reset the device */ +reset: +ftip_command (dev,FTIP_RELEASE ,0 ,0 ); +/* should be IMGSIZE == 65040 */ dev_dbg (&dev->interface->dev,"read %d bytes fingerprint data\n" , bytes_read);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 832/862 blk-mq: use quiesced elevator switch when reinitializing queues
In reply to Greg Kroah-HartmanFrom: Keith Busch <[email protected]>
[ Upstream commit 8237c01f1696bc53c470493bf1fe092a107648a6 ]
The hctx's run_work may be racing with the elevator switch when reinitializing hardware queues. The queue is merely frozen in this context, but that only prevents requests from allocating and doesn't stop the hctx work from running. The work may get an elevator pointer that's being torn down, and can result in use-after-free errors and kernel panics (example below). Use the quiesced elevator switch instead, and make the previous one static since it is now only used locally.
nvme nvme0: resetting controller
nvme nvme0: 32/0/0 default/read/poll queues
BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 80000020c8861067 P4D 80000020c8861067 PUD 250f8c8067 PMD 0 Oops: 0000 [#1] SMP PTI Workqueue: kblockd blk_mq_run_work_fn RIP: 0010:kyber_has_work+0x29/0x70
...
Call Trace: __blk_mq_do_dispatch_sched+0x83/0x2b0 __blk_mq_sched_dispatch_requests+0x12e/0x170 blk_mq_sched_dispatch_requests+0x30/0x60 __blk_mq_run_hw_queue+0x2b/0x50 process_one_work+0x1ef/0x380 worker_thread+0x2d/0x3e0
--- block/blk-mq.c | 6 +++--- block/blk.h | 3 +-- block/elevator.c | 4 ++-- 3 files changed, 6 insertions(+), 7 deletions(-)
block/blk-mq.c +3 -3
@@ -4473,14 +4473,14 @@ static bool blk_mq_elv_switch_none(struct list_head *head,list_add (&qe->node, head);/* -* After elevator_switch_mq, the previous elevator_queue will be +* After elevator_switch, the previous elevator_queue will be * released by elevator_release. The reference of the io scheduler * module get by elevator_get will also be put. So we need to get * a reference of the io scheduler module here to prevent it to be * removed. */ __module_get (qe->type->elevator_owner); -elevator_switch_mq (q,NULL ); +elevator_switch (q,NULL );mutex_unlock (&q->sysfs_lock);return true;
@@ -4512,7 +4512,7 @@ static void blk_mq_elv_switch_back(struct list_head *head,kfree (qe);mutex_lock (&q->sysfs_lock); -elevator_switch_mq (q, t); +elevator_switch (q, t);mutex_unlock (&q->sysfs_lock); }
block/blk.h +1 -2
@@ -270,8 +270,7 @@ bool blk_bio_list_merge(struct request_queue *q, struct list_head *list,void blk_insert_flush (struct request *rq); -int elevator_switch_mq (struct request_queue *q, -struct elevator_type *new_e); +int elevator_switch (struct request_queue *q,struct elevator_type *new_e);void elevator_exit (struct request_queue *q);int elv_register_queue (struct request_queue *q,bool uevent);void elv_unregister_queue (struct request_queue *q);
block/elevator.c +2 -2
@@ -588,7 +588,7 @@ void elv_unregister(struct elevator_type *e) }EXPORT_SYMBOL_GPL (elv_unregister); -int elevator_switch_mq (struct request_queue *q, +static int elevator_switch_mq (struct request_queue *q,struct elevator_type *new_e) {int ret;
@@ -723,7 +723,7 @@ void elevator_init_mq(struct request_queue *q)* need for the new one. this way we have a chance of going back to the old * one, if the new one fails init for some reason. */ -static int elevator_switch (struct request_queue *q,struct elevator_type *new_e) +int elevator_switch (struct request_queue *q,struct elevator_type *new_e) {int err;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 833/862 hwmon (occ): Retry for checksum failure
In reply to Greg Kroah-HartmanFrom: Eddie James <[email protected]>
[ Upstream commit dbed963ed62c4c2b8870a02c8b7dcb0c2af3ee0b ]
Due to the OCC communication design with a shared SRAM area, checkum errors are expected due to corrupted buffer from OCC communications with other system components. Therefore, retry the command twice in the event of a checksum failure.
--- drivers/hwmon/occ/p9_sbe.c | 17 ++++++++++++----- 1 file changed, 12 insertions(+), 5 deletions(-)
drivers/hwmon/occ/p9_sbe.c +12 -5
@@ -14,6 +14,8 @@#include "common.h" +#define OCC_CHECKSUM_RETRIES 3 +struct p9_sbe_occ {struct occ occ;bool sbe_error;
@@ -80,18 +82,23 @@ static bool p9_sbe_occ_save_ffdc(struct p9_sbe_occ *ctx, const void *resp,static int p9_sbe_occ_send_cmd (struct occ *occ,u8 *cmd,size_t len,void *resp,size_t resp_len) { +size_t original_resp_len = resp_len;struct p9_sbe_occ *ctx =to_p9_sbe_occ (occ); -int rc; +int rc, i; - rc =fsi_occ_submit (ctx->sbe, cmd, len, resp, &resp_len); -if (rc <0 ) { +for (i =0 ; i <OCC_CHECKSUM_RETRIES ; ++i) { + rc =fsi_occ_submit (ctx->sbe, cmd, len, resp, &resp_len); +if (rc >=0 ) +break ;if (resp_len) {if (p9_sbe_occ_save_ffdc (ctx, resp, resp_len))sysfs_notify (&occ->bus_dev->kobj,NULL , bin_attr_ffdc.attr.name); +return rc; } - -return rc; +if (rc != -EBADE ) +return rc; + resp_len = original_resp_len; }switch (((struct occ_response *)resp)->return_status) {
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 834/862 fsi: occ: Prevent use after free
In reply to Greg Kroah-HartmanFrom: Eddie James <[email protected]>
[ Upstream commit d3e1e24604031b0d83b6c2d38f54eeea265cfcc0 ]
Use get_device and put_device in the open and close functions to make sure the device doesn't get freed while a file descriptor is open.
Also, lock around the freeing of the device buffer and check the buffer before using it in the submit function.
--- drivers/fsi/fsi-occ.c | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-)
drivers/fsi/fsi-occ.c +15 -3
@@ -94,6 +94,7 @@ static int occ_open(struct inode *inode, struct file *file) client->occ = occ;mutex_init (&client->lock); file->private_data = client; +get_device (occ->dev);/* We allocate a 1-page buffer, make sure it all fits */ BUILD_BUG_ON ((OCC_CMD_DATA_BYTES +3 ) >PAGE_SIZE );
@@ -197,6 +198,7 @@ static int occ_release(struct inode *inode, struct file *file) {struct occ_client *client = file->private_data; +put_device (client->occ->dev);free_page ((unsigned long )client->buffer);kfree (client);
@@ -493,12 +495,19 @@ int fsi_occ_submit(struct device *dev, const void *request, size_t req_len,for (i =1 ; i < req_len -2 ; ++i) checksum += byte_request[i]; -mutex_lock (&occ->occ_lock); + rc =mutex_lock_interruptible (&occ->occ_lock); +if (rc) +return rc; occ->client_buffer = response; occ->client_buffer_size = user_resp_len; occ->client_response_size =0 ; +if (!occ->buffer) { + rc = -ENOENT ; + goto done; + } +/* * Get a sequence number and update the counter. Avoid a sequence * number of 0 which would pass the response check below even if the
@@ -671,10 +680,13 @@ static int occ_remove(struct platform_device *pdev) {struct occ *occ =platform_get_drvdata (pdev); -kvfree (occ->buffer); -misc_deregister (&occ->mdev); +mutex_lock (&occ->occ_lock); +kvfree (occ->buffer); + occ->buffer =NULL ; +mutex_unlock (&occ->occ_lock); +device_for_each_child (&pdev->dev,NULL , occ_unregister_child);ida_simple_remove (&occ_ida, occ->idx);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 835/862 fsi: master-ast-cf: Fix missing of_node_put in fsi_master_acf_probe
In reply to Greg Kroah-HartmanFrom: Lv Ruyi <[email protected]>
[ Upstream commit 182d98e00e4745fe253cb0c24c63bbac253464a2 ]
of_parse_phandle returns node pointer with refcount incremented, use of_node_put() on it when done.
--- drivers/fsi/fsi-master-ast-cf.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/fsi/fsi-master-ast-cf.c +2 -0
@@ -1324,12 +1324,14 @@ static int fsi_master_acf_probe(struct platform_device *pdev) } master->cvic =devm_of_iomap (&pdev->dev, np,0 ,NULL );if (IS_ERR (master->cvic)) { +of_node_put (np); rc =PTR_ERR (master->cvic);dev_err (&pdev->dev,"Error %d mapping CVIC\n" , rc); goto err_free; } rc =of_property_read_u32 (np,"copro-sw-interrupts" , &master->cvic_sw_irq); +of_node_put (np);if (rc) {dev_err (&pdev->dev,"Can't find coprocessor SW interrupt\n" ); goto err_free;
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 836/862 dmaengine: dw-edma: Remove runtime PM support
In reply to Greg Kroah-HartmanFrom: Manivannan Sadhasivam <[email protected]>
[ Upstream commit a0188eb6e71c93ab7dd9bfa4305fac43c70db309 ]
Currently, the dw-edma driver enables the runtime_pm for parent device (chip->dev) and increments/decrements the refcount during alloc/free chan resources callbacks.
This leads to a problem when the eDMA driver has been probed, but the channels were not used. This scenario can happen when the DW PCIe driver probes eDMA driver successfully, but the PCI EPF driver decides not to use eDMA channels and use iATU instead for PCI transfers.
In this case, the underlying device would be runtime suspended due to pm_runtime_enable() in dw_edma_probe() and the PCI EPF driver would have no knowledge of it.
Ideally, the eDMA driver should not be the one doing the runtime PM of the parent device. The responsibility should instead belong to the client drivers like PCI EPF.
So let's remove the runtime PM support from eDMA driver.
--- drivers/dma/dw-edma/dw-edma-core.c | 12 ------------ 1 file changed, 12 deletions(-)
drivers/dma/dw-edma/dw-edma-core.c +0 -12
@@ -9,7 +9,6 @@#include <linux/module.h> #include <linux/device.h> #include <linux/kernel.h> -#include <linux/pm_runtime.h> #include <linux/dmaengine.h> #include <linux/err.h> #include <linux/interrupt.h>
@@ -682,15 +681,12 @@ static int dw_edma_alloc_chan_resources(struct dma_chan *dchan)if (chan->status !=EDMA_ST_IDLE )return -EBUSY ; -pm_runtime_get (chan->dw->chip->dev); -return 0 ; }static void dw_edma_free_chan_resources (struct dma_chan *dchan) {unsigned long timeout = jiffies +msecs_to_jiffies (5000 ); -struct dw_edma_chan *chan =dchan2dw_edma_chan (dchan);int ret;while (time_before (jiffies, timeout)) {
@@ -703,8 +699,6 @@ static void dw_edma_free_chan_resources(struct dma_chan *dchan)cpu_relax (); } - -pm_runtime_put (chan->dw->chip->dev); } static int dw_edma_channel_setup(struct dw_edma *dw, bool write,
@@ -977,9 +971,6 @@ int dw_edma_probe(struct dw_edma_chip *chip)if (err) goto err_irq_free; -/* Power management */ -pm_runtime_enable (dev); -/* Turn debugfs on */ dw_edma_v0_core_debugfs_on (dw);
@@ -1009,9 +1000,6 @@ int dw_edma_remove(struct dw_edma_chip *chip)for (i = (dw->nr_irqs -1 ); i >=0 ; i--)free_irq (chip->ops->irq_vector (dev, i), &dw->irq[i]); -/* Power management */ -pm_runtime_disable (dev); -/* Deregister eDMA device */ dma_async_device_unregister (&dw->wr_edma); list_for_each_entry_safe(chan, _chan, &dw->wr_edma.channels,
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 837/862 usb: typec: ucsi: Dont warn on probe deferral
In reply to Greg Kroah-HartmanFrom: Wayne Chang <[email protected]>
[ Upstream commit fce703a991b7e8c7e1371de95b9abaa832ecf9c3 ]
Deferred probe is an expected return value for fwnode_usb_role_switch_get(). Given that the driver deals with it properly, there's no need to output a warning that may potentially confuse users.
--
V2 -> V3: remove the Fixes and Cc
V1 -> V2: adjust the coding style for better reading format.
drivers/usb/typec/ucsi/ucsi.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-)
--- drivers/usb/typec/ucsi/ucsi.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-)
drivers/usb/typec/ucsi/ucsi.c +3 -5
@@ -1067,11 +1067,9 @@ static int ucsi_register_port(struct ucsi *ucsi, int index) cap->fwnode =ucsi_find_fwnode (con); con->usb_role_sw =fwnode_usb_role_switch_get (cap->fwnode); -if (IS_ERR (con->usb_role_sw)) { -dev_err (ucsi->dev,"con%d: failed to get usb role switch\n" , - con->num); -return PTR_ERR (con->usb_role_sw); - } +if (IS_ERR (con->usb_role_sw)) +return dev_err_probe (ucsi->dev,PTR_ERR (con->usb_role_sw), +"con%d: failed to get usb role switch\n" , con->num);/* Delay other interactions with the con until registration is complete */ mutex_lock (&con->lock);
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 838/862 clk: bcm2835: Round UART input clock up
In reply to Greg Kroah-HartmanFrom: Ivan T. Ivanov <[email protected]>
[ Upstream commit f690a4d7a8f66430662975511c86819dc9965bcc ]
It was reported that RPi3[1] and RPi Zero 2W boards have issues with the Bluetooth. It turns out that when switching from initial to operation speed host and device no longer can talk each other because host uses incorrect UART baud rate.
The UART driver used in this case is amba-pl011. Original fix, see below Github link[2], was inside pl011 module, but somehow it didn't look as the right place to fix. Beside that this original rounding function is not exactly perfect for all possible clock values. So I deiced to move the hack to the platform which actually need it.
The UART clock is initialised to be as close to the requested frequency as possible without exceeding it. Now that there is a clock manager that returns the actual frequencies, an expected 48MHz clock is reported as 47999625. If the requested baud rate == requested clock/16, there is no headroom and the slight reduction in actual clock rate results in failure.
If increasing a clock by less than 0.1% changes it from ..999.. to ..000.., round it up.
[1] https://bugzilla.suse.com/show_bug.cgi?id=1188238
[2] https://github.com/raspberrypi/linux/commit/ab3f1b39537f6d3825b8873006fbe2fc5ff057b7
--- drivers/clk/bcm/clk-bcm2835.c | 35 +++++++++++++++++++++++++++++++++-- 1 file changed, 33 insertions(+), 2 deletions(-)
drivers/clk/bcm/clk-bcm2835.c +33 -2
@@ -30,6 +30,7 @@#include <linux/debugfs.h> #include <linux/delay.h> #include <linux/io.h> +#include <linux/math.h> #include <linux/module.h> #include <linux/of_device.h> #include <linux/platform_device.h>
@@ -502,6 +503,8 @@ struct bcm2835_clock_data {bool low_jitter;u32 tcnt_mux; + +bool round_up; };struct bcm2835_gate_data {
@@ -993,12 +996,34 @@ static unsigned long bcm2835_clock_rate_from_divisor(struct bcm2835_clock *clockreturn temp; } +static unsigned long bcm2835_round_rate (unsigned long rate) +{ +unsigned long scaler; +unsigned long limit; + + limit = rate /100000 ; + + scaler =1 ; +while (scaler < limit) + scaler *=10 ; + +/* +* If increasing a clock by less than 0.1% changes it +* from ..999.. to ..000.., round up. +*/ +if ((rate + scaler -1 ) / scaler %1000 ==0 ) + rate =roundup (rate, scaler); + +return rate; +} +static unsigned long bcm2835_clock_get_rate (struct clk_hw *hw,unsigned long parent_rate) {struct bcm2835_clock *clock =bcm2835_clock_from_hw (hw);struct bcm2835_cprman *cprman = clock->cprman;const struct bcm2835_clock_data *data = clock->data; +unsigned long rate;u32 div;if (data->int_bits ==0 && data->frac_bits ==0 )
@@ -1006,7 +1031,12 @@ static unsigned long bcm2835_clock_get_rate(struct clk_hw *hw, div =cprman_read (cprman, data->div_reg); -return bcm2835_clock_rate_from_divisor (clock, parent_rate, div); + rate =bcm2835_clock_rate_from_divisor (clock, parent_rate, div); + +if (data->round_up) + rate =bcm2835_round_rate (rate); + +return rate; }static void bcm2835_clock_wait_busy (struct bcm2835_clock *clock)
@@ -2143,7 +2173,8 @@ static const struct bcm2835_clk_desc clk_desc_array[] = { .div_reg = CM_UARTDIV, .int_bits = 10, .frac_bits = 12, - .tcnt_mux = 28), + .tcnt_mux = 28, + .round_up = true),/* TV encoder clock. Only operating frequency is 108Mhz. */ [BCM2835_CLOCK_VEC] = REGISTER_PER_CLK(
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 839/862 perf: Skip and warn on unknown format configN attrs
In reply to Greg Kroah-HartmanFrom: Rob Herring <[email protected]>
commit e552b7be12ed62357df84392efa525ecb01910fb upstream.
If the kernel exposes a new perf_event_attr field in a format attr, perf will return an error stating the specified PMU can't be found. For example, a format attr with 'config3:0-63' causes an error as config3 is unknown to perf. This causes a compatibility issue between a newer kernel with older perf tool.
Before this change with a kernel adding 'config3' I get:
$ perf record -e arm_spe// -- true
event syntax error: 'arm_spe//'
\___ Cannot find PMU `arm_spe'. Missing kernel support?
Run 'perf list' for a list of valid events Usage: perf record [<options>] [<command>]
or: perf record [<options>] -- <command> [<options>]
-e, --event <event> event selector. use 'perf list' to list
available events
After this change, I get:
$ perf record -e arm_spe// -- true WARNING: 'arm_spe_0' format 'inv_event_filter' requires 'perf_event_attr::config3' which is not supported by this version of perf! [ perf record: Woken up 2 times to write data ] [ perf record: Captured and wrote 0.091 MB perf.data ]
To support unknown configN formats, rework the YACC implementation to pass any config[0-9]+ format to perf_pmu__new_format() to handle with a warning.
--- tools/perf/util/parse-events.c | 3 +++ tools/perf/util/pmu.c | 17 +++++++++++++++++ tools/perf/util/pmu.h | 2 ++ tools/perf/util/pmu.l | 2 -- tools/perf/util/pmu.y | 15 ++++----------- 5 files changed, 26 insertions(+), 13 deletions(-)
tools/perf/util/parse-events.c +3 -0
@@ -254,6 +254,9 @@ __add_event(struct list_head *list, intstruct perf_cpu_map *cpus = pmu ?perf_cpu_map__get (pmu->cpus) : cpu_list ?perf_cpu_map__new (cpu_list) :NULL ; +if (pmu) +perf_pmu__warn_invalid_formats (pmu); +if (pmu && attr->type ==PERF_TYPE_RAW )perf_pmu__warn_invalid_config (pmu, attr->config, name);
tools/perf/util/pmu.c +17 -0
@@ -1005,6 +1005,23 @@ err:return NULL ; } +void perf_pmu__warn_invalid_formats (struct perf_pmu *pmu) +{ +struct perf_pmu_format *format; + +/* fake pmu doesn't have format list */ +if (pmu == &perf_pmu__fake) +return ; + +list_for_each_entry (format, &pmu->format, list) +if (format->value >=PERF_PMU_FORMAT_VALUE_CONFIG_END ) { +pr_warning ("WARNING: '%s' format '%s' requires 'perf_event_attr::config%d'" +"which is not supported by this version of perf!\n" , + pmu->name, format->name, format->value); +return ; + } +} +static struct perf_pmu *pmu_find (const char *name) {struct perf_pmu *pmu;
tools/perf/util/pmu.h +2 -0
@@ -17,6 +17,7 @@ enum {PERF_PMU_FORMAT_VALUE_CONFIG ,PERF_PMU_FORMAT_VALUE_CONFIG1 ,PERF_PMU_FORMAT_VALUE_CONFIG2 , + PERF_PMU_FORMAT_VALUE_CONFIG_END, };#define PERF_PMU_FORMAT_BITS 64
@@ -139,6 +140,7 @@ int perf_pmu__caps_parse(struct perf_pmuvoid perf_pmu__warn_invalid_config (struct perf_pmu *pmu,__u64 config,const char *name); +void perf_pmu__warn_invalid_formats (struct perf_pmu *pmu);bool perf_pmu__has_hybrid (void );int perf_pmu__match (char *pattern,char *name,char *tok);
tools/perf/util/pmu.l +0 -2
@@ -27,8 +27,6 @@ num_dec [0-9]+ {num_dec} { return value(10); } config { return PP_CONFIG; } -config1 { return PP_CONFIG1; } -config2 { return PP_CONFIG2; } - { return '-'; } : { return ':'; } , { return ','; }
tools/perf/util/pmu.y +4 -11
@@ -20,7 +20,7 @@ do { \ %} -%token PP_CONFIG PP_CONFIG1 PP_CONFIG2 +%token PP_CONFIG %token PP_VALUE PP_ERROR %type <num> PP_VALUE %type <bits> bit_term
@@ -47,18 +47,11 @@ PP_CONFIG ':' bits $3)); } | -PP_CONFIG1 ':' bits +PP_CONFIG PP_VALUE ':' bits { ABORT_ON(perf_pmu__new_format(format, name, - PERF_PMU_FORMAT_VALUE_CONFIG1, - $3)); -} -| -PP_CONFIG2 ':' bits -{ - ABORT_ON(perf_pmu__new_format(format, name, - PERF_PMU_FORMAT_VALUE_CONFIG2, - $3)); + $2, + $4)); } bits:
Greg Kroah-Hartman
maintainerPATCH 840/862 perf intel-pt: Fix segfault in intel_pt_print_info() with uClibc
In reply to Greg Kroah-HartmanFrom: Adrian Hunter <[email protected]>
commit 5a3d47071f0ced0431ef82a5fb6bd077ed9493db upstream.
uClibc segfaulted because NULL was passed as the format to fprintf().
That happened because one of the format strings was missing and intel_pt_print_info() didn't check that before calling fprintf().
Add the missing format string, and check format is not NULL before calling fprintf().
--- tools/perf/util/intel-pt.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
tools/perf/util/intel-pt.c +7 -2
@@ -4033,6 +4033,7 @@ static const char * const intel_pt_info_ [INTEL_PT_SNAPSHOT_MODE] = " Snapshot mode %"PRId64"\n", [INTEL_PT_PER_CPU_MMAPS] = " Per-cpu maps %"PRId64"\n", [INTEL_PT_MTC_BIT] = " MTC bit %#"PRIx64"\n", + [INTEL_PT_MTC_FREQ_BITS] = " MTC freq bits %#"PRIx64"\n", [INTEL_PT_TSC_CTC_N] = " TSC:CTC numerator %"PRIu64"\n", [INTEL_PT_TSC_CTC_D] = " TSC:CTC denominator %"PRIu64"\n", [INTEL_PT_CYC_BIT] = " CYC bit %#"PRIx64"\n",
@@ -4047,8 +4048,12 @@ static void intel_pt_print_info(__u64 *aif (!dump_trace)return ; -for (i = start; i <= finish; i++) -fprintf (stdout, intel_pt_info_fmts[i], arr[i]); +for (i = start; i <= finish; i++) { +const char *fmt = intel_pt_info_fmts[i]; + +if (fmt) +fprintf (stdout, fmt, arr[i]); + } }static void intel_pt_print_info_str (const char *name,const char *str)
Greg Kroah-Hartman
maintainerPATCH 841/862 perf intel-pt: Fix system_wide dummy event for hybrid
In reply to Greg Kroah-HartmanFrom: Adrian Hunter <[email protected]>
commit 6cef7dab3e2e5cb23a13569c3880c0532326748c upstream.
User space tasks can migrate between CPUs, so when tracing selected CPUs, system-wide sideband is still needed, however evlist->core.has_user_cpus is not set in the hybrid case, so check the target cpu_list instead.
--- tools/perf/arch/x86/util/intel-pt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/perf/arch/x86/util/intel-pt.c +1 -1
@@ -871,7 +871,7 @@ static int intel_pt_recording_options(st* User space tasks can migrate between CPUs, so when tracing * selected CPUs, sideband for all CPUs is still needed. */ - need_system_wide_tracking = evlist->core.has_user_cpus && + need_system_wide_tracking = opts->target.cpu_list && !intel_pt_evsel->core.attr.exclude_user; tracking_evsel =evlist__add_aux_dummy (evlist, need_system_wide_tracking);
Greg Kroah-Hartman
maintainerPATCH 842/862 io_uring/net: refactor io_sr_msg types
In reply to Greg Kroah-HartmanFrom: Pavel Begunkov <[email protected]>
[ upstream commit 0b048557db761d287777360a100e1d010760d209 ]
In preparation for using struct io_sr_msg for zerocopy sends, clean up types. First, flags can be u16 as it's provided by the userspace in u16 ioprio, as well as addr_len. This saves us 4 bytes. Also use unsigned for size and done_io, both are as well limited to u32.
--- io_uring/net.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-)
io_uring/net.c +7 -7
@@ -56,21 +56,21 @@ struct io_sr_msg {struct user_msghdr __user *umsg;void __user *buf; }; +unsigned len; +unsigned done_io;unsigned msg_flags; -unsigned flags; -size_t len; -size_t done_io; +u16 flags; };struct io_sendzc {struct file *file;void __user *buf; -size_t len; +unsigned len; +unsigned done_io;unsigned msg_flags; -unsigned flags; -unsigned addr_len; +u16 flags; +u16 addr_len;void __user *addr; -size_t done_io;struct io_kiocb *notif; };
Greg Kroah-Hartman
maintainerPATCH 843/862 io_uring/net: use io_sr_msg for sendzc
In reply to Greg Kroah-HartmanFrom: Pavel Begunkov <[email protected]>
[ upstream commit ac9e5784bbe72f4f603d1af84760ec09bc0b5ccd ]
Reuse struct io_sr_msg for zerocopy sends, which is handy. There is only one zerocopy specific field, namely .notif, and we have enough space for it.
--- io_uring/net.c | 18 +++++------------- 1 file changed, 5 insertions(+), 13 deletions(-)
io_uring/net.c +5 -13
@@ -60,15 +60,7 @@ struct io_sr_msg {unsigned done_io;unsigned msg_flags;u16 flags; -}; - -struct io_sendzc { -struct file *file; -void __user *buf; -unsigned len; -unsigned done_io; -unsigned msg_flags; -u16 flags; +/* used only for sendzc */ u16 addr_len;void __user *addr;struct io_kiocb *notif;
@@ -188,7 +180,7 @@ static int io_sendmsg_copy_hdr(struct ioint io_sendzc_prep_async (struct io_kiocb *req) { - struct io_sendzc *zc = io_kiocb_to_cmd(req, struct io_sendzc); + struct io_sr_msg *zc = io_kiocb_to_cmd(req, struct io_sr_msg);struct io_async_msghdr *io;int ret;
@@ -885,7 +877,7 @@ out_free:void io_sendzc_cleanup (struct io_kiocb *req) { - struct io_sendzc *zc = io_kiocb_to_cmd(req, struct io_sendzc); + struct io_sr_msg *zc = io_kiocb_to_cmd(req, struct io_sr_msg); zc->notif->flags |=REQ_F_CQE_SKIP ;io_notif_flush (zc->notif);
@@ -894,7 +886,7 @@ void io_sendzc_cleanup(struct io_kiocb *int io_sendzc_prep (struct io_kiocb *req,const struct io_uring_sqe *sqe) { - struct io_sendzc *zc = io_kiocb_to_cmd(req, struct io_sendzc); + struct io_sr_msg *zc = io_kiocb_to_cmd(req, struct io_sr_msg);struct io_ring_ctx *ctx = req->ctx;struct io_kiocb *notif;
@@ -1000,7 +992,7 @@ static int io_sg_from_iter(struct sock *int io_sendzc (struct io_kiocb *req,unsigned int issue_flags) {struct sockaddr_storage __address, *addr =NULL ; - struct io_sendzc *zc = io_kiocb_to_cmd(req, struct io_sendzc); + struct io_sr_msg *zc = io_kiocb_to_cmd(req, struct io_sr_msg);struct msghdr msg;struct iovec iov;struct socket *sock;
Greg Kroah-Hartman
maintainerPATCH 844/862 io_uring/net: dont lose partial send_zc on fail
In reply to Greg Kroah-HartmanFrom: Pavel Begunkov <[email protected]>
[ upstream commit 5693bcce892d7b8b15a7a92b011d3d40a023b53c ]
Partial zc send may end up in io_req_complete_failed(), which not only would return invalid result but also mask out the notification leading to lifetime issues.
--- io_uring/net.c | 16 ++++++++++++++++ io_uring/net.h | 1 + io_uring/opdef.c | 1 + 3 files changed, 18 insertions(+)
io_uring/net.c +16 -0
@@ -1093,6 +1093,22 @@ void io_sendrecv_fail(struct io_kiocb *rio_req_set_res (req, res, req->cqe.flags); } +void io_send_zc_fail (struct io_kiocb *req) +{ + struct io_sr_msg *sr = io_kiocb_to_cmd(req, struct io_sr_msg); +int res = req->cqe.res; + +if (req->flags &REQ_F_PARTIAL_IO ) { +if (req->flags &REQ_F_NEED_CLEANUP ) { +io_notif_flush (sr->notif); + sr->notif =NULL ; + req->flags &= ~REQ_F_NEED_CLEANUP ; + } + res = sr->done_io; + } +io_req_set_res (req, res, req->cqe.flags); +} +int io_accept_prep (struct io_kiocb *req,const struct io_uring_sqe *sqe) { struct io_accept *accept = io_kiocb_to_cmd(req, struct io_accept);
io_uring/net.h +1 -0
@@ -58,6 +58,7 @@ int io_connect(struct io_kiocb *req, unsint io_sendzc (struct io_kiocb *req,unsigned int issue_flags);int io_sendzc_prep (struct io_kiocb *req,const struct io_uring_sqe *sqe);void io_sendzc_cleanup (struct io_kiocb *req); +void io_send_zc_fail (struct io_kiocb *req);void io_netmsg_cache_free (struct io_cache_entry *entry);#else
io_uring/opdef.c +1 -0
@@ -494,6 +494,7 @@ const struct io_op_def io_op_defs[] = { .issue = io_sendzc, .prep_async = io_sendzc_prep_async, .cleanup = io_sendzc_cleanup, + .fail = io_send_zc_fail, #else .prep = io_eopnotsupp_prep,#endif
Greg Kroah-Hartman
maintainerPATCH 845/862 io_uring/net: rename io_sendzc()
In reply to Greg Kroah-HartmanFrom: Pavel Begunkov <[email protected]>
[ upstream commit b0e9b5517eb12fa80c72e205fe28534c2e2f39b9 ]
Simple renaming of io_sendzc*() functions in preparatio to adding a zerocopy sendmsg variant.
--- io_uring/net.c | 6 +++--- io_uring/net.h | 6 +++--- io_uring/opdef.c | 6 +++--- 3 files changed, 9 insertions(+), 9 deletions(-)
io_uring/net.c +3 -3
@@ -875,7 +875,7 @@ out_free:return ret; } -void io_sendzc_cleanup (struct io_kiocb *req) +void io_send_zc_cleanup (struct io_kiocb *req) { struct io_sr_msg *zc = io_kiocb_to_cmd(req, struct io_sr_msg);
@@ -884,7 +884,7 @@ void io_sendzc_cleanup(struct io_kiocb * zc->notif =NULL ; } -int io_sendzc_prep (struct io_kiocb *req,const struct io_uring_sqe *sqe) +int io_send_zc_prep (struct io_kiocb *req,const struct io_uring_sqe *sqe) { struct io_sr_msg *zc = io_kiocb_to_cmd(req, struct io_sr_msg);struct io_ring_ctx *ctx = req->ctx;
@@ -989,7 +989,7 @@ static int io_sg_from_iter(struct sock *return ret; } -int io_sendzc (struct io_kiocb *req,unsigned int issue_flags) +int io_send_zc (struct io_kiocb *req,unsigned int issue_flags) {struct sockaddr_storage __address, *addr =NULL ; struct io_sr_msg *zc = io_kiocb_to_cmd(req, struct io_sr_msg);
io_uring/net.h +3 -3
@@ -55,9 +55,9 @@ int io_connect_prep_async(struct io_kiocint io_connect_prep (struct io_kiocb *req,const struct io_uring_sqe *sqe);int io_connect (struct io_kiocb *req,unsigned int issue_flags); -int io_sendzc (struct io_kiocb *req,unsigned int issue_flags); -int io_sendzc_prep (struct io_kiocb *req,const struct io_uring_sqe *sqe); -void io_sendzc_cleanup (struct io_kiocb *req); +int io_send_zc (struct io_kiocb *req,unsigned int issue_flags); +int io_send_zc_prep (struct io_kiocb *req,const struct io_uring_sqe *sqe); +void io_send_zc_cleanup (struct io_kiocb *req);void io_send_zc_fail (struct io_kiocb *req);void io_netmsg_cache_free (struct io_cache_entry *entry);
io_uring/opdef.c +3 -3
@@ -490,10 +490,10 @@ const struct io_op_def io_op_defs[] = { .manual_alloc = 1,#if defined(CONFIG_NET ) .async_size = sizeof(struct io_async_msghdr), - .prep = io_sendzc_prep, - .issue = io_sendzc, + .prep = io_send_zc_prep, + .issue = io_send_zc, .prep_async = io_sendzc_prep_async, - .cleanup = io_sendzc_cleanup, + .cleanup = io_send_zc_cleanup, .fail = io_send_zc_fail, #else .prep = io_eopnotsupp_prep,
Greg Kroah-Hartman
maintainerPATCH 846/862 io_uring/net: dont skip notifs for failed requests
In reply to Greg Kroah-HartmanFrom: Pavel Begunkov <[email protected]>
[ upstream commit 6ae91ac9a6aa7d6005c3c6d0f4d263fbab9f377f ]
We currently only add a notification CQE when the send succeded, i.e. cqe.res >= 0. However, it'd be more robust to do buffer notifications for failed requests as well in case drivers decide do something fanky.
Always return a buffer notification after initial prep, don't hide it. This behaviour is better aligned with documentation and the patch also helps the userspace to respect it.
--- io_uring/net.c | 22 ++++++---------------- 1 file changed, 6 insertions(+), 16 deletions(-)
io_uring/net.c +6 -16
@@ -879,7 +879,6 @@ void io_send_zc_cleanup(struct io_kiocb { struct io_sr_msg *zc = io_kiocb_to_cmd(req, struct io_sr_msg); - zc->notif->flags |=REQ_F_CQE_SKIP ;io_notif_flush (zc->notif); zc->notif =NULL ; }
@@ -996,7 +995,7 @@ int io_send_zc(struct io_kiocb *req, unsstruct msghdr msg;struct iovec iov;struct socket *sock; -unsigned msg_flags, cflags; +unsigned msg_flags;int ret, min_ret =0 ; sock =sock_from_file (req->file);
@@ -1064,8 +1063,6 @@ int io_send_zc(struct io_kiocb *req, uns req->flags |=REQ_F_PARTIAL_IO ;return io_setup_async_addr (req, addr, issue_flags); } -if (ret <0 && !zc->done_io) - zc->notif->flags |=REQ_F_CQE_SKIP ;if (ret == -ERESTARTSYS ) ret = -EINTR ;req_set_fail (req);
@@ -1078,8 +1075,7 @@ int io_send_zc(struct io_kiocb *req, unsio_notif_flush (zc->notif); req->flags &= ~REQ_F_NEED_CLEANUP ; - cflags = ret >=0 ?IORING_CQE_F_MORE :0 ; -io_req_set_res (req, ret, cflags); +io_req_set_res (req, ret,IORING_CQE_F_MORE );return IOU_OK ; }
@@ -1096,17 +1092,11 @@ void io_sendrecv_fail(struct io_kiocb *rvoid io_send_zc_fail (struct io_kiocb *req) { struct io_sr_msg *sr = io_kiocb_to_cmd(req, struct io_sr_msg); -int res = req->cqe.res; -if (req->flags &REQ_F_PARTIAL_IO ) { -if (req->flags &REQ_F_NEED_CLEANUP ) { -io_notif_flush (sr->notif); - sr->notif =NULL ; - req->flags &= ~REQ_F_NEED_CLEANUP ; - } - res = sr->done_io; - } -io_req_set_res (req, res, req->cqe.flags); +if (req->flags &REQ_F_PARTIAL_IO ) + req->cqe.res = sr->done_io; +if (req->flags &REQ_F_NEED_CLEANUP ) + req->cqe.flags |=IORING_CQE_F_MORE ; }int io_accept_prep (struct io_kiocb *req,const struct io_uring_sqe *sqe)
Greg Kroah-Hartman
maintainerPATCH 847/862 io_uring/net: fix notif cqe reordering
In reply to Greg Kroah-HartmanFrom: Pavel Begunkov <[email protected]>
[ upstream commit 108893ddcc4d3aa0a4a02aeb02d478e997001227 ]
send zc is not restricted to !IO_URING_F_UNLOCKED anymore and so we can't use task-tw ordering trick to order notification cqes with requests completions. In this case leave it alone and let io_send_zc_cleanup() flush it.
--- io_uring/net.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
io_uring/net.c +8 -2
@@ -1073,8 +1073,14 @@ int io_send_zc(struct io_kiocb *req, unselse if (zc->done_io) ret = zc->done_io; -io_notif_flush (zc->notif); - req->flags &= ~REQ_F_NEED_CLEANUP ; +/* +* If we're in io-wq we can't rely on tw ordering guarantees, defer +* flushing notif to io_send_zc_cleanup() +*/ +if (!(issue_flags &IO_URING_F_UNLOCKED )) { +io_notif_flush (zc->notif); + req->flags &= ~REQ_F_NEED_CLEANUP ; + }io_req_set_res (req, ret,IORING_CQE_F_MORE );return IOU_OK ; }
Greg Kroah-Hartman
maintainerPATCH 848/862 mm: hugetlb: fix UAF in hugetlb_handle_userfault
In reply to Greg Kroah-HartmanFrom: Liu Shixin <[email protected]>
commit 958f32ce832ba781ac20e11bb2d12a9352ea28fc upstream.
The vma_lock and hugetlb_fault_mutex are dropped before handling userfault and reacquire them again after handle_userfault(), but reacquire the vma_lock could lead to UAF[1,2] due to the following race,
hugetlb_fault
hugetlb_no_page
/*unlock vma_lock */
hugetlb_handle_userfault
handle_userfault
/* unlock mm->mmap_lock*/
vm_mmap_pgoff
do_mmap
mmap_region
munmap_vma_range
/* clean old vma */
/* lock vma_lock again <--- UAF */
/* unlock vma_lock */Since the vma_lock will unlock immediately after hugetlb_handle_userfault(), let's drop the unneeded lock and unlock in hugetlb_handle_userfault() to fix the issue.
[1] https://lore.kernel.org/linux-mm/[email protected]/
[2] https://lore.kernel.org/linux-mm/[email protected]/
--- mm/hugetlb.c | 37 +++++++++++++++++-------------------- 1 file changed, 17 insertions(+), 20 deletions(-)
mm/hugetlb.c +17 -20
@@ -5482,7 +5482,6 @@ static inline vm_fault_t hugetlb_handle_ unsigned long addr, unsigned long reason) { -vm_fault_t ret;u32 hash;struct vm_fault vmf = { .vma = vma,
@@ -5500,18 +5499,14 @@ static inline vm_fault_t hugetlb_handle_ };/* -* hugetlb_fault_mutex and i_mmap_rwsem must be -* dropped before handling userfault. Reacquire -* after handling fault to make calling code simpler. +* vma_lock and hugetlb_fault_mutex must be dropped before handling +* userfault. Also mmap_lock will be dropped during handling +* userfault, any vma operation should be careful from here. */ hash =hugetlb_fault_mutex_hash (mapping, idx);mutex_unlock (&hugetlb_fault_mutex_table[hash]);i_mmap_unlock_read (mapping); - ret =handle_userfault (&vmf, reason); -i_mmap_lock_read (mapping); -mutex_lock (&hugetlb_fault_mutex_table[hash]); - -return ret; +return handle_userfault (&vmf, reason); } static vm_fault_t hugetlb_no_page(struct mm_struct *mm,
@@ -5529,6 +5524,7 @@ static vm_fault_t hugetlb_no_page(structspinlock_t *ptl;unsigned long haddr = address &huge_page_mask (h);bool new_page, new_pagecache_page = false; +u32 hash =hugetlb_fault_mutex_hash (mapping, idx);/* * Currently, we are forced to kill the process in the event the
@@ -5539,7 +5535,7 @@ static vm_fault_t hugetlb_no_page(structif (is_vma_resv_set (vma,HPAGE_RESV_UNMAPPED )) {pr_warn_ratelimited ("PID %d killed due to inadequate hugepage pool\n" , current->pid); -return ret; + goto out; }/*
@@ -5556,12 +5552,10 @@ retry: page =find_lock_page (mapping, idx);if (!page) {/* Check for page in userfault range */ -if (userfaultfd_missing (vma)) { - ret =hugetlb_handle_userfault (vma, mapping, idx, +if (userfaultfd_missing (vma)) +return hugetlb_handle_userfault (vma, mapping, idx, flags, haddr, address,VM_UFFD_MISSING ); - goto out; - } page =alloc_huge_page (vma, haddr,0 );if (IS_ERR (page)) {
@@ -5621,10 +5615,9 @@ retry:if (userfaultfd_minor (vma)) {unlock_page (page);put_page (page); - ret =hugetlb_handle_userfault (vma, mapping, idx, +return hugetlb_handle_userfault (vma, mapping, idx, flags, haddr, address,VM_UFFD_MINOR ); - goto out; } }
@@ -5682,6 +5675,8 @@ retry:unlock_page (page); out: +mutex_unlock (&hugetlb_fault_mutex_table[hash]); +i_mmap_unlock_read (mapping);return ret; backout:
@@ -5780,11 +5775,13 @@ vm_fault_t hugetlb_fault(struct mm_struc entry =huge_ptep_get (ptep);/* PTE markers should be handled the same way as none pte */ -if (huge_pte_none_mostly (entry)) { - ret =hugetlb_no_page (mm, vma, mapping, idx, address, ptep, +if (huge_pte_none_mostly (entry)) +/* +* hugetlb_no_page will drop vma lock and hugetlb fault +* mutex internally, which make us return immediately. +*/ +return hugetlb_no_page (mm, vma, mapping, idx, address, ptep, entry, flags); - goto out_mutex; - } ret =0 ;
Greg Kroah-Hartman
maintainerPATCH 849/862 net: ieee802154: return -EINVAL for unknown addr type
In reply to Greg Kroah-HartmanFrom: Alexander Aring <[email protected]>
commit 30393181fdbc1608cc683b4ee99dcce05ffcc8c7 upstream.
This patch adds handling to return -EINVAL for an unknown addr type. The current behaviour is to return 0 as successful but the size of an unknown addr type is not defined and should return an error like -EINVAL.
--- include/net/ieee802154_netdev.h | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-)
include/net/ieee802154_netdev.h +9 -3
@@ -185,21 +185,27 @@ static inline int ieee802154_sockaddr_check_size(struct sockaddr_ieee802154 *daddr, int len) {struct ieee802154_addr_sa *sa; +int ret =0 ; sa = &daddr->addr;if (len <IEEE802154_MIN_NAMELEN )return -EINVAL ;switch (sa->addr_type) { +case IEEE802154_ADDR_NONE : +break ;case IEEE802154_ADDR_SHORT :if (len <IEEE802154_NAMELEN_SHORT ) -return -EINVAL ; + ret = -EINVAL ;break ;case IEEE802154_ADDR_LONG :if (len <IEEE802154_NAMELEN_LONG ) -return -EINVAL ; + ret = -EINVAL ; +break ; +default : + ret = -EINVAL ;break ; } -return 0 ; +return ret; } static inline void ieee802154_addr_from_sa(struct ieee802154_addr *a,
Greg Kroah-Hartman
maintainerPATCH 850/862 ALSA: usb-audio: Fix last interface check for registration
In reply to Greg Kroah-HartmanFrom: Takashi Iwai <[email protected]>
commit 39efc9c8a973ddff5918191525d1679d0fb368ea upstream.
The recent fix in commit 6392dcd1d0c7 ("ALSA: usb-audio: Register card at the last interface") tried to delay the card registration until the last found interface is probed. It assumed that the probe callback gets called for those later interfaces, but it's not always true; as the driver loops over the descriptor and probes the matching ones, it's not separately called via multiple probe calls. This results in the missing card registration, i.e. no sound device.
For addressing this problem, replace the check whether the last interface is processed with usb_interface_claimed() instead of the comparison with the probe interface number.
--- sound/usb/card.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
sound/usb/card.c +1 -1
@@ -884,7 +884,7 @@ static int usb_audio_probe(struct usb_in* one given via option */ if (check_delayed_register_option (chip) == ifnum || - chip->last_iface == ifnum) { +usb_interface_claimed (usb_ifnum_to_if (dev, chip->last_iface))) { err =snd_card_register (chip->card);if (err <0 ) goto __error;
Greg Kroah-Hartman
maintainerPATCH 851/862 blk-wbt: fix that rwb->wc is always set to 1 in wbt_init()
In reply to Greg Kroah-HartmanFrom: Yu Kuai <[email protected]>
commit 285febabac4a16655372d23ff43e89ff6f216691 upstream.
commit 8c5035dfbb94 ("blk-wbt: call rq_qos_add() after wb_normal is initialized") moves wbt_set_write_cache() before rq_qos_add(), which is wrong because wbt_rq_qos() is still NULL.
Fix the problem by removing wbt_set_write_cache() and setting 'rwb->wc' directly. Noted that this patch also remove the redundant setting of 'rab->wc'.
--- block/blk-wbt.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
block/blk-wbt.c +1 -2
@@ -841,12 +841,11 @@ int wbt_init(struct request_queue *q) rwb->last_comp = rwb->last_issue = jiffies; rwb->win_nsec =RWB_WINDOW_NSEC ; rwb->enable_state =WBT_STATE_ON_DEFAULT ; - rwb->wc =1 ; + rwb->wc =test_bit (QUEUE_FLAG_WC , &q->queue_flags); rwb->rq_depth.default_depth =RWB_DEF_DEPTH ; rwb->min_lat_nsec =wbt_default_latency_nsec (q);wbt_queue_depth_changed (&rwb->rqos); -wbt_set_write_cache (q,test_bit (QUEUE_FLAG_WC , &q->queue_flags));/* * Assign rwb and add the stats callback.
Greg Kroah-Hartman
maintainerPATCH 852/862 net: ethernet: ti: davinci_mdio: fix build for mdio bitbang uses
In reply to Greg Kroah-HartmanFrom: Randy Dunlap <[email protected]>
commit 35bbe652c421037822aba29423f5f1f7d0d69f3f upstream.
davinci_mdio.c uses mdio bitbang APIs, so it should select MDIO_BITBANG to prevent build errors.
arm-linux-gnueabi-ld: drivers/net/ethernet/ti/davinci_mdio.o: in function `davinci_mdio_remove':drivers/net/ethernet/ti/davinci_mdio.c:649: undefined reference to `free_mdio_bitbang'
arm-linux-gnueabi-ld: drivers/net/ethernet/ti/davinci_mdio.o: in function `davinci_mdio_probe':drivers/net/ethernet/ti/davinci_mdio.c:545: undefined reference to `alloc_mdio_bitbang'
arm-linux-gnueabi-ld: drivers/net/ethernet/ti/davinci_mdio.o: in function `davinci_mdiobb_read':drivers/net/ethernet/ti/davinci_mdio.c:236: undefined reference to `mdiobb_read'
arm-linux-gnueabi-ld: drivers/net/ethernet/ti/davinci_mdio.o: in function `davinci_mdiobb_write':drivers/net/ethernet/ti/davinci_mdio.c:253: undefined reference to `mdiobb_write'
--- drivers/net/ethernet/ti/Kconfig | 1 + 1 file changed, 1 insertion(+)
drivers/net/ethernet/ti/Kconfig +1 -0
@@ -33,6 +33,7 @@ config TI_DAVINCI_MDIO tristate "TI DaVinci MDIO Support" depends on ARCH_DAVINCI || ARCH_OMAP2PLUS || ARCH_KEYSTONE || ARCH_K3 || COMPILE_TEST select PHYLIB + select MDIO_BITBANG help This driver supports TI's DaVinci MDIO module.
Greg Kroah-Hartman
maintainerPATCH 853/862 Revert "drm/amd/display: correct hostvm flag"
In reply to Greg Kroah-HartmanFrom: Aric Cyr <[email protected]>
commit 96ab3cb3b0f862308a03046d01d66c7b4154846b upstream.
This reverts commit 796d6a37ff5ffaf9f2dc0f3f4bf9f4a1034c00de.
4K144 resolution isn't available on DCN31.
--- drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/amd/display/dc/dcn31/dcn31_resource.c +1 -1
@@ -891,7 +891,7 @@ static const struct dc_debug_options deb .optimize_edp_link_rate = true, .enable_sw_cntl_psr = true, .enable_z9_disable_interface = true, /* Allow support for the PMFW interface for disable Z9*/ - .dml_hostvm_override = DML_HOSTVM_NO_OVERRIDE, + .dml_hostvm_override = DML_HOSTVM_OVERRIDE_FALSE, };static const struct dc_debug_options debug_defaults_diags = {
Greg Kroah-Hartman
maintainerPATCH 854/862 Revert "net/ieee802154: reject zero-sized raw_sendmsg()"
In reply to Greg Kroah-HartmanFrom: Alexander Aring <[email protected]>
[ Upstream commit 2eb2756f6c9e9621e022d78321ce40a62c4520b5 ]
This reverts commit 3a4d061c699bd3eedc80dc97a4b2a2e1af83c6f5.
There is a v2 which does return zero if zero length is given.
--- net/ieee802154/socket.c | 3 --- 1 file changed, 3 deletions(-)
net/ieee802154/socket.c +0 -3
@@ -251,9 +251,6 @@ static int raw_sendmsg(struct sock *sk, struct msghdr *msg, size_t size)return -EOPNOTSUPP ; } -if (!size) -return -EINVAL ; -lock_sock (sk);if (!sk->sk_bound_dev_if) dev =dev_getfirstbyhwtype (sock_net (sk),ARPHRD_IEEE802154 );
Signature · 1 line
2.35.1
Greg Kroah-Hartman
maintainerPATCH 855/862 net/ieee802154: dont warn zero-sized raw_sendmsg()
In reply to Greg Kroah-HartmanFrom: Tetsuo Handa <[email protected]>
[ Upstream commit b12e924a2f5b960373459c8f8a514f887adf5cac ]
syzbot is hitting skb_assert_len() warning at __dev_queue_xmit() [1], for PF_IEEE802154 socket's zero-sized raw_sendmsg() request is hitting __dev_queue_xmit() with skb->len == 0.
Since PF_IEEE802154 socket's zero-sized raw_sendmsg() request was able to return 0, don't call __dev_queue_xmit() if packet length is 0.
----------
#include <sys/socket.h>
#include <netinet/in.h>
int main(int argc, char *argv[])
{
struct sockaddr_in addr = { .sin_family = AF_INET, .sin_addr.s_addr = htonl(INADDR_LOOPBACK) };
struct iovec iov = { };
struct msghdr hdr = { .msg_name = &addr, .msg_namelen = sizeof(addr), .msg_iov = &iov, .msg_iovlen = 1 };
sendmsg(socket(PF_IEEE802154, SOCK_RAW, 0), &hdr, 0);
return 0;
}
----------Note that this might be a sign that commit fd1894224407c484 ("bpf: Don't redirect packets with invalid pkt_len") should be reverted, for skb->len == 0 was acceptable for at least PF_IEEE802154 socket.
--- net/ieee802154/socket.c | 4 ++++ 1 file changed, 4 insertions(+)
net/ieee802154/socket.c +4 -0
@@ -272,6 +272,10 @@ static int raw_sendmsg(struct sock *sk, err = -EMSGSIZE ; goto out_dev; } +if (!size) { + err =0 ; + goto out_dev; + } hlen =LL_RESERVED_SPACE (dev); tlen = dev->needed_tailroom;
Greg Kroah-Hartman
maintainerPATCH 856/862 powerpc/64s/interrupt: Fix lost interrupts when returning to soft-masked context
In reply to Greg Kroah-HartmanFrom: Nicholas Piggin <[email protected]>
commit a4cb3651a174366cc85a677da9e3681fbe97fdae upstream.
It's possible for an interrupt returning to an irqs-disabled context to lose a pending soft-masked irq because it branches to part of the exit code for irqs-enabled contexts, which is meant to clear only the PACA_IRQS_HARD_DIS flag from PACAIRQHAPPENED by zeroing the byte. This just looks like a simple thinko from a recent commit (if there was no hard mask pending, there would be no reason to clear it anyway).
This also adds comment to the code that actually does need to clear the flag.
--- arch/powerpc/kernel/interrupt_64.S | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)
arch/powerpc/kernel/interrupt_64.S +13 -2
@@ -571,7 +571,7 @@ _ASM_NOKPROBE_SYMBOL(interrupt_return_\s beq .Lfast_kernel_interrupt_return_\srr\() // EE already disabled lbz r11,PACAIRQHAPPENED(r13) andi. r10,r11,PACA_IRQ_MUST_HARD_MASK - beq 1f // No HARD_MASK pending + beq .Lfast_kernel_interrupt_return_\srr\() // No HARD_MASK pending /* Must clear MSR_EE from _MSR */ #ifdef CONFIG_PPC_BOOK3S
@@ -588,12 +588,23 @@ _ASM_NOKPROBE_SYMBOL(interrupt_return_\s b .Lfast_kernel_interrupt_return_\srr\() .Linterrupt_return_\srr\()_soft_enabled: + /* + * In the soft-enabled case, need to double-check that we have no + * pending interrupts that might have come in before we reached the + * restart section of code, and restart the exit so those can be + * handled. + * + * If there are none, it is be possible that the interrupt still + * has PACA_IRQ_HARD_DIS set, which needs to be cleared for the + * interrupted context. This clear will not clobber a new pending + * interrupt coming in, because we're in the restart section, so + * such would return to the restart location. + */ #ifdef CONFIG_PPC_BOOK3S lbz r11,PACAIRQHAPPENED(r13) andi. r11,r11,(~PACA_IRQ_HARD_DIS)@l bne- interrupt_return_\srr\()_kernel_restart #endif -1: li r11,0 stb r11,PACAIRQHAPPENED(r13) // clear the possible HARD_DIS
Greg Kroah-Hartman
maintainerPATCH 857/862 drm/amd/display: Fix build breakage with CONFIG_DEBUG_FS=n
In reply to Greg Kroah-HartmanFrom: Nathan Chancellor <[email protected]>
commit 2130b87b2273389cafe6765bf09ef564cda01407 upstream.
After commit 8799c0be89eb ("drm/amd/display: Fix vblank refcount in vrr transition"), a build with CONFIG_DEBUG_FS=n is broken due to a misplaced brace, along the lines of:
In file included from drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_trace.h:39,
from drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:41:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c: At top level:
./include/drm/drm_atomic.h:864:9: error: expected identifier or ‘(’ before ‘for’
864 | for ((__i) = 0; \
| ^~~
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8317:9: note: in expansion of macro ‘for_each_new_crtc_in_state’
8317 | for_each_new_crtc_in_state(state, crtc, new_crtc_state, j)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~Move the brace within the #ifdef so that the file can be built with or without CONFIG_DEBUG_FS.
--- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +1 -1
@@ -8329,8 +8329,8 @@ static void amdgpu_dm_atomic_commit_tail crtc, dm_new_crtc_state, cur_crc_src)) DRM_DEBUG_DRIVER("Failed to configure crc source"); } -#endif } +#endif }for_each_new_crtc_in_state (state, crtc, new_crtc_state, j)
Greg Kroah-Hartman
maintainerPATCH 858/862 io_uring: fix fdinfo sqe offsets calculation
In reply to Greg Kroah-HartmanFrom: Pavel Begunkov <[email protected]>
commit 00927931cb630bbf8edb6d7f4dadb25139fc5e16 upstream.
Only with the big sqe feature they take 128 bytes per entry, but we unconditionally advance by 128B. Fix it by using sq_shift.
--- io_uring/fdinfo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
io_uring/fdinfo.c +1 -1
@@ -95,7 +95,7 @@ static __cold void __io_uring_show_fdinf sq_idx =READ_ONCE (ctx->sq_array[entry & sq_mask]);if (sq_idx > sq_mask)continue ; - sqe = &ctx->sq_sqes[sq_idx <<1 ]; + sqe = &ctx->sq_sqes[sq_idx << sq_shift]; seq_printf(m, "%5u: opcode:%s, fd:%d, flags:%x, off:%llu, " "addr:0x%llx, rw_flags:0x%x, buf_index:%d " "user_data:%llu",
Greg Kroah-Hartman
maintainerPATCH 859/862 io_uring/rw: ensure kiocb_end_write() is always called
In reply to Greg Kroah-HartmanFrom: Jens Axboe <[email protected]>
commit 2ec33a6c3cca9fe2465e82050c81f5ffdc508b36 upstream.
A previous commit moved the notifications and end-write handling, but it is now missing a few spots where we also want to call both of those. Without that, we can potentially be missing file notifications, and more importantly, have an imbalance in the super_block writers sem accounting.
--- io_uring/rw.c | 38 +++++++++++++++++++++++++++++--------- 1 file changed, 29 insertions(+), 9 deletions(-)
io_uring/rw.c +29 -9
@@ -184,11 +184,34 @@ static void kiocb_end_write(struct io_ki } } +/* +* Trigger the notifications after having done some IO, and finish the write +* accounting, if any. +*/ +static void io_req_io_end (struct io_kiocb *req) +{ + struct io_rw *rw = io_kiocb_to_cmd(req, struct io_rw); + +WARN_ON (!in_task ()); + +if (rw->kiocb.ki_flags &IOCB_WRITE ) { +kiocb_end_write (req); +fsnotify_modify (req->file); + }else { +fsnotify_access (req->file); + } +} +static bool __io_complete_rw_common (struct io_kiocb *req,long res) {if (unlikely (res != req->cqe.res)) {if ((res == -EAGAIN || res == -EOPNOTSUPP ) &&io_rw_should_reissue (req)) { +/* +* Reissue will start accounting again, finish the +* current cycle. +*/ +io_req_io_end (req); req->flags |=REQ_F_REISSUE |REQ_F_PARTIAL_IO ;return true; }
@@ -214,15 +237,7 @@ static inline int io_fixup_rw_res(structstatic void io_req_rw_complete (struct io_kiocb *req,bool *locked) { - struct io_rw *rw = io_kiocb_to_cmd(req, struct io_rw); - -if (rw->kiocb.ki_flags &IOCB_WRITE ) { -kiocb_end_write (req); -fsnotify_modify (req->file); - }else { -fsnotify_access (req->file); - } - +io_req_io_end (req);io_req_task_complete (req, locked); }
@@ -267,6 +282,11 @@ static int kiocb_done(struct io_kiocb *r req->file->f_pos = rw->kiocb.ki_pos;if (ret >=0 && (rw->kiocb.ki_complete == io_complete_rw)) {if (!__io_complete_rw_common (req, ret)) { +/* +* Safe to call io_end from here as we're inline +* from the submission path. +*/ +io_req_io_end (req);io_req_set_res (req, final_ret,io_put_kbuf (req, issue_flags));return IOU_OK ;
Greg Kroah-Hartman
maintainerPATCH 860/862 Kconfig.debug: simplify the dependency of DEBUG_INFO_DWARF4/5
In reply to Greg Kroah-HartmanFrom: Masahiro Yamada <[email protected]>
commit 4f001a21080ff2e2f0e1c3692f5e119aedbb3bc1 upstream.
Commit c0a5c81ca9be ("Kconfig.debug: drop GCC 5+ version check for DWARF5") could have cleaned up the code a bit more.
"CC_IS_CLANG &&" is unneeded. No functional change is intended.
--- lib/Kconfig.debug | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
lib/Kconfig.debug +2 -2
@@ -264,7 +264,7 @@ config DEBUG_INFO_DWARF_TOOLCHAIN_DEFAUL config DEBUG_INFO_DWARF4 bool "Generate DWARF Version 4 debuginfo" select DEBUG_INFO - depends on !CC_IS_CLANG || (CC_IS_CLANG && (AS_IS_LLVM || (AS_IS_GNU && AS_VERSION >= 23502))) + depends on !CC_IS_CLANG || AS_IS_LLVM || (AS_IS_GNU && AS_VERSION >= 23502) help Generate DWARF v4 debug info. This requires gcc 4.5+, binutils 2.35.2 if using clang without clang's integrated assembler, and gdb 7.0+.
@@ -276,7 +276,7 @@ config DEBUG_INFO_DWARF4 config DEBUG_INFO_DWARF5 bool "Generate DWARF Version 5 debuginfo" select DEBUG_INFO - depends on !CC_IS_CLANG || (CC_IS_CLANG && (AS_IS_LLVM || (AS_IS_GNU && AS_VERSION >= 23502))) + depends on !CC_IS_CLANG || AS_IS_LLVM || (AS_IS_GNU && AS_VERSION >= 23502) help Generate DWARF v5 debug info. Requires binutils 2.35.2, gcc 5.0+ (gcc 5.0+ accepts the -gdwarf-5 flag but only had partial support for some
Greg Kroah-Hartman
maintainerPATCH 861/862 Kconfig.debug: add toolchain checks for DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT
In reply to Greg Kroah-HartmanFrom: Masahiro Yamada <[email protected]>
commit bb1435f3f575b5213eaf27434efa3971f51c01de upstream.
CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT does not give explicit -gdwarf-* flag. The actual DWARF version is up to the toolchain.
The combination of GCC and GAS works fine, and Clang with the integrated assembler is good too.
The combination of Clang and GAS is tricky, but at least, the -g flag works for Clang <=13, which defaults to DWARF v4.
Clang 14 switched its default to DWARF v5.
Now, CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT has the same issue as addressed by commit 98cd6f521f10 ("Kconfig: allow explicit opt in to DWARF v5").
CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y for Clang >= 14 and GAS < 2.35 produces a ton of errors like follows:
/tmp/main-c2741c.s: Assembler messages:
/tmp/main-c2741c.s:109: Error: junk at end of line, first unrecognized character is `"' /tmp/main-c2741c.s:109: Error: file number less than one
Add 'depends on' to check toolchains.
--- lib/Kconfig.debug | 1 + 1 file changed, 1 insertion(+)
lib/Kconfig.debug +1 -0
@@ -253,6 +253,7 @@ config DEBUG_INFO_NONE config DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT bool "Rely on the toolchain's implicit default DWARF version" select DEBUG_INFO + depends on !CC_IS_CLANG || AS_IS_LLVM || CLANG_VERSION < 140000 || (AS_IS_GNU && AS_VERSION >= 23502) help The implicit default version of DWARF debug info produced by a toolchain changes over time.
Greg Kroah-Hartman
maintainerPATCH 862/862 lib/Kconfig.debug: Add check for non-constant .{s,u}leb128 support to DWARF5
In reply to Greg Kroah-HartmanFrom: Nathan Chancellor <[email protected]>
commit 0a6de78cff600cb991f2a1b7ed376935871796a0 upstream.
When building with a RISC-V kernel with DWARF5 debug info using clang and the GNU assembler, several instances of the following error appear:
/tmp/vgettimeofday-48aa35.s:2963: Error: non-constant .uleb128 is not supported
Dumping the .s file reveals these .uleb128 directives come from .debug_loc and .debug_ranges:
.Ldebug_loc0:
.byte 4 # DW_LLE_offset_pair
.uleb128 .Lfunc_begin0-.Lfunc_begin0 # starting offset
.uleb128 .Ltmp1-.Lfunc_begin0 # ending offset
.byte 1 # Loc expr size
.byte 90 # DW_OP_reg10
.byte 0 # DW_LLE_end_of_list.Ldebug_ranges0:
.byte 4 # DW_RLE_offset_pair
.uleb128 .Ltmp6-.Lfunc_begin0 # starting offset
.uleb128 .Ltmp27-.Lfunc_begin0 # ending offset
.byte 4 # DW_RLE_offset_pair
.uleb128 .Ltmp28-.Lfunc_begin0 # starting offset
.uleb128 .Ltmp30-.Lfunc_begin0 # ending offset
.byte 0 # DW_RLE_end_of_listThere is an outstanding binutils issue to support a non-constant operand to .sleb128 and .uleb128 in GAS for RISC-V but there does not appear to be any movement on it, due to concerns over how it would work with linker relaxation.
To avoid these build errors, prevent DWARF5 from being selected when using clang and an assembler that does not have support for these symbol deltas, which can be easily checked in Kconfig with as-instr plus the small test program from the dwz test suite from the binutils issue.
--- lib/Kconfig.debug | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
lib/Kconfig.debug +7 -2
@@ -231,6 +231,11 @@ config DEBUG_INFO in the "Debug information" choice below, indicating that debug information will be generated for build targets. +# Clang is known to generate .{s,u}leb128 with symbol deltas with DWARF5, which +# some targets may not support: https://sourceware.org/bugzilla/show_bug.cgi?id=27215 +config AS_HAS_NON_CONST_LEB128 + def_bool $(as-instr,.uleb128 .Lexpr_end4 - .Lexpr_start3\n.Lexpr_start3:\n.Lexpr_end4:) + choice prompt "Debug information" depends on DEBUG_KERNEL
@@ -253,7 +258,7 @@ config DEBUG_INFO_NONE config DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT bool "Rely on the toolchain's implicit default DWARF version" select DEBUG_INFO - depends on !CC_IS_CLANG || AS_IS_LLVM || CLANG_VERSION < 140000 || (AS_IS_GNU && AS_VERSION >= 23502) + depends on !CC_IS_CLANG || AS_IS_LLVM || CLANG_VERSION < 140000 || (AS_IS_GNU && AS_VERSION >= 23502 && AS_HAS_NON_CONST_LEB128) help The implicit default version of DWARF debug info produced by a toolchain changes over time.
@@ -277,7 +282,7 @@ config DEBUG_INFO_DWARF4 config DEBUG_INFO_DWARF5 bool "Generate DWARF Version 5 debuginfo" select DEBUG_INFO - depends on !CC_IS_CLANG || AS_IS_LLVM || (AS_IS_GNU && AS_VERSION >= 23502) + depends on !CC_IS_CLANG || AS_IS_LLVM || (AS_IS_GNU && AS_VERSION >= 23502 && AS_HAS_NON_CONST_LEB128) help Generate DWARF v5 debug info. Requires binutils 2.35.2, gcc 5.0+ (gcc 5.0+ accepts the -gdwarf-5 flag but only had partial support for some
Hey Greg,
Ran tests and boot tested on my system, no regressions found
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.0.3 release. There are 862 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, 21 Oct 2022 08:30:19 +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/v6.x/stable-review/patch-6.0.3-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.0.y
and the diffstat can be found below.thanks,
greg k-h
No new regressions for Tegra ...
Test results for stable-v6.0:
11 builds: 11 pass, 0 fail
28 boots: 28 pass, 0 fail
130 tests: 128 pass, 2 failLinux version: 6.0.3-rc1-g844297340351
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-a04Test failures: tegra194-p2972-0000: boot.py
tegra210-p3450-0000: devices
Jon
Signature · 1 line
nvpublic
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.0.3 release. There are 862 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, 21 Oct 2022 08:30:19 +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/v6.x/stable-review/patch-6.0.3-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.0.y
and the diffstat can be found below.thanks,
greg k-h
Built and booted successfully on RISC-V RV64 (HiFive Unmatched).
Quoted 9 lines
This is the start of the stable review cycle for the 6.0.3 release. There are 862 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, 21 Oct 2022 08:30:19 +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/v6.x/stable-review/patch-6.0.3-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.0.y
and the diffstat can be found below.thanks,
greg k-h
Hi Greg,
Boot tested on both x86 and ARM64 test systems, no regressions found
Thanks.
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.0.3 release. There are 862 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, 21 Oct 2022 08:30:19 +0000. Anything received after that time might be too late.
6.0.3-rc1 compiled and booted on my x86_64 test system. No errors or regressions.
Thanks,
-srw
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.0.3 release. There are 862 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, 21 Oct 2022 08:30:19 +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/v6.x/stable-review/patch-6.0.3-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.0.y
and the diffstat can be found below.thanks,
greg k-h
On ARCH_BRCMSTB using 32-bit and 64-bit ARM kernels, build tested on BMIPS_GENERIC:
Signature · 1 line
Florian
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.0.3 release. There are 862 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, 21 Oct 2022 08:30:19 +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/v6.x/stable-review/patch-6.0.3-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.0.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.0.3 release. There are 862 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, 21 Oct 2022 08:30:19 +0000. Anything received after that time might be too late.
Build results:
total: 152 pass: 152 fail: 0 Qemu test results: total: 490 pass: 490 fail: 0
Guenter
Quoted 5 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.0.3 release. There are 862 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 6.0.3 release. There are 862 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, 21 Oct 2022 08:30:19 +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/v6.x/stable-review/patch-6.0.3-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.0.y
and the diffstat can be found below.
openSUSE configs¹⁾ all green. x86_64 runs fine in qemu.
¹⁾ armv6hl armv7hl arm64 i386 ppc64 ppc64le riscv64 s390x x86_64
Signature · 2 lines
js suse labs
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.0.3 release. There are 862 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, 21 Oct 2022 08:30:19 +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/v6.x/stable-review/patch-6.0.3-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.0.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.
A list of kernel warning / BUGs/ oops / invalid opcode are coming from mainline kernel.
NOTE:
Following kernel warning noticed on arm64 Qcom db410c device while booting with kselftest merge configs. This is reported on mainline [1] & [2].
[ 29.638854] qcom-camss: probe of 1b0ac00.camss failed with error -17 [ 29.772896] ------------[ cut here ]------------ [ 29.773376] list_add corruption. prev->next should be next (ffff000004771300), but was 0000000000000000. (prev=ffff000010c13e00). [ 29.777423] WARNING: CPU: 1 PID: 283 at lib/list_debug.c:30 __list_add_valid+0xdc/0x110 [ 29.784013] NET: Registered PF_QIPCRTR protocol family [ 29.788398] Modules linked in: qrtr(+) rtc_pm8xxx(+) qcom_pon(+)
qcom_spmi_vadc(+) qcom_vadc_common qcom_q6v5_mss(+) qcom_pil_info qcom_q6v5 qcom_sysmon qcom_camss qcom_common videobuf2_dma_sg qcom_glink_smem qmi_helpers venus_core(+) v4l2_fwnode qcom_stats gpu_sched v4l2_async v4l2_mem2mem drm_dp_aux_bus qnoc_msm8916 qcom_rng mdt_loader videobuf2_memops videobuf2_v4l2 drm_display_helper i2c_qcom_cci videobuf2_common icc_smd_rpm display_connector drm_kms_helper rmtfs_mem socinfo fuse drm
[ 29.823494] CPU: 1 PID: 283 Comm: systemd-udevd Not tainted 6.0.2 #1 [ 29.844890] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT) [ 29.851234] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 29.857919] pc : __list_add_valid+0xdc/0x110 [ 29.864544] lr : __list_add_valid+0xdc/0x110
ref:
[1 ] https://lore.kernel.org/all/CA+G9fYuB1-qmObe3L0A0oUDXXaWa=-UxOEGtEWWJ-=_wc791Uw@mail.gmail.com/
[2] https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.0.y/build/v6.0.2/testrun/12505842/suite/log-parser-test/test/check-kernel-exception/log
Following warning noticed on arm64 Qcom db845c device while booting with the Kselftest merge configs enabled.
[ 20.438279] ============================================
[ 20.443648] WARNING: possible recursive locking detected
[ 20.449018] 6.0.2 #1 Not tainted
[ 20.452283] --------------------------------------------
[ 20.457649] kworker/u16:1/11 is trying to acquire lock:
[ 20.462927] cfg80211: Loading compiled-in X.509 certificates for
regulatory database
[ 20.470748] ffff6ca7c8e428f8 (&irq_desc_lock_class){-.-.}-{2:2},
at: __irq_get_desc_lock+0x64/0xac
[ 20.479825]
[ 20.479825] but task is already holding lock:
[ 20.485717] ffff6ca7cb75c0f8 (&irq_desc_lock_class){-.-.}-{2:2},
at: __irq_get_desc_lock+0x64/0xac
[ 20.494777]
[ 20.494777] other info that might help us debug this:
[ 20.501372] Possible unsafe locking scenario:
[ 20.501372]
[ 20.507351] CPU0
[ 20.509834] ----
[ 20.512314] lock(&irq_desc_lock_class);
[ 20.516374] lock(&irq_desc_lock_class);
[ 20.520448]
[ 20.520448] *** DEADLOCK ***[3] https://lore.kernel.org/all/CA+G9fYui6--jhN1CFH6fXNK81sHNYgosTs2hyybFqPxFRvndpg@mail.gmail.com/
The following invalid opcode found while running selftests: memfd:run_hugetlbfs_test.sh on i386 with kselftest configs enabled [4] & [5].
# selftests: memfd: run_hugetlbfs_test.sh
[ 75.841946] run_hugetlbfs_t (1296): drop_caches: 3
[ 75.890473] invalid opcode: 0000 [#1] PREEMPT SMP
[ 75.895185] CPU: 1 PID: 1300 Comm: memfd_test Tainted: G
N 6.0.3-rc1 #1
[ 75.903185] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.5 11/26/2020
[ 75.910576] EIP: hugetlb_file_setup.cold+0x0/0x33
[ 75.915312] Code: b8 ea ff ff ff e9 52 8e 26 ff 0f 0b c7 04 24 70
75 63 d6 e8 a7 4a ff ff b8 ea ff ff ff e9 57 97 26 ff 0f 0b 0f 0b 0f
0b 0f 0b <0f> 0b 64 a1 58 b8 bd d6 c6 05 bd c0 a6 d6 01 8b 90 ec 03 00
00 05
[ 75.934053] EAX: c5360dd0 EBX: 00000000 ECX: 00000020 EDX: 00000000
[ 75.940311] ESI: 80000004 EDI: 00000005 EBP: c5405ea0 ESP: c5405e80
[ 75.946620] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS: 00010212
[ 75.953399] CR0: 80050033 CR2: 00000000 CR3: 06405000 CR4: 003506d0
[ 75.959665] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[ 75.965920] DR6: fffe0ff0 DR7: 00000400
[ 75.969753] Call Trace:
[ 75.972199] __ia32_sys_memfd_create+0x196/0x220
[ 75.976816] __do_fast_syscall_32+0x77/0xd0
[ 75.981008] do_fast_syscall_32+0x32/0x70
[ 75.985023] do_SYSENTER_32+0x15/0x20
[ 75.988680] entry_SYSENTER_32+0x98/0xf6
[ 75.992605] EIP: 0xb7f31549
[ 75.995399] Code: 03 74 c0 01 10 05 03 74 b8 01 10 06 03 74 b4 01
10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 51 52 55 89 e5 0f
34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d 76 00 58 b8 77 00 00 00 cd 80 90
8d 76
[ 76.014144] EAX: ffffffda EBX: 0804b486 ECX: 80000004 EDX: 080493de
[ 76.020410] ESI: b7d10220 EDI: b7e068f0 EBP: bffad738 ESP: bffad6cc
[ 76.026668] DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b EFLAGS: 00000296
[ 76.033455] Modules linked in: x86_pkg_temp_thermal fuse configfs
[last unloaded: test_strscpy(N)]
[ 76.042444] ---[ end trace 0000000000000000 ]---
[ 76.047070] EIP: hugetlb_file_setup.cold+0x0/0x33
[ 76.051777] Code: b8 ea ff ff ff e9 52 8e 26 ff 0f 0b c7 04 24 70
75 63 d6 e8 a7 4a ff ff b8 ea ff ff ff e9 57 97 26 ff 0f 0b 0f 0b 0f
0b 0f 0b <0f> 0b 64 a1 58 b8 bd d6 c6 05 bd c0 a6 d6 01 8b 90 ec 03 00
00 05
[ 76.070550] EAX: c5360dd0 EBX: 00000000 ECX: 00000020 EDX: 00000000
[ 76.076841] ESI: 80000004 EDI: 00000005 EBP: c5405ea0 ESP: c5405e80
[ 76.083133] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 EFLAGS: 00010212
[ 76.089945] CR0: 80050033 CR2: 00000000 CR3: 06405000 CR4: 003506d0
[ 76.096211] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
[ 76.102483] DR6: fffe0ff0 DR7: 00000400# ./run_hugetlbfs_test.sh: line 60: 1300 Segmentation fault ./memfd_test hugetlbfs
# opening: ./mnt/memfd
# fuse: DONE
ok 3 selftests: memfd: run_hugetlbfs_test.sh
[4] https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.0.y/build/v6.0-916-g844297340351/testrun/12536148/suite/log-parser-test/tests/
[5] https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.0.y/build/v6.0-916-g844297340351/testrun/12536148/suite/log-parser-test/test/check-kernel-invalid-opcode/log
While running perf test cases on qemu_x86_64 this kernel BUG noticed [6].
unsupp '/usr/libexec/perf-core/tests/attr/test-record-branch-filter-ind_call' running '/usr/libexec/perf-core/tests/attr/test-record-group'
[ 204.124863] BUG: kernel NULL pointer dereference, address: 0000000000000198 [ 204.125878] #PF: supervisor read access in kernel mode [ 204.126482] #PF: error_code(0x0000) - not-present page [ 204.127127] PGD 0 P4D 0 [ 204.127435] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 204.127939] CPU: 3 PID: 574 Comm: perf-exec Not tainted 6.0.3-rc1 #1 [ 204.128711] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 [ 204.129619] RIP: 0010:x86_pmu_enable_event+0x43/0x130
Following kernel crash log noticed while running selftests: net: pmtu.sh on x15 device [7] with kselftest merge configs enabled.
# selftests: net: pmtu.sh
...
# TEST: IPv4 over vxlan6: PMTU exceptions [ OK ]
[ 169.299682] 8<--- cut here --- [ 169.302764] Unable to handle kernel paging request at virtual address 2c86c000 [ 169.310089] [2c86c000] *pgd=00000000 [ 169.313720] Internal error: Oops: 5 [#1] SMP ARM [ 169.318359] Modules linked in: act_csum act_pedit cls_flower
sch_prio ip_tables x_tables veth tun cfg80211 bluetooth snd_soc_simple_card snd_soc_simple_card_utils etnaviv gpu_sched onboard_usb_hub snd_soc_davinci_mcasp snd_soc_ti_udma snd_soc_ti_edma snd_soc_ti_sdma snd_soc_core ac97_bus snd_pcm_dmaengine snd_pcm snd_timer snd soundcore display_connector fuse [last unloaded:test_blackhole_dev]
[ 169.353576] CPU: 0 PID: 295 Comm: rngd Not tainted 6.0.3-rc1 #1 [ 169.359527] Hardware name: Generic DRA74X (Flattened Device Tree) [ 169.365631] PC is at percpu_counter_add_batch+0x28/0xc4
[7] https://lore.kernel.org/all/CA+G9fYvepPVpDn5AP6bwDukpx7h++avMPEUARuHyvJqWwQ84uQ@mail.gmail.com/T/#u
## Build
* kernel: 6.0.3-rc1
* git: ['https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc', 'https://gitlab.com/mrchapp/linux']
* git branch: linux-6.0.y
* git commit: 84429734035197a6ab8e79c852d5e4e6ed744703
* git describe: v6.0-916-g844297340351
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.0.y/build/v6.0-916-g844297340351
## No Test Regressions (compared to v6.0.2)
## No Metric Regressions (compared to v6.0.2)
## No Test Fixes (compared to v6.0.2)
## No Metric Fixes (compared to v6.0.2)
## Test result summary
total: 131365, pass: 113062, fail: 4832, skip: 13064, xfail: 407
## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 311 total, 307 passed, 4 failed
* arm64: 64 total, 64 passed, 0 failed
* i386: 55 total, 55 passed, 0 failed
* mips: 56 total, 55 passed, 1 failed
* parisc: 12 total, 12 passed, 0 failed
* powerpc: 69 total, 63 passed, 6 failed
* riscv: 27 total, 27 passed, 0 failed
* s390: 21 total, 21 passed, 0 failed
* sh: 24 total, 24 passed, 0 failed
* sparc: 12 total, 12 passed, 0 failed
* x86_64: 58 total, 58 passed, 0 failed
## Test suites summary
* /
* fwts
* igt-gpu-tools
* kself0009test-sync
* kself[
* kselft[
* kselftest-android
* kselftest-arm64
* kselftest-arm64/arm64.btitest.bti_c_func
* kselftest-arm64/arm64.btitest.bti_j_func
* kselftest-arm64/arm64.btitest.bti_jc_func
* kselftest-arm64/arm64.btitest.bti_none_func
* kselftest-arm64/arm64.btitest.nohint_func
* kselftest-arm64/arm64.btitest.paciasp_func
* kselftest-arm64/arm64.nobtitest.bti_c_func
* kselftest-arm64/arm64.nobtitest.bti_j_func
* kselftest-arm64/arm64.nobtitest.bti_jc_func
* kselftest-arm64/arm64.nobtitest.bti_none_func
* kselftest-arm64/arm64.nobtitest.nohint_func
* kselftest-arm64/arm64.nobtitest.paciasp_func
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers-dma-buf
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-filesystems-binderfs
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-membarrier
* kselftest-memfd
* kselftest-memory-hotplug
* kselftest-mincore
* kselftest-mount
* kselftest-mqueue
* kselftest-net
* kselftest-net-forwarding
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kunit
* kvm-unit-tests
* libgpiod
* libhugetlbfs
* log-parser-boot
* log-parser-test
* ltp-at
* 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-ip
* 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
* perf
* perf/Zstd-perf.data-compression
* rcutorture
* v4l2-compliance
* vdso
--
Linaro LKFT
https://lkft.linaro.org
Hi Greg,
Quoted 7 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.0.3 release. There are 862 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, 21 Oct 2022 08:30:19 +0000. Anything received after that time might be too late.
Build test (gcc version 12.2.1 20221016):
mips: 52 configs -> no failure
arm: 100 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]
[1]. https://openqa.qa.codethink.co.uk/tests/2018
Signature · 2 lines
Regards Sudip
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 6.0.3 release. There are 862 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, 21 Oct 2022 08:30:19 +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/v6.x/stable-review/patch-6.0.3-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-6.0.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.