5.10.201-rc1 review
Subsystems (5)
Greg Kroah-Hartman
maintainerPATCH 149/191 rtc: pcf85363: fix wrong mask/val parameters in regmap_update_bits call
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Javier Carrasco <[email protected]>
[ Upstream commit 2be36c09b6b07306be33519e1aa70d2e2a2161bb ]
The current implementation passes PIN_IO_INTA_OUT (2) as a mask and PIN_IO_INTAPM (GENMASK(1, 0)) as a value.
Swap the variables to assign mask and value the right way.
This error was first introduced with the alarm support. For better or worse it worked as expected because 0x02 was applied as a mask to 0x03, resulting 0x02 anyway. This will of course not work for any other value.
--- drivers/rtc/rtc-pcf85363.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/rtc/rtc-pcf85363.c +1 -1
@@ -407,7 +407,7 @@ static int pcf85363_probe(struct i2c_client *client,if (client->irq >0 ) {regmap_write (pcf85363->regmap,CTRL_FLAGS ,0 );regmap_update_bits (pcf85363->regmap,CTRL_PIN_IO , -PIN_IO_INTA_OUT ,PIN_IO_INTAPM ); +PIN_IO_INTAPM ,PIN_IO_INTA_OUT ); ret = devm_request_threaded_irq(&client->dev, client->irq, NULL, pcf85363_rtc_handle_irq, IRQF_TRIGGER_LOW | IRQF_ONESHOT,
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 150/191 pcmcia: cs: fix possible hung task and memory leak pccardd()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yang Yingliang <[email protected]>
[ Upstream commit e3ea1b4847e49234e691c0d66bf030bd65bb7f2b ]
If device_register() returns error in pccardd(), it leads two issues:
1. The socket_released has never been completed, it will block pcmcia_unregister_socket(), because of waiting for completion of socket_released.
2. The device name allocated by dev_set_name() is leaked.
Fix this two issues by calling put_device() when device_register() fails. socket_released can be completed in pcmcia_release_socket(), the name can be freed in kobject_cleanup().
--- drivers/pcmcia/cs.c | 1 + 1 file changed, 1 insertion(+)
drivers/pcmcia/cs.c +1 -0
@@ -605,6 +605,7 @@ static int pccardd(void *__skt)dev_warn (&skt->dev,"PCMCIA: unable to register socket\n" ); skt->thread =NULL ;complete (&skt->thread_done); +put_device (&skt->dev);return 0 ; } ret =pccard_sysfs_add_socket (&skt->dev);
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 151/191 pcmcia: ds: fix refcount leak in pcmcia_device_add()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yang Yingliang <[email protected]>
[ Upstream commit 402ab979b29126068e0b596b641422ff7490214c ]
As the comment of device_register() says, it should use put_device() to give up the reference in the error path. Then, insofar resources will be freed in pcmcia_release_dev(), the error path is no longer needed. In particular, this means that the (previously missing) dropping of the reference to &p_dev->function_config->ref is now handled by pcmcia_release_dev().
--- drivers/pcmcia/ds.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)
drivers/pcmcia/ds.c +8 -2
@@ -578,8 +578,14 @@ static struct pcmcia_device *pcmcia_device_add(struct pcmcia_socket *s,pcmcia_device_query (p_dev); -if (device_register (&p_dev->dev)) - goto err_unreg; +if (device_register (&p_dev->dev)) { +mutex_lock (&s->ops_mutex); +list_del (&p_dev->socket_device_list); + s->device_count--; +mutex_unlock (&s->ops_mutex); +put_device (&p_dev->dev); +return NULL ; + }return p_dev;
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 152/191 pcmcia: ds: fix possible name leak in error path in pcmcia_device_add()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yang Yingliang <[email protected]>
[ Upstream commit 99e1241049a92dd3e9a90a0f91e32ce390133278 ]
Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically. Therefore, it needs to be freed, which is done by the driver core for us once all references to the device are gone. Therefore, move the dev_set_name() call immediately before the call device_register(), which either succeeds (then the freeing will be done upon subsequent remvoal), or puts the reference in the error call. Also, it is not unusual that the return value of dev_set_name is not checked.
--- drivers/pcmcia/ds.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
drivers/pcmcia/ds.c +1 -3
@@ -518,9 +518,6 @@ static struct pcmcia_device *pcmcia_device_add(struct pcmcia_socket *s,/* by default don't allow DMA */ p_dev->dma_mask =0 ; p_dev->dev.dma_mask = &p_dev->dma_mask; -dev_set_name (&p_dev->dev,"%d.%d" , p_dev->socket->sock, p_dev->device_no); -if (!dev_name (&p_dev->dev)) - goto err_free; p_dev->devname =kasprintf (GFP_KERNEL ,"pcmcia%s" ,dev_name (&p_dev->dev));if (!p_dev->devname) goto err_free;
@@ -578,6 +575,7 @@ static struct pcmcia_device *pcmcia_device_add(struct pcmcia_socket *s,pcmcia_device_query (p_dev); +dev_set_name (&p_dev->dev,"%d.%d" , p_dev->socket->sock, p_dev->device_no);if (device_register (&p_dev->dev)) {mutex_lock (&s->ops_mutex);list_del (&p_dev->socket_device_list);
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 153/191 media: i2c: max9286: Fix some redundant of_node_put() calls
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe JAILLET <[email protected]>
[ Upstream commit 0822315e46b400f611cba1193456ee6a5dc3e41d ]
This is odd to have a of_node_put() just after a for_each_child_of_node() or a for_each_endpoint_of_node() loop. It should already be called during the last iteration.
Remove these calls.
--- drivers/media/i2c/max9286.c | 2 -- 1 file changed, 2 deletions(-)
drivers/media/i2c/max9286.c +0 -2
@@ -1143,7 +1143,6 @@ static int max9286_parse_dt(struct max9286_priv *priv) i2c_mux_mask |=BIT (id); } -of_node_put (node);of_node_put (i2c_mux);/* Parse the endpoints */
@@ -1207,7 +1206,6 @@ static int max9286_parse_dt(struct max9286_priv *priv) priv->source_mask |=BIT (ep.port); priv->nsources++; } -of_node_put (node); priv->route_mask = priv->source_mask;
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 154/191 media: bttv: fix use after free error due to btv->timeout timer
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zheng Wang <[email protected]>
[ Upstream commit bd5b50b329e850d467e7bcc07b2b6bde3752fbda ]
There may be some a race condition between timer function bttv_irq_timeout and bttv_remove. The timer is setup in probe and there is no timer_delete operation in remove function. When it hit kfree btv, the function might still be invoked, which will cause use after free bug.
This bug is found by static analysis, it may be false positive.
Fix it by adding del_timer_sync invoking to the remove function.
cpu0 cpu1
bttv_probe
->timer_setup
->bttv_set_dma
->mod_timer;
bttv_remove
->kfree(btv);
->bttv_irq_timeout
->USE btv--- drivers/media/pci/bt8xx/bttv-driver.c | 1 + 1 file changed, 1 insertion(+)
drivers/media/pci/bt8xx/bttv-driver.c +1 -0
@@ -4258,6 +4258,7 @@ static void bttv_remove(struct pci_dev *pci_dev)/* free resources */ free_irq (btv->c.pci->irq,btv); +del_timer_sync (&btv->timeout);iounmap (btv->bt848_mmio);release_mem_region (pci_resource_start (btv->c.pci,0 ),pci_resource_len (btv->c.pci,0 ));
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 155/191 media: s3c-camif: Avoid inappropriate kfree()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Katya Orlova <[email protected]>
[ Upstream commit 61334819aca018c3416ee6c330a08a49c1524fc3 ]
s3c_camif_register_video_node() works with video_device structure stored as a field of camif_vp, so it should not be kfreed.
But there is video_device_release() on error path that do it.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
--- drivers/media/platform/s3c-camif/camif-capture.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-)
drivers/media/platform/s3c-camif/camif-capture.c +2 -4
@@ -1132,12 +1132,12 @@ int s3c_camif_register_video_node(struct camif_dev *camif, int idx) ret =vb2_queue_init (q);if (ret) - goto err_vd_rel; +return ret; vp->pad.flags =MEDIA_PAD_FL_SINK ; ret =media_entity_pads_init (&vfd->entity,1 , &vp->pad);if (ret) - goto err_vd_rel; +return ret;video_set_drvdata (vfd, vp);
@@ -1170,8 +1170,6 @@ int s3c_camif_register_video_node(struct camif_dev *camif, int idx)v4l2_ctrl_handler_free (&vp->ctrl_handler); err_me_cleanup:media_entity_cleanup (&vfd->entity); -err_vd_rel: -video_device_release (vfd);return ret; }
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 156/191 media: vidtv: psi: Add check for kstrdup
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiasheng Jiang <[email protected]>
[ Upstream commit 76a2c5df6ca8bd8ada45e953b8c72b746f42918d ]
Add check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer dereference.
--- drivers/media/test-drivers/vidtv/vidtv_psi.c | 45 +++++++++++++++++--- 1 file changed, 40 insertions(+), 5 deletions(-)
drivers/media/test-drivers/vidtv/vidtv_psi.c +40 -5
@@ -308,16 +308,29 @@ struct vidtv_psi_desc_service *vidtv_psi_service_desc_init(struct vidtv_psi_desc desc->service_name_len = service_name_len; -if (service_name && service_name_len) +if (service_name && service_name_len) { desc->service_name =kstrdup (service_name,GFP_KERNEL ); +if (!desc->service_name) + goto free_desc; + } desc->provider_name_len = provider_name_len; -if (provider_name && provider_name_len) +if (provider_name && provider_name_len) { desc->provider_name =kstrdup (provider_name,GFP_KERNEL ); +if (!desc->provider_name) + goto free_desc_service_name; + }vidtv_psi_desc_chain (head, (struct vidtv_psi_desc *)desc);return desc; + +free_desc_service_name: +if (service_name && service_name_len) +kfree (desc->service_name); +free_desc: +kfree (desc); +return NULL ; }struct vidtv_psi_desc_registration
@@ -362,8 +375,13 @@ struct vidtv_psi_desc_network_name desc->length = network_name_len; -if (network_name && network_name_len) +if (network_name && network_name_len) { desc->network_name =kstrdup (network_name,GFP_KERNEL ); +if (!desc->network_name) { +kfree (desc); +return NULL ; + } + }vidtv_psi_desc_chain (head, (struct vidtv_psi_desc *)desc);return desc;
@@ -449,15 +467,32 @@ struct vidtv_psi_desc_short_event iso_language_code ="eng" ; desc->iso_language_code =kstrdup (iso_language_code,GFP_KERNEL ); +if (!desc->iso_language_code) + goto free_desc; -if (event_name && event_name_len) +if (event_name && event_name_len) { desc->event_name =kstrdup (event_name,GFP_KERNEL ); +if (!desc->event_name) + goto free_desc_language_code; + } -if (text && text_len) +if (text && text_len) { desc->text =kstrdup (text,GFP_KERNEL ); +if (!desc->text) + goto free_desc_event_name; + }vidtv_psi_desc_chain (head, (struct vidtv_psi_desc *)desc);return desc; + +free_desc_event_name: +if (event_name && event_name_len) +kfree (desc->event_name); +free_desc_language_code: +kfree (desc->iso_language_code); +free_desc: +kfree (desc); +return NULL ; }struct vidtv_psi_desc *vidtv_psi_desc_clone (struct vidtv_psi_desc *desc)
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 157/191 media: vidtv: mux: Add check and kfree for kstrdup
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiasheng Jiang <[email protected]>
[ Upstream commit 1fd6eb12642e0c32692924ff359c07de4b781d78 ]
Add check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer dereference. Moreover, use kfree() in the later error handling in order to avoid memory leak.
--- drivers/media/test-drivers/vidtv/vidtv_mux.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/media/test-drivers/vidtv/vidtv_mux.c +6 -1
@@ -504,13 +504,16 @@ struct vidtv_mux *vidtv_mux_init(struct dvb_frontend *fe, m->priv = args->priv; m->network_id = args->network_id; m->network_name =kstrdup (args->network_name,GFP_KERNEL ); +if (!m->network_name) + goto free_mux_buf; + m->timing.current_jiffies =get_jiffies_64 ();if (args->channels) m->channels = args->channels;else if (vidtv_channels_init (m) <0 ) - goto free_mux_buf; + goto free_mux_network_name;/* will alloc data for pmt_sections after initializing pat */ if (vidtv_channel_si_init (m) <0 )
@@ -527,6 +530,8 @@ struct vidtv_mux *vidtv_mux_init(struct dvb_frontend *fe,vidtv_channel_si_destroy (m); free_channels:vidtv_channels_destroy (m); +free_mux_network_name: +kfree (m->network_name); free_mux_buf:vfree (m->mux_buf); free_mux:
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 158/191 media: cedrus: Fix clock/reset sequence
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jernej Skrabec <[email protected]>
[ Upstream commit 36fe515c1a3cd5eac148e8a591a82108d92d5522 ]
According to H6 user manual, resets should always be de-asserted before clocks are enabled. This is also consistent with vendor driver.
--- .../staging/media/sunxi/cedrus/cedrus_hw.c | 24 +++++++++---------- 1 file changed, 12 insertions(+), 12 deletions(-)
drivers/staging/media/sunxi/cedrus/cedrus_hw.c +12 -12
@@ -145,12 +145,12 @@ int cedrus_hw_suspend(struct device *device) {struct cedrus_dev *dev =dev_get_drvdata (device); -reset_control_assert (dev->rstc); -clk_disable_unprepare (dev->ram_clk);clk_disable_unprepare (dev->mod_clk);clk_disable_unprepare (dev->ahb_clk); +reset_control_assert (dev->rstc); +return 0 ; }
@@ -159,11 +159,18 @@ int cedrus_hw_resume(struct device *device)struct cedrus_dev *dev =dev_get_drvdata (device);int ret; + ret =reset_control_reset (dev->rstc); +if (ret) { +dev_err (dev->dev,"Failed to apply reset\n" ); + +return ret; + } + ret =clk_prepare_enable (dev->ahb_clk);if (ret) {dev_err (dev->dev,"Failed to enable AHB clock\n" ); -return ret; + goto err_rst; } ret =clk_prepare_enable (dev->mod_clk);
@@ -180,21 +187,14 @@ int cedrus_hw_resume(struct device *device) goto err_mod_clk; } - ret =reset_control_reset (dev->rstc); -if (ret) { -dev_err (dev->dev,"Failed to apply reset\n" ); - - goto err_ram_clk; - } -return 0 ; -err_ram_clk: -clk_disable_unprepare (dev->ram_clk); err_mod_clk:clk_disable_unprepare (dev->mod_clk); err_ahb_clk:clk_disable_unprepare (dev->ahb_clk); +err_rst: +reset_control_assert (dev->rstc);return ret; }
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 159/191 media: dvb-usb-v2: af9035: fix missing unlock
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans Verkuil <[email protected]>
[ Upstream commit f31b2cb85f0ee165d78e1c43f6d69f82cc3b2145 ]
Instead of returning an error, goto the mutex unlock at the end of the function.
Fixes smatch warning:
drivers/media/usb/dvb-usb-v2/af9035.c:467 af9035_i2c_master_xfer() warn: inconsistent returns '&d->i2c_mutex'.
Locked on : 326,387
Unlocked on: 465,467
--- drivers/media/usb/dvb-usb-v2/af9035.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-)
drivers/media/usb/dvb-usb-v2/af9035.c +9 -4
@@ -322,8 +322,10 @@ static int af9035_i2c_master_xfer(struct i2c_adapter *adap, ret = -EOPNOTSUPP ; }else if ((msg[0 ].addr == state->af9033_i2c_addr[0 ]) || (msg[0 ].addr == state->af9033_i2c_addr[1 ])) { -if (msg[0 ].len <3 || msg[1 ].len <1 ) -return -EOPNOTSUPP ; +if (msg[0 ].len <3 || msg[1 ].len <1 ) { + ret = -EOPNOTSUPP ; + goto unlock; + }/* demod access via firmware interface */ reg = msg[0 ].buf[0 ] <<16 | msg[0 ].buf[1 ] <<8 | msg[0 ].buf[2 ];
@@ -383,8 +385,10 @@ static int af9035_i2c_master_xfer(struct i2c_adapter *adap, ret = -EOPNOTSUPP ; }else if ((msg[0 ].addr == state->af9033_i2c_addr[0 ]) || (msg[0 ].addr == state->af9033_i2c_addr[1 ])) { -if (msg[0 ].len <3 ) -return -EOPNOTSUPP ; +if (msg[0 ].len <3 ) { + ret = -EOPNOTSUPP ; + goto unlock; + }/* demod access via firmware interface */ reg = msg[0 ].buf[0 ] <<16 | msg[0 ].buf[1 ] <<8 | msg[0 ].buf[2 ];
@@ -459,6 +463,7 @@ static int af9035_i2c_master_xfer(struct i2c_adapter *adap, ret = -EOPNOTSUPP ; } +unlock:mutex_unlock (&d->i2c_mutex);if (ret <0 )
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 160/191 regmap: prevent noinc writes from clobbering cache
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ben Wolsieffer <[email protected]>
[ Upstream commit 984a4afdc87a1fc226fd657b1cd8255c13d3fc1a ]
Currently, noinc writes are cached as if they were standard incrementing writes, overwriting unrelated register values in the cache. Instead, we want to cache the last value written to the register, as is done in the accelerated noinc handler (regmap_noinc_readwrite).
--- drivers/base/regmap/regmap.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-)
drivers/base/regmap/regmap.c +9 -7
@@ -1643,17 +1643,19 @@ static int _regmap_raw_write_impl(struct regmap *map, unsigned int reg, }if (!map->cache_bypass && map->format.parse_val) { -unsigned int ival; +unsigned int ival, offset;int val_bytes = map->format.val_bytes; -for (i =0 ; i < val_len / val_bytes; i++) { - ival = map->format.parse_val (val + (i * val_bytes)); - ret =regcache_write (map, - reg +regmap_get_offset (map, i), - ival); + +/* Cache the last written value for noinc writes */ + i = noinc ? val_len - val_bytes :0 ; +for (; i < val_len; i += val_bytes) { + ival = map->format.parse_val (val + i); + offset = noinc ?0 :regmap_get_offset (map, i / val_bytes); + ret =regcache_write (map, reg + offset, ival);if (ret) {dev_err (map->dev,"Error in caching of register: %x ret: %d\n" , - reg +regmap_get_offset (map, i), ret); + reg + offset, ret);return ret; } }
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 161/191 pwm: sti: Avoid conditional gotos
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thierry Reding <[email protected]>
[ Upstream commit fd3ae02bb66f091e55f363d32eca7b4039977bf5 ]
Using gotos for conditional code complicates this code significantly. Convert the code to simple conditional blocks to increase readability.
Stable-dep-of: 2d6812b41e0d ("pwm: sti: Reduce number of allocations and drop usage of chip_data")
--- drivers/pwm/pwm-sti.c | 48 ++++++++++++++++++++----------------------- 1 file changed, 22 insertions(+), 26 deletions(-)
drivers/pwm/pwm-sti.c +22 -26
@@ -593,38 +593,34 @@ static int sti_pwm_probe(struct platform_device *pdev)if (ret)return ret; -if (!cdata->pwm_num_devs) - goto skip_pwm; - - pc->pwm_clk =of_clk_get_by_name (dev->of_node,"pwm" ); -if (IS_ERR (pc->pwm_clk)) { -dev_err (dev,"failed to get PWM clock\n" ); -return PTR_ERR (pc->pwm_clk); - } +if (cdata->pwm_num_devs) { + pc->pwm_clk =of_clk_get_by_name (dev->of_node,"pwm" ); +if (IS_ERR (pc->pwm_clk)) { +dev_err (dev,"failed to get PWM clock\n" ); +return PTR_ERR (pc->pwm_clk); + } - ret =clk_prepare (pc->pwm_clk); -if (ret) { -dev_err (dev,"failed to prepare clock\n" ); -return ret; + ret =clk_prepare (pc->pwm_clk); +if (ret) { +dev_err (dev,"failed to prepare clock\n" ); +return ret; + } } -skip_pwm: -if (!cdata->cpt_num_devs) - goto skip_cpt; - - pc->cpt_clk =of_clk_get_by_name (dev->of_node,"capture" ); -if (IS_ERR (pc->cpt_clk)) { -dev_err (dev,"failed to get PWM capture clock\n" ); -return PTR_ERR (pc->cpt_clk); - } +if (cdata->cpt_num_devs) { + pc->cpt_clk =of_clk_get_by_name (dev->of_node,"capture" ); +if (IS_ERR (pc->cpt_clk)) { +dev_err (dev,"failed to get PWM capture clock\n" ); +return PTR_ERR (pc->cpt_clk); + } - ret =clk_prepare (pc->cpt_clk); -if (ret) { -dev_err (dev,"failed to prepare clock\n" ); -return ret; + ret =clk_prepare (pc->cpt_clk); +if (ret) { +dev_err (dev,"failed to prepare clock\n" ); +return ret; + } } -skip_cpt: pc->chip.dev = dev; pc->chip.ops = &sti_pwm_ops; pc->chip.base =-1 ;
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 162/191 pwm: sti: Reduce number of allocations and drop usage of chip_data
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Uwe Kleine-König <[email protected]>
[ Upstream commit 2d6812b41e0d832919d72c72ebddf361df53ba1b ]
Instead of using one allocation per capture channel, use a single one. Also store it in driver data instead of chip data.
This has several advantages:
- driver data isn't cleared when pwm_put() is called
- Reduces memory fragmentation
Also register the pwm chip only after the per capture channel data is initialized as the capture callback relies on this initialization and it might be called even before pwmchip_add() returns.
It would be still better to have struct sti_pwm_compat_data and the per-channel data struct sti_cpt_ddata in a single memory chunk, but that's not easily possible because the number of capture channels isn't known yet when the driver data struct is allocated.
--- drivers/pwm/pwm-sti.c | 29 ++++++++++++++--------------- 1 file changed, 14 insertions(+), 15 deletions(-)
drivers/pwm/pwm-sti.c +14 -15
@@ -79,6 +79,7 @@ struct sti_pwm_compat_data {unsigned int cpt_num_devs;unsigned int max_pwm_cnt;unsigned int max_prescale; +struct sti_cpt_ddata *ddata; };struct sti_pwm_chip {
@@ -314,7 +315,7 @@ static int sti_pwm_capture(struct pwm_chip *chip, struct pwm_device *pwm, {struct sti_pwm_chip *pc =to_sti_pwmchip (chip);struct sti_pwm_compat_data *cdata = pc->cdata; -struct sti_cpt_ddata *ddata =pwm_get_chip_data (pwm); +struct sti_cpt_ddata *ddata = &cdata->ddata[pwm->hwpwm];struct device *dev = pc->dev;unsigned int effective_ticks;unsigned long long high, low;
@@ -417,7 +418,7 @@ static irqreturn_t sti_pwm_interrupt(int irq, void *data)while (cpt_int_stat) { devicenum =ffs (cpt_int_stat) -1 ; - ddata =pwm_get_chip_data (&pc->chip.pwms[devicenum]); + ddata = &pc->cdata->ddata[devicenum];/* * Capture input:
@@ -619,6 +620,10 @@ static int sti_pwm_probe(struct platform_device *pdev)dev_err (dev,"failed to prepare clock\n" );return ret; } + + cdata->ddata =devm_kzalloc (dev, cdata->cpt_num_devs *sizeof (*cdata->ddata),GFP_KERNEL ); +if (!cdata->ddata) +return -ENOMEM ; } pc->chip.dev = dev;
@@ -626,24 +631,18 @@ static int sti_pwm_probe(struct platform_device *pdev) pc->chip.base =-1 ; pc->chip.npwm = pc->cdata->pwm_num_devs; - ret =pwmchip_add (&pc->chip); -if (ret <0 ) { -clk_unprepare (pc->pwm_clk); -clk_unprepare (pc->cpt_clk); -return ret; - } -for (i =0 ; i < cdata->cpt_num_devs; i++) { -struct sti_cpt_ddata *ddata; - - ddata =devm_kzalloc (dev,sizeof (*ddata),GFP_KERNEL ); -if (!ddata) -return -ENOMEM ; +struct sti_cpt_ddata *ddata = &cdata->ddata[i];init_waitqueue_head (&ddata->wait);mutex_init (&ddata->lock); + } -pwm_set_chip_data (&pc->chip.pwms[i], ddata); + ret =pwmchip_add (&pc->chip); +if (ret <0 ) { +clk_unprepare (pc->pwm_clk); +clk_unprepare (pc->cpt_clk); +return ret; }platform_set_drvdata (pdev, pc);
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 163/191 pwm: brcmstb: Utilize appropriate clock APIs in suspend/resume
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Florian Fainelli <[email protected]>
[ Upstream commit e9bc4411548aaa738905d37851a0146c16b3bb21 ]
The suspend/resume functions currently utilize clk_disable()/clk_enable() respectively which may be no-ops with certain clock providers such as SCMI. Fix this to use clk_disable_unprepare() and clk_prepare_enable() respectively as we should.
--- drivers/pwm/pwm-brcmstb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/pwm/pwm-brcmstb.c +2 -2
@@ -298,7 +298,7 @@ static int brcmstb_pwm_suspend(struct device *dev) {struct brcmstb_pwm *p =dev_get_drvdata (dev); -clk_disable (p->clk); +clk_disable_unprepare (p->clk);return 0 ; }
@@ -307,7 +307,7 @@ static int brcmstb_pwm_resume(struct device *dev) {struct brcmstb_pwm *p =dev_get_drvdata (dev); -clk_enable (p->clk); +clk_prepare_enable (p->clk);return 0 ; }
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 164/191 Input: synaptics-rmi4 - fix use after free in rmi_unregister_function()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
[ Upstream commit eb988e46da2e4eae89f5337e047ce372fe33d5b1 ]
The put_device() calls rmi_release_function() which frees "fn" so the dereference on the next line "fn->num_of_irqs" is a use after free. Move the put_device() to the end to fix this.
--- drivers/input/rmi4/rmi_bus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/input/rmi4/rmi_bus.c +1 -1
@@ -276,11 +276,11 @@ void rmi_unregister_function(struct rmi_function *fn)device_del (&fn->dev);of_node_put (fn->dev.of_node); -put_device (&fn->dev);for (i =0 ; i < fn->num_of_irqs; i++)irq_dispose_mapping (fn->irq[i]); +put_device (&fn->dev); }/**
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 165/191 llc: verify mac len before reading mac header
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Willem de Bruijn <[email protected]>
[ Upstream commit 7b3ba18703a63f6fd487183b9262b08e5632da1b ]
LLC reads the mac header with eth_hdr without verifying that the skb has an Ethernet header.
Syzbot was able to enter llc_rcv on a tun device. Tun can insert packets without mac len and with user configurable skb->protocol (passing a tun_pi header when not configuring IFF_NO_PI).
BUG: KMSAN: uninit-value in llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]
BUG: KMSAN: uninit-value in llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111
llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]
llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111
llc_rcv+0xc5d/0x14a0 net/llc/llc_input.c:218
__netif_receive_skb_one_core net/core/dev.c:5523 [inline]
__netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637
netif_receive_skb_internal net/core/dev.c:5723 [inline]
netif_receive_skb+0x58/0x660 net/core/dev.c:5782
tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555
tun_get_user+0x54c5/0x69c0 drivers/net/tun.c:2002Add a mac_len test before all three eth_hdr(skb) calls under net/llc.
There are further uses in include/net/llc_pdu.h. All these are protected by a test skb->protocol == ETH_P_802_2. Which does not protect against this tun scenario.
But the mac_len test added in this patch in llc_fixup_skb will indirectly protect those too. That is called from llc_rcv before any other LLC code.
It is tempting to just add a blanket mac_len check in llc_rcv, but not sure whether that could break valid LLC paths that do not assume an Ethernet header. 802.2 LLC may be used on top of non-802.3 protocols in principle. The below referenced commit shows that used to, on top of Token Ring.
At least one of the three eth_hdr uses goes back to before the start of git history. But the one that syzbot exercises is introduced in this commit. That commit is old enough (2008), that effectively all stable kernels should receive this.
--- net/llc/llc_input.c | 10 ++++++++-- net/llc/llc_s_ac.c | 3 +++ net/llc/llc_station.c | 3 +++ 3 files changed, 14 insertions(+), 2 deletions(-)
net/llc/llc_input.c +8 -2
@@ -127,8 +127,14 @@ static inline int llc_fixup_skb(struct sk_buff *skb) skb->transport_header += llc_len;skb_pull (skb, llc_len);if (skb->protocol ==htons (ETH_P_802_2 )) { -__be16 pdulen =eth_hdr (skb)->h_proto; -s32 data_size =ntohs (pdulen) - llc_len; +__be16 pdulen; +s32 data_size; + +if (skb->mac_len <ETH_HLEN ) +return 0 ; + + pdulen =eth_hdr (skb)->h_proto; + data_size =ntohs (pdulen) - llc_len;if (data_size <0 || !pskb_may_pull (skb, data_size))
net/llc/llc_s_ac.c +3 -0
@@ -153,6 +153,9 @@ int llc_sap_action_send_test_r(struct llc_sap *sap, struct sk_buff *skb)int rc =1 ;u32 data_size; +if (skb->mac_len <ETH_HLEN ) +return 1 ; +llc_pdu_decode_sa (skb, mac_da);llc_pdu_decode_da (skb, mac_sa);llc_pdu_decode_ssap (skb, &dsap);
net/llc/llc_station.c +3 -0
@@ -77,6 +77,9 @@ static int llc_station_ac_send_test_r(struct sk_buff *skb)u32 data_size;struct sk_buff *nskb; +if (skb->mac_len <ETH_HLEN ) + goto out; +/* The test request command is type U (llc_len = 3) */ data_size =ntohs (eth_hdr (skb)->h_proto) -3 ; nskb =llc_alloc_frame (NULL , skb->dev,LLC_PDU_TYPE_U , data_size);
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 166/191 hsr: Prevent use after free in prp_create_tagged_frame()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
[ Upstream commit 876f8ab52363f649bcc74072157dfd7adfbabc0d ]
The prp_fill_rct() function can fail. In that situation, it frees the skb and returns NULL. Meanwhile on the success path, it returns the original skb. So it's straight forward to fix bug by using the returned value.
--- net/hsr/hsr_forward.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
net/hsr/hsr_forward.c +1 -3
@@ -296,9 +296,7 @@ struct sk_buff *prp_create_tagged_frame(struct hsr_frame_info *frame, skb =skb_copy_expand (frame->skb_std,0 ,skb_tailroom (frame->skb_std) +HSR_HLEN ,GFP_ATOMIC ); -prp_fill_rct (skb, frame, port); - -return skb; +return prp_fill_rct (skb, frame, port); } static void hsr_deliver_master(struct sk_buff *skb, struct net_device *dev,
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 167/191 tipc: Change nla_policy for bearer-related names to NLA_NUL_STRING
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shigeru Yoshida <[email protected]>
[ Upstream commit 19b3f72a41a8751e26bffc093bb7e1cef29ad579 ]
syzbot reported the following uninit-value access issue [1]:
=====================================================
BUG: KMSAN: uninit-value in strlen lib/string.c:418 [inline] BUG: KMSAN: uninit-value in strstr+0xb8/0x2f0 lib/string.c:756 strlen lib/string.c:418 [inline] strstr+0xb8/0x2f0 lib/string.c:756 tipc_nl_node_reset_link_stats+0x3ea/0xb50 net/tipc/node.c:2595 genl_family_rcv_msg_doit net/netlink/genetlink.c:971 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1051 [inline] genl_rcv_msg+0x11ec/0x1290 net/netlink/genetlink.c:1066 netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2545 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1075 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline] netlink_unicast+0xf47/0x1250 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595 __sys_sendmsg net/socket.c:2624 [inline] __do_sys_sendmsg net/socket.c:2633 [inline] __se_sys_sendmsg net/socket.c:2631 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
Uninit was created at:
slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559 __alloc_skb+0x318/0x740 net/core/skbuff.c:650 alloc_skb include/linux/skbuff.h:1286 [inline] netlink_alloc_large_skb net/netlink/af_netlink.c:1214 [inline] netlink_sendmsg+0xb34/0x13d0 net/netlink/af_netlink.c:1885 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595 __sys_sendmsg net/socket.c:2624 [inline] __do_sys_sendmsg net/socket.c:2633 [inline] __se_sys_sendmsg net/socket.c:2631 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
TIPC bearer-related names including link names must be null-terminated strings. If a link name which is not null-terminated is passed through netlink, strstr() and similar functions can cause buffer overrun. This causes the above issue.
This patch changes the nla_policy for bearer-related names from NLA_STRING to NLA_NUL_STRING. This resolves the issue by ensuring that only null-terminated strings are accepted as bearer-related names.
syzbot reported similar uninit-value issue related to bearer names [2]. The root cause of this issue is that a non-null-terminated bearer name was passed. This patch also resolved this issue.
--- net/tipc/netlink.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
net/tipc/netlink.c +2 -2
@@ -88,7 +88,7 @@ const struct nla_policy tipc_nl_net_policy[TIPC_NLA_NET_MAX + 1] = {const struct nla_policy tipc_nl_link_policy[TIPC_NLA_LINK_MAX +1 ] = { [TIPC_NLA_LINK_UNSPEC ] = { .type =NLA_UNSPEC }, - [TIPC_NLA_LINK_NAME ] = { .type =NLA_STRING , + [TIPC_NLA_LINK_NAME ] = { .type =NLA_NUL_STRING , .len =TIPC_MAX_LINK_NAME }, [TIPC_NLA_LINK_MTU ] = { .type =NLA_U32 }, [TIPC_NLA_LINK_BROADCAST ] = { .type =NLA_FLAG },
@@ -125,7 +125,7 @@ const struct nla_policy tipc_nl_prop_policy[TIPC_NLA_PROP_MAX + 1] = {const struct nla_policy tipc_nl_bearer_policy[TIPC_NLA_BEARER_MAX +1 ] = { [TIPC_NLA_BEARER_UNSPEC ] = { .type =NLA_UNSPEC }, - [TIPC_NLA_BEARER_NAME ] = { .type =NLA_STRING , + [TIPC_NLA_BEARER_NAME ] = { .type =NLA_NUL_STRING , .len =TIPC_MAX_BEARER_NAME }, [TIPC_NLA_BEARER_PROP ] = { .type =NLA_NESTED }, [TIPC_NLA_BEARER_DOMAIN ] = { .type =NLA_U32 }
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 168/191 inet: shrink struct flowi_common
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 1726483b79a72e0150734d5367e4a0238bf8fcff ]
I am looking at syzbot reports triggering kernel stack overflows involving a cascade of ipvlan devices.
We can save 8 bytes in struct flowi_common.
This patch alone will not fix the issue, but is a start.
--- include/net/flow.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/net/flow.h +1 -1
@@ -39,8 +39,8 @@ struct flowi_common {#define FLOWI_FLAG_SKIP_NH_OIF 0x04__u32 flowic_secid;kuid_t flowic_uid; -struct flowi_tunnel flowic_tun_key;__u32 flowic_multipath_hash; +struct flowi_tunnel flowic_tun_key; };union flowi_uli {
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 169/191 dccp: Call security_inet_conn_request() after setting IPv4 addresses.
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kuniyuki Iwashima <[email protected]>
[ Upstream commit fa2df45af13091f76b89adb84a28f13818d5d631 ]
Initially, commit 4237c75c0a35 ("[MLSXFRM]: Auto-labeling of child sockets") introduced security_inet_conn_request() in some functions where reqsk is allocated. The hook is added just after the allocation, so reqsk's IPv4 remote address was not initialised then.
However, SELinux/Smack started to read it in netlbl_req_setattr() after the cited commits.
This bug was partially fixed by commit 284904aa7946 ("lsm: Relocate the IPv4 security_inet_conn_request() hooks").
This patch fixes the last bug in DCCPv4.
--- net/dccp/ipv4.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
net/dccp/ipv4.c +3 -3
@@ -613,9 +613,6 @@ int dccp_v4_conn_request(struct sock *sk, struct sk_buff *skb)if (dccp_parse_options (sk, dreq, skb)) goto drop_and_free; -if (security_inet_conn_request (sk, skb, req)) - goto drop_and_free; - ireq =inet_rsk (req);sk_rcv_saddr_set (req_to_sk (req),ip_hdr (skb)->daddr);sk_daddr_set (req_to_sk (req),ip_hdr (skb)->saddr);
@@ -623,6 +620,9 @@ int dccp_v4_conn_request(struct sock *sk, struct sk_buff *skb) ireq->ireq_family =AF_INET ; ireq->ir_iif = sk->sk_bound_dev_if; +if (security_inet_conn_request (sk, skb, req)) + goto drop_and_free; +/* * Step 3: Process LISTEN state *
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 170/191 dccp/tcp: Call security_inet_conn_request() after setting IPv6 addresses.
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kuniyuki Iwashima <[email protected]>
[ Upstream commit 23be1e0e2a83a8543214d2599a31d9a2185a796b ]
Initially, commit 4237c75c0a35 ("[MLSXFRM]: Auto-labeling of child sockets") introduced security_inet_conn_request() in some functions where reqsk is allocated. The hook is added just after the allocation, so reqsk's IPv6 remote address was not initialised then.
However, SELinux/Smack started to read it in netlbl_req_setattr() after commit e1adea927080 ("calipso: Allow request sockets to be relabelled by the lsm.").
Commit 284904aa7946 ("lsm: Relocate the IPv4 security_inet_conn_request() hooks") fixed that kind of issue only in TCPv4 because IPv6 labeling was not supported at that time. Finally, the same issue was introduced again in IPv6.
Let's apply the same fix on DCCPv6 and TCPv6.
--- net/dccp/ipv6.c | 6 +++--- net/ipv6/syncookies.c | 7 ++++--- 2 files changed, 7 insertions(+), 6 deletions(-)
net/dccp/ipv6.c +3 -3
@@ -349,15 +349,15 @@ static int dccp_v6_conn_request(struct sock *sk, struct sk_buff *skb)if (dccp_parse_options (sk, dreq, skb)) goto drop_and_free; -if (security_inet_conn_request (sk, skb, req)) - goto drop_and_free; - ireq =inet_rsk (req); ireq->ir_v6_rmt_addr =ipv6_hdr (skb)->saddr; ireq->ir_v6_loc_addr =ipv6_hdr (skb)->daddr; ireq->ireq_family =AF_INET6 ; ireq->ir_mark =inet_request_mark (sk, skb); +if (security_inet_conn_request (sk, skb, req)) + goto drop_and_free; +if (ipv6_opt_accepted (sk, skb,IP6CB (skb)) || np->rxopt.bits.rxinfo || np->rxopt.bits.rxoinfo || np->rxopt.bits.rxhlim || np->rxopt.bits.rxohlim) {
net/ipv6/syncookies.c +4 -3
@@ -180,14 +180,15 @@ struct sock *cookie_v6_check(struct sock *sk, struct sk_buff *skb) treq =tcp_rsk (req); treq->tfo_listener = false; -if (security_inet_conn_request (sk, skb, req)) - goto out_free; - req->mss = mss; ireq->ir_rmt_port = th->source; ireq->ir_num =ntohs (th->dest); ireq->ir_v6_rmt_addr =ipv6_hdr (skb)->saddr; ireq->ir_v6_loc_addr =ipv6_hdr (skb)->daddr; + +if (security_inet_conn_request (sk, skb, req)) + goto out_free; +if (ipv6_opt_accepted (sk, skb, &TCP_SKB_CB (skb)->header.h6) || np->rxopt.bits.rxinfo || np->rxopt.bits.rxoinfo || np->rxopt.bits.rxhlim || np->rxopt.bits.rxohlim) {
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 171/191 net: r8169: Disable multicast filter for RTL8168H and RTL8107E
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Patrick Thompson <[email protected]>
[ Upstream commit efa5f1311c4998e9e6317c52bc5ee93b3a0f36df ]
RTL8168H and RTL8107E ethernet adapters erroneously filter unicast eapol packets unless allmulti is enabled. These devices correspond to RTL_GIGA_MAC_VER_46 and VER_48. Add an exception for VER_46 and VER_48 in the same way that VER_35 has an exception.
--- drivers/net/ethernet/realtek/r8169_main.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/net/ethernet/realtek/r8169_main.c +3 -1
@@ -2579,7 +2579,9 @@ static void rtl_set_rx_mode(struct net_device *dev) rx_mode |= AcceptAllPhys; }else if (netdev_mc_count (dev) >MC_FILTER_LIMIT || dev->flags &IFF_ALLMULTI || - tp->mac_version ==RTL_GIGA_MAC_VER_35 ) { + tp->mac_version ==RTL_GIGA_MAC_VER_35 || + tp->mac_version ==RTL_GIGA_MAC_VER_46 || + tp->mac_version ==RTL_GIGA_MAC_VER_48 ) {/* accept all multicasts */ }else if (netdev_mc_empty (dev)) { rx_mode &= ~AcceptMulticast;
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 172/191 Fix termination state for idr_for_each_entry_ul()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: NeilBrown <[email protected]>
[ Upstream commit e8ae8ad479e2d037daa33756e5e72850a7bd37a9 ]
The comment for idr_for_each_entry_ul() states
after normal termination @entry is left with the value NULL
This is not correct in the case where UINT_MAX has an entry in the idr. In that case @entry will be non-NULL after termination.
No current code depends on the documentation being correct, but to save future code we should fix it.
Also fix idr_for_each_entry_continue_ul(). While this is not documented as leaving @entry as NULL, the mellanox driver appears to depend on it doing so. So make that explicit in the documentation as well as in the code.
--- include/linux/idr.h | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
include/linux/idr.h +4 -2
@@ -200,7 +200,7 @@ static inline void idr_preload_end(void)*/ #define idr_for_each_entry_ul (idr, entry, tmp, id) \ for (tmp = 0, id = 0; \ - tmp <= id && ((entry) = idr_get_next_ul(idr, &(id))) != NULL; \ + ((entry) = tmp <= id ? idr_get_next_ul(idr, &(id)) : NULL) != NULL; \ tmp = id, ++id)/**
@@ -224,10 +224,12 @@ static inline void idr_preload_end(void)* @id: Entry ID. * * Continue to iterate over entries, continuing after the current position. +* After normal termination @entry is left with the value NULL. This +* is convenient for a "not found" value. */ #define idr_for_each_entry_continue_ul (idr, entry, tmp, id) \ for (tmp = id; \ - tmp <= id && ((entry) = idr_get_next_ul(idr, &(id))) != NULL; \ + ((entry) = tmp <= id ? idr_get_next_ul(idr, &(id)) : NULL) != NULL; \ tmp = id, ++id)/*
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 173/191 net: stmmac: xgmac: Enable support for multiple Flexible PPS outputs
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Furong Xu <[email protected]>
[ Upstream commit db456d90a4c1b43b6251fa4348c8adc59b583274 ]
Quoted 1 line
From XGMAC Core 3.20 and later, each Flexible PPS has individual PPSEN bit
to select Fixed mode or Flexible mode. The PPSEN must be set, or it stays in Fixed PPS mode by default.
XGMAC Core prior 3.20, only PPSEN0(bit 4) is writable. PPSEN{1,2,3} are read-only reserved, and they are already in Flexible mode by default, our new code always set PPSEN{1,2,3} do not make things worse ;-)
--- drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h | 2 +- .../net/ethernet/stmicro/stmmac/dwxgmac2_core.c | 14 +++++++++++++- 2 files changed, 14 insertions(+), 2 deletions(-)
drivers/net/ethernet/stmicro/stmmac/dwxgmac2.h +1 -1
@@ -222,7 +222,7 @@ ((val) << XGMAC_PPS_MINIDX(x))#define XGMAC_PPSCMD_START 0x2#define XGMAC_PPSCMD_STOP 0x5 -#define XGMAC_PPSEN0 BIT(4) +#define XGMAC_PPSENx (x) BIT(4 + (x) * 8)#define XGMAC_PPSx_TARGET_TIME_SEC (x) (0x00000d80 + (x) * 0x10)#define XGMAC_PPSx_TARGET_TIME_NSEC (x) (0x00000d84 + (x) * 0x10)#define XGMAC_TRGTBUSY0 BIT(31)
drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c +13 -1
@@ -1132,7 +1132,19 @@ static int dwxgmac2_flex_pps_config(void __iomem *ioaddr, int index, val |=XGMAC_PPSCMDx (index,XGMAC_PPSCMD_START ); val |=XGMAC_TRGTMODSELx (index,XGMAC_PPSCMD_START ); - val |=XGMAC_PPSEN0 ; + +/* XGMAC Core has 4 PPS outputs at most. +* +* Prior XGMAC Core 3.20, Fixed mode or Flexible mode are selectable for +* PPS0 only via PPSEN0. PPS{1,2,3} are in Flexible mode by default, +* and can not be switched to Fixed mode, since PPSEN{1,2,3} are +* read-only reserved to 0. +* But we always set PPSEN{1,2,3} do not make things worse ;-) +* +* From XGMAC Core 3.20 and later, PPSEN{0,1,2,3} are writable and must +* be set, or the PPS outputs stay in Fixed PPS mode by default. +*/ + val |=XGMAC_PPSENx (index);writel (cfg->start.tv_sec, ioaddr +XGMAC_PPSx_TARGET_TIME_SEC (index));
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 174/191 net/smc: fix dangling sock under state SMC_APPFINCLOSEWAIT
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: D. Wythe <[email protected]>
[ Upstream commit 5211c9729484c923f8d2e06bd29f9322cc42bb8f ]
Considering scenario:
smc_cdc_rx_handler__smc_release
sock_set_flagsmc_close_active()sock_set_flag
__set_bit(DEAD) __set_bit(DONE)
Dues to __set_bit is not atomic, the DEAD or DONE might be lost. if the DEAD flag lost, the state SMC_CLOSED will be never be reached in smc_close_passive_work:
if (sock_flag(sk, SOCK_DEAD) &&
smc_close_sent_any_close(conn)) {
sk->sk_state = SMC_CLOSED;
} else {
/* just shutdown, but not yet closed locally */
sk->sk_state = SMC_APPFINCLOSEWAIT;
}Replace sock_set_flags or __set_bit to set_bit will fix this problem. Since set_bit is atomic.
--- net/smc/af_smc.c | 4 ++-- net/smc/smc.h | 5 +++++ net/smc/smc_cdc.c | 2 +- net/smc/smc_close.c | 2 +- 4 files changed, 9 insertions(+), 4 deletions(-)
net/smc/af_smc.c +2 -2
@@ -143,7 +143,7 @@ static int __smc_release(struct smc_sock *smc)if (!smc->use_fallback) { rc =smc_close_active (smc); -sock_set_flag (sk,SOCK_DEAD ); +smc_sock_set_flag (sk,SOCK_DEAD ); sk->sk_shutdown |=SHUTDOWN_MASK ; }else {if (sk->sk_state !=SMC_CLOSED ) {
@@ -1169,7 +1169,7 @@ static int smc_clcsock_accept(struct smc_sock *lsmc, struct smc_sock **new_smc)if (new_clcsock)sock_release (new_clcsock); new_sk->sk_state =SMC_CLOSED ; -sock_set_flag (new_sk,SOCK_DEAD ); +smc_sock_set_flag (new_sk,SOCK_DEAD );sock_put (new_sk);/* final */ *new_smc =NULL ; goto out;
net/smc/smc.h +5 -0
@@ -297,4 +297,9 @@ static inline bool using_ipsec(struct smc_sock *smc)struct sock *smc_accept_dequeue (struct sock *parent,struct socket *new_sock);void smc_close_non_accepted (struct sock *sk); +static inline void smc_sock_set_flag (struct sock *sk,enum sock_flags flag) +{ +set_bit (flag, &sk->sk_flags); +} +#endif /* __SMC_H */
net/smc/smc_cdc.c +1 -1
@@ -370,7 +370,7 @@ static void smc_cdc_msg_recv_action(struct smc_sock *smc, smc->sk.sk_shutdown |=RCV_SHUTDOWN ;if (smc->clcsock && smc->clcsock->sk) smc->clcsock->sk->sk_shutdown |=RCV_SHUTDOWN ; -sock_set_flag (&smc->sk,SOCK_DONE ); +smc_sock_set_flag (&smc->sk,SOCK_DONE );sock_hold (&smc->sk);/* sock_put in close_work */ if (!queue_work (smc_close_wq, &conn->close_work))sock_put (&smc->sk);
net/smc/smc_close.c +1 -1
@@ -170,7 +170,7 @@ void smc_close_active_abort(struct smc_sock *smc)break ; } -sock_set_flag (sk,SOCK_DEAD ); +smc_sock_set_flag (sk,SOCK_DEAD ); sk->sk_state_change (sk);if (release_clcsock) {
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 175/191 net/smc: allow cdc msg send rather than drop it with NULL sndbuf_desc
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: D. Wythe <[email protected]>
[ Upstream commit c5bf605ba4f9d6fbbb120595ab95002f4716edcb ]
This patch re-fix the issues mentioned by commit 22a825c541d7 ("net/smc: fix NULL sndbuf_desc in smc_cdc_tx_handler()").
Blocking sending message do solve the issues though, but it also prevents the peer to receive the final message. Besides, in logic, whether the sndbuf_desc is NULL or not have no impact on the processing of cdc message sending.
Hence that, this patch allows the cdc message sending but to check the sndbuf_desc with care in smc_cdc_tx_handler().
--- net/smc/smc_cdc.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-)
net/smc/smc_cdc.c +4 -5
@@ -28,13 +28,15 @@ static void smc_cdc_tx_handler(struct smc_wr_tx_pend_priv *pnd_snd, {struct smc_cdc_tx_pend *cdcpend = (struct smc_cdc_tx_pend *)pnd_snd;struct smc_connection *conn = cdcpend->conn; +struct smc_buf_desc *sndbuf_desc;struct smc_sock *smc;int diff; + sndbuf_desc = conn->sndbuf_desc; smc = container_of(conn, struct smc_sock, conn);bh_lock_sock (&smc->sk); -if (!wc_status) { - diff =smc_curs_diff (cdcpend->conn->sndbuf_desc->len, +if (!wc_status && sndbuf_desc) { + diff =smc_curs_diff (sndbuf_desc->len, &cdcpend->conn->tx_curs_fin, &cdcpend->cursor);/* sndbuf_space is decreased in smc_sendmsg */
@@ -104,9 +106,6 @@ int smc_cdc_msg_send(struct smc_connection *conn,union smc_host_cursor cfed;int rc; -if (unlikely (!READ_ONCE (conn->sndbuf_desc))) -return -ENOBUFS ; -smc_cdc_add_pending_send (conn, pend); conn->tx_cdc_seq++;
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 176/191 net/smc: put sk reference if close work was canceled
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: D. Wythe <[email protected]>
[ Upstream commit aa96fbd6d78d9770323b21e2c92bd38821be8852 ]
Note that we always hold a reference to sock when attempting to submit close_work. Therefore, if we have successfully canceled close_work from pending, we MUST release that reference to avoid potential leaks.
--- net/smc/smc_close.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
net/smc/smc_close.c +2 -1
@@ -113,7 +113,8 @@ static void smc_close_cancel_work(struct smc_sock *smc)struct sock *sk = &smc->sk;release_sock (sk); -cancel_work_sync (&smc->conn.close_work); +if (cancel_work_sync (&smc->conn.close_work)) +sock_put (sk);cancel_delayed_work_sync (&smc->conn.tx_work);lock_sock (sk); }
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 177/191 tg3: power down device only on SYSTEM_POWER_OFF
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: George Shuklin <[email protected]>
[ Upstream commit 9fc3bc7643341dc5be7d269f3d3dbe441d8d7ac3 ]
Dell R650xs servers hangs on reboot if tg3 driver calls tg3_power_down.
This happens only if network adapters (BCM5720 for R650xs) were initialized using SNP (e.g. by booting ipxe.efi).
The actual problem is on Dell side, but this fix allows servers to come back alive after reboot.
--- drivers/net/ethernet/broadcom/tg3.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/net/ethernet/broadcom/tg3.c +2 -1
@@ -18156,7 +18156,8 @@ static void tg3_shutdown(struct pci_dev *pdev)if (netif_running (dev))dev_close (dev); -tg3_power_down (tp); +if (system_state ==SYSTEM_POWER_OFF ) +tg3_power_down (tp);rtnl_unlock ();
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 178/191 r8169: respect userspace disabling IFF_MULTICAST
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Heiner Kallweit <[email protected]>
[ Upstream commit 8999ce4cfc87e61b4143ec2e7b93d8e92e11fa7f ]
So far we ignore the setting of IFF_MULTICAST. Fix this and clear bit AcceptMulticast if IFF_MULTICAST isn't set.
Note: Based on the implementations I've seen it doesn't seem to be 100% clear what a driver is supposed to do if IFF_ALLMULTI is set but IFF_MULTICAST is not. This patch is based on the understanding that IFF_MULTICAST has precedence.
--- drivers/net/ethernet/realtek/r8169_main.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/net/ethernet/realtek/r8169_main.c +2 -0
@@ -2577,6 +2577,8 @@ static void rtl_set_rx_mode(struct net_device *dev)if (dev->flags &IFF_PROMISC ) { rx_mode |= AcceptAllPhys; + }else if (!(dev->flags &IFF_MULTICAST )) { + rx_mode &= ~AcceptMulticast; } else if (netdev_mc_count(dev) > MC_FILTER_LIMIT || dev->flags & IFF_ALLMULTI || tp->mac_version == RTL_GIGA_MAC_VER_35 ||
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 179/191 netfilter: xt_recent: fix (increase) ipv6 literal buffer length
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Maciej Żenczykowski <[email protected]>
[ Upstream commit 7b308feb4fd2d1c06919445c65c8fbf8e9fd1781 ]
in6_pton() supports 'low-32-bit dot-decimal representation' (this is useful with DNS64/NAT64 networks for example):
# echo +aaaa:bbbb:cccc:dddd:eeee:ffff:1.2.3.4 > /proc/self/net/xt_recent/DEFAULT # cat /proc/self/net/xt_recent/DEFAULT src=aaaa:bbbb:cccc:dddd:eeee:ffff:0102:0304 ttl: 0 last_seen: 9733848829 oldest_pkt: 1 9733848829
but the provided buffer is too short:
# echo +aaaa:bbbb:cccc:dddd:eeee:ffff:255.255.255.255 > /proc/self/net/xt_recent/DEFAULT -bash: echo: write error: Invalid argument
--- net/netfilter/xt_recent.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/netfilter/xt_recent.c +1 -1
@@ -561,7 +561,7 @@ recent_mt_proc_write(struct file *file, const char __user *input, {struct recent_table *t =PDE_DATA (file_inode (file));struct recent_entry *e; -char buf[sizeof ("+b335:1d35:1e55:dead:c0de:1715:5afe:c0de" )]; +char buf[sizeof ("+b335:1d35:1e55:dead:c0de:1715:255.255.255.255" )];const char *c = buf;union nf_inet_addr addr = {};u_int16_t family;
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 180/191 netfilter: nft_redir: use `struct nf_nat_range2` throughout and deduplicate eval call-backs
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jeremy Sowden <[email protected]>
[ Upstream commit 6f56ad1b92328997e1b1792047099df6f8d7acb5 ]
nf_nat_redirect_ipv4 takes a struct nf_nat_ipv4_multi_range_compat, but converts it internally to a struct nf_nat_range2. Change the function to take the latter, factor out the code now shared with nf_nat_redirect_ipv6, move the conversion to the xt_REDIRECT module, and update the ipv4 range initialization in the nft_redir module.
Replace a bare hex constant for 127.0.0.1 with a macro.
Remove WARN_ON. nf_nat_setup_info calls nf_ct_is_confirmed:
/* Can't setup nat info for confirmed ct. */ if (nf_ct_is_confirmed(ct)) return NF_ACCEPT;
This means that ct cannot be null or the kernel will crash, and implies that ctinfo is IP_CT_NEW or IP_CT_RELATED.
nft_redir has separate ipv4 and ipv6 call-backs which share much of their code, and an inet one switch containing a switch that calls one of the others based on the family of the packet. Merge the ipv4 and ipv6 ones into the inet one in order to get rid of the duplicate code.
Const-qualify the priv pointer since we don't need to write through it.
Assign priv->flags to the range instead of OR-ing it in.
Set the NF_NAT_RANGE_PROTO_SPECIFIED flag once during init, rather than on every eval.
Stable-dep-of: 80abbe8a8263 ("netfilter: nat: fix ipv6 nat redirect with mapped and scoped addresses")
--- include/net/netfilter/nf_nat_redirect.h | 3 +- net/netfilter/nf_nat_redirect.c | 71 ++++++++++----------- net/netfilter/nft_redir.c | 84 +++++++++---------------- net/netfilter/xt_REDIRECT.c | 10 ++- 4 files changed, 72 insertions(+), 96 deletions(-)
include/net/netfilter/nf_nat_redirect.h +1 -2
@@ -6,8 +6,7 @@#include <uapi/linux/netfilter/nf_nat.h> unsigned int -nf_nat_redirect_ipv4 (struct sk_buff *skb, -const struct nf_nat_ipv4_multi_range_compat *mr, +nf_nat_redirect_ipv4 (struct sk_buff *skb,const struct nf_nat_range2 *range,unsigned int hooknum); unsigned int nf_nat_redirect_ipv6(struct sk_buff *skb, const struct nf_nat_range2 *range,
net/netfilter/nf_nat_redirect.c +32 -39
125 lines not on this page · raw message
net/netfilter/nft_redir.c +31 -53
131 lines not on this page · raw message
net/netfilter/xt_REDIRECT.c +8 -2
@@ -46,7 +46,6 @@ static void redirect_tg_destroy(const struct xt_tgdtor_param *par)nf_ct_netns_put (par->net, par->family); } -/* FIXME: Take multiple ranges --RR */ static int redirect_tg4_check (const struct xt_tgchk_param *par) {const struct nf_nat_ipv4_multi_range_compat *mr = par->targinfo;
@@ -65,7 +64,14 @@ static int redirect_tg4_check(const struct xt_tgchk_param *par)static unsigned int redirect_tg4 (struct sk_buff *skb,const struct xt_action_param *par) { -return nf_nat_redirect_ipv4 (skb, par->targinfo,xt_hooknum (par)); +const struct nf_nat_ipv4_multi_range_compat *mr = par->targinfo; +struct nf_nat_range2 range = { + .flags = mr->range[0 ].flags, + .min_proto = mr->range[0 ].min, + .max_proto = mr->range[0 ].max, + }; + +return nf_nat_redirect_ipv4 (skb, &range,xt_hooknum (par)); }static struct xt_target redirect_tg_reg[]__read_mostly = {
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 181/191 netfilter: nat: fix ipv6 nat redirect with mapped and scoped addresses
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Florian Westphal <[email protected]>
[ Upstream commit 80abbe8a8263106fe45a4f293b92b5c74cc9cc8a ]
The ipv6 redirect target was derived from the ipv4 one, i.e. its identical to a 'dnat' with the first (primary) address assigned to the network interface. The code has been moved around to make it usable from nf_tables too, but its still the same as it was back when this was added in 2012.
IPv6, however, has different types of addresses, if the 'wrong' address comes first the redirection does not work.
In Daniels case, the addresses are:
inet6 ::ffff:192 ...
inet6 2a01: ...
... so the function attempts to redirect to the mapped address.
Add more checks before the address is deemed correct:
1. If the packets' daddr is scoped, search for a scoped address too
2. skip tentative addresses
3. skip mapped addresses
Use the first address that appears to match our needs.
--- net/netfilter/nf_nat_redirect.c | 27 ++++++++++++++++++++++++++- 1 file changed, 26 insertions(+), 1 deletion(-)
net/netfilter/nf_nat_redirect.c +26 -1
@@ -80,6 +80,26 @@ EXPORT_SYMBOL_GPL(nf_nat_redirect_ipv4);static const struct in6_addr loopback_addr =IN6ADDR_LOOPBACK_INIT ; +static bool nf_nat_redirect_ipv6_usable (const struct inet6_ifaddr *ifa,unsigned int scope) +{ +unsigned int ifa_addr_type =ipv6_addr_type (&ifa->addr); + +if (ifa_addr_type &IPV6_ADDR_MAPPED ) +return false; + +if ((ifa->flags &IFA_F_TENTATIVE ) && (!(ifa->flags &IFA_F_OPTIMISTIC ))) +return false; + +if (scope) { +unsigned int ifa_scope = ifa_addr_type &IPV6_ADDR_SCOPE_MASK ; + +if (!(scope & ifa_scope)) +return false; + } + +return true; +} +unsigned int nf_nat_redirect_ipv6 (struct sk_buff *skb,const struct nf_nat_range2 *range,unsigned int hooknum)
@@ -89,14 +109,19 @@ nf_nat_redirect_ipv6(struct sk_buff *skb, const struct nf_nat_range2 *range,if (hooknum ==NF_INET_LOCAL_OUT ) { newdst.in6 = loopback_addr; }else { +unsigned int scope =ipv6_addr_scope (&ipv6_hdr (skb)->daddr);struct inet6_dev *idev; -struct inet6_ifaddr *ifa;bool addr = false; idev =__in6_dev_get (skb->dev);if (idev !=NULL ) { +const struct inet6_ifaddr *ifa; +read_lock_bh (&idev->lock);list_for_each_entry (ifa, &idev->addr_list, if_list) { +if (!nf_nat_redirect_ipv6_usable (ifa, scope)) +continue ; + newdst.in6 = ifa->addr; addr = true;break ;
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 182/191 x86: Share definition of __is_canonical_address()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adrian Hunter <[email protected]>
[ Upstream commit 1fb85d06ad6754796cd1b920639ca9d8840abefd ]
Reduce code duplication by moving canonical address code to a common header file.
Stable-dep-of: f79936545fb1 ("x86/sev-es: Allow copy_from_kernel_nofault() in earlier boot")
--- arch/x86/events/intel/pt.c | 14 ++------------ arch/x86/include/asm/page.h | 10 ++++++++++ arch/x86/kvm/emulate.c | 4 ++-- arch/x86/kvm/x86.c | 2 +- arch/x86/kvm/x86.h | 7 +------ arch/x86/mm/maccess.c | 7 +------ 6 files changed, 17 insertions(+), 27 deletions(-)
arch/x86/events/intel/pt.c +2 -12
@@ -1360,20 +1360,10 @@ static void pt_addr_filters_fini(struct perf_event *event) }#ifdef CONFIG_X86_64 -static u64 canonical_address (u64 vaddr,u8 vaddr_bits) -{ -return ((s64 )vaddr << (64 - vaddr_bits)) >> (64 - vaddr_bits); -} - -static u64 is_canonical_address (u64 vaddr,u8 vaddr_bits) -{ -return canonical_address (vaddr, vaddr_bits) == vaddr; -} -/* Clamp to a canonical address greater-than-or-equal-to the address given */ static u64 clamp_to_ge_canonical_addr (u64 vaddr,u8 vaddr_bits) { -return is_canonical_address (vaddr, vaddr_bits) ? +return __is_canonical_address (vaddr, vaddr_bits) ? vaddr : -BIT_ULL (vaddr_bits -1 ); }
@@ -1381,7 +1371,7 @@ static u64 clamp_to_ge_canonical_addr(u64 vaddr, u8 vaddr_bits)/* Clamp to a canonical address less-than-or-equal-to the address given */ static u64 clamp_to_le_canonical_addr (u64 vaddr,u8 vaddr_bits) { -return is_canonical_address (vaddr, vaddr_bits) ? +return __is_canonical_address (vaddr, vaddr_bits) ? vaddr :BIT_ULL (vaddr_bits -1 ) -1 ; }
arch/x86/include/asm/page.h +10 -0
@@ -71,6 +71,16 @@ static inline void copy_user_page(void *to, void *from, unsigned long vaddr,extern bool __virt_addr_valid (unsigned long kaddr);#define virt_addr_valid (kaddr) __virt_addr_valid((unsigned long) (kaddr)) +static __always_inline u64 __canonical_address(u64 vaddr, u8 vaddr_bits) +{ +return ((s64 )vaddr << (64 - vaddr_bits)) >> (64 - vaddr_bits); +} + +static __always_inline u64 __is_canonical_address(u64 vaddr, u8 vaddr_bits) +{ +return __canonical_address (vaddr, vaddr_bits) == vaddr; +} +#endif /* __ASSEMBLY__ */ #include <asm-generic/memory_model.h>
arch/x86/kvm/emulate.c +2 -2
@@ -688,7 +688,7 @@ static inline u8 ctxt_virt_addr_bits(struct x86_emulate_ctxt *ctxt)static inline bool emul_is_noncanonical_address (u64 la,struct x86_emulate_ctxt *ctxt) { -return get_canonical (la,ctxt_virt_addr_bits (ctxt)) != la; +return !__is_canonical_address (la,ctxt_virt_addr_bits (ctxt)); }/*
@@ -738,7 +738,7 @@ static __always_inline int __linearize(struct x86_emulate_ctxt *ctxt,case X86EMUL_MODE_PROT64 : *linear = la; va_bits =ctxt_virt_addr_bits (ctxt); -if (get_canonical (la, va_bits) != la) +if (!__is_canonical_address (la, va_bits)) goto bad; *max_size =min_t (u64, ~0u , (1ull << va_bits) - la);
arch/x86/kvm/x86.c +1 -1
@@ -1640,7 +1640,7 @@ static int __kvm_set_msr(struct kvm_vcpu *vcpu, u32 index, u64 data,* value, and that something deterministic happens if the guest * invokes 64-bit SYSENTER. */ - data =get_canonical (data,vcpu_virt_addr_bits (vcpu)); + data =__canonical_address (data,vcpu_virt_addr_bits (vcpu)); } msr.data = data;
arch/x86/kvm/x86.h +1 -6
@@ -156,14 +156,9 @@ static inline u8 vcpu_virt_addr_bits(struct kvm_vcpu *vcpu)return kvm_read_cr4_bits (vcpu,X86_CR4_LA57 ) ?57 :48 ; } -static inline u64 get_canonical (u64 la,u8 vaddr_bits) -{ -return ((int64_t )la << (64 - vaddr_bits)) >> (64 - vaddr_bits); -} -static inline bool is_noncanonical_address (u64 la,struct kvm_vcpu *vcpu) { -return get_canonical (la,vcpu_virt_addr_bits (vcpu)) != la; +return !__is_canonical_address (la,vcpu_virt_addr_bits (vcpu)); } static inline void vcpu_cache_mmio_info(struct kvm_vcpu *vcpu,
arch/x86/mm/maccess.c +1 -6
@@ -4,11 +4,6 @@#include <linux/kernel.h> #ifdef CONFIG_X86_64 -static __always_inline u64 canonical_address(u64 vaddr, u8 vaddr_bits) -{ -return ((s64 )vaddr << (64 - vaddr_bits)) >> (64 - vaddr_bits); -} -bool copy_from_kernel_nofault_allowed (const void *unsafe_src,size_t size) {unsigned long vaddr = (unsigned long )unsafe_src;
@@ -19,7 +14,7 @@ bool copy_from_kernel_nofault_allowed(const void *unsafe_src, size_t size)* we also need to include the userspace guard page. */ return vaddr >=TASK_SIZE_MAX +PAGE_SIZE && - canonical_address(vaddr, boot_cpu_data.x86_virt_bits) == vaddr; + __is_canonical_address(vaddr, boot_cpu_data.x86_virt_bits); }#else bool copy_from_kernel_nofault_allowed (const void *unsafe_src,size_t size)
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 183/191 x86/sev-es: Allow copy_from_kernel_nofault() in earlier boot
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Adam Dunlap <[email protected]>
[ Upstream commit f79936545fb122856bd78b189d3c7ee59928c751 ]
Previously, if copy_from_kernel_nofault() was called before boot_cpu_data.x86_virt_bits was set up, then it would trigger undefined behavior due to a shift by 64.
This ended up causing boot failures in the latest version of ubuntu2204 in the gcp project when using SEV-SNP.
Specifically, this function is called during an early #VC handler which is triggered by a CPUID to check if NX is implemented.
--- arch/x86/mm/maccess.c | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-)
arch/x86/mm/maccess.c +14 -5
@@ -9,12 +9,21 @@ bool copy_from_kernel_nofault_allowed(const void *unsafe_src, size_t size)unsigned long vaddr = (unsigned long )unsafe_src;/* -* Range covering the highest possible canonical userspace address -* as well as non-canonical address range. For the canonical range -* we also need to include the userspace guard page. +* Do not allow userspace addresses. This disallows +* normal userspace and the userspace guard page: */ -return vaddr >=TASK_SIZE_MAX +PAGE_SIZE && - __is_canonical_address(vaddr, boot_cpu_data.x86_virt_bits); +if (vaddr <TASK_SIZE_MAX +PAGE_SIZE ) +return false; + +/* +* Allow everything during early boot before 'x86_virt_bits' +* is initialized. Needed for instruction decoding in early +* exception handlers. +*/ +if (!boot_cpu_data.x86_virt_bits) +return true; + + return __is_canonical_address(vaddr, boot_cpu_data.x86_virt_bits); }#else bool copy_from_kernel_nofault_allowed (const void *unsafe_src,size_t size)
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 184/191 drm/syncobj: fix DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Erik Kurzinger <[email protected]>
[ Upstream commit 101c9f637efa1655f55876644d4439e552267527 ]
If DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT is invoked with the DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE flag set but no fence has yet been submitted for the given timeline point the call will fail immediately with EINVAL. This does not match the intended behavior where the call should wait until the fence has been submitted (or the timeout expires).
The following small example program illustrates the issue. It should wait for 5 seconds and then print ETIME, but instead it terminates right away after printing EINVAL.
#include <stdio.h>
#include <fcntl.h>
#include <time.h>
#include <errno.h>
#include <xf86drm.h>
int main(void)
{
int fd = open("/dev/dri/card0", O_RDWR);
uint32_t syncobj;
drmSyncobjCreate(fd, 0, &syncobj);
struct timespec ts;
clock_gettime(CLOCK_MONOTONIC, &ts);
uint64_t point = 1;
if (drmSyncobjTimelineWait(fd, &syncobj, &point, 1,
ts.tv_sec * 1000000000 + ts.tv_nsec + 5000000000, // 5s
DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE, NULL)) {
printf("drmSyncobjTimelineWait failed %d\n", errno);
}
}Reviewed by: Simon Ser <[email protected]>
--- drivers/gpu/drm/drm_syncobj.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/gpu/drm/drm_syncobj.c +2 -1
@@ -983,7 +983,8 @@ static signed long drm_syncobj_array_wait_timeout(struct drm_syncobj **syncobjs, fence =drm_syncobj_fence_get (syncobjs[i]);if (!fence ||dma_fence_chain_find_seqno (&fence, points[i])) {dma_fence_put (fence); -if (flags &DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT ) { +if (flags & (DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT | +DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE )) {continue ; }else { timeout = -EINVAL ;
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 185/191 spi: spi-zynq-qspi: add spi-mem to driver kconfig dependencies
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Amit Kumar Mahapatra <[email protected]>
[ Upstream commit c2ded280a4b1b7bd93e53670528504be08d24967 ]
Zynq QSPI driver has been converted to use spi-mem framework so add spi-mem to driver kconfig dependencies.
--- drivers/spi/Kconfig | 1 + 1 file changed, 1 insertion(+)
drivers/spi/Kconfig +1 -0
@@ -949,6 +949,7 @@ config SPI_XTENSA_XTFPGA config SPI_ZYNQ_QSPI tristate "Xilinx Zynq QSPI controller" depends on ARCH_ZYNQ || COMPILE_TEST + depends on SPI_MEM help This enables support for the Zynq Quad SPI controller in master mode.
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 186/191 fbdev: imsttfb: Fix error path of imsttfb_probe()
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Helge Deller <[email protected]>
[ Upstream commit 518ecb6a209f6ff678aeadf9f2bf870c0982ca85 ]
Release ressources when init_imstt() returns failure.
Stable-dep-of: aba6ab57a910 ("fbdev: imsttfb: fix a resource leak in probe")
--- drivers/video/fbdev/imsttfb.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
drivers/video/fbdev/imsttfb.c +4 -2
@@ -1525,8 +1525,10 @@ static int imsttfb_probe(struct pci_dev *pdev, const struct pci_device_id *ent) goto error; info->pseudo_palette = par->palette; ret =init_imstt (info); -if (!ret) -pci_set_drvdata (pdev, info); +if (ret) + goto error; + +pci_set_drvdata (pdev, info);return ret; error:
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 187/191 fbdev: imsttfb: fix a resource leak in probe
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dan Carpenter <[email protected]>
[ Upstream commit aba6ab57a910ad4b940c2024d15f2cdbf5b7f76b ]
I've re-written the error handling but the bug is that if init_imstt() fails we need to call iounmap(par->cmap_regs).
--- drivers/video/fbdev/imsttfb.c | 29 ++++++++++++++++------------- 1 file changed, 16 insertions(+), 13 deletions(-)
drivers/video/fbdev/imsttfb.c +16 -13
@@ -1489,8 +1489,8 @@ static int imsttfb_probe(struct pci_dev *pdev, const struct pci_device_id *ent)if (!request_mem_region (addr, size,"imsttfb" )) {printk (KERN_ERR "imsttfb: Can't reserve memory region\n" ); -framebuffer_release (info); -return -ENODEV ; + ret = -ENODEV ; + goto release_info; }switch (pdev->device) {
@@ -1507,36 +1507,39 @@ static int imsttfb_probe(struct pci_dev *pdev, const struct pci_device_id *ent)printk (KERN_INFO "imsttfb: Device 0x%x unknown, " "contact maintainer.\n" , pdev->device); ret = -ENODEV ; - goto error; + goto release_mem_region; } info->fix.smem_start = addr; info->screen_base = (__u8 *)ioremap (addr, par->ramdac ==IBM ?0x400000 :0x800000 );if (!info->screen_base) - goto error; + goto release_mem_region; info->fix.mmio_start = addr +0x800000 ; par->dc_regs =ioremap (addr +0x800000 ,0x1000 );if (!par->dc_regs) - goto error; + goto unmap_screen_base; par->cmap_regs_phys = addr +0x840000 ; par->cmap_regs = (__u8 *)ioremap (addr +0x840000 ,0x1000 );if (!par->cmap_regs) - goto error; + goto unmap_dc_regs; info->pseudo_palette = par->palette; ret =init_imstt (info);if (ret) - goto error; + goto unmap_cmap_regs;pci_set_drvdata (pdev, info); -return ret; +return 0 ; -error: -if (par->dc_regs) -iounmap (par->dc_regs); -if (info->screen_base) -iounmap (info->screen_base); +unmap_cmap_regs: +iounmap (par->cmap_regs); +unmap_dc_regs: +iounmap (par->dc_regs); +unmap_screen_base: +iounmap (info->screen_base); +release_mem_region:release_mem_region (addr, size); +release_info:framebuffer_release (info);return ret; }
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 188/191 fbdev: fsl-diu-fb: mark wr_reg_wa() static
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Arnd Bergmann <[email protected]>
[ Upstream commit a5035c81847430dfa3482807b07325f29e9e8c09 ]
wr_reg_wa() is not an appropriate name for a global function, and doesn't need to be global anyway, so mark it static and avoid the warning:
drivers/video/fbdev/fsl-diu-fb.c:493:6: error: no previous prototype for 'wr_reg_wa' [-Werror=missing-prototypes]
--- drivers/video/fbdev/fsl-diu-fb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/video/fbdev/fsl-diu-fb.c +1 -1
@@ -490,7 +490,7 @@ static enum fsl_diu_monitor_port fsl_diu_name_to_port(const char *s)* Workaround for failed writing desc register of planes. * Needed with MPC5121 DIU rev 2.0 silicon. */ -void wr_reg_wa (u32 *reg,u32 val) +static void wr_reg_wa (u32 *reg,u32 val) { do { out_be32(reg, val);
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 189/191 tracing/kprobes: Fix the order of argument descriptions
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yujie Liu <[email protected]>
[ Upstream commit f032c53bea6d2057c14553832d846be2f151cfb2 ]
The order of descriptions should be consistent with the argument list of the function, so "kretprobe" should be the second one.
int __kprobe_event_gen_cmd_start(struct dynevent_cmd *cmd, bool kretprobe,
const char *name, const char *loc, ...)
--- kernel/trace/trace_kprobe.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
kernel/trace/trace_kprobe.c +1 -1
@@ -949,9 +949,9 @@ EXPORT_SYMBOL_GPL(kprobe_event_cmd_init);/** * __kprobe_event_gen_cmd_start - Generate a kprobe event command from arg list * @cmd: A pointer to the dynevent_cmd struct representing the new event +* @kretprobe: Is this a return probe? * @name: The name of the kprobe event * @loc: The location of the kprobe event -* @kretprobe: Is this a return probe? * @...: Variable number of arg (pairs), one pair for each field * * NOTE: Users normally won't want to call this function directly, but
Signature · 1 line
2.42.0
Greg Kroah-Hartman
maintainerPATCH 190/191 Revert "mmc: core: Capture correct oemid-bits for eMMC cards"
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dominique Martinet <[email protected]>
commit 421b605edb1ce611dee06cf6fd9a1c1f2fd85ad0 upstream.
This reverts commit 84ee19bffc9306128cd0f1c650e89767079efeff.
The commit above made quirks with an OEMID fail to be applied, as they were checking card->cid.oemid for the full 16 bits defined in MMC_FIXUP macros but the field would only contain the bottom 8 bits.
eMMC v5.1A might have bogus values in OEMID's higher bits so another fix will be made, but it has been decided to revert this until that is ready.
--- drivers/mmc/core/mmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/mmc/core/mmc.c +1 -1
@@ -95,7 +95,7 @@ static int mmc_decode_cid(struct mmc_carcase 3 :/* MMC v3.1 - v3.3 */ case 4 :/* MMC v4 */ card->cid.manfid =UNSTUFF_BITS (resp,120 ,8 ); - card->cid.oemid =UNSTUFF_BITS (resp,104 ,8 ); + card->cid.oemid =UNSTUFF_BITS (resp,104 ,16 ); card->cid.prod_name[0 ] =UNSTUFF_BITS (resp,96 ,8 ); card->cid.prod_name[1 ] =UNSTUFF_BITS (resp,88 ,8 ); card->cid.prod_name[2 ] =UNSTUFF_BITS (resp,80 ,8 );
Greg Kroah-Hartman
maintainerPATCH 191/191 btrfs: use u64 for buffer sizes in the tree search ioctls
In reply to Greg Kroah-Hartman5.10-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filipe Manana <[email protected]>
[ Upstream commit dec96fc2dcb59723e041416b8dc53e011b4bfc2e ]
In the tree search v2 ioctl we use the type size_t, which is an unsigned long, to track the buffer size in the local variable 'buf_size'. An unsigned long is 32 bits wide on a 32 bits architecture. The buffer size defined in struct btrfs_ioctl_search_args_v2 is a u64, so when we later try to copy the local variable 'buf_size' to the argument struct, when the search returns -EOVERFLOW, we copy only 32 bits which will be a problem on big endian systems.
Fix this by using a u64 type for the buffer sizes, not only at btrfs_ioctl_tree_search_v2(), but also everywhere down the call chain so that we can use the u64 at btrfs_ioctl_tree_search_v2().
--- fs/btrfs/ioctl.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)
fs/btrfs/ioctl.c +5 -5
@@ -2104,7 +2104,7 @@ static noinline int key_in_sk(struct btrfs_key *key, static noinline int copy_to_sk(struct btrfs_path *path,struct btrfs_key *key,struct btrfs_ioctl_search_key *sk, -size_t *buf_size, +u64 *buf_size,char __user *ubuf,unsigned long *sk_offset,int *num_found)
@@ -2236,7 +2236,7 @@ static noinline int copy_to_sk(struct btrfs_path *path, static noinline int search_ioctl(struct inode *inode,struct btrfs_ioctl_search_key *sk, -size_t *buf_size, +u64 *buf_size,char __user *ubuf) {struct btrfs_fs_info *info =btrfs_sb (inode->i_sb);
@@ -2306,7 +2306,7 @@ static noinline int btrfs_ioctl_tree_search(struct file *file,struct btrfs_ioctl_search_key sk;struct inode *inode;int ret; -size_t buf_size; +u64 buf_size;if (!capable (CAP_SYS_ADMIN ))return -EPERM ;
@@ -2340,8 +2340,8 @@ static noinline int btrfs_ioctl_tree_search_v2(struct file *file,struct btrfs_ioctl_search_args_v2 args;struct inode *inode;int ret; -size_t buf_size; -const size_t buf_limit =SZ_16M ; +u64 buf_size; +const u64 buf_limit =SZ_16M ;if (!capable (CAP_SYS_ADMIN ))return -EPERM ;
Signature · 1 line
2.42.0
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.201 release. There are 191 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, 17 Nov 2023 20:46:03 +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.10.201-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.10.y
and the diffstat can be found below.thanks,
greg k-h
This was caught up in the previous -rc cycle:
/local/stbopt_p/toolchains_303/stbgcc-12.3-0.2/bin/../lib/gcc/arm-unknown-linux-musleabihf/12.3.0/../../../../arm-unknown-linux-musleabihf/bin/ld: /local/users/fainelli/buildroot/output/arm/build/linux-custom/tools/perf/perf-in.o: in function `evlist__add_aux_dummy':
/local/users/fainelli/buildroot/output/arm/build/linux-custom/tools/perf/util/evlist.c:269: undefined reference to `evlist__dummy_event'
collect2: error: ld returned 1 exit status
make[4]: *** [Makefile.perf:655: /local/users/fainelli/buildroot/output/arm/build/linux-custom/tools/perf/perf] Error 1
make[3]: *** [Makefile.perf:229: sub-make] Error 2
make[2]: *** [Makefile:70: all] Error 2
perf fails to build because of 8911e3d6564efbb253208ba031b42fa3e672b3b0 ("perf evlist: Add evlist__add_dummy_on_all_cpus()").
Signature · 1 line
Florian
Greg Kroah-Hartman wrote on Wed, Nov 15, 2023 at 03:44:35PM -0500:
Quoted 5 lines
This is the start of the stable review cycle for the 5.10.201 release. There are 191 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, 17 Nov 2023 20:46:03 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.10.201-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.10.y
and the diffstat can be found below.
Tested on:
- arm i.MX6ULL (Armadillo 640)
- arm64 i.MX8MP (Armadillo G4)
No obvious regression in dmesg or basic tests:
Signature · 1 line
Dominique Martinet | Asmadeus
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.201 release. There are 191 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, 17 Nov 2023 20:46:03 +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.10.201-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-5.10.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
## Build
* kernel: 5.10.201-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-5.10.y
* git commit: 550b7e1fee20e8840f9c1028c89dd3fc9c959fff
* git describe: v5.10.200-192-g550b7e1fee20
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10.200-192-g550b7e1fee20
## Test Regressions (compared to v5.10.200)
## Metric Regressions (compared to v5.10.200)
## Test Fixes (compared to v5.10.200)
## Metric Fixes (compared to v5.10.200)
## Test result summary
total: 82357, pass: 64836, fail: 2567, skip: 14910, xfail: 44
## Build Summary
* arc: 5 total, 5 passed, 0 failed
* arm: 113 total, 110 passed, 3 failed
* arm64: 43 total, 40 passed, 3 failed
* i386: 34 total, 33 passed, 1 failed
* mips: 24 total, 24 passed, 0 failed
* parisc: 3 total, 0 passed, 3 failed
* powerpc: 25 total, 25 passed, 0 failed
* riscv: 11 total, 11 passed, 0 failed
* s390: 12 total, 12 passed, 0 failed
* sh: 10 total, 10 passed, 0 failed
* sparc: 8 total, 8 passed, 0 failed
* x86_64: 37 total, 37 passed, 0 failed
## Test suites summary
* boot
* 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-exec
* kselftest-filesystems
* kselftest-filesystems-binderfs
* kselftest-filesystems-epoll
* 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-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-sigaltstack
* kselftest-size
* kselftest-tc-testing
* kselftest-timens
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-user_events
* kselftest-vDSO
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kunit
* libgpiod
* 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-pty
* ltp-sched
* ltp-securebits
* ltp-smoke
* ltp-syscalls
* ltp-tracing
* perf
* rcutorture
--
Linaro LKFT
https://lkft.linaro.org
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.201 release. There are 191 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, 17 Nov 2023 20:46:03 +0000. Anything received after that time might be too late.
Build results:
total: 159 pass: 155 fail: 4 Failed builds: arm:allmodconfig arm64:allmodconfig i386:tools/perf x86_64:tools/perf Qemu test results: total: 495 pass: 495 fail: 0
with:
Building arm64:allmodconfig ... failed
--------------
Error log:drivers/interconnect/qcom/osm-l3.c:6:10: fatal error: linux/args.h: No such file or directory
There is no linux/args.h in v5.10.y.
Caused by "interconnect: qcom: osm-l3: Replace custom implementation of COUNT_ARGS()".
Also:
Building i386:tools/perf ... failed
util/evlist.c: In function ‘evlist__add_aux_dummy’:util/evlist.c:269:24: error: implicit declaration of function ‘evlist__dummy_event’; did you mean ‘evsel__is_dummy_event’? [-Werror=implicit-function-declaration]
269 | struct evsel *evsel = evlist__dummy_event(evlist);
| ^~~~~~~~~~~~~~~~~~~
| evsel__is_dummy_eventutil/evlist.c:269:24: error: initialization of ‘struct evsel *’ from ‘int’ makes pointer from integer without a cast
There is indeed no 'evlist__dummy_event' function in v5.10.y.
This is with v5.10.200-192-g550b7e1fee20. I am a bit puzzled why others don't seem to see those problems.
Guenter
Guenter Roeck wrote on Thu, Nov 16, 2023 at 05:13:39PM -0800:
Quoted 8 lines
Failed builds:
arm:allmodconfig arm64:allmodconfig i386:tools/perf x86_64:tools/perfThis is with v5.10.200-192-g550b7e1fee20. I am a bit puzzled why others don't seem to see those problems.
The perf problem was reported by Florian Fainelli, but my current test build does not include userspace tools as we're not shipping them (and would rely on $distro packages when I need perf as a user rather than building it).
Likewise, it looks like neither Linaro nor me build the qcom driver... I'm building kernels that have been trimmed down for our boards (with that exact config we're shipping and providing for our customers), and arm* drivers are especially fractured so it's a bit misleading to see "arm64 pass", that's just the tip of the actual setup tested.
(Anyway, the main reason for me is mostly that $job is a small company that cannot afford extensive upstream testing, so I just don't have the time to do extended tests -- for the same reason we're only supporting the 5.10 tree so I'm focusing my limited time on just this branch, even if I'd love to do more.
I'm just taking the stance that some test is better than no test and report back things we'd need to test before shipping customers a few weeks later anyway -- thank you for covering more!)
Signature · 1 line
Dominique Martinet | Asmadeus
Hi,
Quoted 22 lines · Dominique Martinet
Guenter Roeck wrote on Thu, Nov 16, 2023 at 05:13:39PM -0800:
Quoted 8 lines
Failed builds:
arm:allmodconfig arm64:allmodconfig i386:tools/perf x86_64:tools/perfThis is with v5.10.200-192-g550b7e1fee20. I am a bit puzzled why others don't seem to see those problems.
The perf problem was reported by Florian Fainelli, but my current test build does not include userspace tools as we're not shipping them (and would rely on $distro packages when I need perf as a user rather than building it).
Likewise, it looks like neither Linaro nor me build the qcom driver... I'm building kernels that have been trimmed down for our boards (with that exact config we're shipping and providing for our customers), and arm* drivers are especially fractured so it's a bit misleading to see "arm64 pass", that's just the tip of the actual setup tested.
Quoted 9 lines
(Anyway, the main reason for me is mostly that $job is a small company that cannot afford extensive upstream testing, so I just don't have the time to do extended tests -- for the same reason we're only supporting the 5.10 tree so I'm focusing my limited time on just this branch, even if I'd love to do more.
I'm just taking the stance that some test is better than no test and report back things we'd need to test before shipping customers a few weeks later anyway -- thank you for covering more!)
Just to clarify, I wasn't assuming or expecting that _everyone_ would report those errors. I was just puzzled that I had not seen _any_ reports, especially since arm:allmodconfig and arm64:allmodconfig both failed to build for me (and I had somehow missed Florian's perf report).
Thanks,
Guenter
Quoted 41 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.201 release. There are 191 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, 17 Nov 2023 20:46:03 +0000. Anything received after that time might be too late.
Build results:
total: 159 pass: 155 fail: 4 Failed builds: arm:allmodconfig arm64:allmodconfig i386:tools/perf x86_64:tools/perf Qemu test results: total: 495 pass: 495 fail: 0with:
Building arm64:allmodconfig ... failed
--------------
Error log:drivers/interconnect/qcom/osm-l3.c:6:10: fatal error:linux/args.h: No such file or directoryThere is no
linux/args.hin v5.10.y.Caused by "interconnect: qcom: osm-l3: Replace custom implementation of
COUNT_ARGS()".Also:
Building i386:tools/perf ... failed
util/evlist.c: In function ‘evlist__add_aux_dummy’:util/evlist.c:269:24: error: implicit declaration of function ‘evlist__dummy_event’; did you mean ‘evsel__is_dummy_event’? [-Werror=implicit-function-declaration]269 | struct evsel *evsel = evlist__dummy_event(evlist); | ^~~~~~~~~~~~~~~~~~~ | evsel__is_dummy_event
Quoted 6 lines
util/evlist.c:269:24: error: initialization of ‘struct evsel *’ from ‘int’ makes pointer from integer without a castThere is indeed no '
evlist__dummy_event' function in v5.10.y.This is with v5.10.200-192-g550b7e1fee20. I am a bit puzzled why others don't seem to see those problems.
Thanks for reporting allmodconfig build failures.
My apologies.
The LKFT found allmodconfig failure lately due to infra issues / timeouts, the builds have been re-triggered manually.
arm:allmodconfig - FAILED
arm64:allmodconfig - FAILED
LKFT have stopped building perf on 5.x and 4.x branches, because we reported several perf build issues and were not solved in the past.
However, building perf tests from recent stable branches and testing that on older
stable-rc branches.
- Naresh
Quoted 55 lines · Naresh Kamboju
Quoted 41 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.201 release. There are 191 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, 17 Nov 2023 20:46:03 +0000. Anything received after that time might be too late.
Build results:
total: 159 pass: 155 fail: 4 Failed builds: arm:allmodconfig arm64:allmodconfig i386:tools/perf x86_64:tools/perf Qemu test results: total: 495 pass: 495 fail: 0with:
Building arm64:allmodconfig ... failed
--------------
Error log:drivers/interconnect/qcom/osm-l3.c:6:10: fatal error:linux/args.h: No such file or directoryThere is no
linux/args.hin v5.10.y.Caused by "interconnect: qcom: osm-l3: Replace custom implementation of
COUNT_ARGS()".Also:
Building i386:tools/perf ... failed
util/evlist.c: In function ‘evlist__add_aux_dummy’:util/evlist.c:269:24: error: implicit declaration of function ‘evlist__dummy_event’; did you mean ‘evsel__is_dummy_event’? [-Werror=implicit-function-declaration]269 | struct evsel *evsel = evlist__dummy_event(evlist); | ^~~~~~~~~~~~~~~~~~~ | evsel__is_dummy_eventQuoted 6 lines
util/evlist.c:269:24: error: initialization of ‘struct evsel *’ from ‘int’ makes pointer from integer without a castThere is indeed no '
evlist__dummy_event' function in v5.10.y.This is with v5.10.200-192-g550b7e1fee20. I am a bit puzzled why others don't seem to see those problems.
Thanks for reporting allmodconfig build failures.
My apologies.
The LKFT found allmodconfig failure lately due to infra issues / timeouts, the builds have been re-triggered manually.
Quoted 6 lines
arm:allmodconfig - FAILED
arm64:allmodconfig - FAILEDLKFT have stopped building perf on 5.x and 4.x branches, because we reported several perf build issues and were not solved in the past.
Kind of makes (sad) sense; after all, I had stopped building perf on 4.14.y as well for the same reason. I'll do the same for 4.19.y and for all 5.x branches.
Guenter
Quoted 59 lines · Guenter Roeck
Quoted 58 lines · Naresh Kamboju
Quoted 43 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.201 release. There are 191 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, 17 Nov 2023 20:46:03 +0000. Anything received after that time might be too late.
Build results:
total: 159 pass: 155 fail: 4
Failed builds:
arm:allmodconfig
arm64:allmodconfig
i386:tools/perf
x86_64:tools/perf
Qemu test results:
total: 495 pass: 495 fail: 0with:
Building arm64:allmodconfig ... failed
--------------
Error log:drivers/interconnect/qcom/osm-l3.c:6:10: fatal error:linux/args.h: No such file or directoryThere is no
linux/args.hin v5.10.y.Caused by "interconnect: qcom: osm-l3: Replace custom implementation of
COUNT_ARGS()".Also:
Building i386:tools/perf ... failed
util/evlist.c: In function ‘evlist__add_aux_dummy’:util/evlist.c:269:24: error: implicit declaration of function ‘evlist__dummy_event’; did you mean ‘evsel__is_dummy_event’? [-Werror=implicit-function-declaration] 269 | struct evsel *evsel =evlist__dummy_event(evlist);
| ^~~~~~~~~~~~~~~~~~~
|evsel__is_dummy_eventutil/evlist.c:269:24: error: initialization of ‘struct evsel *’ from ‘int’ makes pointer from integer without a castQuoted 4 lines
There is indeed no '
evlist__dummy_event' function in v5.10.y.This is with v5.10.200-192-g550b7e1fee20. I am a bit puzzled why others don't seem to see those problems.
Thanks for reporting allmodconfig build failures.
My apologies.
The LKFT found allmodconfig failure lately due to infra issues / timeouts, the builds have been re-triggered manually.arm:allmodconfig - FAILED
arm64:allmodconfig - FAILED
Quoted 7 lines
Quoted 3 lines
LKFT have stopped building perf on 5.x and 4.x branches, because we reported several perf build issues and were not solved in the past.
Kind of makes (sad) sense; after all, I had stopped building perf on 4.14.y as well for the same reason. I'll do the same for 4.19.y and for all 5.x branches.
FWIW, I will continue to build and test perf for all branches that I can easily run on our test rack, which are all of them except 4.14.y and 4.19.y.
Signature · 1 line
Florian
Greg Kroah-Hartman
maintainerQuoted 22 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.201 release. There are 191 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, 17 Nov 2023 20:46:03 +0000. Anything received after that time might be too late.
Build results:
total: 159 pass: 155 fail: 4 Failed builds: arm:allmodconfig arm64:allmodconfig i386:tools/perf x86_64:tools/perf Qemu test results: total: 495 pass: 495 fail: 0with:
Quoted 8 lines
Building arm64:allmodconfig ... failed
--------------
Error log:drivers/interconnect/qcom/osm-l3.c:6:10: fatal error:linux/args.h: No such file or directoryThere is no
linux/args.hin v5.10.y.Caused by "interconnect: qcom: osm-l3: Replace custom implementation of
COUNT_ARGS()".
Now dropped, thanks.
greg k-h
Quoted 28 lines · Greg Kroah-Hartman
Quoted 27 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.201 release. There are 191 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, 17 Nov 2023 20:46:03 +0000. Anything received after that time might be too late.
Build results:
total: 159 pass: 155 fail: 4 Failed builds: arm:allmodconfig arm64:allmodconfig i386:tools/perf x86_64:tools/perf Qemu test results: total: 495 pass: 495 fail: 0with:
Building arm64:allmodconfig ... failed
--------------
Error log:drivers/interconnect/qcom/osm-l3.c:6:10: fatal error:linux/args.h: No such file or directory
Quoted 6 lines
Quoted 3 lines
There is no
linux/args.hin v5.10.y.Caused by "interconnect: qcom: osm-l3: Replace custom implementation of
COUNT_ARGS()".Now dropped, thanks.
v5.10.201 fails to build arm:allmodconfig and arm64:allmodconfig with
drivers/interconnect/qcom/sc7180.c:158:10: error: 'struct qcom_icc_bcm' has no member named 'enable_mask'
Guenter
Quoted 31 lines · Guenter Roeck
Quoted 30 lines · Greg Kroah-Hartman
Quoted 29 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.201 release. There are 191 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, 17 Nov 2023 20:46:03 +0000. Anything received after that time might be too late.
Build results:
total: 159 pass: 155 fail: 4
Failed builds:
arm:allmodconfig
arm64:allmodconfig
i386:tools/perf
x86_64:tools/perf
Qemu test results:
total: 495 pass: 495 fail: 0with:
Building arm64:allmodconfig ... failed
--------------
Error log:drivers/interconnect/qcom/osm-l3.c:6:10: fatal error:linux/args.h: No such file or directoryThere is no
linux/args.hin v5.10.y.
Quoted 9 lines
Quoted 4 lines
Quoted 1 line
Caused by "interconnect: qcom: osm-l3: Replace custom implementation of
COUNT_ARGS()".Now dropped, thanks.
v5.10.201 fails to build arm:allmodconfig and arm64:allmodconfig with
drivers/interconnect/qcom/sc7180.c:158:10: error: 'structqcom_icc_bcm' has no member named 'enable_mask'
Sam sent a note about that as well, probably got lost in the pile:
https://lore.kernel.org/stable/[email protected]/
Looks like it's missing a prerequisite patch.
-h
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 5.10.201 release. There are 191 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, 17 Nov 2023 20:46:03 +0000. Anything received after that time might be too late.
Build results:
total: 159 pass: 154 fail: 5 Failed builds: arm:allmodconfig arm64:allmodconfig i386:tools/perf x86_64:allyesconfig x86_64:tools/perf Qemu test results: total: 495 pass: 495 fail: 0
with:
Building arm64:allmodconfig ... failed
--------------
Error log:drivers/interconnect/qcom/osm-l3.c:6:10: fatal error: linux/args.h: No such file or directory
There is no linux/args.h in v5.10.y.
Caused by "interconnect: qcom: osm-l3: Replace custom implementation of COUNT_ARGS()".
Also:
Building i386:tools/perf ... failed
util/evlist.c: In function ‘evlist__add_aux_dummy’:util/evlist.c:269:24: error: implicit declaration of function ‘evlist__dummy_event’; did you mean ‘evsel__is_dummy_event’? [-Werror=implicit-function-declaration]
269 | struct evsel *evsel = evlist__dummy_event(evlist);
| ^~~~~~~~~~~~~~~~~~~
| evsel__is_dummy_eventutil/evlist.c:269:24: error: initialization of ‘struct evsel *’ from ‘int’ makes pointer from integer without a cast
There is indeed no 'evlist__dummy_event' function in v5.10.y.
This is with v5.10.200-192-g550b7e1fee20. I am a bit puzzled why others don't seem to see those problems.
Guenter
Hi!
Quoted 4 lines
This is the start of the stable review cycle for the 5.10.201 release. There are 191 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.
CIP testing did not find any problems here:
https://gitlab.com/cip-project/cip-testing/linux-stable-rc-ci/-/tree/linux-5.10.y
Best regards,
Pavel
Signature · 2 lines
DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany