5.4.235-rc1 review
Subsystems (6)
Greg Kroah-Hartman
maintainerPATCH 317/357 9p/rdma: unmap receive dma buffer in rdma_request()/post_recv()
In reply to Greg Kroah-HartmanFrom: Zhengchao Shao <[email protected]>
[ Upstream commit 74a25e6e916cb57dab4267a96fbe8864ed21abdb ]
When down_interruptible() or ib_post_send() failed in rdma_request(), receive dma buffer is not unmapped. Add unmap action to error path. Also if ib_post_recv() failed in post_recv(), dma buffer is not unmapped. Add unmap action to error path.
--- net/9p/trans_rdma.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-)
net/9p/trans_rdma.c +12 -3
@@ -385,6 +385,7 @@ post_recv(struct p9_client *client, struct p9_rdma_context *c)struct p9_trans_rdma *rdma = client->trans;struct ib_recv_wr wr;struct ib_sge sge; +int ret; c->busa = ib_dma_map_single(rdma->cm_id->device, c->rc.sdata, client->msize,
@@ -402,7 +403,12 @@ post_recv(struct p9_client *client, struct p9_rdma_context *c) wr.wr_cqe = &c->cqe; wr.sg_list = &sge; wr.num_sge =1 ; -return ib_post_recv (rdma->qp, &wr,NULL ); + + ret =ib_post_recv (rdma->qp, &wr,NULL ); +if (ret) +ib_dma_unmap_single (rdma->cm_id->device, c->busa, + client->msize,DMA_FROM_DEVICE ); +return ret; error:p9_debug (P9_DEBUG_ERROR ,"EIO\n" );
@@ -499,7 +505,7 @@ static int rdma_request(struct p9_client *client, struct p9_req_t *req)if (down_interruptible (&rdma->sq_sem)) { err = -EINTR ; - goto send_error; + goto dma_unmap; }/* Mark request as `sent' *before* we actually send it,
@@ -509,11 +515,14 @@ static int rdma_request(struct p9_client *client, struct p9_req_t *req) req->status =REQ_STATUS_SENT ; err =ib_post_send (rdma->qp, &wr,NULL );if (err) - goto send_error; + goto dma_unmap;/* Success */ return 0 ; +dma_unmap: +ib_dma_unmap_single (rdma->cm_id->device, c->busa, + c->req->tc.size,DMA_TO_DEVICE );/* Handle errors that happened during or while preparing the send: */ send_error: req->status =REQ_STATUS_ERROR ;
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 318/357 net/mlx5: Geneve, Fix handling of Geneve object id as error code
In reply to Greg Kroah-HartmanFrom: Maor Dickman <[email protected]>
[ Upstream commit d28a06d7dbedc598a06bd1e53a28125f87ca5d0c ]
On success, mlx5_geneve_tlv_option_create returns non negative Geneve object id. In case the object id is positive value the caller functions will handle it as an error (non zero) and will fail to offload the Geneve rule.
Fix this by changing caller function ,mlx5_geneve_tlv_option_add, to return 0 in case valid non negative object id was provided.
--- drivers/net/ethernet/mellanox/mlx5/core/lib/geneve.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/ethernet/mellanox/mlx5/core/lib/geneve.c +1 -0
@@ -105,6 +105,7 @@ int mlx5_geneve_tlv_option_add(struct mlx5_geneve *geneve, struct geneve_opt *op geneve->opt_type = opt->type; geneve->obj_id = res; geneve->refcount++; + res =0 ; } unlock:
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 319/357 nfc: fix memory leak of se_io context in nfc_genl_se_io
In reply to Greg Kroah-HartmanFrom: Fedor Pchelkin <[email protected]>
[ Upstream commit 25ff6f8a5a3b8dc48e8abda6f013e8cc4b14ffea ]
The callback context for sending/receiving APDUs to/from the selected secure element is allocated inside nfc_genl_se_io and supposed to be eventually freed in se_io_cb callback function. However, there are several error paths where the bwi_timer is not charged to call se_io_cb later, and the cb_context is leaked.
The patch proposes to free the cb_context explicitly on those error paths.
At the moment we can't simply check 'dev->ops->se_io()' return value as it may be negative in both cases: when the timer was charged and was not.
--- drivers/nfc/st-nci/se.c | 6 ++++++ drivers/nfc/st21nfca/se.c | 6 ++++++ net/nfc/netlink.c | 4 ++++ 3 files changed, 16 insertions(+)
drivers/nfc/st-nci/se.c +6 -0
@@ -665,6 +665,12 @@ int st_nci_se_io(struct nci_dev *ndev, u32 se_idx,ST_NCI_EVT_TRANSMIT_DATA , apdu, apdu_length);default : +/* Need to free cb_context here as at the moment we can't +* clearly indicate to the caller if the callback function +* would be called (and free it) or not. In both cases a +* negative value may be returned to the caller. +*/ +kfree (cb_context);return -ENODEV ; } }
drivers/nfc/st21nfca/se.c +6 -0
@@ -236,6 +236,12 @@ int st21nfca_hci_se_io(struct nfc_hci_dev *hdev, u32 se_idx,ST21NFCA_EVT_TRANSMIT_DATA , apdu, apdu_length);default : +/* Need to free cb_context here as at the moment we can't +* clearly indicate to the caller if the callback function +* would be called (and free it) or not. In both cases a +* negative value may be returned to the caller. +*/ +kfree (cb_context);return -ENODEV ; } }
net/nfc/netlink.c +4 -0
@@ -1450,7 +1450,11 @@ static int nfc_se_io(struct nfc_dev *dev, u32 se_idx, rc = dev->ops->se_io (dev, se_idx, apdu, apdu_length, cb, cb_context); +device_unlock (&dev->dev); +return rc; + error: +kfree (cb_context);device_unlock (&dev->dev);return rc; }
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 320/357 net/sched: act_sample: fix action bind logic
In reply to Greg Kroah-HartmanFrom: Pedro Tammela <[email protected]>
[ Upstream commit 4a20056a49a1854966562241922f68197f950539 ]
The TC architecture allows filters and actions to be created independently. In filters the user can reference action objects using:
tc action add action sample ... index 1
tc filter add ... action pedit index 1
In the current code for act_sample this is broken as it checks netlink attributes for create/update before actually checking if we are binding to an existing action.
tdc results:
1..29
ok 1 9784 - Add valid sample action with mandatory arguments
ok 2 5c91 - Add valid sample action with mandatory arguments and continue control action ok 3 334b - Add valid sample action with mandatory arguments and drop control action ok 4 da69 - Add valid sample action with mandatory arguments and reclassify control action ok 5 13ce - Add valid sample action with mandatory arguments and pipe control action ok 6 1886 - Add valid sample action with mandatory arguments and jump control action ok 7 7571 - Add sample action with invalid rate
ok 8 b6d4 - Add sample action with mandatory arguments and invalid control action ok 9 a874 - Add invalid sample action without mandatory arguments
ok 10 ac01 - Add invalid sample action without mandatory argument rate
ok 11 4203 - Add invalid sample action without mandatory argument group
ok 12 14a7 - Add invalid sample action without mandatory argument group
ok 13 8f2e - Add valid sample action with trunc argument
ok 14 45f8 - Add sample action with maximum rate argument
ok 15 ad0c - Add sample action with maximum trunc argument
ok 16 83a9 - Add sample action with maximum group argument
ok 17 ed27 - Add sample action with invalid rate argument
ok 18 2eae - Add sample action with invalid group argument
ok 19 6ff3 - Add sample action with invalid trunc size
ok 20 2b2a - Add sample action with invalid index
ok 21 dee2 - Add sample action with maximum allowed index
ok 22 560e - Add sample action with cookie
ok 23 704a - Replace existing sample action with new rate argument
ok 24 60eb - Replace existing sample action with new group argument
ok 25 2cce - Replace existing sample action with new trunc argument
ok 26 59d1 - Replace existing sample action with new control argument
ok 27 0a6e - Replace sample action with invalid goto chain control
ok 28 3872 - Delete sample action with valid index
ok 29 a394 - Delete sample action with invalid index
--- net/sched/act_sample.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)
net/sched/act_sample.c +9 -2
@@ -54,8 +54,8 @@ static int tcf_sample_init(struct net *net, struct nlattr *nla, sample_policy, NULL);if (ret <0 )return ret; -if (!tb[TCA_SAMPLE_PARMS ] || !tb[TCA_SAMPLE_RATE ] || - !tb[TCA_SAMPLE_PSAMPLE_GROUP ]) + +if (!tb[TCA_SAMPLE_PARMS ])return -EINVAL ; parm =nla_data (tb[TCA_SAMPLE_PARMS ]);
@@ -79,6 +79,13 @@ static int tcf_sample_init(struct net *net, struct nlattr *nla,tcf_idr_release (*a, bind);return -EEXIST ; } + +if (!tb[TCA_SAMPLE_RATE ] || !tb[TCA_SAMPLE_PSAMPLE_GROUP ]) { +NL_SET_ERR_MSG (extack,"sample rate and group are required" ); + err = -EINVAL ; + goto release_idr; + } + err =tcf_action_check_ctrlact (parm->action, tp, &goto_ch, extack);if (err <0 ) goto release_idr;
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 321/357 ARM: dts: spear320-hmi: correct STMPE GPIO compatible
In reply to Greg Kroah-HartmanFrom: Krzysztof Kozlowski <[email protected]>
[ Upstream commit 33a0c1b850c8c85f400531dab3a0b022cdb164b1 ]
The compatible is st,stmpe-gpio.
--- arch/arm/boot/dts/spear320-hmi.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/boot/dts/spear320-hmi.dts +1 -1
@@ -242,7 +242,7 @@ irq-trigger = <0x1>; stmpegpio: stmpe-gpio { - compatible = "stmpe,gpio"; + compatible = "st,stmpe-gpio"; reg = <0>; gpio-controller; #gpio-cells = <2>;
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 322/357 tcp: tcp_check_req() can be called from process context
In reply to Greg Kroah-HartmanFrom: Eric Dumazet <[email protected]>
[ Upstream commit 580f98cc33a260bb8c6a39ae2921b29586b84fdf ]
This is a follow up of commit 0a375c822497 ("tcp: tcp_rtx_synack() can be called from process context").
Frederick Lawler reported another "__this_cpu_add() in preemptible" warning caused by the same reason.
In my former patch I took care of tcp_rtx_synack()
but forgot that tcp_check_req() also contained some SNMP updates.
Note that some parts of tcp_check_req() always run in BH context, I added a comment to clarify this.
--- net/ipv4/tcp_minisocks.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
net/ipv4/tcp_minisocks.c +5 -2
@@ -563,6 +563,9 @@ EXPORT_SYMBOL(tcp_create_openreq_child);* validation and inside tcp_v4_reqsk_send_ack(). Can we do better? * * We don't need to initialize tmp_opt.sack_ok as we don't use the results +* +* Note: If @fastopen is true, this can be called from process context. +* Otherwise, this is from BH context. */ struct sock *tcp_check_req(struct sock *sk, struct sk_buff *skb,
@@ -715,7 +718,7 @@ struct sock *tcp_check_req(struct sock *sk, struct sk_buff *skb, &tcp_rsk(req)->last_oow_ack_time)) req->rsk_ops->send_ack (sk, skb, req);if (paws_reject) -__NET_INC_STATS (sock_net (sk),LINUX_MIB_PAWSESTABREJECTED ); +NET_INC_STATS (sock_net (sk),LINUX_MIB_PAWSESTABREJECTED );return NULL ; }
@@ -734,7 +737,7 @@ struct sock *tcp_check_req(struct sock *sk, struct sk_buff *skb,* "fourth, check the SYN bit" */ if (flg & (TCP_FLAG_RST |TCP_FLAG_SYN )) { -__TCP_INC_STATS (sock_net (sk),TCP_MIB_ATTEMPTFAILS ); +TCP_INC_STATS (sock_net (sk),TCP_MIB_ATTEMPTFAILS ); goto embryonic_reset; }
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 323/357 vc_screen: modify vcs_size() handling in vcs_read()
In reply to Greg Kroah-HartmanFrom: George Kennedy <[email protected]>
[ Upstream commit 46d733d0efc79bc8430d63b57ab88011806d5180 ]
Restore the vcs_size() handling in vcs_read() to what it had been in previous version.
--- drivers/tty/vt/vc_screen.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
drivers/tty/vt/vc_screen.c +1 -3
@@ -296,10 +296,8 @@ vcs_read(struct file *file, char __user *buf, size_t count, loff_t *ppos)*/ size =vcs_size (inode);if (size <0 ) { -if (read) -break ; ret = size; - goto unlock_out; +break ; }if (pos >= size)break ;
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 324/357 rtc: sun6i: Make external 32k oscillator optional
In reply to Greg Kroah-HartmanFrom: Jernej Skrabec <[email protected]>
[ Upstream commit ec98a87509f40324807dc179a7e3163d40709eba ]
Some boards, like OrangePi PC2 (H5), OrangePi Plus 2E (H3) and Tanix TX6 (H6) don't have external 32kHz oscillator. Till H6, it didn't really matter if external oscillator was enabled because HW detected error and fall back to internal one. H6 has same functionality but it's the first SoC which have "auto switch bypass" bit documented and always enabled in driver. This prevents RTC to work correctly if external crystal is not present on board. There are other side effects - all peripherals which depends on this clock also don't work (HDMI CEC for example).
Make clocks property optional. If it is present, select external oscillator. If not, stay on internal.
Stable-dep-of: 344f4030f6c5 ("rtc: sun6i: Always export the internal oscillator")
--- drivers/rtc/rtc-sun6i.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-)
drivers/rtc/rtc-sun6i.c +8 -8
@@ -251,19 +251,17 @@ static void __init sun6i_rtc_clk_init(struct device_node *node,writel (reg, rtc->base +SUN6I_LOSC_CTRL ); } -/* Switch to the external, more precise, oscillator */ - reg |=SUN6I_LOSC_CTRL_EXT_OSC ; -if (rtc->data->has_losc_en) - reg |=SUN6I_LOSC_CTRL_EXT_LOSC_EN ; +/* Switch to the external, more precise, oscillator, if present */ +if (of_get_property (node,"clocks" ,NULL )) { + reg |=SUN6I_LOSC_CTRL_EXT_OSC ; +if (rtc->data->has_losc_en) + reg |=SUN6I_LOSC_CTRL_EXT_LOSC_EN ; + }writel (reg, rtc->base +SUN6I_LOSC_CTRL );/* Yes, I know, this is ugly. */ sun6i_rtc = rtc; -/* Deal with old DTs */ -if (!of_get_property (node,"clocks" ,NULL )) - goto err; -/* Only read IOSC name from device tree if it is exported */ if (rtc->data->export_iosc) of_property_read_string_index(node, "clock-output-names", 2,
@@ -280,11 +278,13 @@ static void __init sun6i_rtc_clk_init(struct device_node *node, } parents[0 ] =clk_hw_get_name (rtc->int_osc); +/* If there is no external oscillator, this will be NULL and ... */ parents[1 ] =of_clk_get_parent_name (node,0 ); rtc->hw.init = &init; init.parent_names = parents; +/* ... number of clock parents will be 1. */ init.num_parents =of_clk_get_parent_count (node) +1 ;of_property_read_string_index (node,"clock-output-names" ,0 , &init.name);
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 325/357 rtc: sun6i: Always export the internal oscillator
In reply to Greg Kroah-HartmanFrom: Samuel Holland <[email protected]>
[ Upstream commit 344f4030f6c50a9db2d03021884c4bf36191b53a ]
On all variants of the hardware, the internal oscillator is one possible parent for the AR100 clock. It needs to be exported so we can model that relationship correctly in the devicetree.
--- drivers/rtc/rtc-sun6i.c | 16 ++++------------ 1 file changed, 4 insertions(+), 12 deletions(-)
drivers/rtc/rtc-sun6i.c +4 -12
@@ -129,7 +129,6 @@ struct sun6i_rtc_clk_data { unsigned int fixed_prescaler : 16; unsigned int has_prescaler : 1; unsigned int has_out_clk : 1; - unsigned int export_iosc : 1; unsigned int has_losc_en : 1; unsigned int has_auto_swt : 1; };
@@ -262,10 +261,8 @@ static void __init sun6i_rtc_clk_init(struct device_node *node,/* Yes, I know, this is ugly. */ sun6i_rtc = rtc; -/* Only read IOSC name from device tree if it is exported */ -if (rtc->data->export_iosc) -of_property_read_string_index (node,"clock-output-names" ,2 , - &iosc_name); +of_property_read_string_index (node,"clock-output-names" ,2 , + &iosc_name); rtc->int_osc = clk_hw_register_fixed_rate_with_accuracy(NULL, iosc_name,
@@ -306,13 +303,10 @@ static void __init sun6i_rtc_clk_init(struct device_node *node, goto err_register; } - clk_data->num =2 ; + clk_data->num =3 ; clk_data->hws[0 ] = &rtc->hw; clk_data->hws[1 ] =__clk_get_hw (rtc->ext_losc); -if (rtc->data->export_iosc) { - clk_data->hws[2 ] = rtc->int_osc; - clk_data->num =3 ; - } + clk_data->hws[2 ] = rtc->int_osc;of_clk_add_hw_provider (node, of_clk_hw_onecell_get, clk_data);return ;
@@ -352,7 +346,6 @@ static const struct sun6i_rtc_clk_data sun8i_h3_rtc_data = { .fixed_prescaler = 32, .has_prescaler = 1, .has_out_clk = 1, - .export_iosc = 1, };static void __init sun8i_h3_rtc_clk_init (struct device_node *node)
@@ -370,7 +363,6 @@ static const struct sun6i_rtc_clk_data sun50i_h6_rtc_data = { .fixed_prescaler = 32, .has_prescaler = 1, .has_out_clk = 1, - .export_iosc = 1, .has_losc_en = 1, .has_auto_swt = 1, };
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 326/357 scsi: ipr: Work around fortify-string warning
In reply to Greg Kroah-HartmanFrom: Arnd Bergmann <[email protected]>
[ Upstream commit ee4e7dfe4ffc9ca50c6875757bd119abfe22b5c5 ]
The ipr_log_vpd_compact() function triggers a fortified memcpy() warning about a potential string overflow with all versions of clang:
In file included from drivers/scsi/ipr.c:43:
In file included from include/linux/string.h:254:include/linux/fortify-string.h:520:4: error: call to '__write_overflow_field' declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror,-Wattribute-warning]
__write_overflow_field(p_size_field, size);
^include/linux/fortify-string.h:520:4: error: call to '__write_overflow_field' declared with 'warning' attribute: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror,-Wattribute-warning] 2 errors generated.
I don't see anything actually wrong with the function, but this is the only instance I can reproduce of the fortification going wrong in the kernel at the moment, so the easiest solution may be to rewrite the function into something that does not trigger the warning.
Instead of having a combined buffer for vendor/device/serial strings, use three separate local variables and just truncate the whitespace individually.
--- drivers/scsi/ipr.c | 41 +++++++++++++++++++++-------------------- 1 file changed, 21 insertions(+), 20 deletions(-)
drivers/scsi/ipr.c +21 -20
@@ -1517,23 +1517,22 @@ static void ipr_process_ccn(struct ipr_cmnd *ipr_cmd) }/** -* strip_and_pad_whitespace - Strip and pad trailing whitespace. -* @i: index into buffer -* @buf: string to modify +* strip_whitespace - Strip and pad trailing whitespace. +* @i: size of buffer +* @buf: string to modify * -* This function will strip all trailing whitespace, pad the end -* of the string with a single space, and NULL terminate the string. +* This function will strip all trailing whitespace and +* NUL terminate the string. * -* Return value: -* new length of string **/ -static int strip_and_pad_whitespace (int i,char *buf) +static void strip_whitespace (int i,char *buf) { +if (i <1 ) +return ; + i--;while (i && buf[i] ==' ' ) i--; - buf[i+1 ] =' ' ; - buf[i+2 ] ='\0' ; -return i +2 ; + buf[i+1 ] ='\0' ; }/**
@@ -1548,19 +1547,21 @@ static int strip_and_pad_whitespace(int i, char *buf)static void ipr_log_vpd_compact (char *prefix,struct ipr_hostrcb *hostrcb,struct ipr_vpd *vpd) { -char buffer[IPR_VENDOR_ID_LEN +IPR_PROD_ID_LEN +IPR_SERIAL_NUM_LEN +3 ]; -int i =0 ; +char vendor_id[IPR_VENDOR_ID_LEN +1 ]; +char product_id[IPR_PROD_ID_LEN +1 ]; +char sn[IPR_SERIAL_NUM_LEN +1 ]; -memcpy (buffer, vpd->vpids.vendor_id,IPR_VENDOR_ID_LEN ); - i =strip_and_pad_whitespace (IPR_VENDOR_ID_LEN -1 , buffer); +memcpy (vendor_id, vpd->vpids.vendor_id,IPR_VENDOR_ID_LEN ); +strip_whitespace (IPR_VENDOR_ID_LEN , vendor_id); -memcpy (&buffer[i], vpd->vpids.product_id,IPR_PROD_ID_LEN ); - i =strip_and_pad_whitespace (i +IPR_PROD_ID_LEN -1 , buffer); +memcpy (product_id, vpd->vpids.product_id,IPR_PROD_ID_LEN ); +strip_whitespace (IPR_PROD_ID_LEN , product_id); -memcpy (&buffer[i], vpd->sn,IPR_SERIAL_NUM_LEN ); - buffer[IPR_SERIAL_NUM_LEN + i] ='\0' ; +memcpy (sn, vpd->sn,IPR_SERIAL_NUM_LEN ); +strip_whitespace (IPR_SERIAL_NUM_LEN , sn); -ipr_hcam_err (hostrcb,"%s VPID/SN: %s\n" , prefix, buffer); +ipr_hcam_err (hostrcb,"%s VPID/SN: %s %s %s\n" , prefix, + vendor_id, product_id, sn); }/**
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 327/357 thermal: intel: quark_dts: fix error pointer dereference
In reply to Greg Kroah-HartmanFrom: Dan Carpenter <[email protected]>
[ Upstream commit f1b930e740811d416de4d2074da48b6633a672c8 ]
If alloc_soc_dts() fails, then we can just return. Trying to free "soc_dts" will lead to an Oops.
--- drivers/thermal/intel/intel_quark_dts_thermal.c | 12 ++---------- 1 file changed, 2 insertions(+), 10 deletions(-)
drivers/thermal/intel/intel_quark_dts_thermal.c +2 -10
@@ -440,22 +440,14 @@ MODULE_DEVICE_TABLE(x86cpu, qrk_thermal_ids);static int __init intel_quark_thermal_init (void ) { -int err =0 ; -if (!x86_match_cpu (qrk_thermal_ids) || !iosf_mbi_available ())return -ENODEV ; soc_dts =alloc_soc_dts (); -if (IS_ERR (soc_dts)) { - err =PTR_ERR (soc_dts); - goto err_free; - } +if (IS_ERR (soc_dts)) +return PTR_ERR (soc_dts);return 0 ; - -err_free: -free_soc_dts (soc_dts); -return err; } static void __exit intel_quark_thermal_exit(void)
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 328/357 thermal: intel: BXT_PMIC: select REGMAP instead of depending on it
In reply to Greg Kroah-HartmanFrom: Randy Dunlap <[email protected]>
[ Upstream commit 1467fb960349dfa5e300658f1a409dde2cfb0c51 ]
REGMAP is a hidden (not user visible) symbol. Users cannot set it directly thru "make *config", so drivers should select it instead of depending on it if they need it.
Consistently using "select" or "depends on" can also help reduce Kconfig circular dependency issues.
Therefore, change the use of "depends on REGMAP" to "select REGMAP".
--- drivers/thermal/intel/Kconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/thermal/intel/Kconfig +2 -1
@@ -60,7 +60,8 @@ endmenu config INTEL_BXT_PMIC_THERMAL tristate "Intel Broxton PMIC thermal driver" - depends on X86 && INTEL_SOC_PMIC_BXTWC && REGMAP + depends on X86 && INTEL_SOC_PMIC_BXTWC + select REGMAP help Select this driver for Intel Broxton PMIC with ADC channels monitoring system temperature measurements and alerts.
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 329/357 tracing: Add NULL checks for buffer in ring_buffer_free_read_page()
In reply to Greg Kroah-HartmanFrom: Jia-Ju Bai <[email protected]>
[ Upstream commit 3e4272b9954094907f16861199728f14002fcaf6 ]
In a previous commit 7433632c9ff6, buffer, buffer->buffers and buffer->buffers[cpu] in ring_buffer_wake_waiters() can be NULL, and thus the related checks are added.
However, in the same call stack, these variables are also used in ring_buffer_free_read_page():
tracing_buffers_release()
ring_buffer_wake_waiters(iter->array_buffer->buffer)
cpu_buffer = buffer->buffers[cpu] -> Add checks by previous commit
ring_buffer_free_read_page(iter->array_buffer->buffer)
cpu_buffer = buffer->buffers[cpu] -> No checkThus, to avod possible null-pointer derefernces, the related checks should be added.
These results are reported by a static tool designed by myself.
--- kernel/trace/ring_buffer.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
kernel/trace/ring_buffer.c +6 -1
@@ -4769,11 +4769,16 @@ EXPORT_SYMBOL_GPL(ring_buffer_alloc_read_page);*/ void ring_buffer_free_read_page (struct ring_buffer *buffer,int cpu,void *data) { -struct ring_buffer_per_cpu *cpu_buffer = buffer->buffers[cpu]; +struct ring_buffer_per_cpu *cpu_buffer;struct buffer_data_page *bpage = data;struct page *page =virt_to_page (bpage);unsigned long flags; +if (!buffer || !buffer->buffers || !buffer->buffers[cpu]) +return ; + + cpu_buffer = buffer->buffers[cpu]; +/* If the page is still in use someplace else, we can't reuse it */ if (page_ref_count (page) >1 ) goto out;
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 330/357 firmware/efi sysfb_efi: Add quirk for Lenovo IdeaPad Duet 3
In reply to Greg Kroah-HartmanFrom: Darrell Kavanagh <[email protected]>
[ Upstream commit e1d447157f232c650e6f32c9fb89ff3d0207c69a ]
Another Lenovo convertable which reports a landscape resolution of 1920x1200 with a pitch of (1920 * 4) bytes, while the actual framebuffer has a resolution of 1200x1920 with a pitch of (1200 * 4) bytes.
--- arch/x86/kernel/sysfb_efi.c | 8 ++++++++ 1 file changed, 8 insertions(+)
arch/x86/kernel/sysfb_efi.c +8 -0
@@ -264,6 +264,14 @@ static const struct dmi_system_id efifb_dmi_swap_width_height[] __initconst = { "Lenovo ideapad D330-10IGM"), }, }, + { + /* Lenovo IdeaPad Duet 3 10IGL5 with 1200x1920 portrait screen */ + .matches = { + DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"), + DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, + "IdeaPad Duet 3 10IGL5"), + }, + }, {}, };
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 331/357 mfd: arizona: Use pm_runtime_resume_and_get() to prevent refcnt leak
In reply to Greg Kroah-HartmanFrom: Liang He <[email protected]>
[ Upstream commit 4414a7ab80cebf715045e3c4d465feefbad21139 ]
In arizona_clk32k_enable(), we should use pm_runtime_resume_and_get() as pm_runtime_get_sync() will increase the refcnt even when it returns an error.
--- drivers/mfd/arizona-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mfd/arizona-core.c +1 -1
@@ -45,7 +45,7 @@ int arizona_clk32k_enable(struct arizona *arizona)if (arizona->clk32k_ref ==1 ) {switch (arizona->pdata.clk32k_src) {case ARIZONA_32KZ_MCLK1 : - ret =pm_runtime_get_sync (arizona->dev); + ret =pm_runtime_resume_and_get (arizona->dev);if (ret !=0 ) goto err_ref; ret =clk_prepare_enable (arizona->mclk[ARIZONA_MCLK1 ]);
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 332/357 media: uvcvideo: Handle cameras with invalid descriptors
In reply to Greg Kroah-HartmanFrom: Ricardo Ribalda <[email protected]>
[ Upstream commit 41ddb251c68ac75c101d3a50a68c4629c9055e4c ]
If the source entity does not contain any pads, do not create a link.
--- drivers/media/usb/uvc/uvc_entity.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/media/usb/uvc/uvc_entity.c +1 -1
@@ -37,7 +37,7 @@ static int uvc_mc_create_links(struct uvc_video_chain *chain,continue ; remote =uvc_entity_by_id (chain->dev, entity->baSourceID[i]); -if (remote ==NULL ) +if (remote ==NULL || remote->num_pads ==0 )return -EINVAL ; source = (UVC_ENTITY_TYPE (remote) ==UVC_TT_STREAMING )
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 333/357 media: uvcvideo: Handle errors from calls to usb_string
In reply to Greg Kroah-HartmanFrom: Guenter Roeck <[email protected]>
[ Upstream commit 4867bb590ae445bcfaa711a86b603c97e94574b3 ]
On a Webcam from Quanta, we see the following error.
usb 3-5: New USB device found, idVendor=0408, idProduct=30d2, bcdDevice= 0.03 usb 3-5: New USB device strings: Mfr=3, Product=1, SerialNumber=2 usb 3-5: Product: USB2.0 HD UVC WebCam
usb 3-5: Manufacturer: Quanta
usb 3-5: SerialNumber: 0x0001
...
uvcvideo: Found UVC 1.10 device USB2.0 HD UVC WebCam (0408:30d2)
uvcvideo: Failed to initialize entity for entity 5
uvcvideo: Failed to register entities (-22).
The Webcam reports an entity of type UVC_VC_EXTENSION_UNIT. It reports a string index of '7' associated with that entity. The attempt to read that string from the camera fails with error -32 (-EPIPE). usb_string() returns that error, but it is ignored. As result, the entity name is empty. This later causes v4l2_device_register_subdev() to return -EINVAL, and no entities are registered as result.
While this appears to be a firmware problem with the camera, the kernel should still handle the situation gracefully. To do that, check the return value from usb_string(). If it reports an error, assign the entity's default name.
--- drivers/media/usb/uvc/uvc_driver.c | 48 ++++++++++++------------------ 1 file changed, 19 insertions(+), 29 deletions(-)
drivers/media/usb/uvc/uvc_driver.c +19 -29
@@ -1060,10 +1060,8 @@ static int uvc_parse_vendor_control(struct uvc_device *dev, + n;memcpy (unit->extension.bmControls, &buffer[23 +p],2 *n); -if (buffer[24 +p+2 *n] !=0 ) -usb_string (udev, buffer[24 +p+2 *n], unit->name, -sizeof (unit->name)); -else +if (buffer[24 +p+2 *n] ==0 || +usb_string (udev, buffer[24 +p+2 *n], unit->name,sizeof (unit->name)) <0 )sprintf (unit->name,"Extension %u" , buffer[3 ]);list_add_tail (&unit->list, &dev->entities);
@@ -1188,15 +1186,15 @@ static int uvc_parse_standard_control(struct uvc_device *dev,memcpy (term->media.bmTransportModes, &buffer[10 +n], p); } -if (buffer[7 ] !=0 ) -usb_string (udev, buffer[7 ], term->name, -sizeof (term->name)); -else if (UVC_ENTITY_TYPE (term) ==UVC_ITT_CAMERA ) -sprintf (term->name,"Camera %u" , buffer[3 ]); -else if (UVC_ENTITY_TYPE (term) ==UVC_ITT_MEDIA_TRANSPORT_INPUT ) -sprintf (term->name,"Media %u" , buffer[3 ]); -else -sprintf (term->name,"Input %u" , buffer[3 ]); +if (buffer[7 ] ==0 || +usb_string (udev, buffer[7 ], term->name,sizeof (term->name)) <0 ) { +if (UVC_ENTITY_TYPE (term) ==UVC_ITT_CAMERA ) +sprintf (term->name,"Camera %u" , buffer[3 ]); +if (UVC_ENTITY_TYPE (term) ==UVC_ITT_MEDIA_TRANSPORT_INPUT ) +sprintf (term->name,"Media %u" , buffer[3 ]); +else +sprintf (term->name,"Input %u" , buffer[3 ]); + }list_add_tail (&term->list, &dev->entities);break ;
@@ -1228,10 +1226,8 @@ static int uvc_parse_standard_control(struct uvc_device *dev,memcpy (term->baSourceID, &buffer[7 ],1 ); -if (buffer[8 ] !=0 ) -usb_string (udev, buffer[8 ], term->name, -sizeof (term->name)); -else +if (buffer[8 ] ==0 || +usb_string (udev, buffer[8 ], term->name,sizeof (term->name)) <0 )sprintf (term->name,"Output %u" , buffer[3 ]);list_add_tail (&term->list, &dev->entities);
@@ -1253,10 +1249,8 @@ static int uvc_parse_standard_control(struct uvc_device *dev,memcpy (unit->baSourceID, &buffer[5 ], p); -if (buffer[5 +p] !=0 ) -usb_string (udev, buffer[5 +p], unit->name, -sizeof (unit->name)); -else +if (buffer[5 +p] ==0 || +usb_string (udev, buffer[5 +p], unit->name,sizeof (unit->name)) <0 )sprintf (unit->name,"Selector %u" , buffer[3 ]);list_add_tail (&unit->list, &dev->entities);
@@ -1286,10 +1280,8 @@ static int uvc_parse_standard_control(struct uvc_device *dev,if (dev->uvc_version >=0x0110 ) unit->processing.bmVideoStandards = buffer[9 +n]; -if (buffer[8 +n] !=0 ) -usb_string (udev, buffer[8 +n], unit->name, -sizeof (unit->name)); -else +if (buffer[8 +n] ==0 || +usb_string (udev, buffer[8 +n], unit->name,sizeof (unit->name)) <0 )sprintf (unit->name,"Processing %u" , buffer[3 ]);list_add_tail (&unit->list, &dev->entities);
@@ -1317,10 +1309,8 @@ static int uvc_parse_standard_control(struct uvc_device *dev, unit->extension.bmControls = (u8 *)unit +sizeof (*unit);memcpy (unit->extension.bmControls, &buffer[23 +p], n); -if (buffer[23 +p+n] !=0 ) -usb_string (udev, buffer[23 +p+n], unit->name, -sizeof (unit->name)); -else +if (buffer[23 +p+n] ==0 || +usb_string (udev, buffer[23 +p+n], unit->name,sizeof (unit->name)) <0 )sprintf (unit->name,"Extension %u" , buffer[3 ]);list_add_tail (&unit->list, &dev->entities);
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 334/357 media: uvcvideo: Quirk for autosuspend in Logitech B910 and C910
In reply to Greg Kroah-HartmanFrom: Ricardo Ribalda <[email protected]>
[ Upstream commit 136effa754b57632f99574fc4a3433e0cfc031d9 ]
Logitech B910 and C910 firmware are unable to recover from a USB autosuspend. When it resumes, the device is in a state where it only produces invalid frames. Eg:
$ echo 0xFFFF > /sys/module/uvcvideo/parameters/trace # enable verbose log $ yavta -c1 -n1 --file='frame#.jpg' --format MJPEG --size=1920x1080 /dev/video1 [350438.435219] uvcvideo: uvc_v4l2_open [350438.529794] uvcvideo: Resuming interface 2 [350438.529801] uvcvideo: Resuming interface 3 [350438.529991] uvcvideo: Trying format 0x47504a4d (MJPG): 1920x1080. [350438.529996] uvcvideo: Using default frame interval 33333.3 us (30.0 fps). [350438.551496] uvcvideo: uvc_v4l2_mmap [350438.555890] uvcvideo: Device requested 3060 B/frame bandwidth. [350438.555896] uvcvideo: Selecting alternate setting 11 (3060 B/frame bandwidth). [350438.556362] uvcvideo: Allocated 5 URB buffers of 32x3060 bytes each. [350439.316468] uvcvideo: Marking buffer as bad (error bit set). [350439.316475] uvcvideo: Frame complete (EOF found). [350439.316477] uvcvideo: EOF in empty payload. [350439.316484] uvcvideo: frame 1 stats: 149/261/417 packets, 1/149/417 pts (early initial), 416/417 scr, last pts/stc/sof 2976325734/2978107243/249 [350439.384510] uvcvideo: Marking buffer as bad (error bit set). [350439.384516] uvcvideo: Frame complete (EOF found). [350439.384518] uvcvideo: EOF in empty payload. [350439.384525] uvcvideo: frame 2 stats: 265/379/533 packets, 1/265/533 pts (early initial), 532/533 scr, last pts/stc/sof 2979524454/2981305193/316 [350439.448472] uvcvideo: Marking buffer as bad (error bit set). [350439.448478] uvcvideo: Frame complete (EOF found). [350439.448480] uvcvideo: EOF in empty payload. [350439.448487] uvcvideo: frame 3 stats: 265/377/533 packets, 1/265/533 pts (early initial), 532/533 scr, last pts/stc/sof 2982723174/2984503144/382 ...(loop)...
The devices can leave this invalid state if the alternate setting of the streaming interface is toggled.
This patch adds a quirk for this device so it can be autosuspended properly.
lsusb -v:
Bus 001 Device 049: ID 046d:0821 Logitech, Inc. HD Webcam C910 Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0x046d Logitech, Inc.
idProduct 0x0821 HD Webcam C910
bcdDevice 0.10
iManufacturer 0 iProduct 0 iSerial 1 390022B0 bNumConfigurations 1
--- drivers/media/usb/uvc/uvc_driver.c | 18 ++++++++++++++++++ drivers/media/usb/uvc/uvc_video.c | 11 +++++++++++ drivers/media/usb/uvc/uvcvideo.h | 1 + 3 files changed, 30 insertions(+)
drivers/media/usb/uvc/uvc_driver.c +18 -0
@@ -2462,6 +2462,24 @@ static const struct usb_device_id uvc_ids[] = { .bInterfaceSubClass = 1, .bInterfaceProtocol = 0, .driver_info = (kernel_ulong_t)&uvc_quirk_probe_minmax }, +/* Logitech, Webcam C910 */ + { .match_flags = USB_DEVICE_ID_MATCH_DEVICE + | USB_DEVICE_ID_MATCH_INT_INFO, + .idVendor = 0x046d, + .idProduct = 0x0821, + .bInterfaceClass = USB_CLASS_VIDEO, + .bInterfaceSubClass = 1, + .bInterfaceProtocol = 0, + .driver_info = UVC_INFO_QUIRK(UVC_QUIRK_WAKE_AUTOSUSPEND)}, + /* Logitech, Webcam B910 */ + { .match_flags = USB_DEVICE_ID_MATCH_DEVICE + | USB_DEVICE_ID_MATCH_INT_INFO, + .idVendor = 0x046d, + .idProduct = 0x0823, + .bInterfaceClass = USB_CLASS_VIDEO, + .bInterfaceSubClass = 1, + .bInterfaceProtocol = 0, + .driver_info = UVC_INFO_QUIRK(UVC_QUIRK_WAKE_AUTOSUSPEND)}, /* Logitech Quickcam Fusion */ { .match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO,
drivers/media/usb/uvc/uvc_video.c +11 -0
@@ -1903,6 +1903,17 @@ static int uvc_video_start_transfer(struct uvc_streaming *stream,uvc_trace (UVC_TRACE_VIDEO ,"Selecting alternate setting %u " "(%u B/frame bandwidth).\n" , altsetting, best_psize); +/* +* Some devices, namely the Logitech C910 and B910, are unable +* to recover from a USB autosuspend, unless the alternate +* setting of the streaming interface is toggled. +*/ +if (stream->dev->quirks &UVC_QUIRK_WAKE_AUTOSUSPEND ) { +usb_set_interface (stream->dev->udev, intfnum, + altsetting); +usb_set_interface (stream->dev->udev, intfnum,0 ); + } + ret =usb_set_interface (stream->dev->udev, intfnum, altsetting);if (ret <0 )return ret;
drivers/media/usb/uvc/uvcvideo.h +1 -0
@@ -199,6 +199,7 @@#define UVC_QUIRK_RESTORE_CTRLS_ON_INIT 0x00000400#define UVC_QUIRK_FORCE_Y8 0x00000800#define UVC_QUIRK_FORCE_BPP 0x00001000 +#define UVC_QUIRK_WAKE_AUTOSUSPEND 0x00002000/* Format flags */ #define UVC_FMT_FLAG_COMPRESSED 0x00000001
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 335/357 media: uvcvideo: Silence memcpy() run-time false positive warnings
In reply to Greg Kroah-HartmanFrom: Kees Cook <[email protected]>
[ Upstream commit b839212988575c701aab4d3d9ca15e44c87e383c ]
The memcpy() in uvc_video_decode_meta() intentionally copies across the length and flags members and into the trailing buf flexible array. Split the copy so that the compiler can better reason about (the lack of) buffer overflows here. Avoid the run-time false positive warning:
memcpy: detected field-spanning write (size 12) of single field "&meta->length" at drivers/media/usb/uvc/uvc_video.c:1355 (size 1)
Additionally fix a typo in the documentation for struct uvc_meta_buf.
--- drivers/media/usb/uvc/uvc_video.c | 4 +++- include/uapi/linux/uvcvideo.h | 2 +- 2 files changed, 4 insertions(+), 2 deletions(-)
drivers/media/usb/uvc/uvc_video.c +3 -1
@@ -1308,7 +1308,9 @@ static void uvc_video_decode_meta(struct uvc_streaming *stream,if (has_scr)memcpy (stream->clock.last_scr, scr,6 ); -memcpy (&meta->length, mem, length); + meta->length = mem[0 ]; + meta->flags = mem[1 ]; +memcpy (meta->buf, &mem[2 ], length -2 ); meta_buf->bytesused += length +sizeof (meta->ns) +sizeof (meta->sof); uvc_trace(UVC_TRACE_FRAME,
include/uapi/linux/uvcvideo.h +1 -1
@@ -86,7 +86,7 @@ struct uvc_xu_control_query {* struct. The first two fields are added by the driver, they can be used for * clock synchronisation. The rest is an exact copy of a UVC payload header. * Only complete objects with complete buffers are included. Therefore it's -* always sizeof(meta->ts) + sizeof(meta->sof) + meta->length bytes large. +* always sizeof(meta->ns) + sizeof(meta->sof) + meta->length bytes large. */ struct uvc_meta_buf {__u64 ns;
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 336/357 staging: emxx_udc: Add checks for dma_alloc_coherent()
In reply to Greg Kroah-HartmanFrom: Yuan Can <[email protected]>
[ Upstream commit f6510a93cfd8c6c79b4dda0f2967cdc6df42eff4 ]
As the dma_alloc_coherent may return NULL, the return value needs to be checked to avoid NULL poineter dereference.
--- drivers/staging/emxx_udc/emxx_udc.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/staging/emxx_udc/emxx_udc.c +6 -1
@@ -2593,10 +2593,15 @@ static int nbu2ss_ep_queue(struct usb_ep *_ep, req->unaligned = false;if (req->unaligned) { -if (!ep->virt_buf) +if (!ep->virt_buf) { ep->virt_buf =dma_alloc_coherent (udc->dev,PAGE_SIZE , &ep->phys_buf,GFP_ATOMIC |GFP_DMA ); +if (!ep->virt_buf) { +spin_unlock_irqrestore (&udc->lock, flags); +return -ENOMEM ; + } + }if (ep->epnum >0 ) {if (ep->direct ==USB_DIR_IN ) memcpy(ep->virt_buf, req->req.buf,
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 337/357 tty: fix out-of-bounds access in tty_driver_lookup_tty()
In reply to Greg Kroah-HartmanFrom: Sven Schnelle <[email protected]>
[ Upstream commit db4df8e9d79e7d37732c1a1b560958e8dadfefa1 ]
When specifying an invalid console= device like console=tty3270, tty_driver_lookup_tty() returns the tty struct without checking whether index is a valid number.
To reproduce:
qemu-system-x86_64 -enable-kvm -nographic -serial mon:stdio \
-kernel ../linux-build-x86/arch/x86/boot/bzImage \
-append "console=ttyS0 console=tty3270"
This crashes with:
[ 0.770599] BUG: kernel NULL pointer dereference, address: 00000000000000ef [ 0.771265] #PF: supervisor read access in kernel mode [ 0.771773] #PF: error_code(0x0000) - not-present page [ 0.772609] Oops: 0000 [#1] PREEMPT SMP PTI [ 0.774878] RIP: 0010:tty_open+0x268/0x6f0 [ 0.784013] chrdev_open+0xbd/0x230 [ 0.784444] ? cdev_device_add+0x80/0x80 [ 0.784920] do_dentry_open+0x1e0/0x410 [ 0.785389] path_openat+0xca9/0x1050 [ 0.785813] do_filp_open+0xaa/0x150 [ 0.786240] file_open_name+0x133/0x1b0 [ 0.786746] filp_open+0x27/0x50 [ 0.787244] console_on_rootfs+0x14/0x4d [ 0.787800] kernel_init_freeable+0x1e4/0x20d [ 0.788383] ? rest_init+0xc0/0xc0 [ 0.788881] kernel_init+0x11/0x120 [ 0.789356] ret_from_fork+0x22/0x30
--- drivers/tty/tty_io.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
drivers/tty/tty_io.c +5 -3
@@ -1156,14 +1156,16 @@ static struct tty_struct *tty_driver_lookup_tty(struct tty_driver *driver, {struct tty_struct *tty; -if (driver->ops->lookup) +if (driver->ops->lookup) {if (!file) tty =ERR_PTR (-EIO );else tty = driver->ops->lookup (driver, file, idx); -else + }else { +if (idx >= driver->num) +return ERR_PTR (-EINVAL ); tty = driver->ttys[idx]; - + }if (!IS_ERR (tty))tty_kref_get (tty);return tty;
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 338/357 tty: serial: fsl_lpuart: disable the CTS when send break signal
In reply to Greg Kroah-HartmanFrom: Sherry Sun <[email protected]>
[ Upstream commit c4c81db5cf8bc53d6160c3abf26d382c841aa434 ]
LPUART IP has a bug that it treats the CTS as higher priority than the break signal, which cause the break signal sending through UARTCTRL_SBK may impacted by the CTS input if the HW flow control is enabled.
Add this workaround patch to fix the IP bug, we can disable CTS before asserting SBK to avoid any interference from CTS, and re-enable it when break off.
Such as for the bluetooth chip power save feature, host can let the BT chip get into sleep state by sending a UART break signal, and wake it up by turning off the UART break. If the BT chip enters the sleep mode successfully, it will pull up the CTS line, if the BT chip is woken up, it will pull down the CTS line. If without this workaround patch, the UART TX pin cannot send the break signal successfully as it affected by the BT CTS pin. After adding this patch, the BT power save feature can work well.
--- drivers/tty/serial/fsl_lpuart.c | 24 ++++++++++++++++++++++-- 1 file changed, 22 insertions(+), 2 deletions(-)
drivers/tty/serial/fsl_lpuart.c +22 -2
@@ -1370,12 +1370,32 @@ static void lpuart_break_ctl(struct uart_port *port, int break_state)static void lpuart32_break_ctl (struct uart_port *port,int break_state) { -unsigned long temp; +unsigned long temp, modem; +struct tty_struct *tty; +unsigned int cflag =0 ; + + tty =tty_port_tty_get (&port->state->port); +if (tty) { + cflag = tty->termios.c_cflag; +tty_kref_put (tty); + } temp =lpuart32_read (port,UARTCTRL ) & ~UARTCTRL_SBK ; + modem =lpuart32_read (port,UARTMODIR ); -if (break_state !=0 ) +if (break_state !=0 ) { temp |=UARTCTRL_SBK ; +/* +* LPUART CTS has higher priority than SBK, need to disable CTS before +* asserting SBK to avoid any interference if flow control is enabled. +*/ +if (cflag &CRTSCTS && modem &UARTMODIR_TXCTSE ) +lpuart32_write (port, modem & ~UARTMODIR_TXCTSE ,UARTMODIR ); + }else { +/* Re-enable the CTS when break off. */ +if (cflag &CRTSCTS && !(modem &UARTMODIR_TXCTSE )) +lpuart32_write (port, modem |UARTMODIR_TXCTSE ,UARTMODIR ); + }lpuart32_write (port, temp,UARTCTRL ); }
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 339/357 mei: bus-fixup:upon error print return values of send and receive
In reply to Greg Kroah-HartmanFrom: Alexander Usyskin <[email protected]>
[ Upstream commit 4b8659e2c258e4fdac9ccdf06cc20c0677894ef9 ]
For easier debugging, upon error, print also return values from __mei_cl_recv() and __mei_cl_send() functions.
--- drivers/misc/mei/bus-fixup.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)
drivers/misc/mei/bus-fixup.c +4 -4
@@ -178,7 +178,7 @@ static int mei_fwver(struct mei_cl_device *cldev) ret =__mei_cl_send (cldev->cl, buf,sizeof (struct mkhi_msg_hdr ),MEI_CL_IO_TX_BLOCKING );if (ret <0 ) { -dev_err (&cldev->dev,"Could not send ReqFWVersion cmd\n" ); +dev_err (&cldev->dev,"Could not send ReqFWVersion cmd ret = %d\n" , ret);return ret; }
@@ -190,7 +190,7 @@ static int mei_fwver(struct mei_cl_device *cldev)* Should be at least one version block, * error out if nothing found */ -dev_err (&cldev->dev,"Could not read FW version\n" ); +dev_err (&cldev->dev,"Could not read FW version ret = %d\n" , bytes_recv);return -EIO ; }
@@ -339,7 +339,7 @@ static int mei_nfc_if_version(struct mei_cl *cl, ret =__mei_cl_send (cl, (u8 *)&cmd,sizeof (struct mei_nfc_cmd ),MEI_CL_IO_TX_BLOCKING );if (ret <0 ) { -dev_err (bus->dev,"Could not send IF version cmd\n" ); +dev_err (bus->dev,"Could not send IF version cmd ret = %d\n" , ret);return ret; }
@@ -354,7 +354,7 @@ static int mei_nfc_if_version(struct mei_cl *cl, ret =0 ; bytes_recv =__mei_cl_recv (cl, (u8 *)reply, if_version_length,0 ,0 );if (bytes_recv <0 || (size_t )bytes_recv < if_version_length) { -dev_err (bus->dev,"Could not read IF version\n" ); +dev_err (bus->dev,"Could not read IF version ret = %d\n" , bytes_recv); ret = -EIO ; goto err; }
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 340/357 tools/iio/iio_utils:fix memory leak
In reply to Greg Kroah-HartmanFrom: Yulong Zhang <[email protected]>
[ Upstream commit f2edf0c819a4823cd6c288801ce737e8d4fcde06 ]
1. fopen sysfs without fclose.
2. asprintf filename without free.
3. if asprintf return error,do not need to free the buffer.
--- tools/iio/iio_utils.c | 23 ++++++----------------- 1 file changed, 6 insertions(+), 17 deletions(-)
tools/iio/iio_utils.c +6 -17
@@ -262,6 +262,7 @@ int iioutils_get_param_float(float *output, const char *param_name,if (fscanf (sysfsfp,"%f" , output) !=1 ) ret = errno ? -errno : -ENODATA ; +fclose (sysfsfp);break ; } error_free_filename:
@@ -342,9 +343,9 @@ int build_channel_array(const char *device_dir, } sysfsfp =fopen (filename,"r" ); +free (filename);if (!sysfsfp) { ret = -errno; -free (filename); goto error_close_dir; }
@@ -354,7 +355,6 @@ int build_channel_array(const char *device_dir,if (fclose (sysfsfp))perror ("build_channel_array(): Failed to close file" ); -free (filename); goto error_close_dir; }if (ret ==1 )
@@ -362,11 +362,9 @@ int build_channel_array(const char *device_dir,if (fclose (sysfsfp)) { ret = -errno; -free (filename); goto error_close_dir; } -free (filename); } *ci_array =malloc (sizeof (**ci_array) * (*counter));
@@ -392,9 +390,9 @@ int build_channel_array(const char *device_dir, } sysfsfp =fopen (filename,"r" ); +free (filename);if (!sysfsfp) { ret = -errno; -free (filename); count--; goto error_cleanup_array; }
@@ -402,20 +400,17 @@ int build_channel_array(const char *device_dir, errno =0 ;if (fscanf (sysfsfp,"%i" , ¤t_enabled) !=1 ) { ret = errno ? -errno : -ENODATA ; -free (filename); count--; goto error_cleanup_array; }if (fclose (sysfsfp)) { ret = -errno; -free (filename); count--; goto error_cleanup_array; }if (!current_enabled) { -free (filename); count--;continue ; }
@@ -426,7 +421,6 @@ int build_channel_array(const char *device_dir,strlen (ent->d_name) - strlen("_en"));if (!current->name) { -free (filename); ret = -ENOMEM ; count--; goto error_cleanup_array;
@@ -436,7 +430,6 @@ int build_channel_array(const char *device_dir, ret =iioutils_break_up_name (current->name, ¤t->generic_name);if (ret) { -free (filename);free (current->name); count--; goto error_cleanup_array;
@@ -447,17 +440,16 @@ int build_channel_array(const char *device_dir, scan_el_dir, current->name);if (ret <0 ) { -free (filename); ret = -ENOMEM ; goto error_cleanup_array; } sysfsfp =fopen (filename,"r" ); +free (filename);if (!sysfsfp) { ret = -errno; -fprintf (stderr,"failed to open %s\n" , - filename); -free (filename); +fprintf (stderr,"failed to open %s/%s_index\n" , + scan_el_dir, current->name); goto error_cleanup_array; }
@@ -467,17 +459,14 @@ int build_channel_array(const char *device_dir,if (fclose (sysfsfp))perror ("build_channel_array(): Failed to close file" ); -free (filename); goto error_cleanup_array; }if (fclose (sysfsfp)) { ret = -errno; -free (filename); goto error_cleanup_array; } -free (filename);/* Find the scale */ ret = iioutils_get_param_float(¤t->scale, "scale",
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 341/357 iio: accel: mma9551_core: Prevent uninitialized variable in mma9551_read_status_word()
In reply to Greg Kroah-HartmanFrom: Harshit Mogalapalli <[email protected]>
[ Upstream commit e56d2c34ce9dc122b1a618172ec0e05e50adb9e9 ]
Smatch Warns: drivers/iio/accel/mma9551_core.c:357
mma9551_read_status_word() error: uninitialized symbol 'v'.
When (offset >= 1 << 12) is true mma9551_transfer() will return -EINVAL without 'v' being initialized, so check for the error and return.
Note: Not a bug as such because the caller checks return value and doesn't not use this parameter in the problem case.
--- drivers/iio/accel/mma9551_core.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/iio/accel/mma9551_core.c +4 -1
@@ -354,9 +354,12 @@ int mma9551_read_status_word(struct i2c_client *client, u8 app_id, ret =mma9551_transfer (client, app_id,MMA9551_CMD_READ_STATUS , reg,NULL ,0 , (u8 *)&v,2 ); +if (ret <0 ) +return ret; + *val =be16_to_cpu (v); -return ret; +return 0 ; }EXPORT_SYMBOL (mma9551_read_status_word);
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 342/357 iio: accel: mma9551_core: Prevent uninitialized variable in mma9551_read_config_word()
In reply to Greg Kroah-HartmanFrom: Harshit Mogalapalli <[email protected]>
[ Upstream commit 64a68158738ec8f520347144352f7a09bdb9e169 ]
Smatch Warns:drivers/iio/accel/mma9551_core.c:299
mma9551_read_config_word() error: uninitialized symbol 'v'.
When (offset >= 1 << 12) is true mma9551_transfer() will return -EINVAL without 'v' being initialized, so check for the error and return.
Note: No actual bug as caller checks the return value and does not use the parameter in the problem case.
--- drivers/iio/accel/mma9551_core.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/iio/accel/mma9551_core.c +4 -1
@@ -296,9 +296,12 @@ int mma9551_read_config_word(struct i2c_client *client, u8 app_id, ret =mma9551_transfer (client, app_id,MMA9551_CMD_READ_CONFIG , reg,NULL ,0 , (u8 *)&v,2 ); +if (ret <0 ) +return ret; + *val =be16_to_cpu (v); -return ret; +return 0 ; }EXPORT_SYMBOL (mma9551_read_config_word);
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 343/357 usb: host: xhci: mvebu: Iterate over array indexes instead of using pointer math
In reply to Greg Kroah-HartmanFrom: Kees Cook <[email protected]>
[ Upstream commit 0fbd2cda92cdb00f72080665554a586f88bca821 ]
Walking the dram->cs array was seen as accesses beyond the first array item by the compiler. Instead, use the array index directly. This allows for run-time bounds checking under CONFIG_UBSAN_BOUNDS as well. Seen with GCC 13 with -fstrict-flex-arrays:
In function 'xhci_mvebu_mbus_config',
inlined from 'xhci_mvebu_mbus_init_quirk' at ../drivers/usb/host/xhci-mvebu.c:66:2:../drivers/usb/host/xhci-mvebu.c:37:28: warning: array subscript 0 is outside array bounds of 'const struct mbus_dram_window[0]' [-Warray-bounds=]
37 | writel(((cs->size - 1) & 0xffff0000) | (cs->mbus_attr << 8) |
| ~~^~~~~~
--- drivers/usb/host/xhci-mvebu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/host/xhci-mvebu.c +1 -1
@@ -33,7 +33,7 @@ static void xhci_mvebu_mbus_config(void __iomem *base,/* Program each DRAM CS in a seperate window */ for (win =0 ; win < dram->num_cs; win++) { -const struct mbus_dram_window *cs = dram->cs + win; +const struct mbus_dram_window *cs = &dram->cs[win]; writel(((cs->size - 1) & 0xffff0000) | (cs->mbus_attr << 8) | (dram->mbus_dram_target_id << 4) | 1,
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 344/357 USB: ene_usb6250: Allocate enough memory for full object
In reply to Greg Kroah-HartmanFrom: Kees Cook <[email protected]>
[ Upstream commit ce33e64c1788912976b61314b56935abd4bc97ef ]
The allocation of PageBuffer is 512 bytes in size, but the dereferencing of struct ms_bootblock_idi (also size 512) happens at a calculated offset within the allocation, which means the object could potentially extend beyond the end of the allocation. Avoid this case by just allocating enough space to catch any accesses beyond the end. Seen with GCC 13:
../drivers/usb/storage/ene_ub6250.c: In function 'ms_lib_process_bootblock':../drivers/usb/storage/ene_ub6250.c:1050:44: warning: array subscript 'struct ms_bootblock_idi[0]' is partly outside array bounds of 'unsigned char[512]' [-Warray-bounds=]
1050 | if (le16_to_cpu(idi->wIDIgeneralConfiguration) != MS_IDI_GENERAL_CONF)
| ^~../include/uapi/linux/byteorder/little_endian.h:37:51: note: in definition of macro '__le16_to_cpu'
37 | #define __le16_to_cpu(x) ((__force __u16)(__le16)(x))
| ^../drivers/usb/storage/ene_ub6250.c:1050:29: note: in expansion of macro 'le16_to_cpu'
1050 | if (le16_to_cpu(idi->wIDIgeneralConfiguration) != MS_IDI_GENERAL_CONF)
| ^~~~~~~~~~~
In file included from ../drivers/usb/storage/ene_ub6250.c:5:
In function 'kmalloc',
inlined from 'ms_lib_process_bootblock' at ../drivers/usb/storage/ene_ub6250.c:942:15:
../include/linux/slab.h:580:24: note: at offset [256, 512] into object of size 512 allocated by 'kmalloc_trace'
580 | return kmalloc_trace(
| ^~~~~~~~~~~~~~
581 | kmalloc_caches[kmalloc_type(flags)][index],
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
582 | flags, size);
| ~~~~~~~~~~~~--- drivers/usb/storage/ene_ub6250.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/storage/ene_ub6250.c +1 -1
@@ -938,7 +938,7 @@ static int ms_lib_process_bootblock(struct us_data *us, u16 PhyBlock, u8 *PageDastruct ms_lib_type_extdat ExtraData;struct ene_ub6250_info *info = (struct ene_ub6250_info *) us->extra; - PageBuffer =kmalloc (MS_BYTES_PER_PAGE ,GFP_KERNEL ); + PageBuffer =kzalloc (MS_BYTES_PER_PAGE *2 ,GFP_KERNEL );if (PageBuffer ==NULL )return (u32)-1 ;
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 345/357 usb: uvc: Enumerate valid values for color matching
In reply to Greg Kroah-HartmanFrom: Daniel Scally <[email protected]>
[ Upstream commit e16cab9c1596e251761d2bfb5e1467950d616963 ]
The color matching descriptors defined in the UVC Specification contain 3 fields with discrete numeric values representing particular settings. Enumerate those values so that later code setting them can be more readable.
--- include/uapi/linux/usb/video.h | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+)
include/uapi/linux/usb/video.h +30 -0
@@ -179,6 +179,36 @@#define UVC_CONTROL_CAP_AUTOUPDATE (1 << 3)#define UVC_CONTROL_CAP_ASYNCHRONOUS (1 << 4) +/* 3.9.2.6 Color Matching Descriptor Values */ +enum uvc_color_primaries_values { +UVC_COLOR_PRIMARIES_UNSPECIFIED , +UVC_COLOR_PRIMARIES_BT_709_SRGB , +UVC_COLOR_PRIMARIES_BT_470_2_M , +UVC_COLOR_PRIMARIES_BT_470_2_B_G , +UVC_COLOR_PRIMARIES_SMPTE_170M , +UVC_COLOR_PRIMARIES_SMPTE_240M , +}; + +enum uvc_transfer_characteristics_values { +UVC_TRANSFER_CHARACTERISTICS_UNSPECIFIED , +UVC_TRANSFER_CHARACTERISTICS_BT_709 , +UVC_TRANSFER_CHARACTERISTICS_BT_470_2_M , +UVC_TRANSFER_CHARACTERISTICS_BT_470_2_B_G , +UVC_TRANSFER_CHARACTERISTICS_SMPTE_170M , +UVC_TRANSFER_CHARACTERISTICS_SMPTE_240M , +UVC_TRANSFER_CHARACTERISTICS_LINEAR , +UVC_TRANSFER_CHARACTERISTICS_SRGB , +}; + +enum uvc_matrix_coefficients { +UVC_MATRIX_COEFFICIENTS_UNSPECIFIED , +UVC_MATRIX_COEFFICIENTS_BT_709 , +UVC_MATRIX_COEFFICIENTS_FCC , +UVC_MATRIX_COEFFICIENTS_BT_470_2_B_G , +UVC_MATRIX_COEFFICIENTS_SMPTE_170M , +UVC_MATRIX_COEFFICIENTS_SMPTE_240M , +}; +/* ------------------------------------------------------------------------ * UVC structures */
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 346/357 kernel/fail_function: fix memory leak with using debugfs_lookup()
In reply to Greg Kroah-HartmanFrom: Greg Kroah-Hartman <[email protected]>
[ Upstream commit 2bb3669f576559db273efe49e0e69f82450efbca ]
When calling debugfs_lookup() the result must have dput() called on it, otherwise the memory will leak over time. To make things simpler, just call debugfs_lookup_and_remove() instead which handles all of the logic at once.
--- kernel/fail_function.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)
kernel/fail_function.c +1 -4
@@ -163,10 +163,7 @@ static void fei_debugfs_add_attr(struct fei_attr *attr)static void fei_debugfs_remove_attr (struct fei_attr *attr) { -struct dentry *dir; - - dir =debugfs_lookup (attr->kp.symbol_name, fei_debugfs_dir); -debugfs_remove_recursive (dir); +debugfs_lookup_and_remove (attr->kp.symbol_name, fei_debugfs_dir); }static int fei_kprobe_handler (struct kprobe *kp,struct pt_regs *regs)
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 347/357 PCI: Add ACS quirk for Wangxun NICs
In reply to Greg Kroah-HartmanFrom: Mengyuan Lou <[email protected]>
[ Upstream commit a2b9b123ccac913e9f9b80337d687a2fe786a634 ]
Wangxun has verified there is no peer-to-peer between functions for the below selection of SFxxx, RP1000 and RP2000 NICS. They may be multi-function devices, but the hardware does not advertise ACS capability.
Add an ACS quirk for these devices so the functions can be in independent IOMMU groups.
--- drivers/pci/quirks.c | 22 ++++++++++++++++++++++ include/linux/pci_ids.h | 2 ++ 2 files changed, 24 insertions(+)
drivers/pci/quirks.c +22 -0
@@ -4843,6 +4843,26 @@ static int pci_quirk_brcm_acs(struct pci_dev *dev, u16 acs_flags) PCI_ACS_SV | PCI_ACS_RR | PCI_ACS_CR | PCI_ACS_UF); } +/* +* Wangxun 10G/1G NICs have no ACS capability, and on multi-function +* devices, peer-to-peer transactions are not be used between the functions. +* So add an ACS quirk for below devices to isolate functions. +* SFxxx 1G NICs(em). +* RP1000/RP2000 10G NICs(sp). +*/ +static int pci_quirk_wangxun_nic_acs (struct pci_dev *dev,u16 acs_flags) +{ +switch (dev->device) { + case 0x0100 ... 0x010F: +case 0x1001 : +case 0x2001 : +return pci_acs_ctrl_enabled (acs_flags, +PCI_ACS_SV |PCI_ACS_RR |PCI_ACS_CR |PCI_ACS_UF ); + } + +return false; +} + static const struct pci_dev_acs_enabled { u16 vendor; u16 device;
@@ -4988,6 +5008,8 @@ static const struct pci_dev_acs_enabled { { PCI_VENDOR_ID_NXP, 0x8d9b, pci_quirk_nxp_rp_acs },/* Zhaoxin Root/Downstream Ports */ { PCI_VENDOR_ID_ZHAOXIN, PCI_ANY_ID, pci_quirk_zhaoxin_pcie_ports_acs }, +/* Wangxun nics */ + { PCI_VENDOR_ID_WANGXUN, PCI_ANY_ID, pci_quirk_wangxun_nic_acs }, { 0 } };
include/linux/pci_ids.h +2 -0
@@ -3024,6 +3024,8 @@#define PCI_DEVICE_ID_INTEL_VMD_9A0B 0x9a0b#define PCI_DEVICE_ID_INTEL_S21152BB 0xb152 +#define PCI_VENDOR_ID_WANGXUN 0x8088 +#define PCI_VENDOR_ID_SCALEMP 0x8686#define PCI_DEVICE_ID_SCALEMP_VSMP_CTL 0x1010
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 348/357 phy: rockchip-typec: Fix unsigned comparison with less than zero
In reply to Greg Kroah-HartmanFrom: Jiapeng Chong <[email protected]>
[ Upstream commit f765c59c5a72546a2d74a92ae5d0eb0329d8e247 ]
The dp and ufp are defined as bool type, the return value type of function extcon_get_state should be int, so the type of dp and ufp are modified to int.
./drivers/phy/rockchip/phy-rockchip-typec.c:827:12-14: WARNING: Unsigned expression compared with zero: dp > 0.
--- drivers/phy/rockchip/phy-rockchip-typec.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/phy/rockchip/phy-rockchip-typec.c +1 -2
@@ -808,9 +808,8 @@ static int tcphy_get_mode(struct rockchip_typec_phy *tcphy)struct extcon_dev *edev = tcphy->extcon;union extcon_property_value property;unsigned int id; -bool ufp, dp;u8 mode; -int ret; +int ret, ufp, dp;if (!edev)return MODE_DFP_USB ;
Signature · 1 line
2.39.2
Greg Kroah-Hartman
maintainerPATCH 349/357 net: tls: avoid hanging tasks on the tx_lock
In reply to Greg Kroah-HartmanFrom: Jakub Kicinski <[email protected]>
commit f3221361dc85d4de22586ce8441ec2c67b454f5d upstream.
syzbot sent a hung task report and Eric explains that adversarial receiver may keep RWIN at 0 for a long time, so we are not guaranteed to make forward progress. Thread which took tx_lock and went to sleep may not release tx_lock for hours. Use interruptible sleep where possible and reschedule the work if it can't take the lock.
Testing: existing selftest passes
--- net/tls/tls_sw.c | 26 +++++++++++++++++++------- 1 file changed, 19 insertions(+), 7 deletions(-)
net/tls/tls_sw.c +19 -7
@@ -945,7 +945,9 @@ int tls_sw_sendmsg(struct sock *sk, struif (msg->msg_flags & ~(MSG_MORE |MSG_DONTWAIT |MSG_NOSIGNAL ))return -EOPNOTSUPP ; -mutex_lock (&tls_ctx->tx_lock); + ret =mutex_lock_interruptible (&tls_ctx->tx_lock); +if (ret) +return ret;lock_sock (sk);if (unlikely (msg->msg_controllen)) {
@@ -1279,7 +1281,9 @@ int tls_sw_sendpage(struct sock *sk, str MSG_SENDPAGE_NOTLAST | MSG_SENDPAGE_NOPOLICY))return -EOPNOTSUPP ; -mutex_lock (&tls_ctx->tx_lock); + ret =mutex_lock_interruptible (&tls_ctx->tx_lock); +if (ret) +return ret;lock_sock (sk); ret =tls_sw_do_sendpage (sk, page, offset, size, flags);release_sock (sk);
@@ -2263,11 +2267,19 @@ static void tx_work_handler(struct work_if (!test_and_clear_bit (BIT_TX_SCHEDULED , &ctx->tx_bitmask))return ; -mutex_lock (&tls_ctx->tx_lock); -lock_sock (sk); -tls_tx_records (sk,-1 ); -release_sock (sk); -mutex_unlock (&tls_ctx->tx_lock); + +if (mutex_trylock (&tls_ctx->tx_lock)) { +lock_sock (sk); +tls_tx_records (sk,-1 ); +release_sock (sk); +mutex_unlock (&tls_ctx->tx_lock); + }else if (!test_and_set_bit (BIT_TX_SCHEDULED , &ctx->tx_bitmask)) { +/* Someone is holding the tx_lock, they will likely run Tx +* and cancel the work on their way out of the lock section. +* Schedule a long delay just in case. +*/ +schedule_delayed_work (&ctx->tx_work.work,msecs_to_jiffies (10 )); + } }void tls_sw_write_space (struct sock *sk,struct tls_context *ctx)
Greg Kroah-Hartman
maintainerPATCH 350/357 x86/resctrl: Apply READ_ONCE/WRITE_ONCE to task_struct.{rmid,closid}
In reply to Greg Kroah-HartmanFrom: Valentin Schneider <[email protected]>
commit 6d3b47ddffed70006cf4ba360eef61e9ce097d8f upstream.
A CPU's current task can have its {closid, rmid} fields read locally while they are being concurrently written to from another CPU. This can happen anytime __resctrl_sched_in() races with either __rdtgroup_move_task() or rdt_move_group_tasks().
Prevent load / store tearing for those accesses by giving them the READ_ONCE() / WRITE_ONCE() treatment.
--- arch/x86/include/asm/resctrl_sched.h | 11 +++++++---- arch/x86/kernel/cpu/resctrl/rdtgroup.c | 10 +++++----- 2 files changed, 12 insertions(+), 9 deletions(-)
arch/x86/include/asm/resctrl_sched.h +7 -4
@@ -56,19 +56,22 @@ static void __resctrl_sched_in(void)struct resctrl_pqr_state *state =this_cpu_ptr (&pqr_state);u32 closid = state->default_closid;u32 rmid = state->default_rmid; +u32 tmp;/* * If this task has a closid/rmid assigned, use it. * Else use the closid/rmid assigned to this cpu. */ if (static_branch_likely (&rdt_alloc_enable_key)) { -if (current->closid) - closid = current->closid; + tmp =READ_ONCE (current->closid); +if (tmp) + closid = tmp; }if (static_branch_likely (&rdt_mon_enable_key)) { -if (current->rmid) - rmid = current->rmid; + tmp =READ_ONCE (current->rmid); +if (tmp) + rmid = tmp; }if (closid != state->cur_closid || rmid != state->cur_rmid) {
arch/x86/kernel/cpu/resctrl/rdtgroup.c +5 -5
@@ -563,11 +563,11 @@ static int __rdtgroup_move_task(struct t*/ if (rdtgrp->type ==RDTCTRL_GROUP ) { - tsk->closid = rdtgrp->closid; - tsk->rmid = rdtgrp->mon.rmid; +WRITE_ONCE (tsk->closid, rdtgrp->closid); +WRITE_ONCE (tsk->rmid, rdtgrp->mon.rmid); }else if (rdtgrp->type ==RDTMON_GROUP ) {if (rdtgrp->mon.parent->closid == tsk->closid) { - tsk->rmid = rdtgrp->mon.rmid; +WRITE_ONCE (tsk->rmid, rdtgrp->mon.rmid); }else {rdt_last_cmd_puts ("Can't move task to different control group\n" );return -EINVAL ;
@@ -2177,8 +2177,8 @@ static void rdt_move_group_tasks(structfor_each_process_thread (p, t) {if (!from ||is_closid_match (t, from) ||is_rmid_match (t, from)) { - t->closid = to->closid; - t->rmid = to->mon.rmid; +WRITE_ONCE (t->closid, to->closid); +WRITE_ONCE (t->rmid, to->mon.rmid);/* * Order the closid/rmid stores above before the loads
Greg Kroah-Hartman
maintainerPATCH 351/357 x86/resctl: fix scheduler confusion with current
In reply to Greg Kroah-HartmanFrom: Linus Torvalds <[email protected]>
commit 7fef099702527c3b2c5234a2ea6a24411485a13a upstream.
The implementation of 'current' on x86 is very intentionally special: it is a very common thing to look up, and it uses 'this_cpu_read_stable()' to get the current thread pointer efficiently from per-cpu storage.
And the keyword in there is 'stable': the current thread pointer never changes as far as a single thread is concerned. Even if when a thread is preempted, or moved to another CPU, or even across an explicit call 'schedule()' that thread will still have the same value for 'current'.
It is, after all, the kernel base pointer to thread-local storage. That's why it's stable to begin with, but it's also why it's important enough that we have that special 'this_cpu_read_stable()' access for it.
So this is all done very intentionally to allow the compiler to treat 'current' as a value that never visibly changes, so that the compiler can do CSE and combine multiple different 'current' accesses into one.
However, there is obviously one very special situation when the currently running thread does actually change: inside the scheduler itself.
So the scheduler code paths are special, and do not have a 'current' thread at all. Instead there are _two_ threads: the previous and the next thread - typically called 'prev' and 'next' (or prev_p/next_p) internally.
So this is all actually quite straightforward and simple, and not all that complicated.
Except for when you then have special code that is run in scheduler context, that code then has to be aware that 'current' isn't really a valid thing. Did you mean 'prev'? Did you mean 'next'?
In fact, even if then look at the code, and you use 'current' after the new value has been assigned to the percpu variable, we have explicitly told the compiler that 'current' is magical and always stable. So the compiler is quite free to use an older (or newer) value of 'current', and the actual assignment to the percpu storage is not relevant even if it might look that way.
Which is exactly what happened in the resctl code, that blithely used 'current' in '__resctrl_sched_in()' when it really wanted the new process state (as implied by the name: we're scheduling 'into' that new resctl state). And clang would end up just using the old thread pointer value at least in some configurations.
This could have happened with gcc too, and purely depends on random compiler details. Clang just seems to have been more aggressive about moving the read of the per-cpu current_task pointer around.
The fix is trivial: just make the resctl code adhere to the scheduler rules of using the prev/next thread pointer explicitly, instead of using 'current' in a situation where it just wasn't valid.
That same code is then also used outside of the scheduler context (when a thread resctl state is explicitly changed), and then we will just pass in 'current' as that pointer, of course. There is no ambiguity in that case.
The fix may be trivial, but noticing and figuring out what went wrong was not. The credit for that goes to Stephane Eranian.
--- arch/x86/include/asm/resctrl_sched.h | 12 ++++++------ arch/x86/kernel/cpu/resctrl/rdtgroup.c | 4 ++-- arch/x86/kernel/process_32.c | 2 +- arch/x86/kernel/process_64.c | 2 +- 4 files changed, 10 insertions(+), 10 deletions(-)
arch/x86/include/asm/resctrl_sched.h +6 -6
@@ -51,7 +51,7 @@ DECLARE_STATIC_KEY_FALSE(rdt_mon_enable_* simple as possible. * Must be called with preemption disabled. */ -static void __resctrl_sched_in (void ) +static inline void __resctrl_sched_in (struct task_struct *tsk) {struct resctrl_pqr_state *state =this_cpu_ptr (&pqr_state);u32 closid = state->default_closid;
@@ -63,13 +63,13 @@ static void __resctrl_sched_in(void)* Else use the closid/rmid assigned to this cpu. */ if (static_branch_likely (&rdt_alloc_enable_key)) { - tmp =READ_ONCE (current->closid); + tmp =READ_ONCE (tsk->closid);if (tmp) closid = tmp; }if (static_branch_likely (&rdt_mon_enable_key)) { - tmp =READ_ONCE (current->rmid); + tmp =READ_ONCE (tsk->rmid);if (tmp) rmid = tmp; }
@@ -81,15 +81,15 @@ static void __resctrl_sched_in(void) } } -static inline void resctrl_sched_in (void ) +static inline void resctrl_sched_in (struct task_struct *tsk) {if (static_branch_likely (&rdt_enable_key)) -__resctrl_sched_in (); +__resctrl_sched_in (tsk); }#else -static inline void resctrl_sched_in (void ) {} +static inline void resctrl_sched_in (struct task_struct *tsk) {}#endif /* CONFIG_X86_CPU_RESCTRL */
arch/x86/kernel/cpu/resctrl/rdtgroup.c +2 -2
@@ -311,7 +311,7 @@ static void update_cpu_closid_rmid(void* executing task might have its own closid selected. Just reuse * the context switch code. */ -resctrl_sched_in (); +resctrl_sched_in (current); }/*
@@ -532,7 +532,7 @@ static void _update_task_closid_rmid(voi* Otherwise, the MSR is updated when the task is scheduled in. */ if (task == current) -resctrl_sched_in (); +resctrl_sched_in (task); }static void update_task_closid_rmid (struct task_struct *t)
arch/x86/kernel/process_32.c +1 -1
@@ -293,7 +293,7 @@ __switch_to(struct task_struct *prev_p,switch_fpu_finish (next_p);/* Load the Intel cache allocation PQR MSR. */ -resctrl_sched_in (); +resctrl_sched_in (next_p);return prev_p; }
arch/x86/kernel/process_64.c +1 -1
@@ -610,7 +610,7 @@ __switch_to(struct task_struct *prev_p, }/* Load the Intel cache allocation PQR MSR. */ -resctrl_sched_in (); +resctrl_sched_in (next_p);return prev_p; }
Greg Kroah-Hartman
maintainerPATCH 352/357 Bluetooth: hci_sock: purge socket queues in the destruct() callback
In reply to Greg Kroah-HartmanFrom: Nguyen Dinh Phi <[email protected]>
commit 709fca500067524381e28a5f481882930eebac88 upstream.
The receive path may take the socket right before hci_sock_release(), but it may enqueue the packets to the socket queues after the call to skb_queue_purge(), therefore the socket can be destroyed without clear its queues completely.
Moving these skb_queue_purge() to the hci_sock_destruct() will fix this issue, because nothing is referencing the socket at this point.
--- net/bluetooth/hci_sock.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
net/bluetooth/hci_sock.c +7 -4
@@ -881,10 +881,6 @@ static int hci_sock_release(struct socke }sock_orphan (sk); - -skb_queue_purge (&sk->sk_receive_queue); -skb_queue_purge (&sk->sk_write_queue); -release_sock (sk);sock_put (sk);return 0 ;
@@ -1985,6 +1981,12 @@ done:return err; } +static void hci_sock_destruct (struct sock *sk) +{ +skb_queue_purge (&sk->sk_receive_queue); +skb_queue_purge (&sk->sk_write_queue); +} +static const struct proto_ops hci_sock_ops = { .family =PF_BLUETOOTH , .owner =THIS_MODULE ,
@@ -2035,6 +2037,7 @@ static int hci_sock_create(struct net *n sock->state =SS_UNCONNECTED ; sk->sk_state =BT_OPEN ; + sk->sk_destruct = hci_sock_destruct;bt_sock_link (&hci_sk_list, sk);return 0 ;
Greg Kroah-Hartman
maintainerPATCH 353/357 tcp: Fix listen() regression in 5.4.229.
In reply to Greg Kroah-HartmanFrom: Kuniyuki Iwashima <[email protected]>
commit fdaf88531cfd17b2a710cceb3141ef6f9085ff40 upstream.
When we backport dadd0dcaa67d ("net/ulp: prevent ULP without clone op from entering the LISTEN status"), we have accidentally backported a part of 7a7160edf1bf ("net: Return errno in sk->sk_prot->get_port().") and removed err = -EADDRINUSE in inet_csk_listen_start().
Thus, listen() no longer returns -EADDRINUSE even if ->get_port() failed as reported in [0].
We set -EADDRINUSE to err just before ->get_port() to fix the regression.
[0]: https://lore.kernel.org/stable/[email protected]/
--- net/ipv4/inet_connection_sock.c | 1 + 1 file changed, 1 insertion(+)
net/ipv4/inet_connection_sock.c +1 -0
@@ -932,6 +932,7 @@ int inet_csk_listen_start(struct sock *s* It is OK, because this socket enters to hash table only * after validation is complete. */ + err = -EADDRINUSE ;inet_sk_state_store (sk,TCP_LISTEN );if (!sk->sk_prot->get_port (sk, inet->inet_num)) { inet->inet_sport =htons (inet->inet_num);
Greg Kroah-Hartman
maintainerPATCH 354/357 media: uvcvideo: Provide sync and async uvc_ctrl_status_event
In reply to Greg Kroah-HartmanFrom: Ricardo Ribalda <[email protected]>
commit d9c8763e61295be0a21dc04ad9c379d5d17c3d86 upstream.
Split the functionality of void uvc_ctrl_status_event_work in two, so it can be called by functions outside interrupt context and not part of an URB.
--- drivers/media/usb/uvc/uvc_ctrl.c | 25 +++++++++++++++---------- drivers/media/usb/uvc/uvc_status.c | 3 ++- drivers/media/usb/uvc/uvcvideo.h | 4 +++- 3 files changed, 20 insertions(+), 12 deletions(-)
drivers/media/usb/uvc/uvc_ctrl.c +15 -10
@@ -1275,17 +1275,12 @@ static void uvc_ctrl_send_slave_event(stuvc_ctrl_send_event (chain, handle, ctrl, mapping, val, changes); } -static void uvc_ctrl_status_event_work (struct work_struct *work) +void uvc_ctrl_status_event (struct uvc_video_chain *chain, +struct uvc_control *ctrl,const u8 *data) { - struct uvc_device *dev = container_of(work, struct uvc_device, - async_ctrl.work); -struct uvc_ctrl_work *w = &dev->async_ctrl; -struct uvc_video_chain *chain = w->chain;struct uvc_control_mapping *mapping; -struct uvc_control *ctrl = w->ctrl;struct uvc_fh *handle;unsigned int i; -int ret;mutex_lock (&chain->ctrl_mutex);
@@ -1293,7 +1288,7 @@ static void uvc_ctrl_status_event_work(s ctrl->handle =NULL ;list_for_each_entry (mapping, &ctrl->info.mappings, list) { -s32 value =__uvc_ctrl_get_value (mapping, w->data); +s32 value =__uvc_ctrl_get_value (mapping, data);/* * handle may be NULL here if the device sends auto-update
@@ -1312,6 +1307,16 @@ static void uvc_ctrl_status_event_work(s }mutex_unlock (&chain->ctrl_mutex); +} + +static void uvc_ctrl_status_event_work (struct work_struct *work) +{ + struct uvc_device *dev = container_of(work, struct uvc_device, + async_ctrl.work); +struct uvc_ctrl_work *w = &dev->async_ctrl; +int ret; + +uvc_ctrl_status_event (w->chain, w->ctrl, w->data);/* Resubmit the URB. */ w->urb->interval = dev->int_ep->desc.bInterval;
@@ -1321,8 +1326,8 @@ static void uvc_ctrl_status_event_work(s ret); } -bool uvc_ctrl_status_event (struct urb *urb,struct uvc_video_chain *chain, -struct uvc_control *ctrl,const u8 *data) +bool uvc_ctrl_status_event_async (struct urb *urb,struct uvc_video_chain *chain, +struct uvc_control *ctrl,const u8 *data) {struct uvc_device *dev = chain->dev;struct uvc_ctrl_work *w = &dev->async_ctrl;
drivers/media/usb/uvc/uvc_status.c +2 -1
@@ -179,7 +179,8 @@ static bool uvc_event_control(struct urbswitch (status->bAttribute) {case UVC_CTRL_VALUE_CHANGE : -return uvc_ctrl_status_event (urb, chain, ctrl, status->bValue); +return uvc_ctrl_status_event_async (urb, chain, ctrl, + status->bValue);case UVC_CTRL_INFO_CHANGE :case UVC_CTRL_FAILURE_CHANGE :
drivers/media/usb/uvc/uvcvideo.h +3 -1
@@ -833,7 +833,9 @@ int uvc_ctrl_add_mapping(struct uvc_videint uvc_ctrl_init_device (struct uvc_device *dev);void uvc_ctrl_cleanup_device (struct uvc_device *dev);int uvc_ctrl_restore_values (struct uvc_device *dev); -bool uvc_ctrl_status_event (struct urb *urb,struct uvc_video_chain *chain, +bool uvc_ctrl_status_event_async (struct urb *urb,struct uvc_video_chain *chain, +struct uvc_control *ctrl,const u8 *data); +void uvc_ctrl_status_event (struct uvc_video_chain *chain,struct uvc_control *ctrl,const u8 *data);int uvc_ctrl_begin (struct uvc_video_chain *chain);
Greg Kroah-Hartman
maintainerPATCH 355/357 media: uvcvideo: Fix race condition with usb_kill_urb
In reply to Greg Kroah-HartmanFrom: Ricardo Ribalda <[email protected]>
commit 619d9b710cf06f7a00a17120ca92333684ac45a8 upstream.
usb_kill_urb warranties that all the handlers are finished when it returns, but does not protect against threads that might be handling asynchronously the urb.
For UVC, the function uvc_ctrl_status_event_async() takes care of control changes asynchronously.
If the code is executed in the following order:
CPU 0 CPU 1
===== =====uvc_status_complete()
uvc_status_stop()uvc_ctrl_status_event_work()
uvc_status_start() -> FAIL
Then uvc_status_start will keep failing and this error will be shown:
<4>[ 5.540139] URB 0000000000000000 submitted while active
drivers/usb/core/urb.c:378 usb_submit_urb+0x4c3/0x528
Let's improve the current situation, by not re-submiting the urb if we are stopping the status event. Also process the queued work (if any) during stop.
CPU 0 CPU 1
===== =====uvc_status_complete()
uvc_status_stop() uvc_status_start()uvc_ctrl_status_event_work() -> FAIL
Hopefully, with the usb layer protection this should be enough to cover all the cases.
--- drivers/media/usb/uvc/uvc_ctrl.c | 5 +++++ drivers/media/usb/uvc/uvc_status.c | 37 +++++++++++++++++++++++++++++++++++++ drivers/media/usb/uvc/uvcvideo.h | 1 + 3 files changed, 43 insertions(+)
drivers/media/usb/uvc/uvc_ctrl.c +5 -0
@@ -6,6 +6,7 @@* Laurent Pinchart ([email protected]) */ +#include <asm/barrier.h> #include <linux/kernel.h> #include <linux/list.h> #include <linux/module.h>
@@ -1318,6 +1319,10 @@ static void uvc_ctrl_status_event_work(suvc_ctrl_status_event (w->chain, w->ctrl, w->data); +/* The barrier is needed to synchronize with uvc_status_stop(). */ +if (smp_load_acquire (&dev->flush_status)) +return ; +/* Resubmit the URB. */ w->urb->interval = dev->int_ep->desc.bInterval; ret =usb_submit_urb (w->urb,GFP_KERNEL );
drivers/media/usb/uvc/uvc_status.c +37 -0
@@ -6,6 +6,7 @@* Laurent Pinchart ([email protected]) */ +#include <asm/barrier.h> #include <linux/kernel.h> #include <linux/input.h> #include <linux/slab.h>
@@ -310,5 +311,41 @@ int uvc_status_start(struct uvc_device *void uvc_status_stop (struct uvc_device *dev) { +struct uvc_ctrl_work *w = &dev->async_ctrl; + +/* +* Prevent the asynchronous control handler from requeing the URB. The +* barrier is needed so the flush_status change is visible to other +* CPUs running the asynchronous handler before usb_kill_urb() is +* called below. +*/ +smp_store_release (&dev->flush_status, true); + +/* +* Cancel any pending asynchronous work. If any status event was queued, +* process it synchronously. +*/ +if (cancel_work_sync (&w->work)) +uvc_ctrl_status_event (w->chain, w->ctrl, w->data); + +/* Kill the urb. */ usb_kill_urb (dev->int_urb); + +/* +* The URB completion handler may have queued asynchronous work. This +* won't resubmit the URB as flush_status is set, but it needs to be +* cancelled before returning or it could then race with a future +* uvc_status_start() call. +*/ +if (cancel_work_sync (&w->work)) +uvc_ctrl_status_event (w->chain, w->ctrl, w->data); + +/* +* From this point, there are no events on the queue and the status URB +* is dead. No events will be queued until uvc_status_start() is called. +* The barrier is needed to make sure that flush_status is visible to +* uvc_ctrl_status_event_work() when uvc_status_start() will be called +* again. +*/ +smp_store_release (&dev->flush_status, false); }
drivers/media/usb/uvc/uvcvideo.h +1 -0
@@ -664,6 +664,7 @@ struct uvc_device {/* Status Interrupt Endpoint */ struct usb_host_endpoint *int_ep;struct urb *int_urb; +bool flush_status;u8 *status;struct input_dev *input;char input_phys[64 ];
Greg Kroah-Hartman
maintainerPATCH 356/357 s390/dasd: add missing discipline function
In reply to Greg Kroah-HartmanFrom: Stefan Haberland <[email protected]>
commit c0c8a8397fa8a74d04915f4d3d28cb4a5d401427 upstream.
Fix crash with illegal operation exception in dasd_device_tasklet. Commit b72949328869 ("s390/dasd: Prepare for additional path event handling") renamed the verify_path function for ECKD but not for FBA and DIAG. This leads to a panic when the path verification function is called for a FBA or DIAG device.
Fix by defining a wrapper function for dasd_generic_verify_path().
--- drivers/s390/block/dasd_diag.c | 8 +++++++- drivers/s390/block/dasd_fba.c | 8 +++++++- drivers/s390/block/dasd_int.h | 1 - 3 files changed, 14 insertions(+), 3 deletions(-)
drivers/s390/block/dasd_diag.c +7 -1
@@ -644,12 +644,18 @@ static void dasd_diag_setup_blk_queue(stblk_queue_segment_boundary (q,PAGE_SIZE -1 ); } +static int dasd_diag_pe_handler (struct dasd_device *device, +__u8 tbvpm,__u8 fcsecpm) +{ +return dasd_generic_verify_path (device, tbvpm); +} +static struct dasd_discipline dasd_diag_discipline = { .owner =THIS_MODULE , .name ="DIAG" , .ebcname ="DIAG" , .check_device = dasd_diag_check_device, - .verify_path = dasd_generic_verify_path, + .pe_handler = dasd_diag_pe_handler, .fill_geometry = dasd_diag_fill_geometry, .setup_blk_queue = dasd_diag_setup_blk_queue, .start_IO = dasd_start_diag,
drivers/s390/block/dasd_fba.c +7 -1
@@ -803,13 +803,19 @@ static void dasd_fba_setup_blk_queue(strblk_queue_flag_set (QUEUE_FLAG_DISCARD , q); } +static int dasd_fba_pe_handler (struct dasd_device *device, +__u8 tbvpm,__u8 fcsecpm) +{ +return dasd_generic_verify_path (device, tbvpm); +} +static struct dasd_discipline dasd_fba_discipline = { .owner =THIS_MODULE , .name ="FBA " , .ebcname ="FBA " , .check_device = dasd_fba_check_characteristics, .do_analysis = dasd_fba_do_analysis, - .verify_path = dasd_generic_verify_path, + .pe_handler = dasd_fba_pe_handler, .setup_blk_queue = dasd_fba_setup_blk_queue, .fill_geometry = dasd_fba_fill_geometry, .start_IO = dasd_start_IO,
drivers/s390/block/dasd_int.h +0 -1
@@ -298,7 +298,6 @@ struct dasd_discipline {* e.g. verify that new path is compatible with the current * configuration. */ -int (*verify_path)(struct dasd_device *,__u8 );int (*pe_handler)(struct dasd_device *,__u8 );/*
Greg Kroah-Hartman
maintainerPATCH 357/357 dt-bindings: rtc: sun6i-a31-rtc: Loosen the requirements on the clocks
In reply to Greg Kroah-HartmanFrom: Maxime Ripard <[email protected]>
commit 48b47749e334b3891f33b9425b470a3c92be8dae upstream.
The commit ec98a87509f4 ("rtc: sun6i: Make external 32k oscillator optional") loosened the requirement of the clocks property, making it optional. However, the binding still required it to be present.
--- Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 1 - 1 file changed, 1 deletion(-)
Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml +0 -1
@@ -128,7 +128,6 @@ required: - compatible - reg - interrupts - - clocks - clock-output-names additionalProperties: false
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.235 release. There are 357 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 Sun, 12 Mar 2023 13:36:38 +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.4.235-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.4.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v5.4:
10 builds: 10 pass, 0 fail
26 boots: 26 pass, 0 fail
59 tests: 59 pass, 0 failLinux version: 5.4.235-rc1-g90cb39c89956
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-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.4.235 release. There are 357 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 Sun, 12 Mar 2023 13:36:38 +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.4.235-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.4.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 5.4.235 release. There are 357 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 Sun, 12 Mar 2023 13:36:38 +0000. Anything received after that time might be too late.
Build results:
total: 159 pass: 157 fail: 2 Failed builds: s390:defconfig s390:allmodconfig Qemu test results: total: 455 pass: 450 fail: 5
Failed tests:
s390:defconfig:nolocktests:smp2:net,default:initrd s390:defconfig:nolocktests:smp2:virtio-blk-ccw:net,virtio-net-pci:rootfs s390:defconfig:nolocktests:smp2:scsi[virtio-ccw]:net,default:rootfs s390:defconfig:nolocktests:virtio-pci:net,virtio-net-pci:rootfs s390:defconfig:nolocktests:scsi[virtio-pci]:net,default:rootfs
Failures as already reported.
Guenter
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.235 release. There are 357 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 Sun, 12 Mar 2023 13:36:38 +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.4.235-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.4.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
As others reported, s390 build regressions are noticed.
* s390, build failures
- gcc-12-defconfig
- gcc-8-defconfig-fe40093d
## Build
* kernel: 5.4.234-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.4.y
* git commit: 71be0366b84f5ed2ce06bcc6feddf31053a41c73
* git describe: v5.4.233-14-g71be0366b84f
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.4.y/build/v5.4.233-14-g71be0366b84f
## Test Regressions (compared to v5.4.233)
## Metric Regressions (compared to v5.4.233)
## Test Fixes (compared to v5.4.233)
## Metric Fixes (compared to v5.4.233)
## Test result summary
total: 124659, pass: 103137, fail: 3281, skip: 17853, xfail: 388
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 144 total, 143 passed, 1 failed
* arm64: 44 total, 40 passed, 4 failed
* i386: 26 total, 20 passed, 6 failed
* mips: 27 total, 27 passed, 0 failed
* parisc: 6 total, 6 passed, 0 failed
* powerpc: 30 total, 30 passed, 0 failed
* riscv: 12 total, 10 passed, 2 failed
* s390: 6 total, 6 passed, 0 failed
* sh: 12 total, 12 passed, 0 failed
* sparc: 6 total, 6 passed, 0 failed
* x86_64: 37 total, 35 passed, 2 failed
## Test suites summary
* boot
* fwts
* igt-gpu-tools
* kselftest-android
* kselftest-arm64
* 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-ftrace
* 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-net-mptcp
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* 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-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
* perf
* 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 5.4.235 release. There are 357 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 Sun, 12 Mar 2023 13:36:38 +0000. Anything received after that time might be too late.
Build test (gcc version 11.3.1 20230210):
mips: 65 configs -> 1 failure
arm: 106 configs -> no failure
arm64: 2 configs -> no failurex86_64: 4 configs -> no failure
alpha allmodconfig -> no failure
powerpc allmodconfig -> no failure
riscv allmodconfig -> no failure
s390 allmodconfig -> failed
xtensa allmodconfig -> no failure
Note:
mips build failed with the error:
arch/mips/lasat/picvue_proc.c:42:44: error: expected ')' before '&' token
42 | static DECLARE_TASKLET(pvc_display_tasklet, &pvc_display, 0);
| ^~
| )
arch/mips/lasat/picvue_proc.c: In function 'pvc_line_proc_write':
arch/mips/lasat/picvue_proc.c:87:27: error: 'pvc_display_tasklet' undeclared (first use in this function)
87 | tasklet_schedule(&pvc_display_tasklet);
| ^~~~~~~~~~~~~~~~~~~arch/mips/lasat/picvue_proc.c:87:27: note: each undeclared identifier is reported only once for each function it appears in At top level:arch/mips/lasat/picvue_proc.c:33:13: error: 'pvc_display' defined but not used [-Werror=unused-function]
33 | static void pvc_display(unsigned long data)
| ^~~~~~~~~~~
s390 build failed with:
drivers/s390/block/dasd_diag.c:658:23: error: initialization of 'int (*)(struct dasd_device *, __u8)' {aka 'int (*)(struct dasd_device *, unsigned char)'} from incompatible pointer type 'int (*)(struct dasd_device *, __u8, __u8)' {aka 'int (*)(struct dasd_device *, unsigned char, unsigned char)'} [-Werror=incompatible-pointer-types]
658 | .pe_handler = dasd_diag_pe_handler,
| ^~~~~~~~~~~~~~~~~~~~
drivers/s390/block/dasd_diag.c:658:23: note: (near initialization for 'dasd_diag_discipline.pe_handler')
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/3081
Signature · 2 lines
Regards Sudip
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.4.235 release. There are 357 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 Sun, 12 Mar 2023 13:36:38 +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.4.235-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.4.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