4.19.295-rc1 review
Subsystems (13)
Greg Kroah-Hartman
maintainerPATCH 146/273 IB/uverbs: Fix an potential error pointer dereference
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xiang Yang <[email protected]>
[ Upstream commit 26b7d1a27167e7adf75b150755e05d2bc123ce55 ]
smatch reports the warning below:drivers/infiniband/core/uverbs_std_types_counters.c:110 ib_uverbs_handler_UVERBS_METHOD_COUNTERS_READ() error: 'uattr' dereferencing possible ERR_PTR()
The return value of uattr maybe ERR_PTR(-ENOENT), fix this by checking the value of uattr before using it.
--- drivers/infiniband/core/uverbs_std_types_counters.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/infiniband/core/uverbs_std_types_counters.c +2 -0
@@ -103,6 +103,8 @@ static int UVERBS_HANDLER(UVERBS_METHOD_COUNTERS_READ)(return ret; uattr =uverbs_attr_get (attrs,UVERBS_ATTR_READ_COUNTERS_BUFF ); +if (IS_ERR (uattr)) +return PTR_ERR (uattr); read_attr.ncounters = uattr->ptr_attr.len /sizeof (u64); read_attr.counters_buff =uverbs_zalloc ( attrs,array_size (read_attr.ncounters,sizeof (u64)));
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 147/273 media: go7007: Remove redundant if statement
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Colin Ian King <[email protected]>
[ Upstream commit f33cb49081da0ec5af0888f8ecbd566bd326eed1 ]
The if statement that compares msgs[i].len != 3 is always false because it is in a code block where msg[i].len is equal to 3. The check is redundant and can be removed.
As detected by cppcheck static analysis:drivers/media/usb/go7007/go7007-i2c.c:168:20: warning: Opposite inner 'if' condition leads to a dead code block. [oppositeInnerCondition]
--- drivers/media/usb/go7007/go7007-i2c.c | 2 -- 1 file changed, 2 deletions(-)
drivers/media/usb/go7007/go7007-i2c.c +0 -2
@@ -173,8 +173,6 @@ static int go7007_i2c_master_xfer(struct i2c_adapter *adapter, }else if (msgs[i].len ==3 ) {if (msgs[i].flags &I2C_M_RD )return -EIO ; -if (msgs[i].len !=3 ) -return -EIO ;if (go7007_i2c_xfer (go, msgs[i].addr,0 , (msgs[i].buf[0 ] <<8 ) | msgs[i].buf[1 ],0x01 , &msgs[i].buf[2 ]) <0 )
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 148/273 USB: gadget: f_mass_storage: Fix unused variable warning
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alan Stern <[email protected]>
[ Upstream commit 55c3e571d2a0aabef4f1354604443f1c415d2e85 ]
Fix a "variable set but not used" warning in f_mass_storage.c. rc is
used if verbose debugging is enabled but not otherwise.
--- drivers/usb/gadget/function/f_mass_storage.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/usb/gadget/function/f_mass_storage.c +1 -1
@@ -950,7 +950,7 @@ static void invalidate_sub(struct fsg_lun *curlun) {struct file *filp = curlun->filp;struct inode *inode =file_inode (filp); -unsigned long rc; +unsigned long __maybe_unused rc; rc =invalidate_mapping_pages (inode->i_mapping,0 ,-1 );VLDBG (curlun,"invalidate_mapping_pages -> %ld\n" , rc);
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 149/273 media: i2c: ov2680: Set V4L2_CTRL_FLAG_MODIFY_LAYOUT on flips
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Stevenson <[email protected]>
[ Upstream commit 66274280b2c745d380508dc27b9a4dfd736e5eda ]
The driver changes the Bayer order based on the flips, but does not define the control correctly with the V4L2_CTRL_FLAG_MODIFY_LAYOUT flag.
Add the V4L2_CTRL_FLAG_MODIFY_LAYOUT flag.
Stable-dep-of: 7b5a42e6ae71 ("media: ov2680: Remove auto-gain and auto-exposure controls")
--- drivers/media/i2c/ov2680.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/media/i2c/ov2680.c +2 -0
@@ -969,6 +969,8 @@ static int ov2680_v4l2_init(struct ov2680_dev *sensor) ctrls->gain->flags |=V4L2_CTRL_FLAG_VOLATILE ; ctrls->exposure->flags |=V4L2_CTRL_FLAG_VOLATILE ; + ctrls->vflip->flags |=V4L2_CTRL_FLAG_MODIFY_LAYOUT ; + ctrls->hflip->flags |=V4L2_CTRL_FLAG_MODIFY_LAYOUT ;v4l2_ctrl_auto_cluster (2 , &ctrls->auto_gain,0 , true);v4l2_ctrl_auto_cluster (2 , &ctrls->auto_exp,1 , true);
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 150/273 media: ov2680: Remove auto-gain and auto-exposure controls
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <[email protected]>
[ Upstream commit 7b5a42e6ae71927359ea67a2c22570ba97fa4059 ]
Quoting the OV2680 datasheet:
"3.2 exposure and gain control
In the OV2680, the exposure time and gain are set manually from an external controller. The OV2680 supports manual gain and exposure control only for normal applications, no auto mode."
And indeed testing with the atomisp_ov2680 fork of ov2680.c has shown that auto-exposure and auto-gain do not work.
Note that the code setting the auto-exposure flag was broken, callers of ov2680_exposure_set() were directly passing !!ctrls->auto_exp->val as "bool auto_exp" value, but ctrls->auto_exp is a menu control with:
enum v4l2_exposure_auto_type {
V4L2_EXPOSURE_AUTO = 0,
V4L2_EXPOSURE_MANUAL = 1,
...So instead of passing !!ctrls->auto_exp->val they should have been passing ctrls->auto_exp->val == V4L2_EXPOSURE_AUTO, iow the passed value was inverted of what it should have been.
Also remove ov2680_g_volatile_ctrl() since without auto support the gain and exposure controls are not volatile.
This also fixes the control values not being properly applied in ov2680_mode_set(). The 800x600 mode register-list also sets gain, exposure and vflip overriding the last set ctrl values.
ov2680_mode_set() does call ov2680_gain_set() and ov2680_exposure_set() but did this before writing the mode register-list, so these values would still be overridden by the mode register-list.
Add a v4l2_ctrl_handler_setup() call after writing the mode register-list to restore all ctrl values. Also remove the ctrls->gain->is_new check from ov2680_gain_set() so that the gain always gets restored properly.
Last since ov2680_mode_set() now calls v4l2_ctrl_handler_setup(), remove the v4l2_ctrl_handler_setup() call after ov2680_mode_restore() since ov2680_mode_restore() calls ov2680_mode_set().
--- drivers/media/i2c/ov2680.c | 161 ++++--------------------------------- 1 file changed, 17 insertions(+), 144 deletions(-)
drivers/media/i2c/ov2680.c +17 -144
@@ -85,15 +85,8 @@ struct ov2680_mode_info {struct ov2680_ctrls {struct v4l2_ctrl_handler handler; -struct { -struct v4l2_ctrl *auto_exp; -struct v4l2_ctrl *exposure; - }; -struct { -struct v4l2_ctrl *auto_gain; -struct v4l2_ctrl *gain; - }; - +struct v4l2_ctrl *exposure; +struct v4l2_ctrl *gain;struct v4l2_ctrl *hflip;struct v4l2_ctrl *vflip;struct v4l2_ctrl *test_pattern;
@@ -143,6 +136,7 @@ static const struct reg_value ov2680_setting_30fps_QUXGA_800_600[] = { {0x380e, 0x02}, {0x380f, 0x84}, {0x3811, 0x04}, {0x3813, 0x04}, {0x3814, 0x31}, {0x3815, 0x31}, {0x3820, 0xc0}, {0x4008, 0x00}, {0x4009, 0x03}, {0x4837, 0x1e}, {0x3501, 0x4e}, {0x3502, 0xe0}, + {0x3503, 0x03}, }; static const struct reg_value ov2680_setting_30fps_720P_1280_720[] = {
@@ -405,69 +399,15 @@ static int ov2680_test_pattern_set(struct ov2680_dev *sensor, int value)return 0 ; } -static int ov2680_gain_set (struct ov2680_dev *sensor,bool auto_gain) -{ -struct ov2680_ctrls *ctrls = &sensor->ctrls; -u32 gain; -int ret; - - ret =ov2680_mod_reg (sensor,OV2680_REG_R_MANUAL ,BIT (1 ), - auto_gain ?0 :BIT (1 )); -if (ret <0 ) -return ret; - -if (auto_gain || !ctrls->gain->is_new) -return 0 ; - - gain = ctrls->gain->val; - - ret =ov2680_write_reg16 (sensor,OV2680_REG_GAIN_PK , gain); - -return 0 ; -} - -static int ov2680_gain_get (struct ov2680_dev *sensor) -{ -u32 gain; -int ret; - - ret =ov2680_read_reg16 (sensor,OV2680_REG_GAIN_PK , &gain); -if (ret) -return ret; - -return gain; -} - -static int ov2680_exposure_set (struct ov2680_dev *sensor,bool auto_exp) +static int ov2680_gain_set (struct ov2680_dev *sensor,u32 gain) { -struct ov2680_ctrls *ctrls = &sensor->ctrls; -u32 exp; -int ret; - - ret =ov2680_mod_reg (sensor,OV2680_REG_R_MANUAL ,BIT (0 ), - auto_exp ?0 :BIT (0 )); -if (ret <0 ) -return ret; - -if (auto_exp || !ctrls->exposure->is_new) -return 0 ; - - exp = (u32 )ctrls->exposure->val; - exp <<=4 ; - -return ov2680_write_reg24 (sensor,OV2680_REG_EXPOSURE_PK_HIGH , exp); +return ov2680_write_reg16 (sensor,OV2680_REG_GAIN_PK , gain); } -static int ov2680_exposure_get (struct ov2680_dev *sensor) +static int ov2680_exposure_set (struct ov2680_dev *sensor,u32 exp) { -int ret; -u32 exp; - - ret =ov2680_read_reg24 (sensor,OV2680_REG_EXPOSURE_PK_HIGH , &exp); -if (ret) -return ret; - -return exp >>4 ; +return ov2680_write_reg24 (sensor,OV2680_REG_EXPOSURE_PK_HIGH , + exp <<4 ); }static int ov2680_stream_enable (struct ov2680_dev *sensor)
@@ -482,33 +422,17 @@ static int ov2680_stream_disable(struct ov2680_dev *sensor)static int ov2680_mode_set (struct ov2680_dev *sensor) { -struct ov2680_ctrls *ctrls = &sensor->ctrls;int ret; - ret =ov2680_gain_set (sensor, false); -if (ret <0 ) -return ret; - - ret =ov2680_exposure_set (sensor, false); + ret =ov2680_load_regs (sensor, sensor->current_mode);if (ret <0 )return ret; - ret =ov2680_load_regs (sensor, sensor->current_mode); +/* Restore value of all ctrls */ + ret =__v4l2_ctrl_handler_setup (&sensor->ctrls.handler);if (ret <0 )return ret; -if (ctrls->auto_gain->val) { - ret =ov2680_gain_set (sensor, true); -if (ret <0 ) -return ret; - } - -if (ctrls->auto_exp->val ==V4L2_EXPOSURE_AUTO ) { - ret =ov2680_exposure_set (sensor, true); -if (ret <0 ) -return ret; - } - sensor->mode_pending_changes = false;return 0 ;
@@ -590,15 +514,10 @@ static int ov2680_s_power(struct v4l2_subdev *sd, int on)else ret =ov2680_power_off (sensor); -mutex_unlock (&sensor->lock); - -if (on && ret ==0 ) { - ret =v4l2_ctrl_handler_setup (&sensor->ctrls.handler); -if (ret <0 ) -return ret; - +if (on && ret ==0 ) ret =ov2680_mode_restore (sensor); - } + +mutex_unlock (&sensor->lock);return ret; }
@@ -796,52 +715,19 @@ static int ov2680_enum_frame_interval(struct v4l2_subdev *sd,return 0 ; } -static int ov2680_g_volatile_ctrl (struct v4l2_ctrl *ctrl) -{ -struct v4l2_subdev *sd =ctrl_to_sd (ctrl); -struct ov2680_dev *sensor =to_ov2680_dev (sd); -struct ov2680_ctrls *ctrls = &sensor->ctrls; -int val; - -if (!sensor->is_enabled) -return 0 ; - -switch (ctrl->id) { -case V4L2_CID_GAIN : - val =ov2680_gain_get (sensor); -if (val <0 ) -return val; - ctrls->gain->val = val; -break ; -case V4L2_CID_EXPOSURE : - val =ov2680_exposure_get (sensor); -if (val <0 ) -return val; - ctrls->exposure->val = val; -break ; - } - -return 0 ; -} -static int ov2680_s_ctrl (struct v4l2_ctrl *ctrl) {struct v4l2_subdev *sd =ctrl_to_sd (ctrl);struct ov2680_dev *sensor =to_ov2680_dev (sd); -struct ov2680_ctrls *ctrls = &sensor->ctrls;if (!sensor->is_enabled)return 0 ;switch (ctrl->id) { -case V4L2_CID_AUTOGAIN : -return ov2680_gain_set (sensor, !!ctrl->val);case V4L2_CID_GAIN : -return ov2680_gain_set (sensor, !!ctrls->auto_gain->val); -case V4L2_CID_EXPOSURE_AUTO : -return ov2680_exposure_set (sensor, !!ctrl->val); +return ov2680_gain_set (sensor, ctrl->val);case V4L2_CID_EXPOSURE : -return ov2680_exposure_set (sensor, !!ctrls->auto_exp->val); +return ov2680_exposure_set (sensor, ctrl->val);case V4L2_CID_VFLIP :if (sensor->is_streaming)return -EBUSY ;
@@ -866,7 +752,6 @@ static int ov2680_s_ctrl(struct v4l2_ctrl *ctrl) }static const struct v4l2_ctrl_ops ov2680_ctrl_ops = { - .g_volatile_ctrl = ov2680_g_volatile_ctrl, .s_ctrl = ov2680_s_ctrl, };
@@ -938,7 +823,7 @@ static int ov2680_v4l2_init(struct ov2680_dev *sensor)if (ret <0 )return ret; -v4l2_ctrl_handler_init (hdl,7 ); +v4l2_ctrl_handler_init (hdl,5 ); hdl->lock = &sensor->lock;
@@ -950,16 +835,9 @@ static int ov2680_v4l2_init(struct ov2680_dev *sensor)ARRAY_SIZE (test_pattern_menu) -1 , 0, 0, test_pattern_menu); - ctrls->auto_exp =v4l2_ctrl_new_std_menu (hdl, ops, -V4L2_CID_EXPOSURE_AUTO , -V4L2_EXPOSURE_MANUAL ,0 , -V4L2_EXPOSURE_AUTO ); - ctrls->exposure =v4l2_ctrl_new_std (hdl, ops,V4L2_CID_EXPOSURE ,0 ,32767 ,1 ,0 ); - ctrls->auto_gain =v4l2_ctrl_new_std (hdl, ops,V4L2_CID_AUTOGAIN , -0 ,1 ,1 ,1 ); ctrls->gain =v4l2_ctrl_new_std (hdl, ops,V4L2_CID_GAIN ,0 ,2047 ,1 ,0 );if (hdl->error) {
@@ -967,14 +845,9 @@ static int ov2680_v4l2_init(struct ov2680_dev *sensor) goto cleanup_entity; } - ctrls->gain->flags |=V4L2_CTRL_FLAG_VOLATILE ; - ctrls->exposure->flags |=V4L2_CTRL_FLAG_VOLATILE ; ctrls->vflip->flags |=V4L2_CTRL_FLAG_MODIFY_LAYOUT ; ctrls->hflip->flags |=V4L2_CTRL_FLAG_MODIFY_LAYOUT ; -v4l2_ctrl_auto_cluster (2 , &ctrls->auto_gain,0 , true); -v4l2_ctrl_auto_cluster (2 , &ctrls->auto_exp,1 , true); - sensor->sd.ctrl_handler = hdl; ret =v4l2_async_register_subdev (&sensor->sd);
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 151/273 media: ov2680: Fix ov2680_bayer_order()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <[email protected]>
[ Upstream commit 50a7bad4e0a37d7018ab6fe843dd84bc6b2ecf72 ]
The index into ov2680_hv_flip_bayer_order[] should be 0-3, but ov2680_bayer_order() was using 0 + BIT(2) + (BIT(2) << 1) as max index, while the intention was to use: 0 + 1 + 2 as max index.
Fix the index calculation in ov2680_bayer_order(), while at it also just use the ctrl values rather then reading them back using a slow i2c-read transaction.
This also allows making the function void, since there now are no more i2c-reads to error check.
Note the check for the ctrls being NULL is there to allow adding an ov2680_fill_format() helper later, which will call ov2680_set_bayer_order() during probe() before the ctrls are created.
[Sakari Ailus: Change all users of ov2680_set_bayer_order() here]
--- drivers/media/i2c/ov2680.c | 33 ++++++++++++++------------------- 1 file changed, 14 insertions(+), 19 deletions(-)
drivers/media/i2c/ov2680.c +14 -19
@@ -315,26 +315,17 @@ static void ov2680_power_down(struct ov2680_dev *sensor)usleep_range (5000 ,10000 ); } -static int ov2680_bayer_order (struct ov2680_dev *sensor) +static void ov2680_set_bayer_order (struct ov2680_dev *sensor) { -u32 format1; -u32 format2; -u32 hv_flip; -int ret; - - ret =ov2680_read_reg (sensor,OV2680_REG_FORMAT1 , &format1); -if (ret <0 ) -return ret; +int hv_flip =0 ; - ret =ov2680_read_reg (sensor,OV2680_REG_FORMAT2 , &format2); -if (ret <0 ) -return ret; +if (sensor->ctrls.vflip && sensor->ctrls.vflip->val) + hv_flip +=1 ; - hv_flip = (format2 &BIT (2 ) <<1 ) | (format1 &BIT (2 )); +if (sensor->ctrls.hflip && sensor->ctrls.hflip->val) + hv_flip +=2 ; sensor->fmt.code = ov2680_hv_flip_bayer_order[hv_flip]; - -return 0 ; }static int ov2680_vflip_enable (struct ov2680_dev *sensor)
@@ -345,7 +336,8 @@ static int ov2680_vflip_enable(struct ov2680_dev *sensor)if (ret <0 )return ret; -return ov2680_bayer_order (sensor); +ov2680_set_bayer_order (sensor); +return 0 ; }static int ov2680_vflip_disable (struct ov2680_dev *sensor)
@@ -356,7 +348,8 @@ static int ov2680_vflip_disable(struct ov2680_dev *sensor)if (ret <0 )return ret; -return ov2680_bayer_order (sensor); +ov2680_set_bayer_order (sensor); +return 0 ; }static int ov2680_hflip_enable (struct ov2680_dev *sensor)
@@ -367,7 +360,8 @@ static int ov2680_hflip_enable(struct ov2680_dev *sensor)if (ret <0 )return ret; -return ov2680_bayer_order (sensor); +ov2680_set_bayer_order (sensor); +return 0 ; }static int ov2680_hflip_disable (struct ov2680_dev *sensor)
@@ -378,7 +372,8 @@ static int ov2680_hflip_disable(struct ov2680_dev *sensor)if (ret <0 )return ret; -return ov2680_bayer_order (sensor); +ov2680_set_bayer_order (sensor); +return 0 ; }static int ov2680_test_pattern_set (struct ov2680_dev *sensor,int value)
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 152/273 media: ov2680: Fix vflip / hflip set functions
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <[email protected]>
[ Upstream commit d5d08ad330c9ccebc5e066fda815423a290f48b0 ]
ov2680_vflip_disable() / ov2680_hflip_disable() pass BIT(0) instead of 0 as value to ov2680_mod_reg().
While fixing this also:
1. Stop having separate enable/disable functions for hflip / vflip
2. Move the is_streaming check, which is unique to hflip / vflip into the ov2680_set_?flip() functions.
for a nice code cleanup.
--- drivers/media/i2c/ov2680.c | 50 +++++++++----------------------------- 1 file changed, 12 insertions(+), 38 deletions(-)
drivers/media/i2c/ov2680.c +12 -38
@@ -328,23 +328,15 @@ static void ov2680_set_bayer_order(struct ov2680_dev *sensor) sensor->fmt.code = ov2680_hv_flip_bayer_order[hv_flip]; } -static int ov2680_vflip_enable (struct ov2680_dev *sensor) +static int ov2680_set_vflip (struct ov2680_dev *sensor,s32 val) {int ret; - ret =ov2680_mod_reg (sensor,OV2680_REG_FORMAT1 ,BIT (2 ),BIT (2 )); -if (ret <0 ) -return ret; - -ov2680_set_bayer_order (sensor); -return 0 ; -} - -static int ov2680_vflip_disable (struct ov2680_dev *sensor) -{ -int ret; +if (sensor->is_streaming) +return -EBUSY ; - ret =ov2680_mod_reg (sensor,OV2680_REG_FORMAT1 ,BIT (2 ),BIT (0 )); + ret =ov2680_mod_reg (sensor,OV2680_REG_FORMAT1 , +BIT (2 ), val ?BIT (2 ) :0 );if (ret <0 )return ret;
@@ -352,23 +344,15 @@ static int ov2680_vflip_disable(struct ov2680_dev *sensor)return 0 ; } -static int ov2680_hflip_enable (struct ov2680_dev *sensor) +static int ov2680_set_hflip (struct ov2680_dev *sensor,s32 val) {int ret; - ret =ov2680_mod_reg (sensor,OV2680_REG_FORMAT2 ,BIT (2 ),BIT (2 )); -if (ret <0 ) -return ret; - -ov2680_set_bayer_order (sensor); -return 0 ; -} - -static int ov2680_hflip_disable (struct ov2680_dev *sensor) -{ -int ret; +if (sensor->is_streaming) +return -EBUSY ; - ret =ov2680_mod_reg (sensor,OV2680_REG_FORMAT2 ,BIT (2 ),BIT (0 )); + ret =ov2680_mod_reg (sensor,OV2680_REG_FORMAT2 , +BIT (2 ), val ?BIT (2 ) :0 );if (ret <0 )return ret;
@@ -724,19 +708,9 @@ static int ov2680_s_ctrl(struct v4l2_ctrl *ctrl)case V4L2_CID_EXPOSURE :return ov2680_exposure_set (sensor, ctrl->val);case V4L2_CID_VFLIP : -if (sensor->is_streaming) -return -EBUSY ; -if (ctrl->val) -return ov2680_vflip_enable (sensor); -else -return ov2680_vflip_disable (sensor); +return ov2680_set_vflip (sensor, ctrl->val);case V4L2_CID_HFLIP : -if (sensor->is_streaming) -return -EBUSY ; -if (ctrl->val) -return ov2680_hflip_enable (sensor); -else -return ov2680_hflip_disable (sensor); +return ov2680_set_hflip (sensor, ctrl->val);case V4L2_CID_TEST_PATTERN :return ov2680_test_pattern_set (sensor, ctrl->val);default :
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 153/273 media: ov2680: Fix regulators being left enabled on ov2680_power_on() errors
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans de Goede <[email protected]>
[ Upstream commit 84b4bd7e0d98166aa32fd470e672721190492eae ]
When the ov2680_power_on() "sensor soft reset failed" path is hit during probe() the WARN() about putting an enabled regulator at drivers/regulator/core.c:2398 triggers 3 times (once for each regulator), filling dmesg with backtraces.
Fix this by properly disabling the regulators on ov2680_power_on() errors.
--- drivers/media/i2c/ov2680.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
drivers/media/i2c/ov2680.c +6 -2
@@ -459,7 +459,7 @@ static int ov2680_power_on(struct ov2680_dev *sensor) ret =ov2680_write_reg (sensor,OV2680_REG_SOFT_RESET ,0x01 );if (ret !=0 ) {dev_err (dev,"sensor soft reset failed\n" ); -return ret; + goto err_disable_regulators; }usleep_range (1000 ,2000 ); }else {
@@ -469,7 +469,7 @@ static int ov2680_power_on(struct ov2680_dev *sensor) ret =clk_prepare_enable (sensor->xvclk);if (ret <0 ) -return ret; + goto err_disable_regulators; sensor->is_enabled = true;
@@ -479,6 +479,10 @@ static int ov2680_power_on(struct ov2680_dev *sensor)ov2680_stream_disable (sensor);return 0 ; + +err_disable_regulators: +regulator_bulk_disable (OV2680_NUM_SUPPLIES , sensor->supplies); +return ret; }static int ov2680_s_power (struct v4l2_subdev *sd,int on)
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 154/273 cgroup:namespace: Remove unused cgroup_namespaces_init()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lu Jialin <[email protected]>
[ Upstream commit 82b90b6c5b38e457c7081d50dff11ecbafc1e61a ]
cgroup_namspace_init() just return 0. Therefore, there is no need to call it during start_kernel. Just remove it.
--- kernel/cgroup/namespace.c | 6 ------ 1 file changed, 6 deletions(-)
kernel/cgroup/namespace.c +0 -6
@@ -148,9 +148,3 @@ const struct proc_ns_operations cgroupns_operations = { .install = cgroupns_install, .owner = cgroupns_owner, }; - -static __init int cgroup_namespaces_init (void ) -{ -return 0 ; -} -subsys_initcall (cgroup_namespaces_init);
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 155/273 scsi: core: Use 32-bit hostnum in scsi_host_lookup()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tony Battersby <[email protected]>
[ Upstream commit 62ec2092095b678ff89ce4ba51c2938cd1e8e630 ]
Change scsi_host_lookup() hostnum argument type from unsigned short to unsigned int to match the type used everywhere else.
--- drivers/scsi/hosts.c | 4 ++-- include/scsi/scsi_host.h | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-)
drivers/scsi/hosts.c +2 -2
@@ -532,7 +532,7 @@ EXPORT_SYMBOL(scsi_host_alloc);static int __scsi_host_match (struct device *dev,const void *data) {struct Scsi_Host *p; -const unsigned short *hostnum = data; +const unsigned int *hostnum = data; p =class_to_shost (dev);return p->host_no == *hostnum;
@@ -549,7 +549,7 @@ static int __scsi_host_match(struct device *dev, const void *data)* that scsi_host_get() took. The put_device() below dropped * the reference from class_find_device(). **/ -struct Scsi_Host *scsi_host_lookup (unsigned short hostnum) +struct Scsi_Host *scsi_host_lookup (unsigned int hostnum) {struct device *cdev;struct Scsi_Host *shost =NULL ;
include/scsi/scsi_host.h +1 -1
@@ -760,7 +760,7 @@ extern void scsi_remove_host(struct Scsi_Host *);extern struct Scsi_Host *scsi_host_get (struct Scsi_Host *);extern int scsi_host_busy (struct Scsi_Host *shost);extern void scsi_host_put (struct Scsi_Host *t); -extern struct Scsi_Host *scsi_host_lookup (unsigned short ); +extern struct Scsi_Host *scsi_host_lookup (unsigned int hostnum);extern const char *scsi_host_state_name (enum scsi_host_state );extern void scsi_cmd_get_serial (struct Scsi_Host *,struct scsi_cmnd *);
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 156/273 scsi: fcoe: Fix potential deadlock on &fip->ctlr_lock
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chengfeng Ye <[email protected]>
[ Upstream commit 1a1975551943f681772720f639ff42fbaa746212 ]
There is a long call chain that &fip->ctlr_lock is acquired by isr fnic_isr_msix_wq_copy() under hard IRQ context. Thus other process context code acquiring the lock should disable IRQ, otherwise deadlock could happen if the IRQ preempts the execution while the lock is held in process context on the same CPU.
[ISR]fnic_isr_msix_wq_copy()
-> fnic_wq_copy_cmpl_handler()
-> fnic_fcpio_cmpl_handler()
-> fnic_fcpio_flogi_reg_cmpl_handler()
-> fnic_flush_tx()
-> fnic_send_frame()
-> fcoe_ctlr_els_send()
-> spin_lock_bh(&fip->ctlr_lock)
[Process Context]
1. fcoe_ctlr_timer_work()
-> fcoe_ctlr_flogi_send()
-> spin_lock_bh(&fip->ctlr_lock)
2. fcoe_ctlr_recv_work()
-> fcoe_ctlr_recv_handler()
-> fcoe_ctlr_recv_els()
-> fcoe_ctlr_announce()
-> spin_lock_bh(&fip->ctlr_lock)
3. fcoe_ctlr_recv_work()
-> fcoe_ctlr_recv_handler()
-> fcoe_ctlr_recv_els()
-> fcoe_ctlr_flogi_retry()
-> spin_lock_bh(&fip->ctlr_lock)
4. -> fcoe_xmit()
-> fcoe_ctlr_els_send()
-> spin_lock_bh(&fip->ctlr_lock)
spin_lock_bh() is not enough since fnic_isr_msix_wq_copy() is a hardirq.
These flaws were found by an experimental static analysis tool I am developing for irq-related deadlock.
The patch fix the potential deadlocks by spin_lock_irqsave() to disable hard irq.
--- drivers/scsi/fcoe/fcoe_ctlr.c | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-)
drivers/scsi/fcoe/fcoe_ctlr.c +12 -8
@@ -330,16 +330,17 @@ static void fcoe_ctlr_announce(struct fcoe_ctlr *fip) {struct fcoe_fcf *sel;struct fcoe_fcf *fcf; +unsigned long flags;mutex_lock (&fip->ctlr_mutex); -spin_lock_bh (&fip->ctlr_lock); +spin_lock_irqsave (&fip->ctlr_lock, flags);kfree_skb (fip->flogi_req); fip->flogi_req =NULL ;list_for_each_entry (fcf, &fip->fcfs, list) fcf->flogi_sent =0 ; -spin_unlock_bh (&fip->ctlr_lock); +spin_unlock_irqrestore (&fip->ctlr_lock, flags); sel = fip->sel_fcf;if (sel &ðer_addr_equal (sel->fcf_mac, fip->dest_addr))
@@ -709,6 +710,7 @@ int fcoe_ctlr_els_send(struct fcoe_ctlr *fip, struct fc_lport *lport, {struct fc_frame *fp;struct fc_frame_header *fh; +unsigned long flags;u16 old_xid;u8 op;u8 mac[ETH_ALEN ];
@@ -742,11 +744,11 @@ int fcoe_ctlr_els_send(struct fcoe_ctlr *fip, struct fc_lport *lport, op =FIP_DT_FLOGI ;if (fip->mode ==FIP_MODE_VN2VN )break ; -spin_lock_bh (&fip->ctlr_lock); +spin_lock_irqsave (&fip->ctlr_lock, flags);kfree_skb (fip->flogi_req); fip->flogi_req = skb; fip->flogi_req_send =1 ; -spin_unlock_bh (&fip->ctlr_lock); +spin_unlock_irqrestore (&fip->ctlr_lock, flags);schedule_work (&fip->timer_work);return -EINPROGRESS ;case ELS_FDISC :
@@ -1723,10 +1725,11 @@ static int fcoe_ctlr_flogi_send_locked(struct fcoe_ctlr *fip)static int fcoe_ctlr_flogi_retry (struct fcoe_ctlr *fip) {struct fcoe_fcf *fcf; +unsigned long flags;int error;mutex_lock (&fip->ctlr_mutex); -spin_lock_bh (&fip->ctlr_lock); +spin_lock_irqsave (&fip->ctlr_lock, flags);LIBFCOE_FIP_DBG (fip,"re-sending FLOGI - reselect\n" ); fcf =fcoe_ctlr_select (fip);if (!fcf || fcf->flogi_sent) {
@@ -1737,7 +1740,7 @@ static int fcoe_ctlr_flogi_retry(struct fcoe_ctlr *fip)fcoe_ctlr_solicit (fip,NULL ); error =fcoe_ctlr_flogi_send_locked (fip); } -spin_unlock_bh (&fip->ctlr_lock); +spin_unlock_irqrestore (&fip->ctlr_lock, flags);mutex_unlock (&fip->ctlr_mutex);return error; }
@@ -1754,8 +1757,9 @@ static int fcoe_ctlr_flogi_retry(struct fcoe_ctlr *fip)static void fcoe_ctlr_flogi_send (struct fcoe_ctlr *fip) {struct fcoe_fcf *fcf; +unsigned long flags; -spin_lock_bh (&fip->ctlr_lock); +spin_lock_irqsave (&fip->ctlr_lock, flags); fcf = fip->sel_fcf;if (!fcf || !fip->flogi_req_send) goto unlock;
@@ -1782,7 +1786,7 @@ static void fcoe_ctlr_flogi_send(struct fcoe_ctlr *fip) }else /* XXX */ LIBFCOE_FIP_DBG (fip,"No FCF selected - defer send\n" ); unlock: -spin_unlock_bh (&fip->ctlr_lock); +spin_unlock_irqrestore (&fip->ctlr_lock, flags); }/**
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 157/273 serial: tegra: handle clk prepare error in tegra_uart_hw_init()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yi Yang <[email protected]>
[ Upstream commit 5abd01145d0cc6cd1b7c2fe6ee0b9ea0fa13671e ]
In tegra_uart_hw_init(), the return value of clk_prepare_enable() should be checked since it might fail.
--- drivers/tty/serial/serial-tegra.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/tty/serial/serial-tegra.c +5 -1
@@ -944,7 +944,11 @@ static int tegra_uart_hw_init(struct tegra_uart_port *tup) tup->ier_shadow =0 ; tup->current_baud =0 ; -clk_prepare_enable (tup->uart_clk); + ret =clk_prepare_enable (tup->uart_clk); +if (ret) { +dev_err (tup->uport.dev,"could not enable clk\n" ); +return ret; + }/* Reset the UART controller to clear all previous status.*/ reset_control_assert (tup->rst);
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 158/273 amba: bus: fix refcount leak
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Peng Fan <[email protected]>
[ Upstream commit e312cbdc11305568554a9e18a2ea5c2492c183f3 ]
commit 5de1540b7bc4 ("drivers/amba: create devices from device tree") increases the refcount of of_node, but not releases it in amba_device_release, so there is refcount leak. By using of_node_put to avoid refcount leak.
--- drivers/amba/bus.c | 1 + 1 file changed, 1 insertion(+)
drivers/amba/bus.c +1 -0
@@ -349,6 +349,7 @@ static void amba_device_release(struct device *dev) {struct amba_device *d =to_amba_device (dev); +of_node_put (d->dev.of_node);if (d->res.parent)release_resource (&d->res);kfree (d);
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 159/273 Revert "IB/isert: Fix incorrect release of isert connection"
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Leon Romanovsky <[email protected]>
[ Upstream commit dfe261107c080709459c32695847eec96238852b ]
Commit: 699826f4e30a ("IB/isert: Fix incorrect release of isert connection") is causing problems on OPA when DEVICE_REMOVAL is happening.
------------[ cut here ]------------ WARNING: CPU: 52 PID: 2117247 at drivers/infiniband/core/cq.c:359 ib_cq_pool_cleanup+0xac/0xb0 [ib_core] Modules linked in: nfsd nfs_acl target_core_user uio tcm_fc libfc
scsi_transport_fc tcm_loop target_core_pscsi target_core_iblock target_core_file rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs rfkill rpcrdma rdma_ucm ib_srpt sunrpc ib_isert iscsi_target_mod target_core_mod opa_vnic ib_iser libiscsi ib_umad scsi_transport_iscsi rdma_cm ib_ipoib iw_cm ib_cm hfi1(-) rdmavt ib_uverbs intel_rapl_msr intel_rapl_common sb_edac ib_core x86_pkg_temp_thermal intel_powerclamp coretemp i2c_i801 mxm_wmi rapl iTCO_wdt ipmi_si iTCO_vendor_support mei_me ipmi_devintf mei intel_cstate ioatdma intel_uncore i2c_smbus joydev pcspkr lpc_ich ipmi_msghandler acpi_power_meter acpi_pad xfs libcrc32c sr_mod sd_mod cdrom t10_pi sg crct10dif_pclmul crc32_pclmul crc32c_intel drm_kms_helper drm_shmem_helper ahci libahci ghash_clmulni_intel igb drm libata dca i2c_algo_bit wmi fuse
CPU: 52 PID: 2117247 Comm: modprobe Not tainted 6.5.0-rc1+ #1 Hardware name: Intel Corporation S2600CWR/S2600CW, BIOS SE5C610.86B.01.01.0014.121820151719 12/18/2015 RIP: 0010:ib_cq_pool_cleanup+0xac/0xb0 [ib_core] Code: ff 48 8b 43 40 48 8d 7b 40 48 83 e8 40 4c 39 e7 75 b3 49 83
c4 10 4d 39 fc 75 94 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc <0f> 0b eb a1 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f
RSP: 0018:ffffc10bea13fc80 EFLAGS: 00010206
RAX: 000000000000010c RBX: ffff9bf5c7e66c00 RCX: 000000008020001d
RDX: 000000008020001e RSI: fffff175221f9900 RDI: ffff9bf5c7e67640
RBP: ffff9bf5c7e67600 R08: ffff9bf5c7e64400 R09: 000000008020001d
R10: 0000000040000000 R11: 0000000000000000 R12: ffff9bee4b1e8a18
R13: dead000000000122 R14: dead000000000100 R15: ffff9bee4b1e8a38
FS: 00007ff1e6d38740(0000) GS:ffff9bfd9fb00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005652044ecc68 CR3: 0000000889b5c005 CR4: 00000000001706e0
Call Trace: <TASK> ? __warn+0x80/0x130 ? ib_cq_pool_cleanup+0xac/0xb0 [ib_core] ? report_bug+0x195/0x1a0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? ib_cq_pool_cleanup+0xac/0xb0 [ib_core] disable_device+0x9d/0x160 [ib_core] __ib_unregister_device+0x42/0xb0 [ib_core] ib_unregister_device+0x22/0x30 [ib_core] rvt_unregister_device+0x20/0x90 [rdmavt] hfi1_unregister_ib_device+0x16/0xf0 [hfi1] remove_one+0x55/0x1a0 [hfi1] pci_device_remove+0x36/0xa0 device_release_driver_internal+0x193/0x200 driver_detach+0x44/0x90 bus_remove_driver+0x69/0xf0 pci_unregister_driver+0x2a/0xb0 hfi1_mod_cleanup+0xc/0x3c [hfi1] __do_sys_delete_module.constprop.0+0x17a/0x2f0 ? exit_to_user_mode_prepare+0xc4/0xd0 ? syscall_trace_enter.constprop.0+0x126/0x1a0 do_syscall_64+0x5c/0x90 ? syscall_exit_to_user_mode+0x12/0x30 ? do_syscall_64+0x69/0x90 ? syscall_exit_work+0x103/0x130 ? syscall_exit_to_user_mode+0x12/0x30 ? do_syscall_64+0x69/0x90 ? exc_page_fault+0x65/0x150 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7ff1e643f5ab Code: 73 01 c3 48 8b 0d 75 a8 1b 00 f7 d8 64 89 01 48 83 c8 ff c3
66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 45 a8 1b 00 f7 d8 64 89 01 48
RSP: 002b:00007ffec9103cc8 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
RAX: ffffffffffffffda RBX: 00005615267fdc50 RCX: 00007ff1e643f5ab
RDX: 0000000000000000 RSI: 0000000000000800 RDI: 00005615267fdcb8
RBP: 00005615267fdc50 R08: 0000000000000000 R09: 0000000000000000
R10: 00007ff1e659eac0 R11: 0000000000000206 R12: 00005615267fdcb8
R13: 0000000000000000 R14: 00005615267fdcb8 R15: 00007ffec9105ff8
</TASK> ---[ end trace 0000000000000000 ]---
And...
restrack: ------------[ cut here ]------------ infiniband hfi1_0: BUG: RESTRACK detected leak of resources
restrack: Kernel PD object allocated by ib_isert is not freed
restrack: Kernel CQ object allocated by ib_core is not freed
restrack: Kernel QP object allocated by rdma_cm is not freed
restrack: ------------[ cut here ]------------
--- drivers/infiniband/ulp/isert/ib_isert.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/infiniband/ulp/isert/ib_isert.c +2 -0
@@ -2654,6 +2654,8 @@ static void isert_wait_conn(struct iscsi_conn *conn)isert_put_unsol_pending_cmds (conn);isert_wait4cmds (conn);isert_wait4logout (isert_conn); + +queue_work (isert_release_wq, &isert_conn->release_work); }static void isert_free_conn (struct iscsi_conn *conn)
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 160/273 HID: multitouch: Correct devm device reference for hidinput input_dev name
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rahul Rameshbabu <[email protected]>
[ Upstream commit 4794394635293a3e74591351fff469cea7ad15a2 ]
Reference the HID device rather than the input device for the devm allocation of the input_dev name. Referencing the input_dev would lead to a use-after-free when the input_dev was unregistered and subsequently fires a uevent that depends on the name. At the point of firing the uevent, the name would be freed by devres management.
Use devm_kasprintf to simplify the logic for allocating memory and formatting the input_dev name string.
--- drivers/hid/hid-multitouch.c | 13 +++---------- 1 file changed, 3 insertions(+), 10 deletions(-)
drivers/hid/hid-multitouch.c +3 -10
@@ -1540,7 +1540,6 @@ static void mt_post_parse(struct mt_device *td, struct mt_application *app)static int mt_input_configured (struct hid_device *hdev,struct hid_input *hi) {struct mt_device *td =hid_get_drvdata (hdev); -char *name;const char *suffix =NULL ;struct mt_report_data *rdata;struct mt_application *mt_application =NULL ;
@@ -1594,15 +1593,9 @@ static int mt_input_configured(struct hid_device *hdev, struct hid_input *hi)break ; } -if (suffix) { - name =devm_kzalloc (&hi->input->dev, -strlen (hdev->name) +strlen (suffix) +2 , -GFP_KERNEL ); -if (name) { -sprintf (name,"%s %s" , hdev->name, suffix); - hi->input->name = name; - } - } +if (suffix) + hi->input->name =devm_kasprintf (&hdev->dev,GFP_KERNEL , +"%s %s" , hdev->name, suffix);return 0 ; }
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 161/273 rpmsg: glink: Add check for kstrdup
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiasheng Jiang <[email protected]>
[ Upstream commit b5c9ee8296a3760760c7b5d2e305f91412adc795 ]
Add check for the return value of kstrdup() and return the error if it fails in order to avoid NULL pointer dereference.
--- drivers/rpmsg/qcom_glink_native.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/rpmsg/qcom_glink_native.c +4 -0
@@ -222,6 +222,10 @@ static struct glink_channel *qcom_glink_alloc_channel(struct qcom_glink *glink, channel->glink = glink; channel->name =kstrdup (name,GFP_KERNEL ); +if (!channel->name) { +kfree (channel); +return ERR_PTR (-ENOMEM ); + }init_completion (&channel->open_req);init_completion (&channel->open_ack);
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 162/273 arch: um: drivers: Kconfig: pedantic formatting
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Enrico Weigelt, metux IT consult <[email protected]>
[ Upstream commit 75f24f78721048a271e2e50a563f51bcfd6f5c1c ]
Formatting of Kconfig files doesn't look so pretty, so just take damp cloth and clean it up. Just indention changes.
Stable-dep-of: db4bfcba7bb8 ("um: Fix hostaudio build errors")
--- arch/um/drivers/Kconfig | 352 ++++++++++++++++++++-------------------- 1 file changed, 176 insertions(+), 176 deletions(-)
arch/um/drivers/Kconfig +176 -176
@@ -11,58 +11,58 @@ config STDERR_CONSOLE config SSL bool "Virtual serial line" help - The User-Mode Linux environment allows you to create virtual serial - lines on the UML that are usually made to show up on the host as - ttys or ptys. + The User-Mode Linux environment allows you to create virtual serial + lines on the UML that are usually made to show up on the host as + ttys or ptys. - See <http://user-mode-linux.sourceforge.net/old/input.html> for more - information and command line examples of how to use this facility. + See <http://user-mode-linux.sourceforge.net/old/input.html> for more + information and command line examples of how to use this facility. - Unless you have a specific reason for disabling this, say Y. + Unless you have a specific reason for disabling this, say Y. config NULL_CHAN bool "null channel support" help - This option enables support for attaching UML consoles and serial - lines to a device similar to /dev/null. Data written to it disappears - and there is never any data to be read. + This option enables support for attaching UML consoles and serial + lines to a device similar to /dev/null. Data written to it disappears + and there is never any data to be read. config PORT_CHAN bool "port channel support" help - This option enables support for attaching UML consoles and serial - lines to host portals. They may be accessed with 'telnet <host> - <port number>'. Any number of consoles and serial lines may be - attached to a single portal, although what UML device you get when - you telnet to that portal will be unpredictable. - It is safe to say 'Y' here. + This option enables support for attaching UML consoles and serial + lines to host portals. They may be accessed with 'telnet <host> + <port number>'. Any number of consoles and serial lines may be + attached to a single portal, although what UML device you get when + you telnet to that portal will be unpredictable. + It is safe to say 'Y' here. config PTY_CHAN bool "pty channel support" help - This option enables support for attaching UML consoles and serial - lines to host pseudo-terminals. Access to both traditional - pseudo-terminals (/dev/pty*) and pts pseudo-terminals are controlled - with this option. The assignment of UML devices to host devices - will be announced in the kernel message log. - It is safe to say 'Y' here. + This option enables support for attaching UML consoles and serial + lines to host pseudo-terminals. Access to both traditional + pseudo-terminals (/dev/pty*) and pts pseudo-terminals are controlled + with this option. The assignment of UML devices to host devices + will be announced in the kernel message log. + It is safe to say 'Y' here. config TTY_CHAN bool "tty channel support" help - This option enables support for attaching UML consoles and serial - lines to host terminals. Access to both virtual consoles - (/dev/tty*) and the slave side of pseudo-terminals (/dev/ttyp* and - /dev/pts/*) are controlled by this option. - It is safe to say 'Y' here. + This option enables support for attaching UML consoles and serial + lines to host terminals. Access to both virtual consoles + (/dev/tty*) and the slave side of pseudo-terminals (/dev/ttyp* and + /dev/pts/*) are controlled by this option. + It is safe to say 'Y' here. config XTERM_CHAN bool "xterm channel support" help - This option enables support for attaching UML consoles and serial - lines to xterms. Each UML device so assigned will be brought up in - its own xterm. - It is safe to say 'Y' here. + This option enables support for attaching UML consoles and serial + lines to xterms. Each UML device so assigned will be brought up in + its own xterm. + It is safe to say 'Y' here. config NOCONFIG_CHAN bool
@@ -72,43 +72,43 @@ config CON_ZERO_CHAN string "Default main console channel initialization" default "fd:0,fd:1" help - This is the string describing the channel to which the main console - will be attached by default. This value can be overridden from the - command line. The default value is "fd:0,fd:1", which attaches the - main console to stdin and stdout. - It is safe to leave this unchanged. + This is the string describing the channel to which the main console + will be attached by default. This value can be overridden from the + command line. The default value is "fd:0,fd:1", which attaches the + main console to stdin and stdout. + It is safe to leave this unchanged. config CON_CHAN string "Default console channel initialization" default "xterm" help - This is the string describing the channel to which all consoles - except the main console will be attached by default. This value can - be overridden from the command line. The default value is "xterm", - which brings them up in xterms. - It is safe to leave this unchanged, although you may wish to change - this if you expect the UML that you build to be run in environments - which don't have X or xterm available. + This is the string describing the channel to which all consoles + except the main console will be attached by default. This value can + be overridden from the command line. The default value is "xterm", + which brings them up in xterms. + It is safe to leave this unchanged, although you may wish to change + this if you expect the UML that you build to be run in environments + which don't have X or xterm available. config SSL_CHAN string "Default serial line channel initialization" default "pty" help - This is the string describing the channel to which the serial lines - will be attached by default. This value can be overridden from the - command line. The default value is "pty", which attaches them to - traditional pseudo-terminals. - It is safe to leave this unchanged, although you may wish to change - this if you expect the UML that you build to be run in environments - which don't have a set of /dev/pty* devices. + This is the string describing the channel to which the serial lines + will be attached by default. This value can be overridden from the + command line. The default value is "pty", which attaches them to + traditional pseudo-terminals. + It is safe to leave this unchanged, although you may wish to change + this if you expect the UML that you build to be run in environments + which don't have a set of /dev/pty* devices. config UML_SOUND tristate "Sound support" help - This option enables UML sound support. If enabled, it will pull in - soundcore and the UML hostaudio relay, which acts as a intermediary - between the host's dsp and mixer devices and the UML sound system. - It is safe to say 'Y' here. + This option enables UML sound support. If enabled, it will pull in + soundcore and the UML hostaudio relay, which acts as a intermediary + between the host's dsp and mixer devices and the UML sound system. + It is safe to say 'Y' here. config SOUND tristate
@@ -131,107 +131,107 @@ menu "UML Network Devices" config UML_NET bool "Virtual network device" help - While the User-Mode port cannot directly talk to any physical - hardware devices, this choice and the following transport options - provide one or more virtual network devices through which the UML - kernels can talk to each other, the host, and with the host's help, - machines on the outside world. + While the User-Mode port cannot directly talk to any physical + hardware devices, this choice and the following transport options + provide one or more virtual network devices through which the UML + kernels can talk to each other, the host, and with the host's help, + machines on the outside world. - For more information, including explanations of the networking and - sample configurations, see - <http://user-mode-linux.sourceforge.net/old/networking.html>. + For more information, including explanations of the networking and + sample configurations, see + <http://user-mode-linux.sourceforge.net/old/networking.html>. - If you'd like to be able to enable networking in the User-Mode - linux environment, say Y; otherwise say N. Note that you must - enable at least one of the following transport options to actually - make use of UML networking. + If you'd like to be able to enable networking in the User-Mode + linux environment, say Y; otherwise say N. Note that you must + enable at least one of the following transport options to actually + make use of UML networking. config UML_NET_ETHERTAP bool "Ethertap transport" depends on UML_NET help - The Ethertap User-Mode Linux network transport allows a single - running UML to exchange packets with its host over one of the - host's Ethertap devices, such as /dev/tap0. Additional running - UMLs can use additional Ethertap devices, one per running UML. - While the UML believes it's on a (multi-device, broadcast) virtual - Ethernet network, it's in fact communicating over a point-to-point - link with the host. - - To use this, your host kernel must have support for Ethertap - devices. Also, if your host kernel is 2.4.x, it must have - CONFIG_NETLINK_DEV configured as Y or M. - - For more information, see - <http://user-mode-linux.sourceforge.net/old/networking.html> That site - has examples of the UML command line to use to enable Ethertap - networking. - - If you'd like to set up an IP network with the host and/or the - outside world, say Y to this, the Daemon Transport and/or the - Slip Transport. You'll need at least one of them, but may choose - more than one without conflict. If you don't need UML networking, - say N. + The Ethertap User-Mode Linux network transport allows a single + running UML to exchange packets with its host over one of the + host's Ethertap devices, such as /dev/tap0. Additional running + UMLs can use additional Ethertap devices, one per running UML. + While the UML believes it's on a (multi-device, broadcast) virtual + Ethernet network, it's in fact communicating over a point-to-point + link with the host. + + To use this, your host kernel must have support for Ethertap + devices. Also, if your host kernel is 2.4.x, it must have + CONFIG_NETLINK_DEV configured as Y or M. + + For more information, see + <http://user-mode-linux.sourceforge.net/old/networking.html> That site + has examples of the UML command line to use to enable Ethertap + networking. + + If you'd like to set up an IP network with the host and/or the + outside world, say Y to this, the Daemon Transport and/or the + Slip Transport. You'll need at least one of them, but may choose + more than one without conflict. If you don't need UML networking, + say N. config UML_NET_TUNTAP bool "TUN/TAP transport" depends on UML_NET help - The UML TUN/TAP network transport allows a UML instance to exchange - packets with the host over a TUN/TAP device. This option will only - work with a 2.4 host, unless you've applied the TUN/TAP patch to - your 2.2 host kernel. + The UML TUN/TAP network transport allows a UML instance to exchange + packets with the host over a TUN/TAP device. This option will only + work with a 2.4 host, unless you've applied the TUN/TAP patch to + your 2.2 host kernel. - To use this transport, your host kernel must have support for TUN/TAP - devices, either built-in or as a module. + To use this transport, your host kernel must have support for TUN/TAP + devices, either built-in or as a module. config UML_NET_SLIP bool "SLIP transport" depends on UML_NET help - The slip User-Mode Linux network transport allows a running UML to - network with its host over a point-to-point link. Unlike Ethertap, - which can carry any Ethernet frame (and hence even non-IP packets), - the slip transport can only carry IP packets. - - To use this, your host must support slip devices. - - For more information, see - <http://user-mode-linux.sourceforge.net/old/networking.html>. - has examples of the UML command line to use to enable slip - networking, and details of a few quirks with it. - - The Ethertap Transport is preferred over slip because of its - limitations. If you prefer slip, however, say Y here. Otherwise - choose the Multicast transport (to network multiple UMLs on - multiple hosts), Ethertap (to network with the host and the - outside world), and/or the Daemon transport (to network multiple - UMLs on a single host). You may choose more than one without - conflict. If you don't need UML networking, say N. + The slip User-Mode Linux network transport allows a running UML to + network with its host over a point-to-point link. Unlike Ethertap, + which can carry any Ethernet frame (and hence even non-IP packets), + the slip transport can only carry IP packets. + + To use this, your host must support slip devices. + + For more information, see + <http://user-mode-linux.sourceforge.net/old/networking.html>. + has examples of the UML command line to use to enable slip + networking, and details of a few quirks with it. + + The Ethertap Transport is preferred over slip because of its + limitations. If you prefer slip, however, say Y here. Otherwise + choose the Multicast transport (to network multiple UMLs on + multiple hosts), Ethertap (to network with the host and the + outside world), and/or the Daemon transport (to network multiple + UMLs on a single host). You may choose more than one without + conflict. If you don't need UML networking, say N. config UML_NET_DAEMON bool "Daemon transport" depends on UML_NET help - This User-Mode Linux network transport allows one or more running - UMLs on a single host to communicate with each other, but not to - the host. - - To use this form of networking, you'll need to run the UML - networking daemon on the host. - - For more information, see - <http://user-mode-linux.sourceforge.net/old/networking.html> That site - has examples of the UML command line to use to enable Daemon - networking. - - If you'd like to set up a network with other UMLs on a single host, - say Y. If you need a network between UMLs on multiple physical - hosts, choose the Multicast Transport. To set up a network with - the host and/or other IP machines, say Y to the Ethertap or Slip - transports. You'll need at least one of them, but may choose - more than one without conflict. If you don't need UML networking, - say N. + This User-Mode Linux network transport allows one or more running + UMLs on a single host to communicate with each other, but not to + the host. + + To use this form of networking, you'll need to run the UML + networking daemon on the host. + + For more information, see + <http://user-mode-linux.sourceforge.net/old/networking.html> That site + has examples of the UML command line to use to enable Daemon + networking. + + If you'd like to set up a network with other UMLs on a single host, + say Y. If you need a network between UMLs on multiple physical + hosts, choose the Multicast Transport. To set up a network with + the host and/or other IP machines, say Y to the Ethertap or Slip + transports. You'll need at least one of them, but may choose + more than one without conflict. If you don't need UML networking, + say N. config UML_NET_VECTOR bool "Vector I/O high performance network devices"
@@ -270,26 +270,26 @@ config UML_NET_MCAST bool "Multicast transport" depends on UML_NET help - This Multicast User-Mode Linux network transport allows multiple - UMLs (even ones running on different host machines!) to talk to - each other over a virtual ethernet network. However, it requires - at least one UML with one of the other transports to act as a - bridge if any of them need to be able to talk to their hosts or any - other IP machines. - - To use this, your host kernel(s) must support IP Multicasting. - - For more information, see - <http://user-mode-linux.sourceforge.net/old/networking.html> That site - has examples of the UML command line to use to enable Multicast - networking, and notes about the security of this approach. - - If you need UMLs on multiple physical hosts to communicate as if - they shared an Ethernet network, say Y. If you need to communicate - with other IP machines, make sure you select one of the other - transports (possibly in addition to Multicast; they're not - exclusive). If you don't need to network UMLs say N to each of - the transports. + This Multicast User-Mode Linux network transport allows multiple + UMLs (even ones running on different host machines!) to talk to + each other over a virtual ethernet network. However, it requires + at least one UML with one of the other transports to act as a + bridge if any of them need to be able to talk to their hosts or any + other IP machines. + + To use this, your host kernel(s) must support IP Multicasting. + + For more information, see + <http://user-mode-linux.sourceforge.net/old/networking.html> That site + has examples of the UML command line to use to enable Multicast + networking, and notes about the security of this approach. + + If you need UMLs on multiple physical hosts to communicate as if + they shared an Ethernet network, say Y. If you need to communicate + with other IP machines, make sure you select one of the other + transports (possibly in addition to Multicast; they're not + exclusive). If you don't need to network UMLs say N to each of + the transports. config UML_NET_PCAP bool "pcap transport"
@@ -300,9 +300,9 @@ config UML_NET_PCAP UML act as a network monitor for the host. You must have libcap installed in order to build the pcap transport into UML. - For more information, see - <http://user-mode-linux.sourceforge.net/old/networking.html> That site - has examples of the UML command line to use to enable this option. + For more information, see + <http://user-mode-linux.sourceforge.net/old/networking.html> That site + has examples of the UML command line to use to enable this option. If you intend to use UML as a network monitor for the host, say Y here. Otherwise, say N.
@@ -311,27 +311,27 @@ config UML_NET_SLIRP bool "SLiRP transport" depends on UML_NET help - The SLiRP User-Mode Linux network transport allows a running UML - to network by invoking a program that can handle SLIP encapsulated - packets. This is commonly (but not limited to) the application - known as SLiRP, a program that can re-socket IP packets back onto - the host on which it is run. Only IP packets are supported, - unlike other network transports that can handle all Ethernet - frames. In general, slirp allows the UML the same IP connectivity - to the outside world that the host user is permitted, and unlike - other transports, SLiRP works without the need of root level - privleges, setuid binaries, or SLIP devices on the host. This - also means not every type of connection is possible, but most - situations can be accommodated with carefully crafted slirp - commands that can be passed along as part of the network device's - setup string. The effect of this transport on the UML is similar - that of a host behind a firewall that masquerades all network - connections passing through it (but is less secure). - - To use this you should first have slirp compiled somewhere - accessible on the host, and have read its documentation. If you - don't need UML networking, say N. - - Startup example: "eth0=slirp,FE:FD:01:02:03:04,/usr/local/bin/slirp" + The SLiRP User-Mode Linux network transport allows a running UML + to network by invoking a program that can handle SLIP encapsulated + packets. This is commonly (but not limited to) the application + known as SLiRP, a program that can re-socket IP packets back onto + he host on which it is run. Only IP packets are supported, + unlike other network transports that can handle all Ethernet + frames. In general, slirp allows the UML the same IP connectivity + to the outside world that the host user is permitted, and unlike + other transports, SLiRP works without the need of root level + privleges, setuid binaries, or SLIP devices on the host. This + also means not every type of connection is possible, but most + situations can be accommodated with carefully crafted slirp + commands that can be passed along as part of the network device's + setup string. The effect of this transport on the UML is similar + that of a host behind a firewall that masquerades all network + connections passing through it (but is less secure). + + To use this you should first have slirp compiled somewhere + accessible on the host, and have read its documentation. If you + don't need UML networking, say N. + + Startup example: "eth0=slirp,FE:FD:01:02:03:04,/usr/local/bin/slirp" endmenu
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 163/273 um: Fix hostaudio build errors
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Randy Dunlap <[email protected]>
[ Upstream commit db4bfcba7bb8d10f00bba2a3da6b9a9c2a1d7b71 ]
Use "select" to ensure that the required kconfig symbols are set as expected.
Drop HOSTAUDIO since it is now equivalent to UML_SOUND.
Set CONFIG_SOUND=m in ARCH=um defconfig files to maintain the status quo of the default configs.
Allow SOUND with UML regardless of HAS_IOMEM. Otherwise there is a kconfig warning for unmet dependencies. (This was not an issue when SOUND was defined in arch/um/drivers/Kconfig. I have done 50 randconfig builds and didn't find any issues.)
This fixes build errors when CONFIG_SOUND is not set:
ld: arch/um/drivers/hostaudio_kern.o: in function `hostaudio_cleanup_module':
hostaudio_kern.c:(.exit.text+0xa): undefined reference to `unregister_sound_mixer'
ld: hostaudio_kern.c:(.exit.text+0x15): undefined reference to `unregister_sound_dsp'
ld: arch/um/drivers/hostaudio_kern.o: in function `hostaudio_init_module':
hostaudio_kern.c:(.init.text+0x19): undefined reference to `register_sound_dsp'
ld: hostaudio_kern.c:(.init.text+0x31): undefined reference to `register_sound_mixer'
ld: hostaudio_kern.c:(.init.text+0x49): undefined reference to `unregister_sound_dsp'
and this kconfig warning:
WARNING: unmet direct dependencies detected for SOUND
--- arch/um/configs/i386_defconfig | 1 + arch/um/configs/x86_64_defconfig | 1 + arch/um/drivers/Kconfig | 16 +++------------- arch/um/drivers/Makefile | 2 +- sound/Kconfig | 2 +- 5 files changed, 7 insertions(+), 15 deletions(-)
arch/um/configs/i386_defconfig +1 -0
@@ -35,6 +35,7 @@ CONFIG_TTY_CHAN=y CONFIG_XTERM_CHAN=y CONFIG_CON_CHAN="pts" CONFIG_SSL_CHAN="pts" +CONFIG_SOUND=m CONFIG_UML_SOUND=m CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_DEVTMPFS=y
arch/um/configs/x86_64_defconfig +1 -0
@@ -33,6 +33,7 @@ CONFIG_TTY_CHAN=y CONFIG_XTERM_CHAN=y CONFIG_CON_CHAN="pts" CONFIG_SSL_CHAN="pts" +CONFIG_SOUND=m CONFIG_UML_SOUND=m CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_DEVTMPFS=y
arch/um/drivers/Kconfig +3 -13
@@ -104,24 +104,14 @@ config SSL_CHAN config UML_SOUND tristate "Sound support" + depends on SOUND + select SOUND_OSS_CORE help This option enables UML sound support. If enabled, it will pull in - soundcore and the UML hostaudio relay, which acts as a intermediary + the UML hostaudio relay, which acts as a intermediary between the host's dsp and mixer devices and the UML sound system. It is safe to say 'Y' here. -config SOUND - tristate - default UML_SOUND - -config SOUND_OSS_CORE - bool - default UML_SOUND - -config HOSTAUDIO - tristate - default UML_SOUND - endmenu menu "UML Network Devices"
arch/um/drivers/Makefile +1 -1
@@ -52,7 +52,7 @@ obj-$(CONFIG_UML_NET) += net.o obj-$(CONFIG_MCONSOLE) += mconsole.o obj-$(CONFIG_MMAPPER) += mmapper_kern.o obj-$(CONFIG_BLK_DEV_UBD) += ubd.o -obj-$(CONFIG_HOSTAUDIO) += hostaudio.o +obj-$(CONFIG_UML_SOUND) += hostaudio.o obj-$(CONFIG_NULL_CHAN) += null.o obj-$(CONFIG_PORT_CHAN) += port.o obj-$(CONFIG_PTY_CHAN) += pty.o
sound/Kconfig +1 -1
@@ -1,6 +1,6 @@ menuconfig SOUND tristate "Sound card support" - depends on HAS_IOMEM + depends on HAS_IOMEM || UML help If you have a sound card in your computer, i.e. if it can say more than an occasional beep, say Y.
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 164/273 dmaengine: ste_dma40: Add missing IRQ check in d40_probe
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: ruanjinjie <[email protected]>
[ Upstream commit c05ce6907b3d6e148b70f0bb5eafd61dcef1ddc1 ]
Check for the return value of platform_get_irq(): if no interrupt is specified, it wouldn't make sense to call request_irq().
--- drivers/dma/ste_dma40.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/dma/ste_dma40.c +4 -0
@@ -3584,6 +3584,10 @@ static int __init d40_probe(struct platform_device *pdev)spin_lock_init (&base->lcla_pool.lock); base->irq =platform_get_irq (pdev,0 ); +if (base->irq <0 ) { + ret = base->irq; + goto destroy_cache; + } ret =request_irq (base->irq, d40_handle_interrupt,0 ,D40_NAME , base);if (ret) {
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 165/273 igmp: limit igmpv3_newpack() packet size to IP_MAX_MTU
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
commit c3b704d4a4a265660e665df51b129e8425216ed1 upstream.
This is a follow up of commit 915d975b2ffa ("net: deal with integer overflows in kmalloc_reserve()") based on David Laight feedback.
Back in 2010, I failed to realize malicious users could set dev->mtu to arbitrary values. This mtu has been since limited to 0x7fffffff but regardless of how big dev->mtu is, it makes no sense for igmpv3_newpack() to allocate more than IP_MAX_MTU and risk various skb fields overflows.
--- net/ipv4/igmp.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
net/ipv4/igmp.c +2 -1
@@ -357,8 +357,9 @@ static struct sk_buff *igmpv3_newpack(ststruct flowi4 fl4;int hlen =LL_RESERVED_SPACE (dev);int tlen = dev->needed_tailroom; -unsigned int size = mtu; +unsigned int size; + size =min (mtu,IP_MAX_MTU );while (1 ) { skb =alloc_skb (size + hlen + tlen,GFP_ATOMIC | __GFP_NOWARN);
Greg Kroah-Hartman
maintainerPATCH 166/273 netfilter: ipset: add the missing IP_SET_HASH_WITH_NET0 macro for ip_set_hash_netportnet.c
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kyle Zeng <[email protected]>
commit 050d91c03b28ca479df13dfb02bcd2c60dd6a878 upstream.
The missing IP_SET_HASH_WITH_NET0 macro in ip_set_hash_netportnet can lead to the use of wrong CIDR_POS(c) for calculating array offsets, which can lead to integer underflow. As a result, it leads to slab out-of-bound access.
This patch adds back the IP_SET_HASH_WITH_NET0 macro to ip_set_hash_netportnet to address the issue.
--- net/netfilter/ipset/ip_set_hash_netportnet.c | 1 + 1 file changed, 1 insertion(+)
net/netfilter/ipset/ip_set_hash_netportnet.c +1 -0
@@ -39,6 +39,7 @@ MODULE_ALIAS("ip_set_hash:net,port,net")#define IP_SET_HASH_WITH_PROTO #define IP_SET_HASH_WITH_NETS #define IPSET_NET_COUNT 2 +#define IP_SET_HASH_WITH_NET0 /* IPv4 variant */
Greg Kroah-Hartman
maintainerPATCH 167/273 netfilter: xt_u32: validate user space input
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wander Lairson Costa <[email protected]>
commit 69c5d284f67089b4750d28ff6ac6f52ec224b330 upstream.
The xt_u32 module doesn't validate the fields in the xt_u32 structure. An attacker may take advantage of this to trigger an OOB read by setting the size fields with a value beyond the arrays boundaries.
Add a checkentry function to validate the structure.
This was originally reported by the ZDI project (ZDI-CAN-18408).
--- net/netfilter/xt_u32.c | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+)
net/netfilter/xt_u32.c +21 -0
@@ -95,11 +95,32 @@ static bool u32_mt(const struct sk_buffreturn ret ^ data->invert; } +static int u32_mt_checkentry (const struct xt_mtchk_param *par) +{ +const struct xt_u32 *data = par->matchinfo; +const struct xt_u32_test *ct; +unsigned int i; + +if (data->ntests >ARRAY_SIZE (data->tests)) +return -EINVAL ; + +for (i =0 ; i < data->ntests; ++i) { + ct = &data->tests[i]; + +if (ct->nnums >ARRAY_SIZE (ct->location) || + ct->nvalues >ARRAY_SIZE (ct->value)) +return -EINVAL ; + } + +return 0 ; +} +static struct xt_match xt_u32_mt_reg__read_mostly = { .name ="u32" , .revision =0 , .family =NFPROTO_UNSPEC , .match = u32_mt, + .checkentry = u32_mt_checkentry, .matchsize =sizeof (struct xt_u32 ), .me =THIS_MODULE , };
Greg Kroah-Hartman
maintainerPATCH 168/273 netfilter: xt_sctp: validate the flag_info count
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wander Lairson Costa <[email protected]>
commit e99476497687ef9e850748fe6d232264f30bc8f9 upstream.
sctp_mt_check doesn't validate the flag_count field. An attacker can take advantage of that to trigger a OOB read and leak memory information.
Add the field validation in the checkentry function.
--- net/netfilter/xt_sctp.c | 2 ++ 1 file changed, 2 insertions(+)
net/netfilter/xt_sctp.c +2 -0
@@ -149,6 +149,8 @@ static int sctp_mt_check(const struct xt {const struct xt_sctp_info *info = par->matchinfo; +if (info->flag_count >ARRAY_SIZE (info->flag_info)) +return -EINVAL ;if (info->flags & ~XT_SCTP_VALID_FLAGS )return -EINVAL ;if (info->invflags & ~XT_SCTP_VALID_FLAGS )
Greg Kroah-Hartman
maintainerPATCH 169/273 skbuff: skb_segment, Call zero copy functions before using skbuff frags
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mohamed Khalfella <[email protected]>
commit 2ea35288c83b3d501a88bc17f2df8f176b5cc96f upstream.
Commit bf5c25d60861 ("skbuff: in skb_segment, call zerocopy functions once per nskb") added the call to zero copy functions in skb_segment(). The change introduced a bug in skb_segment() because skb_orphan_frags() may possibly change the number of fragments or allocate new fragments altogether leaving nrfrags and frag to point to the old values. This can cause a panic with stacktrace like the one below.
[ 193.894380] BUG: kernel NULL pointer dereference, address: 00000000000000bc [ 193.895273] CPU: 13 PID: 18164 Comm: vh-net-17428 Kdump: loaded Tainted: G O 5.15.123+ #26 [ 193.903919] RIP: 0010:skb_segment+0xb0e/0x12f0 [ 194.021892] Call Trace: [ 194.027422] <TASK> [ 194.072861] tcp_gso_segment+0x107/0x540 [ 194.082031] inet_gso_segment+0x15c/0x3d0 [ 194.090783] skb_mac_gso_segment+0x9f/0x110 [ 194.095016] __skb_gso_segment+0xc1/0x190 [ 194.103131] netem_enqueue+0x290/0xb10 [sch_netem] [ 194.107071] dev_qdisc_enqueue+0x16/0x70 [ 194.110884] __dev_queue_xmit+0x63b/0xb30 [ 194.121670] bond_start_xmit+0x159/0x380 [bonding] [ 194.128506] dev_hard_start_xmit+0xc3/0x1e0 [ 194.131787] __dev_queue_xmit+0x8a0/0xb30 [ 194.138225] macvlan_start_xmit+0x4f/0x100 [macvlan] [ 194.141477] dev_hard_start_xmit+0xc3/0x1e0 [ 194.144622] sch_direct_xmit+0xe3/0x280 [ 194.147748] __dev_queue_xmit+0x54a/0xb30 [ 194.154131] tap_get_user+0x2a8/0x9c0 [tap] [ 194.157358] tap_sendmsg+0x52/0x8e0 [tap] [ 194.167049] handle_tx_zerocopy+0x14e/0x4c0 [vhost_net] [ 194.173631] handle_tx+0xcd/0xe0 [vhost_net] [ 194.176959] vhost_worker+0x76/0xb0 [vhost] [ 194.183667] kthread+0x118/0x140 [ 194.190358] ret_from_fork+0x1f/0x30 [ 194.193670] </TASK>
In this case calling skb_orphan_frags() updated nr_frags leaving nrfrags local variable in skb_segment() stale. This resulted in the code hitting i >= nrfrags prematurely and trying to move to next frag_skb using list_skb pointer, which was NULL, and caused kernel panic. Move the call to zero copy functions before using frags and nr_frags.
--- net/core/skbuff.c | 34 ++++++++++++++++++++-------------- 1 file changed, 20 insertions(+), 14 deletions(-)
net/core/skbuff.c +20 -14
@@ -3546,21 +3546,20 @@ struct sk_buff *skb_segment(struct sk_bustruct sk_buff *segs =NULL ;struct sk_buff *tail =NULL ;struct sk_buff *list_skb =skb_shinfo (head_skb)->frag_list; -skb_frag_t *frag =skb_shinfo (head_skb)->frags;unsigned int mss =skb_shinfo (head_skb)->gso_size;unsigned int doffset = head_skb->data -skb_mac_header (head_skb); -struct sk_buff *frag_skb = head_skb;unsigned int offset = doffset;unsigned int tnl_hlen =skb_tnl_header_len (head_skb);unsigned int partial_segs =0 ;unsigned int headroom;unsigned int len = head_skb->len; +struct sk_buff *frag_skb; +skb_frag_t *frag;__be16 proto;bool csum, sg; -int nfrags =skb_shinfo (head_skb)->nr_frags;int err = -ENOMEM ;int i =0 ; -int pos; +int nfrags, pos;int dummy; if ((skb_shinfo(head_skb)->gso_type & SKB_GSO_DODGY) &&
@@ -3638,6 +3637,13 @@ normal: headroom =skb_headroom (head_skb); pos =skb_headlen (head_skb); +if (skb_orphan_frags (head_skb,GFP_ATOMIC )) +return ERR_PTR (-ENOMEM ); + + nfrags =skb_shinfo (head_skb)->nr_frags; + frag =skb_shinfo (head_skb)->frags; + frag_skb = head_skb; + do { struct sk_buff *nskb; skb_frag_t *nskb_frag;
@@ -3662,6 +3668,10 @@ normal: (skb_headlen(list_skb) == len || sg)) {BUG_ON (skb_headlen (list_skb) > len); + nskb =skb_clone (list_skb,GFP_ATOMIC ); +if (unlikely (!nskb)) + goto err; + i =0 ; nfrags =skb_shinfo (list_skb)->nr_frags; frag =skb_shinfo (list_skb)->frags;
@@ -3680,12 +3690,8 @@ normal: frag++; } - nskb =skb_clone (list_skb,GFP_ATOMIC ); list_skb = list_skb->next; -if (unlikely (!nskb)) - goto err; -if (unlikely (pskb_trim (nskb, len))) {kfree_skb (nskb); goto err;
@@ -3750,12 +3756,16 @@ normal:skb_shinfo (nskb)->tx_flags |=skb_shinfo (head_skb)->tx_flags &SKBTX_SHARED_FRAG ; -if (skb_orphan_frags (frag_skb,GFP_ATOMIC ) || -skb_zerocopy_clone (nskb, frag_skb,GFP_ATOMIC )) +if (skb_zerocopy_clone (nskb, frag_skb,GFP_ATOMIC )) goto err;while (pos < offset + len) {if (i >= nfrags) { +if (skb_orphan_frags (list_skb,GFP_ATOMIC ) || +skb_zerocopy_clone (nskb, list_skb, +GFP_ATOMIC )) + goto err; + i =0 ; nfrags =skb_shinfo (list_skb)->nr_frags; frag =skb_shinfo (list_skb)->frags;
@@ -3769,10 +3779,6 @@ normal: i--; frag--; } -if (skb_orphan_frags (frag_skb,GFP_ATOMIC ) || -skb_zerocopy_clone (nskb, frag_skb, -GFP_ATOMIC )) - goto err; list_skb = list_skb->next; }
Greg Kroah-Hartman
maintainerPATCH 170/273 igb: set max size RX buffer when store bad packet is enabled
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Radoslaw Tyl <[email protected]>
commit bb5ed01cd2428cd25b1c88a3a9cba87055eb289f upstream.
Increase the RX buffer size to 3K when the SBP bit is on. The size of the RX buffer determines the number of pages allocated which may not be sufficient for receive frames larger than the set MTU size.
--- drivers/net/ethernet/intel/igb/igb_main.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
drivers/net/ethernet/intel/igb/igb_main.c +7 -4
@@ -4579,6 +4579,10 @@ void igb_configure_rx_ring(struct igb_adstatic void igb_set_rx_buffer_len (struct igb_adapter *adapter,struct igb_ring *rx_ring) { +#if (PAGE_SIZE <8192 ) +struct e1000_hw *hw = &adapter->hw; +#endif +/* set build_skb and buffer size flags */ clear_ring_build_skb_enabled (rx_ring);clear_ring_uses_large_buffer (rx_ring);
@@ -4589,10 +4593,9 @@ static void igb_set_rx_buffer_len(structset_ring_build_skb_enabled (rx_ring);#if (PAGE_SIZE <8192 ) -if (adapter->max_frame_size <=IGB_MAX_FRAME_BUILD_SKB ) -return ; - -set_ring_uses_large_buffer (rx_ring); +if (adapter->max_frame_size >IGB_MAX_FRAME_BUILD_SKB || +rd32 (E1000_RCTL ) &E1000_RCTL_SBP ) +set_ring_uses_large_buffer (rx_ring);#endif }
Greg Kroah-Hartman
maintainerPATCH 171/273 PM / devfreq: Fix leak in devfreq_dev_release()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Boris Brezillon <[email protected]>
commit 5693d077595de721f9ddbf9d37f40e5409707dfe upstream.
srcu_init_notifier_head() allocates resources that need to be released with a srcu_cleanup_notifier_head() call.
Reported by kmemleak.
--- drivers/devfreq/devfreq.c | 1 + 1 file changed, 1 insertion(+)
drivers/devfreq/devfreq.c +1 -0
@@ -582,6 +582,7 @@ static void devfreq_dev_release(struct d devfreq->profile->exit (devfreq->dev.parent);mutex_destroy (&devfreq->lock); +srcu_cleanup_notifier_head (&devfreq->transition_notifier_list);kfree (devfreq); }
Greg Kroah-Hartman
maintainerPATCH 172/273 ALSA: pcm: Fix missing fixup call in compat hw_refine ioctl
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <[email protected]>
commit 358040e3807754944dbddf948a23c6d914297ed7 upstream.
The update of rate_num/den and msbits were factored out to fixup_unreferenced_params() function to be called explicitly after the hw_refine or hw_params procedure. It's called from snd_pcm_hw_refine_user(), but it's forgotten in the PCM compat ioctl. This ended up with the incomplete rate_num/den and msbits parameters when 32bit compat ioctl is used.
This patch adds the missing call in snd_pcm_ioctl_hw_params_compat().
--- sound/core/pcm_compat.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
sound/core/pcm_compat.c +6 -2
@@ -329,10 +329,14 @@ static int snd_pcm_ioctl_hw_params_compa goto error; } -if (refine) +if (refine) { err =snd_pcm_hw_refine (substream, data); -else +if (err <0 ) + goto error; + err =fixup_unreferenced_params (substream, data); + }else { err =snd_pcm_hw_params (substream, data); + }if (err <0 ) goto error; if (copy_to_user(data32, data, sizeof(*data32)) ||
Greg Kroah-Hartman
maintainerPATCH 173/273 ipmi_si: fix a memleak in try_smi_init()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yi Yang <[email protected]>
commit 6cf1a126de2992b4efe1c3c4d398f8de4aed6e3f upstream.
Kmemleak reported the following leak info in try_smi_init():
unreferenced object 0xffff00018ecf9400 (size 1024):
comm "modprobe", pid 2707763, jiffies 4300851415 (age 773.308s) backtrace:
[<000000004ca5b312>] __kmalloc+0x4b8/0x7b0
[<00000000953b1072>] try_smi_init+0x148/0x5dc [ipmi_si]
[<000000006460d325>] 0xffff800081b10148
[<0000000039206ea5>] do_one_initcall+0x64/0x2a4
[<00000000601399ce>] do_init_module+0x50/0x300
[<000000003c12ba3c>] load_module+0x7a8/0x9e0
[<00000000c246fffe>] __se_sys_init_module+0x104/0x180
[<00000000eea99093>] __arm64_sys_init_module+0x24/0x30
[<0000000021b1ef87>] el0_svc_common.constprop.0+0x94/0x250
[<0000000070f4f8b7>] do_el0_svc+0x48/0xe0
[<000000005a05337f>] el0_svc+0x24/0x3c
[<000000005eb248d6>] el0_sync_handler+0x160/0x164
[<0000000030a59039>] el0_sync+0x160/0x180The problem was that when an error occurred before handlers registration and after allocating new_smi->si_sm, the variable wouldn't be freed in the error handling afterwards since shutdown_smi() hadn't been registered yet. Fix it by adding a kfree() in the error handling path in try_smi_init().
Message-Id: <[email protected]>
--- drivers/char/ipmi/ipmi_si_intf.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/char/ipmi/ipmi_si_intf.c +5 -0
@@ -2119,6 +2119,11 @@ static int try_smi_init(struct smi_info new_smi->io.io_cleanup =NULL ; } +if (rv && new_smi->si_sm) { +kfree (new_smi->si_sm); + new_smi->si_sm =NULL ; + } +kfree (init_name);return rv; }
Greg Kroah-Hartman
maintainerPATCH 174/273 ARM: OMAP2+: Fix -Warray-bounds warning in _pwrdm_state_switch()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gustavo A. R. Silva <[email protected]>
commit 847fb80cc01a54bc827b02547bb8743bdb59ddab upstream.
If function pwrdm_read_prev_pwrst() returns -EINVAL, we will end up accessing array pwrdm->state_counter through negative index -22. This is wrong and the compiler is legitimately warning us about this potential problem.
Fix this by sanity checking the value stored in variable _prev_ before accessing array pwrdm->state_counter.
Address the following -Warray-bounds warning:arch/arm/mach-omap2/powerdomain.c:178:45: warning: array subscript -22 is below array bounds of 'unsigned int[4]' [-Warray-bounds]
Message-ID: <ZIFVGwImU3kpaGeH@work>
--- arch/arm/mach-omap2/powerdomain.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/mach-omap2/powerdomain.c +1 -1
@@ -177,7 +177,7 @@ static int _pwrdm_state_switch(struct pobreak ;case PWRDM_STATE_PREV : prev =pwrdm_read_prev_pwrst (pwrdm); -if (pwrdm->state != prev) +if (prev >=0 && pwrdm->state != prev) pwrdm->state_counter[prev]++;if (prev ==PWRDM_POWER_RET )_update_logic_membank_counters (pwrdm);
Greg Kroah-Hartman
maintainerPATCH 175/273 backlight/gpio_backlight: Compare against struct fb_info.device
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Zimmermann <[email protected]>
commit 7b91d017f77c1bda56f27c2f4bbb70de7c6eca08 upstream.
Struct gpio_backlight_platform_data refers to a platform device within the Linux device hierarchy. The test in gpio_backlight_check_fb() compares it against the fbdev device in struct fb_info.dev, which is different. Fix the test by comparing to struct fb_info.device.
Fixes a bug in the backlight driver and prepares fbdev for making struct fb_info.dev optional.
v2:
* move renames into separate patch (Javier, Sam, Michael)
--- drivers/video/backlight/gpio_backlight.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/video/backlight/gpio_backlight.c +1 -1
@@ -48,7 +48,7 @@ static int gpio_backlight_check_fb(struc {struct gpio_backlight *gbl =bl_get_data (bl); -return gbl->fbdev ==NULL || gbl->fbdev == info->dev; +return gbl->fbdev ==NULL || gbl->fbdev == info->device; }static const struct backlight_ops gpio_backlight_ops = {
Greg Kroah-Hartman
maintainerPATCH 176/273 backlight/bd6107: Compare against struct fb_info.device
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Zimmermann <[email protected]>
commit 992bdddaabfba19bdc77c1c7a4977b2aa41ec891 upstream.
Struct bd6107_platform_data refers to a platform device within the Linux device hierarchy. The test in bd6107_backlight_check_fb() compares it against the fbdev device in struct fb_info.dev, which is different. Fix the test by comparing to struct fb_info.device.
Fixes a bug in the backlight driver and prepares fbdev for making struct fb_info.dev optional.
v2:
* move renames into separate patch (Javier, Sam, Michael)
--- drivers/video/backlight/bd6107.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/video/backlight/bd6107.c +1 -1
@@ -110,7 +110,7 @@ static int bd6107_backlight_check_fb(str {struct bd6107 *bd =bl_get_data (backlight); -return bd->pdata->fbdev ==NULL || bd->pdata->fbdev == info->dev; +return bd->pdata->fbdev ==NULL || bd->pdata->fbdev == info->device; }static const struct backlight_ops bd6107_backlight_ops = {
Greg Kroah-Hartman
maintainerPATCH 177/273 backlight/lv5207lp: Compare against struct fb_info.device
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Zimmermann <[email protected]>
commit 1ca8819320fd84e7d95b04e7668efc5f9fe9fa5c upstream.
Struct lv5207lp_platform_data refers to a platform device within the Linux device hierarchy. The test in lv5207lp_backlight_check_fb() compares it against the fbdev device in struct fb_info.dev, which is different. Fix the test by comparing to struct fb_info.device.
Fixes a bug in the backlight driver and prepares fbdev for making struct fb_info.dev optional.
v2:
* move renames into separate patch (Javier, Sam, Michael)
--- drivers/video/backlight/lv5207lp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/video/backlight/lv5207lp.c +1 -1
@@ -75,7 +75,7 @@ static int lv5207lp_backlight_check_fb(s {struct lv5207lp *lv =bl_get_data (backlight); -return lv->pdata->fbdev ==NULL || lv->pdata->fbdev == info->dev; +return lv->pdata->fbdev ==NULL || lv->pdata->fbdev == info->device; }static const struct backlight_ops lv5207lp_backlight_ops = {
Greg Kroah-Hartman
maintainerPATCH 178/273 media: dvb: symbol fixup for dvb_attach()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <[email protected]>
commit 86495af1171e1feec79faa9b64c05c89f46e41d1 upstream.
In commit 9011e49d54dc ("modules: only allow symbol_get of EXPORT_SYMBOL_GPL modules") the use of symbol_get is properly restricted to GPL-only marked symbols. This interacts oddly with the DVB logic which only uses dvb_attach() to load the dvb driver which then uses symbol_get().
Fix this up by properly marking all of the dvb_attach attach symbols as EXPORT_SYMBOL_GPL().
--- drivers/media/dvb-frontends/ascot2e.c | 2 +- drivers/media/dvb-frontends/atbm8830.c | 2 +- drivers/media/dvb-frontends/au8522_dig.c | 2 +- drivers/media/dvb-frontends/bcm3510.c | 2 +- drivers/media/dvb-frontends/cx22700.c | 2 +- drivers/media/dvb-frontends/cx22702.c | 2 +- drivers/media/dvb-frontends/cx24110.c | 2 +- drivers/media/dvb-frontends/cx24113.c | 2 +- drivers/media/dvb-frontends/cx24116.c | 2 +- drivers/media/dvb-frontends/cx24120.c | 2 +- drivers/media/dvb-frontends/cx24123.c | 2 +- drivers/media/dvb-frontends/cxd2820r_core.c | 2 +- drivers/media/dvb-frontends/cxd2841er.c | 4 ++-- drivers/media/dvb-frontends/cxd2880/cxd2880_top.c | 2 +- drivers/media/dvb-frontends/dib0070.c | 2 +- drivers/media/dvb-frontends/dib0090.c | 4 ++-- drivers/media/dvb-frontends/dib3000mb.c | 2 +- drivers/media/dvb-frontends/dib3000mc.c | 2 +- drivers/media/dvb-frontends/dib7000m.c | 2 +- drivers/media/dvb-frontends/dib7000p.c | 2 +- drivers/media/dvb-frontends/dib8000.c | 2 +- drivers/media/dvb-frontends/dib9000.c | 2 +- drivers/media/dvb-frontends/drx39xyj/drxj.c | 2 +- drivers/media/dvb-frontends/drxd_hard.c | 2 +- drivers/media/dvb-frontends/drxk_hard.c | 2 +- drivers/media/dvb-frontends/ds3000.c | 2 +- drivers/media/dvb-frontends/dvb-pll.c | 2 +- drivers/media/dvb-frontends/ec100.c | 2 +- drivers/media/dvb-frontends/helene.c | 4 ++-- drivers/media/dvb-frontends/horus3a.c | 2 +- drivers/media/dvb-frontends/isl6405.c | 2 +- drivers/media/dvb-frontends/isl6421.c | 2 +- drivers/media/dvb-frontends/isl6423.c | 2 +- drivers/media/dvb-frontends/itd1000.c | 2 +- drivers/media/dvb-frontends/ix2505v.c | 2 +- drivers/media/dvb-frontends/l64781.c | 2 +- drivers/media/dvb-frontends/lg2160.c | 2 +- drivers/media/dvb-frontends/lgdt3305.c | 2 +- drivers/media/dvb-frontends/lgdt3306a.c | 2 +- drivers/media/dvb-frontends/lgdt330x.c | 2 +- drivers/media/dvb-frontends/lgs8gxx.c | 2 +- drivers/media/dvb-frontends/lnbh25.c | 2 +- drivers/media/dvb-frontends/lnbp21.c | 4 ++-- drivers/media/dvb-frontends/lnbp22.c | 2 +- drivers/media/dvb-frontends/m88ds3103.c | 2 +- drivers/media/dvb-frontends/m88rs2000.c | 2 +- drivers/media/dvb-frontends/mb86a16.c | 2 +- drivers/media/dvb-frontends/mb86a20s.c | 2 +- drivers/media/dvb-frontends/mt312.c | 2 +- drivers/media/dvb-frontends/mt352.c | 2 +- drivers/media/dvb-frontends/nxt200x.c | 2 +- drivers/media/dvb-frontends/nxt6000.c | 2 +- drivers/media/dvb-frontends/or51132.c | 2 +- drivers/media/dvb-frontends/or51211.c | 2 +- drivers/media/dvb-frontends/s5h1409.c | 2 +- drivers/media/dvb-frontends/s5h1411.c | 2 +- drivers/media/dvb-frontends/s5h1420.c | 2 +- drivers/media/dvb-frontends/s5h1432.c | 2 +- drivers/media/dvb-frontends/s921.c | 2 +- drivers/media/dvb-frontends/si21xx.c | 2 +- drivers/media/dvb-frontends/sp887x.c | 2 +- drivers/media/dvb-frontends/stb0899_drv.c | 2 +- drivers/media/dvb-frontends/stb6000.c | 2 +- drivers/media/dvb-frontends/stb6100.c | 2 +- drivers/media/dvb-frontends/stv0288.c | 2 +- drivers/media/dvb-frontends/stv0297.c | 2 +- drivers/media/dvb-frontends/stv0299.c | 2 +- drivers/media/dvb-frontends/stv0367.c | 6 +++--- drivers/media/dvb-frontends/stv0900_core.c | 2 +- drivers/media/dvb-frontends/stv6110.c | 2 +- drivers/media/dvb-frontends/stv6110x.c | 2 +- drivers/media/dvb-frontends/tda10021.c | 2 +- drivers/media/dvb-frontends/tda10023.c | 2 +- drivers/media/dvb-frontends/tda10048.c | 2 +- drivers/media/dvb-frontends/tda1004x.c | 4 ++-- drivers/media/dvb-frontends/tda10086.c | 2 +- drivers/media/dvb-frontends/tda665x.c | 2 +- drivers/media/dvb-frontends/tda8083.c | 2 +- drivers/media/dvb-frontends/tda8261.c | 2 +- drivers/media/dvb-frontends/tda826x.c | 2 +- drivers/media/dvb-frontends/ts2020.c | 2 +- drivers/media/dvb-frontends/tua6100.c | 2 +- drivers/media/dvb-frontends/ves1820.c | 2 +- drivers/media/dvb-frontends/ves1x93.c | 2 +- drivers/media/dvb-frontends/zl10036.c | 2 +- drivers/media/dvb-frontends/zl10039.c | 2 +- drivers/media/dvb-frontends/zl10353.c | 2 +- drivers/media/pci/bt8xx/dst.c | 2 +- drivers/media/pci/bt8xx/dst_ca.c | 2 +- drivers/media/tuners/fc0011.c | 2 +- drivers/media/tuners/fc0012.c | 2 +- drivers/media/tuners/fc0013.c | 2 +- drivers/media/tuners/max2165.c | 2 +- drivers/media/tuners/mc44s803.c | 2 +- drivers/media/tuners/mt2060.c | 2 +- drivers/media/tuners/mt2131.c | 2 +- drivers/media/tuners/mt2266.c | 2 +- drivers/media/tuners/mxl5005s.c | 2 +- drivers/media/tuners/qt1010.c | 2 +- drivers/media/tuners/tda18218.c | 2 +- drivers/media/tuners/xc4000.c | 2 +- drivers/media/tuners/xc5000.c | 2 +- 102 files changed, 109 insertions(+), 109 deletions(-)
drivers/media/dvb-frontends/ascot2e.c +1 -1
@@ -542,7 +542,7 @@ struct dvb_frontend *ascot2e_attach(stru priv->i2c_address, priv->i2c);return fe; } -EXPORT_SYMBOL (ascot2e_attach); +EXPORT_SYMBOL_GPL (ascot2e_attach);MODULE_DESCRIPTION ("Sony ASCOT2E terr/cab tuner driver" );MODULE_AUTHOR ("[email protected]" );
drivers/media/dvb-frontends/atbm8830.c +1 -1
@@ -498,7 +498,7 @@ error_out:return NULL ; } -EXPORT_SYMBOL (atbm8830_attach); +EXPORT_SYMBOL_GPL (atbm8830_attach);MODULE_DESCRIPTION ("AltoBeam ATBM8830/8831 GB20600 demodulator driver" );MODULE_AUTHOR ("David T. L. Wong <[email protected]>" );
drivers/media/dvb-frontends/au8522_dig.c +1 -1
@@ -891,7 +891,7 @@ error:au8522_release_state (state);return NULL ; } -EXPORT_SYMBOL (au8522_attach); +EXPORT_SYMBOL_GPL (au8522_attach);static const struct dvb_frontend_ops au8522_ops = { .delsys = {SYS_ATSC ,SYS_DVBC_ANNEX_B },
drivers/media/dvb-frontends/bcm3510.c +1 -1
@@ -835,7 +835,7 @@ error:kfree (state);return NULL ; } -EXPORT_SYMBOL (bcm3510_attach); +EXPORT_SYMBOL_GPL (bcm3510_attach);static const struct dvb_frontend_ops bcm3510_ops = { .delsys = {SYS_ATSC ,SYS_DVBC_ANNEX_B },
drivers/media/dvb-frontends/cx22700.c +1 -1
@@ -444,4 +444,4 @@ MODULE_DESCRIPTION("Conexant CX22700 DVBMODULE_AUTHOR ("Holger Waechtler" );MODULE_LICENSE ("GPL" ); -EXPORT_SYMBOL (cx22700_attach); +EXPORT_SYMBOL_GPL (cx22700_attach);
drivers/media/dvb-frontends/cx22702.c +1 -1
@@ -616,7 +616,7 @@ error:kfree (state);return NULL ; } -EXPORT_SYMBOL (cx22702_attach); +EXPORT_SYMBOL_GPL (cx22702_attach);static const struct dvb_frontend_ops cx22702_ops = { .delsys = {SYS_DVBT },
drivers/media/dvb-frontends/cx24110.c +1 -1
@@ -666,4 +666,4 @@ MODULE_DESCRIPTION("Conexant CX24110 DVBMODULE_AUTHOR ("Peter Hettkamp" );MODULE_LICENSE ("GPL" ); -EXPORT_SYMBOL (cx24110_attach); +EXPORT_SYMBOL_GPL (cx24110_attach);
drivers/media/dvb-frontends/cx24113.c +1 -1
@@ -600,7 +600,7 @@ error:return NULL ; } -EXPORT_SYMBOL (cx24113_attach); +EXPORT_SYMBOL_GPL (cx24113_attach);module_param (debug, int,0644 );MODULE_PARM_DESC (debug,"Activates frontend debugging (default:0)" );
drivers/media/dvb-frontends/cx24116.c +1 -1
@@ -1145,7 +1145,7 @@ struct dvb_frontend *cx24116_attach(cons state->frontend.demodulator_priv = state;return &state->frontend; } -EXPORT_SYMBOL (cx24116_attach); +EXPORT_SYMBOL_GPL (cx24116_attach);/* * Initialise or wake up device
drivers/media/dvb-frontends/cx24120.c +1 -1
@@ -313,7 +313,7 @@ error:kfree (state);return NULL ; } -EXPORT_SYMBOL (cx24120_attach); +EXPORT_SYMBOL_GPL (cx24120_attach);static int cx24120_test_rom (struct cx24120_state *state) {
drivers/media/dvb-frontends/cx24123.c +1 -1
@@ -1105,7 +1105,7 @@ error:return NULL ; } -EXPORT_SYMBOL (cx24123_attach); +EXPORT_SYMBOL_GPL (cx24123_attach);static const struct dvb_frontend_ops cx24123_ops = { .delsys = {SYS_DVBS },
drivers/media/dvb-frontends/cxd2820r_core.c +1 -1
@@ -549,7 +549,7 @@ struct dvb_frontend *cxd2820r_attach(conreturn pdata.get_dvb_frontend (client); } -EXPORT_SYMBOL (cxd2820r_attach); +EXPORT_SYMBOL_GPL (cxd2820r_attach);static struct dvb_frontend *cxd2820r_get_dvb_frontend (struct i2c_client *client) {
drivers/media/dvb-frontends/cxd2841er.c +2 -2
@@ -3929,14 +3929,14 @@ struct dvb_frontend *cxd2841er_attach_s( {return cxd2841er_attach (cfg, i2c,SYS_DVBS ); } -EXPORT_SYMBOL (cxd2841er_attach_s); +EXPORT_SYMBOL_GPL (cxd2841er_attach_s);struct dvb_frontend *cxd2841er_attach_t_c (struct cxd2841er_config *cfg,struct i2c_adapter *i2c) {return cxd2841er_attach (cfg, i2c,0 ); } -EXPORT_SYMBOL (cxd2841er_attach_t_c); +EXPORT_SYMBOL_GPL (cxd2841er_attach_t_c);static const struct dvb_frontend_ops cxd2841er_dvbs_s2_ops = { .delsys = {SYS_DVBS ,SYS_DVBS2 },
drivers/media/dvb-frontends/cxd2880/cxd2880_top.c +1 -1
@@ -1950,7 +1950,7 @@ struct dvb_frontend *cxd2880_attach(strureturn fe; } -EXPORT_SYMBOL (cxd2880_attach); +EXPORT_SYMBOL_GPL (cxd2880_attach);MODULE_DESCRIPTION ("Sony CXD2880 DVB-T2/T tuner + demod driver" );MODULE_AUTHOR ("Sony Semiconductor Solutions Corporation" );
drivers/media/dvb-frontends/dib0070.c +1 -1
@@ -767,7 +767,7 @@ free_mem: fe->tuner_priv =NULL ;return NULL ; } -EXPORT_SYMBOL (dib0070_attach); +EXPORT_SYMBOL_GPL (dib0070_attach);MODULE_AUTHOR ("Patrick Boettcher <[email protected]>" );MODULE_DESCRIPTION ("Driver for the DiBcom 0070 base-band RF Tuner" );
drivers/media/dvb-frontends/dib0090.c +2 -2
@@ -2643,7 +2643,7 @@ struct dvb_frontend *dib0090_register(streturn NULL ; } -EXPORT_SYMBOL (dib0090_register); +EXPORT_SYMBOL_GPL (dib0090_register);struct dvb_frontend *dib0090_fw_register (struct dvb_frontend *fe,struct i2c_adapter *i2c,const struct dib0090_config *config) {
@@ -2669,7 +2669,7 @@ free_mem: fe->tuner_priv =NULL ;return NULL ; } -EXPORT_SYMBOL (dib0090_fw_register); +EXPORT_SYMBOL_GPL (dib0090_fw_register);MODULE_AUTHOR ("Patrick Boettcher <[email protected]>" );MODULE_AUTHOR ("Olivier Grenie <[email protected]>" );
drivers/media/dvb-frontends/dib3000mb.c +1 -1
@@ -819,4 +819,4 @@ MODULE_AUTHOR(DRIVER_AUTHOR);MODULE_DESCRIPTION (DRIVER_DESC );MODULE_LICENSE ("GPL" ); -EXPORT_SYMBOL (dib3000mb_attach); +EXPORT_SYMBOL_GPL (dib3000mb_attach);
drivers/media/dvb-frontends/dib3000mc.c +1 -1
@@ -938,7 +938,7 @@ error:kfree (st);return NULL ; } -EXPORT_SYMBOL (dib3000mc_attach); +EXPORT_SYMBOL_GPL (dib3000mc_attach);static const struct dvb_frontend_ops dib3000mc_ops = { .delsys = {SYS_DVBT },
drivers/media/dvb-frontends/dib7000m.c +1 -1
@@ -1437,7 +1437,7 @@ error:kfree (st);return NULL ; } -EXPORT_SYMBOL (dib7000m_attach); +EXPORT_SYMBOL_GPL (dib7000m_attach);static const struct dvb_frontend_ops dib7000m_ops = { .delsys = {SYS_DVBT },
drivers/media/dvb-frontends/dib7000p.c +1 -1
@@ -2818,7 +2818,7 @@ void *dib7000p_attach(struct dib7000p_opreturn ops; } -EXPORT_SYMBOL (dib7000p_attach); +EXPORT_SYMBOL_GPL (dib7000p_attach);static const struct dvb_frontend_ops dib7000p_ops = { .delsys = {SYS_DVBT },
drivers/media/dvb-frontends/dib8000.c +1 -1
@@ -4530,7 +4530,7 @@ void *dib8000_attach(struct dib8000_opsreturn ops; } -EXPORT_SYMBOL (dib8000_attach); +EXPORT_SYMBOL_GPL (dib8000_attach);MODULE_AUTHOR ("Olivier Grenie <[email protected], Patrick Boettcher <[email protected]>" );MODULE_DESCRIPTION ("Driver for the DiBcom 8000 ISDB-T demodulator" );
drivers/media/dvb-frontends/dib9000.c +1 -1
@@ -2547,7 +2547,7 @@ error:kfree (st);return NULL ; } -EXPORT_SYMBOL (dib9000_attach); +EXPORT_SYMBOL_GPL (dib9000_attach);static const struct dvb_frontend_ops dib9000_ops = { .delsys = {SYS_DVBT },
drivers/media/dvb-frontends/drx39xyj/drxj.c +1 -1
@@ -12367,7 +12367,7 @@ error:return NULL ; } -EXPORT_SYMBOL (drx39xxj_attach); +EXPORT_SYMBOL_GPL (drx39xxj_attach);static const struct dvb_frontend_ops drx39xxj_ops = { .delsys = {SYS_ATSC ,SYS_DVBC_ANNEX_B },
drivers/media/dvb-frontends/drxd_hard.c +1 -1
@@ -2972,7 +2972,7 @@ error:kfree (state);return NULL ; } -EXPORT_SYMBOL (drxd_attach); +EXPORT_SYMBOL_GPL (drxd_attach);MODULE_DESCRIPTION ("DRXD driver" );MODULE_AUTHOR ("Micronas" );
drivers/media/dvb-frontends/drxk_hard.c +1 -1
@@ -6867,7 +6867,7 @@ error:kfree (state);return NULL ; } -EXPORT_SYMBOL (drxk_attach); +EXPORT_SYMBOL_GPL (drxk_attach);MODULE_DESCRIPTION ("DRX-K driver" );MODULE_AUTHOR ("Ralph Metzler" );
drivers/media/dvb-frontends/ds3000.c +1 -1
@@ -871,7 +871,7 @@ struct dvb_frontend *ds3000_attach(constds3000_set_voltage (&state->frontend,SEC_VOLTAGE_OFF );return &state->frontend; } -EXPORT_SYMBOL (ds3000_attach); +EXPORT_SYMBOL_GPL (ds3000_attach);static int ds3000_set_carrier_offset (struct dvb_frontend *fe,s32 carrier_offset_khz)
drivers/media/dvb-frontends/dvb-pll.c +1 -1
@@ -875,7 +875,7 @@ out:return NULL ; } -EXPORT_SYMBOL (dvb_pll_attach); +EXPORT_SYMBOL_GPL (dvb_pll_attach); static int
drivers/media/dvb-frontends/ec100.c +1 -1
@@ -309,7 +309,7 @@ error:kfree (state);return NULL ; } -EXPORT_SYMBOL (ec100_attach); +EXPORT_SYMBOL_GPL (ec100_attach);static const struct dvb_frontend_ops ec100_ops = { .delsys = {SYS_DVBT },
drivers/media/dvb-frontends/helene.c +2 -2
@@ -1034,7 +1034,7 @@ struct dvb_frontend *helene_attach_s(str priv->i2c_address, priv->i2c);return fe; } -EXPORT_SYMBOL (helene_attach_s); +EXPORT_SYMBOL_GPL (helene_attach_s); struct dvb_frontend *helene_attach(struct dvb_frontend *fe, const struct helene_config *config,
@@ -1070,7 +1070,7 @@ struct dvb_frontend *helene_attach(struc priv->i2c_address, priv->i2c);return fe; } -EXPORT_SYMBOL (helene_attach); +EXPORT_SYMBOL_GPL (helene_attach);static int helene_probe (struct i2c_client *client,const struct i2c_device_id *id)
drivers/media/dvb-frontends/horus3a.c +1 -1
@@ -404,7 +404,7 @@ struct dvb_frontend *horus3a_attach(stru priv->i2c_address, priv->i2c);return fe; } -EXPORT_SYMBOL (horus3a_attach); +EXPORT_SYMBOL_GPL (horus3a_attach);MODULE_DESCRIPTION ("Sony HORUS3A satellite tuner driver" );MODULE_AUTHOR ("Sergey Kozlov <[email protected]>" );
drivers/media/dvb-frontends/isl6405.c +1 -1
@@ -155,7 +155,7 @@ struct dvb_frontend *isl6405_attach(strureturn fe; } -EXPORT_SYMBOL (isl6405_attach); +EXPORT_SYMBOL_GPL (isl6405_attach);MODULE_DESCRIPTION ("Driver for lnb supply and control ic isl6405" );MODULE_AUTHOR ("Hartmut Hackmann & Oliver Endriss" );
drivers/media/dvb-frontends/isl6421.c +1 -1
@@ -227,7 +227,7 @@ struct dvb_frontend *isl6421_attach(strureturn fe; } -EXPORT_SYMBOL (isl6421_attach); +EXPORT_SYMBOL_GPL (isl6421_attach);MODULE_DESCRIPTION ("Driver for lnb supply and control ic isl6421" );MODULE_AUTHOR ("Andrew de Quincey & Oliver Endriss" );
drivers/media/dvb-frontends/isl6423.c +1 -1
@@ -301,7 +301,7 @@ exit: fe->sec_priv =NULL ;return NULL ; } -EXPORT_SYMBOL (isl6423_attach); +EXPORT_SYMBOL_GPL (isl6423_attach);MODULE_DESCRIPTION ("ISL6423 SEC" );MODULE_AUTHOR ("Manu Abraham" );
drivers/media/dvb-frontends/itd1000.c +1 -1
@@ -399,7 +399,7 @@ struct dvb_frontend *itd1000_attach(strureturn fe; } -EXPORT_SYMBOL (itd1000_attach); +EXPORT_SYMBOL_GPL (itd1000_attach);MODULE_AUTHOR ("Patrick Boettcher <[email protected]>" );MODULE_DESCRIPTION ("Integrant ITD1000 driver" );
drivers/media/dvb-frontends/ix2505v.c +1 -1
@@ -311,7 +311,7 @@ error:kfree (state);return NULL ; } -EXPORT_SYMBOL (ix2505v_attach); +EXPORT_SYMBOL_GPL (ix2505v_attach);module_param_named (debug, ix2505v_debug, int,0644 );MODULE_PARM_DESC (debug,"Turn on/off frontend debugging (default:off)." );
drivers/media/dvb-frontends/l64781.c +1 -1
@@ -605,4 +605,4 @@ MODULE_DESCRIPTION("LSI L64781 DVB-T DemMODULE_AUTHOR ("Holger Waechtler, Marko Kohtala" );MODULE_LICENSE ("GPL" ); -EXPORT_SYMBOL (l64781_attach); +EXPORT_SYMBOL_GPL (l64781_attach);
drivers/media/dvb-frontends/lg2160.c +1 -1
@@ -1436,7 +1436,7 @@ struct dvb_frontend *lg2160_attach(constreturn &state->frontend; } -EXPORT_SYMBOL (lg2160_attach); +EXPORT_SYMBOL_GPL (lg2160_attach);MODULE_DESCRIPTION ("LG Electronics LG216x ATSC/MH Demodulator Driver" );MODULE_AUTHOR ("Michael Krufky <[email protected]>" );
drivers/media/dvb-frontends/lgdt3305.c +1 -1
@@ -1158,7 +1158,7 @@ fail:kfree (state);return NULL ; } -EXPORT_SYMBOL (lgdt3305_attach); +EXPORT_SYMBOL_GPL (lgdt3305_attach);static const struct dvb_frontend_ops lgdt3304_ops = { .delsys = {SYS_ATSC ,SYS_DVBC_ANNEX_B },
drivers/media/dvb-frontends/lgdt3306a.c +1 -1
@@ -1887,7 +1887,7 @@ fail:kfree (state);return NULL ; } -EXPORT_SYMBOL (lgdt3306a_attach); +EXPORT_SYMBOL_GPL (lgdt3306a_attach);#ifdef DBG_DUMP
drivers/media/dvb-frontends/lgdt330x.c +1 -1
@@ -938,7 +938,7 @@ struct dvb_frontend *lgdt330x_attach(conreturn lgdt330x_get_dvb_frontend (client); } -EXPORT_SYMBOL (lgdt330x_attach); +EXPORT_SYMBOL_GPL (lgdt330x_attach);static const struct dvb_frontend_ops lgdt3302_ops = { .delsys = {SYS_ATSC ,SYS_DVBC_ANNEX_B },
drivers/media/dvb-frontends/lgs8gxx.c +1 -1
@@ -1053,7 +1053,7 @@ error_out:return NULL ; } -EXPORT_SYMBOL (lgs8gxx_attach); +EXPORT_SYMBOL_GPL (lgs8gxx_attach);MODULE_DESCRIPTION ("Legend Silicon LGS8913/LGS8GXX DMB-TH demodulator driver" );MODULE_AUTHOR ("David T. L. Wong <[email protected]>" );
drivers/media/dvb-frontends/lnbh25.c +1 -1
@@ -182,7 +182,7 @@ struct dvb_frontend *lnbh25_attach(struc __func__, priv->i2c_address);return fe; } -EXPORT_SYMBOL (lnbh25_attach); +EXPORT_SYMBOL_GPL (lnbh25_attach);MODULE_DESCRIPTION ("ST LNBH25 driver" );MODULE_AUTHOR ("[email protected]" );
drivers/media/dvb-frontends/lnbp21.c +2 -2
@@ -169,7 +169,7 @@ struct dvb_frontend *lnbh24_attach(strucreturn lnbx2x_attach (fe, i2c, override_set, override_clear, i2c_addr,LNBH24_TTX ); } -EXPORT_SYMBOL (lnbh24_attach); +EXPORT_SYMBOL_GPL (lnbh24_attach); struct dvb_frontend *lnbp21_attach(struct dvb_frontend *fe, struct i2c_adapter *i2c, u8 override_set,
@@ -178,7 +178,7 @@ struct dvb_frontend *lnbp21_attach(strucreturn lnbx2x_attach (fe, i2c, override_set, override_clear,0x08 ,LNBP21_ISEL ); } -EXPORT_SYMBOL (lnbp21_attach); +EXPORT_SYMBOL_GPL (lnbp21_attach);MODULE_DESCRIPTION ("Driver for lnb supply and control ic lnbp21, lnbh24" );MODULE_AUTHOR ("Oliver Endriss, Igor M. Liplianin" );
drivers/media/dvb-frontends/lnbp22.c +1 -1
@@ -139,7 +139,7 @@ struct dvb_frontend *lnbp22_attach(strucreturn fe; } -EXPORT_SYMBOL (lnbp22_attach); +EXPORT_SYMBOL_GPL (lnbp22_attach);MODULE_DESCRIPTION ("Driver for lnb supply and control ic lnbp22" );MODULE_AUTHOR ("Dominik Kuhlen" );
drivers/media/dvb-frontends/m88ds3103.c +1 -1
@@ -1293,7 +1293,7 @@ struct dvb_frontend *m88ds3103_attach(co *tuner_i2c_adapter = pdata.get_i2c_adapter (client);return pdata.get_dvb_frontend (client); } -EXPORT_SYMBOL (m88ds3103_attach); +EXPORT_SYMBOL_GPL (m88ds3103_attach);static const struct dvb_frontend_ops m88ds3103_ops = { .delsys = {SYS_DVBS ,SYS_DVBS2 },
drivers/media/dvb-frontends/m88rs2000.c +1 -1
@@ -819,7 +819,7 @@ error:return NULL ; } -EXPORT_SYMBOL (m88rs2000_attach); +EXPORT_SYMBOL_GPL (m88rs2000_attach);MODULE_DESCRIPTION ("M88RS2000 DVB-S Demodulator driver" );MODULE_AUTHOR ("Malcolm Priestley [email protected]" );
drivers/media/dvb-frontends/mb86a16.c +1 -1
@@ -1863,6 +1863,6 @@ error:kfree (state);return NULL ; } -EXPORT_SYMBOL (mb86a16_attach); +EXPORT_SYMBOL_GPL (mb86a16_attach);MODULE_LICENSE ("GPL" );MODULE_AUTHOR ("Manu Abraham" );
drivers/media/dvb-frontends/mb86a20s.c +1 -1
@@ -2097,7 +2097,7 @@ struct dvb_frontend *mb86a20s_attach(condev_info (&i2c->dev,"Detected a Fujitsu mb86a20s frontend\n" );return &state->frontend; } -EXPORT_SYMBOL (mb86a20s_attach); +EXPORT_SYMBOL_GPL (mb86a20s_attach);static const struct dvb_frontend_ops mb86a20s_ops = { .delsys = {SYS_ISDBT },
drivers/media/dvb-frontends/mt312.c +1 -1
@@ -840,7 +840,7 @@ error:kfree (state);return NULL ; } -EXPORT_SYMBOL (mt312_attach); +EXPORT_SYMBOL_GPL (mt312_attach);module_param (debug, int,0644 );MODULE_PARM_DESC (debug,"Turn on/off frontend debugging (default:off)." );
drivers/media/dvb-frontends/mt352.c +1 -1
@@ -603,4 +603,4 @@ MODULE_DESCRIPTION("Zarlink MT352 DVB-TMODULE_AUTHOR ("Holger Waechtler, Daniel Mack, Antonio Mancuso" );MODULE_LICENSE ("GPL" ); -EXPORT_SYMBOL (mt352_attach); +EXPORT_SYMBOL_GPL (mt352_attach);
drivers/media/dvb-frontends/nxt200x.c +1 -1
@@ -1242,5 +1242,5 @@ MODULE_DESCRIPTION("NXT200X (ATSC 8VSB &MODULE_AUTHOR ("Kirk Lapray, Michael Krufky, Jean-Francois Thibert, and Taylor Jacob" );MODULE_LICENSE ("GPL" ); -EXPORT_SYMBOL (nxt200x_attach); +EXPORT_SYMBOL_GPL (nxt200x_attach);
drivers/media/dvb-frontends/nxt6000.c +1 -1
@@ -633,4 +633,4 @@ MODULE_DESCRIPTION("NxtWave NXT6000 DVB-MODULE_AUTHOR ("Florian Schirmer" );MODULE_LICENSE ("GPL" ); -EXPORT_SYMBOL (nxt6000_attach); +EXPORT_SYMBOL_GPL (nxt6000_attach);
drivers/media/dvb-frontends/or51132.c +1 -1
@@ -616,4 +616,4 @@ MODULE_AUTHOR("Kirk Lapray");MODULE_AUTHOR ("Trent Piepho" );MODULE_LICENSE ("GPL" ); -EXPORT_SYMBOL (or51132_attach); +EXPORT_SYMBOL_GPL (or51132_attach);
drivers/media/dvb-frontends/or51211.c +1 -1
@@ -561,5 +561,5 @@ MODULE_DESCRIPTION("Oren OR51211 VSB [pcMODULE_AUTHOR ("Kirk Lapray" );MODULE_LICENSE ("GPL" ); -EXPORT_SYMBOL (or51211_attach); +EXPORT_SYMBOL_GPL (or51211_attach);
drivers/media/dvb-frontends/s5h1409.c +1 -1
@@ -993,7 +993,7 @@ error:kfree (state);return NULL ; } -EXPORT_SYMBOL (s5h1409_attach); +EXPORT_SYMBOL_GPL (s5h1409_attach);static const struct dvb_frontend_ops s5h1409_ops = { .delsys = {SYS_ATSC ,SYS_DVBC_ANNEX_B },
drivers/media/dvb-frontends/s5h1411.c +1 -1
@@ -912,7 +912,7 @@ error:kfree (state);return NULL ; } -EXPORT_SYMBOL (s5h1411_attach); +EXPORT_SYMBOL_GPL (s5h1411_attach);static const struct dvb_frontend_ops s5h1411_ops = { .delsys = {SYS_ATSC ,SYS_DVBC_ANNEX_B },
drivers/media/dvb-frontends/s5h1420.c +1 -1
@@ -928,7 +928,7 @@ error:kfree (state);return NULL ; } -EXPORT_SYMBOL (s5h1420_attach); +EXPORT_SYMBOL_GPL (s5h1420_attach);static const struct dvb_frontend_ops s5h1420_ops = { .delsys = {SYS_DVBS },
drivers/media/dvb-frontends/s5h1432.c +1 -1
@@ -364,7 +364,7 @@ struct dvb_frontend *s5h1432_attach(consreturn &state->frontend; } -EXPORT_SYMBOL (s5h1432_attach); +EXPORT_SYMBOL_GPL (s5h1432_attach);static const struct dvb_frontend_ops s5h1432_ops = { .delsys = {SYS_DVBT },
drivers/media/dvb-frontends/s921.c +1 -1
@@ -503,7 +503,7 @@ struct dvb_frontend *s921_attach(const sreturn &state->frontend; } -EXPORT_SYMBOL (s921_attach); +EXPORT_SYMBOL_GPL (s921_attach);static const struct dvb_frontend_ops s921_ops = { .delsys = {SYS_ISDBT },
drivers/media/dvb-frontends/si21xx.c +1 -1
@@ -943,7 +943,7 @@ error:kfree (state);return NULL ; } -EXPORT_SYMBOL (si21xx_attach); +EXPORT_SYMBOL_GPL (si21xx_attach);module_param (debug, int,0644 );MODULE_PARM_DESC (debug,"Turn on/off frontend debugging (default:off)." );
drivers/media/dvb-frontends/sp887x.c +1 -1
@@ -625,4 +625,4 @@ MODULE_PARM_DESC(debug, "Turn on/off froMODULE_DESCRIPTION ("Spase sp887x DVB-T demodulator driver" );MODULE_LICENSE ("GPL" ); -EXPORT_SYMBOL (sp887x_attach); +EXPORT_SYMBOL_GPL (sp887x_attach);
drivers/media/dvb-frontends/stb0899_drv.c +1 -1
@@ -1650,7 +1650,7 @@ error:kfree (state);return NULL ; } -EXPORT_SYMBOL (stb0899_attach); +EXPORT_SYMBOL_GPL (stb0899_attach);MODULE_PARM_DESC (verbose,"Set Verbosity level" );MODULE_AUTHOR ("Manu Abraham" );MODULE_DESCRIPTION ("STB0899 Multi-Std frontend" );
drivers/media/dvb-frontends/stb6000.c +1 -1
@@ -245,7 +245,7 @@ struct dvb_frontend *stb6000_attach(strureturn fe; } -EXPORT_SYMBOL (stb6000_attach); +EXPORT_SYMBOL_GPL (stb6000_attach);module_param (debug, int,0644 );MODULE_PARM_DESC (debug,"Turn on/off frontend debugging (default:off)." );
drivers/media/dvb-frontends/stb6100.c +1 -1
@@ -569,7 +569,7 @@ static void stb6100_release(struct dvb_fkfree (state); } -EXPORT_SYMBOL (stb6100_attach); +EXPORT_SYMBOL_GPL (stb6100_attach);MODULE_PARM_DESC (verbose,"Set Verbosity level" );MODULE_AUTHOR ("Manu Abraham" );
drivers/media/dvb-frontends/stv0288.c +1 -1
@@ -602,7 +602,7 @@ error:return NULL ; } -EXPORT_SYMBOL (stv0288_attach); +EXPORT_SYMBOL_GPL (stv0288_attach);module_param (debug_legacy_dish_switch, int,0444 ); MODULE_PARM_DESC(debug_legacy_dish_switch,
drivers/media/dvb-frontends/stv0297.c +1 -1
@@ -722,4 +722,4 @@ MODULE_DESCRIPTION("ST STV0297 DVB-C DemMODULE_AUTHOR ("Dennis Noermann and Andrew de Quincey" );MODULE_LICENSE ("GPL" ); -EXPORT_SYMBOL (stv0297_attach); +EXPORT_SYMBOL_GPL (stv0297_attach);
drivers/media/dvb-frontends/stv0299.c +1 -1
@@ -763,4 +763,4 @@ MODULE_DESCRIPTION("ST STV0299 DVB DemodMODULE_AUTHOR ("Ralph Metzler, Holger Waechtler, Peter Schildmann, Felix Domke, Andreas Oberritter, Andrew de Quincey, Kenneth Aafly" );MODULE_LICENSE ("GPL" ); -EXPORT_SYMBOL (stv0299_attach); +EXPORT_SYMBOL_GPL (stv0299_attach);
drivers/media/dvb-frontends/stv0367.c +3 -3
@@ -1760,7 +1760,7 @@ error:kfree (state);return NULL ; } -EXPORT_SYMBOL (stv0367ter_attach); +EXPORT_SYMBOL_GPL (stv0367ter_attach);static int stv0367cab_gate_ctrl (struct dvb_frontend *fe,int enable) {
@@ -2933,7 +2933,7 @@ error:kfree (state);return NULL ; } -EXPORT_SYMBOL (stv0367cab_attach); +EXPORT_SYMBOL_GPL (stv0367cab_attach);/* * Functions for operation on Digital Devices hardware
@@ -3354,7 +3354,7 @@ error:kfree (state);return NULL ; } -EXPORT_SYMBOL (stv0367ddb_attach); +EXPORT_SYMBOL_GPL (stv0367ddb_attach);MODULE_PARM_DESC (debug,"Set debug" );MODULE_PARM_DESC (i2c_debug,"Set i2c debug" );
drivers/media/dvb-frontends/stv0900_core.c +1 -1
@@ -1967,7 +1967,7 @@ error:kfree (state);return NULL ; } -EXPORT_SYMBOL (stv0900_attach); +EXPORT_SYMBOL_GPL (stv0900_attach);MODULE_PARM_DESC (debug,"Set debug" );
drivers/media/dvb-frontends/stv6110.c +1 -1
@@ -437,7 +437,7 @@ struct dvb_frontend *stv6110_attach(strureturn fe; } -EXPORT_SYMBOL (stv6110_attach); +EXPORT_SYMBOL_GPL (stv6110_attach);module_param (debug, int,0644 );MODULE_PARM_DESC (debug,"Turn on/off frontend debugging (default:off)." );
drivers/media/dvb-frontends/stv6110x.c +1 -1
@@ -408,7 +408,7 @@ const struct stv6110x_devctl *stv6110x_aprintk (KERN_INFO "%s: Attaching STV6110x\n" , __func__);return stv6110x->devctl; } -EXPORT_SYMBOL (stv6110x_attach); +EXPORT_SYMBOL_GPL (stv6110x_attach);MODULE_AUTHOR ("Manu Abraham" );MODULE_DESCRIPTION ("STV6110x Silicon tuner" );
drivers/media/dvb-frontends/tda10021.c +1 -1
@@ -525,4 +525,4 @@ MODULE_DESCRIPTION("Philips TDA10021 DVBMODULE_AUTHOR ("Ralph Metzler, Holger Waechtler, Markus Schulz" );MODULE_LICENSE ("GPL" ); -EXPORT_SYMBOL (tda10021_attach); +EXPORT_SYMBOL_GPL (tda10021_attach);
drivers/media/dvb-frontends/tda10023.c +1 -1
@@ -606,4 +606,4 @@ MODULE_DESCRIPTION("Philips TDA10023 DVBMODULE_AUTHOR ("Georg Acher, Hartmut Birr" );MODULE_LICENSE ("GPL" ); -EXPORT_SYMBOL (tda10023_attach); +EXPORT_SYMBOL_GPL (tda10023_attach);
drivers/media/dvb-frontends/tda10048.c +1 -1
@@ -1150,7 +1150,7 @@ error:kfree (state);return NULL ; } -EXPORT_SYMBOL (tda10048_attach); +EXPORT_SYMBOL_GPL (tda10048_attach);static const struct dvb_frontend_ops tda10048_ops = { .delsys = {SYS_DVBT },
drivers/media/dvb-frontends/tda1004x.c +2 -2
@@ -1391,5 +1391,5 @@ MODULE_DESCRIPTION("Philips TDA10045H &MODULE_AUTHOR ("Andrew de Quincey & Robert Schlabbach" );MODULE_LICENSE ("GPL" ); -EXPORT_SYMBOL (tda10045_attach); -EXPORT_SYMBOL (tda10046_attach); +EXPORT_SYMBOL_GPL (tda10045_attach); +EXPORT_SYMBOL_GPL (tda10046_attach);
drivers/media/dvb-frontends/tda10086.c +1 -1
@@ -777,4 +777,4 @@ MODULE_DESCRIPTION("Philips TDA10086 DVBMODULE_AUTHOR ("Andrew de Quincey" );MODULE_LICENSE ("GPL" ); -EXPORT_SYMBOL (tda10086_attach); +EXPORT_SYMBOL_GPL (tda10086_attach);
drivers/media/dvb-frontends/tda665x.c +1 -1
@@ -239,7 +239,7 @@ struct dvb_frontend *tda665x_attach(strureturn fe; } -EXPORT_SYMBOL (tda665x_attach); +EXPORT_SYMBOL_GPL (tda665x_attach);MODULE_DESCRIPTION ("TDA665x driver" );MODULE_AUTHOR ("Manu Abraham" );
drivers/media/dvb-frontends/tda8083.c +1 -1
@@ -493,4 +493,4 @@ MODULE_DESCRIPTION("Philips TDA8083 DVB-MODULE_AUTHOR ("Ralph Metzler, Holger Waechtler" );MODULE_LICENSE ("GPL" ); -EXPORT_SYMBOL (tda8083_attach); +EXPORT_SYMBOL_GPL (tda8083_attach);
drivers/media/dvb-frontends/tda8261.c +1 -1
@@ -200,7 +200,7 @@ exit:return NULL ; } -EXPORT_SYMBOL (tda8261_attach); +EXPORT_SYMBOL_GPL (tda8261_attach);MODULE_AUTHOR ("Manu Abraham" );MODULE_DESCRIPTION ("TDA8261 8PSK/QPSK Tuner" );
drivers/media/dvb-frontends/tda826x.c +1 -1
@@ -177,7 +177,7 @@ struct dvb_frontend *tda826x_attach(strureturn fe; } -EXPORT_SYMBOL (tda826x_attach); +EXPORT_SYMBOL_GPL (tda826x_attach);module_param (debug, int,0644 );MODULE_PARM_DESC (debug,"Turn on/off frontend debugging (default:off)." );
drivers/media/dvb-frontends/ts2020.c +1 -1
@@ -534,7 +534,7 @@ struct dvb_frontend *ts2020_attach(strucreturn fe; } -EXPORT_SYMBOL (ts2020_attach); +EXPORT_SYMBOL_GPL (ts2020_attach);/* * We implement own regmap locking due to legacy DVB attach which uses frontend
drivers/media/dvb-frontends/tua6100.c +1 -1
@@ -194,7 +194,7 @@ struct dvb_frontend *tua6100_attach(stru fe->tuner_priv = priv;return fe; } -EXPORT_SYMBOL (tua6100_attach); +EXPORT_SYMBOL_GPL (tua6100_attach);MODULE_DESCRIPTION ("DVB tua6100 driver" );MODULE_AUTHOR ("Andrew de Quincey" );
drivers/media/dvb-frontends/ves1820.c +1 -1
@@ -446,4 +446,4 @@ MODULE_DESCRIPTION("VLSI VES1820 DVB-C DMODULE_AUTHOR ("Ralph Metzler, Holger Waechtler" );MODULE_LICENSE ("GPL" ); -EXPORT_SYMBOL (ves1820_attach); +EXPORT_SYMBOL_GPL (ves1820_attach);
drivers/media/dvb-frontends/ves1x93.c +1 -1
@@ -553,4 +553,4 @@ MODULE_DESCRIPTION("VLSI VES1x93 DVB-S DMODULE_AUTHOR ("Ralph Metzler" );MODULE_LICENSE ("GPL" ); -EXPORT_SYMBOL (ves1x93_attach); +EXPORT_SYMBOL_GPL (ves1x93_attach);
drivers/media/dvb-frontends/zl10036.c +1 -1
@@ -504,7 +504,7 @@ error:kfree (state);return NULL ; } -EXPORT_SYMBOL (zl10036_attach); +EXPORT_SYMBOL_GPL (zl10036_attach);module_param_named (debug, zl10036_debug, int,0644 );MODULE_PARM_DESC (debug,"Turn on/off frontend debugging (default:off)." );
drivers/media/dvb-frontends/zl10039.c +1 -1
@@ -304,7 +304,7 @@ error:kfree (state);return NULL ; } -EXPORT_SYMBOL (zl10039_attach); +EXPORT_SYMBOL_GPL (zl10039_attach);module_param (debug, int,0644 );MODULE_PARM_DESC (debug,"Turn on/off frontend debugging (default:off)." );
drivers/media/dvb-frontends/zl10353.c +1 -1
@@ -675,4 +675,4 @@ MODULE_DESCRIPTION("Zarlink ZL10353 DVB-MODULE_AUTHOR ("Chris Pascoe" );MODULE_LICENSE ("GPL" ); -EXPORT_SYMBOL (zl10353_attach); +EXPORT_SYMBOL_GPL (zl10353_attach);
drivers/media/pci/bt8xx/dst.c +1 -1
@@ -1733,7 +1733,7 @@ struct dst_state *dst_attach(struct dst_return state;/* Manu (DST is a card not a frontend) */ } -EXPORT_SYMBOL (dst_attach); +EXPORT_SYMBOL_GPL (dst_attach);static const struct dvb_frontend_ops dst_dvbt_ops = { .delsys = {SYS_DVBT },
drivers/media/pci/bt8xx/dst_ca.c +1 -1
@@ -680,7 +680,7 @@ struct dvb_device *dst_ca_attach(structreturn NULL ; } -EXPORT_SYMBOL (dst_ca_attach); +EXPORT_SYMBOL_GPL (dst_ca_attach);MODULE_DESCRIPTION ("DST DVB-S/T/C Combo CA driver" );MODULE_AUTHOR ("Manu Abraham" );
drivers/media/tuners/fc0011.c +1 -1
@@ -508,7 +508,7 @@ struct dvb_frontend *fc0011_attach(strucreturn fe; } -EXPORT_SYMBOL (fc0011_attach); +EXPORT_SYMBOL_GPL (fc0011_attach);MODULE_DESCRIPTION ("Fitipower FC0011 silicon tuner driver" );MODULE_AUTHOR ("Michael Buesch <[email protected]>" );
drivers/media/tuners/fc0012.c +1 -1
@@ -504,7 +504,7 @@ err:return fe; } -EXPORT_SYMBOL (fc0012_attach); +EXPORT_SYMBOL_GPL (fc0012_attach);MODULE_DESCRIPTION ("Fitipower FC0012 silicon tuner driver" );MODULE_AUTHOR ("Hans-Frieder Vogt <[email protected]>" );
drivers/media/tuners/fc0013.c +1 -1
@@ -618,7 +618,7 @@ struct dvb_frontend *fc0013_attach(strucreturn fe; } -EXPORT_SYMBOL (fc0013_attach); +EXPORT_SYMBOL_GPL (fc0013_attach);MODULE_DESCRIPTION ("Fitipower FC0013 silicon tuner driver" );MODULE_AUTHOR ("Hans-Frieder Vogt <[email protected]>" );
drivers/media/tuners/max2165.c +1 -1
@@ -420,7 +420,7 @@ struct dvb_frontend *max2165_attach(strureturn fe; } -EXPORT_SYMBOL (max2165_attach); +EXPORT_SYMBOL_GPL (max2165_attach);MODULE_AUTHOR ("David T. L. Wong <[email protected]>" );MODULE_DESCRIPTION ("Maxim MAX2165 silicon tuner driver" );
drivers/media/tuners/mc44s803.c +1 -1
@@ -366,7 +366,7 @@ error:kfree (priv);return NULL ; } -EXPORT_SYMBOL (mc44s803_attach); +EXPORT_SYMBOL_GPL (mc44s803_attach);MODULE_AUTHOR ("Jochen Friedrich" );MODULE_DESCRIPTION ("Freescale MC44S803 silicon tuner driver" );
drivers/media/tuners/mt2060.c +1 -1
@@ -450,7 +450,7 @@ struct dvb_frontend * mt2060_attach(strureturn fe; } -EXPORT_SYMBOL (mt2060_attach); +EXPORT_SYMBOL_GPL (mt2060_attach);static int mt2060_probe (struct i2c_client *client,const struct i2c_device_id *id)
drivers/media/tuners/mt2131.c +1 -1
@@ -284,7 +284,7 @@ struct dvb_frontend * mt2131_attach(stru fe->tuner_priv = priv;return fe; } -EXPORT_SYMBOL (mt2131_attach); +EXPORT_SYMBOL_GPL (mt2131_attach);MODULE_AUTHOR ("Steven Toth" );MODULE_DESCRIPTION ("Microtune MT2131 silicon tuner driver" );
drivers/media/tuners/mt2266.c +1 -1
@@ -345,7 +345,7 @@ struct dvb_frontend * mt2266_attach(strumt2266_calibrate (priv);return fe; } -EXPORT_SYMBOL (mt2266_attach); +EXPORT_SYMBOL_GPL (mt2266_attach);MODULE_AUTHOR ("Olivier DANET" );MODULE_DESCRIPTION ("Microtune MT2266 silicon tuner driver" );
drivers/media/tuners/mxl5005s.c +1 -1
@@ -4114,7 +4114,7 @@ struct dvb_frontend *mxl5005s_attach(str fe->tuner_priv = state;return fe; } -EXPORT_SYMBOL (mxl5005s_attach); +EXPORT_SYMBOL_GPL (mxl5005s_attach);MODULE_DESCRIPTION ("MaxLinear MXL5005S silicon tuner driver" );MODULE_AUTHOR ("Steven Toth" );
drivers/media/tuners/qt1010.c +1 -1
@@ -446,7 +446,7 @@ struct dvb_frontend * qt1010_attach(stru fe->tuner_priv = priv;return fe; } -EXPORT_SYMBOL (qt1010_attach); +EXPORT_SYMBOL_GPL (qt1010_attach);MODULE_DESCRIPTION ("Quantek QT1010 silicon tuner driver" );MODULE_AUTHOR ("Antti Palosaari <[email protected]>" );
drivers/media/tuners/tda18218.c +1 -1
@@ -345,7 +345,7 @@ struct dvb_frontend *tda18218_attach(strreturn fe; } -EXPORT_SYMBOL (tda18218_attach); +EXPORT_SYMBOL_GPL (tda18218_attach);MODULE_DESCRIPTION ("NXP TDA18218HN silicon tuner driver" );MODULE_AUTHOR ("Antti Palosaari <[email protected]>" );
drivers/media/tuners/xc4000.c +1 -1
@@ -1754,7 +1754,7 @@ fail2:xc4000_release (fe);return NULL ; } -EXPORT_SYMBOL (xc4000_attach); +EXPORT_SYMBOL_GPL (xc4000_attach);MODULE_AUTHOR ("Steven Toth, Davide Ferri" );MODULE_DESCRIPTION ("Xceive xc4000 silicon tuner driver" );
drivers/media/tuners/xc5000.c +1 -1
@@ -1470,7 +1470,7 @@ fail:xc5000_release (fe);return NULL ; } -EXPORT_SYMBOL (xc5000_attach); +EXPORT_SYMBOL_GPL (xc5000_attach);MODULE_AUTHOR ("Steven Toth" );MODULE_DESCRIPTION ("Xceive xc5000 silicon tuner driver" );
Re: [PATCH 4.19 178/273] media: dvb: symbol fixup for dvb_attach()
Quoted 8 lines · Greg Kroah-Hartman
4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <[email protected]>
commit
86495af1171e1feec79faa9b64c05c89f46e41d1upstream.
Quoted 8 lines
In commit
9011e49d54dc("modules: only allowsymbol_getofEXPORT_SYMBOL_GPLmodules") the use ofsymbol_getis properly restricted to GPL-only marked symbols. This interacts oddly with the DVB logic which only usesdvb_attach()to load the dvb driver which then usessymbol_get().Fix this up by properly marking all of the
dvb_attachattach symbols asEXPORT_SYMBOL_GPL().
[...]
This (and other) backports missed a couple of affected exports:
- sp8870_attach in drivers/media/dvb-frontends/sp8870.c (renamed to drivers/staging/media/av7110/sp8870.c upstream)
- xc2028_attach in drivers/media/tuners/tuner-xc2028.c (renamed to drivers/media/tuners/xc2028.c upstream)
Ben.
Signature · 4 lines
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption]
would be development of an easy way to factor large prime numbers.
- Bill GatesGreg Kroah-Hartman
maintainerRe: [PATCH 4.19 178/273] media: dvb: symbol fixup for dvb_attach()
Quoted 17 lines · Ben Hutchings
Quoted 8 lines · Greg Kroah-Hartman
4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Kroah-Hartman <[email protected]>
commit
86495af1171e1feec79faa9b64c05c89f46e41d1upstream.Quoted 8 lines
In commit
9011e49d54dc("modules: only allowsymbol_getofEXPORT_SYMBOL_GPLmodules") the use ofsymbol_getis properly restricted to GPL-only marked symbols. This interacts oddly with the DVB logic which only usesdvb_attach()to load the dvb driver which then usessymbol_get().Fix this up by properly marking all of the
dvb_attachattach symbols asEXPORT_SYMBOL_GPL().
Quoted 8 lines
[...]
This (and other) backports missed a couple of affected exports:
-
sp8870_attachindrivers/media/dvb-frontends/sp8870.c(renamed todrivers/staging/media/av7110/sp8870.cupstream)
-xc2028_attachindrivers/media/tuners/tuner-xc2028.c(renamed todrivers/media/tuners/xc2028.cupstream)
Thanks for catching this, fixed up now for 4.14.y and 4.19.y.
greg k-h
Greg Kroah-Hartman
maintainerPATCH 179/273 ntb: Drop packets when qp link is down
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Jiang <[email protected]>
commit f195a1a6fe416882984f8bd6c61afc1383171860 upstream.
Currently when the transport receive packets after netdev has closed the transport returns error and triggers tx errors to be incremented and carrier to be stopped. There is no reason to return error if the device is already closed. Drop the packet and return 0.
--- drivers/ntb/ntb_transport.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/ntb/ntb_transport.c +5 -1
@@ -2046,9 +2046,13 @@ int ntb_transport_tx_enqueue(struct ntb_struct ntb_queue_entry *entry;int rc; -if (!qp || !qp->link_is_up || !len) +if (!qp || !len)return -EINVAL ; +/* If the qp link is down already, just ignore. */ +if (!qp->link_is_up) +return 0 ; + entry =ntb_list_rm (&qp->ntb_tx_free_q_lock, &qp->tx_free_q);if (!entry) { qp->tx_err_no_buf++;
Greg Kroah-Hartman
maintainerPATCH 180/273 ntb: Clean up tx tail index on link down
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Jiang <[email protected]>
commit cc79bd2738c2d40aba58b2be6ce47dc0e471df0e upstream.
The tx tail index is not reset when the link goes down. This causes the tail index to go out of sync when the link goes down and comes back up. Refactor the ntb_qp_link_down_reset() and reset the tail index as well.
--- drivers/ntb/ntb_transport.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-)
drivers/ntb/ntb_transport.c +9 -2
@@ -746,7 +746,7 @@ static int ntb_set_mw(struct ntb_transporeturn 0 ; } -static void ntb_qp_link_down_reset (struct ntb_transport_qp *qp) +static void ntb_qp_link_context_reset (struct ntb_transport_qp *qp) { qp->link_is_up = false; qp->active = false;
@@ -769,6 +769,13 @@ static void ntb_qp_link_down_reset(struc qp->tx_async =0 ; } +static void ntb_qp_link_down_reset (struct ntb_transport_qp *qp) +{ +ntb_qp_link_context_reset (qp); +if (qp->remote_rx_info) + qp->remote_rx_info->entry = qp->rx_max_entry -1 ; +} +static void ntb_qp_link_cleanup (struct ntb_transport_qp *qp) {struct ntb_transport_ctx *nt = qp->transport;
@@ -993,7 +1000,7 @@ static int ntb_transport_init_queue(stru qp->ndev = nt->ndev; qp->client_ready = false; qp->event_handler =NULL ; -ntb_qp_link_down_reset (qp); +ntb_qp_link_context_reset (qp);if (mw_num < qp_count % mw_count) num_qps_mw = qp_count / mw_count +1 ;
Greg Kroah-Hartman
maintainerPATCH 181/273 ntb: Fix calculation ntb_transport_tx_free_entry()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dave Jiang <[email protected]>
commit 5a7693e6bbf19b22fd6c1d2c4b7beb0a03969e2c upstream.
ntb_transport_tx_free_entry() never returns 0 with the current calculation. If head == tail, then it would return qp->tx_max_entry. Change compare to tail >= head and when they are equal, a 0 would be returned.
--- drivers/ntb/ntb_transport.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/ntb/ntb_transport.c +1 -1
@@ -2199,7 +2199,7 @@ unsigned int ntb_transport_tx_free_entryunsigned int head = qp->tx_index;unsigned int tail = qp->remote_rx_info->entry; -return tail > head ? tail - head : qp->tx_max_entry + tail - head; +return tail >= head ? tail - head : qp->tx_max_entry + tail - head; }EXPORT_SYMBOL_GPL (ntb_transport_tx_free_entry);
Greg Kroah-Hartman
maintainerPATCH 182/273 Revert "PCI: Mark NVIDIA T4 GPUs to avoid bus reset"
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Bjorn Helgaas <[email protected]>
commit 5260bd6d36c83c5b269c33baaaf8c78e520908b0 upstream.
This reverts commit d5af729dc2071273f14cbb94abbc60608142fd83.
d5af729dc207 ("PCI: Mark NVIDIA T4 GPUs to avoid bus reset") avoided Secondary Bus Reset on the T4 because the reset seemed to not work when the T4 was directly attached to a Root Port.
But NVIDIA thinks the issue is probably related to some issue with the Root Port, not with the T4. The T4 provides neither PM nor FLR reset, so masking bus reset compromises this device for assignment scenarios.
Revert d5af729dc207 as requested by Wu Zongyong. This will leave SBR broken in the specific configuration Wu tested, as it was in v6.5, so Wu will debug that further.
--- drivers/pci/quirks.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/pci/quirks.c +1 -1
@@ -3472,7 +3472,7 @@ static void quirk_no_bus_reset(struct pc*/ static void quirk_nvidia_no_bus_reset (struct pci_dev *dev) { -if ((dev->device &0xffc0 ) ==0x2340 || dev->device ==0x1eb8 ) +if ((dev->device &0xffc0 ) ==0x2340 )quirk_no_bus_reset (dev); } DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID,
Greg Kroah-Hartman
maintainerPATCH 183/273 procfs: block chmod on /proc/thread-self/comm
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Aleksa Sarai <[email protected]>
commit ccf61486fe1e1a48e18c638d1813cda77b3c0737 upstream.
Due to an oversight in commit 1b3044e39a89 ("procfs: fix pthread cross-thread naming if !PR_DUMPABLE") in switching from REG to NOD, chmod operations on /proc/thread-self/comm were no longer blocked as they are on almost all other procfs files.
A very similar situation with /proc/self/environ was used to as a root exploit a long time ago, but procfs has SB_I_NOEXEC so this is simply a correctness issue.
Ref: https://lwn.net/Articles/191954/
Ref: 6d76fa58b050 ("Don't allow chmod() on the /proc/<pid>/ files")
Message-Id: <[email protected]>
--- fs/proc/base.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
fs/proc/base.c +2 -1
@@ -3338,7 +3338,8 @@ static int proc_tid_comm_permission(stru }static const struct inode_operations proc_tid_comm_inode_operations = { - .permission = proc_tid_comm_permission, + .setattr = proc_setattr, + .permission = proc_tid_comm_permission, };/*
Greg Kroah-Hartman
maintainerPATCH 184/273 parisc: Fix /proc/cpuinfo output for lscpu
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Helge Deller <[email protected]>
commit 9f5ba4b3e1b3c123eeca5d2d09161e8720048b5c upstream.
The lscpu command is broken since commit cab56b51ec0e ("parisc: Fix device names in /proc/iomem") added the PA pathname to all PA devices, includig the CPUs.
lscpu parses /proc/cpuinfo and now believes it found different CPU types since every CPU is listed with an unique identifier (PA pathname).
Fix this problem by simply dropping the PA pathname when listing the CPUs in /proc/cpuinfo. There is no need to show the pathname in this procfs file.
--- arch/parisc/kernel/processor.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-)
arch/parisc/kernel/processor.c +10 -3
@@ -377,10 +377,18 @@ int show_cpuinfo (struct seq_file *m, void *v) { unsigned long cpu; +char cpu_name[60 ], *p; + +/* strip PA path from CPU name to not confuse lscpu */ +strlcpy (cpu_name,per_cpu (cpu_data,0 ).dev->name,sizeof (cpu_name)); + p =strrchr (cpu_name,'[' ); +if (p) + *(--p) =0 ;for_each_online_cpu (cpu) { -const struct cpuinfo_parisc *cpuinfo = &per_cpu (cpu_data, cpu);#ifdef CONFIG_SMP +const struct cpuinfo_parisc *cpuinfo = &per_cpu (cpu_data, cpu); +if (0 == cpuinfo->hpa)continue ;#endif
@@ -425,8 +433,7 @@ show_cpuinfo (struct seq_file *m, void *seq_printf (m,"model\t\t: %s - %s\n" , boot_cpu_data.pdc.sys_model_name, - cpuinfo->dev ? - cpuinfo->dev->name :"Unknown" ); + cpu_name); seq_printf(m, "hversion\t: 0x%08x\n" "sversion\t: 0x%08x\n",
Greg Kroah-Hartman
maintainerPATCH 185/273 dlm: fix plock lookup when using multiple lockspaces
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Aring <[email protected]>
commit 7c53e847ff5e97f033fdd31f71949807633d506b upstream.
All posix lock ops, for all lockspaces (gfs2 file systems) are sent to userspace (dlm_controld) through a single misc device. The dlm_controld daemon reads the ops from the misc device and sends them to other cluster nodes using separate, per-lockspace cluster api communication channels. The ops for a single lockspace are ordered at this level, so that the results are received in the same sequence that the requests were sent. When the results are sent back to the kernel via the misc device, they are again funneled through the single misc device for all lockspaces. When the dlm code in the kernel processes the results from the misc device, these results will be returned in the same sequence that the requests were sent, on a per-lockspace basis. A recent change in this request/reply matching code missed the "per-lockspace" check (fsid comparison) when matching request and reply, so replies could be incorrectly matched to requests from other lockspaces.
--- fs/dlm/plock.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
fs/dlm/plock.c +3 -3
@@ -469,7 +469,8 @@ static ssize_t dev_write(struct file *fi } }else {list_for_each_entry (iter, &recv_list, list) { -if (!iter->info.wait) { +if (!iter->info.wait && + iter->info.fsid == info.fsid) { op = iter;break ; }
@@ -481,8 +482,7 @@ static ssize_t dev_write(struct file *fiif (info.wait)WARN_ON (op->info.optype !=DLM_PLOCK_OP_LOCK );else -WARN_ON (op->info.fsid != info.fsid || - op->info.number != info.number || +WARN_ON (op->info.number != info.number || op->info.owner != info.owner || op->info.optype != info.optype);
Greg Kroah-Hartman
maintainerPATCH 186/273 dccp: Fix out of bounds access in DCCP error handler
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jann Horn <[email protected]>
commit 977ad86c2a1bcaf58f01ab98df5cc145083c489c upstream.
There was a previous attempt to fix an out-of-bounds access in the DCCP error handlers, but that fix assumed that the error handlers only want to access the first 8 bytes of the DCCP header. Actually, they also look at the DCCP sequence number, which is stored beyond 8 bytes, so an explicit pskb_may_pull() is required.
--- net/dccp/ipv4.c | 13 +++++++++---- net/dccp/ipv6.c | 15 ++++++++++----- 2 files changed, 19 insertions(+), 9 deletions(-)
net/dccp/ipv4.c +9 -4
@@ -247,12 +247,17 @@ static void dccp_v4_err(struct sk_buff *int err;struct net *net =dev_net (skb->dev); -/* Only need dccph_dport & dccph_sport which are the first -* 4 bytes in dccp header. +/* For the first __dccp_basic_hdr_len() check, we only need dh->dccph_x, +* which is in byte 7 of the dccp header. * Our caller (icmp_socket_deliver()) already pulled 8 bytes for us. +* +* Later on, we want to access the sequence number fields, which are +* beyond 8 bytes, so we have to pskb_may_pull() ourselves. */ - BUILD_BUG_ON(offsetofend(struct dccp_hdr, dccph_sport) > 8); - BUILD_BUG_ON(offsetofend(struct dccp_hdr, dccph_dport) > 8); + dh = (struct dccp_hdr *)(skb->data + offset); +if (!pskb_may_pull (skb, offset +__dccp_basic_hdr_len (dh))) +return ; + iph = (struct iphdr *)skb->data; dh = (struct dccp_hdr *)(skb->data + offset); sk = __inet_lookup_established(net, &dccp_hashinfo,
net/dccp/ipv6.c +10 -5
@@ -71,7 +71,7 @@ static inline __u64 dccp_v6_init_sequencstatic void dccp_v6_err (struct sk_buff *skb,struct inet6_skb_parm *opt,u8 type,u8 code,int offset,__be32 info) { -const struct ipv6hdr *hdr = (const struct ipv6hdr *)skb->data; +const struct ipv6hdr *hdr;const struct dccp_hdr *dh;struct dccp_sock *dp;struct ipv6_pinfo *np;
@@ -80,12 +80,17 @@ static void dccp_v6_err(struct sk_buff *__u64 seq;struct net *net =dev_net (skb->dev); -/* Only need dccph_dport & dccph_sport which are the first -* 4 bytes in dccp header. +/* For the first __dccp_basic_hdr_len() check, we only need dh->dccph_x, +* which is in byte 7 of the dccp header. * Our caller (icmpv6_notify()) already pulled 8 bytes for us. +* +* Later on, we want to access the sequence number fields, which are +* beyond 8 bytes, so we have to pskb_may_pull() ourselves. */ - BUILD_BUG_ON(offsetofend(struct dccp_hdr, dccph_sport) > 8); - BUILD_BUG_ON(offsetofend(struct dccp_hdr, dccph_dport) > 8); + dh = (struct dccp_hdr *)(skb->data + offset); +if (!pskb_may_pull (skb, offset +__dccp_basic_hdr_len (dh))) +return ; + hdr = (const struct ipv6hdr *)skb->data; dh = (struct dccp_hdr *)(skb->data + offset); sk = __inet6_lookup_established(net, &dccp_hashinfo,
Greg Kroah-Hartman
maintainerPATCH 187/273 crypto: stm32 - fix loop iterating through scatterlist for DMA
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Bourgoin <[email protected]>
commit d9c83f71eeceed2cb54bb78be84f2d4055fd9a1f upstream.
We were reading the length of the scatterlist sg after copying value of tsg inside.
So we are using the size of the previous scatterlist and for the first one we are using an unitialised value.
Fix this by copying tsg in sg[0] before reading the size.
--- drivers/crypto/stm32/stm32-hash.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/crypto/stm32/stm32-hash.c +1 -1
@@ -578,9 +578,9 @@ static int stm32_hash_dma_send(struct st }for_each_sg (rctx->sg, tsg, rctx->nents, i) { + sg[0 ] = *tsg; len = sg->length; - sg[0 ] = *tsg;if (sg_is_last (sg)) {if (hdev->dma_mode ==1 ) { len = (ALIGN (sg->length,16 ) -16 );
Greg Kroah-Hartman
maintainerPATCH 188/273 cpufreq: brcmstb-avs-cpufreq: Fix -Warray-bounds bug
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gustavo A. R. Silva <[email protected]>
commit e520d0b6be950ce3738cf4b9bd3b392be818f1dc upstream.
Allocate extra space for terminating element at:
drivers/cpufreq/brcmstb-avs-cpufreq.c:
449 table[i].frequency = CPUFREQ_TABLE_END;
and add code comment to make this clear.
This fixes the following -Warray-bounds warning seen after building
ARM with multi_v7_defconfig (GCC 13):
In function 'brcm_avs_get_freq_table',
inlined from 'brcm_avs_cpufreq_init' at drivers/cpufreq/brcmstb-avs-cpufreq.c:623:15:drivers/cpufreq/brcmstb-avs-cpufreq.c:449:28: warning: array subscript 5 is outside array bounds of 'void[60]' [-Warray-bounds=]
449 | table[i].frequency = CPUFREQ_TABLE_END;
In file included from include/linux/node.h:18,
from include/linux/cpu.h:17,
from include/linux/cpufreq.h:12,
from drivers/cpufreq/brcmstb-avs-cpufreq.c:44:
In function 'devm_kmalloc_array',
inlined from 'devm_kcalloc' at include/linux/device.h:328:9,
inlined from 'brcm_avs_get_freq_table' at drivers/cpufreq/brcmstb-avs-cpufreq.c:437:10,
inlined from 'brcm_avs_cpufreq_init' at drivers/cpufreq/brcmstb-avs-cpufreq.c:623:15:include/linux/device.h:323:16: note: at offset 60 into object of size 60 allocated by 'devm_kmalloc'
323 | return devm_kmalloc(dev, bytes, flags);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help us make progress towards globally enabling -Warray-bounds.
--- drivers/cpufreq/brcmstb-avs-cpufreq.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/cpufreq/brcmstb-avs-cpufreq.c +5 -1
@@ -410,7 +410,11 @@ brcm_avs_get_freq_table(struct device *dif (ret)return ERR_PTR (ret); - table =devm_kcalloc (dev,AVS_PSTATE_MAX +1 ,sizeof (*table), +/* +* We allocate space for the 5 different P-STATES AVS, +* plus extra space for a terminating element. +*/ + table =devm_kcalloc (dev,AVS_PSTATE_MAX +1 +1 ,sizeof (*table),GFP_KERNEL );if (!table)return ERR_PTR (-ENOMEM );
Greg Kroah-Hartman
maintainerPATCH 189/273 X.509: if signature is unsupported skip validation
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thore Sommer <[email protected]>
commit ef5b52a631f8c18353e80ccab8408b963305510c upstream.
When the hash algorithm for the signature is not available the digest size is 0 and the signature in the certificate is marked as unsupported.
When validating a self-signed certificate, this needs to be checked, because otherwise trying to validate the signature will fail with an warning:
Loading compiled-in X.509 certificates
WARNING: CPU: 0 PID: 1 at crypto/rsa-pkcs1pad.c:537 \ pkcs1pad_verify+0x46/0x12c
...
Problem loading in-kernel X.509 certificate (-22)
--- crypto/asymmetric_keys/x509_public_key.c | 5 +++++ 1 file changed, 5 insertions(+)
crypto/asymmetric_keys/x509_public_key.c +5 -0
@@ -134,6 +134,11 @@ int x509_check_for_self_signed(struct x5if (strcmp (cert->pub->pkey_algo, cert->sig->pkey_algo) !=0 ) goto out; +if (cert->unsupported_sig) { + ret =0 ; + goto out; + } + ret =public_key_verify_signature (cert->pub, cert->sig);if (ret <0 ) {if (ret == -ENOPKG ) {
Greg Kroah-Hartman
maintainerPATCH 190/273 net: handle ARPHRD_PPP in dev_is_mac_header_xmit()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicolas Dichtel <[email protected]>
commit a4f39c9f14a634e4cd35fcd338c239d11fcc73fc upstream.
The goal is to support a bpf_redirect() from an ethernet device (ingress) to a ppp device (egress).
The l2 header is added automatically by the ppp driver, thus the ethernet header should be removed.
--- include/linux/if_arp.h | 4 ++++ 1 file changed, 4 insertions(+)
include/linux/if_arp.h +4 -0
@@ -56,6 +56,10 @@ static inline bool dev_is_mac_header_xmicase ARPHRD_NONE :case ARPHRD_RAWIP :case ARPHRD_PIMREG : +/* PPP adds its l2 header automatically in ppp_start_xmit(). +* This makes it look like an l3 device to __bpf_redirect() and tcf_mirred_init(). +*/ +case ARPHRD_PPP :return false;default :return true;
Greg Kroah-Hartman
maintainerPATCH 191/273 pstore/ram: Check start of empty przs during init
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Enlin Mu <[email protected]>
commit fe8c3623ab06603eb760444a032d426542212021 upstream.
After commit 30696378f68a ("pstore/ram: Do not treat empty buffers as valid"), initialization would assume a prz was valid after seeing that the buffer_size is zero (regardless of the buffer start position). This unchecked start value means it could be outside the bounds of the buffer, leading to future access panics when written to:
sysdump_panic_event+0x3b4/0x5b8 atomic_notifier_call_chain+0x54/0x90 panic+0x1c8/0x42c die+0x29c/0x2a8 die_kernel_fault+0x68/0x78 __do_kernel_fault+0x1c4/0x1e0 do_bad_area+0x40/0x100 do_translation_fault+0x68/0x80 do_mem_abort+0x68/0xf8 el1_da+0x1c/0xc0 __raw_writeb+0x38/0x174 __memcpy_toio+0x40/0xac persistent_ram_update+0x44/0x12c persistent_ram_write+0x1a8/0x1b8 ramoops_pstore_write+0x198/0x1e8 pstore_console_write+0x94/0xe0 ...
To avoid this, also check if the prz start is 0 during the initialization phase. If not, the next prz sanity check case will discover it (start > size) and zap the buffer back to a sane state.
--- fs/pstore/ram_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/pstore/ram_core.c +1 -1
@@ -500,7 +500,7 @@ static int persistent_ram_post_init(stru sig ^=PERSISTENT_RAM_SIG ;if (prz->buffer->sig == sig) { -if (buffer_size (prz) ==0 ) { +if (buffer_size (prz) ==0 &&buffer_start (prz) ==0 ) {pr_debug ("found existing empty buffer\n" );return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 192/273 PCI/ATS: Add inline to pci_prg_resp_pasid_required()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kuppuswamy Sathyanarayanan <[email protected]>
commit fff42928ade591969836ff49888d063b829ac888 upstream.
Fix unused function warning when compiled with CONFIG_PCI_PASID disabled.
--- include/linux/pci-ats.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/linux/pci-ats.h +1 -1
@@ -67,7 +67,7 @@ static inline int pci_max_pasids(structreturn -EINVAL ; } -static int pci_prg_resp_pasid_required (struct pci_dev *pdev) +static inline int pci_prg_resp_pasid_required (struct pci_dev *pdev) {return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 193/273 sc16is7xx: Set iobase to device index
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Daniel Mack <[email protected]>
[ Upstream commit 5da6b1c079e6804a81e63ab8337224cbd2148c91 ]
Some derivates of sc16is7xx devices expose more than one tty device to userspace. If multiple such devices exist in a system, userspace currently has no clean way to infer which tty maps to which physical line.
Set the .iobase value to the relative index within the device to allow infering the order through sysfs.
Stable-dep-of: 2861ed4d6e6d ("serial: sc16is7xx: fix broken port 0 uart init")
--- drivers/tty/serial/sc16is7xx.c | 1 + 1 file changed, 1 insertion(+)
drivers/tty/serial/sc16is7xx.c +1 -0
@@ -1264,6 +1264,7 @@ static int sc16is7xx_probe(struct device *dev, s->p[i].port.type =PORT_SC16IS7XX ; s->p[i].port.fifosize =SC16IS7XX_FIFO_SIZE ; s->p[i].port.flags =UPF_FIXED_TYPE |UPF_LOW_LATENCY ; + s->p[i].port.iobase = i; s->p[i].port.iotype =UPIO_PORT ; s->p[i].port.uartclk = freq; s->p[i].port.rs485_config = sc16is7xx_config_rs485;
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 194/273 serial: sc16is7xx: fix broken port 0 uart init
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hugo Villeneuve <[email protected]>
[ Upstream commit 2861ed4d6e6d1a2c9de9bf5b0abd996c2dc673d0 ]
The sc16is7xx_config_rs485() function is called only for the second port (index 1, channel B), causing initialization problems for the first port.
For the sc16is7xx driver, port->membase and port->mapbase are not set, and their default values are 0. And we set port->iobase to the device index. This means that when the first device is registered using the uart_add_one_port() function, the following values will be in the port structure:
port->membase = 0
port->mapbase = 0
port->iobase = 0Therefore, the function uart_configure_port() in serial_core.c will exit early because of the following check:
/* * If there isn't a port here, don't do anything further. */ if (!port->iobase && !port->mapbase && !port->membase) return;
Typically, I2C and SPI drivers do not set port->membase and port->mapbase.
The max310x driver sets port->membase to ~0 (all ones). By implementing the same change in this driver, uart_configure_port() is now correctly executed for all ports.
--- drivers/tty/serial/sc16is7xx.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/tty/serial/sc16is7xx.c +6 -0
@@ -1265,6 +1265,12 @@ static int sc16is7xx_probe(struct device *dev, s->p[i].port.fifosize =SC16IS7XX_FIFO_SIZE ; s->p[i].port.flags =UPF_FIXED_TYPE |UPF_LOW_LATENCY ; s->p[i].port.iobase = i; +/* +* Use all ones as membase to make sure uart_configure_port() in +* serial_core.c does not abort for SPI/I2C devices where the +* membase address is not applicable. +*/ + s->p[i].port.membase = (void __iomem *)~0 ; s->p[i].port.iotype =UPIO_PORT ; s->p[i].port.uartclk = freq; s->p[i].port.rs485_config = sc16is7xx_config_rs485;
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 195/273 usb: typec: tcpci: clear the fault status bit
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Marco Felsch <[email protected]>
[ Upstream commit 23e60c8daf5ec2ab1b731310761b668745fcf6ed ]
According the "USB Type-C Port Controller Interface Specification v2.0" the TCPC sets the fault status register bit-7 (AllRegistersResetToDefault) once the registers have been reset to their default values.
This triggers an alert(-irq) on PTN5110 devices albeit we do mask the fault-irq, which may cause a kernel hang. Fix this generically by writing a one to the corresponding bit-7.
--- drivers/usb/typec/tcpci.c | 4 ++++ drivers/usb/typec/tcpci.h | 1 + 2 files changed, 5 insertions(+)
drivers/usb/typec/tcpci.c +4 -0
@@ -379,6 +379,10 @@ static int tcpci_init(struct tcpc_dev *tcpc)if (time_after (jiffies, timeout))return -ETIMEDOUT ; + ret =tcpci_write16 (tcpci,TCPC_FAULT_STATUS ,TCPC_FAULT_STATUS_ALL_REG_RST_TO_DEFAULT ); +if (ret <0 ) +return ret; +/* Handle vendor init */ if (tcpci->data->init) { ret = tcpci->data->init (tcpci, tcpci->data);
drivers/usb/typec/tcpci.h +1 -0
@@ -72,6 +72,7 @@#define TCPC_POWER_STATUS_VBUS_PRES BIT(2)#define TCPC_FAULT_STATUS 0x1f +#define TCPC_FAULT_STATUS_ALL_REG_RST_TO_DEFAULT BIT(7)#define TCPC_COMMAND 0x23#define TCPC_CMD_WAKE_I2C 0x11
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 196/273 udf: initialize newblock to 0
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tom Rix <[email protected]>
commit 23970a1c9475b305770fd37bebfec7a10f263787 upstream.
The clang build reports this errorfs/udf/inode.c:805:6: error: variable 'newblock' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized]
if (*err < 0)
^~~~~~~~newblock is never set before error handling jump. Initialize newblock to 0 and remove redundant settings.
Message-Id: <[email protected]>
--- fs/udf/inode.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
fs/udf/inode.c +1 -3
@@ -689,7 +689,7 @@ static sector_t inode_getblk(struct inodstruct kernel_lb_addr eloc, tmpeloc;int c =1 ;loff_t lbcount =0 , b_off =0 ; -udf_pblk_t newblocknum, newblock; +udf_pblk_t newblocknum, newblock =0 ;sector_t offset =0 ;int8_t etype;struct udf_inode_info *iinfo =UDF_I (inode);
@@ -792,7 +792,6 @@ static sector_t inode_getblk(struct inod ret =udf_do_extend_file (inode, &prev_epos, laarr, hole_len);if (ret <0 ) { *err = ret; - newblock =0 ; goto out_free; } c =0 ;
@@ -855,7 +854,6 @@ static sector_t inode_getblk(struct inod goal, err);if (!newblocknum) { *err = -ENOSPC ; - newblock =0 ; goto out_free; }if (isBeyondEOF)
Greg Kroah-Hartman
maintainerPATCH 197/273 scsi: qla2xxx: fix inconsistent TMF timeout
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Quinn Tran <[email protected]>
commit 009e7fe4a1ed52276b332842a6b6e23b07200f2d upstream.
Different behavior were experienced of session being torn down vs not when TMF is timed out. When FW detects the time out, the session is torn down. When driver detects the time out, the session is not torn down.
Allow TMF error to return to upper layer without session tear down.
--- drivers/scsi/qla2xxx/qla_isr.c | 1 - 1 file changed, 1 deletion(-)
drivers/scsi/qla2xxx/qla_isr.c +0 -1
@@ -2673,7 +2673,6 @@ check_scsi_status:case CS_PORT_BUSY :case CS_INCOMPLETE :case CS_PORT_UNAVAILABLE : -case CS_TIMEOUT :case CS_RESET :/*
Greg Kroah-Hartman
maintainerPATCH 198/273 scsi: qla2xxx: Turn off noisy message log
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Quinn Tran <[email protected]>
commit 8ebaa45163a3fedc885c1dc7d43ea987a2f00a06 upstream.
Some consider noisy log as test failure. Turn off noisy message log.
--- drivers/scsi/qla2xxx/qla_nvme.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/scsi/qla2xxx/qla_nvme.c +1 -1
@@ -518,7 +518,7 @@ static int qla_nvme_post_cmd(struct nvme rval =qla2x00_start_nvme_mq (sp);if (rval !=QLA_SUCCESS ) { -ql_log (ql_log_warn, vha,0x212d , +ql_dbg (ql_dbg_io + ql_dbg_verbose, vha,0x212d ,"qla2x00_start_nvme_mq failed = %d\n" , rval);atomic_dec (&sp->ref_count);wake_up (&sp->nvme_ls_waitq);
Greg Kroah-Hartman
maintainerPATCH 199/273 fbdev/ep93xx-fb: Do not assign to struct fb_info.dev
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Zimmermann <[email protected]>
commit f90a0e5265b60cdd3c77990e8105f79aa2fac994 upstream.
Do not assing the Linux device to struct fb_info.dev. The call to register_framebuffer() initializes the field to the fbdev device. Drivers should not override its value.
Fixes a bug where the driver incorrectly decreases the hardware device's reference counter and leaks the fbdev device.
v2:
* add Fixes tag (Dan)
--- drivers/video/fbdev/ep93xx-fb.c | 1 - 1 file changed, 1 deletion(-)
drivers/video/fbdev/ep93xx-fb.c +0 -1
@@ -478,7 +478,6 @@ static int ep93xxfb_probe(struct platforif (!info)return -ENOMEM ; - info->dev = &pdev->dev;platform_set_drvdata (pdev, info); fbi = info->par; fbi->mach_info = mach_info;
Greg Kroah-Hartman
maintainerPATCH 200/273 drm/ast: Fix DRAM init on AST2200
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Thomas Zimmermann <[email protected]>
commit 4cfe75f0f14f044dae66ad0e6eea812d038465d9 upstream.
Fix the test for the AST2200 in the DRAM initialization. The value in ast->chip has to be compared against an enum constant instead of a numerical value.
This bug got introduced when the driver was first imported into the kernel.
--- drivers/gpu/drm/ast/ast_post.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/gpu/drm/ast/ast_post.c +1 -1
@@ -291,7 +291,7 @@ static void ast_init_dram_reg(struct drm ; }while (ast_read32 (ast,0x10100 ) !=0xa8 ); }else {/* AST2100/1100 */ -if (ast->chip ==AST2100 || ast->chip ==2200 ) +if (ast->chip ==AST2100 || ast->chip ==AST2200 ) dram_reg_info = ast2100_dram_table_data;else dram_reg_info = ast1100_dram_table_data;
Greg Kroah-Hartman
maintainerPATCH 201/273 parisc: led: Fix LAN receive and transmit LEDs
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Helge Deller <[email protected]>
commit 4db89524b084f712a887256391fc19d9f66c8e55 upstream.
Fix the LAN receive and LAN transmit LEDs, which where swapped up to now.
--- arch/parisc/include/asm/led.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
arch/parisc/include/asm/led.h +2 -2
@@ -11,8 +11,8 @@#define LED1 0x02#define LED0 0x01/* bottom (or furthest left) LED */ -#define LED_LAN_TX LED0/* for LAN transmit activity */ -#define LED_LAN_RCV LED1/* for LAN receive activity */ +#define LED_LAN_RCV LED0/* for LAN receive activity */ +#define LED_LAN_TX LED1/* for LAN transmit activity */ #define LED_DISK_IO LED2/* for disk activity */ #define LED_HEARTBEAT LED3/* heartbeat */
Greg Kroah-Hartman
maintainerPATCH 202/273 parisc: led: Reduce CPU overhead for disk & lan LED computation
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Helge Deller <[email protected]>
commit 358ad816e52d4253b38c2f312e6b1cbd89e0dbf7 upstream.
Older PA-RISC machines have LEDs which show the disk- and LAN-activity. The computation is done in software and takes quite some time, e.g. on a J6500 this may take up to 60% time of one CPU if the machine is loaded via network traffic.
Since most people don't care about the LEDs, start with LEDs disabled and just show a CPU heartbeat LED. The disk and LAN LEDs can be turned on manually via /proc/pdc/led.
--- drivers/parisc/led.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/parisc/led.c +2 -2
@@ -60,8 +60,8 @@static int led_type__read_mostly =-1 ;static unsigned char lastleds;/* LED state from most recent update */ static unsigned int led_heartbeat__read_mostly =1 ; -static unsigned int led_diskio__read_mostly =1 ; -static unsigned int led_lanrxtx__read_mostly =1 ; +static unsigned int led_diskio__read_mostly ; +static unsigned int led_lanrxtx__read_mostly ;static char lcd_text[32 ]__read_mostly ;static char lcd_text_default[32 ]__read_mostly ;static int lcd_no_led_support__read_mostly =0 ;/* KittyHawk doesn't support LED on its LCD */
Greg Kroah-Hartman
maintainerPATCH 203/273 clk: qcom: gcc-mdm9615: use proper parent for pll0_vote clock
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dmitry Baryshkov <[email protected]>
commit 1583694bb4eaf186f17131dbc1b83d6057d2749b upstream.
The pll0_vote clock definitely should have pll0 as a parent (instead of pll8).
--- drivers/clk/qcom/gcc-mdm9615.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/clk/qcom/gcc-mdm9615.c +1 -1
@@ -66,7 +66,7 @@ static struct clk_regmap pll0_vote = { .enable_mask = BIT(0), .hw.init = &(struct clk_init_data ){ .name ="pll0_vote" , - .parent_names = (const char *[]){"pll8" }, + .parent_names = (const char *[]){"pll0" }, .num_parents =1 , .ops = &clk_pll_vote_ops, },
Greg Kroah-Hartman
maintainerPATCH 204/273 soc: qcom: qmi_encdec: Restrict string length in decode
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chris Lew <[email protected]>
commit 8d207400fd6b79c92aeb2f33bb79f62dff904ea2 upstream.
The QMI TLV value for strings in a lot of qmi element info structures account for null terminated strings with MAX_LEN + 1. If a string is actually MAX_LEN + 1 length, this will cause an out of bounds access when the NULL character is appended in decoding.
--- drivers/soc/qcom/qmi_encdec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/soc/qcom/qmi_encdec.c +2 -2
@@ -534,8 +534,8 @@ static int qmi_decode_string_elem(struct decoded_bytes += rc; } -if (string_len > temp_ei->elem_len) { -pr_err ("%s: String len %d > Max Len %d\n" , +if (string_len >= temp_ei->elem_len) { +pr_err ("%s: String len %d >= Max Len %d\n" , __func__, string_len, temp_ei->elem_len);return -ETOOSMALL ; }else if (string_len > tlv_len) {
Greg Kroah-Hartman
maintainerPATCH 205/273 NFSv4/pnfs: minor fix for cleanup path in nfs4_get_device_info
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Fedor Pchelkin <[email protected]>
commit 96562c45af5c31b89a197af28f79bfa838fb8391 upstream.
It is an almost improbable error case but when page allocating loop in nfs4_get_device_info() fails then we should only free the already allocated pages, as __free_page() can't deal with NULL arguments.
Found by Linux Verification Center (linuxtesting.org).
--- fs/nfs/pnfs_dev.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/nfs/pnfs_dev.c +1 -1
@@ -152,7 +152,7 @@ nfs4_get_device_info(struct nfs_server *set_bit (NFS_DEVICEID_NOCACHE , &d->flags); out_free_pages: -for (i =0 ; i < max_pages; i++) +while (--i >=0 )__free_page (pages[i]);kfree (pages); out_free_pdev:
Greg Kroah-Hartman
maintainerPATCH 206/273 kconfig: fix possible buffer overflow
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Konstantin Meskhidze <[email protected]>
[ Upstream commit a3b7039bb2b22fcd2ad20d59c00ed4e606ce3754 ]
Buffer 'new_argv' is accessed without bound check after accessing with bound check via 'new_argc' index.
--- scripts/kconfig/preprocess.c | 3 +++ 1 file changed, 3 insertions(+)
scripts/kconfig/preprocess.c +3 -0
@@ -393,6 +393,9 @@ static char *eval_clause(const char *str, size_t len, int argc, char *argv[]) p++; } + +if (new_argc >=FUNCTION_MAX_ARGS ) +pperror ("too many function arguments" ); new_argv[new_argc++] = prev;/*
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 207/273 x86/virt: Drop unnecessary check on extended CPUID level in cpu_has_svm()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sean Christopherson <[email protected]>
[ Upstream commit 5df8ecfe3632d5879d1f154f7aa8de441b5d1c89 ]
Drop the explicit check on the extended CPUID level in cpu_has_svm(), the kernel's cached CPUID info will leave the entire SVM leaf unset if said leaf is not supported by hardware. Prior to using cached information, the check was needed to avoid false positives due to Intel's rather crazy CPUID behavior of returning the values of the maximum supported leaf if the specified leaf is unsupported.
--- arch/x86/include/asm/virtext.h | 6 ------ 1 file changed, 6 deletions(-)
arch/x86/include/asm/virtext.h +0 -6
@@ -89,12 +89,6 @@ static inline int cpu_has_svm(const char **msg)return 0 ; } -if (boot_cpu_data.extended_cpuid_level <SVM_CPUID_FUNC ) { -if (msg) - *msg ="can't execute cpuid_8000000a" ; -return 0 ; - } -if (!boot_cpu_has (X86_FEATURE_SVM )) {if (msg) *msg ="svm not available" ;
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 208/273 watchdog: intel-mid_wdt: add MODULE_ALIAS() to allow auto-load
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Raag Jadav <[email protected]>
[ Upstream commit cf38e7691c85f1b09973b22a0b89bf1e1228d2f9 ]
When built with CONFIG_INTEL_MID_WATCHDOG=m, currently the driver needs to be loaded manually, for the lack of module alias. This causes unintended resets in cases where watchdog timer is set-up by bootloader and the driver is not explicitly loaded. Add MODULE_ALIAS() to load the driver automatically at boot and avoid this issue.
--- drivers/watchdog/intel-mid_wdt.c | 1 + 1 file changed, 1 insertion(+)
drivers/watchdog/intel-mid_wdt.c +1 -0
@@ -186,3 +186,4 @@ module_platform_driver(mid_wdt_driver);MODULE_AUTHOR ("David Cohen <[email protected]>" );MODULE_DESCRIPTION ("Watchdog Driver for Intel MID platform" );MODULE_LICENSE ("GPL" ); +MODULE_ALIAS ("platform:intel_mid_wdt" );
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 209/273 pwm: lpc32xx: Remove handling of PWM channels
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vladimir Zapolskiy <[email protected]>
[ Upstream commit 4aae44f65827f0213a7361cf9c32cfe06114473f ]
Because LPC32xx PWM controllers have only a single output which is registered as the only PWM device/channel per controller, it is known in advance that pwm->hwpwm value is always 0. On basis of this fact simplify the code by removing operations with pwm->hwpwm, there is no controls which require channel number as input.
Even though I wasn't aware at the time when I forward ported that patch, this fixes a null pointer dereference as lpc32xx->chip.pwms is NULL before devm_pwmchip_add() is called.
--- drivers/pwm/pwm-lpc32xx.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-)
drivers/pwm/pwm-lpc32xx.c +8 -8
@@ -55,10 +55,10 @@ static int lpc32xx_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,if (duty_cycles >255 ) duty_cycles =255 ; - val =readl (lpc32xx->base + (pwm->hwpwm <<2 )); + val =readl (lpc32xx->base); val &= ~0xFFFF ; val |= (period_cycles <<8 ) | duty_cycles; -writel (val, lpc32xx->base + (pwm->hwpwm <<2 )); +writel (val, lpc32xx->base);return 0 ; }
@@ -73,9 +73,9 @@ static int lpc32xx_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)if (ret)return ret; - val =readl (lpc32xx->base + (pwm->hwpwm <<2 )); + val =readl (lpc32xx->base); val |=PWM_ENABLE ; -writel (val, lpc32xx->base + (pwm->hwpwm <<2 )); +writel (val, lpc32xx->base);return 0 ; }
@@ -85,9 +85,9 @@ static void lpc32xx_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)struct lpc32xx_pwm_chip *lpc32xx =to_lpc32xx_pwm_chip (chip);u32 val; - val =readl (lpc32xx->base + (pwm->hwpwm <<2 )); + val =readl (lpc32xx->base); val &= ~PWM_ENABLE ; -writel (val, lpc32xx->base + (pwm->hwpwm <<2 )); +writel (val, lpc32xx->base);clk_disable_unprepare (lpc32xx->clk); }
@@ -125,9 +125,9 @@ static int lpc32xx_pwm_probe(struct platform_device *pdev) lpc32xx->chip.base =-1 ;/* If PWM is disabled, configure the output to the default value */ - val =readl (lpc32xx->base + (lpc32xx->chip.pwms[0 ].hwpwm <<2 )); + val =readl (lpc32xx->base); val &= ~PWM_PIN_LEVEL ; -writel (val, lpc32xx->base + (lpc32xx->chip.pwms[0 ].hwpwm <<2 )); +writel (val, lpc32xx->base); ret =pwmchip_add (&lpc32xx->chip);if (ret <0 ) {
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 210/273 net: read sk->sk_family once in sk_mc_loop()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit a3e0fdf71bbe031de845e8e08ed7fba49f9c702c ]
syzbot is playing with IPV6_ADDRFORM quite a lot these days, and managed to hit the WARN_ON_ONCE(1) in sk_mc_loop()
We have many more similar issues to fix.
WARNING: CPU: 1 PID: 1593 at net/core/sock.c:782 sk_mc_loop+0x165/0x260 Modules linked in: CPU: 1 PID: 1593 Comm: kworker/1:3 Not tainted 6.1.40-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023 Workqueue: events_power_efficient gc_worker RIP: 0010:sk_mc_loop+0x165/0x260 net/core/sock.c:782 Code: 34 1b fd 49 81 c7 18 05 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 20 00 74 08 4c 89 ff e8 25 36 6d fd 4d 8b 37 eb 13 e8 db 33 1b fd <0f> 0b b3 01 eb 34 e8 d0 33 1b fd 45 31 f6 49 83 c6 38 4c 89 f0 48 RSP: 0018:ffffc90000388530 EFLAGS: 00010246 RAX: ffffffff846d9b55 RBX: 0000000000000011 RCX: ffff88814f884980 RDX: 0000000000000102 RSI: ffffffff87ae5160 RDI: 0000000000000011 RBP: ffffc90000388550 R08: 0000000000000003 R09: ffffffff846d9a65 R10: 0000000000000002 R11: ffff88814f884980 R12: dffffc0000000000 R13: ffff88810dbee000 R14: 0000000000000010 R15: ffff888150084000 FS: 0000000000000000(0000) GS:ffff8881f6b00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000180 CR3: 000000014ee5b000 CR4: 00000000003506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> [<ffffffff8507734f>] ip6_finish_output2+0x33f/0x1ae0 net/ipv6/ip6_output.c:83 [<ffffffff85062766>] __ip6_finish_output net/ipv6/ip6_output.c:200 [inline] [<ffffffff85062766>] ip6_finish_output+0x6c6/0xb10 net/ipv6/ip6_output.c:211 [<ffffffff85061f8c>] NF_HOOK_COND include/linux/netfilter.h:298 [inline] [<ffffffff85061f8c>] ip6_output+0x2bc/0x3d0 net/ipv6/ip6_output.c:232 [<ffffffff852071cf>] dst_output include/net/dst.h:444 [inline] [<ffffffff852071cf>] ip6_local_out+0x10f/0x140 net/ipv6/output_core.c:161 [<ffffffff83618fb4>] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:483 [inline] [<ffffffff83618fb4>] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline] [<ffffffff83618fb4>] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] [<ffffffff83618fb4>] ipvlan_queue_xmit+0x1174/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677 [<ffffffff8361ddd9>] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229 [<ffffffff84763fc0>] netdev_start_xmit include/linux/netdevice.h:4925 [inline] [<ffffffff84763fc0>] xmit_one net/core/dev.c:3644 [inline] [<ffffffff84763fc0>] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660 [<ffffffff8494c650>] sch_direct_xmit+0x2a0/0x9c0 net/sched/sch_generic.c:342 [<ffffffff8494d883>] qdisc_restart net/sched/sch_generic.c:407 [inline] [<ffffffff8494d883>] __qdisc_run+0xb13/0x1e70 net/sched/sch_generic.c:415 [<ffffffff8478c426>] qdisc_run+0xd6/0x260 include/net/pkt_sched.h:125 [<ffffffff84796eac>] net_tx_action+0x7ac/0x940 net/core/dev.c:5247 [<ffffffff858002bd>] __do_softirq+0x2bd/0x9bd kernel/softirq.c:599 [<ffffffff814c3fe8>] invoke_softirq kernel/softirq.c:430 [inline] [<ffffffff814c3fe8>] __irq_exit_rcu+0xc8/0x170 kernel/softirq.c:683 [<ffffffff814c3f09>] irq_exit_rcu+0x9/0x20 kernel/softirq.c:695
--- net/core/sock.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
net/core/sock.c +2 -1
@@ -632,7 +632,8 @@ bool sk_mc_loop(struct sock *sk)return false;if (!sk)return true; -switch (sk->sk_family) { +/* IPV6_ADDRFORM can change sk->sk_family under us. */ +switch (READ_ONCE (sk->sk_family)) {case AF_INET :return inet_sk (sk)->mc_loop;#if IS_ENABLED (CONFIG_IPV6 )
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 211/273 igb: disable virtualization features on 82580
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Corinna Vinschen <[email protected]>
[ Upstream commit fa09bc40b21a33937872c4c4cf0f266ec9fa4869 ]
Disable virtualization features on 82580 just as on i210/i211. This avoids that virt functions are acidentally called on 82850.
--- drivers/net/ethernet/intel/igb/igb_main.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/net/ethernet/intel/igb/igb_main.c +3 -2
@@ -3736,8 +3736,9 @@ static void igb_probe_vfs(struct igb_adapter *adapter)struct pci_dev *pdev = adapter->pdev;struct e1000_hw *hw = &adapter->hw; -/* Virtualization features not supported on i210 family. */ -if ((hw->mac.type == e1000_i210) || (hw->mac.type == e1000_i211)) +/* Virtualization features not supported on i210 and 82580 family. */ +if ((hw->mac.type == e1000_i210) || (hw->mac.type == e1000_i211) || + (hw->mac.type == e1000_82580))return ;/* Of the below we really only want the effect of getting
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 212/273 veth: Fixing transmit return status for dropped packets
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Liang Chen <[email protected]>
[ Upstream commit 151e887d8ff97e2e42110ffa1fb1e6a2128fb364 ]
The veth_xmit function returns NETDEV_TX_OK even when packets are dropped. This behavior leads to incorrect calculations of statistics counts, as well as things like txq->trans_start updates.
--- drivers/net/veth.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
drivers/net/veth.c +3 -1
@@ -181,6 +181,7 @@ static netdev_tx_t veth_xmit(struct sk_buff *skb, struct net_device *dev) {struct veth_priv *rcv_priv, *priv =netdev_priv (dev);struct veth_rq *rq =NULL ; +int ret =NETDEV_TX_OK ;struct net_device *rcv;int length = skb->len;bool rcv_xdp = false;
@@ -210,6 +211,7 @@ static netdev_tx_t veth_xmit(struct sk_buff *skb, struct net_device *dev) }else { drop:atomic64_inc (&priv->dropped); + ret =NET_XMIT_DROP ; }if (rcv_xdp)
@@ -217,7 +219,7 @@ static netdev_tx_t veth_xmit(struct sk_buff *skb, struct net_device *dev)rcu_read_unlock (); -return NETDEV_TX_OK ; +return ret; }static u64 veth_stats_one (struct pcpu_vstats *result,struct net_device *dev)
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 213/273 net: ipv6/addrconf: avoid integer underflow in ipv6_create_tempaddr
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alex Henrie <[email protected]>
[ Upstream commit f31867d0d9d82af757c1e0178b659438f4c1ea3c ]
The existing code incorrectly casted a negative value (the result of a subtraction) to an unsigned value without checking. For example, if /proc/sys/net/ipv6/conf/*/temp_prefered_lft was set to 1, the preferred lifetime would jump to 4 billion seconds. On my machine and network the shortest lifetime that avoided underflow was 3 seconds.
--- net/ipv6/addrconf.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/ipv6/addrconf.c +1 -1
@@ -1321,7 +1321,7 @@ static int ipv6_create_tempaddr(struct inet6_ifaddr *ifp,* idev->desync_factor if it's larger */ cnf_temp_preferred_lft =READ_ONCE (idev->cnf.temp_prefered_lft); - max_desync_factor =min_t (__u32, + max_desync_factor =min_t (long, idev->cnf.max_desync_factor, cnf_temp_preferred_lft - regen_advance);
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 214/273 af_unix: Fix data-races around user->unix_inflight.
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kuniyuki Iwashima <[email protected]>
[ Upstream commit 0bc36c0650b21df36fbec8136add83936eaf0607 ]
user->unix_inflight is changed under spin_lock(unix_gc_lock), but too_many_unix_fds() reads it locklessly.
Let's annotate the write/read accesses to user->unix_inflight.
BUG: KCSAN: data-race in unix_attach_fds / unix_inflight
write to 0xffffffff8546f2d0 of 8 bytes by task 44798 on cpu 1:
unix_inflight+0x157/0x180 net/unix/scm.c:66 unix_attach_fds+0x147/0x1e0 net/unix/scm.c:123 unix_scm_to_skb net/unix/af_unix.c:1827 [inline] unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1950 unix_seqpacket_sendmsg net/unix/af_unix.c:2308 [inline] unix_seqpacket_sendmsg+0xba/0x130 net/unix/af_unix.c:2292 sock_sendmsg_nosec net/socket.c:725 [inline] sock_sendmsg+0x148/0x160 net/socket.c:748 ____sys_sendmsg+0x4e4/0x610 net/socket.c:2494 ___sys_sendmsg+0xc6/0x140 net/socket.c:2548 __sys_sendmsg+0x94/0x140 net/socket.c:2577 __do_sys_sendmsg net/socket.c:2586 [inline] __se_sys_sendmsg net/socket.c:2584 [inline] __x64_sys_sendmsg+0x45/0x50 net/socket.c:2584 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8
read to 0xffffffff8546f2d0 of 8 bytes by task 44814 on cpu 0:
too_many_unix_fds net/unix/scm.c:101 [inline] unix_attach_fds+0x54/0x1e0 net/unix/scm.c:110 unix_scm_to_skb net/unix/af_unix.c:1827 [inline] unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1950 unix_seqpacket_sendmsg net/unix/af_unix.c:2308 [inline] unix_seqpacket_sendmsg+0xba/0x130 net/unix/af_unix.c:2292 sock_sendmsg_nosec net/socket.c:725 [inline] sock_sendmsg+0x148/0x160 net/socket.c:748 ____sys_sendmsg+0x4e4/0x610 net/socket.c:2494 ___sys_sendmsg+0xc6/0x140 net/socket.c:2548 __sys_sendmsg+0x94/0x140 net/socket.c:2577 __do_sys_sendmsg net/socket.c:2586 [inline] __se_sys_sendmsg net/socket.c:2584 [inline] __x64_sys_sendmsg+0x45/0x50 net/socket.c:2584 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8
value changed: 0x000000000000000c -> 0x000000000000000d
Reported by Kernel Concurrency Sanitizer on:
CPU: 0 PID: 44814 Comm: systemd-coredum Not tainted 6.4.0-11989-g6843306689af #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
--- net/unix/scm.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
net/unix/scm.c +3 -3
@@ -59,7 +59,7 @@ void unix_inflight(struct user_struct *user, struct file *fp)/* Paired with READ_ONCE() in wait_for_unix_gc() */ WRITE_ONCE (unix_tot_inflight, unix_tot_inflight +1 ); } - user->unix_inflight++; +WRITE_ONCE (user->unix_inflight, user->unix_inflight +1 );spin_unlock (&unix_gc_lock); }
@@ -80,7 +80,7 @@ void unix_notinflight(struct user_struct *user, struct file *fp)/* Paired with READ_ONCE() in wait_for_unix_gc() */ WRITE_ONCE (unix_tot_inflight, unix_tot_inflight -1 ); } - user->unix_inflight--; +WRITE_ONCE (user->unix_inflight, user->unix_inflight -1 );spin_unlock (&unix_gc_lock); }
@@ -94,7 +94,7 @@ static inline bool too_many_unix_fds(struct task_struct *p) {struct user_struct *user =current_user (); -if (unlikely (user->unix_inflight >task_rlimit (p,RLIMIT_NOFILE ))) +if (unlikely (READ_ONCE (user->unix_inflight) >task_rlimit (p,RLIMIT_NOFILE )))return !capable (CAP_SYS_RESOURCE ) && !capable (CAP_SYS_ADMIN );return false; }
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 215/273 af_unix: Fix data-race around unix_tot_inflight.
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kuniyuki Iwashima <[email protected]>
[ Upstream commit ade32bd8a738d7497ffe9743c46728db26740f78 ]
unix_tot_inflight is changed under spin_lock(unix_gc_lock), but unix_release_sock() reads it locklessly.
Let's use READ_ONCE() for unix_tot_inflight.
Note that the writer side was marked by commit 9d6d7f1cb67c ("af_unix:
annote lockless accesses to unix_tot_inflight & gc_in_progress")
BUG: KCSAN: data-race in unix_inflight / unix_release_sock
write (marked) to 0xffffffff871852b8 of 4 bytes by task 123 on cpu 1:
unix_inflight+0x130/0x180 net/unix/scm.c:64 unix_attach_fds+0x137/0x1b0 net/unix/scm.c:123 unix_scm_to_skb net/unix/af_unix.c:1832 [inline] unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1955 sock_sendmsg_nosec net/socket.c:724 [inline] sock_sendmsg+0x148/0x160 net/socket.c:747 ____sys_sendmsg+0x4e4/0x610 net/socket.c:2493 ___sys_sendmsg+0xc6/0x140 net/socket.c:2547 __sys_sendmsg+0x94/0x140 net/socket.c:2576 __do_sys_sendmsg net/socket.c:2585 [inline] __se_sys_sendmsg net/socket.c:2583 [inline] __x64_sys_sendmsg+0x45/0x50 net/socket.c:2583 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x72/0xdc
read to 0xffffffff871852b8 of 4 bytes by task 4891 on cpu 0:
unix_release_sock+0x608/0x910 net/unix/af_unix.c:671 unix_release+0x59/0x80 net/unix/af_unix.c:1058 __sock_release+0x7d/0x170 net/socket.c:653 sock_close+0x19/0x30 net/socket.c:1385 __fput+0x179/0x5e0 fs/file_table.c:321 ____fput+0x15/0x20 fs/file_table.c:349 task_work_run+0x116/0x1a0 kernel/task_work.c:179 resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] exit_to_user_mode_loop kernel/entry/common.c:171 [inline] exit_to_user_mode_prepare+0x174/0x180 kernel/entry/common.c:204 __syscall_exit_to_user_mode_work kernel/entry/common.c:286 [inline] syscall_exit_to_user_mode+0x1a/0x30 kernel/entry/common.c:297 do_syscall_64+0x4b/0x90 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x72/0xdc
value changed: 0x00000000 -> 0x00000001
Reported by Kernel Concurrency Sanitizer on:
CPU: 0 PID: 4891 Comm: systemd-coredum Not tainted 6.4.0-rc5-01219-gfa0e21fa4443 #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
--- net/unix/af_unix.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/unix/af_unix.c +1 -1
@@ -594,7 +594,7 @@ static void unix_release_sock(struct sock *sk, int embrion)* What the above comment does talk about? --ANK(980817) */ -if (unix_tot_inflight) +if (READ_ONCE (unix_tot_inflight))unix_gc ();/* Garbage collect fds */ }
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 216/273 af_unix: Fix data-races around sk->sk_shutdown.
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kuniyuki Iwashima <[email protected]>
[ Upstream commit afe8764f76346ba838d4f162883e23d2fcfaa90e ]
sk->sk_shutdown is changed under unix_state_lock(sk), but unix_dgram_sendmsg() calls two functions to read sk_shutdown locklessly.
sock_alloc_send_pskb
`- sock_wait_for_wmem
Let's use READ_ONCE() there.
Note that the writer side was marked by commit e1d09c2c2f57 ("af_unix:
Fix data races around sk->sk_shutdown.").
BUG: KCSAN: data-race in sock_alloc_send_pskb / unix_release_sock
write (marked) to 0xffff8880069af12c of 1 bytes by task 1 on cpu 1:
unix_release_sock+0x75c/0x910 net/unix/af_unix.c:631 unix_release+0x59/0x80 net/unix/af_unix.c:1053 __sock_release+0x7d/0x170 net/socket.c:654 sock_close+0x19/0x30 net/socket.c:1386 __fput+0x2a3/0x680 fs/file_table.c:384 ____fput+0x15/0x20 fs/file_table.c:412 task_work_run+0x116/0x1a0 kernel/task_work.c:179 resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] exit_to_user_mode_loop kernel/entry/common.c:171 [inline] exit_to_user_mode_prepare+0x174/0x180 kernel/entry/common.c:204 __syscall_exit_to_user_mode_work kernel/entry/common.c:286 [inline] syscall_exit_to_user_mode+0x1a/0x30 kernel/entry/common.c:297 do_syscall_64+0x4b/0x90 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x6e/0xd8
read to 0xffff8880069af12c of 1 bytes by task 28650 on cpu 0:
sock_alloc_send_pskb+0xd2/0x620 net/core/sock.c:2767 unix_dgram_sendmsg+0x2f8/0x14f0 net/unix/af_unix.c:1944 unix_seqpacket_sendmsg net/unix/af_unix.c:2308 [inline] unix_seqpacket_sendmsg+0xba/0x130 net/unix/af_unix.c:2292 sock_sendmsg_nosec net/socket.c:725 [inline] sock_sendmsg+0x148/0x160 net/socket.c:748 ____sys_sendmsg+0x4e4/0x610 net/socket.c:2494 ___sys_sendmsg+0xc6/0x140 net/socket.c:2548 __sys_sendmsg+0x94/0x140 net/socket.c:2577 __do_sys_sendmsg net/socket.c:2586 [inline] __se_sys_sendmsg net/socket.c:2584 [inline] __x64_sys_sendmsg+0x45/0x50 net/socket.c:2584 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8
value changed: 0x00 -> 0x03
Reported by Kernel Concurrency Sanitizer on:
CPU: 0 PID: 28650 Comm: systemd-coredum Not tainted 6.4.0-11989-g6843306689af #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
--- net/core/sock.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
net/core/sock.c +2 -2
@@ -2072,7 +2072,7 @@ static long sock_wait_for_wmem(struct sock *sk, long timeo)prepare_to_wait (sk_sleep (sk), &wait,TASK_INTERRUPTIBLE );if (refcount_read (&sk->sk_wmem_alloc) < sk->sk_sndbuf)break ; -if (sk->sk_shutdown &SEND_SHUTDOWN ) +if (READ_ONCE (sk->sk_shutdown) &SEND_SHUTDOWN )break ;if (sk->sk_err)break ;
@@ -2102,7 +2102,7 @@ struct sk_buff *sock_alloc_send_pskb(struct sock *sk, unsigned long header_len, goto failure; err = -EPIPE ; -if (sk->sk_shutdown &SEND_SHUTDOWN ) +if (READ_ONCE (sk->sk_shutdown) &SEND_SHUTDOWN ) goto failure;if (sk_wmem_alloc_get (sk) < sk->sk_sndbuf)
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 217/273 af_unix: Fix data race around sk->sk_err.
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kuniyuki Iwashima <[email protected]>
[ Upstream commit b192812905e4b134f7b7994b079eb647e9d2d37e ]
As with sk->sk_shutdown shown in the previous patch, sk->sk_err can be read locklessly by unix_dgram_sendmsg().
Let's use READ_ONCE() for sk_err as well.
Note that the writer side is marked by commit cc04410af7de ("af_unix:
annotate lockless accesses to sk->sk_err").
--- net/core/sock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
net/core/sock.c +1 -1
@@ -2074,7 +2074,7 @@ static long sock_wait_for_wmem(struct sock *sk, long timeo)break ;if (READ_ONCE (sk->sk_shutdown) &SEND_SHUTDOWN )break ; -if (sk->sk_err) +if (READ_ONCE (sk->sk_err))break ; timeo =schedule_timeout (timeo); }
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 218/273 net: sched: sch_qfq: Fix UAF in qfq_dequeue()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: valis <[email protected]>
[ Upstream commit 8fc134fee27f2263988ae38920bc03da416b03d8 ]
When the plug qdisc is used as a class of the qfq qdisc it could trigger a UAF. This issue can be reproduced with following commands:
tc qdisc add dev lo root handle 1: qfq
tc class add dev lo parent 1: classid 1:1 qfq weight 1 maxpkt 512 tc qdisc add dev lo parent 1:1 handle 2: plug
tc filter add dev lo parent 1: basic classid 1:1
ping -c1 127.0.0.1
and boom:
[ 285.353793] BUG: KASAN: slab-use-after-free in qfq_dequeue+0xa7/0x7f0 [ 285.354910] Read of size 4 at addr ffff8880bad312a8 by task ping/144 [ 285.355903] [ 285.356165] CPU: 1 PID: 144 Comm: ping Not tainted 6.5.0-rc3+ #4 [ 285.357112] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 [ 285.358376] Call Trace: [ 285.358773] <IRQ> [ 285.359109] dump_stack_lvl+0x44/0x60 [ 285.359708] print_address_description.constprop.0+0x2c/0x3c0 [ 285.360611] kasan_report+0x10c/0x120 [ 285.361195] ? qfq_dequeue+0xa7/0x7f0 [ 285.361780] qfq_dequeue+0xa7/0x7f0 [ 285.362342] __qdisc_run+0xf1/0x970 [ 285.362903] net_tx_action+0x28e/0x460 [ 285.363502] __do_softirq+0x11b/0x3de [ 285.364097] do_softirq.part.0+0x72/0x90 [ 285.364721] </IRQ> [ 285.365072] <TASK> [ 285.365422] __local_bh_enable_ip+0x77/0x90 [ 285.366079] __dev_queue_xmit+0x95f/0x1550 [ 285.366732] ? __pfx_csum_and_copy_from_iter+0x10/0x10 [ 285.367526] ? __pfx___dev_queue_xmit+0x10/0x10 [ 285.368259] ? __build_skb_around+0x129/0x190 [ 285.368960] ? ip_generic_getfrag+0x12c/0x170 [ 285.369653] ? __pfx_ip_generic_getfrag+0x10/0x10 [ 285.370390] ? csum_partial+0x8/0x20 [ 285.370961] ? raw_getfrag+0xe5/0x140 [ 285.371559] ip_finish_output2+0x539/0xa40 [ 285.372222] ? __pfx_ip_finish_output2+0x10/0x10 [ 285.372954] ip_output+0x113/0x1e0 [ 285.373512] ? __pfx_ip_output+0x10/0x10 [ 285.374130] ? icmp_out_count+0x49/0x60 [ 285.374739] ? __pfx_ip_finish_output+0x10/0x10 [ 285.375457] ip_push_pending_frames+0xf3/0x100 [ 285.376173] raw_sendmsg+0xef5/0x12d0 [ 285.376760] ? do_syscall_64+0x40/0x90 [ 285.377359] ? __static_call_text_end+0x136578/0x136578 [ 285.378173] ? do_syscall_64+0x40/0x90 [ 285.378772] ? kasan_enable_current+0x11/0x20 [ 285.379469] ? __pfx_raw_sendmsg+0x10/0x10 [ 285.380137] ? __sock_create+0x13e/0x270 [ 285.380673] ? __sys_socket+0xf3/0x180 [ 285.381174] ? __x64_sys_socket+0x3d/0x50 [ 285.381725] ? entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 285.382425] ? __rcu_read_unlock+0x48/0x70 [ 285.382975] ? ip4_datagram_release_cb+0xd8/0x380 [ 285.383608] ? __pfx_ip4_datagram_release_cb+0x10/0x10 [ 285.384295] ? preempt_count_sub+0x14/0xc0 [ 285.384844] ? __list_del_entry_valid+0x76/0x140 [ 285.385467] ? _raw_spin_lock_bh+0x87/0xe0 [ 285.386014] ? __pfx__raw_spin_lock_bh+0x10/0x10 [ 285.386645] ? release_sock+0xa0/0xd0 [ 285.387148] ? preempt_count_sub+0x14/0xc0 [ 285.387712] ? freeze_secondary_cpus+0x348/0x3c0 [ 285.388341] ? aa_sk_perm+0x177/0x390 [ 285.388856] ? __pfx_aa_sk_perm+0x10/0x10 [ 285.389441] ? check_stack_object+0x22/0x70 [ 285.390032] ? inet_send_prepare+0x2f/0x120 [ 285.390603] ? __pfx_inet_sendmsg+0x10/0x10 [ 285.391172] sock_sendmsg+0xcc/0xe0 [ 285.391667] __sys_sendto+0x190/0x230 [ 285.392168] ? __pfx___sys_sendto+0x10/0x10 [ 285.392727] ? kvm_clock_get_cycles+0x14/0x30 [ 285.393328] ? set_normalized_timespec64+0x57/0x70 [ 285.393980] ? _raw_spin_unlock_irq+0x1b/0x40 [ 285.394578] ? __x64_sys_clock_gettime+0x11c/0x160 [ 285.395225] ? __pfx___x64_sys_clock_gettime+0x10/0x10 [ 285.395908] ? _copy_to_user+0x3e/0x60 [ 285.396432] ? exit_to_user_mode_prepare+0x1a/0x120 [ 285.397086] ? syscall_exit_to_user_mode+0x22/0x50 [ 285.397734] ? do_syscall_64+0x71/0x90 [ 285.398258] __x64_sys_sendto+0x74/0x90 [ 285.398786] do_syscall_64+0x64/0x90 [ 285.399273] ? exit_to_user_mode_prepare+0x1a/0x120 [ 285.399949] ? syscall_exit_to_user_mode+0x22/0x50 [ 285.400605] ? do_syscall_64+0x71/0x90 [ 285.401124] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 285.401807] RIP: 0033:0x495726 [ 285.402233] Code: ff ff ff f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 11 b8 2c 00 00 00 0f 09 [ 285.404683] RSP: 002b:00007ffcc25fb618 EFLAGS: 00000246 ORIG_RAX: 000000000000002c [ 285.405677] RAX: ffffffffffffffda RBX: 0000000000000040 RCX: 0000000000495726 [ 285.406628] RDX: 0000000000000040 RSI: 0000000002518750 RDI: 0000000000000000 [ 285.407565] RBP: 00000000005205ef R08: 00000000005f8838 R09: 000000000000001c [ 285.408523] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000002517634 [ 285.409460] R13: 00007ffcc25fb6f0 R14: 0000000000000003 R15: 0000000000000000 [ 285.410403] </TASK> [ 285.410704] [ 285.410929] Allocated by task 144: [ 285.411402] kasan_save_stack+0x1e/0x40 [ 285.411926] kasan_set_track+0x21/0x30 [ 285.412442] __kasan_slab_alloc+0x55/0x70 [ 285.412973] kmem_cache_alloc_node+0x187/0x3d0 [ 285.413567] __alloc_skb+0x1b4/0x230 [ 285.414060] __ip_append_data+0x17f7/0x1b60 [ 285.414633] ip_append_data+0x97/0xf0 [ 285.415144] raw_sendmsg+0x5a8/0x12d0 [ 285.415640] sock_sendmsg+0xcc/0xe0 [ 285.416117] __sys_sendto+0x190/0x230 [ 285.416626] __x64_sys_sendto+0x74/0x90 [ 285.417145] do_syscall_64+0x64/0x90 [ 285.417624] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 [ 285.418306] [ 285.418531] Freed by task 144: [ 285.418960] kasan_save_stack+0x1e/0x40 [ 285.419469] kasan_set_track+0x21/0x30 [ 285.419988] kasan_save_free_info+0x27/0x40 [ 285.420556] ____kasan_slab_free+0x109/0x1a0 [ 285.421146] kmem_cache_free+0x1c2/0x450 [ 285.421680] __netif_receive_skb_core+0x2ce/0x1870 [ 285.422333] __netif_receive_skb_one_core+0x97/0x140 [ 285.423003] process_backlog+0x100/0x2f0 [ 285.423537] __napi_poll+0x5c/0x2d0 [ 285.424023] net_rx_action+0x2be/0x560 [ 285.424510] __do_softirq+0x11b/0x3de [ 285.425034] [ 285.425254] The buggy address belongs to the object at ffff8880bad31280 [ 285.425254] which belongs to the cache skbuff_head_cache of size 224 [ 285.426993] The buggy address is located 40 bytes inside of [ 285.426993] freed 224-byte region [ffff8880bad31280, ffff8880bad31360) [ 285.428572] [ 285.428798] The buggy address belongs to the physical page: [ 285.429540] page:00000000f4b77674 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xbad31 [ 285.430758] flags: 0x100000000000200(slab|node=0|zone=1) [ 285.431447] page_type: 0xffffffff() [ 285.431934] raw: 0100000000000200 ffff88810094a8c0 dead000000000122 0000000000000000 [ 285.432757] raw: 0000000000000000 00000000800c000c 00000001ffffffff 0000000000000000 [ 285.433562] page dumped because: kasan: bad access detected [ 285.434144] [ 285.434320] Memory state around the buggy address: [ 285.434828] ffff8880bad31180: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 285.435580] ffff8880bad31200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 285.436264] >ffff8880bad31280: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 285.436777] ^ [ 285.437106] ffff8880bad31300: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc [ 285.437616] ffff8880bad31380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 285.438126] ================================================================== [ 285.438662] Disabling lock debugging due to kernel taint
Fix this by:
1. Changing sch_plug's .peek handler to qdisc_peek_dequeued(), a function compatible with non-work-conserving qdiscs
2. Checking the return value of qdisc_dequeue_peeked() in sch_qfq.
--- net/sched/sch_plug.c | 2 +- net/sched/sch_qfq.c | 22 +++++++++++++++++----- 2 files changed, 18 insertions(+), 6 deletions(-)
net/sched/sch_plug.c +1 -1
@@ -214,7 +214,7 @@ static struct Qdisc_ops plug_qdisc_ops __read_mostly = { .priv_size = sizeof(struct plug_sched_data), .enqueue = plug_enqueue, .dequeue = plug_dequeue, - .peek = qdisc_peek_head, + .peek = qdisc_peek_dequeued, .init = plug_init, .change = plug_change, .reset = qdisc_reset_queue,
net/sched/sch_qfq.c +17 -5
@@ -988,10 +988,13 @@ static void qfq_update_eligible(struct qfq_sched *q) }/* Dequeue head packet of the head class in the DRR queue of the aggregate. */ -static void agg_dequeue (struct qfq_aggregate *agg, -struct qfq_class *cl,unsigned int len) +static struct sk_buff *agg_dequeue (struct qfq_aggregate *agg, +struct qfq_class *cl,unsigned int len) { -qdisc_dequeue_peeked (cl->qdisc); +struct sk_buff *skb =qdisc_dequeue_peeked (cl->qdisc); + +if (!skb) +return NULL ; cl->deficit -= (int ) len;
@@ -1001,6 +1004,8 @@ static void agg_dequeue(struct qfq_aggregate *agg, cl->deficit += agg->lmax;list_move_tail (&cl->alist, &agg->active); } + +return skb; } static inline struct sk_buff *qfq_peek_skb(struct qfq_aggregate *agg,
@@ -1146,11 +1151,18 @@ static struct sk_buff *qfq_dequeue(struct Qdisc *sch)if (!skb)return NULL ; -qdisc_qstats_backlog_dec (sch, skb); sch->q.qlen--; + + skb =agg_dequeue (in_serv_agg, cl, len); + +if (!skb) { + sch->q.qlen++; +return NULL ; + } + +qdisc_qstats_backlog_dec (sch, skb);qdisc_bstats_update (sch, skb); -agg_dequeue (in_serv_agg, cl, len);/* If lmax is lowered, through qfq_change_class, for a class * owning pending packets with larger size than the new value * of lmax, then the following condition may hold.
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 219/273 kcm: Destroy mutex in kcm_exit_net()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shigeru Yoshida <[email protected]>
[ Upstream commit 6ad40b36cd3b04209e2d6c89d252c873d8082a59 ]
kcm_exit_net() should call mutex_destroy() on knet->mutex. This is especially needed if CONFIG_DEBUG_MUTEXES is enabled.
--- net/kcm/kcmsock.c | 2 ++ 1 file changed, 2 insertions(+)
net/kcm/kcmsock.c +2 -0
@@ -1983,6 +1983,8 @@ static __net_exit void kcm_exit_net(struct net *net)* that all multiplexors and psocks have been destroyed. */ WARN_ON (!list_empty (&knet->mux_list)); + +mutex_destroy (&knet->mutex); }static struct pernet_operations kcm_net_ops = {
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 220/273 igbvf: Change IGBVF_MIN to allow set rx/tx value between 64 and 80
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Olga Zaborska <[email protected]>
[ Upstream commit 8360717524a24a421c36ef8eb512406dbd42160a ]
Change the minimum value of RX/TX descriptors to 64 to enable setting the rx/tx value between 64 and 80. All igbvf devices can use as low as 64 descriptors. This change will unify igbvf with other drivers.
Based on commit 7b1be1987c1e ("e1000e: lower ring minimum size to 64")
--- drivers/net/ethernet/intel/igbvf/igbvf.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/ethernet/intel/igbvf/igbvf.h +2 -2
@@ -39,11 +39,11 @@ enum latency_range {/* Tx/Rx descriptor defines */ #define IGBVF_DEFAULT_TXD 256#define IGBVF_MAX_TXD 4096 -#define IGBVF_MIN_TXD 80 +#define IGBVF_MIN_TXD 64#define IGBVF_DEFAULT_RXD 256#define IGBVF_MAX_RXD 4096 -#define IGBVF_MIN_RXD 80 +#define IGBVF_MIN_RXD 64#define IGBVF_MIN_ITR_USECS 10/* 100000 irq/sec */ #define IGBVF_MAX_ITR_USECS 10000/* 100 irq/sec */
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 221/273 igb: Change IGB_MIN to allow set rx/tx value between 64 and 80
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Olga Zaborska <[email protected]>
[ Upstream commit 6319685bdc8ad5310890add907b7c42f89302886 ]
Change the minimum value of RX/TX descriptors to 64 to enable setting the rx/tx value between 64 and 80. All igb devices can use as low as 64 descriptors. This change will unify igb with other drivers.
Based on commit 7b1be1987c1e ("e1000e: lower ring minimum size to 64")
--- drivers/net/ethernet/intel/igb/igb.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/ethernet/intel/igb/igb.h +2 -2
@@ -32,11 +32,11 @@ struct igb_adapter;/* TX/RX descriptor defines */ #define IGB_DEFAULT_TXD 256#define IGB_DEFAULT_TX_WORK 128 -#define IGB_MIN_TXD 80 +#define IGB_MIN_TXD 64#define IGB_MAX_TXD 4096#define IGB_DEFAULT_RXD 256 -#define IGB_MIN_RXD 80 +#define IGB_MIN_RXD 64#define IGB_MAX_RXD 4096#define IGB_DEFAULT_ITR 3/* dynamic */
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 222/273 idr: fix param name in idr_alloc_cyclic() doc
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ariel Marcovitch <[email protected]>
[ Upstream commit 2a15de80dd0f7e04a823291aa9eb49c5294f56af ]
The relevant parameter is 'start' and not 'nextid'
--- lib/idr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
lib/idr.c +1 -1
@@ -103,7 +103,7 @@ EXPORT_SYMBOL_GPL(idr_alloc);* @end: The maximum ID (exclusive). * @gfp: Memory allocation flags. * -* Allocates an unused ID in the range specified by @nextid and @end. If +* Allocates an unused ID in the range specified by @start and @end. If * @end is <= 0, it is treated as one larger than %INT_MAX. This allows * callers to use @start + N as @end as long as N is within integer range. * The search for an unused ID will start at the last ID allocated and will
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 223/273 netfilter: nfnetlink_osf: avoid OOB read
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wander Lairson Costa <[email protected]>
[ Upstream commit f4f8a7803119005e87b716874bec07c751efafec ]
The opt_num field is controlled by user mode and is not currently validated inside the kernel. An attacker can take advantage of this to trigger an OOB read and potentially leak information.
BUG: KASAN: slab-out-of-bounds in nf_osf_match_one+0xbed/0xd10 net/netfilter/nfnetlink_osf.c:88 Read of size 2 at addr ffff88804bc64272 by task poc/6431 CPU: 1 PID: 6431 Comm: poc Not tainted 6.0.0-rc4 #1 Call Trace: nf_osf_match_one+0xbed/0xd10 net/netfilter/nfnetlink_osf.c:88 nf_osf_find+0x186/0x2f0 net/netfilter/nfnetlink_osf.c:281 nft_osf_eval+0x37f/0x590 net/netfilter/nft_osf.c:47 expr_call_ops_eval net/netfilter/nf_tables_core.c:214 nft_do_chain+0x2b0/0x1490 net/netfilter/nf_tables_core.c:264 nft_do_chain_ipv4+0x17c/0x1f0 net/netfilter/nft_chain_filter.c:23 [..]
Also add validation to genre, subtype and version fields.
--- net/netfilter/nfnetlink_osf.c | 8 ++++++++ 1 file changed, 8 insertions(+)
net/netfilter/nfnetlink_osf.c +8 -0
@@ -318,6 +318,14 @@ static int nfnl_osf_add_callback(struct net *net, struct sock *ctnl, f =nla_data (osf_attrs[OSF_ATTR_FINGER ]); +if (f->opt_num >ARRAY_SIZE (f->opt)) +return -EINVAL ; + +if (!memchr (f->genre,0 ,MAXGENRELEN ) || + !memchr (f->subtype,0 ,MAXGENRELEN ) || + !memchr (f->version,0 ,MAXGENRELEN )) +return -EINVAL ; + kf =kmalloc (sizeof (struct nf_osf_finger ),GFP_KERNEL );if (!kf)return -ENOMEM ;
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 224/273 ata: sata_gemini: Add missing MODULE_DESCRIPTION
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Damien Le Moal <[email protected]>
commit 8566572bf3b4d6e416a4bf2110dbb4817d11ba59 upstream.
Add the missing MODULE_DESCRIPTION() to avoid warnings such as:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/ata/sata_gemini.o
when compiling with W=1.
--- drivers/ata/sata_gemini.c | 1 + 1 file changed, 1 insertion(+)
drivers/ata/sata_gemini.c +1 -0
@@ -434,6 +434,7 @@ static struct platform_driver gemini_sat };module_platform_driver (gemini_sata_driver); +MODULE_DESCRIPTION ("low level driver for Cortina Systems Gemini SATA bridge" );MODULE_AUTHOR ("Linus Walleij <[email protected]>" );MODULE_LICENSE ("GPL" );MODULE_ALIAS ("platform:" DRV_NAME );
Greg Kroah-Hartman
maintainerPATCH 225/273 ata: pata_ftide010: Add missing MODULE_DESCRIPTION
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Damien Le Moal <[email protected]>
commit 7274eef5729037300f29d14edeb334a47a098f65 upstream.
Add the missing MODULE_DESCRIPTION() to avoid warnings such as:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/ata/pata_ftide010.o
when compiling with W=1.
--- drivers/ata/pata_ftide010.c | 1 + 1 file changed, 1 insertion(+)
drivers/ata/pata_ftide010.c +1 -0
@@ -569,6 +569,7 @@ static struct platform_driver pata_ftide };module_platform_driver (pata_ftide010_driver); +MODULE_DESCRIPTION ("low level driver for Faraday Technology FTIDE010" );MODULE_AUTHOR ("Linus Walleij <[email protected]>" );MODULE_LICENSE ("GPL" );MODULE_ALIAS ("platform:" DRV_NAME );
Greg Kroah-Hartman
maintainerPATCH 226/273 btrfs: dont start transaction when joining with TRANS_JOIN_NOSTART
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filipe Manana <[email protected]>
commit 4490e803e1fe9fab8db5025e44e23b55df54078b upstream.
When joining a transaction with TRANS_JOIN_NOSTART, if we don't find a running transaction we end up creating one. This goes against the purpose of TRANS_JOIN_NOSTART which is to join a running transaction if its state is at or below the state TRANS_STATE_COMMIT_START, otherwise return an -ENOENT error and don't start a new transaction. So fix this to not create a new transaction if there's no running transaction at or below that state.
--- fs/btrfs/transaction.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
fs/btrfs/transaction.c +4 -3
@@ -200,10 +200,11 @@ loop:spin_unlock (&fs_info->trans_lock);/* -* If we are ATTACH, we just want to catch the current transaction, -* and commit it. If there is no transaction, just return ENOENT. +* If we are ATTACH or TRANS_JOIN_NOSTART, we just want to catch the +* current transaction, and commit it. If there is no transaction, just +* return ENOENT. */ -if (type ==TRANS_ATTACH ) +if (type ==TRANS_ATTACH || type ==TRANS_JOIN_NOSTART )return -ENOENT ;/*
Greg Kroah-Hartman
maintainerPATCH 227/273 mtd: rawnand: brcmnand: Fix crash during the panic_write
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: William Zhang <[email protected]>
commit e66dd317194daae0475fe9e5577c80aa97f16cb9 upstream.
When executing a NAND command within the panic write path, wait for any pending command instead of calling BUG_ON to avoid crashing while already crashing.
--- drivers/mtd/nand/raw/brcmnand/brcmnand.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-)
drivers/mtd/nand/raw/brcmnand/brcmnand.c +11 -1
@@ -1271,7 +1271,17 @@ static void brcmnand_send_cmd(struct brcdev_dbg (ctrl->dev,"send native cmd %d addr 0x%llx\n" , cmd, cmd_addr); -BUG_ON (ctrl->cmd_pending !=0 ); +/* +* If we came here through _panic_write and there is a pending +* command, try to wait for it. If it times out, rather than +* hitting BUG_ON, just return so we don't crash while crashing. +*/ +if (oops_in_progress) { +if (ctrl->cmd_pending && +bcmnand_ctrl_poll_status (ctrl,NAND_CTRL_RDY ,NAND_CTRL_RDY ,0 )) +return ; + }else +BUG_ON (ctrl->cmd_pending !=0 ); ctrl->cmd_pending = cmd; ret =bcmnand_ctrl_poll_status (ctrl,NAND_CTRL_RDY ,NAND_CTRL_RDY ,0 );
Greg Kroah-Hartman
maintainerPATCH 228/273 mtd: rawnand: brcmnand: Fix potential out-of-bounds access in oob write
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: William Zhang <[email protected]>
commit 5d53244186c9ac58cb88d76a0958ca55b83a15cd upstream.
When the oob buffer length is not in multiple of words, the oob write function does out-of-bounds read on the oob source buffer at the last iteration. Fix that by always checking length limit on the oob buffer read and fill with 0xff when reaching the end of the buffer to the oob registers.
--- drivers/mtd/nand/raw/brcmnand/brcmnand.c | 18 ++++++++++++++++-- 1 file changed, 16 insertions(+), 2 deletions(-)
drivers/mtd/nand/raw/brcmnand/brcmnand.c +16 -2
@@ -1213,19 +1213,33 @@ static int write_oob_to_regs(struct brcm const u8 *oob, int sas, int sector_1k) { int tbytes = sas << sector_1k; -int j; +int j, k =0 ; +u32 last =0xffffffff ; +u8 *plast = (u8 *)&last;/* Adjust OOB values for 1K sector size */ if (sector_1k && (i &0x01 )) tbytes =max (0 , tbytes - (int )ctrl->max_oob); tbytes =min_t (int, tbytes, ctrl->max_oob); -for (j =0 ; j < tbytes; j +=4 ) +/* +* tbytes may not be multiple of words. Make sure we don't read out of +* the boundary and stop at last word. +*/ +for (j =0 ; (j +3 ) < tbytes; j +=4 )oob_reg_write (ctrl, j, (oob[j +0 ] <<24 ) | (oob[j +1 ] <<16 ) | (oob[j +2 ] <<8 ) | (oob[j +3 ] <<0 )); + +/* handle the remaing bytes */ +while (j < tbytes) + plast[k++] = oob[j++]; + +if (tbytes &0x3 ) +oob_reg_write (ctrl, (tbytes & ~0x3 ), (__force u32 )cpu_to_be32 (last)); +return tbytes; }
Greg Kroah-Hartman
maintainerPATCH 229/273 mtd: rawnand: brcmnand: Fix potential false time out warning
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: William Zhang <[email protected]>
commit 9cc0a598b944816f2968baf2631757f22721b996 upstream.
If system is busy during the command status polling function, the driver may not get the chance to poll the status register till the end of time out and return the premature status. Do a final check after time out happens to ensure reading the correct status.
--- drivers/mtd/nand/raw/brcmnand/brcmnand.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/mtd/nand/raw/brcmnand/brcmnand.c +8 -0
@@ -836,6 +836,14 @@ static int bcmnand_ctrl_poll_status(strucpu_relax (); }while (time_after (limit, jiffies)); +/* +* do a final check after time out in case the CPU was busy and the driver +* did not get enough time to perform the polling to avoid false alarms +*/ + val =brcmnand_read_reg (ctrl,BRCMNAND_INTFC_STATUS ); +if ((val & mask) == expected_val) +return 0 ; +dev_warn (ctrl->dev,"timeout on status poll (expected %x got %x)\n" , expected_val, val & mask);
Greg Kroah-Hartman
maintainerPATCH 230/273 perf hists browser: Fix hierarchy mode header
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Namhyung Kim <[email protected]>
commit e2cabf2a44791f01c21f8d5189b946926e34142e upstream.
The commit ef9ff6017e3c4593 ("perf ui browser: Move the extra title lines from the hists browser") introduced ui_browser__gotorc_title() to help moving non-title lines easily. But it missed to update the title for the hierarchy mode so it won't print the header line on TUI at all.
$ perf report --hierarchy
--- tools/perf/ui/browsers/hists.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/perf/ui/browsers/hists.c +1 -1
@@ -1704,7 +1704,7 @@ static void hists_browser__hierarchy_heahists_browser__scnprintf_hierarchy_headers (browser, headers,sizeof (headers)); -ui_browser__gotorc (&browser->b,0 ,0 ); +ui_browser__gotorc_title (&browser->b,0 ,0 );ui_browser__set_color (&browser->b,HE_COLORSET_ROOT );ui_browser__write_nstring (&browser->b, headers, browser->b.width +1 ); }
Greg Kroah-Hartman
maintainerPATCH 231/273 net: ethernet: mtk_eth_soc: fix possible NULL pointer dereference in mtk_hwlro_get_fdir_all()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hangyu Hua <[email protected]>
[ Upstream commit e4c79810755f66c9a933ca810da2724133b1165a ]
rule_locs is allocated in ethtool_get_rxnfc and the size is determined by rule_cnt from user space. So rule_cnt needs to be check before using rule_locs to avoid NULL pointer dereference.
--- drivers/net/ethernet/mediatek/mtk_eth_soc.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/net/ethernet/mediatek/mtk_eth_soc.c +3 -0
@@ -1621,6 +1621,9 @@ static int mtk_hwlro_get_fdir_all(struct net_device *dev,int i;for (i =0 ; i <MTK_MAX_LRO_IP_CNT ; i++) { +if (cnt == cmd->rule_cnt) +return -EMSGSIZE ; +if (mac->hwlro_ip[i]) { rule_locs[cnt] = i; cnt++;
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 232/273 kcm: Fix memory leak in error path of kcm_sendmsg()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shigeru Yoshida <[email protected]>
[ Upstream commit c821a88bd720b0046433173185fd841a100d44ad ]
syzbot reported a memory leak like below:
BUG: memory leak
unreferenced object 0xffff88810b088c00 (size 240):
comm "syz-executor186", pid 5012, jiffies 4294943306 (age 13.680s)
hex dump (first 32 bytes):
00 89 08 0b 81 88 ff ff 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff83e5d5ff>] __alloc_skb+0x1ef/0x230 net/core/skbuff.c:634
[<ffffffff84606e59>] alloc_skb include/linux/skbuff.h:1289 [inline]
[<ffffffff84606e59>] kcm_sendmsg+0x269/0x1050 net/kcm/kcmsock.c:815
[<ffffffff83e479c6>] sock_sendmsg_nosec net/socket.c:725 [inline]
[<ffffffff83e479c6>] sock_sendmsg+0x56/0xb0 net/socket.c:748
[<ffffffff83e47f55>] ____sys_sendmsg+0x365/0x470 net/socket.c:2494
[<ffffffff83e4c389>] ___sys_sendmsg+0xc9/0x130 net/socket.c:2548
[<ffffffff83e4c536>] __sys_sendmsg+0xa6/0x120 net/socket.c:2577
[<ffffffff84ad7bb8>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
[<ffffffff84ad7bb8>] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80
[<ffffffff84c0008b>] entry_SYSCALL_64_after_hwframe+0x63/0xcdIn kcm_sendmsg(), kcm_tx_msg(head)->last_skb is used as a cursor to append newly allocated skbs to 'head'. If some bytes are copied, an error occurred, and jumped to out_error label, 'last_skb' is left unmodified. A later kcm_sendmsg() will use an obsoleted 'last_skb' reference, corrupting the 'head' frag_list and causing the leak.
This patch fixes this issue by properly updating the last allocated skb in 'last_skb'.
--- net/kcm/kcmsock.c | 2 ++ 1 file changed, 2 insertions(+)
net/kcm/kcmsock.c +2 -0
@@ -1074,6 +1074,8 @@ static int kcm_sendmsg(struct socket *sock, struct msghdr *msg, size_t len)if (head != kcm->seq_skb)kfree_skb (head); +else if (copied) +kcm_tx_msg (head)->last_skb = skb; err =sk_stream_error (sk, msg->msg_flags, err);
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 233/273 ixgbe: fix timestamp configuration code
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Vadim Fedorenko <[email protected]>
[ Upstream commit 3c44191dd76cf9c0cc49adaf34384cbd42ef8ad2 ]
The commit in fixes introduced flags to control the status of hardware configuration while processing packets. At the same time another structure is used to provide configuration of timestamper to user-space applications. The way it was coded makes this structures go out of sync easily. The repro is easy for 82599 chips:
[root@hostname ~]# hwstamp_ctl -i eth0 -r 12 -t 1
current settings:tx_type 0rx_filter 0
new settings:tx_type 1rx_filter 12
The eth0 device is properly configured to timestamp any PTPv2 events.
[root@hostname ~]# hwstamp_ctl -i eth0 -r 1 -t 1 current settings:tx_type 1rx_filter 12
SIOCSHWTSTAMP failed: Numerical result out of range
The requested time stamping mode is not supported by the hardware.
The error is properly returned because HW doesn't support all packets timestamping. But the adapter->flags is cleared of timestamp flags even though no HW configuration was done. From that point no RX timestamps are received by user-space application. But configuration shows good values:
[root@hostname ~]# hwstamp_ctl -i eth0
current settings:tx_type 1rx_filter 12
Fix the issue by applying new flags only when the HW was actually configured.
--- drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c | 28 +++++++++++--------- 1 file changed, 15 insertions(+), 13 deletions(-)
drivers/net/ethernet/intel/ixgbe/ixgbe_ptp.c +15 -13
@@ -844,6 +844,7 @@ static int ixgbe_ptp_set_timestamp_mode(struct ixgbe_adapter *adapter,u32 tsync_tx_ctl =IXGBE_TSYNCTXCTL_ENABLED ;u32 tsync_rx_ctl =IXGBE_TSYNCRXCTL_ENABLED ;u32 tsync_rx_mtrl =PTP_EV_PORT <<16 ; +u32 aflags = adapter->flags;bool is_l2 = false;u32 regval;
@@ -864,20 +865,20 @@ static int ixgbe_ptp_set_timestamp_mode(struct ixgbe_adapter *adapter,case HWTSTAMP_FILTER_NONE : tsync_rx_ctl =0 ; tsync_rx_mtrl =0 ; - adapter->flags &= ~(IXGBE_FLAG_RX_HWTSTAMP_ENABLED | -IXGBE_FLAG_RX_HWTSTAMP_IN_REGISTER ); + aflags &= ~(IXGBE_FLAG_RX_HWTSTAMP_ENABLED | +IXGBE_FLAG_RX_HWTSTAMP_IN_REGISTER );break ;case HWTSTAMP_FILTER_PTP_V1_L4_SYNC : tsync_rx_ctl |=IXGBE_TSYNCRXCTL_TYPE_L4_V1 ; tsync_rx_mtrl |=IXGBE_RXMTRL_V1_SYNC_MSG ; - adapter->flags |= (IXGBE_FLAG_RX_HWTSTAMP_ENABLED | -IXGBE_FLAG_RX_HWTSTAMP_IN_REGISTER ); + aflags |= (IXGBE_FLAG_RX_HWTSTAMP_ENABLED | +IXGBE_FLAG_RX_HWTSTAMP_IN_REGISTER );break ;case HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ : tsync_rx_ctl |=IXGBE_TSYNCRXCTL_TYPE_L4_V1 ; tsync_rx_mtrl |=IXGBE_RXMTRL_V1_DELAY_REQ_MSG ; - adapter->flags |= (IXGBE_FLAG_RX_HWTSTAMP_ENABLED | -IXGBE_FLAG_RX_HWTSTAMP_IN_REGISTER ); + aflags |= (IXGBE_FLAG_RX_HWTSTAMP_ENABLED | +IXGBE_FLAG_RX_HWTSTAMP_IN_REGISTER );break ;case HWTSTAMP_FILTER_PTP_V2_EVENT :case HWTSTAMP_FILTER_PTP_V2_L2_EVENT :
@@ -891,8 +892,8 @@ static int ixgbe_ptp_set_timestamp_mode(struct ixgbe_adapter *adapter, tsync_rx_ctl |=IXGBE_TSYNCRXCTL_TYPE_EVENT_V2 ; is_l2 = true; config->rx_filter =HWTSTAMP_FILTER_PTP_V2_EVENT ; - adapter->flags |= (IXGBE_FLAG_RX_HWTSTAMP_ENABLED | -IXGBE_FLAG_RX_HWTSTAMP_IN_REGISTER ); + aflags |= (IXGBE_FLAG_RX_HWTSTAMP_ENABLED | +IXGBE_FLAG_RX_HWTSTAMP_IN_REGISTER );break ;case HWTSTAMP_FILTER_PTP_V1_L4_EVENT :case HWTSTAMP_FILTER_NTP_ALL :
@@ -903,7 +904,7 @@ static int ixgbe_ptp_set_timestamp_mode(struct ixgbe_adapter *adapter,if (hw->mac.type >= ixgbe_mac_X550) { tsync_rx_ctl |=IXGBE_TSYNCRXCTL_TYPE_ALL ; config->rx_filter =HWTSTAMP_FILTER_ALL ; - adapter->flags |=IXGBE_FLAG_RX_HWTSTAMP_ENABLED ; + aflags |=IXGBE_FLAG_RX_HWTSTAMP_ENABLED ;break ; }/* fall through */
@@ -914,8 +915,6 @@ static int ixgbe_ptp_set_timestamp_mode(struct ixgbe_adapter *adapter,* Delay_Req messages and hardware does not support * timestamping all packets => return error */ - adapter->flags &= ~(IXGBE_FLAG_RX_HWTSTAMP_ENABLED | -IXGBE_FLAG_RX_HWTSTAMP_IN_REGISTER ); config->rx_filter =HWTSTAMP_FILTER_NONE ;return -ERANGE ; }
@@ -947,8 +946,8 @@ static int ixgbe_ptp_set_timestamp_mode(struct ixgbe_adapter *adapter,IXGBE_TSYNCRXCTL_TYPE_ALL |IXGBE_TSYNCRXCTL_TSIP_UT_EN ; config->rx_filter =HWTSTAMP_FILTER_ALL ; - adapter->flags |=IXGBE_FLAG_RX_HWTSTAMP_ENABLED ; - adapter->flags &= ~IXGBE_FLAG_RX_HWTSTAMP_IN_REGISTER ; + aflags |=IXGBE_FLAG_RX_HWTSTAMP_ENABLED ; + aflags &= ~IXGBE_FLAG_RX_HWTSTAMP_IN_REGISTER ; is_l2 = true;break ;default :
@@ -981,6 +980,9 @@ static int ixgbe_ptp_set_timestamp_mode(struct ixgbe_adapter *adapter,IXGBE_WRITE_FLUSH (hw); +/* configure adapter flags only when HW is actually configured */ + adapter->flags = aflags; +/* clear TX/RX time stamp registers, just to be sure */ ixgbe_ptp_clear_tx_timestamp (adapter);IXGBE_READ_REG (hw,IXGBE_RXSTMPH );
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 234/273 kcm: Fix error handling for SOCK_DGRAM in kcm_sendmsg().
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kuniyuki Iwashima <[email protected]>
[ Upstream commit a22730b1b4bf437c6bbfdeff5feddf54be4aeada ]
syzkaller found a memory leak in kcm_sendmsg(), and commit c821a88bd720 ("kcm: Fix memory leak in error path of kcm_sendmsg()") suppressed it by updating kcm_tx_msg(head)->last_skb if partial data is copied so that the following sendmsg() will resume from the skb.
However, we cannot know how many bytes were copied when we get the error. Thus, we could mess up the MSG_MORE queue.
When kcm_sendmsg() fails for SOCK_DGRAM, we should purge the queue as we do so for UDP by udp_flush_pending_frames().
Even without this change, when the error occurred, the following sendmsg() resumed from a wrong skb and the queue was messed up. However, we have yet to get such a report, and only syzkaller stumbled on it. So, this can be changed safely.
Note this does not change SOCK_SEQPACKET behaviour.
--- net/kcm/kcmsock.c | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-)
net/kcm/kcmsock.c +8 -7
@@ -1065,17 +1065,18 @@ static int kcm_sendmsg(struct socket *sock, struct msghdr *msg, size_t len) out_error:kcm_push (kcm); -if (copied && sock->type ==SOCK_SEQPACKET ) { +if (sock->type ==SOCK_SEQPACKET ) {/* Wrote some bytes before encountering an * error, return partial success. */ - goto partial_message; - } - -if (head != kcm->seq_skb) +if (copied) + goto partial_message; +if (head != kcm->seq_skb) +kfree_skb (head); + }else {kfree_skb (head); -else if (copied) -kcm_tx_msg (head)->last_skb = skb; + kcm->seq_skb =NULL ; + } err =sk_stream_error (sk, msg->msg_flags, err);
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 235/273 drm/amd/display: Fix a bug when searching for insert_above_mpcc
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wesley Chalmers <[email protected]>
commit 3d028d5d60d516c536de1ddd3ebf3d55f3f8983b upstream.
[WHY]
Currently, when insert_plane is called with insert_above_mpcc parameter that is equal to tree->opp_list, the function returns NULL.
[HOW]
Instead, the function should insert the plane at the top of the tree.
--- drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_mpc.c +3 -2
@@ -193,8 +193,9 @@ struct mpcc *mpc1_insert_plane(/* check insert_above_mpcc exist in tree->opp_list */ struct mpcc *temp_mpcc = tree->opp_list; -while (temp_mpcc && temp_mpcc->mpcc_bot != insert_above_mpcc) - temp_mpcc = temp_mpcc->mpcc_bot; +if (temp_mpcc != insert_above_mpcc) +while (temp_mpcc && temp_mpcc->mpcc_bot != insert_above_mpcc) + temp_mpcc = temp_mpcc->mpcc_bot;if (temp_mpcc ==NULL )return NULL ; }
Greg Kroah-Hartman
maintainerPATCH 236/273 parisc: Drop loops_per_jiffy from per_cpu struct
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Helge Deller <[email protected]>
commit 93346da8ff47cc00f953c7f38a2d6ba11977fc42 upstream.
There is no need to keep a loops_per_jiffy value per cpu. Drop it.
--- arch/parisc/include/asm/processor.h | 1 - arch/parisc/kernel/processor.c | 5 ++--- 2 files changed, 2 insertions(+), 4 deletions(-)
arch/parisc/include/asm/processor.h +0 -1
@@ -108,7 +108,6 @@ struct cpuinfo_parisc {unsigned long cpu_loc;/* CPU location from PAT firmware */ unsigned int state;struct parisc_device *dev; -unsigned long loops_per_jiffy; };extern struct system_cpuinfo_parisc boot_cpu_data;
arch/parisc/kernel/processor.c +2 -3
@@ -177,7 +177,6 @@ static int __init processor_probe(structif (cpuid)memset (p,0 ,sizeof (struct cpuinfo_parisc )); - p->loops_per_jiffy = loops_per_jiffy; p->dev = dev;/* Save IODC data in case we need it */ p->hpa = dev->hpa.start;/* save CPU hpa */ p->cpuid = cpuid;/* save CPU id */
@@ -444,8 +443,8 @@ show_cpuinfo (struct seq_file *m, void *show_cache_info (m);seq_printf (m,"bogomips\t: %lu.%02lu\n" , - cpuinfo->loops_per_jiffy / (500000 /HZ ), - (cpuinfo->loops_per_jiffy / (5000 /HZ )) %100 ); + loops_per_jiffy / (500000 /HZ ), + loops_per_jiffy / (5000 /HZ ) %100 );seq_printf (m,"software id\t: %ld\n\n" , boot_cpu_data.pdc.model.sw_id);
Greg Kroah-Hartman
maintainerPATCH 237/273 autofs: fix memory leak of waitqueues in autofs_catatonic_mode
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Fedor Pchelkin <[email protected]>
[ Upstream commit ccbe77f7e45dfb4420f7f531b650c00c6e9c7507 ]
Syzkaller reports a memory leak:
BUG: memory leak
unreferenced object 0xffff88810b279e00 (size 96):
comm "syz-executor399", pid 3631, jiffies 4294964921 (age 23.870s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 08 9e 27 0b 81 88 ff ff ..........'.....
08 9e 27 0b 81 88 ff ff 00 00 00 00 00 00 00 00 ..'.............
backtrace:
[<ffffffff814cfc90>] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046
[<ffffffff81bb75ca>] kmalloc include/linux/slab.h:576 [inline]
[<ffffffff81bb75ca>] autofs_wait+0x3fa/0x9a0 fs/autofs/waitq.c:378
[<ffffffff81bb88a7>] autofs_do_expire_multi+0xa7/0x3e0 fs/autofs/expire.c:593
[<ffffffff81bb8c33>] autofs_expire_multi+0x53/0x80 fs/autofs/expire.c:619
[<ffffffff81bb6972>] autofs_root_ioctl_unlocked+0x322/0x3b0 fs/autofs/root.c:897
[<ffffffff81bb6a95>] autofs_root_ioctl+0x25/0x30 fs/autofs/root.c:910
[<ffffffff81602a9c>] vfs_ioctl fs/ioctl.c:51 [inline]
[<ffffffff81602a9c>] __do_sys_ioctl fs/ioctl.c:870 [inline]
[<ffffffff81602a9c>] __se_sys_ioctl fs/ioctl.c:856 [inline]
[<ffffffff81602a9c>] __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:856
[<ffffffff84608225>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]
[<ffffffff84608225>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
[<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcdautofs_wait_queue structs should be freed if their wait_ctr becomes zero. Otherwise they will be lost.
In this case an AUTOFS_IOC_EXPIRE_MULTI ioctl is done, then a new waitqueue struct is allocated in autofs_wait(), its initial wait_ctr equals 2. After that wait_event_killable() is interrupted (it returns -ERESTARTSYS), so that 'wq->name.name == NULL' condition may be not satisfied. Actually, this condition can be satisfied when autofs_wait_release() or autofs_catatonic_mode() is called and, what is also important, wait_ctr is decremented in those places. Upon the exit of autofs_wait(), wait_ctr is decremented to 1. Then the unmounting process
begins: kill_sb calls autofs_catatonic_mode(), which should have freed the waitqueues, but it only decrements its usage counter to zero which is not a correct behaviour.
edit:imk
This description is of course not correct. The umount performed as a result of an expire is a umount of a mount that has been automounted, it's not the autofs mount itself. They happen independently, usually after everything mounted within the autofs file system has been expired away. If everything hasn't been expired away the automount daemon can still exit leaving mounts in place. But expires done in both cases will result in a notification that calls autofs_wait_release() with a result status. The problem case is the summary execution of of the automount daemon. In this case any waiting processes won't be woken up until either they are terminated or the mount is umounted.
end edit: imk
So in catatonic mode we should free waitqueues which counter becomes zero.
edit: imk
Initially I was concerned that the calling of autofs_wait_release() and autofs_catatonic_mode() was not mutually exclusive but that can't be the case (obviously) because the queue entry (or entries) is removed from the list when either of these two functions are called. Consequently the wait entry will be freed by only one of these functions or by the woken process in autofs_wait() depending on the order of the calls.
end edit: imk
Message-Id: <[email protected]>
--- fs/autofs/waitq.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
fs/autofs/waitq.c +2 -1
@@ -35,8 +35,9 @@ void autofs_catatonic_mode(struct autofs_sb_info *sbi) wq->status = -ENOENT ;/* Magic is gone - report failure */ kfree (wq->name.name); wq->name.name =NULL ; - wq->wait_ctr--;wake_up_interruptible (&wq->queue); +if (!--wq->wait_ctr) +kfree (wq); wq = nwq; }fput (sbi->pipe);/* Close the pipe */
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 238/273 btrfs: output extra debug info if we failed to find an inline backref
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Qu Wenruo <[email protected]>
[ Upstream commit 7f72f50547b7af4ddf985b07fc56600a4deba281 ]
[BUG]
Syzbot reported several warning triggered insidelookup_inline_extent_backref().
[CAUSE]
As usual, the reproducer doesn't reliably trigger locally here, but at least we know the WARN_ON() is triggered when an inline backref can not be found, and it can only be triggered when @insert is true. (I.e. inserting a new inline backref, which means the backref should already exist)
[ENHANCEMENT]
After the WARN_ON(), dump all the parameters and the extent tree leaf to help debug.
--- fs/btrfs/extent-tree.c | 5 +++++ 1 file changed, 5 insertions(+)
fs/btrfs/extent-tree.c +5 -0
@@ -1549,6 +1549,11 @@ int lookup_inline_extent_backref(struct btrfs_trans_handle *trans, err = -ENOENT ; goto out; }else if (WARN_ON (ret)) { +btrfs_print_leaf (path->nodes[0 ]); +btrfs_err (fs_info, +"extent item not found for insert, bytenr %llu num_bytes %llu parent %llu root_objectid %llu owner %llu offset %llu" , + bytenr, num_bytes, parent, root_objectid, owner, + offset); err = -EIO ; goto out; }
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 239/273 ACPICA: Add AML_NO_OPERAND_RESOLVE flag to Timer
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Abhishek Mainkar <[email protected]>
[ Upstream commit 3a21ffdbc825e0919db9da0e27ee5ff2cc8a863e ]
ACPICA commit 90310989a0790032f5a0140741ff09b545af4bc5
According to the ACPI specification 19.6.134, no argument is required to be passed for ASL Timer instruction. For taking care of no argument, AML_NO_OPERAND_RESOLVE flag is added to ASL Timer instruction opcode.
When ASL timer instruction interpreted by ACPI interpreter, getting error. After adding AML_NO_OPERAND_RESOLVE flag to ASL Timer instruction opcode, issue is not observed.
=============================================================
UBSAN: array-index-out-of-bounds in acpica/dswexec.c:401:12 index -1 is out of range for type 'union acpi_operand_object *[9]' CPU: 37 PID: 1678 Comm: cat Not tainted 6.0.0-dev-th500-6.0.y-1+bcf8c46459e407-generic-64k HW name: NVIDIA BIOS v1.1.1-d7acbfc-dirty 12/19/2022 Call trace: dump_backtrace+0xe0/0x130 show_stack+0x20/0x60 dump_stack_lvl+0x68/0x84 dump_stack+0x18/0x34 ubsan_epilogue+0x10/0x50 __ubsan_handle_out_of_bounds+0x80/0x90 acpi_ds_exec_end_op+0x1bc/0x6d8 acpi_ps_parse_loop+0x57c/0x618 acpi_ps_parse_aml+0x1e0/0x4b4 acpi_ps_execute_method+0x24c/0x2b8 acpi_ns_evaluate+0x3a8/0x4bc acpi_evaluate_object+0x15c/0x37c acpi_evaluate_integer+0x54/0x15c show_power+0x8c/0x12c [acpi_power_meter]
--- drivers/acpi/acpica/psopcode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/acpi/acpica/psopcode.c +1 -1
@@ -603,7 +603,7 @@ const struct acpi_opcode_info acpi_gbl_aml_op_info[AML_NUM_OPCODES] = {/* 7E */ ACPI_OP ("Timer" ,ARGP_TIMER_OP ,ARGI_TIMER_OP ,ACPI_TYPE_ANY ,AML_CLASS_EXECUTE ,AML_TYPE_EXEC_0A_0T_1R , - AML_FLAGS_EXEC_0A_0T_1R), + AML_FLAGS_EXEC_0A_0T_1R | AML_NO_OPERAND_RESOLVE),/* ACPI 5.0 opcodes */
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 240/273 ACPI: video: Add backlight=native DMI quirk for Lenovo Ideapad Z470
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jiri Slaby (SUSE) <[email protected]>
[ Upstream commit 96b709be183c56293933ef45b8b75f8af268c6de ]
The Lenovo Ideapad Z470 predates Windows 8, so it defaults to using acpi_video for backlight control. But this is not functional on this model.
Add a DMI quirk to use the native backlight interface which works.
--- drivers/acpi/video_detect.c | 9 +++++++++ 1 file changed, 9 insertions(+)
drivers/acpi/video_detect.c +9 -0
@@ -294,6 +294,15 @@ static const struct dmi_system_id video_detect_dmi_table[] = { DMI_MATCH(DMI_BOARD_NAME, "Lenovo IdeaPad S405"), }, }, + { +/* https://bugzilla.suse.com/show_bug.cgi?id=1208724 */ + .callback = video_detect_force_native, +/* Lenovo Ideapad Z470 */ + .matches = { +DMI_MATCH (DMI_SYS_VENDOR ,"LENOVO" ), + DMI_MATCH(DMI_PRODUCT_VERSION, "IdeaPad Z470"), + }, + }, {/* https://bugzilla.redhat.com/show_bug.cgi?id=1187004 */ .callback = video_detect_force_native,
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 241/273 hw_breakpoint: fix single-stepping when using bpf_overflow_handler
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tomislav Novak <[email protected]>
[ Upstream commit d11a69873d9a7435fe6a48531e165ab80a8b1221 ]
Arm platforms use is_default_overflow_handler() to determine if the hw_breakpoint code should single-step over the breakpoint trigger or let the custom handler deal with it.
Since bpf_overflow_handler() currently isn't recognized as a default handler, attaching a BPF program to a PERF_TYPE_BREAKPOINT event causes it to keep firing (the instruction triggering the data abort exception is never skipped). For example:
# bpftrace -e 'watchpoint:0x10000:4:w { print("hit") }' -c ./test
Attaching 1 probe...
hit
hit
[...]
^C(./test performs a single 4-byte store to 0x10000)
This patch replaces the check with uses_default_overflow_handler(), which accounts for the bpf_overflow_handler() case by also testing if one of the perf_event_output functions gets invoked indirectly, via orig_default_handler.
--- arch/arm/kernel/hw_breakpoint.c | 8 ++++---- arch/arm64/kernel/hw_breakpoint.c | 4 ++-- include/linux/perf_event.h | 22 +++++++++++++++++++--- 3 files changed, 25 insertions(+), 9 deletions(-)
arch/arm/kernel/hw_breakpoint.c +4 -4
@@ -631,7 +631,7 @@ int hw_breakpoint_arch_parse(struct perf_event *bp, hw->address &= ~alignment_mask; hw->ctrl.len <<= offset; -if (is_default_overflow_handler (bp)) { +if (uses_default_overflow_handler (bp)) {/* * Mismatch breakpoints are required for single-stepping * breakpoints.
@@ -803,7 +803,7 @@ static void watchpoint_handler(unsigned long addr, unsigned int fsr,* Otherwise, insert a temporary mismatch breakpoint so that * we can single-step over the watchpoint trigger. */ -if (!is_default_overflow_handler (wp)) +if (!uses_default_overflow_handler (wp))continue ; step:enable_single_step (wp,instruction_pointer (regs));
@@ -816,7 +816,7 @@ static void watchpoint_handler(unsigned long addr, unsigned int fsr, info->trigger = addr;pr_debug ("watchpoint fired: address = 0x%x\n" , info->trigger);perf_bp_event (wp, regs); -if (is_default_overflow_handler (wp)) +if (uses_default_overflow_handler (wp))enable_single_step (wp,instruction_pointer (regs)); }
@@ -891,7 +891,7 @@ static void breakpoint_handler(unsigned long unknown, struct pt_regs *regs) info->trigger = addr;pr_debug ("breakpoint fired: address = 0x%x\n" , addr);perf_bp_event (bp, regs); -if (is_default_overflow_handler (bp)) +if (uses_default_overflow_handler (bp))enable_single_step (bp, addr); goto unlock; }
arch/arm64/kernel/hw_breakpoint.c +2 -2
@@ -661,7 +661,7 @@ static int breakpoint_handler(unsigned long unused, unsigned int esr,perf_bp_event (bp, regs);/* Do we need to handle the stepping? */ -if (is_default_overflow_handler (bp)) +if (uses_default_overflow_handler (bp)) step =1 ; unlock:rcu_read_unlock ();
@@ -740,7 +740,7 @@ static u64 get_distance_from_watchpoint(unsigned long addr, u64 val,static int watchpoint_report (struct perf_event *wp,unsigned long addr,struct pt_regs *regs) { -int step =is_default_overflow_handler (wp); +int step =uses_default_overflow_handler (wp);struct arch_hw_breakpoint *info =counter_arch_bp (wp); info->trigger = addr;
include/linux/perf_event.h +19 -3
@@ -998,15 +998,31 @@ extern void perf_event_output(struct perf_event *event, struct pt_regs *regs);static inline bool -is_default_overflow_handler (struct perf_event *event) +__is_default_overflow_handler (perf_overflow_handler_t overflow_handler) { -if (likely (event->overflow_handler == perf_event_output_forward)) +if (likely (overflow_handler == perf_event_output_forward))return true; -if (unlikely (event->overflow_handler == perf_event_output_backward)) +if (unlikely (overflow_handler == perf_event_output_backward))return true;return false; } +#define is_default_overflow_handler (event) \ + __is_default_overflow_handler((event)->overflow_handler) + +#ifdef CONFIG_BPF_SYSCALL +static inline bool uses_default_overflow_handler (struct perf_event *event) +{ +if (likely (is_default_overflow_handler (event))) +return true; + +return __is_default_overflow_handler (event->orig_overflow_handler); +} +#else +#define uses_default_overflow_handler (event) \ + is_default_overflow_handler(event) +#endif + extern void perf_event_header__init_id(struct perf_event_header *header, struct perf_sample_data *data,
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 242/273 wifi: ath9k: fix printk specifier
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dongliang Mu <[email protected]>
[ Upstream commit 061115fbfb2ce5870c9a004d68dc63138c07c782 ]
Smatch reports:
ath_pci_probe() warn: argument 4 to %lx specifier is cast from pointer ath_ahb_probe() warn: argument 4 to %lx specifier is cast from pointer
Fix it by modifying %lx to %p in the printk format string.
Note that with this change, the pointer address will be printed as a hashed value by default. This is appropriate because the kernel should not leak kernel pointers to user space in an informational message. If someone wants to see the real address for debugging purposes, this can be achieved with the no_hash_pointers kernel option.
--- drivers/net/wireless/ath/ath9k/ahb.c | 4 ++-- drivers/net/wireless/ath/ath9k/pci.c | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-)
drivers/net/wireless/ath/ath9k/ahb.c +2 -2
@@ -136,8 +136,8 @@ static int ath_ahb_probe(struct platform_device *pdev) ah = sc->sc_ah;ath9k_hw_name (ah, hw_name,sizeof (hw_name)); -wiphy_info (hw->wiphy,"%s mem=0x%lx, irq=%d\n" , - hw_name, (unsigned long )mem, irq); +wiphy_info (hw->wiphy,"%s mem=0x%p, irq=%d\n" , + hw_name, mem, irq);return 0 ;
drivers/net/wireless/ath/ath9k/pci.c +2 -2
@@ -993,8 +993,8 @@ static int ath_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id) sc->sc_ah->msi_reg =0 ;ath9k_hw_name (sc->sc_ah, hw_name,sizeof (hw_name)); -wiphy_info (hw->wiphy,"%s mem=0x%lx, irq=%d\n" , - hw_name, (unsigned long )sc->mem, pdev->irq); +wiphy_info (hw->wiphy,"%s mem=0x%p, irq=%d\n" , + hw_name, sc->mem, pdev->irq);return 0 ;
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 243/273 wifi: mwifiex: fix fortify warning
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dmitry Antipov <[email protected]>
[ Upstream commit dcce94b80a954a8968ff29fafcfb066d6197fa9a ]
When compiling with gcc 13.1 and CONFIG_FORTIFY_SOURCE=y, I've noticed the following:
In function ‘fortify_memcpy_chk’,
inlined from ‘mwifiex_construct_tdls_action_frame’ at drivers/net/wireless/marvell/mwifiex/tdls.c:765:3, inlined from ‘mwifiex_send_tdls_action_frame’ at drivers/net/wireless/marvell/mwifiex/tdls.c:856:6:./include/linux/fortify-string.h:529:25: warning: call to ‘__read_overflow2_field’ declared with attribute warning: detected read beyond size of field (2nd parameter);
maybe use struct_group()? [-Wattribute-warning]
529 | __read_overflow2_field(q_size_field, size);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~The compiler actually complains on:
memmove(pos + ETH_ALEN, &mgmt->u.action.category,
sizeof(mgmt->u.action.u.tdls_discover_resp));
and it happens because the fortification logic interprets this as an attempt to overread 1-byte 'u.action.category' member of 'struct ieee80211_mgmt'. To silence this warning, it's enough to pass an address of 'u.action' itself instead of an address of its first member.
This also fixes an improper usage of 'sizeof()'. Since 'skb' is extended with 'sizeof(mgmt->u.action.u.tdls_discover_resp) + 1' bytes (where 1 is actually 'sizeof(mgmt->u.action.category)'), I assume that the same number of bytes should be copied.
--- drivers/net/wireless/marvell/mwifiex/tdls.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
drivers/net/wireless/marvell/mwifiex/tdls.c +6 -3
@@ -737,6 +737,7 @@ mwifiex_construct_tdls_action_frame(struct mwifiex_private *priv,int ret;u16 capab;struct ieee80211_ht_cap *ht_cap; +unsigned int extra;u8 radio, *pos; capab = priv->curr_bss_params.bss_descriptor.cap_info_bitmap;
@@ -755,7 +756,10 @@ mwifiex_construct_tdls_action_frame(struct mwifiex_private *priv,switch (action_code) {case WLAN_PUB_ACTION_TDLS_DISCOVER_RES : -skb_put (skb,sizeof (mgmt->u.action.u.tdls_discover_resp) +1 ); +/* See the layout of 'struct ieee80211_mgmt'. */ + extra =sizeof (mgmt->u.action.u.tdls_discover_resp) + +sizeof (mgmt->u.action.category); +skb_put (skb, extra); mgmt->u.action.category =WLAN_CATEGORY_PUBLIC ; mgmt->u.action.u.tdls_discover_resp.action_code =WLAN_PUB_ACTION_TDLS_DISCOVER_RES ;
@@ -764,8 +768,7 @@ mwifiex_construct_tdls_action_frame(struct mwifiex_private *priv, mgmt->u.action.u.tdls_discover_resp.capability =cpu_to_le16 (capab);/* move back for addr4 */ -memmove (pos +ETH_ALEN , &mgmt->u.action.category, -sizeof (mgmt->u.action.u.tdls_discover_resp)); +memmove (pos +ETH_ALEN , &mgmt->u.action, extra);/* init address 4 */ memcpy (pos, bc_addr,ETH_ALEN );
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 244/273 crypto: lib/mpi - avoid null pointer deref in mpi_cmp_ui()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark O'Donovan <[email protected]>
[ Upstream commit 9e47a758b70167c9301d2b44d2569f86c7796f2d ]
During NVMeTCP Authentication a controller can trigger a kernel oops by specifying the 8192 bit Diffie Hellman group and passing a correctly sized, but zeroed Diffie Hellamn value. mpi_cmp_ui() was detecting this if the second parameter was 0, but 1 is passed from dh_is_pubkey_valid(). This causes the null pointer u->d to be dereferenced towards the end of mpi_cmp_ui()
--- lib/mpi/mpi-cmp.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
lib/mpi/mpi-cmp.c +6 -2
@@ -25,8 +25,12 @@ int mpi_cmp_ui(MPI u, unsigned long v)mpi_limb_t limb = v;mpi_normalize (u); -if (!u->nlimbs && !limb) -return 0 ; +if (u->nlimbs ==0 ) { +if (v ==0 ) +return 0 ; +else +return -1 ; + }if (u->sign)return -1 ;if (u->nlimbs >1 )
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 245/273 tpm_tis: Resend command to recover from data transfer errors
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Alexander Steffen <[email protected]>
[ Upstream commit 280db21e153d8810ce3b93640c63ae922bcb9e8e ]
Similar to the transmission of TPM responses, also the transmission of TPM commands may become corrupted. Instead of aborting when detecting such issues, try resending the command again.
--- drivers/char/tpm/tpm_tis_core.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-)
drivers/char/tpm/tpm_tis_core.c +11 -4
@@ -425,10 +425,17 @@ static int tpm_tis_send_main(struct tpm_chip *chip, const u8 *buf, size_t len)int rc;u32 ordinal;unsigned long dur; - - rc =tpm_tis_send_data (chip, buf, len); -if (rc <0 ) -return rc; +unsigned int try; + +for (try =0 ; try <TPM_RETRY ; try++) { + rc =tpm_tis_send_data (chip, buf, len); +if (rc >=0 ) +/* Data transfer done successfully */ +break ; +else if (rc != -EIO ) +/* Data transfer failed, not recoverable */ +return rc; + }/* go and do it */ rc =tpm_tis_write8 (priv,TPM_STS (priv->locality),TPM_STS_GO );
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 246/273 alx: fix OOB-read compiler warning
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: GONG, Ruiqi <[email protected]>
[ Upstream commit 3a198c95c95da10ad844cbeade2fe40bdf14c411 ]
The following message shows up when compiling with W=1:
In function ‘fortify_memcpy_chk’,
inlined from ‘alx_get_ethtool_stats’ at drivers/net/ethernet/atheros/alx/ethtool.c:297:2:./include/linux/fortify-string.h:592:4: error: call to ‘__read_overflow2_field’ declared with attribute warning: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Werror=attribute-warning]
592 | __read_overflow2_field(q_size_field, size);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~In order to get alx stats altogether, alx_get_ethtool_stats() reads beyond hw->stats.rx_ok. Fix this warning by directly copying hw->stats, and refactor the unnecessarily complicated BUILD_BUG_ON btw.
--- drivers/net/ethernet/atheros/alx/ethtool.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
drivers/net/ethernet/atheros/alx/ethtool.c +2 -3
@@ -281,9 +281,8 @@ static void alx_get_ethtool_stats(struct net_device *netdev,spin_lock (&alx->stats_lock);alx_update_hw_stats (hw); -BUILD_BUG_ON (sizeof (hw->stats) - offsetof(struct alx_hw_stats , rx_ok) < -ALX_NUM_STATS *sizeof (u64)); -memcpy (data, &hw->stats.rx_ok,ALX_NUM_STATS *sizeof (u64)); +BUILD_BUG_ON (sizeof (hw->stats) !=ALX_NUM_STATS *sizeof (u64)); +memcpy (data, &hw->stats,sizeof (hw->stats));spin_unlock (&alx->stats_lock); }
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 247/273 drm/exynos: fix a possible null-pointer dereference due to data race in exynos_drm_crtc_atomic_disable()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tuo Li <[email protected]>
[ Upstream commit 2e63972a2de14482d0eae1a03a73e379f1c3f44c ]
The variable crtc->state->event is often protected by the lock crtc->dev->event_lock when is accessed. However, it is accessed as a condition of an if statement in exynos_drm_crtc_atomic_disable() without holding the lock:
if (crtc->state->event && !crtc->state->active)
However, if crtc->state->event is changed to NULL by another thread right after the conditions of the if statement is checked to be true, a null-pointer dereference can occur in drm_crtc_send_vblank_event():
e->pipe = pipe;
To fix this possible null-pointer dereference caused by data race, the spin lock coverage is extended to protect the if statement as well as the function call to drm_crtc_send_vblank_event().
Added relevant link.
--- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
drivers/gpu/drm/exynos/exynos_drm_crtc.c +2 -3
@@ -43,13 +43,12 @@ static void exynos_drm_crtc_atomic_disable(struct drm_crtc *crtc,if (exynos_crtc->ops->disable) exynos_crtc->ops->disable (exynos_crtc); +spin_lock_irq (&crtc->dev->event_lock);if (crtc->state->event && !crtc->state->active) { -spin_lock_irq (&crtc->dev->event_lock);drm_crtc_send_vblank_event (crtc, crtc->state->event); -spin_unlock_irq (&crtc->dev->event_lock); - crtc->state->event =NULL ; } +spin_unlock_irq (&crtc->dev->event_lock); } static int exynos_crtc_atomic_check(struct drm_crtc *crtc,
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 248/273 md: raid1: fix potential OOB in raid1_remove_disk()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhang Shurong <[email protected]>
[ Upstream commit 8b0472b50bcf0f19a5119b00a53b63579c8e1e4d ]
If rddev->raid_disk is greater than mddev->raid_disks, there will be an out-of-bounds in raid1_remove_disk(). We have already found similar reports as follows:
1) commit d17f744e883b ("md-raid10: fix KASAN warning")
2) commit 1ebc2cec0b7d ("dm raid: fix KASAN warning in raid5_remove_disk")
Fix this bug by checking whether the "number" variable is valid.
--- drivers/md/raid1.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/md/raid1.c +4 -0
@@ -1783,6 +1783,10 @@ static int raid1_remove_disk(struct mddev *mddev, struct md_rdev *rdev)struct r1conf *conf = mddev->private;int err =0 ;int number = rdev->raid_disk; + +if (unlikely (number >= conf->raid_disks)) + goto abort; +struct raid1_info *p = conf->mirrors + number;if (rdev != p->rdev)
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 249/273 ext2: fix datatype of block number in ext2_xattr_set2()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Georg Ottinger <[email protected]>
[ Upstream commit e88076348425b7d0491c8c98d8732a7df8de7aa3 ]
I run a small server that uses external hard drives for backups. The backup software I use uses ext2 filesystems with 4KiB block size and the server is running SELinux and therefore relies on xattr. I recently upgraded the hard drives from 4TB to 12TB models. I noticed that after transferring some TBs I got a filesystem error "Freeing blocks not in datazone - block = 18446744071529317386, count = 1" and the backup process stopped. Trying to fix the fs with e2fsck resulted in a completely corrupted fs. The error probably came from ext2_free_blocks(), and because of the large number 18e19 this problem immediately looked like some kind of integer overflow. Whereas the 4TB fs was about 1e9 blocks, the new 12TB is about 3e9 blocks. So, searching the ext2 code, I came across the line in fs/ext2/xattr.c:745 where ext2_new_block() is called and the resulting block number is stored in the variable block as an int datatype. If a block with a block number greater than INT32_MAX is returned, this variable overflows and the call to sb_getblk() at line fs/ext2/xattr.c:750 fails, then the call to ext2_free_blocks() produces the error.
Message-Id: <[email protected]>
--- fs/ext2/xattr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
fs/ext2/xattr.c +2 -2
@@ -664,10 +664,10 @@ ext2_xattr_set2(struct inode *inode, struct buffer_head *old_bh,/* We need to allocate a new block */ ext2_fsblk_t goal =ext2_group_first_block_no (sb,EXT2_I (inode)->i_block_group); -int block =ext2_new_block (inode, goal, &error); +ext2_fsblk_t block =ext2_new_block (inode, goal, &error);if (error) goto cleanup; -ea_idebug (inode,"creating block %d" , block); +ea_idebug (inode,"creating block %lu" , block); new_bh =sb_getblk (sb, block);if (unlikely (!new_bh)) {
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 250/273 fs/jfs: prevent double-free in dbUnmount() after failed jfs_remount()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrew Kanner <[email protected]>
[ Upstream commit cade5397e5461295f3cb87880534b6a07cafa427 ]
Syzkaller reported the following issue:
==================================================================
BUG: KASAN: double-free in slab_free mm/slub.c:3787 [inline] BUG: KASAN: double-free in __kmem_cache_free+0x71/0x110 mm/slub.c:3800 Free of addr ffff888086408000 by task syz-executor.4/12750 [...] Call Trace: <TASK> [...] kasan_report_invalid_free+0xac/0xd0 mm/kasan/report.c:482 ____kasan_slab_free+0xfb/0x120 kasan_slab_free include/linux/kasan.h:177 [inline] slab_free_hook mm/slub.c:1781 [inline] slab_free_freelist_hook+0x12e/0x1a0 mm/slub.c:1807 slab_free mm/slub.c:3787 [inline] __kmem_cache_free+0x71/0x110 mm/slub.c:3800 dbUnmount+0xf4/0x110 fs/jfs/jfs_dmap.c:264 jfs_umount+0x248/0x3b0 fs/jfs/jfs_umount.c:87 jfs_put_super+0x86/0x190 fs/jfs/super.c:194 generic_shutdown_super+0x130/0x310 fs/super.c:492 kill_block_super+0x79/0xd0 fs/super.c:1386 deactivate_locked_super+0xa7/0xf0 fs/super.c:332 cleanup_mnt+0x494/0x520 fs/namespace.c:1291 task_work_run+0x243/0x300 kernel/task_work.c:179 resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] exit_to_user_mode_loop+0x124/0x150 kernel/entry/common.c:171 exit_to_user_mode_prepare+0xb2/0x140 kernel/entry/common.c:203 __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline] syscall_exit_to_user_mode+0x26/0x60 kernel/entry/common.c:296 do_syscall_64+0x49/0xb0 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x63/0xcd [...] </TASK> Allocated by task 13352: kasan_save_stack mm/kasan/common.c:45 [inline] kasan_set_track+0x3d/0x60 mm/kasan/common.c:52 ____kasan_kmalloc mm/kasan/common.c:371 [inline] __kasan_kmalloc+0x97/0xb0 mm/kasan/common.c:380 kmalloc include/linux/slab.h:580 [inline] dbMount+0x54/0x980 fs/jfs/jfs_dmap.c:164 jfs_mount+0x1dd/0x830 fs/jfs/jfs_mount.c:121 jfs_fill_super+0x590/0xc50 fs/jfs/super.c:556 mount_bdev+0x26c/0x3a0 fs/super.c:1359 legacy_get_tree+0xea/0x180 fs/fs_context.c:610 vfs_get_tree+0x88/0x270 fs/super.c:1489 do_new_mount+0x289/0xad0 fs/namespace.c:3145 do_mount fs/namespace.c:3488 [inline] __do_sys_mount fs/namespace.c:3697 [inline] __se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3674 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Freed by task 13352: kasan_save_stack mm/kasan/common.c:45 [inline] kasan_set_track+0x3d/0x60 mm/kasan/common.c:52 kasan_save_free_info+0x27/0x40 mm/kasan/generic.c:518 ____kasan_slab_free+0xd6/0x120 mm/kasan/common.c:236 kasan_slab_free include/linux/kasan.h:177 [inline] slab_free_hook mm/slub.c:1781 [inline] slab_free_freelist_hook+0x12e/0x1a0 mm/slub.c:1807 slab_free mm/slub.c:3787 [inline] __kmem_cache_free+0x71/0x110 mm/slub.c:3800 dbUnmount+0xf4/0x110 fs/jfs/jfs_dmap.c:264 jfs_mount_rw+0x545/0x740 fs/jfs/jfs_mount.c:247 jfs_remount+0x3db/0x710 fs/jfs/super.c:454 reconfigure_super+0x3bc/0x7b0 fs/super.c:935 vfs_fsconfig_locked fs/fsopen.c:254 [inline] __do_sys_fsconfig fs/fsopen.c:439 [inline] __se_sys_fsconfig+0xad5/0x1060 fs/fsopen.c:314 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
[...]
JFS_SBI(ipbmap->i_sb)->bmap wasn't set to NULL after kfree() in dbUnmount().
Syzkaller uses faultinject to reproduce this KASAN double-free warning. The issue is triggered if either diMount() or dbMount() fail in jfs_remount(), since diUnmount() or dbUnmount() already happened in such a case - they will do double-free on next execution: jfs_umount or jfs_remount.
Tested on both upstream and jfs-next by syzkaller.
--- fs/jfs/jfs_dmap.c | 1 + 1 file changed, 1 insertion(+)
fs/jfs/jfs_dmap.c +1 -0
@@ -282,6 +282,7 @@ int dbUnmount(struct inode *ipbmap, int mounterror)/* free the memory for the in-memory bmap. */ kfree (bmp); +JFS_SBI (ipbmap->i_sb)->bmap =NULL ;return (0 ); }
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 251/273 jfs: fix invalid free of JFS_IP(ipimap)->i_imap in diUnmount
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Liu Shixin via Jfs-discussion <[email protected]>
[ Upstream commit 6e2bda2c192d0244b5a78b787ef20aa10cb319b7 ]
syzbot found an invalid-free in diUnmount:
BUG: KASAN: double-free in slab_free mm/slub.c:3661 [inline] BUG: KASAN: double-free in __kmem_cache_free+0x71/0x110 mm/slub.c:3674
Free of addr ffff88806f410000 by task syz-executor131/3632
CPU: 0 PID: 3632 Comm: syz-executor131 Not tainted 6.1.0-rc7-syzkaller-00012-gca57f02295f1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 print_address_description+0x74/0x340 mm/kasan/report.c:284 print_report+0x107/0x1f0 mm/kasan/report.c:395 kasan_report_invalid_free+0xac/0xd0 mm/kasan/report.c:460 ____kasan_slab_free+0xfb/0x120 kasan_slab_free include/linux/kasan.h:177 [inline] slab_free_hook mm/slub.c:1724 [inline] slab_free_freelist_hook+0x12e/0x1a0 mm/slub.c:1750 slab_free mm/slub.c:3661 [inline] __kmem_cache_free+0x71/0x110 mm/slub.c:3674 diUnmount+0xef/0x100 fs/jfs/jfs_imap.c:195 jfs_umount+0x108/0x370 fs/jfs/jfs_umount.c:63 jfs_put_super+0x86/0x190 fs/jfs/super.c:194 generic_shutdown_super+0x130/0x310 fs/super.c:492 kill_block_super+0x79/0xd0 fs/super.c:1428 deactivate_locked_super+0xa7/0xf0 fs/super.c:332 cleanup_mnt+0x494/0x520 fs/namespace.c:1186 task_work_run+0x243/0x300 kernel/task_work.c:179 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0x664/0x2070 kernel/exit.c:820 do_group_exit+0x1fd/0x2b0 kernel/exit.c:950 __do_sys_exit_group kernel/exit.c:961 [inline] __se_sys_exit_group kernel/exit.c:959 [inline] __x64_sys_exit_group+0x3b/0x40 kernel/exit.c:959 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd
[...]
JFS_IP(ipimap)->i_imap is not setting to NULL after free in diUnmount. If jfs_remount() free JFS_IP(ipimap)->i_imap but then failed at diMount(). JFS_IP(ipimap)->i_imap will be freed once again.
Fix this problem by setting JFS_IP(ipimap)->i_imap to NULL after free.
--- fs/jfs/jfs_imap.c | 1 + 1 file changed, 1 insertion(+)
fs/jfs/jfs_imap.c +1 -0
@@ -208,6 +208,7 @@ int diUnmount(struct inode *ipimap, int mounterror)* free in-memory control structure */ kfree (imap); +JFS_IP (ipimap)->i_imap =NULL ;return (0 ); }
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 252/273 PCI: dwc: Provide deinit callback for i.MX
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mark Brown <[email protected]>
[ Upstream commit fc8b24c28bec19fc0621d108b9ee81ddfdedb25a ]
The i.MX integration for the DesignWare PCI controller has a _host_exit() operation which undoes everything that the _host_init() operation does but does not wire this up as the host_deinit callback for the core, or call it in any path other than suspend. This means that if we ever unwind the initial probe of the device, for example because it fails, the regulator core complains that the regulators for the device were left enabled:
imx6q-pcie 33800000.pcie: iATU: unroll T, 4 ob, 4 ib, align 64K, limit 16G imx6q-pcie 33800000.pcie: Phy link never came up
imx6q-pcie 33800000.pcie: Phy link never came up
imx6q-pcie: probe of 33800000.pcie failed with error -110
------------[ cut here ]------------ WARNING: CPU: 2 PID: 46 at drivers/regulator/core.c:2396 _regulator_put+0x110/0x128
Wire up the callback so that the core can clean up after itself.
--- drivers/pci/controller/dwc/pci-imx6.c | 1 + 1 file changed, 1 insertion(+)
drivers/pci/controller/dwc/pci-imx6.c +1 -0
@@ -642,6 +642,7 @@ static int imx6_pcie_host_init(struct pcie_port *pp)static const struct dw_pcie_host_ops imx6_pcie_host_ops = { .host_init = imx6_pcie_host_init, + .host_deinit = imx6_pcie_host_exit, }; static int imx6_add_pcie_port(struct imx6_pcie *imx6_pcie,
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 253/273 powerpc/pseries: fix possible memory leak in ibmebus_bus_init()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: ruanjinjie <[email protected]>
[ Upstream commit afda85b963c12947e298ad85d757e333aa40fd74 ]
If device_register() returns error in ibmebus_bus_init(), name of kobject which is allocated in dev_set_name() called in device_add() is leaked.
As comment of device_add() says, it should call put_device() to drop the reference count that was set in device_initialize() when it fails, so the name can be freed in kobject_cleanup().
--- arch/powerpc/platforms/pseries/ibmebus.c | 1 + 1 file changed, 1 insertion(+)
arch/powerpc/platforms/pseries/ibmebus.c +1 -0
@@ -452,6 +452,7 @@ static int __init ibmebus_bus_init(void)if (err) {printk (KERN_WARNING "%s: device_register returned %i\n" , __func__, err); +put_device (&ibmebus_bus_device);bus_unregister (&ibmebus_bus_type);return err;
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 254/273 media: dvb-usb-v2: af9035: Fix null-ptr-deref in af9035_i2c_master_xfer
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhang Shurong <[email protected]>
[ Upstream commit 7bf744f2de0a848fb1d717f5831b03db96feae89 ]
In af9035_i2c_master_xfer, msg is controlled by user. When msg[i].buf is null and msg[i].len is zero, former checks on msg[i].buf would be passed. Malicious data finally reach af9035_i2c_master_xfer. If accessing msg[i].buf[0] without sanity check, null ptr deref would happen. We add check on msg[i].len to prevent crash.
Similar commit:
commit 0ed554fd769a
("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")
--- drivers/media/usb/dvb-usb-v2/af9035.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-)
drivers/media/usb/dvb-usb-v2/af9035.c +8 -6
@@ -284,6 +284,7 @@ static int af9035_i2c_master_xfer(structstruct dvb_usb_device *d =i2c_get_adapdata (adap);struct state *state =d_to_priv (d);int ret; +u32 reg;if (mutex_lock_interruptible (&d->i2c_mutex) <0 )return -EAGAIN ;
@@ -336,8 +337,10 @@ static int af9035_i2c_master_xfer(struct 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 ;/* demod access via firmware interface */ -u32 reg = msg[0 ].buf[0 ] <<16 | msg[0 ].buf[1 ] <<8 | + reg = msg[0 ].buf[0 ] <<16 | msg[0 ].buf[1 ] <<8 | msg[0 ].buf[2 ];if (msg[0 ].addr == state->af9033_i2c_addr[1 ])
@@ -395,17 +398,16 @@ static int af9035_i2c_master_xfer(struct 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 ;/* demod access via firmware interface */ -u32 reg = msg[0 ].buf[0 ] <<16 | msg[0 ].buf[1 ] <<8 | + reg = msg[0 ].buf[0 ] <<16 | msg[0 ].buf[1 ] <<8 | msg[0 ].buf[2 ];if (msg[0 ].addr == state->af9033_i2c_addr[1 ]) reg |=0x100000 ; - ret = (msg[0 ].len >=3 ) ?af9035_wr_regs (d, reg, - &msg[0 ].buf[3 ], - msg[0 ].len -3 ) - : -EOPNOTSUPP ; + ret =af9035_wr_regs (d, reg, &msg[0 ].buf[3 ], msg[0 ].len -3 ); }else {/* I2C write */ u8 buf[MAX_XFER_SIZE ];
Greg Kroah-Hartman
maintainerPATCH 255/273 media: dw2102: Fix null-ptr-deref in dw2102_i2c_transfer()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhang Shurong <[email protected]>
[ Upstream commit 5ae544d94abc8ff77b1b9bf8774def3fa5689b5b ]
In dw2102_i2c_transfer, msg is controlled by user. When msg[i].buf is null and msg[i].len is zero, former checks on msg[i].buf would be passed. Malicious data finally reach dw2102_i2c_transfer. If accessing msg[i].buf[0] without sanity check, null ptr deref would happen. We add check on msg[i].len to prevent crash.
Similar commit:
commit 950e252cb469
("[media] dw2102: limit messages to buffer size")
--- drivers/media/usb/dvb-usb/dw2102.c | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+)
drivers/media/usb/dvb-usb/dw2102.c +24 -0
@@ -131,6 +131,10 @@ static int dw2102_i2c_transfer(struct i2c_adapter *adap, struct i2c_msg msg[],switch (num) {case 2 : +if (msg[0 ].len <1 ) { + num = -EOPNOTSUPP ; +break ; + }/* read stv0299 register */ value = msg[0 ].buf[0 ];/* register */ for (i =0 ; i < msg[1 ].len; i++) {
@@ -142,6 +146,10 @@ static int dw2102_i2c_transfer(struct i2c_adapter *adap, struct i2c_msg msg[],case 1 :switch (msg[0 ].addr) {case 0x68 : +if (msg[0 ].len <2 ) { + num = -EOPNOTSUPP ; +break ; + }/* write to stv0299 register */ buf6[0 ] =0x2a ; buf6[1 ] = msg[0 ].buf[0 ];
@@ -151,6 +159,10 @@ static int dw2102_i2c_transfer(struct i2c_adapter *adap, struct i2c_msg msg[],break ;case 0x60 :if (msg[0 ].flags ==0 ) { +if (msg[0 ].len <4 ) { + num = -EOPNOTSUPP ; +break ; + }/* write to tuner pll */ buf6[0 ] =0x2c ; buf6[1 ] =5 ;
@@ -162,6 +174,10 @@ static int dw2102_i2c_transfer(struct i2c_adapter *adap, struct i2c_msg msg[],dw210x_op_rw (d->udev,0xb2 ,0 ,0 , buf6,7 ,DW210X_WRITE_MSG ); }else { +if (msg[0 ].len <1 ) { + num = -EOPNOTSUPP ; +break ; + }/* read from tuner */ dw210x_op_rw (d->udev,0xb5 ,0 ,0 , buf6,1 ,DW210X_READ_MSG );
@@ -169,12 +185,20 @@ static int dw2102_i2c_transfer(struct i2c_adapter *adap, struct i2c_msg msg[], }break ;case (DW2102_RC_QUERY ): +if (msg[0 ].len <2 ) { + num = -EOPNOTSUPP ; +break ; + }dw210x_op_rw (d->udev,0xb8 ,0 ,0 , buf6,2 ,DW210X_READ_MSG ); msg[0 ].buf[0 ] = buf6[0 ]; msg[0 ].buf[1 ] = buf6[1 ];break ;case (DW2102_VOLTAGE_CTRL ): +if (msg[0 ].len <1 ) { + num = -EOPNOTSUPP ; +break ; + } buf6[0 ] =0x30 ; buf6[1 ] = msg[0 ].buf[0 ]; dw210x_op_rw(d->udev, 0xb2, 0, 0,
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 256/273 media: af9005: Fix null-ptr-deref in af9005_i2c_xfer
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhang Shurong <[email protected]>
[ Upstream commit f4ee84f27625ce1fdf41e8483fa0561a1b837d10 ]
In af9005_i2c_xfer, msg is controlled by user. When msg[i].buf is null and msg[i].len is zero, former checks on msg[i].buf would be passed. Malicious data finally reach af9005_i2c_xfer. If accessing msg[i].buf[0] without sanity check, null ptr deref would happen. We add check on msg[i].len to prevent crash.
Similar commit:
commit 0ed554fd769a
("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")
--- drivers/media/usb/dvb-usb/af9005.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/media/usb/dvb-usb/af9005.c +5 -0
@@ -431,6 +431,10 @@ static int af9005_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msg[],if (ret ==0 ) ret =2 ; }else { +if (msg[0 ].len <2 ) { + ret = -EOPNOTSUPP ; + goto unlock; + }/* write one or more registers */ reg = msg[0 ].buf[0 ]; addr = msg[0 ].addr;
@@ -440,6 +444,7 @@ static int af9005_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msg[], ret =1 ; } +unlock:mutex_unlock (&d->i2c_mutex);return ret; }
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 257/273 media: anysee: fix null-ptr-deref in anysee_master_xfer
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhang Shurong <[email protected]>
[ Upstream commit c30411266fd67ea3c02a05c157231654d5a3bdc9 ]
In anysee_master_xfer, msg is controlled by user. When msg[i].buf is null and msg[i].len is zero, former checks on msg[i].buf would be passed. Malicious data finally reach anysee_master_xfer. If accessing msg[i].buf[0] without sanity check, null ptr deref would happen. We add check on msg[i].len to prevent crash.
Similar commit:
commit 0ed554fd769a
("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")
--- drivers/media/usb/dvb-usb-v2/anysee.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/media/usb/dvb-usb-v2/anysee.c +1 -1
@@ -211,7 +211,7 @@ static int anysee_master_xfer(struct i2c_adapter *adap, struct i2c_msg *msg,while (i < num) {if (num > i +1 && (msg[i+1 ].flags &I2C_M_RD )) { -if (msg[i].len >2 || msg[i+1 ].len >60 ) { +if (msg[i].len !=2 || msg[i +1 ].len >60 ) { ret = -EOPNOTSUPP ;break ; }
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 258/273 media: az6007: Fix null-ptr-deref in az6007_i2c_xfer()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhang Shurong <[email protected]>
[ Upstream commit 1047f9343011f2cedc73c64829686206a7e9fc3f ]
In az6007_i2c_xfer, msg is controlled by user. When msg[i].buf is null and msg[i].len is zero, former checks on msg[i].buf would be passed. Malicious data finally reach az6007_i2c_xfer. If accessing msg[i].buf[0] without sanity check, null ptr deref would happen. We add check on msg[i].len to prevent crash.
Similar commit:
commit 0ed554fd769a
("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")
--- drivers/media/usb/dvb-usb-v2/az6007.c | 8 ++++++++ 1 file changed, 8 insertions(+)
drivers/media/usb/dvb-usb-v2/az6007.c +8 -0
@@ -796,6 +796,10 @@ static int az6007_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[],if (az6007_xfer_debug)printk (KERN_DEBUG "az6007: I2C W addr=0x%x len=%d\n" , addr, msgs[i].len); +if (msgs[i].len <1 ) { + ret = -EIO ; + goto err; + } req =AZ6007_I2C_WR ; index = msgs[i].buf[0 ]; value = addr | (1 <<8 );
@@ -810,6 +814,10 @@ static int az6007_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[],if (az6007_xfer_debug)printk (KERN_DEBUG "az6007: I2C R addr=0x%x len=%d\n" , addr, msgs[i].len); +if (msgs[i].len <1 ) { + ret = -EIO ; + goto err; + } req =AZ6007_I2C_RD ; index = msgs[i].buf[0 ]; value = addr;
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 259/273 iio: core: Use min() instead of min_t() to make code more robust
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Shevchenko <[email protected]>
[ Upstream commit cb1d17535061ca295903f97f5cb0af9db719c02c ]
min() has strict type checking and preferred over min_t() for unsigned types to avoid overflow. Here it's unclear why min_t() was chosen since both variables are of the same type. In any case update to use min().
--- drivers/iio/industrialio-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/iio/industrialio-core.c +1 -1
@@ -323,7 +323,7 @@ static ssize_t iio_debugfs_write_reg(struct file *file,char buf[80 ];int ret; - count =min_t (size_t, count, (sizeof (buf)-1 )); + count =min (count,sizeof (buf) -1 );if (copy_from_user (buf, userbuf, count))return -EFAULT ;
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 260/273 media: tuners: qt1010: replace BUG_ON with a regular error
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans Verkuil <[email protected]>
[ Upstream commit ee630b29ea44d1851bb6c903f400956604834463 ]
BUG_ON is unnecessary here, and in addition it confuses smatch. Replacing this with an error return help resolve this smatch warning:
drivers/media/tuners/qt1010.c:350 qt1010_init() error: buffer overflow 'i2c_data' 34 <= 34
--- drivers/media/tuners/qt1010.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-)
drivers/media/tuners/qt1010.c +6 -5
@@ -351,11 +351,12 @@ static int qt1010_init(struct dvb_frontend *fe)else valptr = &tmpval; -BUG_ON (i >=ARRAY_SIZE (i2c_data) -1 ); - - err =qt1010_init_meas1 (priv, i2c_data[i+1 ].reg, - i2c_data[i].reg, - i2c_data[i].val, valptr); +if (i >=ARRAY_SIZE (i2c_data) -1 ) + err = -EIO ; +else + err =qt1010_init_meas1 (priv, i2c_data[i +1 ].reg, + i2c_data[i].reg, + i2c_data[i].val, valptr); i++;break ; }
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 261/273 media: pci: cx23885: replace BUG with error return
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Hans Verkuil <[email protected]>
[ Upstream commit 2e1796fd4904fdd6062a8e4589778ea899ea0c8d ]
It was completely unnecessary to use BUG in buffer_prepare(). Just replace it with an error return. This also fixes a smatch warning:
drivers/media/pci/cx23885/cx23885-video.c:422 buffer_prepare() error: uninitialized symbol 'ret'.
--- drivers/media/pci/cx23885/cx23885-video.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/media/pci/cx23885/cx23885-video.c +1 -1
@@ -420,7 +420,7 @@ static int buffer_prepare(struct vb2_buffer *vb) dev->height >> 1);break ;default : -BUG (); +return -EINVAL ;/* should not happen */ } dprintk(2, "[%p/%d] buffer_init - %dx%d %dbpp \"%s\" - dma=0x%08lx\n", buf, buf->vb.vb2_buf.index,
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 262/273 usb: gadget: fsl_qe_udc: validate endpoint index for ch9 udc
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ma Ke <[email protected]>
[ Upstream commit ce9daa2efc0872a9a68ea51dc8000df05893ef2e ]
We should verify the bound of the array to assure that host may not manipulate the index to point past endpoint array.
--- drivers/usb/gadget/udc/fsl_qe_udc.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/usb/gadget/udc/fsl_qe_udc.c +2 -0
@@ -1950,6 +1950,8 @@ static void ch9getstatus(struct qe_udc *udc, u8 request_type, u16 value, }else if ((request_type &USB_RECIP_MASK ) ==USB_RECIP_ENDPOINT ) {/* Get endpoint status */ int pipe = index &USB_ENDPOINT_NUMBER_MASK ; +if (pipe >=USB_MAX_ENDPOINTS ) + goto stall;struct qe_ep *target_ep = &udc->eps[pipe];u16 usep;
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 263/273 scsi: target: iscsi: Fix buffer overflow in lio_target_nacl_info_show()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Konstantin Shelekhin <[email protected]>
[ Upstream commit 801f287c93ff95582b0a2d2163f12870a2f076d4 ]
The function lio_target_nacl_info_show() uses sprintf() in a loop to print details for every iSCSI connection in a session without checking for the buffer length. With enough iSCSI connections it's possible to overflow the buffer provided by configfs and corrupt the memory.
This patch replaces sprintf() with sysfs_emit_at() that checks for buffer boundries.
--- drivers/target/iscsi/iscsi_target_configfs.c | 54 ++++++++++---------- 1 file changed, 27 insertions(+), 27 deletions(-)
drivers/target/iscsi/iscsi_target_configfs.c +27 -27
@@ -516,102 +516,102 @@ static ssize_t lio_target_nacl_info_show(struct config_item *item, char *page)spin_lock_bh (&se_nacl->nacl_sess_lock); se_sess = se_nacl->nacl_sess;if (!se_sess) { - rb +=sprintf (page+rb,"No active iSCSI Session for Initiator" + rb +=sysfs_emit_at (page, rb,"No active iSCSI Session for Initiator" " Endpoint: %s\n" , se_nacl->initiatorname); }else { sess = se_sess->fabric_sess_ptr; - rb +=sprintf (page+rb,"InitiatorName: %s\n" , + rb +=sysfs_emit_at (page, rb,"InitiatorName: %s\n" , sess->sess_ops->InitiatorName); - rb +=sprintf (page+rb,"InitiatorAlias: %s\n" , + rb +=sysfs_emit_at (page, rb,"InitiatorAlias: %s\n" , sess->sess_ops->InitiatorAlias); - rb +=sprintf (page+rb, + rb +=sysfs_emit_at (page, rb,"LIO Session ID: %u ISID: 0x%6ph TSIH: %hu " , sess->sid, sess->isid, sess->tsih); - rb +=sprintf (page+rb,"SessionType: %s\n" , + rb +=sysfs_emit_at (page, rb,"SessionType: %s\n" , (sess->sess_ops->SessionType) ?"Discovery" :"Normal" ); - rb +=sprintf (page+rb,"Session State: " ); + rb +=sysfs_emit_at (page, rb,"Session State: " );switch (sess->session_state) {case TARG_SESS_STATE_FREE : - rb +=sprintf (page+rb,"TARG_SESS_FREE\n" ); + rb +=sysfs_emit_at (page, rb,"TARG_SESS_FREE\n" );break ;case TARG_SESS_STATE_ACTIVE : - rb +=sprintf (page+rb,"TARG_SESS_STATE_ACTIVE\n" ); + rb +=sysfs_emit_at (page, rb,"TARG_SESS_STATE_ACTIVE\n" );break ;case TARG_SESS_STATE_LOGGED_IN : - rb +=sprintf (page+rb,"TARG_SESS_STATE_LOGGED_IN\n" ); + rb +=sysfs_emit_at (page, rb,"TARG_SESS_STATE_LOGGED_IN\n" );break ;case TARG_SESS_STATE_FAILED : - rb +=sprintf (page+rb,"TARG_SESS_STATE_FAILED\n" ); + rb +=sysfs_emit_at (page, rb,"TARG_SESS_STATE_FAILED\n" );break ;case TARG_SESS_STATE_IN_CONTINUE : - rb +=sprintf (page+rb,"TARG_SESS_STATE_IN_CONTINUE\n" ); + rb +=sysfs_emit_at (page, rb,"TARG_SESS_STATE_IN_CONTINUE\n" );break ;default : - rb +=sprintf (page+rb,"ERROR: Unknown Session" + rb +=sysfs_emit_at (page, rb,"ERROR: Unknown Session" " State!\n" );break ; } - rb +=sprintf (page+rb,"---------------------[iSCSI Session" + rb +=sysfs_emit_at (page, rb,"---------------------[iSCSI Session" " Values]-----------------------\n" ); - rb +=sprintf (page+rb," CmdSN/WR : CmdSN/WC : ExpCmdSN" + rb +=sysfs_emit_at (page, rb," CmdSN/WR : CmdSN/WC : ExpCmdSN" " : MaxCmdSN : ITT : TTT\n" ); max_cmd_sn = (u32 )atomic_read (&sess->max_cmd_sn); - rb +=sprintf (page+rb," 0x%08x 0x%08x 0x%08x 0x%08x" + rb +=sysfs_emit_at (page, rb," 0x%08x 0x%08x 0x%08x 0x%08x" " 0x%08x 0x%08x\n" , sess->cmdsn_window, (max_cmd_sn - sess->exp_cmd_sn) +1 , sess->exp_cmd_sn, max_cmd_sn, sess->init_task_tag, sess->targ_xfer_tag); - rb +=sprintf (page+rb,"----------------------[iSCSI" + rb +=sysfs_emit_at (page, rb,"----------------------[iSCSI" " Connections]-------------------------\n" );spin_lock (&sess->conn_lock);list_for_each_entry (conn, &sess->sess_conn_list, conn_list) { - rb +=sprintf (page+rb,"CID: %hu Connection" + rb +=sysfs_emit_at (page, rb,"CID: %hu Connection" " State: " , conn->cid);switch (conn->conn_state) {case TARG_CONN_STATE_FREE : - rb +=sprintf (page+rb, + rb +=sysfs_emit_at (page, rb,"TARG_CONN_STATE_FREE\n" );break ;case TARG_CONN_STATE_XPT_UP : - rb +=sprintf (page+rb, + rb +=sysfs_emit_at (page, rb,"TARG_CONN_STATE_XPT_UP\n" );break ;case TARG_CONN_STATE_IN_LOGIN : - rb +=sprintf (page+rb, + rb +=sysfs_emit_at (page, rb,"TARG_CONN_STATE_IN_LOGIN\n" );break ;case TARG_CONN_STATE_LOGGED_IN : - rb +=sprintf (page+rb, + rb +=sysfs_emit_at (page, rb,"TARG_CONN_STATE_LOGGED_IN\n" );break ;case TARG_CONN_STATE_IN_LOGOUT : - rb +=sprintf (page+rb, + rb +=sysfs_emit_at (page, rb,"TARG_CONN_STATE_IN_LOGOUT\n" );break ;case TARG_CONN_STATE_LOGOUT_REQUESTED : - rb +=sprintf (page+rb, + rb +=sysfs_emit_at (page, rb,"TARG_CONN_STATE_LOGOUT_REQUESTED\n" );break ;case TARG_CONN_STATE_CLEANUP_WAIT : - rb +=sprintf (page+rb, + rb +=sysfs_emit_at (page, rb,"TARG_CONN_STATE_CLEANUP_WAIT\n" );break ;default : - rb +=sprintf (page+rb, + rb +=sysfs_emit_at (page, rb,"ERROR: Unknown Connection State!\n" );break ; } - rb +=sprintf (page+rb," Address %pISc %s" , &conn->login_sockaddr, + rb +=sysfs_emit_at (page, rb," Address %pISc %s" , &conn->login_sockaddr, (conn->network_transport ==ISCSI_TCP ) ?"TCP" :"SCTP" ); - rb +=sprintf (page+rb," StatSN: 0x%08x\n" , + rb +=sysfs_emit_at (page, rb," StatSN: 0x%08x\n" , conn->stat_sn); }spin_unlock (&sess->conn_lock);
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 264/273 serial: cpm_uart: Avoid suspicious locking
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christophe Leroy <[email protected]>
[ Upstream commit 36ef11d311f405e55ad8e848c19b212ff71ef536 ]
CHECK drivers/tty/serial/cpm_uart/cpm_uart_core.cdrivers/tty/serial/cpm_uart/cpm_uart_core.c:1271:39: warning: context imbalance in 'cpm_uart_console_write' - unexpected unlock
Allthough 'nolock' is not expected to change, sparse find the following form suspicious:
if (unlikely(nolock)) {
local_irq_save(flags);
} else {
spin_lock_irqsave(&pinfo->port.lock, flags);
}
cpm_uart_early_write(pinfo, s, count, true);
if (unlikely(nolock)) {
local_irq_restore(flags);
} else {
spin_unlock_irqrestore(&pinfo->port.lock, flags);
}Rewrite it a more obvious form:
if (unlikely(oops_in_progress)) {
local_irq_save(flags);
cpm_uart_early_write(pinfo, s, count, true);
local_irq_restore(flags);
} else {
spin_lock_irqsave(&pinfo->port.lock, flags);
cpm_uart_early_write(pinfo, s, count, true);
spin_unlock_irqrestore(&pinfo->port.lock, flags);
}--- drivers/tty/serial/cpm_uart/cpm_uart_core.c | 13 ++++--------- 1 file changed, 4 insertions(+), 9 deletions(-)
drivers/tty/serial/cpm_uart/cpm_uart_core.c +4 -9
@@ -1269,19 +1269,14 @@ static void cpm_uart_console_write(struct console *co, const char *s, {struct uart_cpm_port *pinfo = &cpm_uart_ports[co->index];unsigned long flags; -int nolock = oops_in_progress; -if (unlikely (nolock)) { +if (unlikely (oops_in_progress)) {local_irq_save (flags); - }else { -spin_lock_irqsave (&pinfo->port.lock, flags); - } - -cpm_uart_early_write (pinfo, s, count, true); - -if (unlikely (nolock)) { +cpm_uart_early_write (pinfo, s, count, true);local_irq_restore (flags); }else { +spin_lock_irqsave (&pinfo->port.lock, flags); +cpm_uart_early_write (pinfo, s, count, true);spin_unlock_irqrestore (&pinfo->port.lock, flags); } }
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 265/273 media: pci: ipu3-cio2: Initialise timing struct to avoid a compiler warning
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Sakari Ailus <[email protected]>
[ Upstream commit 9d7531be3085a8f013cf173ccc4e72e3cf493538 ]
Initialise timing struct in cio2_hw_init() to zero in order to avoid a compiler warning. The warning was a false positive.
--- drivers/media/pci/intel/ipu3/ipu3-cio2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/media/pci/intel/ipu3/ipu3-cio2.c +1 -1
@@ -361,7 +361,7 @@ static int cio2_hw_init(struct cio2_device *cio2, struct cio2_queue *q)void __iomem *const base = cio2->base;u8 lanes, csi2bus = q->csi2.port;u8 sensor_vc =SENSOR_VIR_CH_DFLT ; -struct cio2_csi2_timing timing; +struct cio2_csi2_timing timing = {0 };int i, r; fmt =cio2_find_format (NULL , &q->subdev_fmt.code);
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 266/273 kobject: Add sanity check for kset->kobj.ktype in kset_register()
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Zhen Lei <[email protected]>
[ Upstream commit 4d0fe8c52bb3029d83e323c961221156ab98680b ]
When I register a kset in the following way:
static struct kset my_kset;
kobject_set_name(&my_kset.kobj, "my_kset");
ret = kset_register(&my_kset);A null pointer dereference exception is occurred:
[ 4453.568337] Unable to handle kernel NULL pointer dereference at \ virtual address 0000000000000028 ... ... [ 4453.810361] Call trace: [ 4453.813062] kobject_get_ownership+0xc/0x34 [ 4453.817493] kobject_add_internal+0x98/0x274 [ 4453.822005] kset_register+0x5c/0xb4 [ 4453.825820] my_kobj_init+0x44/0x1000 [my_kset]
... ...
Because I didn't initialize my_kset.kobj.ktype.
According to the description in Documentation/core-api/kobject.rst:
- A ktype is the type of object that embeds a kobject. Every structure that embeds a kobject needs a corresponding ktype.
So add sanity check to make sure kset->kobj.ktype is not NULL.
--- lib/kobject.c | 5 +++++ 1 file changed, 5 insertions(+)
lib/kobject.c +5 -0
@@ -829,6 +829,11 @@ int kset_register(struct kset *k)if (!k)return -EINVAL ; +if (!k->kobj.ktype) { +pr_err ("must have a ktype to be initialized properly!\n" ); +return -EINVAL ; + } +kset_init (k); err =kobject_add_internal (&k->kobj);if (err)
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 267/273 md/raid1: fix error: ISO C90 forbids mixed declarations
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nigel Croxon <[email protected]>
[ Upstream commit df203da47f4428bc286fc99318936416253a321c ]
There is a compile error when this commit is added:
md: raid1: fix potential OOB in raid1_remove_disk()
drivers/md/raid1.c: In function 'raid1_remove_disk':drivers/md/raid1.c:1844:9: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
1844 | struct raid1_info *p = conf->mirrors + number;
| ^~~~~~
That's because the new code was inserted before the struct. The change is move the struct command above this commit.
--- drivers/md/raid1.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
drivers/md/raid1.c +1 -2
@@ -1783,12 +1783,11 @@ static int raid1_remove_disk(struct mddev *mddev, struct md_rdev *rdev)struct r1conf *conf = mddev->private;int err =0 ;int number = rdev->raid_disk; +struct raid1_info *p = conf->mirrors + number;if (unlikely (number >= conf->raid_disks)) goto abort; -struct raid1_info *p = conf->mirrors + number; -if (rdev != p->rdev) p = conf->mirrors + conf->raid_disks + number;
Signature · 1 line
2.40.1
Greg Kroah-Hartman
maintainerPATCH 268/273 attr: block mode changes of symlinks
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Christian Brauner <[email protected]>
commit 5d1f903f75a80daa4dfb3d84e114ec8ecbf29956 upstream.
Changing the mode of symlinks is meaningless as the vfs doesn't take the mode of a symlink into account during path lookup permission checking.
However, the vfs doesn't block mode changes on symlinks. This however, has lead to an untenable mess roughly classifiable into the following two categories:
(1) Filesystems that don't implement a i_op->setattr() for symlinks.
Such filesystems may or may not know that without i_op->setattr() defined, notify_change() falls back to simple_setattr() causing the inode's mode in the inode cache to be changed.
That's a generic issue as this will affect all non-size changing inode attributes including ownership changes.
Example: afs
(2) Filesystems that fail with EOPNOTSUPP but change the mode of the symlink nonetheless.
Some filesystems will happily update the mode of a symlink but still return EOPNOTSUPP. This is the biggest source of confusion for userspace.
The EOPNOTSUPP in this case comes from POSIX ACLs. Specifically it comes from filesystems that call posix_acl_chmod(), e.g., btrfs via
if (!err && attr->ia_valid & ATTR_MODE)
err = posix_acl_chmod(idmap, dentry, inode->i_mode);
Filesystems including btrfs don't implement i_op->set_acl() so posix_acl_chmod() will report EOPNOTSUPP.
When posix_acl_chmod() is called, most filesystems will have finished updating the inode.
Perversely, this has the consequences that this behavior may depend on two kconfig options and mount options:
* CONFIG_POSIX_ACL={y,n}
* CONFIG_${FSTYPE}_POSIX_ACL={y,n}
* Opt_acl, Opt_noacl
Example: btrfs, ext4, xfs
The only way to change the mode on a symlink currently involves abusing an O_PATH file descriptor in the following manner:
fd = openat(-1, "/path/to/link", O_CLOEXEC | O_PATH | O_NOFOLLOW);
char path[PATH_MAX];
snprintf(path, sizeof(path), "/proc/self/fd/%d", fd);
chmod(path, 0000);But for most major filesystems with POSIX ACL support such as btrfs, ext4, ceph, tmpfs, xfs and others this will fail with EOPNOTSUPP with the mode still updated due to the aforementioned posix_acl_chmod() nonsense.
So, given that for all major filesystems this would fail with EOPNOTSUPP and that both glibc (cf. [1]) and musl (cf. [2]) outright block mode changes on symlinks we should just try and block mode changes on symlinks directly in the vfs and have a clean break with this nonsense.
If this causes any regressions, we do the next best thing and fix up all filesystems that do return EOPNOTSUPP with the mode updated to not call posix_acl_chmod() on symlinks.
But as usual, let's try the clean cut solution first. It's a simple patch that can be easily reverted. Not marking this for backport as I'll do that manually if we're reasonably sure that this works and there are no strong objections.
We could block this in chmod_common() but it's more appropriate to do it notify_change() as it will also mean that we catch filesystems that change symlink permissions explicitly or accidently.
Similar proposals were floated in the past as in [3] and [4] and again recently in [5]. There's also a couple of bugs about this inconsistency as in [6] and [7].
Message-Id: <[email protected]>
--- fs/attr.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-)
fs/attr.c +18 -2
@@ -256,9 +256,25 @@ int notify_change(struct dentry * dentry }if ((ia_valid &ATTR_MODE )) { -umode_t amode = attr->ia_mode; +/* +* Don't allow changing the mode of symlinks: +* +* (1) The vfs doesn't take the mode of symlinks into account +* during permission checking. +* (2) This has never worked correctly. Most major filesystems +* did return EOPNOTSUPP due to interactions with POSIX ACLs +* but did still updated the mode of the symlink. +* This inconsistency led system call wrapper providers such +* as libc to block changing the mode of symlinks with +* EOPNOTSUPP already. +* (3) To even do this in the first place one would have to use +* specific file descriptors and quite some effort. +*/ +if (S_ISLNK (inode->i_mode)) +return -EOPNOTSUPP ; +/* Flag setting protected by i_mutex */ -if (is_sxid (amode)) +if (is_sxid (attr->ia_mode)) inode->i_flags &= ~S_NOSEC ; }
Greg Kroah-Hartman
maintainerPATCH 269/273 btrfs: fix lockdep splat and potential deadlock after failure running delayed items
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Filipe Manana <[email protected]>
commit e110f8911ddb93e6f55da14ccbbe705397b30d0b upstream.
When running delayed items we are holding a delayed node's mutex and then we will attempt to modify a subvolume btree to insert/update/delete the delayed items. However if have an error during the insertions for example, btrfs_insert_delayed_items() may return with a path that has locked extent buffers (a leaf at the very least), and then we attempt to release the delayed node at __btrfs_run_delayed_items(), which requires taking the delayed node's mutex, causing an ABBA type of deadlock. This was reported by syzbot and the lockdep splat is the following:
WARNING: possible circular locking dependency detected
6.5.0-rc7-syzkaller-00024-g93f5de5f648d #0 Not tainted
------------------------------------------------------
syz-executor.2/13257 is trying to acquire lock:
ffff88801835c0c0 (&delayed_node->mutex){+.+.}-{3:3}, at: __btrfs_release_delayed_node+0x9a/0xaa0 fs/btrfs/delayed-inode.c:256
but task is already holding lock:
ffff88802a5ab8e8 (btrfs-tree-00){++++}-{3:3}, at: __btrfs_tree_lock+0x3c/0x2a0 fs/btrfs/locking.c:198
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (btrfs-tree-00){++++}-{3:3}:
__lock_release kernel/locking/lockdep.c:5475 [inline]
lock_release+0x36f/0x9d0 kernel/locking/lockdep.c:5781
up_write+0x79/0x580 kernel/locking/rwsem.c:1625
btrfs_tree_unlock_rw fs/btrfs/locking.h:189 [inline]
btrfs_unlock_up_safe+0x179/0x3b0 fs/btrfs/locking.c:239
search_leaf fs/btrfs/ctree.c:1986 [inline]
btrfs_search_slot+0x2511/0x2f80 fs/btrfs/ctree.c:2230
btrfs_insert_empty_items+0x9c/0x180 fs/btrfs/ctree.c:4376
btrfs_insert_delayed_item fs/btrfs/delayed-inode.c:746 [inline]
btrfs_insert_delayed_items fs/btrfs/delayed-inode.c:824 [inline]
__btrfs_commit_inode_delayed_items+0xd24/0x2410 fs/btrfs/delayed-inode.c:1111
__btrfs_run_delayed_items+0x1db/0x430 fs/btrfs/delayed-inode.c:1153
flush_space+0x269/0xe70 fs/btrfs/space-info.c:723
btrfs_async_reclaim_metadata_space+0x106/0x350 fs/btrfs/space-info.c:1078
process_one_work+0x92c/0x12c0 kernel/workqueue.c:2600
worker_thread+0xa63/0x1210 kernel/workqueue.c:2751
kthread+0x2b8/0x350 kernel/kthread.c:389
ret_from_fork+0x2e/0x60 arch/x86/kernel/process.c:145
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304-> #0 (&delayed_node->mutex){+.+.}-{3:3}:
check_prev_add kernel/locking/lockdep.c:3142 [inline]
check_prevs_add kernel/locking/lockdep.c:3261 [inline]
validate_chain kernel/locking/lockdep.c:3876 [inline]
__lock_acquire+0x39ff/0x7f70 kernel/locking/lockdep.c:5144
lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5761
__mutex_lock_common+0x1d8/0x2530 kernel/locking/mutex.c:603
__mutex_lock kernel/locking/mutex.c:747 [inline]
mutex_lock_nested+0x1b/0x20 kernel/locking/mutex.c:799
__btrfs_release_delayed_node+0x9a/0xaa0 fs/btrfs/delayed-inode.c:256
btrfs_release_delayed_node fs/btrfs/delayed-inode.c:281 [inline]
__btrfs_run_delayed_items+0x2b5/0x430 fs/btrfs/delayed-inode.c:1156
btrfs_commit_transaction+0x859/0x2ff0 fs/btrfs/transaction.c:2276
btrfs_sync_file+0xf56/0x1330 fs/btrfs/file.c:1988
vfs_fsync_range fs/sync.c:188 [inline]
vfs_fsync fs/sync.c:202 [inline]
do_fsync fs/sync.c:212 [inline]
__do_sys_fsync fs/sync.c:220 [inline]
__se_sys_fsync fs/sync.c:218 [inline]
__x64_sys_fsync+0x196/0x1e0 fs/sync.c:218
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/0xcdother info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(btrfs-tree-00);
lock(&delayed_node->mutex);
lock(btrfs-tree-00);
lock(&delayed_node->mutex);*** DEADLOCK ***
3 locks held by syz-executor.2/13257:
#0: ffff88802c1ee370 (btrfs_trans_num_writers){++++}-{0:0}, at: spin_unlock include/linux/spinlock.h:391 [inline] #0: ffff88802c1ee370 (btrfs_trans_num_writers){++++}-{0:0}, at: join_transaction+0xb87/0xe00 fs/btrfs/transaction.c:287 #1: ffff88802c1ee398 (btrfs_trans_num_extwriters){++++}-{0:0}, at: join_transaction+0xbb2/0xe00 fs/btrfs/transaction.c:288 #2: ffff88802a5ab8e8 (btrfs-tree-00){++++}-{3:3}, at: __btrfs_tree_lock+0x3c/0x2a0 fs/btrfs/locking.c:198
stack backtrace: CPU: 0 PID: 13257 Comm: syz-executor.2 Not tainted 6.5.0-rc7-syzkaller-00024-g93f5de5f648d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106 check_noncircular+0x375/0x4a0 kernel/locking/lockdep.c:2195 check_prev_add kernel/locking/lockdep.c:3142 [inline] check_prevs_add kernel/locking/lockdep.c:3261 [inline] validate_chain kernel/locking/lockdep.c:3876 [inline] __lock_acquire+0x39ff/0x7f70 kernel/locking/lockdep.c:5144 lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5761 __mutex_lock_common+0x1d8/0x2530 kernel/locking/mutex.c:603 __mutex_lock kernel/locking/mutex.c:747 [inline] mutex_lock_nested+0x1b/0x20 kernel/locking/mutex.c:799 __btrfs_release_delayed_node+0x9a/0xaa0 fs/btrfs/delayed-inode.c:256 btrfs_release_delayed_node fs/btrfs/delayed-inode.c:281 [inline] __btrfs_run_delayed_items+0x2b5/0x430 fs/btrfs/delayed-inode.c:1156 btrfs_commit_transaction+0x859/0x2ff0 fs/btrfs/transaction.c:2276 btrfs_sync_file+0xf56/0x1330 fs/btrfs/file.c:1988 vfs_fsync_range fs/sync.c:188 [inline] vfs_fsync fs/sync.c:202 [inline] do_fsync fs/sync.c:212 [inline] __do_sys_fsync fs/sync.c:220 [inline] __se_sys_fsync fs/sync.c:218 [inline] __x64_sys_fsync+0x196/0x1e0 fs/sync.c:218 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 RIP: 0033:0x7f3ad047cae9 Code: 28 00 00 00 75 (...) RSP: 002b:00007f3ad12510c8 EFLAGS: 00000246 ORIG_RAX: 000000000000004a RAX: ffffffffffffffda RBX: 00007f3ad059bf80 RCX: 00007f3ad047cae9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000005 RBP: 00007f3ad04c847a R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007f3ad059bf80 R15: 00007ffe56af92f8 </TASK> ------------[ cut here ]------------
Fix this by releasing the path before releasing the delayed node in the error path at __btrfs_run_delayed_items().
--- fs/btrfs/delayed-inode.c | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-)
fs/btrfs/delayed-inode.c +16 -3
@@ -1171,20 +1171,33 @@ static int __btrfs_run_delayed_items(str ret =__btrfs_commit_inode_delayed_items (trans, path, curr_node);if (ret) { -btrfs_release_delayed_node (curr_node); - curr_node =NULL ;btrfs_abort_transaction (trans, ret);break ; } prev_node = curr_node; curr_node =btrfs_next_delayed_node (curr_node); +/* +* See the comment below about releasing path before releasing +* node. If the commit of delayed items was successful the path +* should always be released, but in case of an error, it may +* point to locked extent buffers (a leaf at the very least). +*/ +ASSERT (path->nodes[0 ] ==NULL );btrfs_release_delayed_node (prev_node); } +/* +* Release the path to avoid a potential deadlock and lockdep splat when +* releasing the delayed node, as that requires taking the delayed node's +* mutex. If another task starts running delayed items before we take +* the mutex, it will first lock the mutex and then it may try to lock +* the same btree path (leaf). +*/ +btrfs_free_path (path); +if (curr_node)btrfs_release_delayed_node (curr_node); -btrfs_free_path (path); trans->block_rsv = block_rsv;return ret;
Greg Kroah-Hartman
maintainerPATCH 270/273 nfsd: fix change_info in NFSv4 RENAME replies
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jeff Layton <[email protected]>
commit fdd2630a7398191e84822612e589062063bd4f3d upstream.
nfsd sends the transposed directory change info in the RENAME reply. The source directory is in save_fh and the target is in current_fh.
--- fs/nfsd/nfs4proc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
fs/nfsd/nfs4proc.c +2 -2
@@ -870,8 +870,8 @@ nfsd4_rename(struct svc_rqst *rqstp, str rename->rn_tname, rename->rn_tnamelen);if (status)return status; -set_change_info (&rename->rn_sinfo, &cstate->current_fh); -set_change_info (&rename->rn_tinfo, &cstate->save_fh); +set_change_info (&rename->rn_sinfo, &cstate->save_fh); +set_change_info (&rename->rn_tinfo, &cstate->current_fh);return nfs_ok; }
Greg Kroah-Hartman
maintainerPATCH 271/273 mtd: rawnand: brcmnand: Fix ECC level field setting for v7.2 controller
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: William Zhang <[email protected]>
commit 2ec2839a9062db8a592525a3fdabd42dcd9a3a9b upstream.
v7.2 controller has different ECC level field size and shift in the acc control register than its predecessor and successor controller. It needs to be set specifically.
--- drivers/mtd/nand/raw/brcmnand/brcmnand.c | 75 +++++++++++++++++-------------- 1 file changed, 42 insertions(+), 33 deletions(-)
drivers/mtd/nand/raw/brcmnand/brcmnand.c +42 -33
@@ -152,6 +152,7 @@ struct brcmnand_controller {unsigned int max_page_size;const unsigned int *page_sizes;unsigned int max_oob; +u32 ecc_level_shift;u32 features;/* for low-power standby/resume only */
@@ -441,6 +442,34 @@ enum { INTFC_CTLR_READY = BIT(31), }; +/*********************************************************************** +* NAND ACC CONTROL bitfield +* +* Some bits have remained constant throughout hardware revision, while +* others have shifted around. +***********************************************************************/ + +/* Constant for all versions (where supported) */ +enum { +/* See BRCMNAND_HAS_CACHE_MODE */ +ACC_CONTROL_CACHE_MODE =BIT (22 ), + +/* See BRCMNAND_HAS_PREFETCH */ +ACC_CONTROL_PREFETCH =BIT (23 ), + +ACC_CONTROL_PAGE_HIT =BIT (24 ), +ACC_CONTROL_WR_PREEMPT =BIT (25 ), +ACC_CONTROL_PARTIAL_PAGE =BIT (26 ), +ACC_CONTROL_RD_ERASED =BIT (27 ), +ACC_CONTROL_FAST_PGM_RDIN =BIT (28 ), +ACC_CONTROL_WR_ECC =BIT (30 ), +ACC_CONTROL_RD_ECC =BIT (31 ), +}; + +#define ACC_CONTROL_ECC_SHIFT 16 +/* Only for v7.2 */ +#define ACC_CONTROL_ECC_EXT_SHIFT 13 +static inline u32 nand_readreg (struct brcmnand_controller *ctrl,u32 offs) {return brcmnand_readl (ctrl->nand_base + offs);
@@ -544,6 +573,12 @@ static int brcmnand_revision_init(structelse if (of_property_read_bool (ctrl->dev->of_node,"brcm,nand-has-wp" )) ctrl->features |=BRCMNAND_HAS_WP ; +/* v7.2 has different ecc level shift in the acc register */ +if (ctrl->nand_version ==0x0702 ) + ctrl->ecc_level_shift =ACC_CONTROL_ECC_EXT_SHIFT ; +else + ctrl->ecc_level_shift =ACC_CONTROL_ECC_SHIFT ; +return 0 ; }
@@ -697,30 +732,6 @@ static inline int brcmnand_cmd_shift(strreturn 0 ; } -/*********************************************************************** -* NAND ACC CONTROL bitfield -* -* Some bits have remained constant throughout hardware revision, while -* others have shifted around. -***********************************************************************/ - -/* Constant for all versions (where supported) */ -enum { -/* See BRCMNAND_HAS_CACHE_MODE */ -ACC_CONTROL_CACHE_MODE =BIT (22 ), - -/* See BRCMNAND_HAS_PREFETCH */ -ACC_CONTROL_PREFETCH =BIT (23 ), - -ACC_CONTROL_PAGE_HIT =BIT (24 ), -ACC_CONTROL_WR_PREEMPT =BIT (25 ), -ACC_CONTROL_PARTIAL_PAGE =BIT (26 ), -ACC_CONTROL_RD_ERASED =BIT (27 ), -ACC_CONTROL_FAST_PGM_RDIN =BIT (28 ), -ACC_CONTROL_WR_ECC =BIT (30 ), -ACC_CONTROL_RD_ECC =BIT (31 ), -}; -static inline u32 brcmnand_spare_area_mask (struct brcmnand_controller *ctrl) {if (ctrl->nand_version >=0x0702 )
@@ -731,18 +742,15 @@ static inline u32 brcmnand_spare_area_mareturn GENMASK (5 ,0 ); } -#define NAND_ACC_CONTROL_ECC_SHIFT 16 -#define NAND_ACC_CONTROL_ECC_EXT_SHIFT 13 -static inline u32 brcmnand_ecc_level_mask (struct brcmnand_controller *ctrl) {u32 mask = (ctrl->nand_version >=0x0600 ) ?0x1f :0x0f ; - mask <<=NAND_ACC_CONTROL_ECC_SHIFT ; + mask <<=ACC_CONTROL_ECC_SHIFT ;/* v7.2 includes additional ECC levels */ -if (ctrl->nand_version >=0x0702 ) - mask |=0x7 <<NAND_ACC_CONTROL_ECC_EXT_SHIFT ; +if (ctrl->nand_version ==0x0702 ) + mask |=0x7 <<ACC_CONTROL_ECC_EXT_SHIFT ;return mask; }
@@ -756,8 +764,8 @@ static void brcmnand_set_ecc_enabled(strif (en) { acc_control |= ecc_flags;/* enable RD/WR ECC */ - acc_control |= host->hwcfg.ecc_level - <<NAND_ACC_CONTROL_ECC_SHIFT ; + acc_control &= ~brcmnand_ecc_level_mask (ctrl); + acc_control |= host->hwcfg.ecc_level << ctrl->ecc_level_shift; }else { acc_control &= ~ecc_flags;/* disable RD/WR ECC */ acc_control &= ~brcmnand_ecc_level_mask (ctrl);
@@ -2103,9 +2111,10 @@ static int brcmnand_set_cfg(struct brcmn tmp =nand_readreg (ctrl, acc_control_offs); tmp &= ~brcmnand_ecc_level_mask (ctrl); - tmp |= cfg->ecc_level <<NAND_ACC_CONTROL_ECC_SHIFT ; + tmp |= cfg->ecc_level << ctrl->ecc_level_shift; tmp &= ~brcmnand_spare_area_mask (ctrl); tmp |= cfg->spare_area_size; +nand_writereg (ctrl, acc_control_offs, tmp);brcmnand_set_sector_size_1k (host, cfg->sector_size_1k);
Greg Kroah-Hartman
maintainerPATCH 272/273 net/sched: cls_fw: No longer copy tcf_result on update to avoid use-after-free
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: valis <[email protected]>
commit 76e42ae831991c828cffa8c37736ebfb831ad5ec upstream.
When fw_change() is called on an existing filter, the whole tcf_result struct is always copied into the new instance of the filter.
This causes a problem when updating a filter bound to a class, as tcf_unbind_filter() is always called on the old instance in the success path, decreasing filter_cnt of the still referenced class and allowing it to be deleted, leading to a use-after-free.
Fix this by no longer copying the tcf_result struct from the old filter.
[ Fixed small conflict as 'fnew->ifindex' assignment is not protected by
CONFIG_NET_CLS_IND on upstream since a51486266c3 ]
--- net/sched/cls_fw.c | 1 - 1 file changed, 1 deletion(-)
net/sched/cls_fw.c +0 -1
@@ -277,7 +277,6 @@ static int fw_change(struct net *net, streturn -ENOBUFS ; fnew->id = f->id; - fnew->res = f->res;#ifdef CONFIG_NET_CLS_IND fnew->ifindex = f->ifindex;#endif /* CONFIG_NET_CLS_IND */
Greg Kroah-Hartman
maintainerPATCH 273/273 net/sched: Retire rsvp classifier
In reply to Greg Kroah-Hartman4.19-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jamal Hadi Salim <[email protected]>
commit 265b4da82dbf5df04bee5a5d46b7474b1aaf326a upstream.
The rsvp classifier has served us well for about a quarter of a century but has has not been getting much maintenance attention due to lack of known users.
--- net/sched/Kconfig | 28 - net/sched/Makefile | 2 net/sched/cls_rsvp.c | 28 - net/sched/cls_rsvp.h | 775 -------------------------------------------------- net/sched/cls_rsvp6.c | 28 - 5 files changed, 861 deletions(-)
net/sched/Kconfig +0 -28
@@ -503,34 +503,6 @@ config CLS_U32_MARK ---help--- Say Y here to be able to use netfilter marks as u32 key. -config NET_CLS_RSVP - tristate "IPv4 Resource Reservation Protocol (RSVP)" - select NET_CLS - ---help--- - The Resource Reservation Protocol (RSVP) permits end systems to - request a minimum and maximum data flow rate for a connection; this - is important for real time data such as streaming sound or video. - - Say Y here if you want to be able to classify outgoing packets based - on their RSVP requests. - - To compile this code as a module, choose M here: the - module will be called cls_rsvp. - -config NET_CLS_RSVP6 - tristate "IPv6 Resource Reservation Protocol (RSVP6)" - select NET_CLS - ---help--- - The Resource Reservation Protocol (RSVP) permits end systems to - request a minimum and maximum data flow rate for a connection; this - is important for real time data such as streaming sound or video. - - Say Y here if you want to be able to classify outgoing packets based - on their RSVP requests and you are using the IPv6 protocol. - - To compile this code as a module, choose M here: the - module will be called cls_rsvp6. - config NET_CLS_FLOW tristate "Flow classifier" select NET_CLS
net/sched/Makefile +0 -2
@@ -61,8 +61,6 @@ obj-$(CONFIG_NET_SCH_ETF) += sch_etf.o obj-$(CONFIG_NET_CLS_U32) += cls_u32.o obj-$(CONFIG_NET_CLS_ROUTE4) += cls_route.o obj-$(CONFIG_NET_CLS_FW) += cls_fw.o -obj-$(CONFIG_NET_CLS_RSVP) += cls_rsvp.o -obj-$(CONFIG_NET_CLS_RSVP6) += cls_rsvp6.o obj-$(CONFIG_NET_CLS_BASIC) += cls_basic.o obj-$(CONFIG_NET_CLS_FLOW) += cls_flow.o obj-$(CONFIG_NET_CLS_CGROUP) += cls_cgroup.o
net/sched/cls_rsvp.c deleted +0 -28
@@ -1,28 +0,0 @@ -/* -* net/sched/cls_rsvp.c Special RSVP packet classifier for IPv4. -* -* This program is free software; you can redistribute it and/or -* modify it under the terms of the GNU General Public License -* as published by the Free Software Foundation; either version -* 2 of the License, or (at your option) any later version. -* -* Authors: Alexey Kuznetsov, <[email protected]> -*/ - -#include <linux/module.h> -#include <linux/types.h> -#include <linux/kernel.h> -#include <linux/string.h> -#include <linux/errno.h> -#include <linux/skbuff.h> -#include <net/ip.h> -#include <net/netlink.h> -#include <net/act_api.h> -#include <net/pkt_cls.h> - -#define RSVP_DST_LEN 1 -#define RSVP_ID "rsvp" -#define RSVP_OPS cls_rsvp_ops - -#include "cls_rsvp.h" -MODULE_LICENSE ("GPL" );
net/sched/cls_rsvp.h deleted +0 -775
775 lines not on this page · raw message
net/sched/cls_rsvp6.c deleted +0 -28
@@ -1,28 +0,0 @@ -/* -* net/sched/cls_rsvp6.c Special RSVP packet classifier for IPv6. -* -* This program is free software; you can redistribute it and/or -* modify it under the terms of the GNU General Public License -* as published by the Free Software Foundation; either version -* 2 of the License, or (at your option) any later version. -* -* Authors: Alexey Kuznetsov, <[email protected]> -*/ - -#include <linux/module.h> -#include <linux/types.h> -#include <linux/kernel.h> -#include <linux/string.h> -#include <linux/errno.h> -#include <linux/ipv6.h> -#include <linux/skbuff.h> -#include <net/act_api.h> -#include <net/pkt_cls.h> -#include <net/netlink.h> - -#define RSVP_DST_LEN 4 -#define RSVP_ID "rsvp6" -#define RSVP_OPS cls_rsvp6_ops - -#include "cls_rsvp.h" -MODULE_LICENSE ("GPL" );
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.19.295 release. There are 273 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, 22 Sep 2023 11:28:09 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at:
Quoted 9 lines
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.295-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.19.y
and the diffstat can be found below.thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
thanks,
-- Shuah
Quoted 10 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.19.295 release. There are 273 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, 22 Sep 2023 11:28:09 +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/v4.x/stable-review/patch-4.19.295-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.19.y
and the diffstat can be found below.thanks,
greg k-h
Following arm build regressions noticed on 4.19 kernel.
* arm, build
- clang-17-imx_v6_v7_defconfig
- gcc-12-imx_v6_v7_defconfig
- gcc-8-imx_v6_v7_defconfig
Logs:
------drivers/pci/controller/dwc/pci-imx6.c:645:10: error: 'const struct dw_pcie_host_ops' has no member named 'host_deinit'; did you mean 'host_init'?
645 | .host_deinit = imx6_pcie_host_exit,
| ^~~~~~~~~~~
| host_init
drivers/pci/controller/dwc/pci-imx6.c:645:24: error:
'imx6_pcie_host_exit' undeclared here (not in a function); did you
mean 'imx6_pcie_host_init'?
645 | .host_deinit = imx6_pcie_host_exit,
| ^~~~~~~~~~~~~~~~~~~
| imx6_pcie_host_initLinks:
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.19.y/build/v4.19.294-274-gb67b483f6a45/testrun/20075618/suite/build/test/gcc-12-imx_v6_v7_defconfig/history/
- https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.19.y/build/v4.19.294-274-gb67b483f6a45/testrun/20075618/suite/build/test/gcc-12-imx_v6_v7_defconfig/log
## Build
* kernel: 4.19.295-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-4.19.y
* git commit: b67b483f6a4512bad5b589f3bf49503cfe941cf9
* git describe: v4.19.294-274-gb67b483f6a45
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.19.y/build/v4.19.294-274-gb67b483f6a45
## Test Regressions (compared to v4.19.294-235-gf91592b50ab2)
* arm, build
- clang-17-imx_v6_v7_defconfig
- gcc-12-imx_v6_v7_defconfig
- gcc-8-imx_v6_v7_defconfig
## Metric Regressions (compared to v4.19.294-235-gf91592b50ab2)
## Test Fixes (compared to v4.19.294-235-gf91592b50ab2)
## Metric Fixes (compared to v4.19.294-235-gf91592b50ab2)
## Test result summary
total: 52194, pass: 44599, fail: 1323, skip: 6238, xfail: 34
## Build Summary
* arc: 10 total, 10 passed, 0 failed
* arm: 111 total, 102 passed, 9 failed
* arm64: 37 total, 32 passed, 5 failed
* i386: 21 total, 18 passed, 3 failed
* mips: 21 total, 21 passed, 0 failed
* parisc: 3 total, 0 passed, 3 failed
* powerpc: 24 total, 24 passed, 0 failed
* s390: 6 total, 6 passed, 0 failed
* sh: 12 total, 12 passed, 0 failed
* sparc: 6 total, 6 passed, 0 failed
* x86_64: 30 total, 25 passed, 5 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-filesystems
* kselftest-filesystems-binderfs
* kselftest-filesystems-epoll
* kselftest-firmware
* kselftest-fpu
* kselftest-ftrace
* kselftest-futex
* kselftest-gpio
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* 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-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-user
* kselftest-vm
* kselftest-zram
* kunit
* log-parser-boot
* log-parser-test
* ltp-cap_bounds
* ltp-commands
* ltp-containers
* ltp-controllers
* ltp-crypto
* ltp-cve
* 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
* rcutorture
--
Linaro LKFT
https://lkft.linaro.org
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.19.295 release. There are 273 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, 22 Sep 2023 11:28:09 +0000. Anything received after that time might be too late.
Building arm:allmodconfig ... failed
Building arm:imx_v6_v7_defconfig ... failed
drivers/pci/controller/dwc/pci-imx6.c:645:10: error: 'const struct dw_pcie_host_ops' has no member named 'host_deinit'; did you mean 'host_init'?
645 | .host_deinit = imx6_pcie_host_exit,
| ^~~~~~~~~~~
| host_init
drivers/pci/controller/dwc/pci-imx6.c:645:24: error: 'imx6_pcie_host_exit' undeclared here (not in a function); did you mean 'imx6_pcie_host_init'?
645 | .host_deinit = imx6_pcie_host_exit,
| ^~~~~~~~~~~~~~~~~~~
| imx6_pcie_host_initGuenter
Greg Kroah-Hartman
maintainerQuoted 13 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.19.295 release. There are 273 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, 22 Sep 2023 11:28:09 +0000. Anything received after that time might be too late.
Building arm:allmodconfig ... failed
Building arm:imx_v6_v7_defconfig ... failed
Quoted 9 lines
drivers/pci/controller/dwc/pci-imx6.c:645:10: error: 'const structdw_pcie_host_ops' has no member named 'host_deinit'; did you mean 'host_init'?645 | .host_deinit = imx6_pcie_host_exit, | ^~~~~~~~~~~ | host_init drivers/pci/controller/dwc/pci-imx6.c:645:24: error: 'imx6_pcie_host_exit' undeclared here (not in a function); did you mean 'imx6_pcie_host_init'? 645 | .host_deinit = imx6_pcie_host_exit, | ^~~~~~~~~~~~~~~~~~~ | imx6_pcie_host_init
Offending patch now dropped, thanks.
greg k-h
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.19.295 release. There are 273 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, 22 Sep 2023 11:28:09 +0000. Anything received after that time might be too late.
Build results:
total: 149 pass: 147 fail: 2 Failed builds: arm:allmodconfig arm:imx_v6_v7_defconfig Qemu test results: total: 441 pass: 434 fail: 7 Failed tests: arm:mcimx6ul-evk:imx_v6_v7_defconfig:nodrm:mem256:net=nic:net=nic:imx6ul-14x14-evk:initrd arm:mcimx6ul-evk:imx_v6_v7_defconfig:nodrm:sd:mem256:net=nic:net=nic:imx6ul-14x14-evk:ext2 arm:mcimx6ul-evk:imx_v6_v7_defconfig:nodrm:usb0:mem256:net=nic:net=nic:imx6ul-14x14-evk:ext2 arm:mcimx6ul-evk:imx_v6_v7_defconfig:nodrm:usb1:mem256:net=nic:net=nic:imx6ul-14x14-evk:ext2 arm:mcimx7d-sabre:imx_v6_v7_defconfig:nodrm:mem256:net=nic:imx7d-sdb:initrd arm:mcimx7d-sabre:imx_v6_v7_defconfig:nodrm:usb1:mem256:net=nic:imx7d-sdb:ext2 arm:mcimx7d-sabre:imx_v6_v7_defconfig:nodrm:sd:mem256:net=nic:imx7d-sdb:ext2
drivers/pci/controller/dwc/pci-imx6.c:645:10: error: 'const struct dw_pcie_host_ops' has no member named 'host_deinit' drivers/pci/controller/dwc/pci-imx6.c:645:24: error: 'imx6_pcie_host_exit' undeclared here
Guenter
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.19.295 release. There are 273 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, 22 Sep 2023 11:28:09 +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/v4.x/stable-review/patch-4.19.295-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.19.y
and the diffstat can be found below.thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v4.19:
11 builds: 11 pass, 0 fail
22 boots: 22 pass, 0 fail
40 tests: 40 pass, 0 failLinux version: 4.19.295-rc1-gb67b483f6a45
Boards tested: tegra124-jetson-tk1, tegra186-p2771-0000,
tegra194-p2972-0000, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04Jon