4.14.60-stable review
Subsystems (11)
Greg Kroah-Hartman
maintainerPATCH 194/246 staging: lustre: llite: correct removexattr detection
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: James Simmons <[email protected]>
[ Upstream commit 1b60f6dfa38403ff7c4d0b4b7ecdb810f9789a2a ]
In ll_xattr_set_common() detect the removexattr() case correctly by testing for a NULL value as well as XATTR_REPLACE.
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-10787
Reviewed-on: https://review.whamcloud.com/
--- drivers/staging/lustre/lustre/llite/xattr.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/staging/lustre/lustre/llite/xattr.c +5 -1
@@ -93,7 +93,11 @@ ll_xattr_set_common(const struct xattr_h__u64 valid;int rc; -if (flags ==XATTR_REPLACE ) { +/* When setxattr() is called with a size of 0 the value is +* unconditionally replaced by "". When removexattr() is +* called we get a NULL value and XATTR_REPLACE for flags. +*/ +if (!value && flags ==XATTR_REPLACE ) {ll_stats_ops_tally (ll_i2sbi (inode),LPROC_LL_REMOVEXATTR ,1 ); valid =OBD_MD_FLXATTRRM ; }else {
Greg Kroah-Hartman
maintainerPATCH 195/246 staging: lustre: ldlm: free resource when ldlm_lock_create() fails.
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: NeilBrown <[email protected]>
[ Upstream commit d8caf662b4aeeb2ac83ac0b22e40db88e9360c77 ]
ldlm_lock_create() gets a resource, but don't put it on all failure paths. It should.
--- drivers/staging/lustre/lustre/ldlm/ldlm_lock.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
drivers/staging/lustre/lustre/ldlm/ldlm_lock.c +5 -1
@@ -1571,8 +1571,10 @@ struct ldlm_lock *ldlm_lock_create(strucreturn ERR_CAST (res); lock =ldlm_lock_new (res); -if (!lock) +if (!lock) { +ldlm_resource_putref (res);return ERR_PTR (-ENOMEM ); + } lock->l_req_mode = mode; lock->l_ast_data = data;
@@ -1615,6 +1617,8 @@ out:return ERR_PTR (rc); } + +/** * Enqueue (request) a lock. * On the client this is called from ldlm_cli_enqueue_fini
Greg Kroah-Hartman
maintainerPATCH 196/246 serial: core: Make sure compiler barfs for 16-byte earlycon names
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Douglas Anderson <[email protected]>
[ Upstream commit c1c734cb1f54b062f7e67ffc9656d82f5b412b9c ]
As part of bringup I ended up wanting to call an earlycon driver by a name that was exactly 16-bytes big, specifically "qcom_geni_serial".
Unfortunately, when I tried this I found that things compiled just fine. They just didn't work.
Specifically the compiler felt perfectly justified in initting the ".name" field of "struct earlycon_id" with the full 16-bytes and just skipping the '\0'. Needless to say, that behavior didn't seem ideal, but I guess someone must have allowed it for a reason.
One way to fix this is to shorten the name field to 15 bytes and then add an extra byte after that nobody touches. This should always be initted to 0 and we're golden.
There are, of course, other ways to fix this too. We could audit all the users of the "name" field and make them stop at both null termination or at 16 bytes. We could also just make the name field much bigger so that we're not likely to run into this. ...but both seem like we'll just hit the bug again.
--- include/linux/serial_core.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
include/linux/serial_core.h +2 -1
@@ -348,7 +348,8 @@ struct earlycon_device { };struct earlycon_id { -char name[16 ]; +char name[15 ]; +char name_term;/* In case compiler didn't '\0' term name */ char compatible[128 ];int (*setup)(struct earlycon_device *,const char *options); };
Greg Kroah-Hartman
maintainerPATCH 197/246 soc: imx: gpcv2: Do not pass static memory as platform data
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andrey Smirnov <[email protected]>
[ Upstream commit 050f810e238f268670f14a8f8b793ba2dbf2e92f ]
Platform device core assumes the ownership of dev.platform_data as well as that it is dynamically allocated and it will try to kfree it as a part of platform_device_release(). Change the code to use platform_device_add_data() n instead of a pointer to a static memory to avoid causing a BUG() when calling platform_device_put().
The problem can be reproduced by artificially enabling the error path of platform_device_add() call (around line 357).
Note that this change also allows us to constify imx7_pgc_domains, since we no longer need to be able to modify it.
--- drivers/soc/imx/gpcv2.c | 22 +++++++++++++++------- 1 file changed, 15 insertions(+), 7 deletions(-)
drivers/soc/imx/gpcv2.c +15 -7
@@ -155,7 +155,7 @@ static int imx7_gpc_pu_pgc_sw_pdn_req(streturn imx7_gpc_pu_pgc_sw_pxx_req (genpd, false); } -static struct imx7_pgc_domain imx7_pgc_domains[] = { +static const struct imx7_pgc_domain imx7_pgc_domains[] = { [IMX7_POWER_DOMAIN_MIPI_PHY ] = { .genpd = { .name ="mipi-phy" ,
@@ -321,11 +321,6 @@ static int imx_gpcv2_probe(struct platfocontinue ; } - domain = &imx7_pgc_domains[domain_index]; - domain->regmap = regmap; - domain->genpd.power_on = imx7_gpc_pu_pgc_sw_pup_req; - domain->genpd.power_off = imx7_gpc_pu_pgc_sw_pdn_req; - pd_pdev =platform_device_alloc ("imx7-pgc-domain" , domain_index);if (!pd_pdev) {
@@ -334,7 +329,20 @@ static int imx_gpcv2_probe(struct platforeturn -ENOMEM ; } - pd_pdev->dev.platform_data = domain; + ret =platform_device_add_data (pd_pdev, + &imx7_pgc_domains[domain_index], +sizeof (imx7_pgc_domains[domain_index])); +if (ret) { +platform_device_put (pd_pdev); +of_node_put (np); +return ret; + } + + domain = pd_pdev->dev.platform_data; + domain->regmap = regmap; + domain->genpd.power_on = imx7_gpc_pu_pgc_sw_pup_req; + domain->genpd.power_off = imx7_gpc_pu_pgc_sw_pdn_req; + pd_pdev->dev.parent = dev; pd_pdev->dev.of_node = np;
Greg Kroah-Hartman
maintainerPATCH 198/246 microblaze: Fix simpleImage format generation
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Michal Simek <[email protected]>
[ Upstream commit ece97f3a5fb50cf5f98886fbc63c9665f2bb199d ]
simpleImage generation was broken for some time. This patch is fixing steps how simpleImage.*.ub file is generated. Steps are objdump of vmlinux and create .ub.
Also make sure that there is striped elf version with .strip suffix.
--- arch/microblaze/boot/Makefile | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
arch/microblaze/boot/Makefile +6 -4
@@ -22,17 +22,19 @@ $(obj)/linux.bin.gz: $(obj)/linux.bin FO quiet_cmd_cp = CP $< $@$2 cmd_cp = cat $< >$@$2 || (rm -f $@ && echo false) -quiet_cmd_strip = STRIP $@ +quiet_cmd_strip = STRIP $< $@$2 cmd_strip = $(STRIP) -K microblaze_start -K _end -K __log_buf \ - -K _fdt_start vmlinux -o $@ + -K _fdt_start $< -o $@$2 UIMAGE_LOADADDR = $(CONFIG_KERNEL_BASE_ADDR) +UIMAGE_IN = $@ +UIMAGE_OUT = [email protected] $(obj)/simpleImage.%: vmlinux FORCE $(call if_changed,cp,.unstrip) $(call if_changed,objcopy) $(call if_changed,uimage) - $(call if_changed,strip) - @echo 'Kernel: $@ is ready' ' (#'`cat .version`')' + $(call if_changed,strip,.strip) + @echo 'Kernel: $(UIMAGE_OUT) is ready' ' (#'`cat .version`')' clean-files += simpleImage.*.unstrip linux.bin.ub dts/*.dtb
Greg Kroah-Hartman
maintainerPATCH 199/246 usb: hub: Dont wait for connect state at resume for powered-off ports
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dominik Bozek <[email protected]>
[ Upstream commit 5d111f5190848d6fb1c414dc57797efea3526a2f ]
wait_for_connected() wait till a port change status to USB_PORT_STAT_CONNECTION, but this is not possible if the port is unpowered. The loop will only exit at timeout.
Such case take place if an over-current incident happen while system is in S3. Then during resume wait_for_connected() will wait 2s, which may be noticeable by the user.
--- drivers/usb/core/hub.c | 4 ++++ 1 file changed, 4 insertions(+)
drivers/usb/core/hub.c +4 -0
@@ -3361,6 +3361,10 @@ static int wait_for_connected(struct usbwhile (delay_ms <2000 ) {if (status || *portstatus &USB_PORT_STAT_CONNECTION )break ; +if (!port_is_power_on (hub, *portstatus)) { + status = -ENODEV ; +break ; + }msleep (20 ); delay_ms +=20 ; status =hub_port_status (hub, *port1, portstatus, portchange);
Greg Kroah-Hartman
maintainerPATCH 200/246 crypto: authencesn - dont leak pointers to authenc keys
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tudor-Dan Ambarus <[email protected]>
[ Upstream commit 31545df391d58a3bb60e29b1192644a6f2b5a8dd ]
In crypto_authenc_esn_setkey we save pointers to the authenc keys in a local variable of type struct crypto_authenc_keys and we don't zeroize it after use. Fix this and don't leak pointers to the authenc keys.
--- crypto/authencesn.c | 1 + 1 file changed, 1 insertion(+)
crypto/authencesn.c +1 -0
@@ -90,6 +90,7 @@ static int crypto_authenc_esn_setkey(str CRYPTO_TFM_RES_MASK); out: +memzero_explicit (&keys,sizeof (keys));return err; badkey:
Greg Kroah-Hartman
maintainerPATCH 201/246 crypto: authenc - dont leak pointers to authenc keys
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Tudor-Dan Ambarus <[email protected]>
[ Upstream commit ad2fdcdf75d169e7a5aec6c7cb421c0bec8ec711 ]
In crypto_authenc_setkey we save pointers to the authenc keys in a local variable of type struct crypto_authenc_keys and we don't zeroize it after use. Fix this and don't leak pointers to the authenc keys.
--- crypto/authenc.c | 1 + 1 file changed, 1 insertion(+)
crypto/authenc.c +1 -0
@@ -108,6 +108,7 @@ static int crypto_authenc_setkey(struct CRYPTO_TFM_RES_MASK); out: +memzero_explicit (&keys,sizeof (keys));return err; badkey:
Greg Kroah-Hartman
maintainerPATCH 202/246 media: omap3isp: fix unbalanced dma_iommu_mapping
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Suman Anna <[email protected]>
[ Upstream commit b7e1e6859fbf60519fd82d7120cee106a6019512 ]
The OMAP3 ISP driver manages its MMU mappings through the IOMMU-aware ARM DMA backend. The current code creates a dma_iommu_mapping and attaches this to the ISP device, but never detaches the mapping in either the probe failure paths or the driver remove path resulting in an unbalanced mapping refcount and a memory leak. Fix this properly.
--- drivers/media/platform/omap3isp/isp.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-)
drivers/media/platform/omap3isp/isp.c +4 -3
@@ -1945,6 +1945,7 @@ error_csi2:static void isp_detach_iommu (struct isp_device *isp) { +arm_iommu_detach_device (isp->dev);arm_iommu_release_mapping (isp->mapping); isp->mapping =NULL ; }
@@ -1961,8 +1962,7 @@ static int isp_attach_iommu(struct isp_d mapping =arm_iommu_create_mapping (&platform_bus_type,SZ_1G ,SZ_2G );if (IS_ERR (mapping)) {dev_err (isp->dev,"failed to create ARM IOMMU mapping\n" ); - ret =PTR_ERR (mapping); - goto error; +return PTR_ERR (mapping); } isp->mapping = mapping;
@@ -1977,7 +1977,8 @@ static int isp_attach_iommu(struct isp_dreturn 0 ; error: -isp_detach_iommu (isp); +arm_iommu_release_mapping (isp->mapping); + isp->mapping =NULL ;return ret; }
Greg Kroah-Hartman
maintainerPATCH 203/246 regulator: Dont return or expect -errno from of_map_mode()
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Douglas Anderson <[email protected]>
[ Upstream commit 02f3703934a42417021405ef336fe45add13c3d1 ]
In of_get_regulation_constraints() we were taking the result of of_map_mode() (an unsigned int) and assigning it to an int. We were then checking whether this value was -EINVAL. Some implementers of of_map_mode() were returning -EINVAL (even though the return type of their function needed to be unsigned int) because they needed to signal an error back to of_get_regulation_constraints().
In general in the regulator framework the mode is always referred to as an unsigned int. While we could fix this to be a signed int (the highest value we store in there right now is 0x8), it's actually pretty clean to just define the regulator mode 0x0 (the lack of any bits set) as an invalid mode. Let's do that.
--- drivers/regulator/cpcap-regulator.c | 2 +- drivers/regulator/of_regulator.c | 13 +++++++------ drivers/regulator/twl-regulator.c | 2 +- include/linux/regulator/consumer.h | 1 + 4 files changed, 10 insertions(+), 8 deletions(-)
drivers/regulator/cpcap-regulator.c +1 -1
@@ -222,7 +222,7 @@ static unsigned int cpcap_map_mode(unsigcase CPCAP_BIT_AUDIO_LOW_PWR :return REGULATOR_MODE_STANDBY ;default : -return -EINVAL ; +return REGULATOR_MODE_INVALID ; } }
drivers/regulator/of_regulator.c +7 -6
@@ -31,6 +31,7 @@ static void of_get_regulation_constraintstruct regulation_constraints *constraints = &(*init_data)->constraints;struct regulator_state *suspend_state;struct device_node *suspend_np; +unsigned int mode;int ret, i;u32 pval;
@@ -124,11 +125,11 @@ static void of_get_regulation_constraintif (!of_property_read_u32 (np,"regulator-initial-mode" , &pval)) {if (desc && desc->of_map_mode) { - ret = desc->of_map_mode (pval); -if (ret == -EINVAL ) + mode = desc->of_map_mode (pval); +if (mode ==REGULATOR_MODE_INVALID )pr_err ("%s: invalid mode %u\n" , np->name, pval);else - constraints->initial_mode = ret; + constraints->initial_mode = mode; }else {pr_warn ("%s: mapping for mode %d not defined\n" , np->name, pval);
@@ -163,12 +164,12 @@ static void of_get_regulation_constraintif (!of_property_read_u32 (suspend_np,"regulator-mode" , &pval)) {if (desc && desc->of_map_mode) { - ret = desc->of_map_mode (pval); -if (ret == -EINVAL ) + mode = desc->of_map_mode (pval); +if (mode ==REGULATOR_MODE_INVALID )pr_err ("%s: invalid mode %u\n" , np->name, pval);else - suspend_state->mode = ret; + suspend_state->mode = mode; }else {pr_warn ("%s: mapping for mode %d not defined\n" , np->name, pval);
drivers/regulator/twl-regulator.c +1 -1
@@ -274,7 +274,7 @@ static inline unsigned int twl4030reg_macase RES_STATE_SLEEP :return REGULATOR_MODE_STANDBY ;default : -return -EINVAL ; +return REGULATOR_MODE_INVALID ; } }
include/linux/regulator/consumer.h +1 -0
@@ -80,6 +80,7 @@ struct regmap;* These modes can be OR'ed together to make up a mask of valid register modes. */ +#define REGULATOR_MODE_INVALID 0x0#define REGULATOR_MODE_FAST 0x1#define REGULATOR_MODE_NORMAL 0x2#define REGULATOR_MODE_IDLE 0x4
Greg Kroah-Hartman
maintainerPATCH 204/246 scsi: scsi_dh: replace too broad "TP9" string with the exact models
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xose Vazquez Perez <[email protected]>
[ Upstream commit 37b37d2609cb0ac267280ef27350b962d16d272e ]
SGI/TP9100 is not an RDAC array:
^^^
This partially reverts commit 35204772ea03 ("[SCSI] scsi_dh_rdac :
Consolidate rdac strings together")
[mkp: fixed up the new entries to align with rest of struct]
--- drivers/scsi/scsi_dh.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
drivers/scsi/scsi_dh.c +4 -1
@@ -58,7 +58,10 @@ static const struct scsi_dh_blist scsi_d {"IBM", "3526", "rdac", }, {"IBM", "3542", "rdac", }, {"IBM", "3552", "rdac", }, - {"SGI", "TP9", "rdac", }, + {"SGI", "TP9300", "rdac", }, + {"SGI", "TP9400", "rdac", }, + {"SGI", "TP9500", "rdac", }, + {"SGI", "TP9700", "rdac", }, {"SGI", "IS", "rdac", }, {"STK", "OPENstorage", "rdac", }, {"STK", "FLEXLINE 380", "rdac", },
Greg Kroah-Hartman
maintainerPATCH 205/246 scsi: megaraid_sas: Increase timeout by 1 sec for non-RAID fastpath IOs
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Shivasharan S <[email protected]>
[ Upstream commit 3239b8cd28fd849a2023483257d35d68c5876c74 ]
Hardware could time out Fastpath IOs one second earlier than the timeout provided by the host.
For non-RAID devices, driver provides timeout value based on OS provided timeout value. Under certain scenarios, if the OS provides a timeout value of 1 second, due to above behavior hardware will timeout immediately.
Increase timeout value for non-RAID fastpath IOs by 1 second.
--- drivers/scsi/megaraid/megaraid_sas_fusion.c | 3 +++ 1 file changed, 3 insertions(+)
drivers/scsi/megaraid/megaraid_sas_fusion.c +3 -0
@@ -2677,6 +2677,9 @@ megasas_build_syspd_fusion(struct megasa pRAID_Context->timeout_value =cpu_to_le16 (os_timeout_value); pRAID_Context->virtual_disk_tgt_id =cpu_to_le16 (device_id); }else { +if (os_timeout_value) + os_timeout_value++; +/* system pd Fast Path */ io_request->Function =MPI2_FUNCTION_SCSI_IO_REQUEST ; timeout_limit = (scmd->device->type == TYPE_DISK) ?
Greg Kroah-Hartman
maintainerPATCH 206/246 scsi: cxlflash: Synchronize reset and remove ops
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Uma Krishnan <[email protected]>
[ Upstream commit a3feb6ef50def7c91244d7bd15a3625b7b49b81f ]
The following Oops can be encountered if a device removal or system shutdown is initiated while an EEH recovery is in process:
[c000000ff2f479c0] c008000015256f18 cxlflash_pci_slot_reset+0xa0/0x100
[cxlflash]
[c000000ff2f47a30] c00800000dae22e0 cxl_pci_slot_reset+0x168/0x290 [cxl] [c000000ff2f47ae0] c00000000003ef1c eeh_report_reset+0xec/0x170 [c000000ff2f47b20] c00000000003d0b8 eeh_pe_dev_traverse+0x98/0x170 [c000000ff2f47bb0] c00000000003f80c eeh_handle_normal_event+0x56c/0x580 [c000000ff2f47c60] c00000000003fba4 eeh_handle_event+0x2a4/0x338 [c000000ff2f47d10] c0000000000400b8 eeh_event_handler+0x1f8/0x200 [c000000ff2f47dc0] c00000000013da48 kthread+0x1a8/0x1b0 [c000000ff2f47e30] c00000000000b528 ret_from_kernel_thread+0x5c/0xb4
The remove handler frees AFU memory while the EEH recovery is in progress, leading to a race condition. This can result in a crash if the recovery thread tries to access this memory.
To resolve this issue, the cxlflash remove handler will evaluate the device state and yield to any active reset or probing threads.
--- drivers/scsi/cxlflash/main.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/scsi/cxlflash/main.c +3 -3
@@ -946,9 +946,9 @@ static void cxlflash_remove(struct pci_dreturn ; } -/* If a Task Management Function is active, wait for it to complete -* before continuing with remove. -*/ +/* Yield to running recovery threads before continuing with remove */ +wait_event (cfg->reset_waitq, cfg->state !=STATE_RESET && + cfg->state !=STATE_PROBING );spin_lock_irqsave (&cfg->tmf_slock, lock_flags);if (cfg->tmf_active) wait_event_interruptible_lock_irq(cfg->tmf_waitq,
Greg Kroah-Hartman
maintainerPATCH 207/246 scsi: cxlflash: Avoid clobbering context control register value
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Matthew R. Ochs" <[email protected]>
[ Upstream commit 465891fe9237b02f8d0fd26448f733fae7236f4a ]
The SISLite specification originally defined the context control register with a single field of bits to represent the LISN and also stipulated that the register reset value be 0. The cxlflash driver took advantage of this when programming the LISN for the master contexts via an unconditional write - no other bits were preserved.
When unmap support was added, SISLite was updated to define bit 0 of the context control register as a way for the AFU to notify the context owner that unmap operations were supported. Thus the assumptions under which the register is setup changed and the existing unconditional write is clobbering the unmap state for master contexts. This is presently not an issue due to the order in which the context control register is programmed in relation to the unmap bit being queried but should be addressed to avoid a future regression in the event this code is moved elsewhere.
To remedy this issue, preserve the bits when programming the LISN field in the context control register. Since the LISN will now be programmed using a read value, assert that the initial state of the LISN field is as described in SISLite (0).
--- drivers/scsi/cxlflash/main.c | 5 ++++- drivers/scsi/cxlflash/sislite.h | 1 + 2 files changed, 5 insertions(+), 1 deletion(-)
drivers/scsi/cxlflash/main.c +4 -1
@@ -1303,7 +1303,10 @@ static void afu_err_intr_init(struct afufor (i =0 ; i < afu->num_hwqs; i++) { hwq =get_hwq (afu, i); -writeq_be (SISL_MSI_SYNC_ERROR , &hwq->host_map->ctx_ctrl); + reg =readq_be (&hwq->host_map->ctx_ctrl); +WARN_ON ((reg &SISL_CTX_CTRL_LISN_MASK ) !=0 ); + reg |=SISL_MSI_SYNC_ERROR ; +writeq_be (reg, &hwq->host_map->ctx_ctrl);writeq_be (SISL_ISTATUS_MASK , &hwq->host_map->intr_mask); } }
drivers/scsi/cxlflash/sislite.h +1 -0
@@ -284,6 +284,7 @@ struct sisl_host_map {__be64 cmd_room;__be64 ctx_ctrl;/* least significant byte or b56:63 is LISN# */ #define SISL_CTX_CTRL_UNMAP_SECTOR 0x8000000000000000ULL/* b0 */ +#define SISL_CTX_CTRL_LISN_MASK (0xFFULL)__be64 mbox_w;/* restricted use */ __be64 sq_start;/* Submission Queue (R/W): write sequence and */ __be64 sq_end;/* inclusion semantics are the same as RRQ */
Greg Kroah-Hartman
maintainerPATCH 208/246 media: atomisp: compat32: fix __user annotations
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mauro Carvalho Chehab <[email protected]>
[ Upstream commit ad4222a0e29664666a71685a6e732923ca7c7e45 ]
The __user annotations at the compat32 code is not right:
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:81:18: warning: incorrect type in assignment (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:81:18: expected void *base
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:81:18: got void [noderef] <asn:1>*
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:232:23: warning: incorrect type in assignment (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:232:23: expected unsigned int [usertype] *xcoords_y
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:232:23: got void [noderef] <asn:1>*
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:233:23: warning: incorrect type in assignment (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:233:23: expected unsigned int [usertype] *ycoords_y
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:233:23: got void [noderef] <asn:1>*
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:234:24: warning: incorrect type in assignment (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:234:24: expected unsigned int [usertype] *xcoords_uv
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:234:24: got void [noderef] <asn:1>*
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:235:24: warning: incorrect type in assignment (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:235:24: expected unsigned int [usertype] *ycoords_uv
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:235:24: got void [noderef] <asn:1>*
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:296:29: warning: incorrect type in assignment (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:296:29: expected unsigned int [usertype] *effective_width
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:296:29: got void [noderef] <asn:1>*
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:360:29: warning: incorrect type in assignment (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:360:29: expected unsigned int [usertype] *effective_width
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:360:29: got void [noderef] <asn:1>*
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:437:19: warning: incorrect type in assignment (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:437:19: expected struct v4l2_framebuffer *frame
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:437:19: got void [noderef] <asn:1>*
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:481:29: warning: incorrect type in assignment (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:481:29: expected unsigned short *calb_grp_values
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:481:29: got void [noderef] <asn:1>*
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:701:39: warning: cast removes address space of expression drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:704:21: warning: incorrect type in argument 1 (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:704:21: expected void const volatile [noderef] <asn:1>*<noident>
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:704:21: got unsigned int [usertype] *src
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:737:43: warning: incorrect type in assignment (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:737:43: expected struct atomisp_shading_table *shading_table
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:737:43: got void [noderef] <asn:1>*
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:742:44: warning: incorrect type in argument 1 (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:742:44: expected void [noderef] <asn:1>*to
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:742:44: got struct atomisp_shading_table *shading_table
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:755:41: warning: incorrect type in assignment (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:755:41: expected struct atomisp_morph_table *morph_table
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:755:41: got void [noderef] <asn:1>*
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:760:44: warning: incorrect type in argument 1 (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:760:44: expected void [noderef] <asn:1>*to
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:760:44: got struct atomisp_morph_table *morph_table
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:772:40: warning: incorrect type in assignment (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:772:40: expected struct atomisp_dvs2_coefficients *dvs2_coefs
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:772:40: got void [noderef] <asn:1>*
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:777:44: warning: incorrect type in argument 1 (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:777:44: expected void [noderef] <asn:1>*to
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:777:44: got struct atomisp_dvs2_coefficients *dvs2_coefs
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:788:46: warning: incorrect type in assignment (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:788:46: expected struct atomisp_dvs_6axis_config *dvs_6axis_config
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:788:46: got void [noderef] <asn:1>*
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:793:44: warning: incorrect type in argument 1 (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:793:44: expected void [noderef] <asn:1>*to
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:793:44: got struct atomisp_dvs_6axis_config *dvs_6axis_config
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:853:17: warning: incorrect type in assignment (different address spaces)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:853:17: expected struct atomisp_sensor_ae_bracketing_lut_entry *lut
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c:853:17: got void [noderef] <asn:1>*
--- drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c | 49 +++++----- 1 file changed, 26 insertions(+), 23 deletions(-)
drivers/staging/media/atomisp/pci/atomisp2/atomisp_compat_ioctl32.c +26 -23
@@ -81,7 +81,7 @@ static int get_v4l2_framebuffer32(struct get_user(kp->flags, &up->flags))return -EFAULT ; - kp->base =compat_ptr (tmp); + kp->base = (void __force *)compat_ptr (tmp);get_v4l2_pix_format ((struct v4l2_pix_format *)&kp->fmt, &up->fmt);return 0 ; }
@@ -232,10 +232,10 @@ static int get_atomisp_dvs_6axis_config3 get_user(ycoords_uv, &up->ycoords_uv))return -EFAULT ; - kp->xcoords_y =compat_ptr (xcoords_y); - kp->ycoords_y =compat_ptr (ycoords_y); - kp->xcoords_uv =compat_ptr (xcoords_uv); - kp->ycoords_uv =compat_ptr (ycoords_uv); + kp->xcoords_y = (void __force *)compat_ptr (xcoords_y); + kp->ycoords_y = (void __force *)compat_ptr (ycoords_y); + kp->xcoords_uv = (void __force *)compat_ptr (xcoords_uv); + kp->ycoords_uv = (void __force *)compat_ptr (ycoords_uv);return 0 ; }
@@ -296,7 +296,7 @@ static int get_atomisp_metadata_stat32(sreturn -EFAULT ; kp->data =compat_ptr (data); - kp->effective_width =compat_ptr (effective_width); + kp->effective_width = (void __force *)compat_ptr (effective_width);return 0 ; }
@@ -360,7 +360,7 @@ static int get_atomisp_metadata_by_type_return -EFAULT ; kp->data =compat_ptr (data); - kp->effective_width =compat_ptr (effective_width); + kp->effective_width = (void __force *)compat_ptr (effective_width);return 0 ; }
@@ -437,7 +437,7 @@ static int get_atomisp_overlay32(struct get_user(kp->overlay_start_x, &up->overlay_start_y)) return -EFAULT; - kp->frame =compat_ptr (frame); + kp->frame = (void __force *)compat_ptr (frame);return 0 ; }
@@ -481,7 +481,7 @@ static int get_atomisp_calibration_group get_user(calb_grp_values, &up->calb_grp_values)) return -EFAULT; - kp->calb_grp_values =compat_ptr (calb_grp_values); + kp->calb_grp_values = (void __force *)compat_ptr (calb_grp_values);return 0 ; }
@@ -703,8 +703,8 @@ static int get_atomisp_parameters32(strureturn -EFAULT ;while (n >=0 ) { -compat_uptr_t *src = (compat_uptr_t *)up + n; -uintptr_t *dst = (uintptr_t *)kp + n; +compat_uptr_t __user *src = ((compat_uptr_t __user *)up) + n; +uintptr_t *dst = ((uintptr_t *)kp) + n;if (get_user ((*dst), src))return -EFAULT ;
@@ -751,12 +751,12 @@ static int get_atomisp_parameters32(stru#endif return -EFAULT ; - kp->shading_table = user_ptr + offset; + kp->shading_table = (void __force *)user_ptr + offset; offset =sizeof (struct atomisp_shading_table );if (!kp->shading_table)return -EFAULT ; -if (copy_to_user (kp->shading_table, +if (copy_to_user ((void __user *)kp->shading_table, &karg.shading_table,sizeof (struct atomisp_shading_table )))return -EFAULT ;
@@ -777,13 +777,14 @@ static int get_atomisp_parameters32(stru#endif return -EFAULT ; - kp->morph_table = user_ptr + offset; + kp->morph_table = (void __force *)user_ptr + offset; offset +=sizeof (struct atomisp_morph_table );if (!kp->morph_table)return -EFAULT ; -if (copy_to_user (kp->morph_table, &karg.morph_table, -sizeof (struct atomisp_morph_table ))) +if (copy_to_user ((void __user *)kp->morph_table, + &karg.morph_table, +sizeof (struct atomisp_morph_table )))return -EFAULT ; }
@@ -802,13 +803,14 @@ static int get_atomisp_parameters32(stru#endif return -EFAULT ; - kp->dvs2_coefs = user_ptr + offset; + kp->dvs2_coefs = (void __force *)user_ptr + offset; offset +=sizeof (struct atomisp_dis_coefficients );if (!kp->dvs2_coefs)return -EFAULT ; -if (copy_to_user (kp->dvs2_coefs, &karg.dvs2_coefs, -sizeof (struct atomisp_dis_coefficients ))) +if (copy_to_user ((void __user *)kp->dvs2_coefs, + &karg.dvs2_coefs, +sizeof (struct atomisp_dis_coefficients )))return -EFAULT ; }/* handle dvs 6axis configuration */
@@ -826,13 +828,14 @@ static int get_atomisp_parameters32(stru#endif return -EFAULT ; - kp->dvs_6axis_config = user_ptr + offset; + kp->dvs_6axis_config = (void __force *)user_ptr + offset; offset +=sizeof (struct atomisp_dvs_6axis_config );if (!kp->dvs_6axis_config)return -EFAULT ; -if (copy_to_user (kp->dvs_6axis_config, &karg.dvs_6axis_config, -sizeof (struct atomisp_dvs_6axis_config ))) +if (copy_to_user ((void __user *)kp->dvs_6axis_config, + &karg.dvs_6axis_config, +sizeof (struct atomisp_dvs_6axis_config )))return -EFAULT ; } }
@@ -891,7 +894,7 @@ static int get_atomisp_sensor_ae_bracket get_user(lut, &up->lut))return -EFAULT ; - kp->lut =compat_ptr (lut); + kp->lut = (void __force *)compat_ptr (lut);return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 209/246 media: si470x: fix __be16 annotations
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Mauro Carvalho Chehab <[email protected]>
[ Upstream commit 90db5c829692a0a7845e977e45719b4699216bd4 ]
The annotations there are wrong as warned:
drivers/media/radio/si470x/radio-si470x-i2c.c:107:35: warning: cast to restricted __be16 drivers/media/radio/si470x/radio-si470x-i2c.c:107:35: warning: cast to restricted __be16 drivers/media/radio/si470x/radio-si470x-i2c.c:107:35: warning: cast to restricted __be16 drivers/media/radio/si470x/radio-si470x-i2c.c:107:35: warning: cast to restricted __be16 drivers/media/radio/si470x/radio-si470x-i2c.c:129:24: warning: incorrect type in assignment (different base types)
drivers/media/radio/si470x/radio-si470x-i2c.c:129:24: expected unsigned short [unsigned] [short] <noident>
drivers/media/radio/si470x/radio-si470x-i2c.c:129:24: got restricted __be16 [usertype] <noident>
drivers/media/radio/si470x/radio-si470x-i2c.c:163:39: warning: cast to restricted __be16 drivers/media/radio/si470x/radio-si470x-i2c.c:163:39: warning: cast to restricted __be16 drivers/media/radio/si470x/radio-si470x-i2c.c:163:39: warning: cast to restricted __be16 drivers/media/radio/si470x/radio-si470x-i2c.c:163:39: warning: cast to restricted __be16
--- drivers/media/radio/si470x/radio-si470x-i2c.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
drivers/media/radio/si470x/radio-si470x-i2c.c +3 -3
@@ -92,7 +92,7 @@ MODULE_PARM_DESC(max_rds_errors, "RDS ma*/ int si470x_get_register (struct si470x_device *radio,int regnr) { -u16 buf[READ_REG_NUM ]; +__be16 buf[READ_REG_NUM ];struct i2c_msg msgs[1 ] = { { .addr = radio->client->addr,
@@ -117,7 +117,7 @@ int si470x_get_register(struct si470x_deint si470x_set_register (struct si470x_device *radio,int regnr) {int i; -u16 buf[WRITE_REG_NUM ]; +__be16 buf[WRITE_REG_NUM ];struct i2c_msg msgs[1 ] = { { .addr = radio->client->addr,
@@ -147,7 +147,7 @@ int si470x_set_register(struct si470x_destatic int si470x_get_all_registers (struct si470x_device *radio) {int i; -u16 buf[READ_REG_NUM ]; +__be16 buf[READ_REG_NUM ];struct i2c_msg msgs[1 ] = { { .addr = radio->client->addr,
Greg Kroah-Hartman
maintainerPATCH 210/246 ASoC: topology: Fix bclk and fsync inversion in set_link_hw_format()
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kirill Marinushkin <[email protected]>
[ Upstream commit a941e2fab3207cb0d57dc4ec47b1b12c8ea78b84 ]
The values of bclk and fsync are inverted WRT the codec. But the existing solution already works for Broadwell, see the alsa-lib config:
alsa-lib/src/conf/topology/broadwell/broadwell.conf
This commit provides the backwards-compatible solution to fix this misuse.
--- include/uapi/sound/asoc.h | 16 ++++++++++++++-- sound/soc/soc-topology.c | 12 +++++++----- 2 files changed, 21 insertions(+), 7 deletions(-)
include/uapi/sound/asoc.h +14 -2
@@ -160,6 +160,18 @@#define SND_SOC_TPLG_LNK_FLGBIT_SYMMETRIC_SAMPLEBITS (1 << 2)#define SND_SOC_TPLG_LNK_FLGBIT_VOICE_WAKEUP (1 << 3) +/* DAI topology BCLK parameter +* For the backwards capability, by default codec is bclk master +*/ +#define SND_SOC_TPLG_BCLK_CM 0/* codec is bclk master */ +#define SND_SOC_TPLG_BCLK_CS 1/* codec is bclk slave */ + +/* DAI topology FSYNC parameter +* For the backwards capability, by default codec is fsync master +*/ +#define SND_SOC_TPLG_FSYNC_CM 0/* codec is fsync master */ +#define SND_SOC_TPLG_FSYNC_CS 1/* codec is fsync slave */ +/* * Block Header. * This header precedes all object and object arrays below.
@@ -315,8 +327,8 @@ struct snd_soc_tplg_hw_config {__u8 clock_gated;/* 1 if clock can be gated to save power */ __u8 invert_bclk;/* 1 for inverted BCLK, 0 for normal */ __u8 invert_fsync;/* 1 for inverted frame clock, 0 for normal */ -__u8 bclk_master;/* 1 for master of BCLK, 0 for slave */ -__u8 fsync_master;/* 1 for master of FSYNC, 0 for slave */ +__u8 bclk_master;/* SND_SOC_TPLG_BCLK_ value */ +__u8 fsync_master;/* SND_SOC_TPLG_FSYNC_ value */ __u8 mclk_direction;/* 0 for input, 1 for output */ __le16 reserved;/* for 32bit alignment */ __le32 mclk_rate;/* MCLK or SYSCLK freqency in Hz */
sound/soc/soc-topology.c +7 -5
@@ -2010,13 +2010,15 @@ static void set_link_hw_format(struct sn link->dai_fmt |=SND_SOC_DAIFMT_IB_IF ;/* clock masters */ - bclk_master = hw_config->bclk_master; - fsync_master = hw_config->fsync_master; -if (!bclk_master && !fsync_master) + bclk_master = (hw_config->bclk_master == +SND_SOC_TPLG_BCLK_CM ); + fsync_master = (hw_config->fsync_master == +SND_SOC_TPLG_FSYNC_CM ); +if (bclk_master && fsync_master) link->dai_fmt |=SND_SOC_DAIFMT_CBM_CFM ; -else if (bclk_master && !fsync_master) - link->dai_fmt |=SND_SOC_DAIFMT_CBS_CFM ;else if (!bclk_master && fsync_master) + link->dai_fmt |=SND_SOC_DAIFMT_CBS_CFM ; +else if (bclk_master && !fsync_master) link->dai_fmt |=SND_SOC_DAIFMT_CBM_CFS ;else link->dai_fmt |=SND_SOC_DAIFMT_CBS_CFS ;
Greg Kroah-Hartman
maintainerPATCH 211/246 ASoC: topology: Add missing clock gating parameter when parsing hw_configs
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Kirill Marinushkin <[email protected]>
[ Upstream commit 933e1c4a667103c4d10ebdc9505a0a6abd8c3fbd ]
Clock gating parameter is a part of dai_fmt. It is supported by alsa-lib when creating a topology binary file, but ignored by kernel when loading this topology file.
After applying this commit, the clock gating parameter is not ignored any more. This solution is backwards compatible. The existing behaviour is not broken, because by default the parameter value is 0 and is ignored.
snd_soc_tplg_hw_config.clock_gated = 0 => no effect snd_soc_tplg_hw_config.clock_gated = 1 => SND_SOC_DAIFMT_GATED snd_soc_tplg_hw_config.clock_gated = 2 => SND_SOC_DAIFMT_CONT
For example, the following config, based on alsa-lib/src/conf/topology/broadwell/broadwell.conf, is now supported:
~~~~
SectionHWConfig."CodecHWConfig" {
id "1"
format "I2S" # physical audio format.
pm_gate_clocks "true" # clock can be gated
}
SectionLink."Codec" {
# used for binding to the physical link
id "0" hw_configs [
"CodecHWConfig"
]
default_hw_conf_id "1"
}~~~~
--- include/uapi/sound/asoc.h | 7 ++++++- sound/soc/soc-topology.c | 7 +++++++ 2 files changed, 13 insertions(+), 1 deletion(-)
include/uapi/sound/asoc.h +6 -1
@@ -139,6 +139,11 @@#define SND_SOC_TPLG_DAI_FLGBIT_SYMMETRIC_CHANNELS (1 << 1)#define SND_SOC_TPLG_DAI_FLGBIT_SYMMETRIC_SAMPLEBITS (1 << 2) +/* DAI clock gating */ +#define SND_SOC_TPLG_DAI_CLK_GATE_UNDEFINED 0 +#define SND_SOC_TPLG_DAI_CLK_GATE_GATED 1 +#define SND_SOC_TPLG_DAI_CLK_GATE_CONT 2 +/* DAI physical PCM data formats. * Add new formats to the end of the list. */
@@ -324,7 +329,7 @@ struct snd_soc_tplg_hw_config {__le32 size;/* in bytes of this structure */ __le32 id;/* unique ID - - used to match */ __le32 fmt;/* SND_SOC_DAI_FORMAT_ format value */ -__u8 clock_gated;/* 1 if clock can be gated to save power */ +__u8 clock_gated;/* SND_SOC_TPLG_DAI_CLK_GATE_ value */ __u8 invert_bclk;/* 1 for inverted BCLK, 0 for normal */ __u8 invert_fsync;/* 1 for inverted frame clock, 0 for normal */ __u8 bclk_master;/* SND_SOC_TPLG_BCLK_ value */
sound/soc/soc-topology.c +7 -0
@@ -1997,6 +1997,13 @@ static void set_link_hw_format(struct sn link->dai_fmt = hw_config->fmt &SND_SOC_DAIFMT_FORMAT_MASK ; +/* clock gating */ +if (hw_config->clock_gated ==SND_SOC_TPLG_DAI_CLK_GATE_GATED ) + link->dai_fmt |=SND_SOC_DAIFMT_GATED ; +else if (hw_config->clock_gated == +SND_SOC_TPLG_DAI_CLK_GATE_CONT ) + link->dai_fmt |=SND_SOC_DAIFMT_CONT ; +/* clock signal polarity */ invert_bclk = hw_config->invert_bclk; invert_fsync = hw_config->invert_fsync;
Greg Kroah-Hartman
maintainerPATCH 214/246 drm/dp/mst: Fix off-by-one typo when dump payload table
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Andy Shevchenko <[email protected]>
[ Upstream commit 7056a2bccc3b5afc51f9b35b30a46f0d9219968d ]
It seems there is a classical off-by-one typo from the beginning when commit
ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)")
introduced a new helper.
Fix a typo by introducing a macro constant.
--- drivers/gpu/drm/drm_dp_mst_topology.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
drivers/gpu/drm/drm_dp_mst_topology.c +5 -4
@@ -2862,12 +2862,14 @@ static void drm_dp_mst_dump_mstb(struct } } +#define DP_PAYLOAD_TABLE_SIZE 64 +static bool dump_dp_payload_table (struct drm_dp_mst_topology_mgr *mgr,char *buf) {int i; -for (i =0 ; i <64 ; i +=16 ) { +for (i =0 ; i <DP_PAYLOAD_TABLE_SIZE ; i +=16 ) {if (drm_dp_dpcd_read (mgr->aux,DP_PAYLOAD_TABLE_UPDATE_STATUS + i, &buf[i],16 ) !=16 )
@@ -2936,7 +2938,7 @@ void drm_dp_mst_dump_topology(struct seqmutex_lock (&mgr->lock);if (mgr->mst_primary) { -u8 buf[64 ]; +u8 buf[DP_PAYLOAD_TABLE_SIZE ];int ret; ret =drm_dp_dpcd_read (mgr->aux,DP_DPCD_REV , buf,DP_RECEIVER_CAP_SIZE );
@@ -2954,8 +2956,7 @@ void drm_dp_mst_dump_topology(struct seqseq_printf (m," revision: hw: %x.%x sw: %x.%x\n" , buf[0x9 ] >>4 , buf[0x9 ] &0xf , buf[0xa ], buf[0xb ]);if (dump_dp_payload_table (mgr, buf)) -seq_printf (m,"payload table: %*ph\n" ,63 , buf); - +seq_printf (m,"payload table: %*ph\n" ,DP_PAYLOAD_TABLE_SIZE , buf); }mutex_unlock (&mgr->lock);
Greg Kroah-Hartman
maintainerPATCH 215/246 block: bio_iov_iter_get_pages: fix size of last iovec
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Martin Wilck <[email protected]>
commit b403ea2404889e1227812fa9657667a1deb9c694 upstream.
If the last page of the bio is not "full", the length of the last vector slot needs to be corrected. This slot has the index (bio->bi_vcnt - 1), but only in bio->bi_io_vec. In the "bv" helper array, which is shifted by the value of bio->bi_vcnt at function invocation, the correct index is (nr_pages - 1).
v2: improved readability following suggestions from Ming Lei.
v3: followed a formatting suggestion from Christoph Hellwig.
--- block/bio.c | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-)
block/bio.c +8 -10
@@ -881,16 +881,16 @@ EXPORT_SYMBOL(bio_add_page);*/ int bio_iov_iter_get_pages (struct bio *bio,struct iov_iter *iter) { -unsigned short nr_pages = bio->bi_max_vecs - bio->bi_vcnt; +unsigned short nr_pages = bio->bi_max_vecs - bio->bi_vcnt, idx;struct bio_vec *bv = bio->bi_io_vec + bio->bi_vcnt;struct page **pages = (struct page **)bv; -size_t offset, diff; +size_t offset;ssize_t size; size =iov_iter_get_pages (iter, pages,LONG_MAX , nr_pages, &offset);if (unlikely (size <=0 ))return size ? size : -EFAULT ; - nr_pages = (size + offset +PAGE_SIZE -1 ) /PAGE_SIZE ; + idx = nr_pages = (size + offset +PAGE_SIZE -1 ) /PAGE_SIZE ;/* * Deep magic below: We need to walk the pinned pages backwards
@@ -903,17 +903,15 @@ int bio_iov_iter_get_pages(struct bio *b bio->bi_iter.bi_size += size; bio->bi_vcnt += nr_pages; - diff = (nr_pages *PAGE_SIZE - offset) - size; -while (nr_pages--) { - bv[nr_pages].bv_page = pages[nr_pages]; - bv[nr_pages].bv_len =PAGE_SIZE ; - bv[nr_pages].bv_offset =0 ; +while (idx--) { + bv[idx].bv_page = pages[idx]; + bv[idx].bv_len =PAGE_SIZE ; + bv[idx].bv_offset =0 ; } bv[0 ].bv_offset += offset; bv[0 ].bv_len -= offset; -if (diff) - bv[bio->bi_vcnt -1 ].bv_len -= diff; + bv[nr_pages -1 ].bv_len -= nr_pages *PAGE_SIZE - offset - size;iov_iter_advance (iter, size);return 0 ;
Greg Kroah-Hartman
maintainerPATCH 216/246 blkdev: __blkdev_direct_IO_simple: fix leak in error case
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Martin Wilck <[email protected]>
commit 9362dd1109f87a9d0a798fbc890cb339c171ed35 upstream.
--- fs/block_dev.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-)
fs/block_dev.c +5 -4
@@ -231,7 +231,7 @@ __blkdev_direct_IO_simple(struct kiocb * ret =bio_iov_iter_get_pages (&bio, iter);if (unlikely (ret)) -return ret; + goto out; ret = bio.bi_iter.bi_size;if (iov_iter_rw (iter) ==READ ) {
@@ -260,12 +260,13 @@ __blkdev_direct_IO_simple(struct kiocb *put_page (bvec->bv_page); } -if (vecs != inline_vecs) -kfree (vecs); -if (unlikely (bio.bi_status)) ret =blk_status_to_errno (bio.bi_status); +out: +if (vecs != inline_vecs) +kfree (vecs); +bio_uninit (&bio);return ret;
Greg Kroah-Hartman
maintainerPATCH 217/246 block: reset bi_iter.bi_done after splitting bio
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Greg Edwards <[email protected]>
commit 5151842b9d8732d4cbfa8400b40bff894f501b2f upstream.
After the bio has been updated to represent the remaining sectors, reset bi_done so bio_rewind_iter() does not rewind further than it should.
This resolves a bio_integrity_process() failure on reads where the original request was split.
--- block/bio.c | 1 + 1 file changed, 1 insertion(+)
block/bio.c +1 -0
@@ -1889,6 +1889,7 @@ struct bio *bio_split(struct bio *bio, ibio_integrity_trim (split);bio_advance (bio, split->bi_iter.bi_size); + bio->bi_iter.bi_done =0 ;if (bio_flagged (bio,BIO_TRACE_COMPLETION ))bio_set_flag (split,BIO_TRACE_COMPLETION );
Greg Kroah-Hartman
maintainerPATCH 218/246 random: mix rdrand with entropy sent in from userspace
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Theodore Ts'o <[email protected]>
commit 81e69df38e2911b642ec121dec319fad2a4782f3 upstream.
Fedora has integrated the jitter entropy daemon to work around slow boot problems, especially on VM's that don't support virtio-rng:
https://bugzilla.redhat.com/show_bug.cgi?id=1572944
It's understandable why they did this, but the Jitter entropy daemon works fundamentally on the principle: "the CPU microarchitecture is **so** complicated and we can't figure it out, so it *must* be random". Yes, it uses statistical tests to "prove" it is secure, but AES_ENCRYPT(NSA_KEY, COUNTER++) will also pass statistical tests with flying colors.
So if RDRAND is available, mix it into entropy submitted from userspace. It can't hurt, and if you believe the NSA has backdoored RDRAND, then they probably have enough details about the Intel microarchitecture that they can reverse engineer how the Jitter entropy daemon affects the microarchitecture, and attack its output stream. And if RDRAND is in fact an honest DRNG, it will immeasurably improve on what the Jitter entropy daemon might produce.
This also provides some protection against someone who is able to read or set the entropy seed file.
--- drivers/char/random.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
drivers/char/random.c +9 -1
@@ -1897,14 +1897,22 @@ static int write_pool(struct entropy_store *r, const char __user *buffer, size_t count) { size_t bytes; -__u32 buf[16 ]; +__u32 t, buf[16 ];const char __user *p = buffer;while (count >0 ) { +int b, i =0 ; + bytes =min (count,sizeof (buf));if (copy_from_user (&buf, p, bytes))return -EFAULT ; +for (b = bytes ; b >0 ; b -=sizeof (__u32), i++) { +if (!arch_get_random_int (&t)) +break ; + buf[i] ^= t; + } + count -= bytes; p += bytes;
Greg Kroah-Hartman
maintainerPATCH 219/246 squashfs: be more careful about metadata corruption
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Linus Torvalds <[email protected]>
commit 01cfb7937a9af2abb1136c7e89fbf3fd92952956 upstream.
Anatoly Trosinenko reports that a corrupted squashfs image can cause a kernel oops. It turns out that squashfs can end up being confused about negative fragment lengths.
The regular squashfs_read_data() does check for negative lengths, but squashfs_read_metadata() did not, and the fragment size code just blindly trusted the on-disk value. Fix both the fragment parsing and the metadata reading code.
--- fs/squashfs/cache.c | 3 +++ fs/squashfs/file.c | 8 ++++++-- fs/squashfs/fragment.c | 4 +--- fs/squashfs/squashfs_fs.h | 6 ++++++ 4 files changed, 16 insertions(+), 5 deletions(-)
fs/squashfs/cache.c +3 -0
@@ -350,6 +350,9 @@ int squashfs_read_metadata(struct super_TRACE ("Entered squashfs_read_metadata [%llx:%x]\n" , *block, *offset); +if (unlikely (length <0 )) +return -EIO ; +while (length) { entry =squashfs_cache_get (sb, msblk->block_cache, *block,0 );if (entry->error) {
fs/squashfs/file.c +6 -2
@@ -194,7 +194,11 @@ static long long read_indexes(struct sup }for (i =0 ; i < blocks; i++) { -int size =le32_to_cpu (blist[i]); +int size =squashfs_block_size (blist[i]); +if (size <0 ) { + err = size; + goto failure; + } block +=SQUASHFS_COMPRESSED_SIZE_BLOCK (size); } n -= blocks;
@@ -367,7 +371,7 @@ static int read_blocklist(struct inode * sizeof(size));if (res <0 )return res; -return le32_to_cpu (size); +return squashfs_block_size (size); }/* Copy data into page cache */
fs/squashfs/fragment.c +1 -3
@@ -61,9 +61,7 @@ int squashfs_frag_lookup(struct super_blreturn size; *fragment_block =le64_to_cpu (fragment_entry.start_block); - size =le32_to_cpu (fragment_entry.size); - -return size; +return squashfs_block_size (fragment_entry.size); }
fs/squashfs/squashfs_fs.h +6 -0
@@ -129,6 +129,12 @@#define SQUASHFS_COMPRESSED_BLOCK (B ) (!((B) & SQUASHFS_COMPRESSED_BIT_BLOCK)) +static inline int squashfs_block_size (__le32 raw) +{ +u32 size =le32_to_cpu (raw); +return (size >>25 ) ? -EIO : size; +} +/* * Inode number ops. Inodes consist of a compressed block number, and an * uncompressed offset within that block
Greg Kroah-Hartman
maintainerPATCH 220/246 ext4: fix inline data updates with checksums enabled
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Theodore Ts'o <[email protected]>
commit 362eca70b53389bddf3143fe20f53dcce2cfdf61 upstream.
The inline data code was updating the raw inode directly; this is problematic since if metadata checksums are enabled, ext4_mark_inode_dirty() must be called to update the inode's checksum. In addition, the jbd2 layer requires that get_write_access() be called before the metadata buffer is modified. Fix both of these problems.
https://bugzilla.kernel.org/show_bug.cgi?id=200443
--- fs/ext4/inline.c | 19 +++++++++++-------- fs/ext4/inode.c | 16 +++++++--------- 2 files changed, 18 insertions(+), 17 deletions(-)
fs/ext4/inline.c +11 -8
@@ -688,6 +688,10 @@ int ext4_try_to_write_inline_data(struct goto convert; } + ret =ext4_journal_get_write_access (handle, iloc.bh); +if (ret) + goto out; + flags |=AOP_FLAG_NOFS ; page =grab_cache_page_write_begin (mapping,0 , flags);
@@ -716,7 +720,7 @@ int ext4_try_to_write_inline_data(struct out_up_read:up_read (&EXT4_I (inode)->xattr_sem); out: -if (handle) +if (handle && (ret !=1 ))ext4_journal_stop (handle);brelse (iloc.bh);return ret;
@@ -758,6 +762,7 @@ int ext4_write_inline_data_end(struct inext4_write_unlock_xattr (inode, &no_expand);brelse (iloc.bh); +mark_inode_dirty (inode); out:return copied; }
@@ -904,7 +909,6 @@ retry_journal: goto out; } - page =grab_cache_page_write_begin (mapping,0 , flags);if (!page) { ret = -ENOMEM ;
@@ -922,6 +926,9 @@ retry_journal:if (ret <0 ) goto out_release_page; } + ret =ext4_journal_get_write_access (handle, iloc.bh); +if (ret) + goto out_release_page;up_read (&EXT4_I (inode)->xattr_sem); *pagep = page;
@@ -942,7 +949,6 @@ int ext4_da_write_inline_data_end(struct unsigned len, unsigned copied, struct page *page) { - int i_size_changed = 0; int ret; ret =ext4_write_inline_data_end (inode, pos, len, copied, page);
@@ -960,10 +966,8 @@ int ext4_da_write_inline_data_end(struct* But it's important to update i_size while still holding page lock: * page writeout could otherwise come in and zero beyond i_size. */ -if (pos+copied > inode->i_size) { +if (pos+copied > inode->i_size)i_size_write (inode, pos+copied); - i_size_changed =1 ; - }unlock_page (page);put_page (page);
@@ -973,8 +977,7 @@ int ext4_da_write_inline_data_end(struct* ordering of page lock and transaction start for journaling * filesystems. */ -if (i_size_changed) -mark_inode_dirty (inode); +mark_inode_dirty (inode);return copied; }
fs/ext4/inode.c +7 -9
@@ -1388,9 +1388,10 @@ static int ext4_write_end(struct file *floff_t old_size = inode->i_size;int ret =0 , ret2;int i_size_changed =0 ; +int inline_data =ext4_has_inline_data (inode);trace_ext4_write_end (inode, pos, len, copied); -if (ext4_has_inline_data (inode)) { +if (inline_data) { ret =ext4_write_inline_data_end (inode, pos, len, copied, page);if (ret <0 ) {
@@ -1418,7 +1419,7 @@ static int ext4_write_end(struct file *f* ordering of page lock and transaction start for journaling * filesystems. */ -if (i_size_changed) +if (i_size_changed || inline_data)ext4_mark_inode_dirty (handle, inode);if (pos + len > inode->i_size &&ext4_can_truncate (inode))
@@ -1492,6 +1493,7 @@ static int ext4_journalled_write_end(strint partial =0 ;unsigned from, to;int size_changed =0 ; +int inline_data =ext4_has_inline_data (inode);trace_ext4_journalled_write_end (inode, pos, len, copied); from = pos & (PAGE_SIZE -1 );
@@ -1499,7 +1501,7 @@ static int ext4_journalled_write_end(strBUG_ON (!ext4_handle_valid (handle)); -if (ext4_has_inline_data (inode)) { +if (inline_data) { ret =ext4_write_inline_data_end (inode, pos, len, copied, page);if (ret <0 ) {
@@ -1530,7 +1532,7 @@ static int ext4_journalled_write_end(strif (old_size < pos)pagecache_isize_extended (inode, old_size, pos); -if (size_changed) { +if (size_changed || inline_data) { ret2 =ext4_mark_inode_dirty (handle, inode);if (!ret) ret = ret2;
@@ -2027,11 +2029,7 @@ static int __ext4_journalled_writepage(s }if (inline_data) { -BUFFER_TRACE (inode_bh,"get write access" ); - ret =ext4_journal_get_write_access (handle, inode_bh); - - err =ext4_handle_dirty_metadata (handle, inode, inode_bh); - + ret =ext4_mark_inode_dirty (handle, inode); }else { ret =ext4_walk_page_buffers (handle, page_bufs,0 , len,NULL , do_journal_get_write_access);
Greg Kroah-Hartman
maintainerPATCH 221/246 ext4: check for allocation block validity with block group locked
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Theodore Ts'o <[email protected]>
commit 8d5a803c6a6ce4ec258e31f76059ea5153ba46ef upstream.
With commit 044e6e3d74a3: "ext4: don't update checksum of new initialized bitmaps" the buffer valid bit will get set without actually setting up the checksum for the allocation bitmap, since the checksum will get calculated once we actually allocate an inode or block.
If we are doing this, then we need to (re-)check the verified bit after we take the block group lock. Otherwise, we could race with another process reading and verifying the bitmap, which would then complain about the checksum being invalid.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1780137
--- fs/ext4/balloc.c | 3 +++ fs/ext4/ialloc.c | 3 +++ 2 files changed, 6 insertions(+)
fs/ext4/balloc.c +3 -0
@@ -379,6 +379,8 @@ static int ext4_validate_block_bitmap(streturn -EFSCORRUPTED ;ext4_lock_group (sb, block_group); +if (buffer_verified (bh)) + goto verified;if (unlikely (!ext4_block_bitmap_csum_verify (sb, block_group, desc, bh))) {ext4_unlock_group (sb, block_group);
@@ -401,6 +403,7 @@ static int ext4_validate_block_bitmap(streturn -EFSCORRUPTED ; }set_buffer_verified (bh); +verified:ext4_unlock_group (sb, block_group);return 0 ; }
fs/ext4/ialloc.c +3 -0
@@ -91,6 +91,8 @@ static int ext4_validate_inode_bitmap(streturn -EFSCORRUPTED ;ext4_lock_group (sb, block_group); +if (buffer_verified (bh)) + goto verified; blk =ext4_inode_bitmap (sb, desc);if (!ext4_inode_bitmap_csum_verify (sb, block_group, desc, bh,EXT4_INODES_PER_GROUP (sb) /8 )) {
@@ -108,6 +110,7 @@ static int ext4_validate_inode_bitmap(streturn -EFSBADCRC ; }set_buffer_verified (bh); +verified:ext4_unlock_group (sb, block_group);return 0 ; }
Greg Kroah-Hartman
maintainerPATCH 222/246 ext4: fix check to prevent initializing reserved inodes
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Theodore Ts'o <[email protected]>
commit 5012284700775a4e6e3fbe7eac4c543c4874b559 upstream.
Commit 8844618d8aa7: "ext4: only look at the bg_flags field if it is valid" will complain if block group zero does not have the EXT4_BG_INODE_ZEROED flag set. Unfortunately, this is not correct, since a freshly created file system has this flag cleared. It gets almost immediately after the file system is mounted read-write --- but the following somewhat unlikely sequence will end up triggering a false positive report of a corrupted file system:
mkfs.ext4 /dev/vdc
mount -o ro /dev/vdc /vdc
mount -o remount,rw /dev/vdc
Instead, when initializing the inode table for block group zero, test to make sure that itable_unused count is not too large, since that is the case that will result in some or all of the reserved inodes getting cleared.
This fixes the failures reported by Eric Whiteney when running generic/230 and generic/231 in the the nojournal test case.
--- fs/ext4/ialloc.c | 5 ++++- fs/ext4/super.c | 8 +------- 2 files changed, 5 insertions(+), 8 deletions(-)
fs/ext4/ialloc.c +4 -1
@@ -1397,7 +1397,10 @@ int ext4_init_inode_table(struct super_b ext4_itable_unused_count(sb, gdp)), sbi->s_inodes_per_block); -if ((used_blks <0 ) || (used_blks > sbi->s_itb_per_group)) { +if ((used_blks <0 ) || (used_blks > sbi->s_itb_per_group) || + ((group ==0 ) && ((EXT4_INODES_PER_GROUP (sb) - +ext4_itable_unused_count (sb, gdp)) < +EXT4_FIRST_INO (sb)))) { ext4_error(sb, "Something is wrong with group %u: " "used itable blocks: %d; " "itable unused count: %u",
fs/ext4/super.c +1 -7
@@ -3103,14 +3103,8 @@ static ext4_group_t ext4_has_uninit_itabif (!gdp)continue ; -if (gdp->bg_flags &cpu_to_le16 (EXT4_BG_INODE_ZEROED )) -continue ; -if (group !=0 ) +if (!(gdp->bg_flags &cpu_to_le16 (EXT4_BG_INODE_ZEROED )))break ; -ext4_error (sb,"Inode table for bg 0 marked as " -"needing zeroing" ); -if (sb_rdonly (sb)) -return ngroups; }return group;
Re: [PATCH 4.14 222/246] ext4: fix check to prevent initializing reserved inodes
Quoted 1 line · Greg Kroah-Hartman
4.14-stable review patch. If anyone has any objections, please let me know.
It seems this patch is still missing from the 4.4.y and 4.9.y branches.
Matthias
Quoted 71 lines
------------------
From: Theodore Ts'o <[email protected]>
commit
5012284700775a4e6e3fbe7eac4c543c4874b559upstream.Commit
8844618d8aa7: "ext4: only look at thebg_flagsfield if it is valid" will complain if block group zero does not have theEXT4_BG_INODE_ZEROEDflag set. Unfortunately, this is not correct, since a freshly created file system has this flag cleared. It gets almost immediately after the file system is mounted read-write --- but the following somewhat unlikely sequence will end up triggering a false positive report of a corrupted file system:mkfs.ext4
/dev/vdc
mount -o ro/dev/vdc/vdc
mount -o remount,rw/dev/vdcInstead, when initializing the inode table for block group zero, test to make sure that
itable_unusedcount is not too large, since that is the case that will result in some or all of the reserved inodes getting cleared.This fixes the failures reported by Eric Whiteney when running generic/230 and generic/231 in the the nojournal test case.
Fixes 8844618d8aa7 ("ext4: only look at the bg_flags field if it is valid")Reported-by Eric Whitney <[email protected]>Signed-off-by Theodore Ts'o <[email protected]>Signed-off-by Greg Kroah-Hartman <[email protected]>--- fs/ext4/ialloc.c | 5 ++++- fs/ext4/super.c | 8 +------- 2 files changed, 5 insertions(+), 8 deletions(-)fs/ext4/ialloc.c +4
-1@@ -1397,7 +1397,10 @@ int ext4_init_inode_table(struct super_b ext4_itable_unused_count(sb, gdp)), sbi->s_inodes_per_block); -if ((used_blks <0 ) || (used_blks > sbi->s_itb_per_group)) { +if ((used_blks <0 ) || (used_blks > sbi->s_itb_per_group) || + ((group ==0 ) && ((EXT4_INODES_PER_GROUP (sb) - +ext4_itable_unused_count (sb, gdp)) < +EXT4_FIRST_INO (sb)))) { ext4_error(sb, "Something is wrong with group %u: " "used itable blocks: %d; " "itable unused count: %u",fs/ext4/super.c +1
-7@@ -3103,14 +3103,8 @@ static ext4_group_t ext4_has_uninit_itabif (!gdp)continue ; -if (gdp->bg_flags &cpu_to_le16 (EXT4_BG_INODE_ZEROED )) -continue ; -if (group !=0 ) +if (!(gdp->bg_flags &cpu_to_le16 (EXT4_BG_INODE_ZEROED )))break ; -ext4_error (sb,"Inode table for bg 0 marked as " -"needing zeroing" ); -if (sb_rdonly (sb)) -return ngroups; }return group;
Greg Kroah-Hartman
maintainerRe: [PATCH 4.14 222/246] ext4: fix check to prevent initializing reserved inodes
Quoted 4 lines · Matthias Schiffer
Quoted 1 line · Greg Kroah-Hartman
4.14-stable review patch. If anyone has any objections, please let me know.
It seems this patch is still missing from the 4.4.y and 4.9.y branches.
Maybe because no one has provided a working backport? :)
Re: [PATCH 4.14 222/246] ext4: fix check to prevent initializing reserved inodes
Quoted 7 lines · Greg Kroah-Hartman
Quoted 4 lines · Matthias Schiffer
Quoted 1 line · Greg Kroah-Hartman
4.14-stable review patch. If anyone has any objections, please let me know.
It seems this patch is still missing from the 4.4.y and 4.9.y branches.
Maybe because no one has provided a working backport? :)
Here you go....
- Ted
From c489f091a4b8ef4835146a6bb9a77cfc31055cd4 Mon Sep 17 00:00:00 2001
From: Theodore Ts'o <[email protected]>
Date: Sat, 28 Jul 2018 08:12:04 -0400
Subject: [PATCH] ext4: fix check to prevent initializing reserved inodes
Commit 5012284700775a4e6e3fbe7eac4c543c4874b559 upstream.
Commit 8844618d8aa7: "ext4: only look at the bg_flags field if it is valid" will complain if block group zero does not have the EXT4_BG_INODE_ZEROED flag set. Unfortunately, this is not correct, since a freshly created file system has this flag cleared. It gets almost immediately after the file system is mounted read-write --- but the following somewhat unlikely sequence will end up triggering a false positive report of a corrupted file system:
mkfs.ext4 /dev/vdc
mount -o ro /dev/vdc /vdc
mount -o remount,rw /dev/vdc
Instead, when initializing the inode table for block group zero, test to make sure that itable_unused count is not too large, since that is the case that will result in some or all of the reserved inodes getting cleared.
This fixes the failures reported by Eric Whiteney when running generic/230 and generic/231 in the the nojournal test case.
--- fs/ext4/ialloc.c | 5 ++++- fs/ext4/super.c | 8 +------- 2 files changed, 5 insertions(+), 8 deletions(-)
fs/ext4/ialloc.c +4 -1
@@ -1316,7 +1316,10 @@ int ext4_init_inode_table(struct super_block *sb, ext4_group_t group, ext4_itable_unused_count(sb, gdp)), sbi->s_inodes_per_block); -if ((used_blks <0 ) || (used_blks > sbi->s_itb_per_group)) { +if ((used_blks <0 ) || (used_blks > sbi->s_itb_per_group) || + ((group ==0 ) && ((EXT4_INODES_PER_GROUP (sb) - +ext4_itable_unused_count (sb, gdp)) < +EXT4_FIRST_INO (sb)))) { ext4_error(sb, "Something is wrong with group %u: " "used itable blocks: %d; " "itable unused count: %u",
fs/ext4/super.c +1 -7
@@ -3031,14 +3031,8 @@ static ext4_group_t ext4_has_uninit_itable(struct super_block *sb)if (!gdp)continue ; -if (gdp->bg_flags &cpu_to_le16 (EXT4_BG_INODE_ZEROED )) -continue ; -if (group !=0 ) +if (!(gdp->bg_flags &cpu_to_le16 (EXT4_BG_INODE_ZEROED )))break ; -ext4_error (sb,"Inode table for bg 0 marked as " -"needing zeroing" ); -if (sb->s_flags &MS_RDONLY ) -return ngroups; }return group;
Signature · 1 line
2.18.0.rc0
Greg Kroah-Hartman
maintainerPATCH 223/246 PCI: pciehp: Assume NoCompl+ for Thunderbolt ports
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lukas Wunner <[email protected]>
commit 493fb50e958c1c6deef7feff0b8c3855def78d75 upstream.
Certain Thunderbolt 1 controllers claim to support Command Completed events (value of 0b in the No Command Completed Support field of the Slot Capabilities register) but in reality they neither set the Command Completed bit in the Slot Status register nor signal a Command Completed interrupt:
8086:1513 CV82524 [Light Ridge 4C 2010] 8086:151a DSL2310 [Eagle Ridge 2C 2011] 8086:151b CVL2510 [Light Peak 2C 2010] 8086:1547 DSL3510 [Cactus Ridge 4C 2012] 8086:1548 DSL3310 [Cactus Ridge 2C 2012] 8086:1549 DSL2210 [Port Ridge 1C 2011]
All known newer chips (Redwood Ridge and onwards) set No Command Completed Support, indicating that they do not support Command Completed events.
The user-visible impact is that after unplugging such a device, 2 seconds elapse until pciehp is unbound. That's because on ->remove, pcie_write_cmd() is called via pcie_disable_notification() and every call to pcie_write_cmd() takes 2 seconds (1 second for each invocation of pcie_wait_cmd()):
[ 337.942727] pciehp 0000:0a:00.0:pcie204: Timeout on hotplug command 0x1038 (issued 21176 msec ago) [ 340.014735] pciehp 0000:0a:00.0:pcie204: Timeout on hotplug command 0x0000 (issued 2072 msec ago)
That by itself has always been unpleasant, but the situation has become worse with commit cc27b735ad3a ("PCI/portdrv: Turn off PCIe services during shutdown"): Now pciehp is unbound on ->shutdown. Because Thunderbolt controllers typically have 4 hotplug ports, every reboot and shutdown is now delayed by 8 seconds, plus another 2 seconds for every attached Thunderbolt 1 device.
Thunderbolt hotplug slots are not physical slots that one inserts cards into, but rather logical hotplug slots implemented in silicon. Devices appear beyond those logical slots once a PCI tunnel is established on top of the Thunderbolt Converged I/O switch. One would expect commands written to the Slot Control register to be executed immediately by the silicon, so for simplicity we always assume NoCompl+ for Thunderbolt ports.
--- drivers/pci/hotplug/pciehp_hpc.c | 7 +++++++ 1 file changed, 7 insertions(+)
drivers/pci/hotplug/pciehp_hpc.c +7 -0
@@ -863,6 +863,13 @@ struct controller *pcie_init(struct pcieif (pdev->hotplug_user_indicators) slot_cap &= ~(PCI_EXP_SLTCAP_AIP |PCI_EXP_SLTCAP_PIP ); +/* +* We assume no Thunderbolt controllers support Command Complete events, +* but some controllers falsely claim they do. +*/ +if (pdev->is_thunderbolt) + slot_cap |=PCI_EXP_SLTCAP_NCCS ; + ctrl->slot_cap = slot_cap;mutex_init (&ctrl->ctrl_lock);init_waitqueue_head (&ctrl->queue);
Greg Kroah-Hartman
maintainerPATCH 224/246 PCI: xgene: Remove leftover pci_scan_child_bus() call
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lorenzo Pieralisi <[email protected]>
commit 94b9d290b753cbbc87971ee134511245f5872a83 upstream.
The changes in commit 9af275be15f7 ("PCI: xgene: Convert PCI scan API to pci_scan_root_bus_bridge()") converted the xgene PCI host driver to the new pci_scan_root_bus_bridge() bus scanning API but erroneously left the existing pci_scan_child_bus() call in place which resulted in duplicate PCI bus enumerations.
Remove the leftover pci_scan_child_bus() call to properly complete the API conversion.
--- drivers/pci/host/pci-xgene.c | 1 - 1 file changed, 1 deletion(-)
drivers/pci/host/pci-xgene.c +0 -1
@@ -686,7 +686,6 @@ static int xgene_pcie_probe_bridge(struc bus = bridge->bus; -pci_scan_child_bus (bus);pci_assign_unassigned_bus_resources (bus);list_for_each_entry (child, &bus->children, node)pcie_bus_configure_settings (child);
Greg Kroah-Hartman
maintainerPATCH 225/246 ovl: Sync upper dirty data when syncing overlayfs
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Chengguang Xu <[email protected]>
commit e8d4bfe3a71537284a90561f77c85dea6c154369 upstream.
When executing filesystem sync or umount on overlayfs, dirty data does not get synced as expected on upper filesystem. This patch fixes sync filesystem method to keep data consistency for overlayfs.
--- fs/overlayfs/super.c | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-)
fs/overlayfs/super.c +15 -4
@@ -232,6 +232,7 @@ static void ovl_put_super(struct super_bkfree (ufs); } +/* Sync real dirty inodes in upper filesystem (if it exists) */ static int ovl_sync_fs (struct super_block *sb,int wait) {struct ovl_fs *ufs = sb->s_fs_info;
@@ -240,14 +241,24 @@ static int ovl_sync_fs(struct super_blocif (!ufs->upper_mnt)return 0 ; - upper_sb = ufs->upper_mnt->mnt_sb; -if (!upper_sb->s_op->sync_fs) + +/* +* If this is a sync(2) call or an emergency sync, all the super blocks +* will be iterated, including upper_sb, so no need to do anything. +* +* If this is a syncfs(2) call, then we do need to call +* sync_filesystem() on upper_sb, but enough if we do it when being +* called with wait == 1. +*/ +if (!wait)return 0 ; -/* real inodes have already been synced by sync_filesystem(ovl_sb) */ + upper_sb = ufs->upper_mnt->mnt_sb; +down_read (&upper_sb->s_umount); - ret = upper_sb->s_op->sync_fs (upper_sb, wait); + ret =sync_filesystem (upper_sb);up_read (&upper_sb->s_umount); +return ret; }
Greg Kroah-Hartman
maintainerPATCH 226/246 usb: gadget: udc: renesas_usb3: should remove debugfs
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yoshihiro Shimoda <[email protected]>
commit 1990cf7c21ea185cec98c6d45a82c04481261e35 upstream.
This patch fixes an issue that this driver doesn't remove its debugfs.
--- drivers/usb/gadget/udc/renesas_usb3.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
drivers/usb/gadget/udc/renesas_usb3.c +7 -1
@@ -334,6 +334,7 @@ struct renesas_usb3 {struct usb_gadget_driver *driver;struct extcon_dev *extcon;struct work_struct extcon_work; +struct dentry *dentry;struct renesas_usb3_ep *usb3_ep;int num_usb3_eps;
@@ -2397,8 +2398,12 @@ static void renesas_usb3_debugfs_init(st file =debugfs_create_file ("b_device" ,0644 , root, usb3, &renesas_usb3_b_device_fops); -if (!file) +if (!file) {dev_info (dev,"%s: Can't create debugfs mode\n" , __func__); +debugfs_remove_recursive (root); + }else { + usb3->dentry = root; + } }/*------- platform_driver ------------------------------------------------*/
@@ -2406,6 +2411,7 @@ static int renesas_usb3_remove(struct pl {struct renesas_usb3 *usb3 =platform_get_drvdata (pdev); +debugfs_remove_recursive (usb3->dentry);device_remove_file (&pdev->dev, &dev_attr_role);usb_del_gadget_udc (&usb3->gadget);
Greg Kroah-Hartman
maintainerPATCH 227/246 RDMA/uverbs: Protect from attempts to create flows on unsupported QP
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Leon Romanovsky <[email protected]>
commit 940efcc8889f0d15567eb07fc9fd69b06e366aa5 upstream.
Flows can be created on UD and RAW_PACKET QP types. Attempts to provide other QP types as an input causes to various unpredictable failures.
The reason is that in order to support all various types (e.g. XRC), we are supposed to use real_qp handle and not qp handle and expect to driver/FW to fail such (XRC) flows. The simpler and safer variant is to ban all QP types except UD and RAW_PACKET, instead of relying on driver/FW.
--- drivers/infiniband/core/uverbs_cmd.c | 5 +++++ 1 file changed, 5 insertions(+)
drivers/infiniband/core/uverbs_cmd.c +5 -0
@@ -3376,6 +3376,11 @@ int ib_uverbs_ex_create_flow(struct ib_u goto err_uobj; } +if (qp->qp_type !=IB_QPT_UD && qp->qp_type !=IB_QPT_RAW_PACKET ) { + err = -EINVAL ; + goto err_put; + } + flow_attr =kzalloc (sizeof (*flow_attr) + cmd.flow_attr.num_of_specs *sizeof (union ib_flow_spec ),GFP_KERNEL );if (!flow_attr) {
Greg Kroah-Hartman
maintainerPATCH 232/246 ipv4: remove BUG_ON() from fib_compute_spec_dst
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Lorenzo Bianconi <[email protected]>
[ Upstream commit 9fc12023d6f51551d6ca9ed7e02ecc19d79caf17 ]
Remove BUG_ON() from fib_compute_spec_dst routine and check in_dev pointer during flowi4 data structure initialization. fib_compute_spec_dst routine can be run concurrently with device removal where ip_ptr net_device pointer is set to NULL. This can happen if userspace enables pkt info on UDP rx socket and the device is removed while traffic is flowing
--- net/ipv4/fib_frontend.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
net/ipv4/fib_frontend.c +2 -2
@@ -282,19 +282,19 @@ __be32 fib_compute_spec_dst(struct sk_bureturn ip_hdr (skb)->daddr; in_dev =__in_dev_get_rcu (dev); -BUG_ON (!in_dev); net =dev_net (dev); scope =RT_SCOPE_UNIVERSE ;if (!ipv4_is_zeronet (ip_hdr (skb)->saddr)) { +bool vmark = in_dev &&IN_DEV_SRC_VMARK (in_dev);struct flowi4 fl4 = { .flowi4_iif =LOOPBACK_IFINDEX , .flowi4_oif =l3mdev_master_ifindex_rcu (dev), .daddr =ip_hdr (skb)->saddr, .flowi4_tos =RT_TOS (ip_hdr (skb)->tos), .flowi4_scope = scope, - .flowi4_mark =IN_DEV_SRC_VMARK (in_dev) ? skb->mark :0 , + .flowi4_mark = vmark ? skb->mark :0 , };if (!fib_lookup (net, &fl4, &res,0 ))return FIB_RES_PREFSRC (net, res);
Greg Kroah-Hartman
maintainerPATCH 233/246 net: ena: Fix use of uninitialized DMA address bits field
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Gal Pressman <[email protected]>
[ Upstream commit 101f0cd4f2216d32f1b8a75a2154cf3997484ee2 ]
UBSAN triggers the following undefined behaviour warnings:
[...]
[ 13.236124] UBSAN: Undefined behaviour in drivers/net/ethernet/amazon/ena/ena_eth_com.c:468:22 [ 13.240043] shift exponent 64 is too large for 64-bit type 'long long unsigned int' [...] [ 13.744769] UBSAN: Undefined behaviour in drivers/net/ethernet/amazon/ena/ena_eth_com.c:373:4 [ 13.748694] shift exponent 64 is too large for 64-bit type 'long long unsigned int'
[...]
When splitting the address to high and low, GENMASK_ULL is used to generate a bitmask with dma_addr_bits field from io_sq (in ena_com_prepare_tx and ena_com_add_single_rx_desc).
The problem is that dma_addr_bits is not initialized with a proper value (besides being cleared in ena_com_create_io_queue).
Assign dma_addr_bits the correct value that is stored in ena_dev when initializing the SQ.
--- drivers/net/ethernet/amazon/ena/ena_com.c | 1 + 1 file changed, 1 insertion(+)
drivers/net/ethernet/amazon/ena/ena_com.c +1 -0
@@ -331,6 +331,7 @@ static int ena_com_init_io_sq(struct enamemset (&io_sq->desc_addr,0x0 ,sizeof (io_sq->desc_addr)); + io_sq->dma_addr_bits = ena_dev->dma_addr_bits; io_sq->desc_entry_size = (io_sq->direction ==ENA_COM_IO_QUEUE_DIRECTION_TX ) ? sizeof(struct ena_eth_io_tx_desc) :
Greg Kroah-Hartman
maintainerPATCH 234/246 net: fix amd-xgbe flow-control issue
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: tangpengpeng <[email protected]>
[ Upstream commit 7f3fc7ddf719cd6faaf787722c511f6918ac6aab ]
If we enable or disable xgbe flow-control by ethtool , it does't work.Because the parameter is not properly assigned,so we need to adjust the assignment order of the parameters.
--- drivers/net/ethernet/amd/xgbe/xgbe-mdio.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/ethernet/amd/xgbe/xgbe-mdio.c +2 -2
@@ -1128,14 +1128,14 @@ static void xgbe_phy_adjust_link(structif (pdata->tx_pause != pdata->phy.tx_pause) { new_state =1 ; - pdata->hw_if.config_tx_flow_control (pdata); pdata->tx_pause = pdata->phy.tx_pause; + pdata->hw_if.config_tx_flow_control (pdata); }if (pdata->rx_pause != pdata->phy.rx_pause) { new_state =1 ; - pdata->hw_if.config_rx_flow_control (pdata); pdata->rx_pause = pdata->phy.rx_pause; + pdata->hw_if.config_rx_flow_control (pdata); }/* Speed support */
Greg Kroah-Hartman
maintainerPATCH 235/246 net: lan78xx: fix rx handling before first packet is send
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Stefan Wahren <[email protected]>
[ Upstream commit 136f55f660192ce04af091642efc75d85e017364 ]
As long the bh tasklet isn't scheduled once, no packet from the rx path will be handled. Since the tx path also schedule the same tasklet this situation only persits until the first packet transmission. So fix this issue by scheduling the tasklet after link reset.
--- drivers/net/usb/lan78xx.c | 2 ++ 1 file changed, 2 insertions(+)
drivers/net/usb/lan78xx.c +2 -0
@@ -1216,6 +1216,8 @@ static int lan78xx_link_reset(struct lanmod_timer (&dev->stat_monitor, jiffies +STAT_UPDATE_TIMER ); } + +tasklet_schedule (&dev->bh); }return ret;
Greg Kroah-Hartman
maintainerPATCH 236/246 net: mdio-mux: bcm-iproc: fix wrong getter and setter pair
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Anton Vasilyev <[email protected]>
[ Upstream commit b0753408aadf32c7ece9e6b765017881e54af833 ]
mdio_mux_iproc_probe() uses platform_set_drvdata() to store md pointer in device, whereas mdio_mux_iproc_remove() restores md pointer by dev_get_platdata(&pdev->dev). This leads to wrong resources release.
The patch replaces getter to platform_get_drvdata.
--- drivers/net/phy/mdio-mux-bcm-iproc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/phy/mdio-mux-bcm-iproc.c +1 -1
@@ -218,7 +218,7 @@ out:static int mdio_mux_iproc_remove (struct platform_device *pdev) { -struct iproc_mdiomux_desc *md =dev_get_platdata (&pdev->dev); +struct iproc_mdiomux_desc *md =platform_get_drvdata (pdev);mdio_mux_uninit (md->mux_handle);mdiobus_unregister (md->mii_bus);
Greg Kroah-Hartman
maintainerPATCH 237/246 NET: stmmac: align DMA stuff to largest cache line length
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eugeniy Paltsev <[email protected]>
[ Upstream commit 9939a46d90c6c76f4533d534dbadfa7b39dc6acc ]
As for today STMMAC_ALIGN macro (which is used to align DMA stuff) relies on L1 line length (L1_CACHE_BYTES).
This isn't correct in case of system with several cache levels which might have L1 cache line length smaller than L2 line. This can lead to sharing one cache line between DMA buffer and other data, so we can lose this data while invalidate DMA buffer before DMA transaction.
Fix that by using SMP_CACHE_BYTES instead of L1_CACHE_BYTES for aligning.
--- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +1 -1
@@ -51,7 +51,7 @@#include <linux/of_mdio.h> #include "dwmac1000.h" -#define STMMAC_ALIGN (x) L1_CACHE_ALIGN(x) +#define STMMAC_ALIGN (x) __ALIGN_KERNEL(x, SMP_CACHE_BYTES)#define TSO_MAX_BUFF_SIZE (SZ_16K - 1)/* Module parameters */
Greg Kroah-Hartman
maintainerPATCH 238/246 tcp_bbr: fix bw probing to raise in-flight data for very small BDPs
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Neal Cardwell <[email protected]>
[ Upstream commit 383d470936c05554219094a4d364d964cb324827 ]
For some very small BDPs (with just a few packets) there was a quantization effect where the target number of packets in flight during the super-unity-gain (1.25x) phase of gain cycling was implicitly truncated to a number of packets no larger than the normal unity-gain (1.0x) phase of gain cycling. This meant that in multi-flow scenarios some flows could get stuck with a lower bandwidth, because they did not push enough packets inflight to discover that there was more bandwidth available. This was really only an issue in multi-flow LAN scenarios, where RTTs and BDPs are low enough for this to be an issue.
This fix ensures that gain cycling can raise inflight for small BDPs by ensuring that in PROBE_BW mode target inflight values with a super-unity gain are always greater than inflight values with a gain <= 1. Importantly, this applies whether the inflight value is calculated for use as a cwnd value, or as a target inflight value for the end of the super-unity phase in bbr_is_next_cycle_phase() (both need to be bigger to ensure we can probe with more packets in flight reliably).
This is a candidate fix for stable releases.
--- net/ipv4/tcp_bbr.c | 4 ++++ 1 file changed, 4 insertions(+)
net/ipv4/tcp_bbr.c +4 -0
@@ -353,6 +353,10 @@ static u32 bbr_target_cwnd(struct sock */* Reduce delayed ACKs by rounding up cwnd to the next even number. */ cwnd = (cwnd +1 ) & ~1U ; +/* Ensure gain cycling gets inflight above BDP even for small BDPs. */ +if (bbr->mode ==BBR_PROBE_BW && gain >BBR_UNIT ) + cwnd +=2 ; +return cwnd; }
Greg Kroah-Hartman
maintainerPATCH 239/246 xen-netfront: wait xenbus state change when load module manually
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Xiao Liang <[email protected]>
[ Upstream commit 822fb18a82abaf4ee7058793d95d340f5dab7bfc ]
When loading module manually, after call xenbus_switch_state to initializes the state of the netfront device, the driver state did not change so fast that may lead no dev created in latest kernel. This patch adds wait to make sure xenbus knows the driver is not in closed/unknown state.
Current state:
[vm]# ethtool eth0
Settings for eth0:
Link detected: yes
[vm]# modprobe -r xen_netfront
[vm]# modprobe xen_netfront
[vm]# ethtool eth0
Settings for eth0:
Cannot get device settings: No such device
Cannot get wake-on-lan settings: No such device
Cannot get message level: No such device
Cannot get link status: No such device
No data available
With the patch installed.
[vm]# ethtool eth0
Settings for eth0:
Link detected: yes
[vm]# modprobe -r xen_netfront
[vm]# modprobe xen_netfront
[vm]# ethtool eth0
Settings for eth0:
Link detected: yes
--- drivers/net/xen-netfront.c | 6 ++++++ 1 file changed, 6 insertions(+)
drivers/net/xen-netfront.c +6 -0
@@ -87,6 +87,7 @@ struct netfront_cb {/* IRQ name is queue name with "-tx" or "-rx" appended */ #define IRQ_NAME_SIZE (QUEUE_NAME_SIZE + 3) +static DECLARE_WAIT_QUEUE_HEAD (module_load_q);static DECLARE_WAIT_QUEUE_HEAD (module_unload_q);struct netfront_stats {
@@ -1330,6 +1331,11 @@ static struct net_device *xennet_create_netif_carrier_off (netdev);xenbus_switch_state (dev, XenbusStateInitialising); +wait_event (module_load_q, +xenbus_read_driver_state (dev->otherend) != + XenbusStateClosed && +xenbus_read_driver_state (dev->otherend) != + XenbusStateUnknown);return netdev; exit:
Greg Kroah-Hartman
maintainerPATCH 240/246 netlink: Do not subscribe to non-existent groups
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dmitry Safonov <[email protected]>
[ Upstream commit 7acf9d4237c46894e0fa0492dd96314a41742e84 ]
Make ABI more strict about subscribing to group > ngroups. Code doesn't check for that and it looks bogus.
(one can subscribe to non-existing group)
Still, it's possible to bind() to all possible groups with (-1)
--- net/netlink/af_netlink.c | 1 + 1 file changed, 1 insertion(+)
net/netlink/af_netlink.c +1 -0
@@ -976,6 +976,7 @@ static int netlink_bind(struct socket *sif (err)return err; } + groups &= (1UL << nlk->ngroups) -1 ; bound = nlk->bound;if (bound) {
Greg Kroah-Hartman
maintainerPATCH 241/246 netlink: Dont shift with UB on nlk->ngroups
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Dmitry Safonov <[email protected]>
[ Upstream commit 61f4b23769f0cc72ae62c9a81cf08f0397d40da8 ]
On i386 nlk->ngroups might be 32 or 0. Which leads to UB, resulting in hang during boot.
Check for 0 ngroups and use (unsigned long long) as a type to shift.
--- net/netlink/af_netlink.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
net/netlink/af_netlink.c +5 -1
@@ -976,7 +976,11 @@ static int netlink_bind(struct socket *sif (err)return err; } - groups &= (1UL << nlk->ngroups) -1 ; + +if (nlk->ngroups ==0 ) + groups =0 ; +else + groups &= (1ULL << nlk->ngroups) -1 ; bound = nlk->bound;if (bound) {
Greg Kroah-Hartman
maintainerPATCH 242/246 tcp: do not force quickack when receiving out-of-order packets
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit a3893637e1eb0ef5eb1bbc52b3a8d2dfa317a35d ]
As explained in commit 9f9843a751d0 ("tcp: properly handle stretch acks in slow start"), TCP stacks have to consider how many packets are acknowledged in one single ACK, because of GRO, but also because of ACK compression or losses.
We plan to add SACK compression in the following patch, we must therefore not call tcp_enter_quickack_mode()
--- net/ipv4/tcp_input.c | 2 -- 1 file changed, 2 deletions(-)
net/ipv4/tcp_input.c +0 -2
@@ -4721,8 +4721,6 @@ drop:if (!before (TCP_SKB_CB (skb)->seq, tp->rcv_nxt +tcp_receive_window (tp))) goto out_of_window; -tcp_enter_quickack_mode (sk); -if (before (TCP_SKB_CB (skb)->seq, tp->rcv_nxt)) {/* Partial packet, seq < rcv_next < end_seq */ SOCK_DEBUG(sk, "partial packet: rcv_next %X seq %X - %X\n",
Greg Kroah-Hartman
maintainerPATCH 243/246 tcp: add max_quickacks param to tcp_incr_quickack and tcp_enter_quickack_mode
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 9a9c9b51e54618861420093ae6e9b50a961914c5 ]
We want to add finer control of the number of ACK packets sent after ECN events.
This patch is not changing current behavior, it only enables following change.
--- include/net/tcp.h | 2 +- net/ipv4/tcp_dctcp.c | 4 ++-- net/ipv4/tcp_input.c | 24 +++++++++++++----------- 3 files changed, 16 insertions(+), 14 deletions(-)
include/net/tcp.h +1 -1
@@ -372,7 +372,7 @@ ssize_t tcp_splice_read(struct socket *s struct pipe_inode_info *pipe, size_t len, unsigned int flags); -void tcp_enter_quickack_mode (struct sock *sk); +void tcp_enter_quickack_mode (struct sock *sk,unsigned int max_quickacks);static inline void tcp_dec_quickack_mode (struct sock *sk,const unsigned int pkts) {
net/ipv4/tcp_dctcp.c +2 -2
@@ -138,7 +138,7 @@ static void dctcp_ce_state_0_to_1(struct*/ if (inet_csk (sk)->icsk_ack.pending &ICSK_ACK_TIMER )__tcp_send_ack (sk, ca->prior_rcv_nxt); -tcp_enter_quickack_mode (sk); +tcp_enter_quickack_mode (sk,1 ); } ca->prior_rcv_nxt = tp->rcv_nxt;
@@ -159,7 +159,7 @@ static void dctcp_ce_state_1_to_0(struct*/ if (inet_csk (sk)->icsk_ack.pending &ICSK_ACK_TIMER )__tcp_send_ack (sk, ca->prior_rcv_nxt); -tcp_enter_quickack_mode (sk); +tcp_enter_quickack_mode (sk,1 ); } ca->prior_rcv_nxt = tp->rcv_nxt;
net/ipv4/tcp_input.c +13 -11
@@ -198,21 +198,23 @@ static void tcp_measure_rcv_mss(struct s } } -static void tcp_incr_quickack (struct sock *sk) +static void tcp_incr_quickack (struct sock *sk,unsigned int max_quickacks) {struct inet_connection_sock *icsk =inet_csk (sk);unsigned int quickacks =tcp_sk (sk)->rcv_wnd / (2 * icsk->icsk_ack.rcv_mss);if (quickacks ==0 ) quickacks =2 ; + quickacks =min (quickacks, max_quickacks);if (quickacks > icsk->icsk_ack.quick) - icsk->icsk_ack.quick =min (quickacks,TCP_MAX_QUICKACKS ); + icsk->icsk_ack.quick = quickacks; } -void tcp_enter_quickack_mode (struct sock *sk) +void tcp_enter_quickack_mode (struct sock *sk,unsigned int max_quickacks) {struct inet_connection_sock *icsk =inet_csk (sk); -tcp_incr_quickack (sk); + +tcp_incr_quickack (sk, max_quickacks); icsk->icsk_ack.pingpong =0 ; icsk->icsk_ack.ato =TCP_ATO_MIN ; }
@@ -257,7 +259,7 @@ static void __tcp_ecn_check_ce(struct tc* it is probably a retransmit. */ if (tp->ecn_flags &TCP_ECN_SEEN ) -tcp_enter_quickack_mode ((struct sock *)tp); +tcp_enter_quickack_mode ((struct sock *)tp,TCP_MAX_QUICKACKS );break ;case INET_ECN_CE :if (tcp_ca_needs_ecn ((struct sock *)tp))
@@ -265,7 +267,7 @@ static void __tcp_ecn_check_ce(struct tcif (!(tp->ecn_flags &TCP_ECN_DEMAND_CWR )) {/* Better not delay acks, sender can have a very low cwnd */ -tcp_enter_quickack_mode ((struct sock *)tp); +tcp_enter_quickack_mode ((struct sock *)tp,TCP_MAX_QUICKACKS ); tp->ecn_flags |=TCP_ECN_DEMAND_CWR ; } tp->ecn_flags |=TCP_ECN_SEEN ;
@@ -686,7 +688,7 @@ static void tcp_event_data_recv(struct s/* The _first_ data packet received, initialize * delayed ACK engine. */ -tcp_incr_quickack (sk); +tcp_incr_quickack (sk,TCP_MAX_QUICKACKS ); icsk->icsk_ack.ato =TCP_ATO_MIN ; }else {int m = now - icsk->icsk_ack.lrcvtime;
@@ -702,7 +704,7 @@ static void tcp_event_data_recv(struct s/* Too long gap. Apparently sender failed to * restart window, so that we send ACKs quickly. */ -tcp_incr_quickack (sk); +tcp_incr_quickack (sk,TCP_MAX_QUICKACKS );sk_mem_reclaim (sk); } }
@@ -4160,7 +4162,7 @@ static void tcp_send_dupack(struct sockif (TCP_SKB_CB (skb)->end_seq !=TCP_SKB_CB (skb)->seq &&before (TCP_SKB_CB (skb)->seq, tp->rcv_nxt)) {NET_INC_STATS (sock_net (sk),LINUX_MIB_DELAYEDACKLOST ); -tcp_enter_quickack_mode (sk); +tcp_enter_quickack_mode (sk,TCP_MAX_QUICKACKS );if (tcp_is_sack (tp) && sysctl_tcp_dsack) {u32 end_seq =TCP_SKB_CB (skb)->end_seq;
@@ -4710,7 +4712,7 @@ queue_and_out:tcp_dsack_set (sk,TCP_SKB_CB (skb)->seq,TCP_SKB_CB (skb)->end_seq); out_of_window: -tcp_enter_quickack_mode (sk); +tcp_enter_quickack_mode (sk,TCP_MAX_QUICKACKS );inet_csk_schedule_ack (sk); drop:tcp_drop (sk, skb);
@@ -5791,7 +5793,7 @@ static int tcp_rcv_synsent_state_process* to stand against the temptation 8) --ANK */ inet_csk_schedule_ack (sk); -tcp_enter_quickack_mode (sk); +tcp_enter_quickack_mode (sk,TCP_MAX_QUICKACKS );inet_csk_reset_xmit_timer (sk,ICSK_TIME_DACK ,TCP_DELACK_MAX ,TCP_RTO_MAX );
Greg Kroah-Hartman
maintainerPATCH 244/246 tcp: do not aggressively quick ack after ECN events
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 522040ea5fdd1c33bbf75e1d7c7c0422b96a94ef ]
ECN signals currently forces TCP to enter quickack mode for up to 16 (TCP_MAX_QUICKACKS) following incoming packets.
We believe this is not needed, and only sending one immediate ack for the current packet should be enough.
This should reduce the extra load noticed in DCTCP environments, after congestion events.
This is part 2 of our effort to reduce pure ACK packets.
--- net/ipv4/tcp_input.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
net/ipv4/tcp_input.c +2 -2
@@ -259,7 +259,7 @@ static void __tcp_ecn_check_ce(struct tc* it is probably a retransmit. */ if (tp->ecn_flags &TCP_ECN_SEEN ) -tcp_enter_quickack_mode ((struct sock *)tp,TCP_MAX_QUICKACKS ); +tcp_enter_quickack_mode ((struct sock *)tp,1 );break ;case INET_ECN_CE :if (tcp_ca_needs_ecn ((struct sock *)tp))
@@ -267,7 +267,7 @@ static void __tcp_ecn_check_ce(struct tcif (!(tp->ecn_flags &TCP_ECN_DEMAND_CWR )) {/* Better not delay acks, sender can have a very low cwnd */ -tcp_enter_quickack_mode ((struct sock *)tp,TCP_MAX_QUICKACKS ); +tcp_enter_quickack_mode ((struct sock *)tp,1 ); tp->ecn_flags |=TCP_ECN_DEMAND_CWR ; } tp->ecn_flags |=TCP_ECN_SEEN ;
Greg Kroah-Hartman
maintainerPATCH 245/246 tcp: refactor tcp_ecn_check_ce to remove sk type cast
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Yousuk Seung <[email protected]>
[ Upstream commit f4c9f85f3b2cb7669830cd04d0be61192a4d2436 ]
Refactor tcp_ecn_check_ce and __tcp_ecn_check_ce to accept struct sock* instead of tcp_sock* to clean up type casts. This is a pure refactor patch.
--- net/ipv4/tcp_input.c | 26 ++++++++++++++------------ 1 file changed, 14 insertions(+), 12 deletions(-)
net/ipv4/tcp_input.c +14 -12
@@ -250,8 +250,10 @@ static void tcp_ecn_withdraw_cwr(struct tp->ecn_flags &= ~TCP_ECN_DEMAND_CWR ; } -static void __tcp_ecn_check_ce (struct tcp_sock *tp,const struct sk_buff *skb) +static void __tcp_ecn_check_ce (struct sock *sk,const struct sk_buff *skb) { +struct tcp_sock *tp =tcp_sk (sk); +switch (TCP_SKB_CB (skb)->ip_dsfield &INET_ECN_MASK ) {case INET_ECN_NOT_ECT :/* Funny extension: if ECT is not set on a segment,
@@ -259,31 +261,31 @@ static void __tcp_ecn_check_ce(struct tc* it is probably a retransmit. */ if (tp->ecn_flags &TCP_ECN_SEEN ) -tcp_enter_quickack_mode ((struct sock *)tp,1 ); +tcp_enter_quickack_mode (sk,1 );break ;case INET_ECN_CE : -if (tcp_ca_needs_ecn ((struct sock *)tp)) -tcp_ca_event ((struct sock *)tp,CA_EVENT_ECN_IS_CE ); +if (tcp_ca_needs_ecn (sk)) +tcp_ca_event (sk,CA_EVENT_ECN_IS_CE );if (!(tp->ecn_flags &TCP_ECN_DEMAND_CWR )) {/* Better not delay acks, sender can have a very low cwnd */ -tcp_enter_quickack_mode ((struct sock *)tp,1 ); +tcp_enter_quickack_mode (sk,1 ); tp->ecn_flags |=TCP_ECN_DEMAND_CWR ; } tp->ecn_flags |=TCP_ECN_SEEN ;break ;default : -if (tcp_ca_needs_ecn ((struct sock *)tp)) -tcp_ca_event ((struct sock *)tp,CA_EVENT_ECN_NO_CE ); +if (tcp_ca_needs_ecn (sk)) +tcp_ca_event (sk,CA_EVENT_ECN_NO_CE ); tp->ecn_flags |=TCP_ECN_SEEN ;break ; } } -static void tcp_ecn_check_ce (struct tcp_sock *tp,const struct sk_buff *skb) +static void tcp_ecn_check_ce (struct sock *sk,const struct sk_buff *skb) { -if (tp->ecn_flags &TCP_ECN_OK ) -__tcp_ecn_check_ce (tp, skb); +if (tcp_sk (sk)->ecn_flags &TCP_ECN_OK ) +__tcp_ecn_check_ce (sk, skb); }static void tcp_ecn_rcv_synack (struct tcp_sock *tp,const struct tcphdr *th)
@@ -710,7 +712,7 @@ static void tcp_event_data_recv(struct s } icsk->icsk_ack.lrcvtime = now; -tcp_ecn_check_ce (tp, skb); +tcp_ecn_check_ce (sk, skb);if (skb->len >=128 )tcp_grow_window (sk, skb);
@@ -4443,7 +4445,7 @@ static void tcp_data_queue_ofo(struct sou32 seq, end_seq;bool fragstolen; -tcp_ecn_check_ce (tp, skb); +tcp_ecn_check_ce (sk, skb);if (unlikely (tcp_try_rmem_schedule (sk, skb, skb->truesize))) {NET_INC_STATS (sock_net (sk),LINUX_MIB_TCPOFODROP );
Greg Kroah-Hartman
maintainerPATCH 246/246 tcp: add one more quick ack after after ECN events
In reply to Greg Kroah-Hartman4.14-stable review patch. If anyone has any objections, please let me know.
------------------
From: Eric Dumazet <[email protected]>
[ Upstream commit 15ecbe94a45ef88491ca459b26efdd02f91edb6d ]
Larry Brakmo proposal ( https://patchwork.ozlabs.org/patch/935233/
tcp: force cwnd at least 2 in tcp_cwnd_reduction) made us rethink about our recent patch removing ~16 quick acks after ECN events.
tcp_enter_quickack_mode(sk, 1) makes sure one immediate ack is sent, but in the case the sender cwnd was lowered to 1, we do not want to have a delayed ack for the next packet we will receive.
--- net/ipv4/tcp_input.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
net/ipv4/tcp_input.c +2 -2
@@ -261,7 +261,7 @@ static void __tcp_ecn_check_ce(struct so* it is probably a retransmit. */ if (tp->ecn_flags &TCP_ECN_SEEN ) -tcp_enter_quickack_mode (sk,1 ); +tcp_enter_quickack_mode (sk,2 );break ;case INET_ECN_CE :if (tcp_ca_needs_ecn (sk))
@@ -269,7 +269,7 @@ static void __tcp_ecn_check_ce(struct soif (!(tp->ecn_flags &TCP_ECN_DEMAND_CWR )) {/* Better not delay acks, sender can have a very low cwnd */ -tcp_enter_quickack_mode (sk,1 ); +tcp_enter_quickack_mode (sk,2 ); tp->ecn_flags |=TCP_ECN_DEMAND_CWR ; } tp->ecn_flags |=TCP_ECN_SEEN ;
Quoted 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.60 release. There are 246 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 Aug 3 16:49:18 UTC 2018. 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.14.60-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.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 9 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.60 release. There are 246 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 Aug 3 16:49:18 UTC 2018. 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.14.60-rc1.gzor in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.gitlinux-4.14.y
and the diffstat can be found below.thanks,
greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.
Summary
------------------------------------------------------------------------
kernel: 4.14.60-rc1
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: 68285958fc2aaa2d85f795151e1c302d7991f1b5
git describe: v4.14.59-247-g68285958fc2a
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.59-247-g68285958fc2a
No regressions (compared to build v4.14.59-247-g654fc6e3ea92)
Ran 16388 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_x86_64
- x15 - arm
- x86_64
Test Suites
-----------
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* ltp-fsx-tests
* ltp-math-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
Signature · 2 lines
Linaro LKFT https://lkft.linaro.org
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.60 release. There are 246 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 Aug 3 16:49:18 UTC 2018. Anything received after that time might be too late.
Build results:
total: 148 pass: 148 fail: 0 Qemu test results: total: 198 pass: 198 fail: 0
Details are available at http://kerneltests.org/builders/.
Guenter
Quoted 10 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.60 release. There are 246 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 Aug 3 16:49:18 UTC 2018. Anything received after that time might be too late.
Quoted 7 lines
Build results:
total: 148 pass: 148 fail: 0 Qemu test results: total: 198 pass: 198 fail: 0Details are available at http://kerneltests.org/builders/.
I spoke too early. parisc images crash after adding some configuration options. I don't see the crash with v4.14.59. I'll send another update later after figuring out what is going on.
Guenter
Quoted 16 lines · Guenter Roeck
Quoted 15 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.60 release. There are 246 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 Aug 3 16:49:18 UTC 2018. Anything received after that time might be too late.
Build results:
total: 148 pass: 148 fail: 0 Qemu test results: total: 198 pass: 198 fail: 0
Quoted 7 lines
Quoted 2 lines
Details are available at http://kerneltests.org/builders/.
I spoke too early. parisc images crash after adding some configuration options. I don't see the crash with v4.14.59. I'll send another update later after figuring out what is going on.
The patch causing the problem is commit 27608f359da88eaf ("fasync: Fix deadlock between task-context and interrupt-context kill_fasync()"), see bisect log below.
Kernel log message is as follows.
PDC_CHASSIS: Fault (1), CHASSIS 0
Backtrace: [<10267738>] dput.part.5+0x1dc/0x1f0 [<1026776c>] dput+0x20/0x30 [<1024f79c>] __fput+0x14c/0x230 [<1024f8e4>] ____fput+0x18/0x28 [<1019abe0>] task_work_run+0xa4/0xd8 [<1016d044>] do_notify_resume+0x7c/0x84 [<1015c258>] syscall_do_signal+0x50/0x9c
The problem only affects v4.14.60-rc1; all other stable releases and release candidates are fine.
Guenter
---
# bad: [68285958fc2aaa2d85f795151e1c302d7991f1b5] Linux 4.14.60-rc1
# good: [53208e12faa5b8c6eac4eb1d23d6e3fae450fc5a] Linux 4.14.59
git bisect start 'HEAD' 'v4.14.59'
# good: [77d10fced99b2dc0a8067102073005c44e71f964] rtc: vr41xx: fix possible race condition
git bisect good 77d10fced99b2dc0a8067102073005c44e71f964
# bad: [ae308d8e99f6549bd14fc3c639f53966a49cd260] nvme: lightnvm: add granby support
git bisect bad ae308d8e99f6549bd14fc3c639f53966a49cd260
# good: [ee78ecab4e4f0db3f8dbef8369a90da02a89e07f] media: saa7164: Fix driver name in debug output
git bisect good ee78ecab4e4f0db3f8dbef8369a90da02a89e07f
# good: [7e4011cb50b422efaa08e2ad1c009e73b59403ad] f2fs: avoid fsync() failure caused by EAGAIN in writepage() git bisect good 7e4011cb50b422efaa08e2ad1c009e73b59403ad
# good: [bca093b5dd86a25b8b81ba8a54e60ee6db095f15] net: hns3: Fixes the out of bounds access in hclge_map_tqp git bisect good bca093b5dd86a25b8b81ba8a54e60ee6db095f15
# bad: [539f19edd347359502e4b6ce9ce793183e0e0a18] stop_machine: Use raw spinlocks
git bisect bad 539f19edd347359502e4b6ce9ce793183e0e0a18
# bad: [27608f359da88eafd5e344fb7ef1aeea9052bbae] fasync: Fix deadlock between task-context and interrupt-context kill_fasync() git bisect bad 27608f359da88eafd5e344fb7ef1aeea9052bbae
# good: [73b68f3851b934de3cd2e01d6039d9dff4cf74e5] dt-bindings: net: meson-dwmac: new compatible name for AXG SoC git bisect good 73b68f3851b934de3cd2e01d6039d9dff4cf74e5
# first bad commit: [27608f359da88eafd5e344fb7ef1aeea9052bbae] fasync: Fix deadlock between task-context and interrupt-context kill_fasync()
Greg Kroah-Hartman
maintainerQuoted 41 lines · Guenter Roeck
Quoted 16 lines · Guenter Roeck
Quoted 15 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.60 release. There are 246 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 Aug 3 16:49:18 UTC 2018. Anything received after that time might be too late.
Build results:
total: 148 pass: 148 fail: 0 Qemu test results: total: 198 pass: 198 fail: 0Quoted 7 lines
Quoted 2 lines
Details are available at http://kerneltests.org/builders/.
I spoke too early. parisc images crash after adding some configuration options. I don't see the crash with v4.14.59. I'll send another update later after figuring out what is going on.
The patch causing the problem is commit
27608f359da88eaf("fasync: Fix deadlock between task-context and interrupt-contextkill_fasync()"), see bisect log below.Kernel log message is as follows.
PDC_CHASSIS: Fault (1), CHASSIS 0Backtrace: [<10267738>] dput.part.5+0x1dc/0x1f0 [<1026776c>] dput+0x20/0x30 [<1024f79c>] __fput+0x14c/0x230 [<1024f8e4>] ____fput+0x18/0x28 [<1019abe0>] task_work_run+0xa4/0xd8 [<1016d044>] do_notify_resume+0x7c/0x84 [<1015c258>] syscall_do_signal+0x50/0x9c
Quoted 2 lines
The problem only affects v4.14.60-rc1; all other stable releases and release candidates are fine.
That is really odd as that commit is also in the 4.17 and 4.9 -rc releases.
I'll go drop it from all queues just to be safe, odds are something in that backport isn't correct.
thanks for the testing and bisection, much appreciated.
greg k-h
Greg Kroah-Hartman
maintainerQuoted 45 lines · Greg Kroah-Hartman
Quoted 41 lines · Guenter Roeck
Quoted 16 lines · Guenter Roeck
Quoted 15 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.60 release. There are 246 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 Aug 3 16:49:18 UTC 2018. Anything received after that time might be too late.
Build results:
total: 148 pass: 148 fail: 0 Qemu test results: total: 198 pass: 198 fail: 0Quoted 7 lines
Quoted 2 lines
Details are available at http://kerneltests.org/builders/.
I spoke too early. parisc images crash after adding some configuration options. I don't see the crash with v4.14.59. I'll send another update later after figuring out what is going on.
The patch causing the problem is commit
27608f359da88eaf("fasync: Fix deadlock between task-context and interrupt-contextkill_fasync()"), see bisect log below.Kernel log message is as follows.
PDC_CHASSIS: Fault (1), CHASSIS 0Backtrace: [<10267738>] dput.part.5+0x1dc/0x1f0 [<1026776c>] dput+0x20/0x30 [<1024f79c>] __fput+0x14c/0x230 [<1024f8e4>] ____fput+0x18/0x28 [<1019abe0>] task_work_run+0xa4/0xd8 [<1016d044>] do_notify_resume+0x7c/0x84 [<1015c258>] syscall_do_signal+0x50/0x9cQuoted 2 lines
The problem only affects v4.14.60-rc1; all other stable releases and release candidates are fine.
Quoted 7 lines
That is really odd as that commit is also in the 4.17 and 4.9 -rc releases.
I'll go drop it from all queues just to be safe, odds are something in that backport isn't correct.
thanks for the testing and bisection, much appreciated.
I've pushed out -rc2 releases for all of these with that patch removed.
thanks,
greg k-h
On 08/02/2018 12:45 PM, Greg Kroah-Hartman wrote:
[ ... ]
Quoted 3 lines
I've pushed out -rc2 releases for all of these with that patch removed.
Boot tests with updated images passed for all three releases.
Guenter
Greg Kroah-Hartman
maintainerQuoted 7 lines · Guenter Roeck
On 08/02/2018 12:45 PM, Greg Kroah-Hartman wrote:
[ ... ]Quoted 3 lines
I've pushed out -rc2 releases for all of these with that patch removed.
Boot tests with updated images passed for all three releases.
Wonderful, thanks for letting me know.
greg k-h
Quoted 1 line
I've pushed out -rc2 releases for all of these with that patch removed.
Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.
Summary
------------------------------------------------------------------------
kernel: 4.14.60-rc2
git repo: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: 438a20f25869d6047a20ca359e0851b27e01c2fd
git describe: v4.14.59-246-g438a20f25869
Test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.59-246-g438a20f25869
No regressions (compared to build v4.14.59-247-g68285958fc2a)
Ran 14773 total tests in the following environments and test suites.
Environments
--------------
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_x86_64
- x15 - arm
- x86_64
Test Suites
-----------
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none
Signature · 2 lines
Linaro LKFT https://lkft.linaro.org
Greg Kroah-Hartman
maintainerQuoted 4 lines · Naresh Kamboju
Quoted 1 line
I've pushed out -rc2 releases for all of these with that patch removed.
Results from Linaro’s test farm.
No regressions on arm64, arm andx86_64.
Great!
Quoted 42 lines · Greg Kroah-Hartman
Quoted 41 lines · Guenter Roeck
Quoted 16 lines · Guenter Roeck
Quoted 15 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman
This is the start of the stable review cycle for the 4.14.60 release. There are 246 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 Aug 3 16:49:18 UTC 2018. Anything received after that time might be too late.
Build results:
total: 148 pass: 148 fail: 0 Qemu test results: total: 198 pass: 198 fail: 0Quoted 7 lines
Quoted 2 lines
Details are available at http://kerneltests.org/builders/.
I spoke too early. parisc images crash after adding some configuration options. I don't see the crash with v4.14.59. I'll send another update later after figuring out what is going on.
The patch causing the problem is commit
27608f359da88eaf("fasync: Fix deadlock between task-context and interrupt-contextkill_fasync()"), see bisect log below.Kernel log message is as follows.
PDC_CHASSIS: Fault (1), CHASSIS 0Backtrace: [<10267738>] dput.part.5+0x1dc/0x1f0 [<1026776c>] dput+0x20/0x30 [<1024f79c>] __fput+0x14c/0x230 [<1024f8e4>] ____fput+0x18/0x28 [<1019abe0>] task_work_run+0xa4/0xd8 [<1016d044>] do_notify_resume+0x7c/0x84 [<1015c258>] syscall_do_signal+0x50/0x9c
Quoted 9 lines
Quoted 2 lines
The problem only affects v4.14.60-rc1; all other stable releases and release candidates are fine.
That is really odd as that commit is also in the 4.17 and 4.9 -rc releases.
I'll go drop it from all queues just to be safe, odds are something in that backport isn't correct.
... or the context is somehow different. But I agree, it is odd that I didn't see the problem in 4.9/4.17.
I restarted the boot tests; I'll let you know after they are complete. Build tests will run again tonight.
Guenter