- Linux-stable-mirror - lists.linaro.org

Re: [PATCH 3.18 00/68] 3.18.101-stable review

by Greg Kroah-Hartman

On Tue, Mar 20, 2018 at 05:50:27PM +0000, Harsh Shandilya wrote: > On Tue 20 Mar, 2018, 2:14 AM Greg Kroah-Hartman, <gregkh(a)linuxfoundation.org> > wrote: > > > This is the start of the stable review cycle for the 3.18.101 release. > > There are 68 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 Wed Mar 21 17:17:59 UTC 2018. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > > > https://www.kernel.org/pub/linux/kernel/v3.x/stable-review/patch-3.18.101-r… > > or in the git tree and branch at: > > git:// > > git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > > linux-3.18.y > > and the diffstat can be found below. > > > > No merge issues with the CAF msm-3.18 tree, no regressions noticed on the > OnePlus3T. Wonderful, thanks for testing and letting me know. greg k-h

7 years, 1 month

1
0
0 0

[PATCH] drm/vmwgfx: Fix a destoy-while-held mutex problem.

by Thomas Hellstrom

When validating legacy surfaces, the backup bo might be destroyed at surface validate time. However, the kms resource validation code may have the bo reserved, so we will destroy a locked mutex. While there shouldn't be any other users of that mutex when it is destroyed, it causes a lock leak and thus throws a lockdep error. Fix this by having the kms resource validation code hold a reference to the bo while we have it reserved. We do this by introducing a validation context which might come in handy when the kms code is extended to validate multiple resources or buffers. Cc: <stable(a)vger.kernel.org> Signed-off-by: Thomas Hellstrom <thellstrom(a)vmware.com> Reviewed-by: Brian Paul <brianp(a)vmware.com> Reviewed-by: Sinclair Yeh <syeh(a)vmware.com> --- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 28 +++++++++++++++++++--------- drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 12 +++++++++--- drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 5 +++-- drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 5 +++-- 4 files changed, 34 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c index b3d62aa01a9b..3c824fd7cbf3 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c @@ -31,7 +31,6 @@ #include <drm/drm_atomic_helper.h> #include <drm/drm_rect.h> - /* Might need a hrtimer here? */ #define VMWGFX_PRESENT_RATE ((HZ / 60 > 0) ? HZ / 60 : 1) @@ -2517,9 +2516,12 @@ void vmw_kms_helper_buffer_finish(struct vmw_private *dev_priv, * Helper to be used if an error forces the caller to undo the actions of * vmw_kms_helper_resource_prepare. */ -void vmw_kms_helper_resource_revert(struct vmw_resource *res) +void vmw_kms_helper_resource_revert(struct vmw_validation_ctx *ctx) { - vmw_kms_helper_buffer_revert(res->backup); + struct vmw_resource *res = ctx->res; + + vmw_kms_helper_buffer_revert(ctx->buf); + vmw_dmabuf_unreference(&ctx->buf); vmw_resource_unreserve(res, false, NULL, 0); mutex_unlock(&res->dev_priv->cmdbuf_mutex); } @@ -2536,10 +2538,14 @@ void vmw_kms_helper_resource_revert(struct vmw_resource *res) * interrupted by a signal. */ int vmw_kms_helper_resource_prepare(struct vmw_resource *res, - bool interruptible) + bool interruptible, + struct vmw_validation_ctx *ctx) { int ret = 0; + ctx->buf = NULL; + ctx->res = res; + if (interruptible) ret = mutex_lock_interruptible(&res->dev_priv->cmdbuf_mutex); else @@ -2558,6 +2564,8 @@ int vmw_kms_helper_resource_prepare(struct vmw_resource *res, res->dev_priv->has_mob); if (ret) goto out_unreserve; + + ctx->buf = vmw_dmabuf_reference(res->backup); } ret = vmw_resource_validate(res); if (ret) @@ -2565,7 +2573,7 @@ int vmw_kms_helper_resource_prepare(struct vmw_resource *res, return 0; out_revert: - vmw_kms_helper_buffer_revert(res->backup); + vmw_kms_helper_buffer_revert(ctx->buf); out_unreserve: vmw_resource_unreserve(res, false, NULL, 0); out_unlock: @@ -2581,11 +2589,13 @@ int vmw_kms_helper_resource_prepare(struct vmw_resource *res, * @out_fence: Optional pointer to a fence pointer. If non-NULL, a * ref-counted fence pointer is returned here. */ -void vmw_kms_helper_resource_finish(struct vmw_resource *res, - struct vmw_fence_obj **out_fence) +void vmw_kms_helper_resource_finish(struct vmw_validation_ctx *ctx, + struct vmw_fence_obj **out_fence) { - if (res->backup || out_fence) - vmw_kms_helper_buffer_finish(res->dev_priv, NULL, res->backup, + struct vmw_resource *res = ctx->res; + + if (ctx->buf || out_fence) + vmw_kms_helper_buffer_finish(res->dev_priv, NULL, ctx->buf, out_fence, NULL); vmw_resource_unreserve(res, false, NULL, 0); diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h index 948362c43c73..3d2ca280eaa7 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h @@ -240,6 +240,11 @@ struct vmw_display_unit { int set_gui_y; }; +struct vmw_validation_ctx { + struct vmw_resource *res; + struct vmw_dma_buffer *buf; +}; + #define vmw_crtc_to_du(x) \ container_of(x, struct vmw_display_unit, crtc) #define vmw_connector_to_du(x) \ @@ -296,9 +301,10 @@ void vmw_kms_helper_buffer_finish(struct vmw_private *dev_priv, struct drm_vmw_fence_rep __user * user_fence_rep); int vmw_kms_helper_resource_prepare(struct vmw_resource *res, - bool interruptible); -void vmw_kms_helper_resource_revert(struct vmw_resource *res); -void vmw_kms_helper_resource_finish(struct vmw_resource *res, + bool interruptible, + struct vmw_validation_ctx *ctx); +void vmw_kms_helper_resource_revert(struct vmw_validation_ctx *ctx); +void vmw_kms_helper_resource_finish(struct vmw_validation_ctx *ctx, struct vmw_fence_obj **out_fence); int vmw_kms_readback(struct vmw_private *dev_priv, struct drm_file *file_priv, diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c index 63a4cd794b73..3ec9eae831b8 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c @@ -909,12 +909,13 @@ int vmw_kms_sou_do_surface_dirty(struct vmw_private *dev_priv, struct vmw_framebuffer_surface *vfbs = container_of(framebuffer, typeof(*vfbs), base); struct vmw_kms_sou_surface_dirty sdirty; + struct vmw_validation_ctx ctx; int ret; if (!srf) srf = &vfbs->surface->res; - ret = vmw_kms_helper_resource_prepare(srf, true); + ret = vmw_kms_helper_resource_prepare(srf, true, &ctx); if (ret) return ret; @@ -933,7 +934,7 @@ int vmw_kms_sou_do_surface_dirty(struct vmw_private *dev_priv, ret = vmw_kms_helper_dirty(dev_priv, framebuffer, clips, vclips, dest_x, dest_y, num_clips, inc, &sdirty.base); - vmw_kms_helper_resource_finish(srf, out_fence); + vmw_kms_helper_resource_finish(&ctx, out_fence); return ret; } diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c index b68d74888ab1..6b969e5dea2a 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c @@ -980,12 +980,13 @@ int vmw_kms_stdu_surface_dirty(struct vmw_private *dev_priv, struct vmw_framebuffer_surface *vfbs = container_of(framebuffer, typeof(*vfbs), base); struct vmw_stdu_dirty sdirty; + struct vmw_validation_ctx ctx; int ret; if (!srf) srf = &vfbs->surface->res; - ret = vmw_kms_helper_resource_prepare(srf, true); + ret = vmw_kms_helper_resource_prepare(srf, true, &ctx); if (ret) return ret; @@ -1008,7 +1009,7 @@ int vmw_kms_stdu_surface_dirty(struct vmw_private *dev_priv, dest_x, dest_y, num_clips, inc, &sdirty.base); out_finish: - vmw_kms_helper_resource_finish(srf, out_fence); + vmw_kms_helper_resource_finish(&ctx, out_fence); return ret; } -- 2.14.3

7 years, 1 month

1
1
0 0

[PATCH 4.15] scsi: megaraid_sas: Do not use 32-bit atomic request descriptor for Ventura controllers

by Shivasharan S

commit 9ff97fa8db94caeab59a3c5401e975df468b4d8e upstream. Problem Statement: Sending I/O through 32 bit descriptors to Ventura series of controller results in IO timeout on certain conditions. This error only occurs on systems with high I/O activity on Ventura series controllers. Changes in this patch will prevent driver from using 32 bit descriptor and use 64 bit Descriptors. Cc: <stable(a)vger.kernel.org> Signed-off-by: Kashyap Desai <kashyap.desai(a)broadcom.com> Signed-off-by: Shivasharan S <shivasharan.srikanteshwara(a)broadcom.com> Reviewed-by: Hannes Reinecke <hare(a)suse.com> Reviewed-by: Tomas Henzl <thenzl(a)redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> --- Backported due to merge conflicts. Needs to be applied to 4.15.y stable tree. drivers/scsi/megaraid/megaraid_sas_fusion.c | 42 ++++++++++------------------- 1 file changed, 14 insertions(+), 28 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c b/drivers/scsi/megaraid/megaraid_sas_fusion.c index 65dc4fea6352..be2992509b8c 100644 --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c @@ -216,36 +216,30 @@ inline void megasas_return_cmd_fusion(struct megasas_instance *instance, /** * megasas_fire_cmd_fusion - Sends command to the FW * @instance: Adapter soft state - * @req_desc: 32bit or 64bit Request descriptor + * @req_desc: 64bit Request descriptor * - * Perform PCI Write. Ventura supports 32 bit Descriptor. - * Prior to Ventura (12G) MR controller supports 64 bit Descriptor. + * Perform PCI Write. */ static void megasas_fire_cmd_fusion(struct megasas_instance *instance, union MEGASAS_REQUEST_DESCRIPTOR_UNION *req_desc) { - if (instance->adapter_type == VENTURA_SERIES) - writel(le32_to_cpu(req_desc->u.low), - &instance->reg_set->inbound_single_queue_port); - else { #if defined(writeq) && defined(CONFIG_64BIT) - u64 req_data = (((u64)le32_to_cpu(req_desc->u.high) << 32) | - le32_to_cpu(req_desc->u.low)); + u64 req_data = (((u64)le32_to_cpu(req_desc->u.high) << 32) | + le32_to_cpu(req_desc->u.low)); - writeq(req_data, &instance->reg_set->inbound_low_queue_port); + writeq(req_data, &instance->reg_set->inbound_low_queue_port); #else - unsigned long flags; - spin_lock_irqsave(&instance->hba_lock, flags); - writel(le32_to_cpu(req_desc->u.low), - &instance->reg_set->inbound_low_queue_port); - writel(le32_to_cpu(req_desc->u.high), - &instance->reg_set->inbound_high_queue_port); - mmiowb(); - spin_unlock_irqrestore(&instance->hba_lock, flags); + unsigned long flags; + spin_lock_irqsave(&instance->hba_lock, flags); + writel(le32_to_cpu(req_desc->u.low), + &instance->reg_set->inbound_low_queue_port); + writel(le32_to_cpu(req_desc->u.high), + &instance->reg_set->inbound_high_queue_port); + mmiowb(); + spin_unlock_irqrestore(&instance->hba_lock, flags); #endif - } } /** @@ -982,7 +976,6 @@ megasas_ioc_init_fusion(struct megasas_instance *instance) const char *sys_info; MFI_CAPABILITIES *drv_ops; u32 scratch_pad_2; - unsigned long flags; struct timeval tv; bool cur_fw_64bit_dma_capable; @@ -1121,14 +1114,7 @@ megasas_ioc_init_fusion(struct megasas_instance *instance) break; } - /* For Ventura also IOC INIT required 64 bit Descriptor write. */ - spin_lock_irqsave(&instance->hba_lock, flags); - writel(le32_to_cpu(req_desc.u.low), - &instance->reg_set->inbound_low_queue_port); - writel(le32_to_cpu(req_desc.u.high), - &instance->reg_set->inbound_high_queue_port); - mmiowb(); - spin_unlock_irqrestore(&instance->hba_lock, flags); + megasas_fire_cmd_fusion(instance, &req_desc); wait_and_poll(instance, cmd, MFI_POLL_TIMEOUT_SECS); -- 2.16.1

7 years, 1 month

1
0
0 0

[PATCH 4.11, 4.14] scsi: megaraid_sas: Do not use 32-bit atomic request descriptor for Ventura controllers

by Shivasharan S

commit 9ff97fa8db94caeab59a3c5401e975df468b4d8e upstream. Problem Statement: Sending I/O through 32 bit descriptors to Ventura series of controller results in IO timeout on certain conditions. This error only occurs on systems with high I/O activity on Ventura series controllers. Changes in this patch will prevent driver from using 32 bit descriptor and use 64 bit Descriptors. Cc: <stable(a)vger.kernel.org> Signed-off-by: Kashyap Desai <kashyap.desai(a)broadcom.com> Signed-off-by: Shivasharan S <shivasharan.srikanteshwara(a)broadcom.com> Reviewed-by: Hannes Reinecke <hare(a)suse.com> Reviewed-by: Tomas Henzl <thenzl(a)redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> --- Backported due to merge conflicts. Needs to be applied to 4.11.y to 4.14.y stable trees. drivers/scsi/megaraid/megaraid_sas_fusion.c | 42 ++++++++++------------------- 1 file changed, 14 insertions(+), 28 deletions(-) diff --git a/drivers/scsi/megaraid/megaraid_sas_fusion.c b/drivers/scsi/megaraid/megaraid_sas_fusion.c index f990ab4d45e1..c892bd4ca1d6 100644 --- a/drivers/scsi/megaraid/megaraid_sas_fusion.c +++ b/drivers/scsi/megaraid/megaraid_sas_fusion.c @@ -190,36 +190,30 @@ inline void megasas_return_cmd_fusion(struct megasas_instance *instance, /** * megasas_fire_cmd_fusion - Sends command to the FW * @instance: Adapter soft state - * @req_desc: 32bit or 64bit Request descriptor + * @req_desc: 64bit Request descriptor * - * Perform PCI Write. Ventura supports 32 bit Descriptor. - * Prior to Ventura (12G) MR controller supports 64 bit Descriptor. + * Perform PCI Write. */ static void megasas_fire_cmd_fusion(struct megasas_instance *instance, union MEGASAS_REQUEST_DESCRIPTOR_UNION *req_desc) { - if (instance->is_ventura) - writel(le32_to_cpu(req_desc->u.low), - &instance->reg_set->inbound_single_queue_port); - else { #if defined(writeq) && defined(CONFIG_64BIT) - u64 req_data = (((u64)le32_to_cpu(req_desc->u.high) << 32) | - le32_to_cpu(req_desc->u.low)); + u64 req_data = (((u64)le32_to_cpu(req_desc->u.high) << 32) | + le32_to_cpu(req_desc->u.low)); - writeq(req_data, &instance->reg_set->inbound_low_queue_port); + writeq(req_data, &instance->reg_set->inbound_low_queue_port); #else - unsigned long flags; - spin_lock_irqsave(&instance->hba_lock, flags); - writel(le32_to_cpu(req_desc->u.low), - &instance->reg_set->inbound_low_queue_port); - writel(le32_to_cpu(req_desc->u.high), - &instance->reg_set->inbound_high_queue_port); - mmiowb(); - spin_unlock_irqrestore(&instance->hba_lock, flags); + unsigned long flags; + spin_lock_irqsave(&instance->hba_lock, flags); + writel(le32_to_cpu(req_desc->u.low), + &instance->reg_set->inbound_low_queue_port); + writel(le32_to_cpu(req_desc->u.high), + &instance->reg_set->inbound_high_queue_port); + mmiowb(); + spin_unlock_irqrestore(&instance->hba_lock, flags); #endif - } } /** @@ -766,7 +760,6 @@ megasas_ioc_init_fusion(struct megasas_instance *instance) const char *sys_info; MFI_CAPABILITIES *drv_ops; u32 scratch_pad_2; - unsigned long flags; fusion = instance->ctrl_context; @@ -894,14 +887,7 @@ megasas_ioc_init_fusion(struct megasas_instance *instance) break; } - /* For Ventura also IOC INIT required 64 bit Descriptor write. */ - spin_lock_irqsave(&instance->hba_lock, flags); - writel(le32_to_cpu(req_desc.u.low), - &instance->reg_set->inbound_low_queue_port); - writel(le32_to_cpu(req_desc.u.high), - &instance->reg_set->inbound_high_queue_port); - mmiowb(); - spin_unlock_irqrestore(&instance->hba_lock, flags); + megasas_fire_cmd_fusion(instance, &req_desc); wait_and_poll(instance, cmd, MFI_POLL_TIMEOUT_SECS); -- 2.16.1

7 years, 1 month

1
0
0 0

FW: Neue Kunden

by Thomas Stein

Sehr geehrte Damen und Herren, nach unserem Besuch Ihrer Homepage möchten wir Ihnen ein Angebot von Produkten vorstellen, das Ihnen ermöglichen wird, den Verkauf Ihrer Produkte sowie Dienstleistungen deutlich zu erhöhen. Ich biete Ihnen den ganz neuen Adressenkatalog der Österreicher Unternehmen an, in dem sich direkte Kontaktdaten der Firmeninhaber und Manager befinden. Die Datenbanken der Firmen sind in für Sie interessante und relevante Zielgruppen untergliedert. Die Firmenangaben beinhalten: Name der Firma, Ansprechpartner, E-mail Adresse, Tel. + Fax-Nr., PLZ, Ort, Straße etc. *** 1. Österreich 2018 ( 104 000 ) - 149 EUR ( bis zum 21.03.2018 ) *** Die Verwendungsmöglichkeiten der Datenbanken sind praktisch unbegrenzt und Sie können durch Verwendung der von uns entwickelten Programme des personalisierten Versendens von Angeboten u.ä. mittels E-mailing bzw. Fax effektive und sichere Werbekampagnen damit durchführen. Bitte informieren Sie sich über die weiteren Details einmal unverbindlich auf unseren Webseite: http://www.gbcdb.net/?page=catalog MfG Thomas Stein http://www.gbcdb.net/?page=catalog

7 years, 1 month

1
0
0 0

[PATCH] tpm: fix potential buffer overruns caused by bit glitches on the bus

by Jarkko Sakkinen

From: Jeremy Boone <jeremy.boone(a)nccgroup.trust> commit 3be23274755ee85771270a23af7691dc9b3a95db upstream Discrete TPMs are often connected over slow serial buses which, on some platforms, can have glitches causing bit flips. If a bit does flip it could cause an overrun if it's in one of the size parameters, so sanity check that we're not overrunning the provided buffer when doing a memcpy(). Signed-off-by: Jeremy Boone <jeremy.boone(a)nccgroup.trust> Cc: stable(a)vger.kernel.org Signed-off-by: James Bottomley <James.Bottomley(a)HansenPartnership.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> Tested-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> --- Backported to v4.9 v2: fixed the upstream ID drivers/char/tpm/tpm-interface.c | 5 +++++ drivers/char/tpm/tpm2-cmd.c | 6 ++++++ 2 files changed, 11 insertions(+) diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c index d0ac2d56520f..830d7e30e508 100644 --- a/drivers/char/tpm/tpm-interface.c +++ b/drivers/char/tpm/tpm-interface.c @@ -1078,6 +1078,11 @@ int tpm_get_random(u32 chip_num, u8 *out, size_t max) break; recd = be32_to_cpu(tpm_cmd.params.getrandom_out.rng_data_len); + if (recd > num_bytes) { + total = -EFAULT; + break; + } + memcpy(dest, tpm_cmd.params.getrandom_out.rng_data, recd); dest += recd; diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c index 17896d654033..a5780ebe15ef 100644 --- a/drivers/char/tpm/tpm2-cmd.c +++ b/drivers/char/tpm/tpm2-cmd.c @@ -668,6 +668,11 @@ static int tpm2_unseal_cmd(struct tpm_chip *chip, if (!rc) { data_len = be16_to_cpup( (__be16 *) &buf.data[TPM_HEADER_SIZE + 4]); + if (data_len < MIN_KEY_SIZE || data_len > MAX_KEY_SIZE + 1) { + rc = -EFAULT; + goto out; + } + data = &buf.data[TPM_HEADER_SIZE + 6]; memcpy(payload->key, data, data_len - 1); @@ -675,6 +680,7 @@ static int tpm2_unseal_cmd(struct tpm_chip *chip, payload->migratable = data[data_len - 1]; } +out: tpm_buf_destroy(&buf); return rc; } -- 2.15.1

7 years, 1 month

1
0
0 0

[PATCH 1/2] tpm: fix potential buffer overruns caused by bit glitches on the bus

by Jarkko Sakkinen

From: Jeremy Boone <jeremy.boone(a)nccgroup.trust> commit 3be23274755ee85771270a23af7691dc9b3a95db upstream Discrete TPMs are often connected over slow serial buses which, on some platforms, can have glitches causing bit flips. If a bit does flip it could cause an overrun if it's in one of the size parameters, so sanity check that we're not overrunning the provided buffer when doing a memcpy(). Signed-off-by: Jeremy Boone <jeremy.boone(a)nccgroup.trust> Cc: stable(a)vger.kernel.org Signed-off-by: James Bottomley <James.Bottomley(a)HansenPartnership.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> Tested-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> --- Backported to v4.4. v2: fixed the upstream ID drivers/char/tpm/tpm-interface.c | 5 +++++ drivers/char/tpm/tpm2-cmd.c | 6 ++++++ 2 files changed, 11 insertions(+) diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c index aaa5fa95dede..36afc1a21699 100644 --- a/drivers/char/tpm/tpm-interface.c +++ b/drivers/char/tpm/tpm-interface.c @@ -1040,6 +1040,11 @@ int tpm_get_random(u32 chip_num, u8 *out, size_t max) break; recd = be32_to_cpu(tpm_cmd.params.getrandom_out.rng_data_len); + if (recd > num_bytes) { + total = -EFAULT; + break; + } + memcpy(dest, tpm_cmd.params.getrandom_out.rng_data, recd); dest += recd; diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c index 286bd090a488..389a009b83f2 100644 --- a/drivers/char/tpm/tpm2-cmd.c +++ b/drivers/char/tpm/tpm2-cmd.c @@ -622,6 +622,11 @@ static int tpm2_unseal_cmd(struct tpm_chip *chip, if (!rc) { data_len = be16_to_cpup( (__be16 *) &buf.data[TPM_HEADER_SIZE + 4]); + if (data_len < MIN_KEY_SIZE || data_len > MAX_KEY_SIZE + 1) { + rc = -EFAULT; + goto out; + } + data = &buf.data[TPM_HEADER_SIZE + 6]; memcpy(payload->key, data, data_len - 1); @@ -629,6 +634,7 @@ static int tpm2_unseal_cmd(struct tpm_chip *chip, payload->migratable = data[data_len - 1]; } +out: tpm_buf_destroy(&buf); return rc; } -- 2.15.1

7 years, 1 month

1
1
0 0

[Linux-stable-mirror] [PATCH RESEND] rpmsg: virtio_rpmsg_bus: fix rpmsg_probe() for virtio-mmio transport

by Anup Patel

When virtio-rpmsg device is provided via virtio-mmio transport, the dma_alloc_coherent() (called by rpmsg_probe()) fails on ARM/ARM64 systems because "vdev->dev.parent->parent" device is used as parameter to dma_alloc_coherent(). The "vdev->dev.parent->parent" device represents underlying remoteproc platform device when virtio-rpmsg device is provided via virtio-remoteproc transport. When virtio-rpmsg device is provided via virtio-mmio transport, the "vdev->dev.parent->parent" device represents the parent device of virtio-mmio platform device and dma_alloc_coherent() fails for this device because generally there is no corresponding platform device and dma_ops are not setup for "vdev->dev.parent->parent". This patch fixes dma_alloc_coherent() usage in rpmsg_probe() by trying dma_alloc_coherent() with "vdev->dev.parent" device when it fails with "vdev->dev.parent->parent" device. Fixes: b5ab5e24e960 ("remoteproc: maintain a generic child device for each rproc") Signed-off-by: Anup Patel <anup(a)brainfault.org> Cc: stable(a)vger.kernel.org --- drivers/rpmsg/virtio_rpmsg_bus.c | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c index 82b8300..7f8710a 100644 --- a/drivers/rpmsg/virtio_rpmsg_bus.c +++ b/drivers/rpmsg/virtio_rpmsg_bus.c @@ -64,6 +64,7 @@ struct virtproc_info { struct virtio_device *vdev; struct virtqueue *rvq, *svq; + struct device *bufs_dev; void *rbufs, *sbufs; unsigned int num_bufs; unsigned int buf_size; @@ -924,9 +925,16 @@ static int rpmsg_probe(struct virtio_device *vdev) total_buf_space, &vrp->bufs_dma, GFP_KERNEL); if (!bufs_va) { - err = -ENOMEM; - goto vqs_del; - } + bufs_va = dma_alloc_coherent(vdev->dev.parent, + total_buf_space, &vrp->bufs_dma, + GFP_KERNEL); + if (!bufs_va) { + err = -ENOMEM; + goto vqs_del; + } else + vrp->bufs_dev = vdev->dev.parent; + } else + vrp->bufs_dev = vdev->dev.parent->parent; dev_dbg(&vdev->dev, "buffers: va %p, dma %pad\n", bufs_va, &vrp->bufs_dma); @@ -988,7 +996,7 @@ static int rpmsg_probe(struct virtio_device *vdev) return 0; free_coherent: - dma_free_coherent(vdev->dev.parent->parent, total_buf_space, + dma_free_coherent(vrp->bufs_dev, total_buf_space, bufs_va, vrp->bufs_dma); vqs_del: vdev->config->del_vqs(vrp->vdev); @@ -1023,7 +1031,7 @@ static void rpmsg_remove(struct virtio_device *vdev) vdev->config->del_vqs(vrp->vdev); - dma_free_coherent(vdev->dev.parent->parent, total_buf_space, + dma_free_coherent(vrp->bufs_dev, total_buf_space, vrp->rbufs, vrp->bufs_dma); kfree(vrp); -- 2.7.4

7 years, 1 month

2
5
0 0

v3.2.101 build: 5 failures 20 warnings (v3.2.101)

by Build bot for Mark Brown

Tree/Branch: v3.2.101 Git describe: v3.2.101 Commit: 68f705428e Linux 3.2.101 Build Time: 0 min 4 sec Passed: 0 / 5 ( 0.00 %) Failed: 5 / 5 (100.00 %) Errors: 6 Warnings: 20 Section Mismatches: 0 Failed defconfigs: x86_64-allnoconfig arm-allmodconfig arm-allnoconfig x86_64-allmodconfig x86_64-defconfig Errors: x86_64-allnoconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode arm-allnoconfig /home/broonie/build/linux-stable/arch/arm/include/asm/div64.h:77:7: error: '__LINUX_ARM_ARCH__' undeclared (first use in this function) /home/broonie/build/linux-stable/arch/arm/include/asm/glue-cache.h:129:2: error: #error Unknown cache maintenance model /home/broonie/build/linux-stable/arch/arm/include/asm/glue-df.h:107:2: error: #error Unknown data abort handler type /home/broonie/build/linux-stable/arch/arm/include/asm/glue-pf.h:54:2: error: #error Unknown prefetch abort handler type x86_64-allmodconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode x86_64-defconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 2 warnings 0 mismatches : arm-allmodconfig 19 warnings 0 mismatches : arm-allnoconfig ------------------------------------------------------------------------------- Errors summary: 6 3 /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode 3 /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode 1 /home/broonie/build/linux-stable/arch/arm/include/asm/glue-pf.h:54:2: error: #error Unknown prefetch abort handler type 1 /home/broonie/build/linux-stable/arch/arm/include/asm/glue-df.h:107:2: error: #error Unknown data abort handler type 1 /home/broonie/build/linux-stable/arch/arm/include/asm/glue-cache.h:129:2: error: #error Unknown cache maintenance model 1 /home/broonie/build/linux-stable/arch/arm/include/asm/div64.h:77:7: error: '__LINUX_ARM_ARCH__' undeclared (first use in this function) Warnings Summary: 20 2 .config:27:warning: symbol value '' invalid for PHYS_OFFSET 1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:342:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:272:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:265:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:131:35: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:127:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:121:3: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:120:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:114:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/swab.h:25:28: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:82:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:102:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/irqflags.h:11:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/fpstate.h:32:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:33:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:28:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:196:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:194:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/bitops.h:217:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/atomic.h:30:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- x86_64-allnoconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- arm-allmodconfig : FAIL, 0 errors, 2 warnings, 0 section mismatches Warnings: .config:27:warning: symbol value '' invalid for PHYS_OFFSET .config:27:warning: symbol value '' invalid for PHYS_OFFSET ------------------------------------------------------------------------------- arm-allnoconfig : FAIL, 4 errors, 19 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/arch/arm/include/asm/div64.h:77:7: error: '__LINUX_ARM_ARCH__' undeclared (first use in this function) /home/broonie/build/linux-stable/arch/arm/include/asm/glue-cache.h:129:2: error: #error Unknown cache maintenance model /home/broonie/build/linux-stable/arch/arm/include/asm/glue-df.h:107:2: error: #error Unknown data abort handler type /home/broonie/build/linux-stable/arch/arm/include/asm/glue-pf.h:54:2: error: #error Unknown prefetch abort handler type Warnings: /home/broonie/build/linux-stable/arch/arm/include/asm/irqflags.h:11:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:114:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:120:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:121:3: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:127:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:131:35: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:265:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:272:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:342:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/bitops.h:217:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/swab.h:25:28: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/fpstate.h:32:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:82:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:102:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/atomic.h:30:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:28:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:33:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:194:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:196:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] ------------------------------------------------------------------------------- x86_64-allmodconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- x86_64-defconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches:

7 years, 1 month

1
0
0 0

v3.16.56 build: 0 failures 4 warnings (v3.16.56)

by Build bot for Mark Brown

Tree/Branch: v3.16.56 Git describe: v3.16.56 Commit: a413cc78bc Linux 3.16.56 Build Time: 29 min 33 sec Passed: 8 / 8 (100.00 %) Failed: 0 / 8 ( 0.00 %) Errors: 0 Warnings: 4 Section Mismatches: 0 ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 1 warnings 0 mismatches : x86_64-allnoconfig 1 warnings 0 mismatches : arm64-allmodconfig 1 warnings 0 mismatches : x86_64-defconfig 2 warnings 0 mismatches : arm64-defconfig ------------------------------------------------------------------------------- Warnings Summary: 4 2 ../ipc/sem.c:377:6: warning: '___p1' may be used uninitialized in this function [-Wmaybe-uninitialized] 1 ../drivers/platform/x86/eeepc-laptop.c:279:10: warning: 'value' may be used uninitialized in this function [-Wmaybe-uninitialized] 1 ../drivers/net/ethernet/broadcom/genet/bcmgenet.c:1346:17: warning: unused variable 'kdev' [-Wunused-variable] 1 ../arch/x86/kernel/cpu/common.c:1032:13: warning: 'syscall32_cpu_init' defined but not used [-Wunused-function] =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- x86_64-allnoconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: ../arch/x86/kernel/cpu/common.c:1032:13: warning: 'syscall32_cpu_init' defined but not used [-Wunused-function] ------------------------------------------------------------------------------- arm64-allmodconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: ../drivers/net/ethernet/broadcom/genet/bcmgenet.c:1346:17: warning: unused variable 'kdev' [-Wunused-variable] ------------------------------------------------------------------------------- x86_64-defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: ../drivers/platform/x86/eeepc-laptop.c:279:10: warning: 'value' may be used uninitialized in this function [-Wmaybe-uninitialized] ------------------------------------------------------------------------------- arm64-defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches Warnings: ../ipc/sem.c:377:6: warning: '___p1' may be used uninitialized in this function [-Wmaybe-uninitialized] ../ipc/sem.c:377:6: warning: '___p1' may be used uninitialized in this function [-Wmaybe-uninitialized] ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: arm64-allnoconfig arm-multi_v7_defconfig arm-allnoconfig arm-multi_v5_defconfig

7 years, 1 month

1
0
0 0

[PATCH 2/3] cfi_cmdset_0001: Workaround Micron Erase suspend bug.

by Joakim Tjernlund

From: Joakim Tjernlund <joakim.tjernlund(a)transmode.se> Some Micron chips does not work well wrt Erase suspend for boot blocks. This avoids the issue by not allowing Erase suspend for the boot blocks for the 28F00AP30(1GBit) chip. Signed-off-by: Joakim Tjernlund <joakim.tjernlund(a)infinera.com> Cc: <stable(a)vger.kernel.org> --- drivers/mtd/chips/cfi_cmdset_0001.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c b/drivers/mtd/chips/cfi_cmdset_0001.c index b59872304ae7..64ae65dab877 100644 --- a/drivers/mtd/chips/cfi_cmdset_0001.c +++ b/drivers/mtd/chips/cfi_cmdset_0001.c @@ -45,6 +45,7 @@ #define I82802AB 0x00ad #define I82802AC 0x00ac #define PF38F4476 0x881c +#define M28F00AP30 0x8963 /* STMicroelectronics chips */ #define M50LPW080 0x002F #define M50FLW080A 0x0080 @@ -375,6 +376,17 @@ static void cfi_fixup_major_minor(struct cfi_private *cfi, extp->MinorVersion = '1'; } +static int cfi_is_micron_28F00AP30(struct cfi_private *cfi, struct flchip *chip) +{ + /* + * Micron(was Numonyx) 1Gbit bottom boot are buggy w.r.t + * Erase Supend for their small Erase Blocks(0x8000) + */ + if (cfi->mfr == CFI_MFR_INTEL && cfi->id == M28F00AP30) + return 1; + return 0; +} + static inline struct cfi_pri_intelext * read_pri_intelext(struct map_info *map, __u16 adr) { @@ -854,6 +866,11 @@ static int chip_ready (struct map_info *map, struct flchip *chip, unsigned long chip->in_progress_block_addr) goto sleep; + /* do not suspend small EBs, buggy Micron Chips */ + if (cfi_is_micron_28F00AP30(cfi, chip) && + (chip->in_progress_block_mask == ~(0x8000-1))) + goto sleep; + /* Erase suspend */ map_write(map, CMD(0xB0), chip->in_progress_block_addr); -- 2.13.6

7 years, 1 month

3
2
0 0

+ mm-hmm-hmm_pfns_bad-was-accessing-wrong-struct.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/hmm: hmm_pfns_bad() was accessing wrong struct has been added to the -mm tree. Its filename is mm-hmm-hmm_pfns_bad-was-accessing-wrong-struct.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-hmm-hmm_pfns_bad-was-accessing-… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-hmm-hmm_pfns_bad-was-accessing-… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/SubmitChecklist when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Jérôme Glisse <jglisse(a)redhat.com> Subject: mm/hmm: hmm_pfns_bad() was accessing wrong struct The private field of mm_walk struct point to an hmm_vma_walk struct and not to the hmm_range struct desired. Fix to get proper struct pointer. Link: http://lkml.kernel.org/r/20180320020038.3360-6-jglisse@redhat.com Signed-off-by: Jérôme Glisse <jglisse(a)redhat.com> Cc: Evgeny Baskakov <ebaskakov(a)nvidia.com> Cc: Ralph Campbell <rcampbell(a)nvidia.com> Cc: Mark Hairgrove <mhairgrove(a)nvidia.com> Cc: John Hubbard <jhubbard(a)nvidia.com> Cc: Balbir Singh <bsingharora(a)gmail.com> Cc: Jason Gunthorpe <jgg(a)mellanox.com> Cc: Logan Gunthorpe <logang(a)deltatee.com> Cc: Stephen Bates <sbates(a)raithlin.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- diff -puN mm/hmm.c~mm-hmm-hmm_pfns_bad-was-accessing-wrong-struct mm/hmm.c --- a/mm/hmm.c~mm-hmm-hmm_pfns_bad-was-accessing-wrong-struct +++ a/mm/hmm.c @@ -312,7 +312,8 @@ static int hmm_pfns_bad(unsigned long ad unsigned long end, struct mm_walk *walk) { - struct hmm_range *range = walk->private; + struct hmm_vma_walk *hmm_vma_walk = walk->private; + struct hmm_range *range = hmm_vma_walk->range; hmm_pfn_t *pfns = range->pfns; unsigned long i; _ Patches currently in -mm which might be from jglisse(a)redhat.com are mm-hmm-fix-header-file-if-else-endif-maze-v2.patch mm-hmm-unregister-mmu_notifier-when-last-hmm-client-quit.patch mm-hmm-hmm_pfns_bad-was-accessing-wrong-struct.patch mm-hmm-use-struct-for-hmm_vma_fault-hmm_vma_get_pfns-parameters-v2.patch mm-hmm-remove-hmm_pfn_read-flag-and-ignore-peculiar-architecture-v2.patch mm-hmm-use-uint64_t-for-hmm-pfn-instead-of-defining-hmm_pfn_t-to-ulong-v2.patch mm-hmm-cleanup-special-vma-handling-vm_special.patch mm-hmm-do-not-differentiate-between-empty-entry-or-missing-directory-v2.patch mm-hmm-rename-hmm_pfn_device_unaddressable-to-hmm_pfn_device_private.patch mm-hmm-move-hmm_pfns_clear-closer-to-where-it-is-use.patch mm-hmm-factor-out-pte-and-pmd-handling-to-simplify-hmm_vma_walk_pmd.patch mm-hmm-change-hmm_vma_fault-to-allow-write-fault-on-page-basis.patch mm-hmm-use-device-driver-encoding-for-hmm-pfn-v2.patch

7 years, 1 month

1
0
0 0

+ mm-hmm-hmm-should-have-a-callback-before-mm-is-destroyed-v2.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/hmm: HMM should have a callback before MM is destroyed v2 has been added to the -mm tree. Its filename is mm-hmm-hmm-should-have-a-callback-before-mm-is-destroyed-v2.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-hmm-hmm-should-have-a-callback-… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-hmm-hmm-should-have-a-callback-… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/SubmitChecklist when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Ralph Campbell <rcampbell(a)nvidia.com> Subject: mm/hmm: HMM should have a callback before MM is destroyed v2 The hmm_mirror_register() function registers a callback for when the CPU pagetable is modified. Normally, the device driver will call hmm_mirror_unregister() when the process using the device is finished. However, if the process exits uncleanly, the struct_mm can be destroyed with no warning to the device driver. Link: http://lkml.kernel.org/r/20180320020038.3360-4-jglisse@redhat.com Signed-off-by: Ralph Campbell <rcampbell(a)nvidia.com> Signed-off-by: Jérôme Glisse <jglisse(a)redhat.com> Cc: Evgeny Baskakov <ebaskakov(a)nvidia.com> Cc: Mark Hairgrove <mhairgrove(a)nvidia.com> Cc: John Hubbard <jhubbard(a)nvidia.com> Cc: Balbir Singh <bsingharora(a)gmail.com> Cc: Jason Gunthorpe <jgg(a)mellanox.com> Cc: Logan Gunthorpe <logang(a)deltatee.com> Cc: Stephen Bates <sbates(a)raithlin.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- diff -puN include/linux/hmm.h~mm-hmm-hmm-should-have-a-callback-before-mm-is-destroyed-v2 include/linux/hmm.h --- a/include/linux/hmm.h~mm-hmm-hmm-should-have-a-callback-before-mm-is-destroyed-v2 +++ a/include/linux/hmm.h @@ -218,6 +218,16 @@ enum hmm_update_type { * @update: callback to update range on a device */ struct hmm_mirror_ops { + /* release() - release hmm_mirror + * + * @mirror: pointer to struct hmm_mirror + * + * This is called when the mm_struct is being released. + * The callback should make sure no references to the mirror occur + * after the callback returns. + */ + void (*release)(struct hmm_mirror *mirror); + /* sync_cpu_device_pagetables() - synchronize page tables * * @mirror: pointer to struct hmm_mirror diff -puN mm/hmm.c~mm-hmm-hmm-should-have-a-callback-before-mm-is-destroyed-v2 mm/hmm.c --- a/mm/hmm.c~mm-hmm-hmm-should-have-a-callback-before-mm-is-destroyed-v2 +++ a/mm/hmm.c @@ -160,6 +160,21 @@ static void hmm_invalidate_range(struct up_read(&hmm->mirrors_sem); } +static void hmm_release(struct mmu_notifier *mn, struct mm_struct *mm) +{ + struct hmm *hmm = mm->hmm; + struct hmm_mirror *mirror; + struct hmm_mirror *mirror_next; + + down_write(&hmm->mirrors_sem); + list_for_each_entry_safe(mirror, mirror_next, &hmm->mirrors, list) { + list_del_init(&mirror->list); + if (mirror->ops->release) + mirror->ops->release(mirror); + } + up_write(&hmm->mirrors_sem); +} + static void hmm_invalidate_range_start(struct mmu_notifier *mn, struct mm_struct *mm, unsigned long start, @@ -185,6 +200,7 @@ static void hmm_invalidate_range_end(str } static const struct mmu_notifier_ops hmm_mmu_notifier_ops = { + .release = hmm_release, .invalidate_range_start = hmm_invalidate_range_start, .invalidate_range_end = hmm_invalidate_range_end, }; @@ -230,7 +246,7 @@ void hmm_mirror_unregister(struct hmm_mi struct hmm *hmm = mirror->hmm; down_write(&hmm->mirrors_sem); - list_del(&mirror->list); + list_del_init(&mirror->list); up_write(&hmm->mirrors_sem); } EXPORT_SYMBOL(hmm_mirror_unregister); _ Patches currently in -mm which might be from rcampbell(a)nvidia.com are mm-hmm-documentation-editorial-update-to-hmm-documentation.patch mm-hmm-hmm-should-have-a-callback-before-mm-is-destroyed-v2.patch

7 years, 1 month

1
0
0 0

+ mm-hmm-fix-header-file-if-else-endif-maze-v2.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/hmm: fix header file if/else/endif maze v2 has been added to the -mm tree. Its filename is mm-hmm-fix-header-file-if-else-endif-maze-v2.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-hmm-fix-header-file-if-else-end… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-hmm-fix-header-file-if-else-end… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/SubmitChecklist when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Jérôme Glisse <jglisse(a)redhat.com> Subject: mm/hmm: fix header file if/else/endif maze v2 The #if/#else/#endif for IS_ENABLED(CONFIG_HMM) were wrong. Because of this after multiple include there was multiple definition of both hmm_mm_init() and hmm_mm_destroy() leading to build failure if HMM was enabled (CONFIG_HMM set). Link: http://lkml.kernel.org/r/20180320020038.3360-3-jglisse@redhat.com Signed-off-by: Jérôme Glisse <jglisse(a)redhat.com> Acked-by: Balbir Singh <bsingharora(a)gmail.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Ralph Campbell <rcampbell(a)nvidia.com> Cc: John Hubbard <jhubbard(a)nvidia.com> Cc: Evgeny Baskakov <ebaskakov(a)nvidia.com> Cc: Jason Gunthorpe <jgg(a)mellanox.com> Cc: Logan Gunthorpe <logang(a)deltatee.com> Cc: Mark Hairgrove <mhairgrove(a)nvidia.com> Cc: Stephen Bates <sbates(a)raithlin.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- diff -puN include/linux/hmm.h~mm-hmm-fix-header-file-if-else-endif-maze-v2 include/linux/hmm.h --- a/include/linux/hmm.h~mm-hmm-fix-header-file-if-else-endif-maze-v2 +++ a/include/linux/hmm.h @@ -498,23 +498,16 @@ struct hmm_device { struct hmm_device *hmm_device_new(void *drvdata); void hmm_device_put(struct hmm_device *hmm_device); #endif /* CONFIG_DEVICE_PRIVATE || CONFIG_DEVICE_PUBLIC */ -#endif /* IS_ENABLED(CONFIG_HMM) */ /* Below are for HMM internal use only! Not to be used by device driver! */ -#if IS_ENABLED(CONFIG_HMM_MIRROR) void hmm_mm_destroy(struct mm_struct *mm); static inline void hmm_mm_init(struct mm_struct *mm) { mm->hmm = NULL; } -#else /* IS_ENABLED(CONFIG_HMM_MIRROR) */ -static inline void hmm_mm_destroy(struct mm_struct *mm) {} -static inline void hmm_mm_init(struct mm_struct *mm) {} -#endif /* IS_ENABLED(CONFIG_HMM_MIRROR) */ - - #else /* IS_ENABLED(CONFIG_HMM) */ static inline void hmm_mm_destroy(struct mm_struct *mm) {} static inline void hmm_mm_init(struct mm_struct *mm) {} +#endif /* IS_ENABLED(CONFIG_HMM) */ #endif /* LINUX_HMM_H */ _ Patches currently in -mm which might be from jglisse(a)redhat.com are mm-hmm-fix-header-file-if-else-endif-maze-v2.patch mm-hmm-unregister-mmu_notifier-when-last-hmm-client-quit.patch mm-hmm-hmm_pfns_bad-was-accessing-wrong-struct.patch mm-hmm-use-struct-for-hmm_vma_fault-hmm_vma_get_pfns-parameters-v2.patch mm-hmm-remove-hmm_pfn_read-flag-and-ignore-peculiar-architecture-v2.patch mm-hmm-use-uint64_t-for-hmm-pfn-instead-of-defining-hmm_pfn_t-to-ulong-v2.patch mm-hmm-cleanup-special-vma-handling-vm_special.patch mm-hmm-do-not-differentiate-between-empty-entry-or-missing-directory-v2.patch mm-hmm-rename-hmm_pfn_device_unaddressable-to-hmm_pfn_device_private.patch mm-hmm-move-hmm_pfns_clear-closer-to-where-it-is-use.patch mm-hmm-factor-out-pte-and-pmd-handling-to-simplify-hmm_vma_walk_pmd.patch mm-hmm-change-hmm_vma_fault-to-allow-write-fault-on-page-basis.patch mm-hmm-use-device-driver-encoding-for-hmm-pfn-v2.patch

7 years, 1 month

1
0
0 0

+ mm-hugetlb-prevent-hugetlb-vma-to-be-misaligned.patch added to -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: mm/hugetlb: prevent hugetlb VMA to be misaligned has been added to the -mm tree. Its filename is mm-hugetlb-prevent-hugetlb-vma-to-be-misaligned.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-hugetlb-prevent-hugetlb-vma-to-… and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-hugetlb-prevent-hugetlb-vma-to-… Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/SubmitChecklist when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Laurent Dufour <ldufour(a)linux.vnet.ibm.com> Subject: mm/hugetlb: prevent hugetlb VMA to be misaligned When running the sampler detailed below, the kernel, if built with the VM debug option turned on (as many distro do), is panicing with the following message: kernel BUG at /build/linux-jWa1Fv/linux-4.15.0/mm/hugetlb.c:3310! Oops: Exception in kernel mode, sig: 5 [#1] LE SMP NR_CPUS=2048 NUMA PowerNV Modules linked in: kcm nfc af_alg caif_socket caif phonet fcrypt 8<--8<--8<--8< snip 8<--8<--8<--8< CPU: 18 PID: 43243 Comm: trinity-subchil Tainted: G C E 4.15.0-10-generic #11-Ubuntu NIP: c00000000036e764 LR: c00000000036ee48 CTR: 0000000000000009 REGS: c000003fbcdcf810 TRAP: 0700 Tainted: G C E (4.15.0-10-generic) MSR: 9000000000029033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 24002222 XER: 20040000 CFAR: c00000000036ee44 SOFTE: 1 GPR00: c00000000036ee48 c000003fbcdcfa90 c0000000016ea600 c000003fbcdcfc40 GPR04: c000003fd9858950 00007115e4e00000 00007115e4e10000 0000000000000000 GPR08: 0000000000000010 0000000000010000 0000000000000000 0000000000000000 GPR12: 0000000000002000 c000000007a2c600 00000fe3985954d0 00007115e4e00000 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 00000fe398595a94 000000000000a6fc c000003fd9858950 0000000000018554 GPR24: c000003fdcd84500 c0000000019acd00 00007115e4e10000 c000003fbcdcfc40 GPR28: 0000000000200000 00007115e4e00000 c000003fbc9ac600 c000003fd9858950 NIP [c00000000036e764] __unmap_hugepage_range+0xa4/0x760 LR [c00000000036ee48] __unmap_hugepage_range_final+0x28/0x50 Call Trace: [c000003fbcdcfa90] [00007115e4e00000] 0x7115e4e00000 (unreliable) [c000003fbcdcfb50] [c00000000036ee48] __unmap_hugepage_range_final+0x28/0x50 [c000003fbcdcfb80] [c00000000033497c] unmap_single_vma+0x11c/0x190 [c000003fbcdcfbd0] [c000000000334e14] unmap_vmas+0x94/0x140 [c000003fbcdcfc20] [c00000000034265c] exit_mmap+0x9c/0x1d0 [c000003fbcdcfce0] [c000000000105448] mmput+0xa8/0x1d0 [c000003fbcdcfd10] [c00000000010fad0] do_exit+0x360/0xc80 [c000003fbcdcfdd0] [c0000000001104c0] do_group_exit+0x60/0x100 [c000003fbcdcfe10] [c000000000110584] SyS_exit_group+0x24/0x30 [c000003fbcdcfe30] [c00000000000b184] system_call+0x58/0x6c Instruction dump: 552907fe e94a0028 e94a0408 eb2a0018 81590008 7f9c5036 0b090000 e9390010 7d2948f8 7d2a2838 0b0a0000 7d293038 <0b090000> e9230086 2fa90000 419e0468 ===[ end trace ee88f958a1c62605 ]=== The panic is due to a VMA pointing to a hugetlb area while the vma->vm_start or vma->vm_end field are not aligned to the huge page boundaries. The sampler is just unmapping a part of the hugetlb area, leading to 2 VMAs which are not well aligned. The same could be achieved by calling madvise() situation, as it is when running: stress-ng --shm-sysv 1 The hugetlb code is assuming that the VMA will be well aligned when it is unmapped, so we must prevent such a VMA from bing split or shrunk to a misaligned address. This patch prevents this by checking the new VMA's boundaries when a VMA is modified by calling vma_adjust(). === Sampler used to hit the panic nclude <sys/ipc.h> unsigned long page_size; int main(void) { int shmid, ret=1; void *addr; setbuf(stdout, NULL); page_size = getpagesize(); shmid = shmget(0x1410, LENGTH, IPC_CREAT | SHM_HUGETLB | SHM_R | SHM_W); if (shmid < 0) { perror("shmget"); exit(1); } printf("shmid: %d ", shmid); addr = shmat(shmid, NULL, 0); if (addr == (void*)-1) { perror("shmat"); goto out; } /* * The following munmap() call will split the VMA in 2, leading to * unaligned to huge page size VMAs which will trigger a check when * shmdt() is called. */ if (munmap(addr + HPSIZE + page_size, page_size)) { perror("munmap"); goto out; } if (shmdt(addr)) { perror("shmdt"); goto out; } printf("test done. "); ret = 0; out: shmctl(shmid, IPC_RMID, NULL); return ret; } === End of code Link: http://lkml.kernel.org/r/1521566754-30390-1-git-send-email-ldufour@linux.vn… Signed-off-by: Laurent Dufour <ldufour(a)linux.vnet.ibm.com> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: Andrea Arcangeli <aarcange(a)redhat.com> Cc: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- diff -puN mm/mmap.c~mm-hugetlb-prevent-hugetlb-vma-to-be-misaligned mm/mmap.c --- a/mm/mmap.c~mm-hugetlb-prevent-hugetlb-vma-to-be-misaligned +++ a/mm/mmap.c @@ -692,6 +692,17 @@ int __vma_adjust(struct vm_area_struct * long adjust_next = 0; int remove_next = 0; + if (is_vm_hugetlb_page(vma)) { + /* + * We must check against the huge page boundarie to not + * create misaligned VMA. + */ + struct hstate *h = hstate_vma(vma); + + if (start & ~huge_page_mask(h) || end & ~huge_page_mask(h)) + return -EINVAL; + } + if (next && !insert) { struct vm_area_struct *exporter = NULL, *importer = NULL; _ Patches currently in -mm which might be from ldufour(a)linux.vnet.ibm.com are mm-hugetlb-prevent-hugetlb-vma-to-be-misaligned.patch

7 years, 1 month

1
0
0 0

All builds broken in v4.1.y.queue

by Guenter Roeck

kernel/locking/mutex.c: In function '__mutex_unlock_common_slowpath': build/kernel/locking/mutex.c:721:2: error: implicit declaration of function 'WAKE_Q' kernel/locking/mutex.c:721:9: error: 'wake_q' undeclared This affects all architectures and all builds. Guenter

7 years, 1 month

1
0
0 0

[PATCH] nvme: Skip checking heads without namespaces

by Keith Busch

If a task is holding a reference to a namespace on a removed controller, the head will not be released. If the same controller is added again later, its namespaces may not be successfully added. Instead, the user will see kernel message "Duplicate IDs for nsid <X>". This patch fixes that by skipping heads that don't have namespaces when considering if a new namespace is safe to add. Reported-by: Alex Gagniuc <Alex_Gagniuc(a)Dellteam.com> Cc: stable(a)vger.kernel.org Signed-off-by: Keith Busch <keith.busch(a)intel.com> --- drivers/nvme/host/core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c index 7aeca5db7916..0b9e60861e53 100644 --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@ -2793,6 +2793,7 @@ static int __nvme_check_ids(struct nvme_subsystem *subsys, list_for_each_entry(h, &subsys->nsheads, entry) { if (nvme_ns_ids_valid(&new->ids) && + !list_empty(&h->list) && nvme_ns_ids_equal(&new->ids, &h->ids)) return -EINVAL; } -- 2.14.3

7 years, 1 month

3
3
0 0

Build/test failures in v4.1.50

by Guenter Roeck

Hi, unfortunately I missed message that the stable release queue repository for 4.1.y changed. It looks like I am not copied on release announcements, so I missed the last couple of releases. As a result, my builders did not catch any changes for some time. I just ran a test on v4.1.50 and got the following results. Build results: total: 139 pass: 133 fail: 6 Failed builds: arm:axm55xx_defconfig arm64:allmodconfig i386:defconfig i386:allyesconfig i386:allmodconfig i386:allnoconfig Qemu test results: total: 125 pass: 111 fail: 14 Failed tests: arm64:virt:smp:defconfig:initrd arm64:xlnx-zcu102:smp:defconfig:initrd:zynqmp-ep108 arm64:virt:nosmp:defconfig:initrd arm64:xlnx-zcu102:nosmp:defconfig:initrd:zynqmp-ep108 x86:Broadwell:q35:x86_pc_defconfig x86:Skylake-Client:q35:x86_pc_defconfig x86:SandyBridge:q35:x86_pc_defconfig x86:Haswell:pc:x86_pc_defconfig x86:Nehalem:q35:x86_pc_defconfig x86:phenom:pc:x86_pc_defconfig x86:core2duo:q35:x86_pc_nosmp_defconfig x86:Conroe:isapc:x86_pc_nosmp_defconfig x86:Opteron_G1:pc:x86_pc_nosmp_defconfig x86:n270:isapc:x86_pc_nosmp_defconfig From the logs: Building arm:axm55xx_defconfig ... failed -------------- Error log: arch/arm/kvm/handle_exit.c: In function 'handle_hvc': arch/arm/kvm/handle_exit.c:48:3: error: implicit declaration of function 'vcpu_set_reg' Building arm64:allmodconfig ... failed -------------- Error log: arch/arm64/kvm/handle_exit.c:45:3: error: implicit declaration of function ‘vcpu_set_reg’; did you mean ‘vcpu_sys_reg’? Building i386:defconfig ... failed -------------- Error log: arch/x86/lib/checksum_32.S:32:31: fatal error: asm/nospec-branch.h All other failures have the same cause. Guenter

7 years, 1 month

2
1
0 0

Please apply 9b54d816e0042 ("blkcg: fix double free...") to v4.1.y..v4.9.y

by Guenter Roeck

Hi Greg, Hi Sasha, commit 9b54d816e0042 ("blkcg: fix double free of new_blkg in blkcg_init_queue") fixes CVE-2018-7480. See https://nvd.nist.gov/vuln/detail/CVE-2018-7480 for details. Please apply to v4.1.y .. v4.9.y. Thanks, Guenter

7 years, 1 month

3
2
0 0

[PATCH 1/6] mm/vmscan: Wake up flushers for legacy cgroups too

by Andrey Ryabinin

Commit 726d061fbd36 ("mm: vmscan: kick flushers when we encounter dirty pages on the LRU") added flusher invocation to shrink_inactive_list() when many dirty pages on the LRU are encountered. However, shrink_inactive_list() doesn't wake up flushers for legacy cgroup reclaim, so the next commit bbef938429f5 ("mm: vmscan: remove old flusher wakeup from direct reclaim path") removed the only source of flusher's wake up in legacy mem cgroup reclaim path. This leads to premature OOM if there is too many dirty pages in cgroup: # mkdir /sys/fs/cgroup/memory/test # echo $$ > /sys/fs/cgroup/memory/test/tasks # echo 50M > /sys/fs/cgroup/memory/test/memory.limit_in_bytes # dd if=/dev/zero of=tmp_file bs=1M count=100 Killed dd invoked oom-killer: gfp_mask=0x14000c0(GFP_KERNEL), nodemask=(null), order=0, oom_score_adj=0 Call Trace: dump_stack+0x46/0x65 dump_header+0x6b/0x2ac oom_kill_process+0x21c/0x4a0 out_of_memory+0x2a5/0x4b0 mem_cgroup_out_of_memory+0x3b/0x60 mem_cgroup_oom_synchronize+0x2ed/0x330 pagefault_out_of_memory+0x24/0x54 __do_page_fault+0x521/0x540 page_fault+0x45/0x50 Task in /test killed as a result of limit of /test memory: usage 51200kB, limit 51200kB, failcnt 73 memory+swap: usage 51200kB, limit 9007199254740988kB, failcnt 0 kmem: usage 296kB, limit 9007199254740988kB, failcnt 0 Memory cgroup stats for /test: cache:49632KB rss:1056KB rss_huge:0KB shmem:0KB mapped_file:0KB dirty:49500KB writeback:0KB swap:0KB inactive_anon:0KB active_anon:1168KB inactive_file:24760KB active_file:24960KB unevictable:0KB Memory cgroup out of memory: Kill process 3861 (bash) score 88 or sacrifice child Killed process 3876 (dd) total-vm:8484kB, anon-rss:1052kB, file-rss:1720kB, shmem-rss:0kB oom_reaper: reaped process 3876 (dd), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB Wake up flushers in legacy cgroup reclaim too. Fixes: bbef938429f5 ("mm: vmscan: remove old flusher wakeup from direct reclaim path") Signed-off-by: Andrey Ryabinin <aryabinin(a)virtuozzo.com> Cc: <stable(a)vger.kernel.org> --- mm/vmscan.c | 31 ++++++++++++++++--------------- 1 file changed, 16 insertions(+), 15 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index 8fcd9f8d7390..4390a8d5be41 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -1771,6 +1771,20 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec, if (stat.nr_writeback && stat.nr_writeback == nr_taken) set_bit(PGDAT_WRITEBACK, &pgdat->flags); + /* + * If dirty pages are scanned that are not queued for IO, it + * implies that flushers are not doing their job. This can + * happen when memory pressure pushes dirty pages to the end of + * the LRU before the dirty limits are breached and the dirty + * data has expired. It can also happen when the proportion of + * dirty pages grows not through writes but through memory + * pressure reclaiming all the clean cache. And in some cases, + * the flushers simply cannot keep up with the allocation + * rate. Nudge the flusher threads in case they are asleep. + */ + if (stat.nr_unqueued_dirty == nr_taken) + wakeup_flusher_threads(WB_REASON_VMSCAN); + /* * Legacy memcg will stall in page writeback so avoid forcibly * stalling here. @@ -1783,22 +1797,9 @@ shrink_inactive_list(unsigned long nr_to_scan, struct lruvec *lruvec, if (stat.nr_dirty && stat.nr_dirty == stat.nr_congested) set_bit(PGDAT_CONGESTED, &pgdat->flags); - /* - * If dirty pages are scanned that are not queued for IO, it - * implies that flushers are not doing their job. This can - * happen when memory pressure pushes dirty pages to the end of - * the LRU before the dirty limits are breached and the dirty - * data has expired. It can also happen when the proportion of - * dirty pages grows not through writes but through memory - * pressure reclaiming all the clean cache. And in some cases, - * the flushers simply cannot keep up with the allocation - * rate. Nudge the flusher threads in case they are asleep, but - * also allow kswapd to start writing pages during reclaim. - */ - if (stat.nr_unqueued_dirty == nr_taken) { - wakeup_flusher_threads(WB_REASON_VMSCAN); + /* Allow kswapd to start writing pages during reclaim. */ + if (stat.nr_unqueued_dirty == nr_taken) set_bit(PGDAT_DIRTY, &pgdat->flags); - } /* * If kswapd scans pages marked marked for immediate -- 2.16.1

7 years, 1 month

3
2
0 0

Re: 4.14.28 crash on tcp_push

by Willy Tarreau

Hi Pavlos, On Tue, Mar 20, 2018 at 01:01:38PM +0100, Pavlos Parissis wrote: > Hi, > > We were upgrading a production system from 4.14.20 to 4.14.28 and we got the following crash and I > was wondering if anyone has seen similar crash: > > [ 346.435832] BUG: unable to handle kernel NULL pointer dereference at 0000000000000038 > [ 346.473216] IP: tcp_push+0x42/0x120 > [ 346.489607] PGD 8000001838949067 P4D 8000001838949067 PUD 183894a067 PMD 0 > [ 346.523318] Oops: 0002 [#1] SMP PTI > [ 346.540395] Modules linked in: sctp_diag sctp dccp_diag dccp udp_diag unix_diag tcp_diag > inet_diag 8021q garp mrp input_leds joydev xfs libcrc32c loop vfat fat x86_pkg_temp_thermal > intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel > pcbc aesni_intel iTCO_wdt crypto_simd glue_helper cryptd iTCO_vendor_support intel_cstate lpc_ich > intel_rapl_perf mfd_core hpwdt i2c_i801 hpilo pcspkr wmi sg ipmi_si ipmi_devintf ipmi_msghandler > acpi_power_meter shpchp ioatdma ip_tables ext4 mbcache jbd2 mgag200 i2c_algo_bit drm_kms_helper > syscopyarea sysfillrect sysimgblt fb_sys_fops sd_mod ttm crc32c_intel ixgbe mdio hpsa tg3 i40e drm > dca ptp pps_core scsi_transport_sas dm_mirror dm_region_hash dm_log dm_mod dax > [ 346.854574] CPU: 5 PID: 1533 Comm: carbon-submissi Not tainted 4.14.28-1.el7.x86_64 #1 > [ 346.892452] Hardware name: HP ProLiant DL380 Gen9/ProLiant DL380 Gen9, BIOS P89 04/25/2017 > [ 346.931641] task: ffff88183806c5c0 task.stack: ffffc90007ea8000 > [ 346.959768] RIP: 0010:tcp_push+0x42/0x120 > [ 346.978914] RSP: 0018:ffffc90007eabc78 EFLAGS: 00010246 > [ 347.004199] RAX: 0000000000000000 RBX: 00000000000000c2 RCX: 0000000000000001 > [ 347.038684] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88184ad0c800 > [ 347.073236] RBP: ffffc90007eabc78 R08: 000000000000ffcb R09: 0000000000000257 > [ 347.108070] R10: ffff88184ad0c958 R11: 000000000000ffcb R12: 00000000ffffffe0 > [ 347.142006] R13: 00000000ffffffe0 R14: ffff88184ad0c800 R15: ffff88184ad0c958 > [ 347.176290] FS: 00007fbad3ff7700(0000) GS:ffff880c4fd40000(0000) knlGS:0000000000000000 > [ 347.215545] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 347.243091] CR2: 0000000000000038 CR3: 0000001838bd4004 CR4: 00000000001606e0 > [ 347.276950] Call Trace: > [ 347.288526] tcp_sendmsg_locked+0x118/0xe50 > [ 347.308321] tcp_sendmsg+0x2c/0x50 > [ 347.324517] inet_sendmsg+0x37/0xb0 > [ 347.341379] sock_sendmsg+0x3e/0x50 > [ 347.358018] sock_write_iter+0x85/0xf0 > [ 347.376095] __vfs_write+0xfb/0x160 > [ 347.392961] vfs_write+0xb2/0x1b0 > [ 347.408915] ? syscall_trace_enter+0x1cd/0x2b0 > [ 347.430458] SyS_write+0x55/0xc0 > [ 347.446047] do_syscall_64+0x79/0x1b0 > [ 347.463757] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 > [ 347.488102] RIP: 0033:0x7fbae295a6ad > [ 347.505100] RSP: 002b:00007fbad3ff6e60 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 > [ 347.541196] RAX: ffffffffffffffda RBX: 00000000000000c7 RCX: 00007fbae295a6ad > [ 347.575649] RDX: 00000000000000c7 RSI: 00007fbabc06ab60 RDI: 0000000000000013 > [ 347.609762] RBP: 000000000000000a R08: 00007fbabc06ab60 R09: 00000000022a58f0 > [ 347.643653] R10: 0000000000001a05 R11: 0000000000000293 R12: 00007fbabc06ab60 > [ 347.677684] R13: 000000000200f040 R14: 00000000022a1840 R15: 00000000000000cb > [ 347.712207] Code: 48 8b 87 60 01 00 00 4c 8d 97 58 01 00 00 41 89 d3 ba 00 00 00 00 49 39 c2 48 > 0f 44 c2 89 f2 81 e2 00 80 00 00 0f 85 af 00 00 00 <80> 48 38 08 44 8b 8f 74 06 00 00 44 89 8f 7c 06 > 00 00 83 e6 01 > [ 347.803312] RIP: tcp_push+0x42/0x120 RSP: ffffc90007eabc78 > [ 347.829666] CR2: 0000000000000038 > [ 347.845805] ---[ end trace 031807a627822772 ]--- > [ 347.873681] Kernel panic - not syncing: Fatal exception > [ 347.898899] Kernel Offset: disabled > [ 347.920580] Rebooting in 70 seconds.. Interesting, I also experienced a spontaneous panic on my home firewall after upgrading it from 4.14.10 to 4.14.27, but I didn't have any symbol in the traces so the dump wasn't exploitable. All I know is that it was a NULL deref with a very small offset as well. It may be totally unrelated though but the coincidence is troubling, especially since I haven't had a panic in -stable for a very long time. Ah I've just seen your second e-mail. So if it's the same as the patch you pointed, the bug is 4.14-only and the fix as well. It will likely come with the next batch of networking backports. Cheers, Willy

7 years, 1 month

1
0
0 0

[Linux-stable-mirror] [PATCH] thermal: imx: Fix race condition in imx_thermal_probe()

by Fabio Estevam

From: Mikhail Lappo <mikhail.lappo(a)esrlabs.com> When device boots with T > T_trip_1 and requests interrupt, the race condition takes place. The interrupt comes before THERMAL_DEVICE_ENABLED is set. This leads to an attempt to reading sensor value from irq and disabling the sensor, based on the data->mode field, which expected to be THERMAL_DEVICE_ENABLED, but still stays as THERMAL_DEVICE_DISABLED. Afher this issue sensor is never re-enabled, as the driver state is wrong. Fix this problem by setting the 'data' members prior to requesting the interrupts. Fixes: 37713a1e8e4c ("thermal: imx: implement thermal alarm interrupt handling") Cc: <stable(a)vger.kernel.org> Signed-off-by: Mikhail Lappo <mikhail.lappo(a)esrlabs.com> Signed-off-by: Fabio Estevam <fabio.estevam(a)nxp.com> --- drivers/thermal/imx_thermal.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/thermal/imx_thermal.c b/drivers/thermal/imx_thermal.c index a67781b..ee3a215 100644 --- a/drivers/thermal/imx_thermal.c +++ b/drivers/thermal/imx_thermal.c @@ -637,6 +637,9 @@ static int imx_thermal_probe(struct platform_device *pdev) regmap_write(map, TEMPSENSE0 + REG_CLR, TEMPSENSE0_POWER_DOWN); regmap_write(map, TEMPSENSE0 + REG_SET, TEMPSENSE0_MEASURE_TEMP); + data->irq_enabled = true; + data->mode = THERMAL_DEVICE_ENABLED; + ret = devm_request_threaded_irq(&pdev->dev, data->irq, imx_thermal_alarm_irq, imx_thermal_alarm_irq_thread, 0, "imx_thermal", data); @@ -649,9 +652,6 @@ static int imx_thermal_probe(struct platform_device *pdev) return ret; } - data->irq_enabled = true; - data->mode = THERMAL_DEVICE_ENABLED; - return 0; } -- 2.7.4

7 years, 1 month

4
8
0 0

patch "phy: allwinner: sun4i-usb: poll vbus changes on A23/A33 when driving" added to usb-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled phy: allwinner: sun4i-usb: poll vbus changes on A23/A33 when driving to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-next branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. >From d7119224bfe6e8efbf821a52db7da9530d790f07 Mon Sep 17 00:00:00 2001 From: Chen-Yu Tsai <wens(a)csie.org> Date: Fri, 19 Jan 2018 17:25:41 +0800 Subject: phy: allwinner: sun4i-usb: poll vbus changes on A23/A33 when driving VBUS The AXP223 PMIC, like the AXP221, does not generate VBUS change interrupts when N_VBUSEN is used to drive VBUS for the OTG port on the board. This was not noticed until recently, as most A23/A33 boards use a GPIO pin that does not support interrupts for OTG ID detection. This forces the driver to use polling. However the A33-OlinuXino uses a pin that does support interrupts, so the driver uses them. However the VBUS interrupt never fires, and the driver never gets to update the VBUS status. This results in musb timing out waiting for VBUS to rise. This was worked around for the AXP221 by resorting to polling changes in commit 91d96f06a760 ("phy-sun4i-usb: Add workaround for missing Vbus det interrupts on A31"). This patch adds the A23 and A33 to the list of SoCs that need the workaround. Fixes: fc1f45ed3043 ("phy-sun4i-usb: Add support for the usb-phys on the sun8i-a33 SoC") Fixes: 123dfdbcfaf5 ("phy-sun4i-usb: Add support for the usb-phys on the sun8i-a23 SoC") Cc: <stable(a)vger.kernel.org> # 4.3.x: 68dbc2ce77bb phy-sun4i-usb: Use of_match_node to get model specific config data Cc: <stable(a)vger.kernel.org> # 4.3.x: 5cf700ac9d50 phy: phy-sun4i-usb: Fix optional gpios failing probe Cc: <stable(a)vger.kernel.org> # 4.3.x: 04e59a0211ff phy-sun4i-usb: Fix irq free conditions to match request conditions Cc: <stable(a)vger.kernel.org> # 4.3.x: 91d96f06a760 phy-sun4i-usb: Add workaround for missing Vbus det interrupts on A31 Cc: <stable(a)vger.kernel.org> # 4.3.x Signed-off-by: Chen-Yu Tsai <wens(a)csie.org> Acked-by: Maxime Ripard <maxime.ripard(a)free-electrons.com> Signed-off-by: Kishon Vijay Abraham I <kishon(a)ti.com> Signed-off-by: Kishon Vijay Abraham I <kishon(a)ti.com> --- drivers/phy/allwinner/phy-sun4i-usb.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c b/drivers/phy/allwinner/phy-sun4i-usb.c index bee798892b21..d4dcd39b8d76 100644 --- a/drivers/phy/allwinner/phy-sun4i-usb.c +++ b/drivers/phy/allwinner/phy-sun4i-usb.c @@ -411,11 +411,13 @@ static bool sun4i_usb_phy0_poll(struct sun4i_usb_phy_data *data) return true; /* - * The A31 companion pmic (axp221) does not generate vbus change - * interrupts when the board is driving vbus, so we must poll + * The A31/A23/A33 companion pmics (AXP221/AXP223) do not + * generate vbus change interrupts when the board is driving + * vbus using the N_VBUSEN pin on the pmic, so we must poll * when using the pmic for vbus-det _and_ we're driving vbus. */ - if (data->cfg->type == sun6i_a31_phy && + if ((data->cfg->type == sun6i_a31_phy || + data->cfg->type == sun8i_a33_phy) && data->vbus_power_supply && data->phys[0].regulator_on) return true; @@ -886,7 +888,7 @@ static const struct sun4i_usb_phy_cfg sun7i_a20_cfg = { static const struct sun4i_usb_phy_cfg sun8i_a23_cfg = { .num_phys = 2, - .type = sun4i_a10_phy, + .type = sun6i_a31_phy, .disc_thresh = 3, .phyctl_offset = REG_PHYCTL_A10, .dedicated_clocks = true, -- 2.16.2

7 years, 1 month

1
0
0 0

[PATCH][v2] mtd: rawnand: fsl_ifc: Fix nand waitfunc return value

by Jagdish Gediya

As per the IFC hardware manual, Most significant 2 bytes in nand_fsr register are the outcome of NAND READ STATUS command. So status value need to be shifted and aligned as per the nand framework requirement. Fixes: 82771882d960 ("NAND Machine support for Integrated Flash Controller") Cc: stable(a)vger.kernel.org # v3.18+ Signed-off-by: Jagdish Gediya <jagdish.gediya(a)nxp.com> Reviewed-by: Prabhakar Kushwaha <prabhakar.kushwaha(a)nxp.com> --- Changes for v2: Incorporated comments from Boris Brezillon - Added fixes tag drivers/mtd/nand/fsl_ifc_nand.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c index 9390cbd..0aa03ba 100644 --- a/drivers/mtd/nand/fsl_ifc_nand.c +++ b/drivers/mtd/nand/fsl_ifc_nand.c @@ -643,12 +643,13 @@ static int fsl_ifc_wait(struct mtd_info *mtd, struct nand_chip *chip) fsl_ifc_run_command(mtd); nand_fsr = ifc_in32(&ifc->ifc_nand.nand_fsr); - + nand_fsr >>= 16; + nand_fsr = (nand_fsr >> 8) | (nand_fsr << 8); /* * The chip always seems to report that it is * write-protected, even when it is not. */ - return nand_fsr | NAND_STATUS_WP; + return (nand_fsr & 0xff) | NAND_STATUS_WP; } /* -- 1.9.1

7 years, 1 month

2
3
0 0

[PATCH 4.14 000/110] 4.14.25-stable review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.14.25 release. There are 110 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 Mar 9 19:10:03 UTC 2018. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.25-rc… or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y and the diffstat can be found below. thanks, greg k-h ------------- Pseudo-Shortlog of commits: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Linux 4.14.25-rc1 Sagi Grimberg <sagi(a)grimberg.me> nvme-rdma: don't suppress send completions NeilBrown <neilb(a)suse.com> md: only allow remove_and_add_spares when no sync_thread running. Adam Ford <aford173(a)gmail.com> ARM: dts: LogicPD Torpedo: Fix I2C1 pinmux Adam Ford <aford173(a)gmail.com> ARM: dts: LogicPD SOM-LV: Fix I2C1 pinmux Kai Heng Feng <kai.heng.feng(a)canonical.com> ACPI / bus: Parse tables as term_list for Dell XPS 9570 and Precision M5530 Eric Biggers <ebiggers(a)google.com> KVM/x86: remove WARN_ON() for when vm_munmap() fails Tianyu Lan <lantianyu1986(a)gmail.com> KVM/x86: Fix wrong macro references of X86_CR0_PG_BIT and X86_CR4_PAE_BIT in kvm_valid_sregs() Ard Biesheuvel <ard.biesheuvel(a)linaro.org> PCI/ASPM: Deal with missing root ports in link state handling Radim Krčmář <rkrcmar(a)redhat.com> KVM: x86: fix vcpu initialization with userspace lapic Paolo Bonzini <pbonzini(a)redhat.com> KVM/VMX: Optimize vmx_vcpu_run() and svm_vcpu_run() by marking the RDMSR path as unlikely() Paolo Bonzini <pbonzini(a)redhat.com> KVM: x86: move LAPIC initialization after VMCS creation Paolo Bonzini <pbonzini(a)redhat.com> KVM/x86: Remove indirect MSR op calls from SPEC_CTRL Wanpeng Li <wanpeng.li(a)hotmail.com> KVM: mmu: Fix overlap between public and private memslots Wanpeng Li <wanpengli(a)tencent.com> KVM: X86: Fix SMRAM accessing even if VM is shutdown Paolo Bonzini <pbonzini(a)redhat.com> KVM: x86: extend usage of RET_MMIO_PF_* constants Arnd Bergmann <arnd(a)arndb.de> ARM: kvm: fix building with gcc-8 Ulf Magnusson <ulfalizer(a)gmail.com> ARM: mvebu: Fix broken PL310_ERRATA_753970 selects Daniel Schultz <d.schultz(a)phytec.de> ARM: dts: rockchip: Remove 1.8 GHz operation point from phycore som Arnd Bergmann <arnd(a)arndb.de> ARM: orion: fix orion_ge00_switch_board_info initialization Jan Beulich <JBeulich(a)suse.com> x86/mm: Fix {pmd,pud}_{set,clear}_flags() Rasmus Villemoes <linux(a)rasmusvillemoes.dk> nospec: Allow index argument to have const-qualified type David Hildenbrand <david(a)redhat.com> KVM: s390: consider epoch index on TOD clock syncs David Hildenbrand <david(a)redhat.com> KVM: s390: consider epoch index on hotplugged CPUs David Hildenbrand <david(a)redhat.com> KVM: s390: provide only a single function for setting the tod (fix SCK) David Hildenbrand <david(a)redhat.com> KVM: s390: take care of clock-comparator sign control Anna Karbownik <anna.karbownik(a)intel.com> EDAC, sb_edac: Fix out of bound writes during DIMM configuration on KNL Mauro Carvalho Chehab <mchehab(a)kernel.org> media: m88ds3103: don't call a non-initalized function Ming Lei <ming.lei(a)redhat.com> blk-mq: don't call io sched's .requeue_request when requeueing rq to ->dispatch Julian Wiedmann <jwi(a)linux.vnet.ibm.com> s390/qeth: fix IPA command submission race Julian Wiedmann <jwi(a)linux.vnet.ibm.com> s390/qeth: fix IP address lookup for L3 devices Julian Wiedmann <jwi(a)linux.vnet.ibm.com> Revert "s390/qeth: fix using of ref counter for rxip addresses" Julian Wiedmann <jwi(a)linux.vnet.ibm.com> s390/qeth: fix double-free on IP add/remove race Julian Wiedmann <jwi(a)linux.vnet.ibm.com> s390/qeth: fix IP removal on offline cards Julian Wiedmann <jwi(a)linux.vnet.ibm.com> s390/qeth: fix overestimated count of buffer elements Julian Wiedmann <jwi(a)linux.vnet.ibm.com> s390/qeth: fix SETIP command handling Ursula Braun <ubraun(a)linux.vnet.ibm.com> s390/qeth: fix underestimated count of buffer elements Jason Wang <jasowang(a)redhat.com> virtio-net: disable NAPI only when enabled during XDP set Jason Wang <jasowang(a)redhat.com> tuntap: disable preemption during XDP processing Jason Wang <jasowang(a)redhat.com> tuntap: correctly add the missing XDP flush Soheil Hassas Yeganeh <soheil(a)google.com> tcp: purge write queue upon RST Jason A. Donenfeld <Jason(a)zx2c4.com> netlink: put module reference if dump start fails Ido Schimmel <idosch(a)mellanox.com> mlxsw: spectrum_router: Do not unconditionally clear route offload indication Paolo Abeni <pabeni(a)redhat.com> cls_u32: fix use after free in u32_destroy_key() Tom Lendacky <thomas.lendacky(a)amd.com> amd-xgbe: Restore PCI interrupt enablement setting on resume Eran Ben Elisha <eranbe(a)mellanox.com> net/mlx5e: Verify inline header size do not exceed SKB linear size Ido Schimmel <idosch(a)mellanox.com> bridge: Fix VLAN reference count problem Alexey Kodanev <alexey.kodanev(a)oracle.com> sctp: fix dst refcnt leak in sctp_v6_get_dst() David Ahern <dsahern(a)gmail.com> net: ipv4: Set addr_type in hash_keys for forwarded case Jiri Pirko <jiri(a)mellanox.com> mlxsw: spectrum_router: Fix error path in mlxsw_sp_vr_create Yuchung Cheng <ycheng(a)google.com> tcp: revert F-RTO extension to detect more spurious timeouts Yuchung Cheng <ycheng(a)google.com> tcp: revert F-RTO middle-box workaround Xin Long <lucien.xin(a)gmail.com> sctp: do not pr_err for the duplicated node in transport rhlist Ivan Vecera <ivecera(a)redhat.com> net/sched: cls_u32: fix cls_u32 on filter replace Eric Dumazet <edumazet(a)google.com> net_sched: gen_estimator: fix broken estimators based on percpu stats Inbar Karmy <inbark(a)mellanox.com> net/mlx5e: Fix loopback self test when GRO is off Tonghao Zhang <xiangxia.m.yue(a)gmail.com> doc: Change the min default value of tcp_wmem/tcp_rmem. Eric Dumazet <edumazet(a)google.com> tcp_bbr: better deal with suboptimal GSO David Howells <dhowells(a)redhat.com> rxrpc: Fix send in rxrpc_send_data_packet() Ilya Lesokhin <ilyal(a)mellanox.com> tcp: Honor the eor bit in tcp_mtu_probe Heiner Kallweit <hkallweit1(a)gmail.com> net: phy: fix phy_start to consider PHY_IGNORE_INTERRUPT Gal Pressman <galp(a)mellanox.com> net/mlx5e: Specify numa node when allocating drop rq Shalom Toledo <shalomt(a)mellanox.com> mlxsw: spectrum_switchdev: Check success of FDB add operation Tommi Rantala <tommi.t.rantala(a)nokia.com> sctp: fix dst refcnt leak in sctp_v4_get_dst Gal Pressman <galp(a)mellanox.com> net/mlx5e: Fix TCP checksum in LRO buffers Alexey Kodanev <alexey.kodanev(a)oracle.com> udplite: fix partial checksum initialization Alexey Kodanev <alexey.kodanev(a)oracle.com> sctp: verify size of a new chunk in _sctp_make_chunk() Guillaume Nault <g.nault(a)alphalink.fr> ppp: prevent unregistered channels from connecting to PPP units Roman Kapl <code(a)rkapl.cz> net: sched: report if filter is too large to dump Nicolas Dichtel <nicolas.dichtel(a)6wind.com> netlink: ensure to loop over all netns in genlmsg_multicast_allns() Sabrina Dubroca <sd(a)queasysnail.net> net: ipv4: don't allow setting net.ipv4.route.min_pmtu below 68 Jakub Kicinski <jakub.kicinski(a)netronome.com> net: fix race on decreasing number of TX queues Grygorii Strashko <grygorii.strashko(a)ti.com> net: ethernet: ti: cpsw: fix net watchdog timeout Wolfram Sang <wsa+renesas(a)sang-engineering.com> net: amd-xgbe: fix comparison to bitshift when dealing with a mask Arnd Bergmann <arnd(a)arndb.de> ipv6 sit: work around bogus gcc-8 -Wrestrict warning Denis Du <dudenis2000(a)yahoo.ca> hdlc_ppp: carrier detect ok, don't turn off negotiation Stefano Brivio <sbrivio(a)redhat.com> fib_semantics: Don't match route with mismatching tclassid Xin Long <lucien.xin(a)gmail.com> bridge: check brport attr show in brport_show Thomas Gleixner <tglx(a)linutronix.de> x86/cpu_entry_area: Sync cpu_entry_area to initial_page_table Sebastian Panceac <sebastian(a)resin.io> x86/platform/intel-mid: Handle Intel Edison reboot correctly Juergen Gross <jgross(a)suse.com> x86/xen: Zero MSR_IA32_SPEC_CTRL before suspend Jan Kara <jack(a)suse.cz> direct-io: Fix sleep in atomic due to sync AIO Dan Williams <dan.j.williams(a)intel.com> dax: fix vma_is_fsdax() helper Viresh Kumar <viresh.kumar(a)linaro.org> cpufreq: s3c24xx: Fix broken s3c_cpufreq_init() Dan Williams <dan.j.williams(a)intel.com> vfio: disable filesystem-dax page pinning Ming Lei <ming.lei(a)redhat.com> block: kyber: fix domain token leak during requeue Jiufei Xue <jiufei.xue(a)linux.alibaba.com> block: fix the count of PGPGOUT for WRITE_SAME Anand Jain <anand.jain(a)oracle.com> btrfs: use proper endianness accessors for super_copy John David Anglin <dave.anglin(a)bell.net> parisc: Fix ordering of cache and TLB flushes Helge Deller <deller(a)gmx.de> parisc: Reduce irq overhead when run in qemu Helge Deller <deller(a)gmx.de> parisc: Use cr16 interval timers unconditionally on qemu Lingutla Chandrasekhar <clingutla(a)codeaurora.org> timers: Forward timer base before migrating timers Shawn Lin <shawn.lin(a)rock-chips.com> mmc: dw_mmc: Fix out-of-bounds access for slot's caps Shawn Lin <shawn.lin(a)rock-chips.com> mmc: dw_mmc: Factor out dw_mci_init_slot_caps Shawn Lin <shawn.lin(a)rock-chips.com> mmc: dw_mmc: Avoid accessing registers in runtime suspended state Geert Uytterhoeven <geert+renesas(a)glider.be> mmc: dw_mmc-k3: Fix out-of-bounds access through DT alias Adrian Hunter <adrian.hunter(a)intel.com> mmc: sdhci-pci: Fix S0i3 for Intel BYT-based controllers Takashi Iwai <tiwai(a)suse.de> ALSA: hda - Fix pincfg at resume on Lenovo T470 dock Hans de Goede <hdegoede(a)redhat.com> ALSA: hda: Add a power_save blacklist Takashi Iwai <tiwai(a)suse.de> ALSA: x86: Fix missing spinlock and mutex initializations Richard Fitzgerald <rf(a)opensource.cirrus.com> ALSA: control: Fix memory corruption risk in snd_ctl_elem_read Erik Veijola <erik.veijola(a)gmail.com> ALSA: usb-audio: Add a quirck for B&W PX headphones Alexander Steffen <Alexander.Steffen(a)infineon.com> tpm_tis_spi: Use DMA-safe memory for SPI transfers Arnd Bergmann <arnd(a)arndb.de> tpm: constify transmit data pointers Jeremy Boone <jeremy.boone(a)nccgroup.trust> tpm_tis: fix potential buffer overruns caused by bit glitches on the bus Jeremy Boone <jeremy.boone(a)nccgroup.trust> tpm_i2c_nuvoton: fix potential buffer overruns caused by bit glitches on the bus Jeremy Boone <jeremy.boone(a)nccgroup.trust> tpm_i2c_infineon: fix potential buffer overruns caused by bit glitches on the bus Jeremy Boone <jeremy.boone(a)nccgroup.trust> tpm: fix potential buffer overruns caused by bit glitches on the bus Jeremy Boone <jeremy.boone(a)nccgroup.trust> tpm: st33zp24: fix potential buffer overruns caused by bit glitches on the bus Emil Tantilov <emil.s.tantilov(a)intel.com> ixgbe: fix crash in build_skb Rx code path Hans de Goede <hdegoede(a)redhat.com> Bluetooth: btusb: Use DMI matching for QCA reset_resume quirking ------------- Diffstat: Documentation/networking/ip-sysctl.txt | 4 +- Makefile | 4 +- arch/arm/boot/dts/logicpd-som-lv.dtsi | 9 +- arch/arm/boot/dts/logicpd-torpedo-som.dtsi | 8 ++ arch/arm/boot/dts/rk3288-phycore-som.dtsi | 20 ---- arch/arm/kvm/hyp/Makefile | 5 + arch/arm/kvm/hyp/banked-sr.c | 4 + arch/arm/mach-mvebu/Kconfig | 4 +- arch/arm/plat-orion/common.c | 23 ++-- arch/parisc/include/asm/cacheflush.h | 1 + arch/parisc/include/asm/processor.h | 2 + arch/parisc/kernel/cache.c | 57 +++++----- arch/parisc/kernel/pacache.S | 22 ++++ arch/parisc/kernel/time.c | 11 +- arch/s390/kvm/interrupt.c | 25 ++++- arch/s390/kvm/kvm-s390.c | 79 +++++++------ arch/s390/kvm/kvm-s390.h | 5 +- arch/s390/kvm/priv.c | 9 +- arch/x86/include/asm/pgtable.h | 8 +- arch/x86/include/asm/pgtable_32.h | 1 + arch/x86/include/asm/pgtable_64.h | 1 + arch/x86/include/asm/pgtable_types.h | 10 ++ arch/x86/kernel/setup.c | 17 +-- arch/x86/kernel/setup_percpu.c | 17 +-- arch/x86/kvm/lapic.c | 11 +- arch/x86/kvm/mmu.c | 97 ++++++++-------- arch/x86/kvm/paging_tmpl.h | 18 +-- arch/x86/kvm/svm.c | 9 +- arch/x86/kvm/vmx.c | 9 +- arch/x86/kvm/x86.c | 12 +- arch/x86/mm/cpu_entry_area.c | 6 + arch/x86/mm/init_32.c | 15 +++ arch/x86/platform/intel-mid/intel-mid.c | 2 +- arch/x86/xen/suspend.c | 16 +++ block/blk-core.c | 2 +- block/blk-mq.c | 4 +- block/kyber-iosched.c | 1 + drivers/acpi/bus.c | 38 +++++-- drivers/bluetooth/btusb.c | 25 ++++- drivers/char/tpm/st33zp24/st33zp24.c | 4 +- drivers/char/tpm/tpm-interface.c | 4 + drivers/char/tpm/tpm2-cmd.c | 4 + drivers/char/tpm/tpm_i2c_infineon.c | 5 +- drivers/char/tpm/tpm_i2c_nuvoton.c | 8 +- drivers/char/tpm/tpm_tis.c | 2 +- drivers/char/tpm/tpm_tis_core.c | 9 +- drivers/char/tpm/tpm_tis_core.h | 4 +- drivers/char/tpm/tpm_tis_spi.c | 48 ++++---- drivers/cpufreq/s3c24xx-cpufreq.c | 8 +- drivers/edac/sb_edac.c | 2 +- drivers/md/md.c | 4 + drivers/media/dvb-frontends/m88ds3103.c | 7 +- drivers/mmc/host/dw_mmc-exynos.c | 1 + drivers/mmc/host/dw_mmc-k3.c | 4 + drivers/mmc/host/dw_mmc-rockchip.c | 1 + drivers/mmc/host/dw_mmc-zx.c | 1 + drivers/mmc/host/dw_mmc.c | 84 +++++++++----- drivers/mmc/host/dw_mmc.h | 2 + drivers/mmc/host/sdhci-pci-core.c | 35 +++++- drivers/net/ethernet/amd/xgbe/xgbe-drv.c | 2 +- drivers/net/ethernet/amd/xgbe/xgbe-pci.c | 2 + drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 8 ++ drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 10 +- drivers/net/ethernet/mellanox/mlx5/core/en_rx.c | 49 +++++--- .../net/ethernet/mellanox/mlx5/core/en_selftest.c | 3 +- drivers/net/ethernet/mellanox/mlx5/core/en_tx.c | 2 +- .../net/ethernet/mellanox/mlxsw/spectrum_router.c | 22 ++-- .../ethernet/mellanox/mlxsw/spectrum_switchdev.c | 29 ++++- drivers/net/ethernet/ti/cpsw.c | 16 ++- drivers/net/phy/phy.c | 2 +- drivers/net/ppp/ppp_generic.c | 9 ++ drivers/net/tun.c | 7 ++ drivers/net/virtio_net.c | 8 +- drivers/net/wan/hdlc_ppp.c | 5 +- drivers/nvme/host/rdma.c | 54 +++------ drivers/pci/pcie/aspm.c | 8 +- drivers/s390/net/qeth_core.h | 7 +- drivers/s390/net/qeth_core_main.c | 43 +++---- drivers/s390/net/qeth_l3.h | 34 +++++- drivers/s390/net/qeth_l3_main.c | 123 +++++++++------------ drivers/vfio/vfio_iommu_type1.c | 18 ++- fs/btrfs/sysfs.c | 8 +- fs/btrfs/transaction.c | 20 ++-- fs/direct-io.c | 3 +- include/linux/fs.h | 2 +- include/linux/nospec.h | 3 +- include/net/udplite.h | 1 + kernel/time/timer.c | 6 + net/bridge/br_sysfs_if.c | 3 + net/bridge/br_vlan.c | 2 + net/core/dev.c | 11 +- net/core/gen_estimator.c | 1 + net/ipv4/fib_semantics.c | 5 + net/ipv4/route.c | 10 +- net/ipv4/tcp_input.c | 24 ++-- net/ipv4/tcp_output.c | 33 +++++- net/ipv4/udp.c | 5 + net/ipv6/ip6_checksum.c | 5 + net/ipv6/sit.c | 2 +- net/netlink/af_netlink.c | 4 +- net/netlink/genetlink.c | 12 +- net/rxrpc/output.c | 2 +- net/sched/cls_api.c | 7 +- net/sched/cls_u32.c | 24 ++-- net/sctp/input.c | 5 +- net/sctp/ipv6.c | 10 +- net/sctp/protocol.c | 10 +- net/sctp/sm_make_chunk.c | 7 +- sound/core/control.c | 2 +- sound/pci/hda/hda_intel.c | 38 ++++++- sound/pci/hda/patch_realtek.c | 3 +- sound/usb/quirks-table.h | 47 ++++++++ sound/x86/intel_hdmi_audio.c | 2 + virt/kvm/kvm_main.c | 3 +- 114 files changed, 1065 insertions(+), 564 deletions(-)

7 years, 1 month

7
114
0 0

[PATCH] serial: mvebu-uart: fix tx lost characters

by Gabriel Matni

From: Gabriel Matni <gabriel.matni(a)exfo.com> Fixes missing characters on kernel console at low baud rates (i.e.9600). The driver should poll TX_RDY or TX_FIFO_EMP instead of TX_EMP to ensure that the transmitter holding register (THR) is ready to receive a new byte. TX_EMP tells us when it is possible to send a break sequence via SND_BRK_SEQ. While this also indicates that both the THR and the TSR are empty, it does not guarantee that a new byte can be written just yet. Fixes: 30530791a7a0 ("serial: mvebu-uart: initial support for Armada-3700 serial port") Reviewed-by: Miquel Raynal <miquel.raynal(a)bootlin.com> Acked-by: Gregory CLEMENT <gregory.clement(a)bootlin.com> Signed-off-by: Gabriel Matni <gabriel.matni(a)exfo.com> --- drivers/tty/serial/mvebu-uart.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/tty/serial/mvebu-uart.c b/drivers/tty/serial/mvebu-uart.c index a100e98259d7..f0df0640208e 100644 --- a/drivers/tty/serial/mvebu-uart.c +++ b/drivers/tty/serial/mvebu-uart.c @@ -618,7 +618,7 @@ static void wait_for_xmitr(struct uart_port *port) u32 val; readl_poll_timeout_atomic(port->membase + UART_STAT, val, - (val & STAT_TX_EMP), 1, 10000); + (val & STAT_TX_RDY(port)), 1, 10000); } static void mvebu_uart_console_putchar(struct uart_port *port, int ch) -- 2.7.4 > -----Original Message----- > From: Miquel Raynal [mailto:miquel.raynal@bootlin.com] > Sent: March 5, 2018 4:47 AM > To: Gabriel Matni <gabriel.matni(a)exfo.com> > Cc: linux-arm-kernel(a)lists.infradead.org; gregkh(a)linuxfoundation.org; > Grégory Clement <gregory.clement(a)bootlin.com>; Thomas Petazzoni > <thomas.petazzoni(a)bootlin.com> > Subject: Re: [PATCH] serial: mvebu_uart: fix tx lost characters > > Hi Gabriel, > > On Tue, 27 Feb 2018 21:56:03 +0000, Gabriel Matni > <gabriel.matni(a)exfo.com> wrote: > > > Hi Miquèl, > > > > > -----Original Message----- > > > From: Miquel Raynal [mailto:miquel.raynal@bootlin.com] > > > Sent: February 27, 2018 8:13 AM > > > To: Gabriel Matni <gabriel.matni(a)exfo.com> > > > Cc: linux-arm-kernel(a)lists.infradead.org; gregkh(a)linuxfoundation.org; > > > Grégory Clement <gregory.clement(a)bootlin.com>; Thomas Petazzoni > > > <thomas.petazzoni(a)bootlin.com> > > > Subject: Re: [PATCH] serial: mvebu_uart: fix tx lost characters > > > > > > Hi Gabriel, > > > > > > On Thu, 22 Feb 2018 20:30:56 +0000, Gabriel Matni > > > <gabriel.matni(a)exfo.com> wrote: > > > > > > > From: Gabriel Matni <gabriel.matni(a)exfo.com> > > > > > > > > Fixes missing characters on kernel console at low baud rates (i.e.9600). > > > > The driver should poll TX_RDY instead of TX_EMPTY to ensure that the > > > > transmitter holding is ready to receive a new byte. Polling TX_EMPTY > > > > isn't enough as the hardware buffer can become empty but not yet > ready > > > > for CPU to write the next byte. > > > > > > I am kind of sceptic with the explanation. My understanding is that: > > > - TX_EMPTY means the FIFO is empty > > I had a deeper look into the spec : TX_EMPTY != TX_FIFO_EMPTY. I was > referring to TX_FIFO_EMPTY here so my understanding of your solution was > wrong. > > > > - TX_RDY means the FIFO is not full, neither empty, it is a "half > > > loaded" state. > > > Polling TX_RDY instead of TX_EMPTY should work too, but I don't see why > it > > > would fix the loss of character by filling the FIFO when there are bytes in > it > > > rather than when it is fully empty. > > > > TX_READY is set whenever the UART Transmitter Holding register is ready > to > > receive a new byte. It gets cleared as soon as a new byte is written to the > > register. If the FIFO is empty or still has room, the ready will be set. > > > > TX_EMPTY tells us when it is possible to send a break sequence via > > SND_BRK_SEQ. While this also indicates that both the THR and the TSR are > > empty, it does not guarantee that a new byte can be written just yet. > > I do agree with this statement. You are right that polling on TX_EMPTY > looks wrong and we should definitively poll on TX_READY instead. > > > I am > > unsure about the FIFO status in this case as I can encounter > TX_FIFO_EMP=0 > > while TX_EMP=1, which suggests that the FIFO isn't necessarily empty > when > > TX_EMP is set. > > That is weird but maybe the TX_FIFO_EMPTY is asserted only when all > bits have been shifted, which is a 10-bit period after TSR is > cleared, while TX_EMPTY would not wait for these bits to be actually > shifted out and would be asserted a bit earlier, as soon as TSR is > cleared. That is just and idea. > > > > > Therefore, the driver can either poll TX_FIFO_EMP or TX_READY to know > > whether it can output a new byte. I personally like TX_READY as it takes > > advantage of the FIFO. > > True. > > > > > > > > > > > Signed-off-by: Gabriel Matni <gabriel.matni(a)exfo.com> > > Reviewed-by: Miquel Raynal <miquel.raynal(a)bootlin.com> > > Thanks, > Miquèl > > -- > Miquel Raynal, Bootlin (formerly Free Electrons) > Embedded Linux and Kernel engineering > https://bootlin.com

7 years, 1 month

3
5
0 0

[PATCH 0/3] Fix build on multi_v7_defconfig

by Sam Protsenko

Recent patches broke build on multi_v7_defconfig (ARM), on stable-rc/linux-4.4.y branch. The build error as follows: arch/arm/mach-omap2/omap_hwmod_7xx_data.c:2243:12: error: 'HWMOD_CLKDM_NOAUTO' undeclared here (not in a function) .flags = HWMOD_CLKDM_NOAUTO, ^~~~~~~~~~~~~~~~~~ Pull in missing dependency patches to fix that build error. 1. "Allow modules to disable HW_AUTO": this commit is needed to fix build error 2. "add usecounting support to autoidle APIs": this commit is a dependency for 1 3. "provide space for more hwmod flags": this is also a dependency for 1 Tested on TI BeagleBoard X15. Roger Quadros (1): ARM: OMAP2+ hwmod: Allow modules to disable HW_AUTO Sekhar Nori (1): ARM: OMAP2+: omap_hwmod: provide space for more hwmod flags Tero Kristo (1): ARM: OMAP2+: clockdomain: add usecounting support to autoidle APIs arch/arm/mach-omap2/clockdomain.c | 36 ++++++++++++++++++++++++------------ arch/arm/mach-omap2/clockdomain.h | 2 ++ arch/arm/mach-omap2/cpuidle44xx.c | 2 +- arch/arm/mach-omap2/omap-smp.c | 2 +- arch/arm/mach-omap2/omap_hwmod.c | 32 +++++++++++++++++--------------- arch/arm/mach-omap2/omap_hwmod.h | 7 ++++++- arch/arm/mach-omap2/pm.c | 8 +------- arch/arm/mach-omap2/powerdomain.c | 20 ++++++-------------- 8 files changed, 58 insertions(+), 51 deletions(-) -- 2.16.1

7 years, 1 month

3
6
0 0

patch "phy: allwinner: sun4i-usb: poll vbus changes on A23/A33 when driving" added to usb-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled phy: allwinner: sun4i-usb: poll vbus changes on A23/A33 when driving to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-testing branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will be merged to the usb-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. >From d7119224bfe6e8efbf821a52db7da9530d790f07 Mon Sep 17 00:00:00 2001 From: Chen-Yu Tsai <wens(a)csie.org> Date: Fri, 19 Jan 2018 17:25:41 +0800 Subject: phy: allwinner: sun4i-usb: poll vbus changes on A23/A33 when driving VBUS The AXP223 PMIC, like the AXP221, does not generate VBUS change interrupts when N_VBUSEN is used to drive VBUS for the OTG port on the board. This was not noticed until recently, as most A23/A33 boards use a GPIO pin that does not support interrupts for OTG ID detection. This forces the driver to use polling. However the A33-OlinuXino uses a pin that does support interrupts, so the driver uses them. However the VBUS interrupt never fires, and the driver never gets to update the VBUS status. This results in musb timing out waiting for VBUS to rise. This was worked around for the AXP221 by resorting to polling changes in commit 91d96f06a760 ("phy-sun4i-usb: Add workaround for missing Vbus det interrupts on A31"). This patch adds the A23 and A33 to the list of SoCs that need the workaround. Fixes: fc1f45ed3043 ("phy-sun4i-usb: Add support for the usb-phys on the sun8i-a33 SoC") Fixes: 123dfdbcfaf5 ("phy-sun4i-usb: Add support for the usb-phys on the sun8i-a23 SoC") Cc: <stable(a)vger.kernel.org> # 4.3.x: 68dbc2ce77bb phy-sun4i-usb: Use of_match_node to get model specific config data Cc: <stable(a)vger.kernel.org> # 4.3.x: 5cf700ac9d50 phy: phy-sun4i-usb: Fix optional gpios failing probe Cc: <stable(a)vger.kernel.org> # 4.3.x: 04e59a0211ff phy-sun4i-usb: Fix irq free conditions to match request conditions Cc: <stable(a)vger.kernel.org> # 4.3.x: 91d96f06a760 phy-sun4i-usb: Add workaround for missing Vbus det interrupts on A31 Cc: <stable(a)vger.kernel.org> # 4.3.x Signed-off-by: Chen-Yu Tsai <wens(a)csie.org> Acked-by: Maxime Ripard <maxime.ripard(a)free-electrons.com> Signed-off-by: Kishon Vijay Abraham I <kishon(a)ti.com> Signed-off-by: Kishon Vijay Abraham I <kishon(a)ti.com> --- drivers/phy/allwinner/phy-sun4i-usb.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c b/drivers/phy/allwinner/phy-sun4i-usb.c index bee798892b21..d4dcd39b8d76 100644 --- a/drivers/phy/allwinner/phy-sun4i-usb.c +++ b/drivers/phy/allwinner/phy-sun4i-usb.c @@ -411,11 +411,13 @@ static bool sun4i_usb_phy0_poll(struct sun4i_usb_phy_data *data) return true; /* - * The A31 companion pmic (axp221) does not generate vbus change - * interrupts when the board is driving vbus, so we must poll + * The A31/A23/A33 companion pmics (AXP221/AXP223) do not + * generate vbus change interrupts when the board is driving + * vbus using the N_VBUSEN pin on the pmic, so we must poll * when using the pmic for vbus-det _and_ we're driving vbus. */ - if (data->cfg->type == sun6i_a31_phy && + if ((data->cfg->type == sun6i_a31_phy || + data->cfg->type == sun8i_a33_phy) && data->vbus_power_supply && data->phys[0].regulator_on) return true; @@ -886,7 +888,7 @@ static const struct sun4i_usb_phy_cfg sun7i_a20_cfg = { static const struct sun4i_usb_phy_cfg sun8i_a23_cfg = { .num_phys = 2, - .type = sun4i_a10_phy, + .type = sun6i_a31_phy, .disc_thresh = 3, .phyctl_offset = REG_PHYCTL_A10, .dedicated_clocks = true, -- 2.16.2

7 years, 1 month

1
0
0 0

[PATCH] spi: Fix unregistration of controller with fixed SPI bus number

by Jarkko Nikula

Commit 9b61e302210e (spi: Pick spi bus number from Linux idr or spi alias) ceased to unregister SPI buses with fixed bus numbers. Moreover this is visible only if CONFIG_SPI_DEBUG=y is set or when trying to re-register the same SPI controller. rmmod spi_pxa2xx_platform (with CONFIG_SPI_DEBUG=y): [ 26.788362] spi_master spi1: attempting to delete unregistered controller [spi1] modprobe spi_pxa2xx_platform: [ 37.883137] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:19.0/pxa2xx-spi.12/spi_master/spi1' [ 37.894984] CPU: 1 PID: 1467 Comm: modprobe Not tainted 4.16.0-rc4+ #21 [ 37.902384] Call Trace: ... [ 38.122680] kobject_add_internal failed for spi1 with -EEXIST, don't try to register things with the same name in the same directory. [ 38.136154] WARNING: CPU: 1 PID: 1467 at lib/kobject.c:238 kobject_add_internal+0x2a5/0x2f0 ... [ 38.513817] pxa2xx-spi pxa2xx-spi.12: problem registering spi master [ 38.521036] pxa2xx-spi: probe of pxa2xx-spi.12 failed with error -17 Fix this by not returning immediately from spi_unregister_controller() if idr_find() doesn't find controller with given ID/bus number. It finds only those controllers that were registered with dynamic SPI bus numbers. Only conditional cleanup between dynamic and fixed bus numbers is to remove allocated IDR. Fixes: 9b61e302210e (spi: Pick spi bus number from Linux idr or spi alias) Cc: stable(a)vger.kernel.org Signed-off-by: Jarkko Nikula <jarkko.nikula(a)linux.intel.com> --- This doesn't apply to v4.14 without commit 67f7b2781faf ("spi: fix use-after-free at controller deregistration"). --- drivers/spi/spi.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index b33a727a0158..e90fd442b3f0 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -2254,12 +2254,6 @@ void spi_unregister_controller(struct spi_controller *ctlr) mutex_lock(&board_lock); found = idr_find(&spi_master_idr, id); mutex_unlock(&board_lock); - if (found != ctlr) { - dev_dbg(&ctlr->dev, - "attempting to delete unregistered controller [%s]\n", - dev_name(&ctlr->dev)); - return; - } if (ctlr->queued) { if (spi_destroy_queue(ctlr)) dev_err(&ctlr->dev, "queue remove failed\n"); @@ -2272,7 +2266,8 @@ void spi_unregister_controller(struct spi_controller *ctlr) device_unregister(&ctlr->dev); /* free bus id */ mutex_lock(&board_lock); - idr_remove(&spi_master_idr, id); + if (found == ctlr) + idr_remove(&spi_master_idr, id); mutex_unlock(&board_lock); } EXPORT_SYMBOL_GPL(spi_unregister_controller); -- 2.16.1

7 years, 1 month

2
1
0 0

[RESEND PATCH] spi: Fix unregistration of controller with fixed SPI bus number

by Jarkko Nikula

Commit 9b61e302210e (spi: Pick spi bus number from Linux idr or spi alias) ceased to unregister SPI buses with fixed bus numbers. Moreover this is visible only if CONFIG_SPI_DEBUG=y is set or when trying to re-register the same SPI controller. rmmod spi_pxa2xx_platform (with CONFIG_SPI_DEBUG=y): [ 26.788362] spi_master spi1: attempting to delete unregistered controller [spi1] modprobe spi_pxa2xx_platform: [ 37.883137] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:19.0/pxa2xx-spi.12/spi_master/spi1' [ 37.894984] CPU: 1 PID: 1467 Comm: modprobe Not tainted 4.16.0-rc4+ #21 [ 37.902384] Call Trace: ... [ 38.122680] kobject_add_internal failed for spi1 with -EEXIST, don't try to register things with the same name in the same directory. [ 38.136154] WARNING: CPU: 1 PID: 1467 at lib/kobject.c:238 kobject_add_internal+0x2a5/0x2f0 ... [ 38.513817] pxa2xx-spi pxa2xx-spi.12: problem registering spi master [ 38.521036] pxa2xx-spi: probe of pxa2xx-spi.12 failed with error -17 Fix this by not returning immediately from spi_unregister_controller() if idr_find() doesn't find controller with given ID/bus number. It finds only those controllers that were registered with dynamic SPI bus numbers. Only conditional cleanup between dynamic and fixed bus numbers is to remove allocated IDR. Fixes: 9b61e302210e (spi: Pick spi bus number from Linux idr or spi alias) Cc: stable(a)vger.kernel.org Signed-off-by: Jarkko Nikula <jarkko.nikula(a)linux.intel.com> --- This doesn't apply to v4.14 without commit 67f7b2781faf ("spi: fix use-after-free at controller deregistration"). --- drivers/spi/spi.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index b33a727a0158..e90fd442b3f0 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -2254,12 +2254,6 @@ void spi_unregister_controller(struct spi_controller *ctlr) mutex_lock(&board_lock); found = idr_find(&spi_master_idr, id); mutex_unlock(&board_lock); - if (found != ctlr) { - dev_dbg(&ctlr->dev, - "attempting to delete unregistered controller [%s]\n", - dev_name(&ctlr->dev)); - return; - } if (ctlr->queued) { if (spi_destroy_queue(ctlr)) dev_err(&ctlr->dev, "queue remove failed\n"); @@ -2272,7 +2266,8 @@ void spi_unregister_controller(struct spi_controller *ctlr) device_unregister(&ctlr->dev); /* free bus id */ mutex_lock(&board_lock); - idr_remove(&spi_master_idr, id); + if (found == ctlr) + idr_remove(&spi_master_idr, id); mutex_unlock(&board_lock); } EXPORT_SYMBOL_GPL(spi_unregister_controller); -- 2.16.2

7 years, 1 month

1
0
0 0

[PATCH][v3] mtd: rawnand: fsl_ifc: Fix eccstat array overflow for IFC ver >= 2.0.0

by Jagdish Gediya

Number of ECC status registers i.e. (ECCSTATx) has been increased in IFC version 2.0.0 due to increase in SRAM size. This is causing eccstat array to over flow. So, replace eccstat array with u32 variable to make it fail-safe and independent of number of ECC status registers or SRAM size. Fixes: bccb06c353af ("mtd: nand: ifc: update bufnum mask for ver >= 2.0.0") Cc: stable(a)vger.kernel.org # 3.18+ Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha(a)nxp.com> Signed-off-by: Jagdish Gediya <jagdish.gediya(a)nxp.com> --- Changes for v2: Incorporated comments from Miquel Raynal and Boris Brezillon - Updated patch subject - Remove usage of eccstat array - Added Cc: stable(a)vger.kernel.org Changes for v3: Incorporated comments from Boris Brezillon - Added fixes tag drivers/mtd/nand/fsl_ifc_nand.c | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c index 4872a7b..9390cbd 100644 --- a/drivers/mtd/nand/fsl_ifc_nand.c +++ b/drivers/mtd/nand/fsl_ifc_nand.c @@ -173,14 +173,9 @@ static void set_addr(struct mtd_info *mtd, int column, int page_addr, int oob) /* returns nonzero if entire page is blank */ static int check_read_ecc(struct mtd_info *mtd, struct fsl_ifc_ctrl *ctrl, - u32 *eccstat, unsigned int bufnum) + u32 eccstat, unsigned int bufnum) { - u32 reg = eccstat[bufnum / 4]; - int errors; - - errors = (reg >> ((3 - bufnum % 4) * 8)) & 15; - - return errors; + return (eccstat >> ((3 - bufnum % 4) * 8)) & 15; } /* @@ -193,7 +188,7 @@ static void fsl_ifc_run_command(struct mtd_info *mtd) struct fsl_ifc_ctrl *ctrl = priv->ctrl; struct fsl_ifc_nand_ctrl *nctrl = ifc_nand_ctrl; struct fsl_ifc_runtime __iomem *ifc = ctrl->rregs; - u32 eccstat[4]; + u32 eccstat; int i; /* set the chip select for NAND Transaction */ @@ -237,10 +232,18 @@ static void fsl_ifc_run_command(struct mtd_info *mtd) else eccstat_regs = ifc->ifc_nand.v1_nand_eccstat; - for (i = sector / 4; i <= sector_end / 4; i++) - eccstat[i] = ifc_in32(&eccstat_regs[i]); + eccstat = 0; for (i = sector; i <= sector_end; i++) { + + /* + * sector is not necessarily aligned on 4 and + * we need to read the eccstat in this case, + * hence the sector test. + */ + if ((i % 4 == 0) || (sector == sector_end)) + eccstat = ifc_in32(&eccstat_regs[i / 4]); + errors = check_read_ecc(mtd, ctrl, eccstat, i); if (errors == 15) { -- 1.9.1

7 years, 1 month

2
1
0 0

Patch "ARM: dts: r8a7794: Add DU1 clock to device tree" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: dts: r8a7794: Add DU1 clock to device tree to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: arm-dts-r8a7794-add-du1-clock-to-device-tree.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 1764f8081f1524bf629e0744b277db751281ff56 Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven <geert+renesas(a)glider.be> Date: Tue, 28 Mar 2017 12:45:30 +0200 Subject: ARM: dts: r8a7794: Add DU1 clock to device tree From: Geert Uytterhoeven <geert+renesas(a)glider.be> commit 1764f8081f1524bf629e0744b277db751281ff56 upstream. Add the missing module clock for the second channel of the display unit. Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be> Acked-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Signed-off-by: Simon Horman <horms+renesas(a)verge.net.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/boot/dts/r8a7794.dtsi | 8 +++++--- include/dt-bindings/clock/r8a7794-clock.h | 1 + 2 files changed, 6 insertions(+), 3 deletions(-) --- a/arch/arm/boot/dts/r8a7794.dtsi +++ b/arch/arm/boot/dts/r8a7794.dtsi @@ -1261,19 +1261,21 @@ clocks = <&mp_clk>, <&hp_clk>, <&zs_clk>, <&p_clk>, <&p_clk>, <&zs_clk>, <&zs_clk>, <&p_clk>, <&p_clk>, <&p_clk>, <&p_clk>, - <&zx_clk>; + <&zx_clk>, <&zx_clk>; #clock-cells = <1>; clock-indices = < R8A7794_CLK_EHCI R8A7794_CLK_HSUSB R8A7794_CLK_HSCIF2 R8A7794_CLK_SCIF5 R8A7794_CLK_SCIF4 R8A7794_CLK_HSCIF1 R8A7794_CLK_HSCIF0 R8A7794_CLK_SCIF3 R8A7794_CLK_SCIF2 R8A7794_CLK_SCIF1 - R8A7794_CLK_SCIF0 R8A7794_CLK_DU0 + R8A7794_CLK_SCIF0 + R8A7794_CLK_DU1 R8A7794_CLK_DU0 >; clock-output-names = "ehci", "hsusb", "hscif2", "scif5", "scif4", "hscif1", "hscif0", - "scif3", "scif2", "scif1", "scif0", "du0"; + "scif3", "scif2", "scif1", "scif0", + "du1", "du0"; }; mstp8_clks: mstp8_clks@e6150990 { compatible = "renesas,r8a7794-mstp-clocks", "renesas,cpg-mstp-clocks"; --- a/include/dt-bindings/clock/r8a7794-clock.h +++ b/include/dt-bindings/clock/r8a7794-clock.h @@ -81,6 +81,7 @@ #define R8A7794_CLK_SCIF2 19 #define R8A7794_CLK_SCIF1 20 #define R8A7794_CLK_SCIF0 21 +#define R8A7794_CLK_DU1 23 #define R8A7794_CLK_DU0 24 /* MSTP8 */ Patches currently in stable-queue which might be from geert+renesas(a)glider.be are queue-4.9/arm64-dts-r8a7796-remove-unit-address-and-reg-from-integrated-cache.patch queue-4.9/arm-dts-r8a7791-remove-unit-address-and-reg-from-integrated-cache.patch queue-4.9/arm-dts-r7s72100-fix-ethernet-clock-parent.patch queue-4.9/arm-dts-r8a7791-correct-parent-of-ssi-clocks.patch queue-4.9/arm-dts-r8a7794-add-du1-clock-to-device-tree.patch queue-4.9/arm-dts-silk-correct-clock-of-du1.patch queue-4.9/arm-dts-r8a7792-remove-unit-address-and-reg-from-integrated-cache.patch queue-4.9/arm-dts-koelsch-correct-clock-frequency-of-x2-du-clock-input.patch queue-4.9/arm-dts-r8a7794-correct-clock-of-du1.patch queue-4.9/arm-dts-r8a7794-remove-unit-address-and-reg-from-integrated-cache.patch queue-4.9/arm-dts-r8a7793-remove-unit-address-and-reg-from-integrated-cache.patch queue-4.9/arm-dts-r8a7793-correct-parent-of-ssi-clocks.patch queue-4.9/arm-dts-r8a7790-correct-parent-of-ssi-clocks.patch

7 years, 1 month

1
0
0 0

patch "staging: comedi: ni_mio_common: ack ai fifo error interrupts." added to staging-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: comedi: ni_mio_common: ack ai fifo error interrupts. to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-next branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. >From e1d9fc04c41840a4688ef6ce90b6dcca157ea4d7 Mon Sep 17 00:00:00 2001 From: Frank Mori Hess <fmh6jj(a)gmail.com> Date: Thu, 15 Mar 2018 10:25:44 +0000 Subject: staging: comedi: ni_mio_common: ack ai fifo error interrupts. Ack ai fifo error interrupts in interrupt handler to clear interrupt after fifo overflow. It should prevent lock-ups after the ai fifo overflows. Cc: <stable(a)vger.kernel.org> # v4.2+ Signed-off-by: Frank Mori Hess <fmh6jj(a)gmail.com> Signed-off-by: Ian Abbott <abbotti(a)mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/comedi/drivers/ni_mio_common.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/staging/comedi/drivers/ni_mio_common.c b/drivers/staging/comedi/drivers/ni_mio_common.c index d6eb55b41814..e40a2c0a9543 100644 --- a/drivers/staging/comedi/drivers/ni_mio_common.c +++ b/drivers/staging/comedi/drivers/ni_mio_common.c @@ -1275,6 +1275,8 @@ static void ack_a_interrupt(struct comedi_device *dev, unsigned short a_status) ack |= NISTC_INTA_ACK_AI_START; if (a_status & NISTC_AI_STATUS1_STOP) ack |= NISTC_INTA_ACK_AI_STOP; + if (a_status & NISTC_AI_STATUS1_OVER) + ack |= NISTC_INTA_ACK_AI_ERR; if (ack) ni_stc_writew(dev, ack, NISTC_INTA_ACK_REG); } -- 2.16.2

7 years, 1 month

1
0
0 0

[PATCH 4.14 000/109] 4.14.28-stable review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.14.28 release. There are 109 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Mar 18 15:22:53 UTC 2018. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.28-rc… or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y and the diffstat can be found below. thanks, greg k-h ------------- Pseudo-Shortlog of commits: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Linux 4.14.28-rc1 Anusha Srivatsa <anusha.srivatsa(a)intel.com> drm/i915/glk: Disable Guc and HuC on GLK Sinan Kaya <okaya(a)codeaurora.org> dmaengine: qcom_hidma: check pending interrupts Arnd Bergmann <arnd(a)arndb.de> IB/mlx5: revisit -Wmaybe-uninitialized warning Mimi Zohar <zohar(a)linux.vnet.ibm.com> ima: relax requiring a file signature for new files with zero length Davidlohr Bueso <dave(a)stgolabs.net> locking/locktorture: Fix num reader/writer corner cases SeongJae Park <sj38.park(a)gmail.com> rcutorture/configinit: Fix build directory error message Mahesh Bandewar <maheshb(a)google.com> ipvlan: add L2 check for packets arriving via virtual devices Christophe Leroy <christophe.leroy(a)c-s.fr> Fix misannotated out-of-line _copy_to_user() Adrian Hunter <adrian.hunter(a)intel.com> mmc: mmc_test: Ensure command queue is disabled for testing Dan Carpenter <dan.carpenter(a)oracle.com> ASoC: nuc900: Fix a loop timeout test Horia Geantă <horia.geanta(a)nxp.com> crypto: caam/qi - use correct print specifier for size_t Luca Coelho <luciano.coelho(a)intel.com> mac80211: remove BUG() when interface type is invalid Adiel Aloni <adiel.aloni(a)intel.com> mac80211_hwsim: enforce PS_MANUAL_POLL to be set after PS_ENABLED Chris Wilson <chris(a)chris-wilson.co.uk> agp/intel: Flush all chipset writes after updating the GGTT Geert Uytterhoeven <geert+renesas(a)glider.be> arm64: dts: renesas: salvator-common: Add EthernetAVB PHY reset Nicholas Piggin <npiggin(a)gmail.com> powerpc/64: Don't trace irqs-off at interrupt return to soft-disabled context Josh Poimboeuf <jpoimboe(a)redhat.com> powerpc/modules: Don't try to restore r2 after a sibling call Yong Zhao <yong.zhao(a)amd.com> drm/amdkfd: Fix memory leaks in kfd topology Stephen Hemminger <stephen(a)networkplumber.org> veth: set peer GSO values John Fastabend <john.fastabend(a)gmail.com> net: sched: drop qdisc_reset from dev_graft_qdisc Toshiaki Makita <makita.toshiaki(a)lab.ntt.co.jp> virtio_net: Disable interrupts if napi_complete_done rescheduled napi Gustavo A. R. Silva <garsilva(a)embeddedor.com> media: davinci: vpif_capture: add NULL check on devm_kzalloc return value Dan Carpenter <dan.carpenter(a)oracle.com> media: cpia2: Fix a couple off by one bugs Heinz Mauelshagen <heinzm(a)redhat.com> dm raid: fix raid set size revalidation Kieran Bingham <kieran.bingham+renesas(a)ideasonboard.com> media: vsp1: Prevent suspending and resuming DRM pipelines Xose Vazquez Perez <xose.vazquez(a)gmail.com> scsi: dh: add new rdac devices Xose Vazquez Perez <xose.vazquez(a)gmail.com> scsi: devinfo: apply to HP XP the same flags as Hitachi VSP Bart Van Assche <bart.vanassche(a)wdc.com> scsi: core: scsi_get_device_flags_keyed(): Always return device flags Michael Chan <michael.chan(a)broadcom.com> bnxt_en: Don't print "Link speed -1 no longer supported" messages. Tobias Jordan <Tobias.Jordan(a)elektrobit.com> spi: sun6i: disable/unprepare clocks on remove Julien BOIBESSOT <julien.boibessot(a)armadeus.com> tools/usbip: fixes build with musl libc toolchain Ben Greear <greearb(a)candelatech.com> ath10k: fix invalid STS_CAP_OFFSET_MASK Limin Zhu <liminzhu(a)marvell.com> mwifiex: cfg80211: do not change virtual interface during scan processing Srinivas Kandagatla <srinivas.kandagatla(a)linaro.org> clk: qcom: msm8916: fix mnd_width for codec_digcodec Monk Liu <Monk.Liu(a)amd.com> drm/amdgpu:fix virtual dce bug Sara Sharon <sara.sharon(a)intel.com> iwlwifi: mvm: avoid dumping assert log when device is stopped Thomas Richter <tmricht(a)linux.vnet.ibm.com> perf annotate: Fix objdump comment parsing for Intel mov dissassembly Thomas Richter <tmricht(a)linux.vnet.ibm.com> perf annotate: Fix unnecessary memory allocation for s390x Takeshi Kihara <takeshi.kihara.df(a)renesas.com> pinctrl: sh-pfc: r8a7795-es1: Fix MOD_SEL1 bit[25:24] to 0x3 when using STP_ISEN_1_D Fabrizio Castro <fabrizio.castro(a)bp.renesas.com> pinctrl: sh-pfc: r8a7791: Add can_clk function Jernej Skrabec <jernej.skrabec(a)siol.net> drm/sun4i: Fix format mask in DE2 driver Axel Lin <axel.lin(a)ingics.com> pwm: stmpe: Fix wrong register offset for hwpwm=2 case Li Dongyang <dongyang.li(a)anu.edu.au> scsi: ses: don't ask for diagnostic pages repeatedly during probe Monk Liu <Monk.Liu(a)amd.com> drm/amdgpu:fix random missing of FLR NOTIFY Peter Ujfalusi <peter.ujfalusi(a)ti.com> dmaengine: amba-pl08x: Use vchan_terminate_vdesc() instead of desc_free Peter Ujfalusi <peter.ujfalusi(a)ti.com> dmaengine: bcm2835-dma: Use vchan_terminate_vdesc() instead of desc_free Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> cpufreq: Fix governor module removal race Manikanta Pubbisetty <mpubbise(a)qti.qualcomm.com> ath10k: update tdls teardown state to target Peter Meerwald-Stadler <pmeerw(a)pmeerw.net> iio: health: max30102: Add power enable parameter to get_temp function Stefan Brüns <stefan.bruens(a)rwth-aachen.de> iio: adc: ina2xx: Shift bus voltage register to mask flag bits Philipp Zabel <p.zabel(a)pengutronix.de> drm/etnaviv: make THERMAL selectable Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> power: supply: ab8500_charger: Bail out in case of error in 'ab8500_charger_init_hw_registers()' Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> power: supply: ab8500_charger: Fix an error handling path Tero Kristo <t-kristo(a)ti.com> clk: ti: clkctrl: add support for retrying failed init Bjorn Andersson <bjorn.andersson(a)linaro.org> leds: pm8058: Silence pointer to integer size warning Yossef Efraim <yossefe(a)mellanox.com> xfrm: Fix xfrm_replay_overflow_offload_esn Eric W. Biederman <ebiederm(a)xmission.com> userns: Don't fail follow_automount based on s_user_ns Jagdish Gediya <jagdish.gediya(a)nxp.com> mtd: nand: ifc: update bufnum mask for ver >= 2.0.0 Andrew F. Davis <afd(a)ti.com> ARM: dts: omap3-n900: Fix the audio CODEC's reset pin Andrew F. Davis <afd(a)ti.com> ARM: dts: am335x-pepper: Fix the audio CODEC's reset pin Sunil Goutham <sgoutham(a)cavium.com> net: thunderx: Set max queue count taking XDP_TX into account Miquel Raynal <miquel.raynal(a)free-electrons.com> mtd: nand: fix interpretation of NAND_CMD_NONE in nand_command[_lp]() Lorenzo Colitti <lorenzo(a)google.com> net: xfrm: allow clearing socket xfrm policies. Alexey Khoroshilov <khoroshilov(a)ispras.ru> rtc: brcmstb-waketimer: fix error handling in brcmstb_waketmr_probe() Michael Hennerich <michael.hennerich(a)analog.com> net: ieee802154: adf7242: Fix bug if defined DEBUG Luis R. Rodriguez <mcgrof(a)kernel.org> test_firmware: fix setting old custom fw path back on exit Colin Ian King <colin.king(a)canonical.com> crypto: cavium - fix memory leak on info Pierre <pinaraf(a)pinaraf.info> crypto: ecc - Fix NULL pointer deref. on no default_rng Paul E. McKenney <paulmck(a)linux.vnet.ibm.com> sched: Stop resched_cpu() from sending IPIs to offline CPUs Paul E. McKenney <paulmck(a)linux.vnet.ibm.com> sched: Stop switched_to_rt() from sending IPIs to offline CPUs Johan Hovold <johan(a)kernel.org> USB: ledtrig-usbport: fix of-node leak Adam Thomson <Adam.Thomson.Opensource(a)diasemi.com> typec: tcpm: fusb302: Resolve out of order messaging events Colin Ian King <colin.king(a)canonical.com> staging: rtl8822be: fix missing null check on dev_alloc_skb return Felix Kuehling <Felix.Kuehling(a)amd.com> drm/amdgpu: fix get_max_engine_clock_in_mhz Simon Shields <simon(a)lineageos.org> ARM: dts: exynos: Correct Trats2 panel reset line Yixun Lan <yixun.lan(a)amlogic.com> clk: meson: gxbb: fix wrong clock for SARADC/SANA Simon Horman <horms+renesas(a)verge.net.au> ARM: dts: koelsch: Move cec_clock to root node Emmanuel Grumbach <emmanuel.grumbach(a)intel.com> iwlwifi: mvm: rs: don't override the rate history in the search cycle Jiri Kosina <jkosina(a)suse.cz> HID: elo: clear BTN_LEFT mapping Hans de Goede <hdegoede(a)redhat.com> HID: multitouch: Only look at non touch fields in first packet of a frame Ville Syrjälä <ville.syrjala(a)linux.intel.com> video/hdmi: Allow "empty" HDMI infoframes Chris Wilson <chris(a)chris-wilson.co.uk> dma-buf/fence: Fix lock inversion within dma-fence-array Jani Nikula <jani.nikula(a)intel.com> drm/edid: set ELD connector type in drm_edid_to_eld() Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Revert "btrfs: use proper endianness accessors for super_copy" Steffen Maier <maier(a)linux.vnet.ibm.com> dm mpath: fix passing integrity data Greentime Hu <green.hu(a)gmail.com> earlycon: add reg-offset to physical address before mapping Sebastian Andrzej Siewior <bigeasy(a)linutronix.de> serial: core: mark port as initialized in autoconfig Nikola Ciprich <nikola.ciprich(a)linuxbox.cz> serial: 8250_pci: Add Brainboxes UC-260 4 port serial device Roger Quadros <rogerq(a)ti.com> usb: dwc3: Fix lock-up on ID change during system suspend/resume Xinyong <xinyong.fang(a)linux.alibaba.com> usb: gadget: f_fs: Fix use-after-free in ffs_fs_kill_sb() Pete Zaitcev <zaitcev(a)kotori.zaitcev.us> usb: usbmon: Read text within supplied buffer size Danilo Krummrich <danilokrummrich(a)dk-develop.de> usb: quirks: add control message delay for 1b1c:1b20 Colin Ian King <colin.king(a)canonical.com> usbip: vudc: fix null pointer dereference on udc->lock Teijo Kinnunen <teijo.kinnunen(a)code-q.fi> USB: storage: Add JMicron bridge 152d:2567 to unusual_devs.h Joel Fernandes <joelaf(a)google.com> staging: android: ashmem: Fix lockdep issue during llseek Frank Mori Hess <fmh6jj(a)gmail.com> staging: comedi: fix comedi_nsamples_left. Oliver Neukum <oneukum(a)suse.com> uas: fix comparison for error code Jonas Danielsson <jonas(a)orbital-systems.com> tty/serial: atmel: add new version check for usart Ulrich Hecht <ulrich.hecht+renesas(a)gmail.com> serial: sh-sci: prevent lockup on full TTY buffers Mathias Nyman <mathias.nyman(a)linux.intel.com> xhci: fix endpoint context tracer output Kai-Heng Feng <kai.heng.feng(a)canonical.com> xhci: Fix front USB ports on ASUS PRIME B350M-A Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com> usb: host: xhci-rcar: add support for r8a77965 Hans de Goede <hdegoede(a)redhat.com> ASoC: rt5651: Fix regcache sync errors on resume Richard Fitzgerald <rf(a)opensource.cirrus.com> ASoC: wm_adsp: For TLV controls only register TLV get/set Fabio Estevam <fabio.estevam(a)nxp.com> ASoC: sgtl5000: Fix suspend/resume Yong Deng <yong.deng(a)magewell.com> ASoC: sun4i-i2s: Fix RX slot number of SUN8I H.J. Lu <hjl.tools(a)gmail.com> x86: Treat R_X86_64_PLT32 as R_X86_64_PC32 Andrew Lunn <andrew(a)lunn.ch> net: phy: Restore phy_resume() locking assumption Russell King <rmk+kernel(a)armlinux.org.uk> net: phy: fix resume handling ------------- Diffstat: Documentation/devicetree/bindings/usb/usb-xhci.txt | 1 + Makefile | 4 +- arch/arm/boot/dts/am335x-pepper.dts | 2 +- arch/arm/boot/dts/exynos4412-trats2.dts | 2 +- arch/arm/boot/dts/omap3-n900.dts | 4 +- arch/arm/boot/dts/r8a7791-koelsch.dts | 12 +- arch/arm64/boot/dts/renesas/salvator-common.dtsi | 1 + arch/powerpc/include/asm/code-patching.h | 1 + arch/powerpc/kernel/entry_64.S | 10 +- arch/powerpc/kernel/module_64.c | 12 +- arch/powerpc/lib/code-patching.c | 5 + arch/x86/kernel/machine_kexec_64.c | 1 + arch/x86/kernel/module.c | 1 + arch/x86/tools/relocs.c | 3 + crypto/ecc.c | 2 +- drivers/base/Kconfig | 1 + drivers/char/agp/intel-gtt.c | 2 + drivers/clk/meson/gxbb.c | 4 +- drivers/clk/qcom/gcc-msm8916.c | 1 + drivers/clk/ti/clkctrl.c | 12 +- drivers/cpufreq/cpufreq.c | 6 + drivers/crypto/caam/caamalg_qi.c | 6 +- drivers/crypto/cavium/cpt/cptvf_reqmanager.c | 3 +- drivers/dma-buf/dma-fence-array.c | 14 ++- drivers/dma/amba-pl08x.c | 11 +- drivers/dma/bcm2835-dma.c | 10 +- drivers/dma/qcom/hidma_ll.c | 9 +- drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 7 +- drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 4 +- drivers/gpu/drm/amd/amdgpu/mxgpu_ai.c | 14 ++- drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 10 ++ drivers/gpu/drm/drm_edid.c | 9 +- drivers/gpu/drm/etnaviv/Kconfig | 9 ++ drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 8 +- drivers/gpu/drm/i915/intel_guc_loader.c | 9 -- drivers/gpu/drm/i915/intel_huc.c | 11 -- drivers/gpu/drm/sun4i/sun8i_mixer.h | 2 +- drivers/hid/hid-elo.c | 6 + drivers/hid/hid-multitouch.c | 17 ++- drivers/iio/adc/ina2xx-adc.c | 26 +++-- drivers/iio/health/max30102.c | 36 +++--- drivers/infiniband/hw/mlx5/mr.c | 3 + drivers/leds/leds-pm8058.c | 2 +- drivers/md/dm-mpath.c | 5 +- drivers/md/dm-raid.c | 30 +++-- drivers/media/platform/davinci/vpif_capture.c | 2 + drivers/media/platform/vsp1/vsp1_drv.c | 16 ++- drivers/media/usb/cpia2/cpia2_v4l.c | 4 +- drivers/mmc/core/mmc_test.c | 11 +- drivers/mtd/nand/fsl_ifc_nand.c | 7 ++ drivers/mtd/nand/nand_base.c | 9 +- drivers/net/ethernet/broadcom/bnxt/bnxt.c | 10 +- drivers/net/ethernet/cavium/thunder/nicvf_main.c | 5 + drivers/net/ieee802154/adf7242.c | 4 +- drivers/net/ipvlan/ipvlan_core.c | 4 + drivers/net/phy/at803x.c | 4 - drivers/net/phy/phy.c | 9 +- drivers/net/phy/phy_device.c | 20 +++- drivers/net/veth.c | 3 + drivers/net/virtio_net.c | 9 +- drivers/net/wireless/ath/ath10k/mac.c | 10 ++ drivers/net/wireless/ath/ath10k/wmi.h | 3 +- drivers/net/wireless/intel/iwlwifi/mvm/rs.c | 4 +- drivers/net/wireless/intel/iwlwifi/mvm/utils.c | 6 + drivers/net/wireless/mac80211_hwsim.c | 17 ++- drivers/net/wireless/marvell/mwifiex/cfg80211.c | 6 + drivers/pinctrl/sh-pfc/pfc-r8a7791.c | 22 +++- drivers/pinctrl/sh-pfc/pfc-r8a7795-es1.c | 2 +- drivers/power/supply/ab8500_charger.c | 6 +- drivers/pwm/pwm-stmpe.c | 2 +- drivers/rtc/rtc-brcmstb-waketimer.c | 15 ++- drivers/scsi/scsi_devinfo.c | 9 +- drivers/scsi/scsi_dh.c | 5 +- drivers/scsi/ses.c | 11 +- drivers/spi/spi-sun6i.c | 2 +- drivers/staging/android/ashmem.c | 15 ++- drivers/staging/comedi/drivers.c | 3 +- drivers/staging/rtlwifi/rtl8822be/fw.c | 2 + drivers/staging/typec/fusb302/fusb302.c | 21 +++- drivers/tty/serial/8250/8250_pci.c | 11 ++ drivers/tty/serial/atmel_serial.c | 1 + drivers/tty/serial/earlycon.c | 3 +- drivers/tty/serial/serial_core.c | 2 + drivers/tty/serial/sh-sci.c | 2 + drivers/usb/core/ledtrig-usbport.c | 8 +- drivers/usb/core/message.c | 4 + drivers/usb/core/quirks.c | 3 +- drivers/usb/dwc3/core.c | 2 +- drivers/usb/gadget/function/f_fs.c | 1 - drivers/usb/host/xhci-pci.c | 3 + drivers/usb/host/xhci-rcar.c | 4 + drivers/usb/host/xhci.c | 3 + drivers/usb/host/xhci.h | 23 ++-- drivers/usb/mon/mon_text.c | 126 +++++++++++++-------- drivers/usb/storage/uas.c | 2 +- drivers/usb/storage/unusual_devs.h | 7 ++ drivers/usb/usbip/vudc_sysfs.c | 8 +- drivers/video/hdmi.c | 51 +++++---- fs/btrfs/sysfs.c | 8 +- fs/btrfs/transaction.c | 20 ++-- fs/namei.c | 3 - include/linux/dma-fence-array.h | 3 + include/linux/phy.h | 1 + include/linux/usb/quirks.h | 3 + kernel/locking/locktorture.c | 76 +++++++------ kernel/sched/core.c | 3 +- kernel/sched/rt.c | 2 +- lib/usercopy.c | 2 +- net/mac80211/iface.c | 2 +- net/sched/sch_generic.c | 28 +++-- net/xfrm/xfrm_policy.c | 2 +- net/xfrm/xfrm_replay.c | 3 +- net/xfrm/xfrm_state.c | 7 ++ security/integrity/ima/ima_appraise.c | 3 +- sound/soc/codecs/rt5651.c | 1 + sound/soc/codecs/sgtl5000.c | 11 ++ sound/soc/codecs/wm_adsp.c | 14 ++- sound/soc/nuc900/nuc900-ac97.c | 4 +- sound/soc/sunxi/sun4i-i2s.c | 2 +- tools/perf/arch/s390/annotate/instructions.c | 3 +- tools/perf/util/annotate.c | 8 +- tools/testing/selftests/firmware/fw_filesystem.sh | 5 +- .../testing/selftests/rcutorture/bin/configinit.sh | 2 +- tools/usb/usbip/src/usbipd.c | 2 +- 124 files changed, 763 insertions(+), 345 deletions(-)

7 years, 1 month

8
122
0 0

[PATCH 05/15] mm/hmm: hmm_pfns_bad() was accessing wrong struct

by jglisse＠redhat.com

From: Jérôme Glisse <jglisse(a)redhat.com> The private field of mm_walk struct point to an hmm_vma_walk struct and not to the hmm_range struct desired. Fix to get proper struct pointer. Signed-off-by: Jérôme Glisse <jglisse(a)redhat.com> Cc: stable(a)vger.kernel.org Cc: Evgeny Baskakov <ebaskakov(a)nvidia.com> Cc: Ralph Campbell <rcampbell(a)nvidia.com> Cc: Mark Hairgrove <mhairgrove(a)nvidia.com> Cc: John Hubbard <jhubbard(a)nvidia.com> --- mm/hmm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/hmm.c b/mm/hmm.c index 667944630dc9..f5631e1a7319 100644 --- a/mm/hmm.c +++ b/mm/hmm.c @@ -312,7 +312,8 @@ static int hmm_pfns_bad(unsigned long addr, unsigned long end, struct mm_walk *walk) { - struct hmm_range *range = walk->private; + struct hmm_vma_walk *hmm_vma_walk = walk->private; + struct hmm_range *range = hmm_vma_walk->range; hmm_pfn_t *pfns = range->pfns; unsigned long i; -- 2.14.3

7 years, 1 month

1
0
0 0

[PATCH 02/15] mm/hmm: fix header file if/else/endif maze v2

by jglisse＠redhat.com

From: Jérôme Glisse <jglisse(a)redhat.com> The #if/#else/#endif for IS_ENABLED(CONFIG_HMM) were wrong. Because of this after multiple include there was multiple definition of both hmm_mm_init() and hmm_mm_destroy() leading to build failure if HMM was enabled (CONFIG_HMM set). Changed since v1: - Fix the maze when CONFIG_HMM is disabled not just when it is disabled. This fix bot build failure. - Improved commit message. Signed-off-by: Jérôme Glisse <jglisse(a)redhat.com> Acked-by: Balbir Singh <bsingharora(a)gmail.com> Cc: stable(a)vger.kernel.org Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Ralph Campbell <rcampbell(a)nvidia.com> Cc: John Hubbard <jhubbard(a)nvidia.com> Cc: Evgeny Baskakov <ebaskakov(a)nvidia.com> --- include/linux/hmm.h | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/include/linux/hmm.h b/include/linux/hmm.h index 325017ad9311..36dd21fe5caf 100644 --- a/include/linux/hmm.h +++ b/include/linux/hmm.h @@ -498,23 +498,16 @@ struct hmm_device { struct hmm_device *hmm_device_new(void *drvdata); void hmm_device_put(struct hmm_device *hmm_device); #endif /* CONFIG_DEVICE_PRIVATE || CONFIG_DEVICE_PUBLIC */ -#endif /* IS_ENABLED(CONFIG_HMM) */ /* Below are for HMM internal use only! Not to be used by device driver! */ -#if IS_ENABLED(CONFIG_HMM_MIRROR) void hmm_mm_destroy(struct mm_struct *mm); static inline void hmm_mm_init(struct mm_struct *mm) { mm->hmm = NULL; } -#else /* IS_ENABLED(CONFIG_HMM_MIRROR) */ -static inline void hmm_mm_destroy(struct mm_struct *mm) {} -static inline void hmm_mm_init(struct mm_struct *mm) {} -#endif /* IS_ENABLED(CONFIG_HMM_MIRROR) */ - - #else /* IS_ENABLED(CONFIG_HMM) */ static inline void hmm_mm_destroy(struct mm_struct *mm) {} static inline void hmm_mm_init(struct mm_struct *mm) {} +#endif /* IS_ENABLED(CONFIG_HMM) */ #endif /* LINUX_HMM_H */ -- 2.14.3

7 years, 1 month

1
0
0 0

Applied "ASoC: ssm2602: Replace reg_default_raw with reg_default" to the asoc tree

by Mark Brown

The patch ASoC: ssm2602: Replace reg_default_raw with reg_default has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From a01df75ce737951ad13a08d101306e88c3f57cb2 Mon Sep 17 00:00:00 2001 From: James Kelly <jamespeterkelly(a)gmail.com> Date: Mon, 19 Mar 2018 21:29:50 +1100 Subject: [PATCH] ASoC: ssm2602: Replace reg_default_raw with reg_default SSM2602 driver is broken on recent kernels (at least since 4.9). User space applications such as amixer or alsamixer get EIO when attempting to access codec controls via the relevant IOCTLs. Root cause of these failures is the regcache_hw_init function in drivers/base/regmap/regcache.c, which prevents regmap cache initalization from the reg_defaults_raw element of the regmap_config structure when registers are write only. It also disables the regmap cache entirely when all registers are write only or volatile as is the case for the SSM2602 driver. Using the reg_defaults element of the regmap_config structure rather than the reg_defaults_raw element to initalize the regmap cache avoids the logic in the regcache_hw_init function entirely. It also makes this driver consistent with other ASoC codec drivers, as this driver was the ONLY codec driver that used the reg_defaults_raw element to initalize the cache. Tested on Digilent Zybo Z7 development board which has a SSM2603 codec chip connected to a Xilinx Zynq SoC. Signed-off-by: James Kelly <jamespeterkelly(a)gmail.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> Cc: stable(a)vger.kernel.org --- sound/soc/codecs/ssm2602.c | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/sound/soc/codecs/ssm2602.c b/sound/soc/codecs/ssm2602.c index 9b341c23f62b..5e80867d09ef 100644 --- a/sound/soc/codecs/ssm2602.c +++ b/sound/soc/codecs/ssm2602.c @@ -54,10 +54,17 @@ struct ssm2602_priv { * using 2 wire for device control, so we cache them instead. * There is no point in caching the reset register */ -static const u16 ssm2602_reg[SSM2602_CACHEREGNUM] = { - 0x0097, 0x0097, 0x0079, 0x0079, - 0x000a, 0x0008, 0x009f, 0x000a, - 0x0000, 0x0000 +static const struct reg_default ssm2602_reg[SSM2602_CACHEREGNUM] = { + { .reg = 0x00, .def = 0x0097 }, + { .reg = 0x01, .def = 0x0097 }, + { .reg = 0x02, .def = 0x0079 }, + { .reg = 0x03, .def = 0x0079 }, + { .reg = 0x04, .def = 0x000a }, + { .reg = 0x05, .def = 0x0008 }, + { .reg = 0x06, .def = 0x009f }, + { .reg = 0x07, .def = 0x000a }, + { .reg = 0x08, .def = 0x0000 }, + { .reg = 0x09, .def = 0x0000 } }; @@ -620,8 +627,8 @@ const struct regmap_config ssm2602_regmap_config = { .volatile_reg = ssm2602_register_volatile, .cache_type = REGCACHE_RBTREE, - .reg_defaults_raw = ssm2602_reg, - .num_reg_defaults_raw = ARRAY_SIZE(ssm2602_reg), + .reg_defaults = ssm2602_reg, + .num_reg_defaults = ARRAY_SIZE(ssm2602_reg), }; EXPORT_SYMBOL_GPL(ssm2602_regmap_config); -- 2.16.2

7 years, 1 month

1
0
0 0

[PATCH v3 1/5] tpm: fix intermittent failure with self tests

by Jarkko Sakkinen

From: James Bottomley <James.Bottomley(a)HansenPartnership.com> My Nuvoton 6xx in a Dell XPS-13 has been intermittently failing to work (necessitating a reboot). The problem seems to be that the TPM gets into a state where the partial self-test doesn't return TPM_RC_SUCCESS (meaning all tests have run to completion), but instead returns TPM_RC_TESTING (meaning some tests are still running in the background). There are various theories that resending the self-test command actually causes the tests to restart and thus triggers more TPM_RC_TESTING returns until the timeout is exceeded. There are several issues here: firstly being we shouldn't slow down the boot sequence waiting for the self test to complete once the TPM backgrounds them. It will actually make available all functions that have passed and if it gets a failure return TPM_RC_FAILURE to every subsequent command. So the fix is to kick off self tests once and if they return TPM_RC_TESTING log that as a backgrounded self test and continue on. In order to prevent other tpm users from seeing any TPM_RC_TESTING returns (which it might if they send a command that needs a TPM subsystem which is still under test), we loop in tpm_transmit_cmd until either a timeout or we don't get a TPM_RC_TESTING return. Finally, there have been observations of strange returns from a partial test. One Nuvoton is occasionally returning TPM_RC_COMMAND_CODE, so treat any unexpected return from a partial self test as an indication we need to run a full self test. [jarkko.sakkinen(a)linux.intel.com: cleaned up James' original commit and added a proper Fixes line] Fixes: 2482b1bba5122 ("tpm: Trigger only missing TPM 2.0 self tests") Cc: stable(a)vger.kernel.org Signed-off-by: James Bottomley <James.Bottomley(a)HansenPartnership.com> Tested-by: Jarkko Sakkinen <jarkko.sakkine(a)linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkine(a)linux.intel.com> --- drivers/char/tpm/tpm-interface.c | 20 ++++++++++++--- drivers/char/tpm/tpm.h | 1 + drivers/char/tpm/tpm2-cmd.c | 54 ++++++++++++---------------------------- 3 files changed, 33 insertions(+), 42 deletions(-) diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c index 9e80a953d693..1adb976a2e37 100644 --- a/drivers/char/tpm/tpm-interface.c +++ b/drivers/char/tpm/tpm-interface.c @@ -537,14 +537,26 @@ ssize_t tpm_transmit_cmd(struct tpm_chip *chip, struct tpm_space *space, const char *desc) { const struct tpm_output_header *header = buf; + unsigned int delay_msec = TPM2_DURATION_SHORT; int err; ssize_t len; - len = tpm_transmit(chip, space, (u8 *)buf, bufsiz, flags); - if (len < 0) - return len; + for (;;) { + len = tpm_transmit(chip, space, (u8 *)buf, bufsiz, flags); + if (len < 0) + return len; + err = be32_to_cpu(header->return_code); + if (err != TPM2_RC_TESTING) + break; + + delay_msec *= 2; + if (delay_msec > TPM2_DURATION_LONG) { + dev_err(&chip->dev, "the self test is still running\n"); + break; + } + tpm_msleep(delay_msec); + } - err = be32_to_cpu(header->return_code); if (err != 0 && desc) dev_err(&chip->dev, "A TPM error (%d) occurred %s\n", err, desc); diff --git a/drivers/char/tpm/tpm.h b/drivers/char/tpm/tpm.h index f895fba4e20d..cccd5994a0e1 100644 --- a/drivers/char/tpm/tpm.h +++ b/drivers/char/tpm/tpm.h @@ -104,6 +104,7 @@ enum tpm2_return_codes { TPM2_RC_HASH = 0x0083, /* RC_FMT1 */ TPM2_RC_HANDLE = 0x008B, TPM2_RC_INITIALIZE = 0x0100, /* RC_VER1 */ + TPM2_RC_FAILURE = 0x0101, TPM2_RC_DISABLED = 0x0120, TPM2_RC_COMMAND_CODE = 0x0143, TPM2_RC_TESTING = 0x090A, /* RC_WARN */ diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c index a700f8f9ead7..89a5397b18d2 100644 --- a/drivers/char/tpm/tpm2-cmd.c +++ b/drivers/char/tpm/tpm2-cmd.c @@ -31,10 +31,6 @@ struct tpm2_startup_in { __be16 startup_type; } __packed; -struct tpm2_self_test_in { - u8 full_test; -} __packed; - struct tpm2_get_tpm_pt_in { __be32 cap_id; __be32 property_id; @@ -60,7 +56,6 @@ struct tpm2_get_random_out { union tpm2_cmd_params { struct tpm2_startup_in startup_in; - struct tpm2_self_test_in selftest_in; struct tpm2_get_tpm_pt_in get_tpm_pt_in; struct tpm2_get_tpm_pt_out get_tpm_pt_out; struct tpm2_get_random_in getrandom_in; @@ -827,16 +822,6 @@ unsigned long tpm2_calc_ordinal_duration(struct tpm_chip *chip, u32 ordinal) } EXPORT_SYMBOL_GPL(tpm2_calc_ordinal_duration); -#define TPM2_SELF_TEST_IN_SIZE \ - (sizeof(struct tpm_input_header) + \ - sizeof(struct tpm2_self_test_in)) - -static const struct tpm_input_header tpm2_selftest_header = { - .tag = cpu_to_be16(TPM2_ST_NO_SESSIONS), - .length = cpu_to_be32(TPM2_SELF_TEST_IN_SIZE), - .ordinal = cpu_to_be32(TPM2_CC_SELF_TEST) -}; - /** * tpm2_do_selftest() - ensure that all self tests have passed * @@ -852,27 +837,24 @@ static const struct tpm_input_header tpm2_selftest_header = { */ static int tpm2_do_selftest(struct tpm_chip *chip) { + struct tpm_buf buf; + int full; int rc; - unsigned int delay_msec = 10; - long duration; - struct tpm2_cmd cmd; - duration = jiffies_to_msecs( - tpm2_calc_ordinal_duration(chip, TPM2_CC_SELF_TEST)); - - while (1) { - cmd.header.in = tpm2_selftest_header; - cmd.params.selftest_in.full_test = 0; - - rc = tpm_transmit_cmd(chip, NULL, &cmd, TPM2_SELF_TEST_IN_SIZE, - 0, 0, "continue selftest"); + for (full = 0; full < 2; full++) { + rc = tpm_buf_init(&buf, TPM2_ST_NO_SESSIONS, TPM2_CC_SELF_TEST); + if (rc) + return rc; - if (rc != TPM2_RC_TESTING || delay_msec >= duration) - break; + tpm_buf_append_u8(&buf, full); + rc = tpm_transmit_cmd(chip, NULL, buf.data, PAGE_SIZE, 0, 0, + "attempting the self test"); + tpm_buf_destroy(&buf); - /* wait longer than before */ - delay_msec *= 2; - tpm_msleep(delay_msec); + if (rc == TPM2_RC_TESTING) + rc = TPM2_RC_SUCCESS; + if (rc == TPM2_RC_INITIALIZE || rc == TPM2_RC_SUCCESS) + return rc; } return rc; @@ -1058,10 +1040,8 @@ int tpm2_auto_startup(struct tpm_chip *chip) goto out; rc = tpm2_do_selftest(chip); - if (rc != 0 && rc != TPM2_RC_INITIALIZE) { - dev_err(&chip->dev, "TPM self test failed\n"); + if (rc && rc != TPM2_RC_INITIALIZE) goto out; - } if (rc == TPM2_RC_INITIALIZE) { rc = tpm_startup(chip); @@ -1069,10 +1049,8 @@ int tpm2_auto_startup(struct tpm_chip *chip) goto out; rc = tpm2_do_selftest(chip); - if (rc) { - dev_err(&chip->dev, "TPM self test failed\n"); + if (rc) goto out; - } } rc = tpm2_get_pcr_allocation(chip); -- 2.15.1

7 years, 1 month

2
3
0 0

[PATCH v2] clk: mvebu: armada-38x: add support for missing clocks

by Richard Genoud

Clearfog boards can come with a CPU clocked at 1600MHz (commercial) or 1333MHz (industrial). They have also some dip-switches to select a different clock (666, 800, 1066, 1200). The funny thing is that the recovery button is on the MPP34 fq selector. So, when booting an industrial board with this button down, the frequency 666MHz is selected (and the kernel didn't boot). This patch add all the missing clocks. The only mode I didn't test is 2GHz (uboot found 4294MHz instead :/ ). Fixes: 0e85aeced4d6 ("clk: mvebu: add clock support for Armada 380/385") Cc: <stable(a)vger.kernel.org> # 3.16.x: 9593f4f56cf5: clk: mvebu: armada-38x: add support for 1866MHz variants Cc: <stable(a)vger.kernel.org> # 3.16.x Signed-off-by: Richard Genoud <richard.genoud(a)gmail.com> Acked-by: Gregory CLEMENT <gregory.clement(a)bootlin.com> --- drivers/clk/mvebu/armada-38x.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/clk/mvebu/armada-38x.c b/drivers/clk/mvebu/armada-38x.c index 394aa6f03f01..9ff4ea63932d 100644 --- a/drivers/clk/mvebu/armada-38x.c +++ b/drivers/clk/mvebu/armada-38x.c @@ -46,11 +46,11 @@ static u32 __init armada_38x_get_tclk_freq(void __iomem *sar) } static const u32 armada_38x_cpu_frequencies[] __initconst = { - 0, 0, 0, 0, - 1066 * 1000 * 1000, 0, 0, 0, + 666 * 1000 * 1000, 0, 800 * 1000 * 1000, 0, + 1066 * 1000 * 1000, 0, 1200 * 1000 * 1000, 0, 1332 * 1000 * 1000, 0, 0, 0, 1600 * 1000 * 1000, 0, 0, 0, - 1866 * 1000 * 1000, + 1866 * 1000 * 1000, 0, 0, 2000 * 1000 * 1000, }; static u32 __init armada_38x_get_cpu_freq(void __iomem *sar) @@ -76,11 +76,11 @@ static const struct coreclk_ratio armada_38x_coreclk_ratios[] __initconst = { }; static const int armada_38x_cpu_l2_ratios[32][2] __initconst = { - {0, 1}, {0, 1}, {0, 1}, {0, 1}, - {1, 2}, {0, 1}, {0, 1}, {0, 1}, - {1, 2}, {0, 1}, {0, 1}, {0, 1}, + {1, 2}, {0, 1}, {1, 2}, {0, 1}, + {1, 2}, {0, 1}, {1, 2}, {0, 1}, {1, 2}, {0, 1}, {0, 1}, {0, 1}, {1, 2}, {0, 1}, {0, 1}, {0, 1}, + {1, 2}, {0, 1}, {0, 1}, {1, 2}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, @@ -91,7 +91,7 @@ static const int armada_38x_cpu_ddr_ratios[32][2] __initconst = { {1, 2}, {0, 1}, {0, 1}, {0, 1}, {1, 2}, {0, 1}, {0, 1}, {0, 1}, {1, 2}, {0, 1}, {0, 1}, {0, 1}, - {1, 2}, {0, 1}, {0, 1}, {0, 1}, + {1, 2}, {0, 1}, {0, 1}, {7, 15}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 1}, {0, 1},

7 years, 1 month

2
1
0 0

[PATCH 1/2] dt-bindings: clock: mediatek: add binding for fixed-factor clock axisel_d4

by sean.wang＠mediatek.com

From: Sean Wang <sean.wang(a)mediatek.com> Just add binding for a fixed-factor clock axisel_d4, which would be referenced by PWM devices on MT7623 or MT2701 SoC. Cc: stable(a)vger.kernel.org Fixes: 1de9b21633d6 ("clk: mediatek: Add dt-bindings for MT2701 clocks") Signed-off-by: Sean Wang <sean.wang(a)mediatek.com> Cc: Rob Herring <robh+dt(a)kernel.org> Cc: Mark Rutland <mark.rutland(a)arm.com> Cc: devicetree(a)vger.kernel.org --- include/dt-bindings/clock/mt2701-clk.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/include/dt-bindings/clock/mt2701-clk.h b/include/dt-bindings/clock/mt2701-clk.h index 551f760..24e93df 100644 --- a/include/dt-bindings/clock/mt2701-clk.h +++ b/include/dt-bindings/clock/mt2701-clk.h @@ -176,7 +176,8 @@ #define CLK_TOP_AUD_EXT1 156 #define CLK_TOP_AUD_EXT2 157 #define CLK_TOP_NFI1X_PAD 158 -#define CLK_TOP_NR 159 +#define CLK_TOP_AXISEL_D4 159 +#define CLK_TOP_NR 160 /* APMIXEDSYS */ -- 2.7.4

7 years, 1 month

3
4
0 0

[PATCH] tpm_tis: fix potential buffer overruns caused by bit glitches on the bus

by Jarkko Sakkinen

From: Jeremy Boone <jeremy.boone(a)nccgroup.trust> commit 2c0a646268f2a3536866bf237733a52aec260594 upstream Discrete TPMs are often connected over slow serial buses which, on some platforms, can have glitches causing bit flips. In all the driver _recv() functions, we need to use a u32 to unmarshal the response size, otherwise a bit flip of the 31st bit would cause the expected variable to go negative, which would then try to read a huge amount of data. Also sanity check that the expected amount of data is large enough for the TPM header. Signed-off-by: Jeremy Boone <jeremy.boone(a)nccgroup.trust> Cc: stable(a)vger.kernel.org Signed-off-by: James Bottomley <James.Bottomley(a)HansenPartnership.com> Tested-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> --- Backported to v4.4 because of merge conflict. drivers/char/tpm/tpm_tis.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c index 7f13221aeb30..9dd93a209ef2 100644 --- a/drivers/char/tpm/tpm_tis.c +++ b/drivers/char/tpm/tpm_tis.c @@ -283,7 +283,8 @@ static int recv_data(struct tpm_chip *chip, u8 *buf, size_t count) static int tpm_tis_recv(struct tpm_chip *chip, u8 *buf, size_t count) { int size = 0; - int expected, status; + int status; + u32 expected; if (count < TPM_HEADER_SIZE) { size = -EIO; @@ -298,7 +299,7 @@ static int tpm_tis_recv(struct tpm_chip *chip, u8 *buf, size_t count) } expected = be32_to_cpu(*(__be32 *) (buf + 2)); - if (expected > count) { + if (expected > count || expected < TPM_HEADER_SIZE) { size = -EIO; goto out; } -- 2.15.1

7 years, 1 month

2
4
0 0

[PATCH] tpm: fix potential buffer overruns caused by bit glitches on the bus

by Jarkko Sakkinen

From: Jeremy Boone <jeremy.boone(a)nccgroup.trust> commit c8e3e06d252155ad0e38a64a65ebb85638893025 upstream Discrete TPMs are often connected over slow serial buses which, on some platforms, can have glitches causing bit flips. If a bit does flip it could cause an overrun if it's in one of the size parameters, so sanity check that we're not overrunning the provided buffer when doing a memcpy(). Signed-off-by: Jeremy Boone <jeremy.boone(a)nccgroup.trust> Cc: stable(a)vger.kernel.org Signed-off-by: James Bottomley <James.Bottomley(a)HansenPartnership.com> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> Tested-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com> --- Backport for v4.9 because of the merge conflict. drivers/char/tpm/tpm-interface.c | 5 +++++ drivers/char/tpm/tpm2-cmd.c | 6 ++++++ 2 files changed, 11 insertions(+) diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c index d0ac2d56520f..830d7e30e508 100644 --- a/drivers/char/tpm/tpm-interface.c +++ b/drivers/char/tpm/tpm-interface.c @@ -1078,6 +1078,11 @@ int tpm_get_random(u32 chip_num, u8 *out, size_t max) break; recd = be32_to_cpu(tpm_cmd.params.getrandom_out.rng_data_len); + if (recd > num_bytes) { + total = -EFAULT; + break; + } + memcpy(dest, tpm_cmd.params.getrandom_out.rng_data, recd); dest += recd; diff --git a/drivers/char/tpm/tpm2-cmd.c b/drivers/char/tpm/tpm2-cmd.c index 17896d654033..a5780ebe15ef 100644 --- a/drivers/char/tpm/tpm2-cmd.c +++ b/drivers/char/tpm/tpm2-cmd.c @@ -668,6 +668,11 @@ static int tpm2_unseal_cmd(struct tpm_chip *chip, if (!rc) { data_len = be16_to_cpup( (__be16 *) &buf.data[TPM_HEADER_SIZE + 4]); + if (data_len < MIN_KEY_SIZE || data_len > MAX_KEY_SIZE + 1) { + rc = -EFAULT; + goto out; + } + data = &buf.data[TPM_HEADER_SIZE + 6]; memcpy(payload->key, data, data_len - 1); @@ -675,6 +680,7 @@ static int tpm2_unseal_cmd(struct tpm_chip *chip, payload->migratable = data[data_len - 1]; } +out: tpm_buf_destroy(&buf); return rc; } -- 2.15.1

7 years, 1 month

2
4
0 0

[PATCH] Change synchronize_rcu() in scsi_device_quiesce() into synchronize_sched()

by Bart Van Assche

Since blk_queue_enter() uses rcu_read_lock_sched() scsi_device_quiesce() must use synchronize_sched(). Reported-by: Tejun Heo <tj(a)kernel.org> Fixes: 3a0a529971ec ("block, scsi: Make SCSI quiesce and resume work reliably") Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: Hannes Reinecke <hare(a)suse.com> Cc: Ming Lei <ming.lei(a)redhat.com> Cc: Christoph Hellwig <hch(a)lst.de> Cc: Johannes Thumshirn <jthumshirn(a)suse.de> Cc: Tejun Heo <tj(a)kernel.org> Cc: Oleksandr Natalenko <oleksandr(a)natalenko.name> Cc: Martin Steigerwald <martin(a)lichtvoll.de> Cc: stable(a)vger.kernel.org # v4.15 --- drivers/scsi/scsi_lib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index 1d83f29aee74..0b99ee2fbbb5 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -3014,7 +3014,7 @@ scsi_device_quiesce(struct scsi_device *sdev) * unfreeze even if the queue was already frozen before this function * was called. See also https://lwn.net/Articles/573497/. */ - synchronize_rcu(); + synchronize_sched(); blk_mq_unfreeze_queue(q); mutex_lock(&sdev->state_mutex); -- 2.16.2

7 years, 1 month

5
11
0 0

[PATCH v3] usb: dwc3: pci: Properly cleanup resource

by Thinh Nguyen

Platform device is allocated before adding resources. Make sure to properly cleanup on error case. Cc: <stable(a)vger.kernel.org> Fixes: f1c7e7108109 ("usb: dwc3: convert to pcim_enable_device()") Signed-off-by: Thinh Nguyen <thinhn(a)synopsys.com> --- Changes in v3: - Include Cc: <stable(a)vger.kernel.org> Changes in v2: - Separate from patch series "usb: dwc3: pci: Make device properties customizable" drivers/usb/dwc3/dwc3-pci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c index 3ba11136ebf0..c961a94d136b 100644 --- a/drivers/usb/dwc3/dwc3-pci.c +++ b/drivers/usb/dwc3/dwc3-pci.c @@ -222,7 +222,7 @@ static int dwc3_pci_probe(struct pci_dev *pci, ret = platform_device_add_resources(dwc->dwc3, res, ARRAY_SIZE(res)); if (ret) { dev_err(dev, "couldn't add resources to dwc3 device\n"); - return ret; + goto err; } dwc->pci = pci; -- 2.11.0

7 years, 1 month

1
0
0 0

[merged] drivers-infiniband-ulp-srpt-ib_srptc-fix-build-with-gcc-444.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: drivers/infiniband/ulp/srpt/ib_srpt.c: fix build with gcc-4.4.4 has been removed from the -mm tree. Its filename was drivers-infiniband-ulp-srpt-ib_srptc-fix-build-with-gcc-444.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Andrew Morton <akpm(a)linux-foundation.org> Subject: drivers/infiniband/ulp/srpt/ib_srpt.c: fix build with gcc-4.4.4 gcc-4.4.4 has issues with initialization of anonymous unions: drivers/infiniband/ulp/srpt/ib_srpt.c: In function 'srpt_zerolength_write': drivers/infiniband/ulp/srpt/ib_srpt.c:854: error: unknown field 'wr_cqe' specified in initializer drivers/infiniband/ulp/srpt/ib_srpt.c:854: warning: initialization makes integer from pointer without a cast Work aound this. Fixes: 2a78cb4db487 ("IB/srpt: Fix an out-of-bounds stack access in srpt_zerolength_write()") Cc: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: Christoph Hellwig <hch(a)lst.de> Cc: Jason Gunthorpe <jgg(a)mellanox.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- drivers/infiniband/ulp/srpt/ib_srpt.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff -puN drivers/infiniband/ulp/srpt/ib_srpt.c~drivers-infiniband-ulp-srpt-ib_srptc-fix-build-with-gcc-444 drivers/infiniband/ulp/srpt/ib_srpt.c --- a/drivers/infiniband/ulp/srpt/ib_srpt.c~drivers-infiniband-ulp-srpt-ib_srptc-fix-build-with-gcc-444 +++ a/drivers/infiniband/ulp/srpt/ib_srpt.c @@ -850,8 +850,9 @@ static int srpt_zerolength_write(struct struct ib_send_wr *bad_wr; struct ib_rdma_wr wr = { .wr = { + .next = NULL, + { .wr_cqe = &ch->zw_cqe, }, .opcode = IB_WR_RDMA_WRITE, - .wr_cqe = &ch->zw_cqe, .send_flags = IB_SEND_SIGNALED, } }; _ Patches currently in -mm which might be from akpm(a)linux-foundation.org are i-need-old-gcc.patch mm-mempolicy-avoid-use-uninitialized-preferred_node-fix.patch hugetlbfs-check-for-pgoff-value-overflow-v3-fix.patch hugetlbfs-check-for-pgoff-value-overflow-v3-fix-fix.patch mm-vmalloc-add-interfaces-to-free-unmapped-page-table-fix.patch arm-arch-arm-include-asm-pageh-needs-personalityh.patch ocfs2-without-quota-support-try-to-avoid-calling-quota-recovery-checkpatch-fixes.patch mm.patch mm-initialize-pages-on-demand-during-boot-fix-4-fix.patch mm-initialize-pages-on-demand-during-boot-v5-fix.patch mm-initialize-pages-on-demand-during-boot-v6-checkpatch-fixes.patch direct-io-minor-cleanups-in-do_blockdev_direct_io-fix.patch mm-fix-races-between-swapoff-and-flush-dcache-fix.patch headers-untangle-kmemleakh-from-mmh-fix.patch mm-vmscan-dont-mess-with-pgdat-flags-in-memcg-reclaim-checkpatch-fixes.patch list_lru-prefetch-neighboring-list-entries-before-acquiring-lock-fix.patch mm-oom-cgroup-aware-oom-killer-fix.patch mm-oom-docs-describe-the-cgroup-aware-oom-killer-fix-2-fix.patch proc-add-seq_put_decimal_ull_width-to-speed-up-proc-pid-smaps-fix.patch linux-next-rejects.patch linux-next-fixup.patch fs-fsnotify-account-fsnotify-metadata-to-kmemcg-fix.patch kernel-forkc-export-kernel_thread-to-modules.patch slab-leaks3-default-y.patch

7 years, 1 month

1
0
0 0

[merged] drivers-infiniband-core-verbsc-fix-build-with-gcc-444.patch removed from -mm tree

by akpm＠linux-foundation.org

The patch titled Subject: drivers/infiniband/core/verbs.c: fix build with gcc-4.4.4 has been removed from the -mm tree. Its filename was drivers-infiniband-core-verbsc-fix-build-with-gcc-444.patch This patch was dropped because it was merged into mainline or a subsystem tree ------------------------------------------------------ From: Andrew Morton <akpm(a)linux-foundation.org> Subject: drivers/infiniband/core/verbs.c: fix build with gcc-4.4.4 gcc-4.4.4 has issues with initialization of anonymous unions. drivers/infiniband/core/verbs.c: In function '__ib_drain_sq': drivers/infiniband/core/verbs.c:2204: error: unknown field 'wr_cqe' specified in initializer drivers/infiniband/core/verbs.c:2204: warning: initialization makes integer from pointer without a cast Work around this. Fixes: a1ae7d0345edd5 ("RDMA/core: Avoid that ib_drain_qp() triggers an out-of-bounds stack access") Cc: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: Steve Wise <swise(a)opengridcomputing.com> Cc: Sagi Grimberg <sagi(a)grimberg.me> Cc: Jason Gunthorpe <jgg(a)mellanox.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- drivers/infiniband/core/verbs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff -puN drivers/infiniband/core/verbs.c~drivers-infiniband-core-verbsc-fix-build-with-gcc-444 drivers/infiniband/core/verbs.c --- a/drivers/infiniband/core/verbs.c~drivers-infiniband-core-verbsc-fix-build-with-gcc-444 +++ a/drivers/infiniband/core/verbs.c @@ -2200,8 +2200,9 @@ static void __ib_drain_sq(struct ib_qp * struct ib_send_wr *bad_swr; struct ib_rdma_wr swr = { .wr = { + .next = NULL, + { .wr_cqe = &sdrain.cqe, }, .opcode = IB_WR_RDMA_WRITE, - .wr_cqe = &sdrain.cqe, }, }; int ret; _ Patches currently in -mm which might be from akpm(a)linux-foundation.org are i-need-old-gcc.patch mm-mempolicy-avoid-use-uninitialized-preferred_node-fix.patch hugetlbfs-check-for-pgoff-value-overflow-v3-fix.patch hugetlbfs-check-for-pgoff-value-overflow-v3-fix-fix.patch mm-vmalloc-add-interfaces-to-free-unmapped-page-table-fix.patch arm-arch-arm-include-asm-pageh-needs-personalityh.patch ocfs2-without-quota-support-try-to-avoid-calling-quota-recovery-checkpatch-fixes.patch mm.patch mm-initialize-pages-on-demand-during-boot-fix-4-fix.patch mm-initialize-pages-on-demand-during-boot-v5-fix.patch mm-initialize-pages-on-demand-during-boot-v6-checkpatch-fixes.patch direct-io-minor-cleanups-in-do_blockdev_direct_io-fix.patch mm-fix-races-between-swapoff-and-flush-dcache-fix.patch headers-untangle-kmemleakh-from-mmh-fix.patch mm-vmscan-dont-mess-with-pgdat-flags-in-memcg-reclaim-checkpatch-fixes.patch list_lru-prefetch-neighboring-list-entries-before-acquiring-lock-fix.patch mm-oom-cgroup-aware-oom-killer-fix.patch mm-oom-docs-describe-the-cgroup-aware-oom-killer-fix-2-fix.patch proc-add-seq_put_decimal_ull_width-to-speed-up-proc-pid-smaps-fix.patch linux-next-rejects.patch linux-next-fixup.patch fs-fsnotify-account-fsnotify-metadata-to-kmemcg-fix.patch kernel-forkc-export-kernel_thread-to-modules.patch slab-leaks3-default-y.patch

7 years, 1 month

1
0
0 0

[PATCH 4.9 0/2] Clear LED_BLINK_SW flag in led_blink_set()

by Jacek Anaszewski

The fix for brightness setting when setting delay_off=0 introduces a regression and has truncated commit message. Revert that patch and apply the one-line change required to fix the original issue in the way appropriate for the 4.9 code base. Thanks, Jacek Anaszewski Jacek Anaszewski (2): Revert "led: core: Fix brightness setting when setting delay_off=0" led: core: Clear LED_BLINK_SW flag in led_blink_set() drivers/leds/led-core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) -- 2.1.4

7 years, 1 month

2
4
0 0

[PATCH v2] block: Change a rcu_read_{lock, unlock}_sched() pair into rcu_read_{lock, unlock}()

by Bart Van Assche

scsi_device_quiesce() uses synchronize_rcu() to guarantee that the effect of blk_set_preempt_only() will be visible for percpu_ref_tryget() calls that occur after the queue unfreeze by using the approach explained in https://lwn.net/Articles/573497/. The rcu read lock and unlock calls in blk_queue_enter() form a pair with the synchronize_rcu() call in scsi_device_quiesce(). Both scsi_device_quiesce() and blk_queue_enter() must either use regular RCU or RCU-sched. Since neither the RCU-protected code in blk_queue_enter() nor blk_queue_usage_counter_release() sleeps, regular RCU protection is sufficient. Note: scsi_device_quiesce() does not have to be modified since it already uses synchronize_rcu(). Reported-by: Tejun Heo <tj(a)kernel.org> Fixes: 3a0a529971ec ("block, scsi: Make SCSI quiesce and resume work reliably") Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Acked-by: Tejun Heo <tj(a)kernel.org> Cc: Tejun Heo <tj(a)kernel.org> Cc: Hannes Reinecke <hare(a)suse.com> Cc: Ming Lei <ming.lei(a)redhat.com> Cc: Christoph Hellwig <hch(a)lst.de> Cc: Johannes Thumshirn <jthumshirn(a)suse.de> Cc: Oleksandr Natalenko <oleksandr(a)natalenko.name> Cc: Martin Steigerwald <martin(a)lichtvoll.de> Cc: stable(a)vger.kernel.org # v4.15 --- Changes between v1 and v2: - Explained in the interaction between scsi_device_quiesce() and blk_queue_enter() in the patch description. block/blk-core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/block/blk-core.c b/block/blk-core.c index 5e88c579e896..a0f675f84f86 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -917,7 +917,7 @@ int blk_queue_enter(struct request_queue *q, blk_mq_req_flags_t flags) bool success = false; int ret; - rcu_read_lock_sched(); + rcu_read_lock(); if (percpu_ref_tryget_live(&q->q_usage_counter)) { /* * The code that sets the PREEMPT_ONLY flag is @@ -930,7 +930,7 @@ int blk_queue_enter(struct request_queue *q, blk_mq_req_flags_t flags) percpu_ref_put(&q->q_usage_counter); } } - rcu_read_unlock_sched(); + rcu_read_unlock(); if (success) return 0; -- 2.16.2

7 years, 1 month

2
1
0 0

patch "staging: comedi: ni_mio_common: ack ai fifo error interrupts." added to staging-testing

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: comedi: ni_mio_common: ack ai fifo error interrupts. to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-testing branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will be merged to the staging-next branch sometime soon, after it passes testing, and the merge window is open. If you have any questions about this process, please let me know. >From e1d9fc04c41840a4688ef6ce90b6dcca157ea4d7 Mon Sep 17 00:00:00 2001 From: Frank Mori Hess <fmh6jj(a)gmail.com> Date: Thu, 15 Mar 2018 10:25:44 +0000 Subject: staging: comedi: ni_mio_common: ack ai fifo error interrupts. Ack ai fifo error interrupts in interrupt handler to clear interrupt after fifo overflow. It should prevent lock-ups after the ai fifo overflows. Cc: <stable(a)vger.kernel.org> # v4.2+ Signed-off-by: Frank Mori Hess <fmh6jj(a)gmail.com> Signed-off-by: Ian Abbott <abbotti(a)mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/comedi/drivers/ni_mio_common.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/staging/comedi/drivers/ni_mio_common.c b/drivers/staging/comedi/drivers/ni_mio_common.c index d6eb55b41814..e40a2c0a9543 100644 --- a/drivers/staging/comedi/drivers/ni_mio_common.c +++ b/drivers/staging/comedi/drivers/ni_mio_common.c @@ -1275,6 +1275,8 @@ static void ack_a_interrupt(struct comedi_device *dev, unsigned short a_status) ack |= NISTC_INTA_ACK_AI_START; if (a_status & NISTC_AI_STATUS1_STOP) ack |= NISTC_INTA_ACK_AI_STOP; + if (a_status & NISTC_AI_STATUS1_OVER) + ack |= NISTC_INTA_ACK_AI_ERR; if (ack) ni_stc_writew(dev, ack, NISTC_INTA_ACK_REG); } -- 2.16.2

7 years, 1 month

1
0
0 0

[PATCH] xprtrdma: Fix corner cases when handling device removal

by Chuck Lever

Michal Kalderon has found some corner cases around device unload with active NFS mounts that I didn't have the imagination to test when xprtrdma device removal was added last year. - The ULP device removal handler is responsible for deallocating the PD. That wasn't clear to me initially, and my own testing suggested it was not necessary, but that is incorrect. - The transport destruction path can no longer assume that there is a valid ID. - When destroying a transport, ensure that ib_free_cq() is not invoked on a CQ that was already released. Reported-by: Michal Kalderon <Michal.Kalderon(a)cavium.com> Fixes: bebd031866ca ("xprtrdma: Support unplugging an HCA from ...") Signed-off-by: Chuck Lever <chuck.lever(a)oracle.com> Cc: stable(a)vger.kernel.org --- net/sunrpc/xprtrdma/verbs.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/net/sunrpc/xprtrdma/verbs.c b/net/sunrpc/xprtrdma/verbs.c index fe518b3..5e3afed 100644 --- a/net/sunrpc/xprtrdma/verbs.c +++ b/net/sunrpc/xprtrdma/verbs.c @@ -250,7 +250,6 @@ wait_for_completion(&ia->ri_remove_done); ia->ri_id = NULL; - ia->ri_pd = NULL; ia->ri_device = NULL; /* Return 1 to ensure the core destroys the id. */ return 1; @@ -448,7 +447,9 @@ ia->ri_id->qp = NULL; } ib_free_cq(ep->rep_attr.recv_cq); + ep->rep_attr.recv_cq = NULL; ib_free_cq(ep->rep_attr.send_cq); + ep->rep_attr.send_cq = NULL; /* The ULP is responsible for ensuring all DMA * mappings and MRs are gone. @@ -461,6 +462,8 @@ rpcrdma_dma_unmap_regbuf(req->rl_recvbuf); } rpcrdma_mrs_destroy(buf); + ib_dealloc_pd(ia->ri_pd); + ia->ri_pd = NULL; /* Allow waiters to continue */ complete(&ia->ri_remove_done); @@ -628,14 +631,16 @@ { cancel_delayed_work_sync(&ep->rep_connect_worker); - if (ia->ri_id->qp) { + if (ia->ri_id && ia->ri_id->qp) { rpcrdma_ep_disconnect(ep, ia); rdma_destroy_qp(ia->ri_id); ia->ri_id->qp = NULL; } - ib_free_cq(ep->rep_attr.recv_cq); - ib_free_cq(ep->rep_attr.send_cq); + if (ep->rep_attr.recv_cq) + ib_free_cq(ep->rep_attr.recv_cq); + if (ep->rep_attr.send_cq) + ib_free_cq(ep->rep_attr.send_cq); } /* Re-establish a connection after a device removal event.

7 years, 1 month

1
0
0 0

[PATCH] block: Change a rcu_read_{lock, unlock}_sched() pair into rcu_read_{lock, unlock}()

by Bart Van Assche

Since neither the RCU-protected code in blk_queue_enter() nor blk_queue_usage_counter_release() sleeps, regular RCU protection is sufficient. Note: scsi_device_quiesce() does not have to be modified since it already uses synchronize_rcu(). Reported-by: Tejun Heo <tj(a)kernel.org> Fixes: 3a0a529971ec ("block, scsi: Make SCSI quiesce and resume work reliably") Signed-off-by: Bart Van Assche <bart.vanassche(a)wdc.com> Cc: Hannes Reinecke <hare(a)suse.com> Cc: Ming Lei <ming.lei(a)redhat.com> Cc: Christoph Hellwig <hch(a)lst.de> Cc: Johannes Thumshirn <jthumshirn(a)suse.de> Cc: Tejun Heo <tj(a)kernel.org> Cc: Oleksandr Natalenko <oleksandr(a)natalenko.name> Cc: Martin Steigerwald <martin(a)lichtvoll.de> Cc: stable(a)vger.kernel.org # v4.15 --- block/blk-core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/block/blk-core.c b/block/blk-core.c index 5e88c579e896..a0f675f84f86 100644 --- a/block/blk-core.c +++ b/block/blk-core.c @@ -917,7 +917,7 @@ int blk_queue_enter(struct request_queue *q, blk_mq_req_flags_t flags) bool success = false; int ret; - rcu_read_lock_sched(); + rcu_read_lock(); if (percpu_ref_tryget_live(&q->q_usage_counter)) { /* * The code that sets the PREEMPT_ONLY flag is @@ -930,7 +930,7 @@ int blk_queue_enter(struct request_queue *q, blk_mq_req_flags_t flags) percpu_ref_put(&q->q_usage_counter); } } - rcu_read_unlock_sched(); + rcu_read_unlock(); if (success) return 0; -- 2.16.2

7 years, 1 month

2
1
0 0

v4.1.50 build: 2 failures 31 warnings (v4.1.50)

by Build bot for Mark Brown

Tree/Branch: v4.1.50 Git describe: v4.1.50 Commit: 6f20f6d4c0 Linux 4.1.50 Build Time: 42 min 12 sec Passed: 6 / 9 ( 66.67 %) Failed: 2 / 9 ( 22.22 %) Unknown: 1 / 9 ( 11.11 %) Errors: 1 Warnings: 31 Section Mismatches: 1 Failed defconfigs: arm64-allmodconfig arm64-defconfig Errors: arm64-allmodconfig ../arch/arm64/kvm/handle_exit.c:45:3: error: implicit declaration of function 'vcpu_set_reg' [-Werror=implicit-function-declaration] arm64-defconfig ../arch/arm64/kvm/handle_exit.c:45:3: error: implicit declaration of function 'vcpu_set_reg' [-Werror=implicit-function-declaration] ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 21 warnings 1 mismatches : arm64-allmodconfig 2 warnings 0 mismatches : arm-multi_v5_defconfig 2 warnings 0 mismatches : arm-multi_v7_defconfig 4 warnings 0 mismatches : x86_64-defconfig 23 warnings 0 mismatches : arm-allmodconfig ------------------------------------------------------------------------------- Errors summary: 1 2 ../arch/arm64/kvm/handle_exit.c:45:3: error: implicit declaration of function 'vcpu_set_reg' [-Werror=implicit-function-declaration] Warnings Summary: 31 8 ../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast 5 ../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool] 2 ../sound/pci/oxygen/oxygen_mixer.c:91:43: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses] 2 ../drivers/scsi/qla2xxx/qla_target.c:3086:6: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 8 has type 'uint32_t {aka unsigned int}' [-Wformat=] 2 ../drivers/scsi/qla2xxx/qla_target.c:3083:17: warning: unused variable 'se_cmd' [-Wunused-variable] 2 ../drivers/scsi/ips.c:210:2: warning: #warning "This driver has only been tested on the x86/ia64/x86_64 platforms" [-Wcpp] 2 ../drivers/scsi/be2iscsi/be_main.c:3168:18: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses] 2 ../drivers/media/platform/s3c-camif/camif-capture.c:134:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses] 2 ../drivers/media/platform/s3c-camif/camif-capture.c:118:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses] 2 ../drivers/ata/pata_hpt366.c:382:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers] 2 ../drivers/ata/pata_hpt366.c:379:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers] 2 ../drivers/ata/pata_hpt366.c:376:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers] 1 ../include/trace/ftrace.h:28:0: warning: "TRACE_SYSTEM_STRING" redefined 1 ../drivers/xen/swiotlb-xen.c:704:27: warning: passing argument 6 of '__generic_dma_ops(dev)->mmap' makes pointer from integer without a cast [-Wint-conversion] 1 ../drivers/usb/renesas_usbhs/common.c:492:25: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 1 ../drivers/rtc/rtc-pcf8563.c:444:5: warning: 'alm_pending' may be used uninitialized in this function [-Wmaybe-uninitialized] 1 ../drivers/rtc/rtc-armada38x.c:91:22: warning: unused variable 'flags' [-Wunused-variable] 1 ../drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c:1478:8: warning: 'skb' may be used uninitialized in this function [-Wmaybe-uninitialized] 1 ../drivers/mmc/host/sh_mmcif.c:402:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] 1 ../drivers/mmc/host/sh_mmcif.c:401:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] 1 ../drivers/media/platform/coda/./trace.h:12:0: warning: "TRACE_SYSTEM_STRING" redefined 1 ../drivers/iommu/intel-iommu.c:3800:5: warning: suggest explicit braces to avoid ambiguous 'else' [-Wparentheses] 1 ../drivers/iommu/dmar.c:1849:5: warning: suggest explicit braces to avoid ambiguous 'else' [-Wparentheses] 1 ../drivers/infiniband/hw/qib/qib_qp.c:44:0: warning: "BITS_PER_PAGE" redefined 1 ../drivers/infiniband/hw/cxgb4/mem.c:147:20: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] 1 ../drivers/hid/hid-input.c:1163:67: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses] 1 ../drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm204.c:975:1: warning: the frame size of 1192 bytes is larger than 1024 bytes [-Wframe-larger-than=] 1 ../arch/x86/include/asm/msr.h:209:23: warning: right shift count >= width of type [-Wshift-count-overflow] 1 ../arch/arm64/xen/../../arm/xen/mm.c:183:10: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types] 1 ../arch/arm/mach-cns3xxx/pcie.c:266:1: warning: the frame size of 1080 bytes is larger than 1024 bytes [-Wframe-larger-than=] 1 ../arch/arm/include/asm/cmpxchg.h:205:3: warning: value computed is not used [-Wunused-value] Section Mismatch Summary: 1 1 WARNING: drivers/staging/fsl-mc/bus/mc-bus-driver.o(.init.text+0xb0): Section mismatch in reference from the function init_module() to the function .exit.text:dprc_driver_exit() =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- arm64-allmodconfig : FAIL, 1 errors, 21 warnings, 1 section mismatches Errors: ../arch/arm64/kvm/handle_exit.c:45:3: error: implicit declaration of function 'vcpu_set_reg' [-Werror=implicit-function-declaration] Warnings: ../arch/arm64/xen/../../arm/xen/mm.c:183:10: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types] ../drivers/ata/pata_hpt366.c:376:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers] ../drivers/ata/pata_hpt366.c:379:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers] ../drivers/ata/pata_hpt366.c:382:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers] ../sound/pci/oxygen/oxygen_mixer.c:91:43: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses] ../drivers/infiniband/hw/qib/qib_qp.c:44:0: warning: "BITS_PER_PAGE" redefined ../drivers/mmc/host/sh_mmcif.c:401:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ../drivers/mmc/host/sh_mmcif.c:402:4: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] ../drivers/media/platform/s3c-camif/camif-capture.c:118:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses] ../drivers/media/platform/s3c-camif/camif-capture.c:134:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses] ../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool] ../drivers/scsi/be2iscsi/be_main.c:3168:18: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses] ../drivers/scsi/qla2xxx/qla_target.c:3086:6: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 8 has type 'uint32_t {aka unsigned int}' [-Wformat=] ../drivers/scsi/qla2xxx/qla_target.c:3083:17: warning: unused variable 'se_cmd' [-Wunused-variable] ../drivers/scsi/ips.c:210:2: warning: #warning "This driver has only been tested on the x86/ia64/x86_64 platforms" [-Wcpp] ../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast ../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast ../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast ../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast ../drivers/usb/renesas_usbhs/common.c:492:25: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] ../drivers/xen/swiotlb-xen.c:704:27: warning: passing argument 6 of '__generic_dma_ops(dev)->mmap' makes pointer from integer without a cast [-Wint-conversion] Section Mismatches: WARNING: drivers/staging/fsl-mc/bus/mc-bus-driver.o(.init.text+0xb0): Section mismatch in reference from the function init_module() to the function .exit.text:dprc_driver_exit() ------------------------------------------------------------------------------- arm-multi_v5_defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches Warnings: ../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool] ../drivers/rtc/rtc-pcf8563.c:444:5: warning: 'alm_pending' may be used uninitialized in this function [-Wmaybe-uninitialized] ------------------------------------------------------------------------------- arm-multi_v7_defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches Warnings: ../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool] ../drivers/net/wireless/brcm80211/brcmfmac/fwsignal.c:1478:8: warning: 'skb' may be used uninitialized in this function [-Wmaybe-uninitialized] ------------------------------------------------------------------------------- x86_64-defconfig : PASS, 0 errors, 4 warnings, 0 section mismatches Warnings: ../arch/x86/include/asm/msr.h:209:23: warning: right shift count >= width of type [-Wshift-count-overflow] ../drivers/hid/hid-input.c:1163:67: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses] ../drivers/iommu/dmar.c:1849:5: warning: suggest explicit braces to avoid ambiguous 'else' [-Wparentheses] ../drivers/iommu/intel-iommu.c:3800:5: warning: suggest explicit braces to avoid ambiguous 'else' [-Wparentheses] ------------------------------------------------------------------------------- arm-allmodconfig : UNKNOWN, 0 errors, 23 warnings, 0 section mismatches Warnings: ../arch/arm/mach-cns3xxx/pcie.c:266:1: warning: the frame size of 1080 bytes is larger than 1024 bytes [-Wframe-larger-than=] ../arch/arm/include/asm/cmpxchg.h:205:3: warning: value computed is not used [-Wunused-value] ../drivers/ata/pata_hpt366.c:376:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers] ../drivers/ata/pata_hpt366.c:379:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers] ../drivers/ata/pata_hpt366.c:382:9: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers] ../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool] ../sound/pci/oxygen/oxygen_mixer.c:91:43: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses] ../drivers/infiniband/hw/cxgb4/mem.c:147:20: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] ../drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgm204.c:975:1: warning: the frame size of 1192 bytes is larger than 1024 bytes [-Wframe-larger-than=] ../include/trace/ftrace.h:28:0: warning: "TRACE_SYSTEM_STRING" redefined ../drivers/media/platform/coda/./trace.h:12:0: warning: "TRACE_SYSTEM_STRING" redefined ../drivers/media/platform/s3c-camif/camif-capture.c:118:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses] ../drivers/media/platform/s3c-camif/camif-capture.c:134:10: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses] ../include/linux/blkdev.h:624:26: warning: switch condition has boolean value [-Wswitch-bool] ../drivers/rtc/rtc-armada38x.c:91:22: warning: unused variable 'flags' [-Wunused-variable] ../drivers/scsi/be2iscsi/be_main.c:3168:18: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses] ../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast ../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast ../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast ../include/linux/kernel.h:723:17: warning: comparison of distinct pointer types lacks a cast ../drivers/scsi/qla2xxx/qla_target.c:3086:6: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 8 has type 'uint32_t {aka unsigned int}' [-Wformat=] ../drivers/scsi/qla2xxx/qla_target.c:3083:17: warning: unused variable 'se_cmd' [-Wunused-variable] ../drivers/scsi/ips.c:210:2: warning: #warning "This driver has only been tested on the x86/ia64/x86_64 platforms" [-Wcpp] ------------------------------------------------------------------------------- arm64-defconfig : FAIL, 1 errors, 0 warnings, 0 section mismatches Errors: ../arch/arm64/kvm/handle_exit.c:45:3: error: implicit declaration of function 'vcpu_set_reg' [-Werror=implicit-function-declaration] ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: x86_64-allnoconfig arm64-allnoconfig arm-allnoconfig close failed in file object destructor: sys.excepthook is missing lost sys.stderr

7 years, 1 month

1
0
0 0

requesting stable backport for 4.1 and 4.4: 95a762e2c8c9 ("bpf: fix incorrect sign extension in check_alu_op()")

by Jann Horn

Hi! Someone on Twitter (https://twitter.com/vnik5287/status/974277953394651137) is pointing out that the BPF fix commit 95a762e2c8c942780948091f8f2a4f32fce1ac6f ("bpf: fix incorrect sign extension in check_alu_op()") needs to be applied all the way back to 4.4, and probably also 4.1; my "Fixes:" tag on that commit is incorrect. I assumed that without map access, math correctness issues don't matter, but actually, this one does matter because check_cond_jmp_op() will omit verification for branches that appear to be unreachable (comparison of CONST_IMM register and a constant value). :/ FWIW, I checked by hand what the binary blob of BPF code in the linked PoC does, and it's basically this (with some error checking and other minor stuff omitted): // trick the verifier into not checking any of the code below r9 = (u32)-1 if (r9 == (s32)-1) exit 0 // read some configuration r6 = *map_lookup_elem(MAP_FD, &0) // operation selector r7 = *map_lookup_elem(MAP_FD, &1) // pointer to access r8 = *map_lookup_elem(MAP_FD, &2) // value to write r2 = map_lookup_elem(MAP_FD, &2) if r6 == 0: // operation: read r3 = *r7 *r2 = r3 exit if r6 == 1: // operation: get frame pointer *r2 = fp exit *r7 = r8 // operation: write exit The author of the tweet does point out that this exploit is mitigated by sanitize_dead_code() (introduced in "bpf: fix branch pruning logic" and backported all the way), but 95a762e2c8c9 should still be applied.

7 years, 1 month

4
5
0 0

Patch "USB: gadget: udc: Add missing platform_device_put() on error in bdc_pci_probe()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: gadget: udc: Add missing platform_device_put() on error in bdc_pci_probe() to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-gadget-udc-add-missing-platform_device_put-on-error-in-bdc_pci_probe.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 8874ae5f15f3feef3b4a415b9aed51edcf449aa1 Mon Sep 17 00:00:00 2001 From: Wei Yongjun <weiyongjun1(a)huawei.com> Date: Tue, 23 Jan 2018 09:35:14 +0000 Subject: USB: gadget: udc: Add missing platform_device_put() on error in bdc_pci_probe() From: Wei Yongjun <weiyongjun1(a)huawei.com> commit 8874ae5f15f3feef3b4a415b9aed51edcf449aa1 upstream. Add the missing platform_device_put() before return from bdc_pci_probe() in the platform_device_add_resources() error handling case. Fixes: efed421a94e6 ("usb: gadget: Add UDC driver for Broadcom USB3.0 device controller IP BDC") Signed-off-by: Wei Yongjun <weiyongjun1(a)huawei.com> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/gadget/udc/bdc/bdc_pci.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/usb/gadget/udc/bdc/bdc_pci.c +++ b/drivers/usb/gadget/udc/bdc/bdc_pci.c @@ -82,6 +82,7 @@ static int bdc_pci_probe(struct pci_dev if (ret) { dev_err(&pci->dev, "couldn't add resources to bdc device\n"); + platform_device_put(bdc); return ret; } Patches currently in stable-queue which might be from weiyongjun1(a)huawei.com are queue-4.9/usb-gadget-udc-add-missing-platform_device_put-on-error-in-bdc_pci_probe.patch

7 years, 1 month

1
0
0 0

Patch "usb: dwc3: Fix GDBGFIFOSPACE_TYPE values" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: dwc3: Fix GDBGFIFOSPACE_TYPE values to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-dwc3-fix-gdbgfifospace_type-values.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From b16ea8b9492e99e03b1269fe93ebdbf8e4eabf8a Mon Sep 17 00:00:00 2001 From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> Date: Fri, 2 Feb 2018 13:21:35 -0800 Subject: usb: dwc3: Fix GDBGFIFOSPACE_TYPE values From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> commit b16ea8b9492e99e03b1269fe93ebdbf8e4eabf8a upstream. The FIFO/Queue type values are incorrect. Correct them according to DWC_usb3 programming guide section 1.2.27 (or DWC_usb31 section 1.2.25). Additionally, this patch includes ProtocolStatusQ and AuxEventQ types. Fixes: cf6d867d3b57 ("usb: dwc3: core: add fifo space helper") Signed-off-by: Thinh Nguyen <thinhn(a)synopsys.com> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/dwc3/core.h | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) --- a/drivers/usb/dwc3/core.h +++ b/drivers/usb/dwc3/core.h @@ -159,13 +159,15 @@ #define DWC3_GDBGFIFOSPACE_TYPE(n) (((n) << 5) & 0x1e0) #define DWC3_GDBGFIFOSPACE_SPACE_AVAILABLE(n) (((n) >> 16) & 0xffff) -#define DWC3_TXFIFOQ 1 -#define DWC3_RXFIFOQ 3 -#define DWC3_TXREQQ 5 -#define DWC3_RXREQQ 7 -#define DWC3_RXINFOQ 9 -#define DWC3_DESCFETCHQ 13 -#define DWC3_EVENTQ 15 +#define DWC3_TXFIFOQ 0 +#define DWC3_RXFIFOQ 1 +#define DWC3_TXREQQ 2 +#define DWC3_RXREQQ 3 +#define DWC3_RXINFOQ 4 +#define DWC3_PSTATQ 5 +#define DWC3_DESCFETCHQ 6 +#define DWC3_EVENTQ 7 +#define DWC3_AUXEVENTQ 8 /* Global RX Threshold Configuration Register */ #define DWC3_GRXTHRCFG_MAXRXBURSTSIZE(n) (((n) & 0x1f) << 19) Patches currently in stable-queue which might be from Thinh.Nguyen(a)synopsys.com are queue-4.9/usb-dwc3-fix-gdbgfifospace_type-values.patch

7 years, 1 month

1
0
0 0

Patch "scsi: qla2xxx: Fix extraneous ref on sp's after adapter break" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: qla2xxx: Fix extraneous ref on sp's after adapter break to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-qla2xxx-fix-extraneous-ref-on-sp-s-after-adapter-break.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 4cd3b6ebff8510b2139d64024411207090cfe0a9 Mon Sep 17 00:00:00 2001 From: Bill Kuzeja <William.Kuzeja(a)stratus.com> Date: Thu, 25 May 2017 15:26:31 -0400 Subject: scsi: qla2xxx: Fix extraneous ref on sp's after adapter break From: Bill Kuzeja <William.Kuzeja(a)stratus.com> commit 4cd3b6ebff8510b2139d64024411207090cfe0a9 upstream. Hung task timeouts can result if a qlogic board breaks unexpectedly while running I/O. These tasks become hung because command srb reference counts are not going to zero, hence the affected srbs and commands do not get freed. This fix accounts for this extra reference in the srbs in the case of a board failure. Fixes: a465537ad1a4 ("qla2xxx: Disable the adapter and skip error recovery in case of register disconnect") Signed-off-by: Bill Kuzeja <william.kuzeja(a)stratus.com> Acked-by: Himanshu Madhani <himanshu.madhani(a)cavium.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/qla2xxx/qla_os.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) --- a/drivers/scsi/qla2xxx/qla_os.c +++ b/drivers/scsi/qla2xxx/qla_os.c @@ -1443,7 +1443,7 @@ qla2x00_loop_reset(scsi_qla_host_t *vha) void qla2x00_abort_all_cmds(scsi_qla_host_t *vha, int res) { - int que, cnt; + int que, cnt, status; unsigned long flags; srb_t *sp; struct qla_hw_data *ha = vha->hw; @@ -1473,8 +1473,12 @@ qla2x00_abort_all_cmds(scsi_qla_host_t * */ sp_get(sp); spin_unlock_irqrestore(&ha->hardware_lock, flags); - qla2xxx_eh_abort(GET_CMD_SP(sp)); + status = qla2xxx_eh_abort(GET_CMD_SP(sp)); spin_lock_irqsave(&ha->hardware_lock, flags); + /* Get rid of extra reference if immediate exit + * from ql2xxx_eh_abort */ + if (status == FAILED && (qla2x00_isp_reg_stat(ha))) + atomic_dec(&sp->ref_count); } req->outstanding_cmds[cnt] = NULL; sp->done(vha, sp, res); Patches currently in stable-queue which might be from William.Kuzeja(a)stratus.com are queue-4.9/scsi-qla2xxx-fix-extraneous-ref-on-sp-s-after-adapter-break.patch

7 years, 1 month

1
0
0 0

Patch "usb: gadget: bdc: 64-bit pointer capability check" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: gadget: bdc: 64-bit pointer capability check to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-gadget-bdc-64-bit-pointer-capability-check.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From c8e4e5bdb62a5ac6f860ebcaaf7b467b62f453f1 Mon Sep 17 00:00:00 2001 From: Srinath Mannam <srinath.mannam(a)broadcom.com> Date: Thu, 15 Jun 2017 14:39:22 +0530 Subject: usb: gadget: bdc: 64-bit pointer capability check From: Srinath Mannam <srinath.mannam(a)broadcom.com> commit c8e4e5bdb62a5ac6f860ebcaaf7b467b62f453f1 upstream. Corrected the register to check the 64-bit pointer capability state. 64-bit pointer implementation capability was checking in wrong register, which causes the BDC enumeration failure in 64-bit memory address. Fixes: efed421a94e6 ("usb: gadget: Add UDC driver for Broadcom USB3.0 device controller IP BDC") Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com> Signed-off-by: Srinath Mannam <srinath.mannam(a)broadcom.com> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/gadget/udc/bdc/bdc_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/usb/gadget/udc/bdc/bdc_core.c +++ b/drivers/usb/gadget/udc/bdc/bdc_core.c @@ -475,7 +475,7 @@ static int bdc_probe(struct platform_dev bdc->dev = dev; dev_dbg(bdc->dev, "bdc->regs: %p irq=%d\n", bdc->regs, bdc->irq); - temp = bdc_readl(bdc->regs, BDC_BDCSC); + temp = bdc_readl(bdc->regs, BDC_BDCCAP1); if ((temp & BDC_P64) && !dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) { dev_dbg(bdc->dev, "Using 64-bit address\n"); Patches currently in stable-queue which might be from srinath.mannam(a)broadcom.com are queue-4.9/usb-gadget-bdc-64-bit-pointer-capability-check.patch

7 years, 1 month

1
0
0 0

Patch "USB: gadget: udc: Add missing platform_device_put() on error in bdc_pci_probe()" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: gadget: udc: Add missing platform_device_put() on error in bdc_pci_probe() to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-gadget-udc-add-missing-platform_device_put-on-error-in-bdc_pci_probe.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 8874ae5f15f3feef3b4a415b9aed51edcf449aa1 Mon Sep 17 00:00:00 2001 From: Wei Yongjun <weiyongjun1(a)huawei.com> Date: Tue, 23 Jan 2018 09:35:14 +0000 Subject: USB: gadget: udc: Add missing platform_device_put() on error in bdc_pci_probe() From: Wei Yongjun <weiyongjun1(a)huawei.com> commit 8874ae5f15f3feef3b4a415b9aed51edcf449aa1 upstream. Add the missing platform_device_put() before return from bdc_pci_probe() in the platform_device_add_resources() error handling case. Fixes: efed421a94e6 ("usb: gadget: Add UDC driver for Broadcom USB3.0 device controller IP BDC") Signed-off-by: Wei Yongjun <weiyongjun1(a)huawei.com> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/gadget/udc/bdc/bdc_pci.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/usb/gadget/udc/bdc/bdc_pci.c +++ b/drivers/usb/gadget/udc/bdc/bdc_pci.c @@ -82,6 +82,7 @@ static int bdc_pci_probe(struct pci_dev if (ret) { dev_err(&pci->dev, "couldn't add resources to bdc device\n"); + platform_device_put(bdc); return ret; } Patches currently in stable-queue which might be from weiyongjun1(a)huawei.com are queue-4.4/usb-gadget-udc-add-missing-platform_device_put-on-error-in-bdc_pci_probe.patch

7 years, 1 month

1
0
0 0

Patch "usb: gadget: bdc: 64-bit pointer capability check" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: gadget: bdc: 64-bit pointer capability check to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-gadget-bdc-64-bit-pointer-capability-check.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From c8e4e5bdb62a5ac6f860ebcaaf7b467b62f453f1 Mon Sep 17 00:00:00 2001 From: Srinath Mannam <srinath.mannam(a)broadcom.com> Date: Thu, 15 Jun 2017 14:39:22 +0530 Subject: usb: gadget: bdc: 64-bit pointer capability check From: Srinath Mannam <srinath.mannam(a)broadcom.com> commit c8e4e5bdb62a5ac6f860ebcaaf7b467b62f453f1 upstream. Corrected the register to check the 64-bit pointer capability state. 64-bit pointer implementation capability was checking in wrong register, which causes the BDC enumeration failure in 64-bit memory address. Fixes: efed421a94e6 ("usb: gadget: Add UDC driver for Broadcom USB3.0 device controller IP BDC") Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com> Signed-off-by: Srinath Mannam <srinath.mannam(a)broadcom.com> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/gadget/udc/bdc/bdc_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/usb/gadget/udc/bdc/bdc_core.c +++ b/drivers/usb/gadget/udc/bdc/bdc_core.c @@ -475,7 +475,7 @@ static int bdc_probe(struct platform_dev bdc->dev = dev; dev_dbg(bdc->dev, "bdc->regs: %p irq=%d\n", bdc->regs, bdc->irq); - temp = bdc_readl(bdc->regs, BDC_BDCSC); + temp = bdc_readl(bdc->regs, BDC_BDCCAP1); if ((temp & BDC_P64) && !dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) { dev_dbg(bdc->dev, "Using 64-bit address\n"); Patches currently in stable-queue which might be from srinath.mannam(a)broadcom.com are queue-4.4/usb-gadget-bdc-64-bit-pointer-capability-check.patch

7 years, 1 month

1
0
0 0

Patch "usb: gadget: udc: renesas_usb3: fix oops in renesas_usb3_remove()" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: gadget: udc: renesas_usb3: fix oops in renesas_usb3_remove() to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-gadget-udc-renesas_usb3-fix-oops-in-renesas_usb3_remove.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From e3190868e5f52fb26544f16463593d54ce46ce61 Mon Sep 17 00:00:00 2001 From: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com> Date: Fri, 12 Jan 2018 20:00:56 +0900 Subject: usb: gadget: udc: renesas_usb3: fix oops in renesas_usb3_remove() From: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com> commit e3190868e5f52fb26544f16463593d54ce46ce61 upstream. This patch fixes an issue that the renesas_usb3_remove() causes NULL pointer dereference because the usb3_to_dev() macro will use the gadget instance and it will be deleted before. Fixes: cf06df3fae28 ("usb: gadget: udc: renesas_usb3: move pm_runtime_{en,dis}able()") Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/gadget/udc/renesas_usb3.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/usb/gadget/udc/renesas_usb3.c +++ b/drivers/usb/gadget/udc/renesas_usb3.c @@ -2410,7 +2410,7 @@ static int renesas_usb3_remove(struct pl __renesas_usb3_ep_free_request(usb3->ep0_req); if (usb3->phy) phy_put(usb3->phy); - pm_runtime_disable(usb3_to_dev(usb3)); + pm_runtime_disable(&pdev->dev); return 0; } Patches currently in stable-queue which might be from yoshihiro.shimoda.uh(a)renesas.com are queue-4.15/usb-gadget-udc-renesas_usb3-fix-oops-in-renesas_usb3_remove.patch

7 years, 1 month

1
0
0 0

Patch "USB: gadget: udc: Add missing platform_device_put() on error in bdc_pci_probe()" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: gadget: udc: Add missing platform_device_put() on error in bdc_pci_probe() to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-gadget-udc-add-missing-platform_device_put-on-error-in-bdc_pci_probe.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 8874ae5f15f3feef3b4a415b9aed51edcf449aa1 Mon Sep 17 00:00:00 2001 From: Wei Yongjun <weiyongjun1(a)huawei.com> Date: Tue, 23 Jan 2018 09:35:14 +0000 Subject: USB: gadget: udc: Add missing platform_device_put() on error in bdc_pci_probe() From: Wei Yongjun <weiyongjun1(a)huawei.com> commit 8874ae5f15f3feef3b4a415b9aed51edcf449aa1 upstream. Add the missing platform_device_put() before return from bdc_pci_probe() in the platform_device_add_resources() error handling case. Fixes: efed421a94e6 ("usb: gadget: Add UDC driver for Broadcom USB3.0 device controller IP BDC") Signed-off-by: Wei Yongjun <weiyongjun1(a)huawei.com> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/gadget/udc/bdc/bdc_pci.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/usb/gadget/udc/bdc/bdc_pci.c +++ b/drivers/usb/gadget/udc/bdc/bdc_pci.c @@ -77,6 +77,7 @@ static int bdc_pci_probe(struct pci_dev if (ret) { dev_err(&pci->dev, "couldn't add resources to bdc device\n"); + platform_device_put(bdc); return ret; } Patches currently in stable-queue which might be from weiyongjun1(a)huawei.com are queue-4.15/usb-gadget-udc-add-missing-platform_device_put-on-error-in-bdc_pci_probe.patch

7 years, 1 month

1
0
0 0

Patch "usb: dwc3: of-simple: fix oops by unbalanced clk disable call" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: dwc3: of-simple: fix oops by unbalanced clk disable call to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-dwc3-of-simple-fix-oops-by-unbalanced-clk-disable-call.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From bff52352e0ccc2481f2b6b0d612ff8ff56c50f3a Mon Sep 17 00:00:00 2001 From: Enric Balletbo i Serra <enric.balletbo(a)collabora.com> Date: Mon, 18 Dec 2017 16:14:36 +0100 Subject: usb: dwc3: of-simple: fix oops by unbalanced clk disable call From: Enric Balletbo i Serra <enric.balletbo(a)collabora.com> commit bff52352e0ccc2481f2b6b0d612ff8ff56c50f3a upstream. dwc3_of_simple_dev_pm_ops has never been used since commit a0d8c4cfdf31 ("usb: dwc3: of-simple: set dev_pm_ops"), but this commit has brought and oops when unbind the device due this sequence: dwc3_of_simple_remove -> clk_disable ... -> pm_runtime_put_sync -> dwc3_of_simple_runtime_suspend -> clk_disable (again) This double call to clk_core_disable causes a kernel oops like this: WARNING: CPU: 1 PID: 4022 at drivers/clk/clk.c:656 clk_core_disable+0x78/0x80 CPU: 1 PID: 4022 Comm: bash Not tainted 4.15.0-rc4+ #44 Hardware name: Google Kevin (DT) pstate: 80000085 (Nzcv daIf -PAN -UAO) pc : clk_core_disable+0x78/0x80 lr : clk_core_disable_lock+0x20/0x38 sp : ffff00000bbf3a90 ... Call trace: clk_core_disable+0x78/0x80 clk_disable+0x1c/0x30 dwc3_of_simple_runtime_suspend+0x30/0x50 pm_generic_runtime_suspend+0x28/0x40 This patch fixes the unbalanced clk disable call by setting the num_clocks variable to zero once the clocks were disabled. Fixes: a0d8c4cfdf31 ("usb: dwc3: of-simple: set dev_pm_ops") Signed-off-by: Enric Balletbo i Serra <enric.balletbo(a)collabora.com> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/dwc3/dwc3-of-simple.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/usb/dwc3/dwc3-of-simple.c +++ b/drivers/usb/dwc3/dwc3-of-simple.c @@ -143,6 +143,7 @@ static int dwc3_of_simple_remove(struct clk_disable_unprepare(simple->clks[i]); clk_put(simple->clks[i]); } + simple->num_clocks = 0; reset_control_assert(simple->resets); reset_control_put(simple->resets); Patches currently in stable-queue which might be from enric.balletbo(a)collabora.com are queue-4.15/usb-dwc3-of-simple-fix-oops-by-unbalanced-clk-disable-call.patch

7 years, 1 month

1
0
0 0

Patch "usb: dwc3: Fix GDBGFIFOSPACE_TYPE values" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: dwc3: Fix GDBGFIFOSPACE_TYPE values to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-dwc3-fix-gdbgfifospace_type-values.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From b16ea8b9492e99e03b1269fe93ebdbf8e4eabf8a Mon Sep 17 00:00:00 2001 From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> Date: Fri, 2 Feb 2018 13:21:35 -0800 Subject: usb: dwc3: Fix GDBGFIFOSPACE_TYPE values From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> commit b16ea8b9492e99e03b1269fe93ebdbf8e4eabf8a upstream. The FIFO/Queue type values are incorrect. Correct them according to DWC_usb3 programming guide section 1.2.27 (or DWC_usb31 section 1.2.25). Additionally, this patch includes ProtocolStatusQ and AuxEventQ types. Fixes: cf6d867d3b57 ("usb: dwc3: core: add fifo space helper") Signed-off-by: Thinh Nguyen <thinhn(a)synopsys.com> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/dwc3/core.h | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) --- a/drivers/usb/dwc3/core.h +++ b/drivers/usb/dwc3/core.h @@ -158,13 +158,15 @@ #define DWC3_GDBGFIFOSPACE_TYPE(n) (((n) << 5) & 0x1e0) #define DWC3_GDBGFIFOSPACE_SPACE_AVAILABLE(n) (((n) >> 16) & 0xffff) -#define DWC3_TXFIFOQ 1 -#define DWC3_RXFIFOQ 3 -#define DWC3_TXREQQ 5 -#define DWC3_RXREQQ 7 -#define DWC3_RXINFOQ 9 -#define DWC3_DESCFETCHQ 13 -#define DWC3_EVENTQ 15 +#define DWC3_TXFIFOQ 0 +#define DWC3_RXFIFOQ 1 +#define DWC3_TXREQQ 2 +#define DWC3_RXREQQ 3 +#define DWC3_RXINFOQ 4 +#define DWC3_PSTATQ 5 +#define DWC3_DESCFETCHQ 6 +#define DWC3_EVENTQ 7 +#define DWC3_AUXEVENTQ 8 /* Global RX Threshold Configuration Register */ #define DWC3_GRXTHRCFG_MAXRXBURSTSIZE(n) (((n) & 0x1f) << 19) Patches currently in stable-queue which might be from Thinh.Nguyen(a)synopsys.com are queue-4.15/usb-dwc3-fix-gdbgfifospace_type-values.patch

7 years, 1 month

1
0
0 0

Patch "usb: dwc3: core: Power-off core/PHYs on system_suspend in host mode" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: dwc3: core: Power-off core/PHYs on system_suspend in host mode to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-dwc3-core-power-off-core-phys-on-system_suspend-in-host-mode.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From c4a5153e87fdf6805f63ff57556260e2554155a5 Mon Sep 17 00:00:00 2001 From: Manu Gautam <mgautam(a)codeaurora.org> Date: Thu, 18 Jan 2018 16:54:30 +0530 Subject: usb: dwc3: core: Power-off core/PHYs on system_suspend in host mode From: Manu Gautam <mgautam(a)codeaurora.org> commit c4a5153e87fdf6805f63ff57556260e2554155a5 upstream. Commit 689bf72c6e0d ("usb: dwc3: Don't reinitialize core during host bus-suspend/resume") updated suspend/resume routines to not power_off and reinit PHYs/core for host mode. It broke platforms that rely on DWC3 core to power_off PHYs to enter low power state on system suspend. Perform dwc3_core_exit/init only during host mode system_suspend/ resume to addresses power regression from above mentioned patch and also allow USB session to stay connected across runtime_suspend/resume in host mode. While at it also replace existing checks for HOST only dr_mode with current_dr_role to have similar core driver behavior for both Host-only and DRD+Host configurations. Fixes: 689bf72c6e0d ("usb: dwc3: Don't reinitialize core during host bus-suspend/resume") Reviewed-by: Roger Quadros <rogerq(a)ti.com> Signed-off-by: Manu Gautam <mgautam(a)codeaurora.org> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/dwc3/core.c | 36 ++++++++++++++++++++++-------------- 1 file changed, 22 insertions(+), 14 deletions(-) --- a/drivers/usb/dwc3/core.c +++ b/drivers/usb/dwc3/core.c @@ -100,6 +100,8 @@ static void dwc3_set_prtcap(struct dwc3 reg &= ~(DWC3_GCTL_PRTCAPDIR(DWC3_GCTL_PRTCAP_OTG)); reg |= DWC3_GCTL_PRTCAPDIR(mode); dwc3_writel(dwc->regs, DWC3_GCTL, reg); + + dwc->current_dr_role = mode; } static void __dwc3_set_mode(struct work_struct *work) @@ -133,8 +135,6 @@ static void __dwc3_set_mode(struct work_ dwc3_set_prtcap(dwc, dwc->desired_dr_role); - dwc->current_dr_role = dwc->desired_dr_role; - spin_unlock_irqrestore(&dwc->lock, flags); switch (dwc->desired_dr_role) { @@ -218,7 +218,7 @@ static int dwc3_core_soft_reset(struct d * XHCI driver will reset the host block. If dwc3 was configured for * host-only mode, then we can return early. */ - if (dwc->dr_mode == USB_DR_MODE_HOST) + if (dwc->current_dr_role == DWC3_GCTL_PRTCAP_HOST) return 0; reg = dwc3_readl(dwc->regs, DWC3_DCTL); @@ -915,7 +915,6 @@ static int dwc3_core_init_mode(struct dw switch (dwc->dr_mode) { case USB_DR_MODE_PERIPHERAL: - dwc->current_dr_role = DWC3_GCTL_PRTCAP_DEVICE; dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_DEVICE); if (dwc->usb2_phy) @@ -931,7 +930,6 @@ static int dwc3_core_init_mode(struct dw } break; case USB_DR_MODE_HOST: - dwc->current_dr_role = DWC3_GCTL_PRTCAP_HOST; dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_HOST); if (dwc->usb2_phy) @@ -1279,7 +1277,7 @@ static int dwc3_remove(struct platform_d } #ifdef CONFIG_PM -static int dwc3_suspend_common(struct dwc3 *dwc) +static int dwc3_suspend_common(struct dwc3 *dwc, pm_message_t msg) { unsigned long flags; @@ -1291,6 +1289,10 @@ static int dwc3_suspend_common(struct dw dwc3_core_exit(dwc); break; case DWC3_GCTL_PRTCAP_HOST: + /* do nothing during host runtime_suspend */ + if (!PMSG_IS_AUTO(msg)) + dwc3_core_exit(dwc); + break; default: /* do nothing */ break; @@ -1299,7 +1301,7 @@ static int dwc3_suspend_common(struct dw return 0; } -static int dwc3_resume_common(struct dwc3 *dwc) +static int dwc3_resume_common(struct dwc3 *dwc, pm_message_t msg) { unsigned long flags; int ret; @@ -1315,6 +1317,13 @@ static int dwc3_resume_common(struct dwc spin_unlock_irqrestore(&dwc->lock, flags); break; case DWC3_GCTL_PRTCAP_HOST: + /* nothing to do on host runtime_resume */ + if (!PMSG_IS_AUTO(msg)) { + ret = dwc3_core_init(dwc); + if (ret) + return ret; + } + break; default: /* do nothing */ break; @@ -1326,12 +1335,11 @@ static int dwc3_resume_common(struct dwc static int dwc3_runtime_checks(struct dwc3 *dwc) { switch (dwc->current_dr_role) { - case USB_DR_MODE_PERIPHERAL: - case USB_DR_MODE_OTG: + case DWC3_GCTL_PRTCAP_DEVICE: if (dwc->connected) return -EBUSY; break; - case USB_DR_MODE_HOST: + case DWC3_GCTL_PRTCAP_HOST: default: /* do nothing */ break; @@ -1348,7 +1356,7 @@ static int dwc3_runtime_suspend(struct d if (dwc3_runtime_checks(dwc)) return -EBUSY; - ret = dwc3_suspend_common(dwc); + ret = dwc3_suspend_common(dwc, PMSG_AUTO_SUSPEND); if (ret) return ret; @@ -1364,7 +1372,7 @@ static int dwc3_runtime_resume(struct de device_init_wakeup(dev, false); - ret = dwc3_resume_common(dwc); + ret = dwc3_resume_common(dwc, PMSG_AUTO_RESUME); if (ret) return ret; @@ -1411,7 +1419,7 @@ static int dwc3_suspend(struct device *d struct dwc3 *dwc = dev_get_drvdata(dev); int ret; - ret = dwc3_suspend_common(dwc); + ret = dwc3_suspend_common(dwc, PMSG_SUSPEND); if (ret) return ret; @@ -1427,7 +1435,7 @@ static int dwc3_resume(struct device *de pinctrl_pm_select_default_state(dev); - ret = dwc3_resume_common(dwc); + ret = dwc3_resume_common(dwc, PMSG_RESUME); if (ret) return ret; Patches currently in stable-queue which might be from mgautam(a)codeaurora.org are queue-4.15/usb-dwc3-core-power-off-core-phys-on-system_suspend-in-host-mode.patch

7 years, 1 month

1
0
0 0

Patch "scsi: qla2xxx: Fix smatch warning in qla25xx_delete_{rsp|req}_que" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: qla2xxx: Fix smatch warning in qla25xx_delete_{rsp|req}_que to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-qla2xxx-fix-smatch-warning-in-qla25xx_delete_-rsp-req-_que.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 62aa281470fdb7c0796d63a1cc918a8c1f02dde2 Mon Sep 17 00:00:00 2001 From: Himanshu Madhani <himanshu.madhani(a)cavium.com> Date: Sat, 16 Dec 2017 16:05:09 -0800 Subject: scsi: qla2xxx: Fix smatch warning in qla25xx_delete_{rsp|req}_que From: Himanshu Madhani <himanshu.madhani(a)cavium.com> commit 62aa281470fdb7c0796d63a1cc918a8c1f02dde2 upstream. This patch fixes following warnings reported by smatch: drivers/scsi/qla2xxx/qla_mid.c:586 qla25xx_delete_req_que() error: we previously assumed 'req' could be null (see line 580) drivers/scsi/qla2xxx/qla_mid.c:602 qla25xx_delete_rsp_que() error: we previously assumed 'rsp' could be null (see line 596) Fixes: 7867b98dceb7 ("scsi: qla2xxx: Fix memory leak in dual/target mode") Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com> Signed-off-by: Himanshu Madhani <himanshu.madhani(a)cavium.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/qla2xxx/qla_mid.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/drivers/scsi/qla2xxx/qla_mid.c +++ b/drivers/scsi/qla2xxx/qla_mid.c @@ -582,8 +582,9 @@ qla25xx_delete_req_que(struct scsi_qla_h ret = qla25xx_init_req_que(vha, req); if (ret != QLA_SUCCESS) return QLA_FUNCTION_FAILED; + + qla25xx_free_req_que(vha, req); } - qla25xx_free_req_que(vha, req); return ret; } @@ -598,8 +599,9 @@ qla25xx_delete_rsp_que(struct scsi_qla_h ret = qla25xx_init_rsp_que(vha, rsp); if (ret != QLA_SUCCESS) return QLA_FUNCTION_FAILED; + + qla25xx_free_rsp_que(vha, rsp); } - qla25xx_free_rsp_que(vha, rsp); return ret; } Patches currently in stable-queue which might be from himanshu.madhani(a)cavium.com are queue-4.15/scsi-qla2xxx-fix-smatch-warning-in-qla25xx_delete_-rsp-req-_que.patch queue-4.15/scsi-qla2xxx-fix-crashes-in-qla2x00_probe_one-on-probe-failure.patch queue-4.15/scsi-qla2xxx-fix-null-pointer-access-for-fcport-structure.patch

7 years, 1 month

1
0
0 0

Patch "usb: dwc2: fix STM32F7 USB OTG HS compatible" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: dwc2: fix STM32F7 USB OTG HS compatible to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-dwc2-fix-stm32f7-usb-otg-hs-compatible.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 1a149e3554e0324a3d551dfb327bdb67b150a320 Mon Sep 17 00:00:00 2001 From: Amelie Delaunay <amelie.delaunay(a)st.com> Date: Thu, 1 Mar 2018 11:05:35 +0100 Subject: usb: dwc2: fix STM32F7 USB OTG HS compatible From: Amelie Delaunay <amelie.delaunay(a)st.com> commit 1a149e3554e0324a3d551dfb327bdb67b150a320 upstream. This patch fixes compatible for STM32F7 USB OTG HS and consistently rename dw2_set_params function. The v2 former patch [1] had been acked by Paul Young, but v1 was merged. [1] https://patchwork.kernel.org/patch/9925573/ Fixes: d8fae8b93682 ("usb: dwc2: add support for STM32F7xx USB OTG HS") Signed-off-by: Amelie Delaunay <amelie.delaunay(a)st.com> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/dwc2/params.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/drivers/usb/dwc2/params.c +++ b/drivers/usb/dwc2/params.c @@ -137,7 +137,7 @@ static void dwc2_set_stm32f4x9_fsotg_par p->activate_stm_fs_transceiver = true; } -static void dwc2_set_stm32f7xx_hsotg_params(struct dwc2_hsotg *hsotg) +static void dwc2_set_stm32f7_hsotg_params(struct dwc2_hsotg *hsotg) { struct dwc2_core_params *p = &hsotg->params; @@ -164,8 +164,8 @@ const struct of_device_id dwc2_of_match_ { .compatible = "st,stm32f4x9-fsotg", .data = dwc2_set_stm32f4x9_fsotg_params }, { .compatible = "st,stm32f4x9-hsotg" }, - { .compatible = "st,stm32f7xx-hsotg", - .data = dwc2_set_stm32f7xx_hsotg_params }, + { .compatible = "st,stm32f7-hsotg", + .data = dwc2_set_stm32f7_hsotg_params }, {}, }; MODULE_DEVICE_TABLE(of, dwc2_of_match_table); Patches currently in stable-queue which might be from amelie.delaunay(a)st.com are queue-4.15/usb-dwc2-fix-stm32f7-usb-otg-hs-compatible.patch queue-4.15/dt-bindings-usb-fix-the-stm32f7-dwc2-otg-hs-core-binding.patch

7 years, 1 month

1
0
0 0

Patch "scsi: qla2xxx: Fix NULL pointer access for fcport structure" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: qla2xxx: Fix NULL pointer access for fcport structure to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-qla2xxx-fix-null-pointer-access-for-fcport-structure.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 5c25d451163cab9be80744cbc5448d6b95ab8d1a Mon Sep 17 00:00:00 2001 From: Quinn Tran <quinn.tran(a)cavium.com> Date: Thu, 28 Dec 2017 12:33:09 -0800 Subject: scsi: qla2xxx: Fix NULL pointer access for fcport structure From: Quinn Tran <quinn.tran(a)cavium.com> commit 5c25d451163cab9be80744cbc5448d6b95ab8d1a upstream. when processing iocb in a timeout case, driver was trying to log messages without verifying if the fcport structure could have valid data. This results in a NULL pointer access. Fixes: 726b85487067("qla2xxx: Add framework for async fabric discovery") Signed-off-by: Quinn Tran <quinn.tran(a)cavium.com> Signed-off-by: Himanshu Madhani <himanshu.madhani(a)cavium.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/qla2xxx/qla_init.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) --- a/drivers/scsi/qla2xxx/qla_init.c +++ b/drivers/scsi/qla2xxx/qla_init.c @@ -102,11 +102,16 @@ qla2x00_async_iocb_timeout(void *data) struct srb_iocb *lio = &sp->u.iocb_cmd; struct event_arg ea; - ql_dbg(ql_dbg_disc, fcport->vha, 0x2071, - "Async-%s timeout - hdl=%x portid=%06x %8phC.\n", - sp->name, sp->handle, fcport->d_id.b24, fcport->port_name); + if (fcport) { + ql_dbg(ql_dbg_disc, fcport->vha, 0x2071, + "Async-%s timeout - hdl=%x portid=%06x %8phC.\n", + sp->name, sp->handle, fcport->d_id.b24, fcport->port_name); - fcport->flags &= ~FCF_ASYNC_SENT; + fcport->flags &= ~FCF_ASYNC_SENT; + } else { + pr_info("Async-%s timeout - hdl=%x.\n", + sp->name, sp->handle); + } switch (sp->type) { case SRB_LOGIN_CMD: Patches currently in stable-queue which might be from quinn.tran(a)cavium.com are queue-4.15/scsi-qla2xxx-fix-null-pointer-access-for-fcport-structure.patch

7 years, 1 month

1
0
0 0

Patch "scsi: qla2xxx: Fix logo flag for qlt_free_session_done()" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: qla2xxx: Fix logo flag for qlt_free_session_done() to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-qla2xxx-fix-logo-flag-for-qlt_free_session_done.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From a2390348c19d0819d525d375414a7cfdacb51a68 Mon Sep 17 00:00:00 2001 From: Himanshu Madhani <hmadhani(a)redhat.com> Date: Mon, 22 Jan 2018 12:04:20 -0800 Subject: scsi: qla2xxx: Fix logo flag for qlt_free_session_done() From: Himanshu Madhani <hmadhani(a)redhat.com> commit a2390348c19d0819d525d375414a7cfdacb51a68 upstream. Commit 3515832cc614 ("scsi: qla2xxx: Reset the logo flag, after target re-login.")fixed the target re-login after session relogin is complete, but missed out the qlt_free_session_done() path. This patch clears send_els_logo flag in qlt_free_session_done() callback. [mkp: checkpatch] Fixes: 3515832cc614 ("scsi: qla2xxx: Reset the logo flag, after target re-login.") Signed-off-by: Himanshu Madhani <hmadhani(a)redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/qla2xxx/qla_target.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/scsi/qla2xxx/qla_target.c +++ b/drivers/scsi/qla2xxx/qla_target.c @@ -982,6 +982,7 @@ static void qlt_free_session_done(struct logo.id = sess->d_id; logo.cmd_count = 0; + sess->send_els_logo = 0; qlt_send_first_logo(vha, &logo); } Patches currently in stable-queue which might be from hmadhani(a)redhat.com are queue-4.15/scsi-qla2xxx-fix-logo-flag-for-qlt_free_session_done.patch

7 years, 1 month

1
0
0 0

Patch "scsi: qla2xxx: Fix crashes in qla2x00_probe_one on probe failure" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: qla2xxx: Fix crashes in qla2x00_probe_one on probe failure to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-qla2xxx-fix-crashes-in-qla2x00_probe_one-on-probe-failure.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 6a2cf8d3663e13e19af636c2a8d92e766261dc45 Mon Sep 17 00:00:00 2001 From: Bill Kuzeja <William.Kuzeja(a)stratus.com> Date: Mon, 5 Mar 2018 00:02:55 -0500 Subject: scsi: qla2xxx: Fix crashes in qla2x00_probe_one on probe failure From: Bill Kuzeja <William.Kuzeja(a)stratus.com> commit 6a2cf8d3663e13e19af636c2a8d92e766261dc45 upstream. Because of the shifting around of code in qla2x00_probe_one recently, failures during adapter initialization can lead to problems, i.e. NULL pointer crashes and doubly freed data structures which cause eventual panics. This V2 version makes the relevant memory free routines idempotent, so repeat calls won't cause any harm. I also removed the problematic probe_init_failed exit point as it is not needed. Fixes: d64d6c5671db ("scsi: qla2xxx: Fix NULL pointer crash due to probe failure") Signed-off-by: Bill Kuzeja <william.kuzeja(a)stratus.com> Acked-by: Himanshu Madhani <himanshu.madhani(a)cavium.com> Reviewed-by: Hannes Reinecke <hare(a)suse.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/qla2xxx/qla_os.c | 59 ++++++++++++++++++++++++++---------------- 1 file changed, 37 insertions(+), 22 deletions(-) --- a/drivers/scsi/qla2xxx/qla_os.c +++ b/drivers/scsi/qla2xxx/qla_os.c @@ -449,7 +449,7 @@ static int qla2x00_alloc_queues(struct q ha->req_q_map[0] = req; set_bit(0, ha->rsp_qid_map); set_bit(0, ha->req_qid_map); - return 1; + return 0; fail_qpair_map: kfree(ha->base_qpair); @@ -466,6 +466,9 @@ fail_req_map: static void qla2x00_free_req_que(struct qla_hw_data *ha, struct req_que *req) { + if (!ha->req_q_map) + return; + if (IS_QLAFX00(ha)) { if (req && req->ring_fx00) dma_free_coherent(&ha->pdev->dev, @@ -476,14 +479,17 @@ static void qla2x00_free_req_que(struct (req->length + 1) * sizeof(request_t), req->ring, req->dma); - if (req) + if (req) { kfree(req->outstanding_cmds); - - kfree(req); + kfree(req); + } } static void qla2x00_free_rsp_que(struct qla_hw_data *ha, struct rsp_que *rsp) { + if (!ha->rsp_q_map) + return; + if (IS_QLAFX00(ha)) { if (rsp && rsp->ring) dma_free_coherent(&ha->pdev->dev, @@ -494,7 +500,8 @@ static void qla2x00_free_rsp_que(struct (rsp->length + 1) * sizeof(response_t), rsp->ring, rsp->dma); } - kfree(rsp); + if (rsp) + kfree(rsp); } static void qla2x00_free_queues(struct qla_hw_data *ha) @@ -1717,6 +1724,8 @@ qla2x00_abort_all_cmds(scsi_qla_host_t * struct qla_tgt_cmd *cmd; uint8_t trace = 0; + if (!ha->req_q_map) + return; spin_lock_irqsave(&ha->hardware_lock, flags); for (que = 0; que < ha->max_req_queues; que++) { req = ha->req_q_map[que]; @@ -3071,14 +3080,14 @@ qla2x00_probe_one(struct pci_dev *pdev, /* Set up the irqs */ ret = qla2x00_request_irqs(ha, rsp); if (ret) - goto probe_hw_failed; + goto probe_failed; /* Alloc arrays of request and response ring ptrs */ - if (!qla2x00_alloc_queues(ha, req, rsp)) { + if (qla2x00_alloc_queues(ha, req, rsp)) { ql_log(ql_log_fatal, base_vha, 0x003d, "Failed to allocate memory for queue pointers..." "aborting.\n"); - goto probe_init_failed; + goto probe_failed; } if (ha->mqenable && shost_use_blk_mq(host)) { @@ -3363,15 +3372,6 @@ skip_dpc: return 0; -probe_init_failed: - qla2x00_free_req_que(ha, req); - ha->req_q_map[0] = NULL; - clear_bit(0, ha->req_qid_map); - qla2x00_free_rsp_que(ha, rsp); - ha->rsp_q_map[0] = NULL; - clear_bit(0, ha->rsp_qid_map); - ha->max_req_queues = ha->max_rsp_queues = 0; - probe_failed: if (base_vha->timer_active) qla2x00_stop_timer(base_vha); @@ -4451,11 +4451,17 @@ qla2x00_mem_free(struct qla_hw_data *ha) if (ha->init_cb) dma_free_coherent(&ha->pdev->dev, ha->init_cb_size, ha->init_cb, ha->init_cb_dma); - vfree(ha->optrom_buffer); - kfree(ha->nvram); - kfree(ha->npiv_info); - kfree(ha->swl); - kfree(ha->loop_id_map); + + if (ha->optrom_buffer) + vfree(ha->optrom_buffer); + if (ha->nvram) + kfree(ha->nvram); + if (ha->npiv_info) + kfree(ha->npiv_info); + if (ha->swl) + kfree(ha->swl); + if (ha->loop_id_map) + kfree(ha->loop_id_map); ha->srb_mempool = NULL; ha->ctx_mempool = NULL; @@ -4471,6 +4477,15 @@ qla2x00_mem_free(struct qla_hw_data *ha) ha->ex_init_cb_dma = 0; ha->async_pd = NULL; ha->async_pd_dma = 0; + ha->loop_id_map = NULL; + ha->npiv_info = NULL; + ha->optrom_buffer = NULL; + ha->swl = NULL; + ha->nvram = NULL; + ha->mctp_dump = NULL; + ha->dcbx_tlv = NULL; + ha->xgmac_data = NULL; + ha->sfp_data = NULL; ha->s_dma_pool = NULL; ha->dl_dma_pool = NULL; Patches currently in stable-queue which might be from William.Kuzeja(a)stratus.com are queue-4.15/scsi-qla2xxx-fix-crashes-in-qla2x00_probe_one-on-probe-failure.patch

7 years, 1 month

1
0
0 0

Patch "phy: phy-brcm-usb-init: Some Low Speed keyboards fail on 7271" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled phy: phy-brcm-usb-init: Some Low Speed keyboards fail on 7271 to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: phy-phy-brcm-usb-init-some-low-speed-keyboards-fail-on-7271.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 279a0cd0e02aa1e506d9acf94a7ecb530821359c Mon Sep 17 00:00:00 2001 From: Al Cooper <al.cooper(a)broadcom.com> Date: Wed, 27 Dec 2017 14:28:49 -0500 Subject: phy: phy-brcm-usb-init: Some Low Speed keyboards fail on 7271 From: Al Cooper <al.cooper(a)broadcom.com> commit 279a0cd0e02aa1e506d9acf94a7ecb530821359c upstream. Enable the the Low Speed Keep Alive signal on the 7271b0 by setting the LS_KEEP_ALIVE bit in the USB CTRL OBRIDGE register otherwise some Dell Low Speed keyboards fail. Also do a little cleanup of the EBRIDGE ESTOP_SCB_REQ bit. Since this is only used on one platform, remove it from the platform tables and just use "if (family == "). Fixes: 49859e55e364 ("phy: usb: phy-brcm-usb: Add Broadcom STB USB phy driver") Signed-off-by: Al Cooper <alcooperx(a)gmail.com> Acked-by: Florian Fainelli <f.fainelli(a)gmail.com> Signed-off-by: Kishon Vijay Abraham I <kishon(a)ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/phy/broadcom/phy-brcm-usb-init.c | 19 +++++++------------ 1 file changed, 7 insertions(+), 12 deletions(-) --- a/drivers/phy/broadcom/phy-brcm-usb-init.c +++ b/drivers/phy/broadcom/phy-brcm-usb-init.c @@ -50,6 +50,8 @@ #define USB_CTRL_PLL_CTL_PLL_IDDQ_PWRDN_MASK 0x80000000 /* option */ #define USB_CTRL_EBRIDGE 0x0c #define USB_CTRL_EBRIDGE_ESTOP_SCB_REQ_MASK 0x00020000 /* option */ +#define USB_CTRL_OBRIDGE 0x10 +#define USB_CTRL_OBRIDGE_LS_KEEP_ALIVE_MASK 0x08000000 #define USB_CTRL_MDIO 0x14 #define USB_CTRL_MDIO2 0x18 #define USB_CTRL_UTMI_CTL_1 0x2c @@ -116,7 +118,6 @@ enum { USB_CTRL_SETUP_STRAP_IPP_SEL_SELECTOR, USB_CTRL_SETUP_OC3_DISABLE_SELECTOR, USB_CTRL_PLL_CTL_PLL_IDDQ_PWRDN_SELECTOR, - USB_CTRL_EBRIDGE_ESTOP_SCB_REQ_SELECTOR, USB_CTRL_USB_PM_BDC_SOFT_RESETB_SELECTOR, USB_CTRL_USB_PM_XHC_SOFT_RESETB_SELECTOR, USB_CTRL_USB_PM_USB_PWRDN_SELECTOR, @@ -203,7 +204,6 @@ usb_reg_bits_map_table[BRCM_FAMILY_COUNT USB_CTRL_SETUP_STRAP_IPP_SEL_MASK, USB_CTRL_SETUP_OC3_DISABLE_MASK, 0, /* USB_CTRL_PLL_CTL_PLL_IDDQ_PWRDN_MASK */ - USB_CTRL_EBRIDGE_ESTOP_SCB_REQ_MASK, 0, /* USB_CTRL_USB_PM_BDC_SOFT_RESETB_MASK */ USB_CTRL_USB_PM_XHC_SOFT_RESETB_MASK, USB_CTRL_USB_PM_USB_PWRDN_MASK, @@ -225,7 +225,6 @@ usb_reg_bits_map_table[BRCM_FAMILY_COUNT 0, /* USB_CTRL_SETUP_STRAP_IPP_SEL_MASK */ USB_CTRL_SETUP_OC3_DISABLE_MASK, USB_CTRL_PLL_CTL_PLL_IDDQ_PWRDN_MASK, - USB_CTRL_EBRIDGE_ESTOP_SCB_REQ_MASK, 0, /* USB_CTRL_USB_PM_BDC_SOFT_RESETB_MASK */ USB_CTRL_USB_PM_XHC_SOFT_RESETB_VAR_MASK, 0, /* USB_CTRL_USB_PM_USB_PWRDN_MASK */ @@ -247,7 +246,6 @@ usb_reg_bits_map_table[BRCM_FAMILY_COUNT USB_CTRL_SETUP_STRAP_IPP_SEL_MASK, USB_CTRL_SETUP_OC3_DISABLE_MASK, 0, /* USB_CTRL_PLL_CTL_PLL_IDDQ_PWRDN_MASK */ - USB_CTRL_EBRIDGE_ESTOP_SCB_REQ_MASK, USB_CTRL_USB_PM_BDC_SOFT_RESETB_MASK, USB_CTRL_USB_PM_XHC_SOFT_RESETB_MASK, USB_CTRL_USB_PM_USB_PWRDN_MASK, @@ -269,7 +267,6 @@ usb_reg_bits_map_table[BRCM_FAMILY_COUNT 0, /* USB_CTRL_SETUP_STRAP_IPP_SEL_MASK */ USB_CTRL_SETUP_OC3_DISABLE_MASK, USB_CTRL_PLL_CTL_PLL_IDDQ_PWRDN_MASK, - USB_CTRL_EBRIDGE_ESTOP_SCB_REQ_MASK, 0, /* USB_CTRL_USB_PM_BDC_SOFT_RESETB_MASK */ USB_CTRL_USB_PM_XHC_SOFT_RESETB_VAR_MASK, 0, /* USB_CTRL_USB_PM_USB_PWRDN_MASK */ @@ -291,7 +288,6 @@ usb_reg_bits_map_table[BRCM_FAMILY_COUNT 0, /* USB_CTRL_SETUP_STRAP_IPP_SEL_MASK */ USB_CTRL_SETUP_OC3_DISABLE_MASK, 0, /* USB_CTRL_PLL_CTL_PLL_IDDQ_PWRDN_MASK */ - USB_CTRL_EBRIDGE_ESTOP_SCB_REQ_MASK, 0, /* USB_CTRL_USB_PM_BDC_SOFT_RESETB_MASK */ USB_CTRL_USB_PM_XHC_SOFT_RESETB_VAR_MASK, USB_CTRL_USB_PM_USB_PWRDN_MASK, @@ -313,7 +309,6 @@ usb_reg_bits_map_table[BRCM_FAMILY_COUNT 0, /* USB_CTRL_SETUP_STRAP_IPP_SEL_MASK */ 0, /* USB_CTRL_SETUP_OC3_DISABLE_MASK */ USB_CTRL_PLL_CTL_PLL_IDDQ_PWRDN_MASK, - 0, /* USB_CTRL_EBRIDGE_ESTOP_SCB_REQ_MASK */ 0, /* USB_CTRL_USB_PM_BDC_SOFT_RESETB_MASK */ 0, /* USB_CTRL_USB_PM_XHC_SOFT_RESETB_MASK */ 0, /* USB_CTRL_USB_PM_USB_PWRDN_MASK */ @@ -335,7 +330,6 @@ usb_reg_bits_map_table[BRCM_FAMILY_COUNT USB_CTRL_SETUP_STRAP_IPP_SEL_MASK, USB_CTRL_SETUP_OC3_DISABLE_MASK, 0, /* USB_CTRL_PLL_CTL_PLL_IDDQ_PWRDN_MASK */ - 0, /* USB_CTRL_EBRIDGE_ESTOP_SCB_REQ_MASK */ USB_CTRL_USB_PM_BDC_SOFT_RESETB_MASK, USB_CTRL_USB_PM_XHC_SOFT_RESETB_MASK, USB_CTRL_USB_PM_USB_PWRDN_MASK, @@ -357,7 +351,6 @@ usb_reg_bits_map_table[BRCM_FAMILY_COUNT 0, /* USB_CTRL_SETUP_STRAP_IPP_SEL_MASK */ USB_CTRL_SETUP_OC3_DISABLE_MASK, USB_CTRL_PLL_CTL_PLL_IDDQ_PWRDN_MASK, - 0, /* USB_CTRL_EBRIDGE_ESTOP_SCB_REQ_MASK */ 0, /* USB_CTRL_USB_PM_BDC_SOFT_RESETB_MASK */ 0, /* USB_CTRL_USB_PM_XHC_SOFT_RESETB_MASK */ 0, /* USB_CTRL_USB_PM_USB_PWRDN_MASK */ @@ -379,7 +372,6 @@ usb_reg_bits_map_table[BRCM_FAMILY_COUNT USB_CTRL_SETUP_STRAP_IPP_SEL_MASK, USB_CTRL_SETUP_OC3_DISABLE_MASK, 0, /* USB_CTRL_PLL_CTL_PLL_IDDQ_PWRDN_MASK */ - USB_CTRL_EBRIDGE_ESTOP_SCB_REQ_MASK, USB_CTRL_USB_PM_BDC_SOFT_RESETB_MASK, USB_CTRL_USB_PM_XHC_SOFT_RESETB_MASK, USB_CTRL_USB_PM_USB_PWRDN_MASK, @@ -401,7 +393,6 @@ usb_reg_bits_map_table[BRCM_FAMILY_COUNT USB_CTRL_SETUP_STRAP_IPP_SEL_MASK, USB_CTRL_SETUP_OC3_DISABLE_MASK, 0, /* USB_CTRL_PLL_CTL_PLL_IDDQ_PWRDN_MASK */ - USB_CTRL_EBRIDGE_ESTOP_SCB_REQ_MASK, USB_CTRL_USB_PM_BDC_SOFT_RESETB_MASK, USB_CTRL_USB_PM_XHC_SOFT_RESETB_MASK, USB_CTRL_USB_PM_USB_PWRDN_MASK, @@ -952,13 +943,17 @@ void brcm_usb_init_eohci(struct brcm_usb * Don't enable this so the memory controller doesn't read * into memory holes. NOTE: This bit is low true on 7366C0. */ - USB_CTRL_SET_FAMILY(params, EBRIDGE, ESTOP_SCB_REQ); + USB_CTRL_SET(ctrl, EBRIDGE, ESTOP_SCB_REQ); /* Setup the endian bits */ reg = brcmusb_readl(USB_CTRL_REG(ctrl, SETUP)); reg &= ~USB_CTRL_SETUP_ENDIAN_BITS; reg |= USB_CTRL_MASK_FAMILY(params, SETUP, ENDIAN); brcmusb_writel(reg, USB_CTRL_REG(ctrl, SETUP)); + + if (params->selected_family == BRCM_FAMILY_7271A0) + /* Enable LS keep alive fix for certain keyboards */ + USB_CTRL_SET(ctrl, OBRIDGE, LS_KEEP_ALIVE); } void brcm_usb_init_xhci(struct brcm_usb_init_params *params) Patches currently in stable-queue which might be from al.cooper(a)broadcom.com are queue-4.15/phy-phy-brcm-usb-init-power-down-usb-3.0-phy-when-xhci-disabled.patch queue-4.15/phy-phy-brcm-usb-init-drd-mode-can-cause-crash-on-startup.patch queue-4.15/phy-phy-brcm-usb-init-some-low-speed-keyboards-fail-on-7271.patch

7 years, 1 month

1
0
0 0

Patch "phy: phy-brcm-usb-init: Power down USB 3.0 PHY when XHCI disabled" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled phy: phy-brcm-usb-init: Power down USB 3.0 PHY when XHCI disabled to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: phy-phy-brcm-usb-init-power-down-usb-3.0-phy-when-xhci-disabled.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From cd6f769fdea7ff7d77a6cc97658c60ca0b836d0e Mon Sep 17 00:00:00 2001 From: Al Cooper <al.cooper(a)broadcom.com> Date: Wed, 27 Dec 2017 14:28:50 -0500 Subject: phy: phy-brcm-usb-init: Power down USB 3.0 PHY when XHCI disabled From: Al Cooper <al.cooper(a)broadcom.com> commit cd6f769fdea7ff7d77a6cc97658c60ca0b836d0e upstream. Set PHY3_IDDQ_OVERRIDE in the xhci uninit routine. This will save additional power when the XHCI driver is not enabled. Fixes: 49859e55e364 ("phy: usb: phy-brcm-usb: Add Broadcom STB USB phy driver") Signed-off-by: Al Cooper <alcooperx(a)gmail.com> Acked-by: Florian Fainelli <f.fainelli(a)gmail.com> Signed-off-by: Kishon Vijay Abraham I <kishon(a)ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/phy/broadcom/phy-brcm-usb-init.c | 2 ++ 1 file changed, 2 insertions(+) --- a/drivers/phy/broadcom/phy-brcm-usb-init.c +++ b/drivers/phy/broadcom/phy-brcm-usb-init.c @@ -73,6 +73,7 @@ #define USB_CTRL_USB30_CTL1_USB3_IPP_MASK 0x20000000 /* option */ #define USB_CTRL_USB30_PCTL 0x70 #define USB_CTRL_USB30_PCTL_PHY3_SOFT_RESETB_MASK 0x00000002 +#define USB_CTRL_USB30_PCTL_PHY3_IDDQ_OVERRIDE_MASK 0x00008000 #define USB_CTRL_USB30_PCTL_PHY3_SOFT_RESETB_P1_MASK 0x00020000 #define USB_CTRL_USB_DEVICE_CTL1 0x90 #define USB_CTRL_USB_DEVICE_CTL1_PORT_MODE_MASK 0x00000003 /* option */ @@ -999,6 +1000,7 @@ void brcm_usb_uninit_eohci(struct brcm_u void brcm_usb_uninit_xhci(struct brcm_usb_init_params *params) { brcmusb_xhci_soft_reset(params, 1); + USB_CTRL_SET(params->ctrl_regs, USB30_PCTL, PHY3_IDDQ_OVERRIDE); } void brcm_usb_set_family_map(struct brcm_usb_init_params *params) Patches currently in stable-queue which might be from al.cooper(a)broadcom.com are queue-4.15/phy-phy-brcm-usb-init-power-down-usb-3.0-phy-when-xhci-disabled.patch queue-4.15/phy-phy-brcm-usb-init-drd-mode-can-cause-crash-on-startup.patch queue-4.15/phy-phy-brcm-usb-init-some-low-speed-keyboards-fail-on-7271.patch

7 years, 1 month

1
0
0 0

Patch "phy: phy-brcm-usb-init: DRD mode can cause crash on startup" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled phy: phy-brcm-usb-init: DRD mode can cause crash on startup to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: phy-phy-brcm-usb-init-drd-mode-can-cause-crash-on-startup.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 0aa0c12262fd848c48448c39ff6c1c097be00dd4 Mon Sep 17 00:00:00 2001 From: Al Cooper <al.cooper(a)broadcom.com> Date: Wed, 27 Dec 2017 14:28:51 -0500 Subject: phy: phy-brcm-usb-init: DRD mode can cause crash on startup From: Al Cooper <al.cooper(a)broadcom.com> commit 0aa0c12262fd848c48448c39ff6c1c097be00dd4 upstream. This is caused by a bug in the BDC core. When the BDC core comes out of reset and it's not selected, it gets a backup clock. When the BDC core is selected, it get's the main clock. If HOST mode is then selected the BDC core has the main clock shut off but the backup clock is not restored. The failure scenario and cause are as follows: - DRD mode is active - Device mode is selected first in bootloader - When host mode is now selected, the clock to the BDC is cut off. - BDC registers are inaccessible and therefore the BDC driver crashes upon Linux boot. The fix is to have the phy driver always force a BDC reset on startup. Fixes: 49859e55e364 ("phy: usb: phy-brcm-usb: Add Broadcom STB USB phy driver") Signed-off-by: Al Cooper <alcooperx(a)gmail.com> Acked-by: Florian Fainelli <f.fainelli(a)gmail.com> Signed-off-by: Kishon Vijay Abraham I <kishon(a)ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/phy/broadcom/phy-brcm-usb-init.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/phy/broadcom/phy-brcm-usb-init.c +++ b/drivers/phy/broadcom/phy-brcm-usb-init.c @@ -917,6 +917,7 @@ void brcm_usb_init_common(struct brcm_us USB_CTRL_UNSET_FAMILY(params, USB_PM, BDC_SOFT_RESETB); break; default: + USB_CTRL_UNSET_FAMILY(params, USB_PM, BDC_SOFT_RESETB); USB_CTRL_SET_FAMILY(params, USB_PM, BDC_SOFT_RESETB); break; } Patches currently in stable-queue which might be from al.cooper(a)broadcom.com are queue-4.15/phy-phy-brcm-usb-init-power-down-usb-3.0-phy-when-xhci-disabled.patch queue-4.15/phy-phy-brcm-usb-init-drd-mode-can-cause-crash-on-startup.patch queue-4.15/phy-phy-brcm-usb-init-some-low-speed-keyboards-fail-on-7271.patch

7 years, 1 month

1
0
0 0

Patch "phy: phy-brcm-usb: Fix two DT properties to match bindings doc" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled phy: phy-brcm-usb: Fix two DT properties to match bindings doc to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: phy-phy-brcm-usb-fix-two-dt-properties-to-match-bindings-doc.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 5e498ff117c19fd80181b5bb09ecb024b552ece8 Mon Sep 17 00:00:00 2001 From: Al Cooper <alcooperx(a)gmail.com> Date: Wed, 27 Dec 2017 14:28:48 -0500 Subject: phy: phy-brcm-usb: Fix two DT properties to match bindings doc From: Al Cooper <alcooperx(a)gmail.com> commit 5e498ff117c19fd80181b5bb09ecb024b552ece8 upstream. Change "brcm,has_xhci" and "brcm,has_eohci" device tree properties to the preferred "brcm,has-xhci" and "brcm,has-eohci". This also matches the existing device tree bindings document. Fixes: 49859e55e364 ("phy: usb: phy-brcm-usb: Add Broadcom STB USB phy driver") Signed-off-by: Al Cooper <alcooperx(a)gmail.com> Acked-by: Florian Fainelli <f.fainelli(a)gmail.com> Signed-off-by: Kishon Vijay Abraham I <kishon(a)ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/phy/broadcom/phy-brcm-usb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/phy/broadcom/phy-brcm-usb.c +++ b/drivers/phy/broadcom/phy-brcm-usb.c @@ -338,9 +338,9 @@ static int brcm_usb_phy_probe(struct pla ARRAY_SIZE(brcm_dr_mode_to_name), mode, &priv->ini.mode); } - if (of_property_read_bool(dn, "brcm,has_xhci")) + if (of_property_read_bool(dn, "brcm,has-xhci")) priv->has_xhci = true; - if (of_property_read_bool(dn, "brcm,has_eohci")) + if (of_property_read_bool(dn, "brcm,has-eohci")) priv->has_eohci = true; err = brcm_usb_phy_dvr_init(dev, priv, dn); Patches currently in stable-queue which might be from alcooperx(a)gmail.com are queue-4.15/phy-phy-brcm-usb-fix-two-dt-properties-to-match-bindings-doc.patch queue-4.15/phy-phy-brcm-usb-init-power-down-usb-3.0-phy-when-xhci-disabled.patch queue-4.15/phy-phy-brcm-usb-init-drd-mode-can-cause-crash-on-startup.patch queue-4.15/phy-phy-brcm-usb-init-some-low-speed-keyboards-fail-on-7271.patch

7 years, 1 month

1
0
0 0

Patch "dt-bindings: usb: fix the STM32F7 DWC2 OTG HS core binding" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled dt-bindings: usb: fix the STM32F7 DWC2 OTG HS core binding to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: dt-bindings-usb-fix-the-stm32f7-dwc2-otg-hs-core-binding.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 4c437920fa216f66f6a5d469cae2a0360cc2d9c7 Mon Sep 17 00:00:00 2001 From: Amelie Delaunay <amelie.delaunay(a)st.com> Date: Thu, 1 Mar 2018 11:05:34 +0100 Subject: dt-bindings: usb: fix the STM32F7 DWC2 OTG HS core binding From: Amelie Delaunay <amelie.delaunay(a)st.com> commit 4c437920fa216f66f6a5d469cae2a0360cc2d9c7 upstream. This patch fixes binding documentation for DWC2 controller in HS mode found on STMicroelectronics STM32F7 SoC. The v2 former patch [1] had been acked by Rob Herring, but v1 was merged. [1] https://patchwork.kernel.org/patch/9925575/ Fixes: 000777dadc7e ("dt-bindings: usb: Document the STM32F7xx DWC2 ...") Signed-off-by: Amelie Delaunay <amelie.delaunay(a)st.com> Reviewed-by: Rob Herring <robh(a)kernel.org> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- Documentation/devicetree/bindings/usb/dwc2.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/Documentation/devicetree/bindings/usb/dwc2.txt +++ b/Documentation/devicetree/bindings/usb/dwc2.txt @@ -19,7 +19,7 @@ Required properties: configured in FS mode; - "st,stm32f4x9-hsotg": The DWC2 USB HS controller instance in STM32F4x9 SoCs configured in HS mode; - - "st,stm32f7xx-hsotg": The DWC2 USB HS controller instance in STM32F7xx SoCs + - "st,stm32f7-hsotg": The DWC2 USB HS controller instance in STM32F7 SoCs configured in HS mode; - reg : Should contain 1 register range (address and length) - interrupts : Should contain 1 interrupt Patches currently in stable-queue which might be from amelie.delaunay(a)st.com are queue-4.15/usb-dwc2-fix-stm32f7-usb-otg-hs-compatible.patch queue-4.15/dt-bindings-usb-fix-the-stm32f7-dwc2-otg-hs-core-binding.patch

7 years, 1 month

1
0
0 0

Patch "USB: gadget: udc: Add missing platform_device_put() on error in bdc_pci_probe()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled USB: gadget: udc: Add missing platform_device_put() on error in bdc_pci_probe() to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-gadget-udc-add-missing-platform_device_put-on-error-in-bdc_pci_probe.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 8874ae5f15f3feef3b4a415b9aed51edcf449aa1 Mon Sep 17 00:00:00 2001 From: Wei Yongjun <weiyongjun1(a)huawei.com> Date: Tue, 23 Jan 2018 09:35:14 +0000 Subject: USB: gadget: udc: Add missing platform_device_put() on error in bdc_pci_probe() From: Wei Yongjun <weiyongjun1(a)huawei.com> commit 8874ae5f15f3feef3b4a415b9aed51edcf449aa1 upstream. Add the missing platform_device_put() before return from bdc_pci_probe() in the platform_device_add_resources() error handling case. Fixes: efed421a94e6 ("usb: gadget: Add UDC driver for Broadcom USB3.0 device controller IP BDC") Signed-off-by: Wei Yongjun <weiyongjun1(a)huawei.com> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/gadget/udc/bdc/bdc_pci.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/usb/gadget/udc/bdc/bdc_pci.c +++ b/drivers/usb/gadget/udc/bdc/bdc_pci.c @@ -82,6 +82,7 @@ static int bdc_pci_probe(struct pci_dev if (ret) { dev_err(&pci->dev, "couldn't add resources to bdc device\n"); + platform_device_put(bdc); return ret; } Patches currently in stable-queue which might be from weiyongjun1(a)huawei.com are queue-4.14/usb-gadget-udc-add-missing-platform_device_put-on-error-in-bdc_pci_probe.patch

7 years, 1 month

1
0
0 0

Patch "scsi: qla2xxx: Fix smatch warning in qla25xx_delete_{rsp|req}_que" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: qla2xxx: Fix smatch warning in qla25xx_delete_{rsp|req}_que to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-qla2xxx-fix-smatch-warning-in-qla25xx_delete_-rsp-req-_que.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 62aa281470fdb7c0796d63a1cc918a8c1f02dde2 Mon Sep 17 00:00:00 2001 From: Himanshu Madhani <himanshu.madhani(a)cavium.com> Date: Sat, 16 Dec 2017 16:05:09 -0800 Subject: scsi: qla2xxx: Fix smatch warning in qla25xx_delete_{rsp|req}_que From: Himanshu Madhani <himanshu.madhani(a)cavium.com> commit 62aa281470fdb7c0796d63a1cc918a8c1f02dde2 upstream. This patch fixes following warnings reported by smatch: drivers/scsi/qla2xxx/qla_mid.c:586 qla25xx_delete_req_que() error: we previously assumed 'req' could be null (see line 580) drivers/scsi/qla2xxx/qla_mid.c:602 qla25xx_delete_rsp_que() error: we previously assumed 'rsp' could be null (see line 596) Fixes: 7867b98dceb7 ("scsi: qla2xxx: Fix memory leak in dual/target mode") Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com> Signed-off-by: Himanshu Madhani <himanshu.madhani(a)cavium.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/qla2xxx/qla_mid.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/drivers/scsi/qla2xxx/qla_mid.c +++ b/drivers/scsi/qla2xxx/qla_mid.c @@ -582,8 +582,9 @@ qla25xx_delete_req_que(struct scsi_qla_h ret = qla25xx_init_req_que(vha, req); if (ret != QLA_SUCCESS) return QLA_FUNCTION_FAILED; + + qla25xx_free_req_que(vha, req); } - qla25xx_free_req_que(vha, req); return ret; } @@ -598,8 +599,9 @@ qla25xx_delete_rsp_que(struct scsi_qla_h ret = qla25xx_init_rsp_que(vha, rsp); if (ret != QLA_SUCCESS) return QLA_FUNCTION_FAILED; + + qla25xx_free_rsp_que(vha, rsp); } - qla25xx_free_rsp_que(vha, rsp); return ret; } Patches currently in stable-queue which might be from himanshu.madhani(a)cavium.com are queue-4.14/scsi-qla2xxx-fix-smatch-warning-in-qla25xx_delete_-rsp-req-_que.patch queue-4.14/scsi-qla2xxx-fix-crashes-in-qla2x00_probe_one-on-probe-failure.patch queue-4.14/scsi-qla2xxx-fix-null-pointer-access-for-fcport-structure.patch

7 years, 1 month

1
0
0 0

Patch "usb: dwc3: Fix GDBGFIFOSPACE_TYPE values" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled usb: dwc3: Fix GDBGFIFOSPACE_TYPE values to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: usb-dwc3-fix-gdbgfifospace_type-values.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From b16ea8b9492e99e03b1269fe93ebdbf8e4eabf8a Mon Sep 17 00:00:00 2001 From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> Date: Fri, 2 Feb 2018 13:21:35 -0800 Subject: usb: dwc3: Fix GDBGFIFOSPACE_TYPE values From: Thinh Nguyen <Thinh.Nguyen(a)synopsys.com> commit b16ea8b9492e99e03b1269fe93ebdbf8e4eabf8a upstream. The FIFO/Queue type values are incorrect. Correct them according to DWC_usb3 programming guide section 1.2.27 (or DWC_usb31 section 1.2.25). Additionally, this patch includes ProtocolStatusQ and AuxEventQ types. Fixes: cf6d867d3b57 ("usb: dwc3: core: add fifo space helper") Signed-off-by: Thinh Nguyen <thinhn(a)synopsys.com> Signed-off-by: Felipe Balbi <felipe.balbi(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/dwc3/core.h | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) --- a/drivers/usb/dwc3/core.h +++ b/drivers/usb/dwc3/core.h @@ -166,13 +166,15 @@ #define DWC3_GDBGFIFOSPACE_TYPE(n) (((n) << 5) & 0x1e0) #define DWC3_GDBGFIFOSPACE_SPACE_AVAILABLE(n) (((n) >> 16) & 0xffff) -#define DWC3_TXFIFOQ 1 -#define DWC3_RXFIFOQ 3 -#define DWC3_TXREQQ 5 -#define DWC3_RXREQQ 7 -#define DWC3_RXINFOQ 9 -#define DWC3_DESCFETCHQ 13 -#define DWC3_EVENTQ 15 +#define DWC3_TXFIFOQ 0 +#define DWC3_RXFIFOQ 1 +#define DWC3_TXREQQ 2 +#define DWC3_RXREQQ 3 +#define DWC3_RXINFOQ 4 +#define DWC3_PSTATQ 5 +#define DWC3_DESCFETCHQ 6 +#define DWC3_EVENTQ 7 +#define DWC3_AUXEVENTQ 8 /* Global RX Threshold Configuration Register */ #define DWC3_GRXTHRCFG_MAXRXBURSTSIZE(n) (((n) & 0x1f) << 19) Patches currently in stable-queue which might be from Thinh.Nguyen(a)synopsys.com are queue-4.14/usb-dwc3-fix-gdbgfifospace_type-values.patch

7 years, 1 month

1
0
0 0

Patch "scsi: qla2xxx: Fix NULL pointer access for fcport structure" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: qla2xxx: Fix NULL pointer access for fcport structure to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-qla2xxx-fix-null-pointer-access-for-fcport-structure.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 5c25d451163cab9be80744cbc5448d6b95ab8d1a Mon Sep 17 00:00:00 2001 From: Quinn Tran <quinn.tran(a)cavium.com> Date: Thu, 28 Dec 2017 12:33:09 -0800 Subject: scsi: qla2xxx: Fix NULL pointer access for fcport structure From: Quinn Tran <quinn.tran(a)cavium.com> commit 5c25d451163cab9be80744cbc5448d6b95ab8d1a upstream. when processing iocb in a timeout case, driver was trying to log messages without verifying if the fcport structure could have valid data. This results in a NULL pointer access. Fixes: 726b85487067("qla2xxx: Add framework for async fabric discovery") Signed-off-by: Quinn Tran <quinn.tran(a)cavium.com> Signed-off-by: Himanshu Madhani <himanshu.madhani(a)cavium.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/qla2xxx/qla_init.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) --- a/drivers/scsi/qla2xxx/qla_init.c +++ b/drivers/scsi/qla2xxx/qla_init.c @@ -102,11 +102,16 @@ qla2x00_async_iocb_timeout(void *data) struct srb_iocb *lio = &sp->u.iocb_cmd; struct event_arg ea; - ql_dbg(ql_dbg_disc, fcport->vha, 0x2071, - "Async-%s timeout - hdl=%x portid=%06x %8phC.\n", - sp->name, sp->handle, fcport->d_id.b24, fcport->port_name); + if (fcport) { + ql_dbg(ql_dbg_disc, fcport->vha, 0x2071, + "Async-%s timeout - hdl=%x portid=%06x %8phC.\n", + sp->name, sp->handle, fcport->d_id.b24, fcport->port_name); - fcport->flags &= ~FCF_ASYNC_SENT; + fcport->flags &= ~FCF_ASYNC_SENT; + } else { + pr_info("Async-%s timeout - hdl=%x.\n", + sp->name, sp->handle); + } switch (sp->type) { case SRB_LOGIN_CMD: Patches currently in stable-queue which might be from quinn.tran(a)cavium.com are queue-4.14/scsi-qla2xxx-fix-null-pointer-access-for-fcport-structure.patch

7 years, 1 month

1
0
0 0

Patch "scsi: qla2xxx: Fix logo flag for qlt_free_session_done()" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: qla2xxx: Fix logo flag for qlt_free_session_done() to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-qla2xxx-fix-logo-flag-for-qlt_free_session_done.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From a2390348c19d0819d525d375414a7cfdacb51a68 Mon Sep 17 00:00:00 2001 From: Himanshu Madhani <hmadhani(a)redhat.com> Date: Mon, 22 Jan 2018 12:04:20 -0800 Subject: scsi: qla2xxx: Fix logo flag for qlt_free_session_done() From: Himanshu Madhani <hmadhani(a)redhat.com> commit a2390348c19d0819d525d375414a7cfdacb51a68 upstream. Commit 3515832cc614 ("scsi: qla2xxx: Reset the logo flag, after target re-login.")fixed the target re-login after session relogin is complete, but missed out the qlt_free_session_done() path. This patch clears send_els_logo flag in qlt_free_session_done() callback. [mkp: checkpatch] Fixes: 3515832cc614 ("scsi: qla2xxx: Reset the logo flag, after target re-login.") Signed-off-by: Himanshu Madhani <hmadhani(a)redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/qla2xxx/qla_target.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/scsi/qla2xxx/qla_target.c +++ b/drivers/scsi/qla2xxx/qla_target.c @@ -971,6 +971,7 @@ static void qlt_free_session_done(struct logo.id = sess->d_id; logo.cmd_count = 0; + sess->send_els_logo = 0; qlt_send_first_logo(vha, &logo); } Patches currently in stable-queue which might be from hmadhani(a)redhat.com are queue-4.14/scsi-qla2xxx-fix-logo-flag-for-qlt_free_session_done.patch

7 years, 1 month

1
0
0 0

Patch "scsi: qla2xxx: Fix crashes in qla2x00_probe_one on probe failure" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: qla2xxx: Fix crashes in qla2x00_probe_one on probe failure to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-qla2xxx-fix-crashes-in-qla2x00_probe_one-on-probe-failure.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 6a2cf8d3663e13e19af636c2a8d92e766261dc45 Mon Sep 17 00:00:00 2001 From: Bill Kuzeja <William.Kuzeja(a)stratus.com> Date: Mon, 5 Mar 2018 00:02:55 -0500 Subject: scsi: qla2xxx: Fix crashes in qla2x00_probe_one on probe failure From: Bill Kuzeja <William.Kuzeja(a)stratus.com> commit 6a2cf8d3663e13e19af636c2a8d92e766261dc45 upstream. Because of the shifting around of code in qla2x00_probe_one recently, failures during adapter initialization can lead to problems, i.e. NULL pointer crashes and doubly freed data structures which cause eventual panics. This V2 version makes the relevant memory free routines idempotent, so repeat calls won't cause any harm. I also removed the problematic probe_init_failed exit point as it is not needed. Fixes: d64d6c5671db ("scsi: qla2xxx: Fix NULL pointer crash due to probe failure") Signed-off-by: Bill Kuzeja <william.kuzeja(a)stratus.com> Acked-by: Himanshu Madhani <himanshu.madhani(a)cavium.com> Reviewed-by: Hannes Reinecke <hare(a)suse.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/qla2xxx/qla_os.c | 59 ++++++++++++++++++++++++++---------------- 1 file changed, 37 insertions(+), 22 deletions(-) --- a/drivers/scsi/qla2xxx/qla_os.c +++ b/drivers/scsi/qla2xxx/qla_os.c @@ -442,7 +442,7 @@ static int qla2x00_alloc_queues(struct q ha->req_q_map[0] = req; set_bit(0, ha->rsp_qid_map); set_bit(0, ha->req_qid_map); - return 1; + return 0; fail_qpair_map: kfree(ha->base_qpair); @@ -459,6 +459,9 @@ fail_req_map: static void qla2x00_free_req_que(struct qla_hw_data *ha, struct req_que *req) { + if (!ha->req_q_map) + return; + if (IS_QLAFX00(ha)) { if (req && req->ring_fx00) dma_free_coherent(&ha->pdev->dev, @@ -469,14 +472,17 @@ static void qla2x00_free_req_que(struct (req->length + 1) * sizeof(request_t), req->ring, req->dma); - if (req) + if (req) { kfree(req->outstanding_cmds); - - kfree(req); + kfree(req); + } } static void qla2x00_free_rsp_que(struct qla_hw_data *ha, struct rsp_que *rsp) { + if (!ha->rsp_q_map) + return; + if (IS_QLAFX00(ha)) { if (rsp && rsp->ring) dma_free_coherent(&ha->pdev->dev, @@ -487,7 +493,8 @@ static void qla2x00_free_rsp_que(struct (rsp->length + 1) * sizeof(response_t), rsp->ring, rsp->dma); } - kfree(rsp); + if (rsp) + kfree(rsp); } static void qla2x00_free_queues(struct qla_hw_data *ha) @@ -1710,6 +1717,8 @@ qla2x00_abort_all_cmds(scsi_qla_host_t * struct qla_tgt_cmd *cmd; uint8_t trace = 0; + if (!ha->req_q_map) + return; spin_lock_irqsave(&ha->hardware_lock, flags); for (que = 0; que < ha->max_req_queues; que++) { req = ha->req_q_map[que]; @@ -3063,14 +3072,14 @@ qla2x00_probe_one(struct pci_dev *pdev, /* Set up the irqs */ ret = qla2x00_request_irqs(ha, rsp); if (ret) - goto probe_hw_failed; + goto probe_failed; /* Alloc arrays of request and response ring ptrs */ - if (!qla2x00_alloc_queues(ha, req, rsp)) { + if (qla2x00_alloc_queues(ha, req, rsp)) { ql_log(ql_log_fatal, base_vha, 0x003d, "Failed to allocate memory for queue pointers..." "aborting.\n"); - goto probe_init_failed; + goto probe_failed; } if (ha->mqenable && shost_use_blk_mq(host)) { @@ -3347,15 +3356,6 @@ skip_dpc: return 0; -probe_init_failed: - qla2x00_free_req_que(ha, req); - ha->req_q_map[0] = NULL; - clear_bit(0, ha->req_qid_map); - qla2x00_free_rsp_que(ha, rsp); - ha->rsp_q_map[0] = NULL; - clear_bit(0, ha->rsp_qid_map); - ha->max_req_queues = ha->max_rsp_queues = 0; - probe_failed: if (base_vha->timer_active) qla2x00_stop_timer(base_vha); @@ -4435,11 +4435,17 @@ qla2x00_mem_free(struct qla_hw_data *ha) if (ha->init_cb) dma_free_coherent(&ha->pdev->dev, ha->init_cb_size, ha->init_cb, ha->init_cb_dma); - vfree(ha->optrom_buffer); - kfree(ha->nvram); - kfree(ha->npiv_info); - kfree(ha->swl); - kfree(ha->loop_id_map); + + if (ha->optrom_buffer) + vfree(ha->optrom_buffer); + if (ha->nvram) + kfree(ha->nvram); + if (ha->npiv_info) + kfree(ha->npiv_info); + if (ha->swl) + kfree(ha->swl); + if (ha->loop_id_map) + kfree(ha->loop_id_map); ha->srb_mempool = NULL; ha->ctx_mempool = NULL; @@ -4455,6 +4461,15 @@ qla2x00_mem_free(struct qla_hw_data *ha) ha->ex_init_cb_dma = 0; ha->async_pd = NULL; ha->async_pd_dma = 0; + ha->loop_id_map = NULL; + ha->npiv_info = NULL; + ha->optrom_buffer = NULL; + ha->swl = NULL; + ha->nvram = NULL; + ha->mctp_dump = NULL; + ha->dcbx_tlv = NULL; + ha->xgmac_data = NULL; + ha->sfp_data = NULL; ha->s_dma_pool = NULL; ha->dl_dma_pool = NULL; Patches currently in stable-queue which might be from William.Kuzeja(a)stratus.com are queue-4.14/scsi-qla2xxx-fix-crashes-in-qla2x00_probe_one-on-probe-failure.patch

7 years, 1 month

1
0
0 0

Re: NULL pointer dereferences with 4.14.27

by Holger Hoffstätte

(CC: davem, soheil & gregkh) On 03/17/18 20:12, Holger Hoffstätte wrote: > On 03/17/18 19:41, Carlos Carvalho wrote: >> I've put 4.14.27 this morning in this machine and in about 2h it started >> showing null dereferences identical to the following one. There were several of >> them, with about 1/2h of interval. Strangely it continued to work and I saw no >> other anomalies. I've just reverted to 4.14.26. >> >> It only happened in this machine, which has a net traffic of several Gb/s and >> thousands of simultaneous connections. >> >> Mar 17 13:29:21 sagres kernel: : BUG: unable to handle kernel NULL pointer dereference at 0000000000000038 >> Mar 17 13:29:21 sagres kernel: : IP: tcp_push+0x4e/0xe7 >> Mar 17 13:29:21 sagres kernel: : PGD 0 P4D 0 >> Mar 17 13:29:21 sagres kernel: : Oops: 0002 [#1] SMP PTI >> Mar 17 13:29:21 sagres kernel: : CPU: 55 PID: 2658 Comm: apache2 Not tainted 4.14.27 #4 (snip) > > Fixed by: https://www.spinics.net/lists/netdev/msg489445.html > > -h > This patch is in the netdev patchwork at https://patchwork.ozlabs.org/patch/886324/ but has been marked as "not applicable" without further queued/rejected comment from Dave, so I believe it became a victim of email lossage. As the patch says it doesn't apply to anything older than 4.14, but it has been tested & reported by several people as fixing the problem, and indeed works fine. Since GregKH only accepts net patches from Dave I wanted to make sure it got queued up for 4.14. Thanks, Holger

7 years, 1 month

2
1
0 0

[Linux-stable-mirror] [PATCH 1/4] clk: bcm2835: Fix ana->maskX definitions

by Boris Brezillon

ana->maskX values are already '~'-ed in bcm2835_pll_set_rate(). Remove the '~' in the definition to fix ANA setup. Note that this commit fixes a long standing bug preventing one from using an HDMI display if it's plugged after the FW has booted Linux. This is because PLLH is used by the HDMI encoder to generate the pixel clock. Fixes: 41691b8862e2 ("clk: bcm2835: Add support for programming the audio domain clocks") Cc: <stable(a)vger.kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon(a)bootlin.com> Reviewed-by: Eric Anholt <eric(a)anholt.net> --- drivers/clk/bcm/clk-bcm2835.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c index 44301a3d9963..2108a274185a 100644 --- a/drivers/clk/bcm/clk-bcm2835.c +++ b/drivers/clk/bcm/clk-bcm2835.c @@ -449,17 +449,17 @@ struct bcm2835_pll_ana_bits { static const struct bcm2835_pll_ana_bits bcm2835_ana_default = { .mask0 = 0, .set0 = 0, - .mask1 = (u32)~(A2W_PLL_KI_MASK | A2W_PLL_KP_MASK), + .mask1 = A2W_PLL_KI_MASK | A2W_PLL_KP_MASK, .set1 = (2 << A2W_PLL_KI_SHIFT) | (8 << A2W_PLL_KP_SHIFT), - .mask3 = (u32)~A2W_PLL_KA_MASK, + .mask3 = A2W_PLL_KA_MASK, .set3 = (2 << A2W_PLL_KA_SHIFT), .fb_prediv_mask = BIT(14), }; static const struct bcm2835_pll_ana_bits bcm2835_ana_pllh = { - .mask0 = (u32)~(A2W_PLLH_KA_MASK | A2W_PLLH_KI_LOW_MASK), + .mask0 = A2W_PLLH_KA_MASK | A2W_PLLH_KI_LOW_MASK, .set0 = (2 << A2W_PLLH_KA_SHIFT) | (2 << A2W_PLLH_KI_LOW_SHIFT), - .mask1 = (u32)~(A2W_PLLH_KI_HIGH_MASK | A2W_PLLH_KP_MASK), + .mask1 = A2W_PLLH_KI_HIGH_MASK | A2W_PLLH_KP_MASK, .set1 = (6 << A2W_PLLH_KP_SHIFT), .mask3 = 0, .set3 = 0, -- 2.14.1

7 years, 1 month

2
5
0 0

Re: [PATCH 4/4] clk: bcm2835: Make sure the PLL is gated before changing its rate

by Stephen Boyd

Quoting Eric Anholt (2018-03-13 09:56:57) > Stephen Boyd <sboyd(a)kernel.org> writes: > > > > What exactly is going on here? It sounds like the framework isn't aware > > of the 'on/off' boot state of certain clks (a known problem) and that's > > causing some sort of problem when changing rates? This usually happens > > with PLLs that are enabled at boot time and can't support their rate > > changing when they're enabled. We really should start reading on/off > > state and "hand off" that enabled state to something in the framework so > > we at least know if a clk is enabled or not out of boot. There was some > > work on clk handoff done a while ago by Mike that never landed which may > > be useful to finish this off. Maybe we can pass that enabled state off > > to the clk we always create for a clk_hw structure at registration time > > and then have clk_disable_unused operate on that clk pointer at late > > init. > > Yes, the usual problem of clk not handling boot-time clock state well. > > That said, it's patch 1 that's critical for fixing many of our users, > and we need that in as soon as possible. #2 is also reviewed and ready. Got it. I'll pick up the first two then.

7 years, 1 month

1
0
0 0

Patch "btrfs: Fix use-after-free when cleaning up fs_devs with a single stale device" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled btrfs: Fix use-after-free when cleaning up fs_devs with a single stale device to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-use-after-free-when-cleaning-up-fs_devs-with-a-single-stale-device.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From fd649f10c3d21ee9d7542c609f29978bdf73ab94 Mon Sep 17 00:00:00 2001 From: Nikolay Borisov <nborisov(a)suse.com> Date: Tue, 30 Jan 2018 16:07:37 +0200 Subject: btrfs: Fix use-after-free when cleaning up fs_devs with a single stale device From: Nikolay Borisov <nborisov(a)suse.com> commit fd649f10c3d21ee9d7542c609f29978bdf73ab94 upstream. Commit 4fde46f0cc71 ("Btrfs: free the stale device") introduced btrfs_free_stale_device which iterates the device lists for all registered btrfs filesystems and deletes those devices which aren't mounted. In a btrfs_devices structure has only 1 device attached to it and it is unused then btrfs_free_stale_devices will proceed to also free the btrfs_fs_devices struct itself. Currently this leads to a use after free since list_for_each_entry will try to perform a check on the already freed memory to see if it has to terminate the loop. The fix is to use 'break' when we know we are freeing the current fs_devs. Fixes: 4fde46f0cc71 ("Btrfs: free the stale device") Signed-off-by: Nikolay Borisov <nborisov(a)suse.com> Reviewed-by: Anand Jain <anand.jain(a)oracle.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/volumes.c | 1 + 1 file changed, 1 insertion(+) --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -583,6 +583,7 @@ void btrfs_free_stale_device(struct btrf btrfs_sysfs_remove_fsid(fs_devs); list_del(&fs_devs->list); free_fs_devices(fs_devs); + break; } else { fs_devs->num_devices--; list_del(&dev->dev_list); Patches currently in stable-queue which might be from nborisov(a)suse.com are queue-4.9/btrfs-fix-use-after-free-when-cleaning-up-fs_devs-with-a-single-stale-device.patch

7 years, 1 month

1
0
0 0

Patch "btrfs: alloc_chunk: fix DUP stripe size handling" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled btrfs: alloc_chunk: fix DUP stripe size handling to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-alloc_chunk-fix-dup-stripe-size-handling.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 92e222df7b8f05c565009c7383321b593eca488b Mon Sep 17 00:00:00 2001 From: Hans van Kranenburg <hans.van.kranenburg(a)mendix.com> Date: Mon, 5 Feb 2018 17:45:11 +0100 Subject: btrfs: alloc_chunk: fix DUP stripe size handling From: Hans van Kranenburg <hans.van.kranenburg(a)mendix.com> commit 92e222df7b8f05c565009c7383321b593eca488b upstream. In case of using DUP, we search for enough unallocated disk space on a device to hold two stripes. The devices_info[ndevs-1].max_avail that holds the amount of unallocated space found is directly assigned to stripe_size, while it's actually twice the stripe size. Later on in the code, an unconditional division of stripe_size by dev_stripes corrects the value, but in the meantime there's a check to see if the stripe_size does not exceed max_chunk_size. Since during this check stripe_size is twice the amount as intended, the check will reduce the stripe_size to max_chunk_size if the actual correct to be used stripe_size is more than half the amount of max_chunk_size. The unconditional division later tries to correct stripe_size, but will actually make sure we can't allocate more than half the max_chunk_size. Fix this by moving the division by dev_stripes before the max chunk size check, so it always contains the right value, instead of putting a duct tape division in further on to get it fixed again. Since in all other cases than DUP, dev_stripes is 1, this change only affects DUP. Other attempts in the past were made to fix this: * 37db63a400 "Btrfs: fix max chunk size check in chunk allocator" tried to fix the same problem, but still resulted in part of the code acting on a wrongly doubled stripe_size value. * 86db25785a "Btrfs: fix max chunk size on raid5/6" unintentionally broke this fix again. The real problem was already introduced with the rest of the code in 73c5de0051. The user visible result however will be that the max chunk size for DUP will suddenly double, while it's actually acting according to the limits in the code again like it was 5 years ago. Reported-by: Naohiro Aota <naohiro.aota(a)wdc.com> Link: https://www.spinics.net/lists/linux-btrfs/msg69752.html Fixes: 73c5de0051 ("btrfs: quasi-round-robin for chunk allocation") Fixes: 86db25785a ("Btrfs: fix max chunk size on raid5/6") Signed-off-by: Hans van Kranenburg <hans.van.kranenburg(a)mendix.com> Reviewed-by: David Sterba <dsterba(a)suse.com> [ update comment ] Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/volumes.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -4748,10 +4748,13 @@ static int __btrfs_alloc_chunk(struct bt if (devs_max && ndevs > devs_max) ndevs = devs_max; /* - * the primary goal is to maximize the number of stripes, so use as many - * devices as possible, even if the stripes are not maximum sized. + * The primary goal is to maximize the number of stripes, so use as + * many devices as possible, even if the stripes are not maximum sized. + * + * The DUP profile stores more than one stripe per device, the + * max_avail is the total size so we have to adjust. */ - stripe_size = devices_info[ndevs-1].max_avail; + stripe_size = div_u64(devices_info[ndevs - 1].max_avail, dev_stripes); num_stripes = ndevs * dev_stripes; /* @@ -4791,8 +4794,6 @@ static int __btrfs_alloc_chunk(struct bt stripe_size = devices_info[ndevs-1].max_avail; } - stripe_size = div_u64(stripe_size, dev_stripes); - /* align to BTRFS_STRIPE_LEN */ stripe_size = div_u64(stripe_size, raid_stripe_len); stripe_size *= raid_stripe_len; Patches currently in stable-queue which might be from hans.van.kranenburg(a)mendix.com are queue-4.9/btrfs-alloc_chunk-fix-dup-stripe-size-handling.patch

7 years, 1 month

1
0
0 0

Patch "btrfs: Fix use-after-free when cleaning up fs_devs with a single stale device" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled btrfs: Fix use-after-free when cleaning up fs_devs with a single stale device to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-use-after-free-when-cleaning-up-fs_devs-with-a-single-stale-device.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From fd649f10c3d21ee9d7542c609f29978bdf73ab94 Mon Sep 17 00:00:00 2001 From: Nikolay Borisov <nborisov(a)suse.com> Date: Tue, 30 Jan 2018 16:07:37 +0200 Subject: btrfs: Fix use-after-free when cleaning up fs_devs with a single stale device From: Nikolay Borisov <nborisov(a)suse.com> commit fd649f10c3d21ee9d7542c609f29978bdf73ab94 upstream. Commit 4fde46f0cc71 ("Btrfs: free the stale device") introduced btrfs_free_stale_device which iterates the device lists for all registered btrfs filesystems and deletes those devices which aren't mounted. In a btrfs_devices structure has only 1 device attached to it and it is unused then btrfs_free_stale_devices will proceed to also free the btrfs_fs_devices struct itself. Currently this leads to a use after free since list_for_each_entry will try to perform a check on the already freed memory to see if it has to terminate the loop. The fix is to use 'break' when we know we are freeing the current fs_devs. Fixes: 4fde46f0cc71 ("Btrfs: free the stale device") Signed-off-by: Nikolay Borisov <nborisov(a)suse.com> Reviewed-by: Anand Jain <anand.jain(a)oracle.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/volumes.c | 1 + 1 file changed, 1 insertion(+) --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -568,6 +568,7 @@ void btrfs_free_stale_device(struct btrf btrfs_sysfs_remove_fsid(fs_devs); list_del(&fs_devs->list); free_fs_devices(fs_devs); + break; } else { fs_devs->num_devices--; list_del(&dev->dev_list); Patches currently in stable-queue which might be from nborisov(a)suse.com are queue-4.4/btrfs-fix-use-after-free-when-cleaning-up-fs_devs-with-a-single-stale-device.patch

7 years, 1 month

1
0
0 0

Patch "btrfs: alloc_chunk: fix DUP stripe size handling" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled btrfs: alloc_chunk: fix DUP stripe size handling to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-alloc_chunk-fix-dup-stripe-size-handling.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 92e222df7b8f05c565009c7383321b593eca488b Mon Sep 17 00:00:00 2001 From: Hans van Kranenburg <hans.van.kranenburg(a)mendix.com> Date: Mon, 5 Feb 2018 17:45:11 +0100 Subject: btrfs: alloc_chunk: fix DUP stripe size handling From: Hans van Kranenburg <hans.van.kranenburg(a)mendix.com> commit 92e222df7b8f05c565009c7383321b593eca488b upstream. In case of using DUP, we search for enough unallocated disk space on a device to hold two stripes. The devices_info[ndevs-1].max_avail that holds the amount of unallocated space found is directly assigned to stripe_size, while it's actually twice the stripe size. Later on in the code, an unconditional division of stripe_size by dev_stripes corrects the value, but in the meantime there's a check to see if the stripe_size does not exceed max_chunk_size. Since during this check stripe_size is twice the amount as intended, the check will reduce the stripe_size to max_chunk_size if the actual correct to be used stripe_size is more than half the amount of max_chunk_size. The unconditional division later tries to correct stripe_size, but will actually make sure we can't allocate more than half the max_chunk_size. Fix this by moving the division by dev_stripes before the max chunk size check, so it always contains the right value, instead of putting a duct tape division in further on to get it fixed again. Since in all other cases than DUP, dev_stripes is 1, this change only affects DUP. Other attempts in the past were made to fix this: * 37db63a400 "Btrfs: fix max chunk size check in chunk allocator" tried to fix the same problem, but still resulted in part of the code acting on a wrongly doubled stripe_size value. * 86db25785a "Btrfs: fix max chunk size on raid5/6" unintentionally broke this fix again. The real problem was already introduced with the rest of the code in 73c5de0051. The user visible result however will be that the max chunk size for DUP will suddenly double, while it's actually acting according to the limits in the code again like it was 5 years ago. Reported-by: Naohiro Aota <naohiro.aota(a)wdc.com> Link: https://www.spinics.net/lists/linux-btrfs/msg69752.html Fixes: 73c5de0051 ("btrfs: quasi-round-robin for chunk allocation") Fixes: 86db25785a ("Btrfs: fix max chunk size on raid5/6") Signed-off-by: Hans van Kranenburg <hans.van.kranenburg(a)mendix.com> Reviewed-by: David Sterba <dsterba(a)suse.com> [ update comment ] Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/volumes.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -4638,10 +4638,13 @@ static int __btrfs_alloc_chunk(struct bt if (devs_max && ndevs > devs_max) ndevs = devs_max; /* - * the primary goal is to maximize the number of stripes, so use as many - * devices as possible, even if the stripes are not maximum sized. + * The primary goal is to maximize the number of stripes, so use as + * many devices as possible, even if the stripes are not maximum sized. + * + * The DUP profile stores more than one stripe per device, the + * max_avail is the total size so we have to adjust. */ - stripe_size = devices_info[ndevs-1].max_avail; + stripe_size = div_u64(devices_info[ndevs - 1].max_avail, dev_stripes); num_stripes = ndevs * dev_stripes; /* @@ -4681,8 +4684,6 @@ static int __btrfs_alloc_chunk(struct bt stripe_size = devices_info[ndevs-1].max_avail; } - stripe_size = div_u64(stripe_size, dev_stripes); - /* align to BTRFS_STRIPE_LEN */ stripe_size = div_u64(stripe_size, raid_stripe_len); stripe_size *= raid_stripe_len; Patches currently in stable-queue which might be from hans.van.kranenburg(a)mendix.com are queue-4.4/btrfs-alloc_chunk-fix-dup-stripe-size-handling.patch

7 years, 1 month

1
0
0 0

[PATCH AUTOSEL for 4.9 001/281] qed: Fix overriding of supported autoneg value.

by Sasha Levin

From: "sudarsana.kalluru(a)cavium.com" <sudarsana.kalluru(a)cavium.com> [ Upstream commit 34f9199ce7b7e5c641b96e928bd60e086bf7f278 ] Driver currently uses advertised-autoneg value to populate the supported-autoneg field. When advertised field is updated, user gets the same value for supported field. Supported-autoneg value need to be populated from the link capabilities value returned by the MFW. Signed-off-by: Sudarsana Reddy Kalluru <Sudarsana.Kalluru(a)cavium.com> Signed-off-by: Yuval Mintz <Yuval.Mintz(a)cavium.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> --- drivers/net/ethernet/qlogic/qed/qed_dev.c | 3 +++ drivers/net/ethernet/qlogic/qed/qed_main.c | 6 +++++- drivers/net/ethernet/qlogic/qed/qed_mcp.h | 1 + 3 files changed, 9 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/qlogic/qed/qed_dev.c b/drivers/net/ethernet/qlogic/qed/qed_dev.c index afe5e57d9acb..9a6adbd9ed34 100644 --- a/drivers/net/ethernet/qlogic/qed/qed_dev.c +++ b/drivers/net/ethernet/qlogic/qed/qed_dev.c @@ -1628,6 +1628,9 @@ static int qed_hw_get_nvm_info(struct qed_hwfn *p_hwfn, struct qed_ptt *p_ptt) DP_NOTICE(p_hwfn, "Unknown Speed in 0x%08x\n", link_temp); } + p_hwfn->mcp_info->link_capabilities.default_speed_autoneg = + link->speed.autoneg; + link_temp &= NVM_CFG1_PORT_DRV_FLOW_CONTROL_MASK; link_temp >>= NVM_CFG1_PORT_DRV_FLOW_CONTROL_OFFSET; link->pause.autoneg = !!(link_temp & diff --git a/drivers/net/ethernet/qlogic/qed/qed_main.c b/drivers/net/ethernet/qlogic/qed/qed_main.c index 333c7442e48a..605351a2a1bc 100644 --- a/drivers/net/ethernet/qlogic/qed/qed_main.c +++ b/drivers/net/ethernet/qlogic/qed/qed_main.c @@ -1239,7 +1239,7 @@ static void qed_fill_link(struct qed_hwfn *hwfn, /* TODO - at the moment assume supported and advertised speed equal */ if_link->supported_caps = QED_LM_FIBRE_BIT; - if (params.speed.autoneg) + if (link_caps.default_speed_autoneg) if_link->supported_caps |= QED_LM_Autoneg_BIT; if (params.pause.autoneg || (params.pause.forced_rx && params.pause.forced_tx)) @@ -1249,6 +1249,10 @@ static void qed_fill_link(struct qed_hwfn *hwfn, if_link->supported_caps |= QED_LM_Pause_BIT; if_link->advertised_caps = if_link->supported_caps; + if (params.speed.autoneg) + if_link->advertised_caps |= QED_LM_Autoneg_BIT; + else + if_link->advertised_caps &= ~QED_LM_Autoneg_BIT; if (params.speed.advertised_speeds & NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_1G) if_link->advertised_caps |= QED_LM_1000baseT_Half_BIT | diff --git a/drivers/net/ethernet/qlogic/qed/qed_mcp.h b/drivers/net/ethernet/qlogic/qed/qed_mcp.h index dff520ed069b..7b7a84d2c839 100644 --- a/drivers/net/ethernet/qlogic/qed/qed_mcp.h +++ b/drivers/net/ethernet/qlogic/qed/qed_mcp.h @@ -35,6 +35,7 @@ struct qed_mcp_link_params { struct qed_mcp_link_capabilities { u32 speed_capabilities; + bool default_speed_autoneg; }; struct qed_mcp_link_state { -- 2.14.1

7 years, 1 month

1
280
0 0

Patch "btrfs: remove spurious WARN_ON(ref->count < 0) in find_parent_nodes" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled btrfs: remove spurious WARN_ON(ref->count < 0) in find_parent_nodes to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-remove-spurious-warn_on-ref-count-0-in-find_parent_nodes.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From c8195a7b1ad5648857ce20ba24f384faed8512bc Mon Sep 17 00:00:00 2001 From: Zygo Blaxell <ce3g8jdj(a)umail.furryterror.org> Date: Tue, 23 Jan 2018 22:22:09 -0500 Subject: btrfs: remove spurious WARN_ON(ref->count < 0) in find_parent_nodes From: Zygo Blaxell <ce3g8jdj(a)umail.furryterror.org> commit c8195a7b1ad5648857ce20ba24f384faed8512bc upstream. Until v4.14, this warning was very infrequent: WARNING: CPU: 3 PID: 18172 at fs/btrfs/backref.c:1391 find_parent_nodes+0xc41/0x14e0 Modules linked in: [...] CPU: 3 PID: 18172 Comm: bees Tainted: G D W L 4.11.9-zb64+ #1 Hardware name: System manufacturer System Product Name/M5A78L-M/USB3, BIOS 2101 12/02/2014 Call Trace: dump_stack+0x85/0xc2 __warn+0xd1/0xf0 warn_slowpath_null+0x1d/0x20 find_parent_nodes+0xc41/0x14e0 __btrfs_find_all_roots+0xad/0x120 ? extent_same_check_offsets+0x70/0x70 iterate_extent_inodes+0x168/0x300 iterate_inodes_from_logical+0x87/0xb0 ? iterate_inodes_from_logical+0x87/0xb0 ? extent_same_check_offsets+0x70/0x70 btrfs_ioctl+0x8ac/0x2820 ? lock_acquire+0xc2/0x200 do_vfs_ioctl+0x91/0x700 ? __fget+0x112/0x200 SyS_ioctl+0x79/0x90 entry_SYSCALL_64_fastpath+0x23/0xc6 ? trace_hardirqs_off_caller+0x1f/0x140 Starting with v4.14 (specifically 86d5f9944252 ("btrfs: convert prelimary reference tracking to use rbtrees")) the WARN_ON occurs three orders of magnitude more frequently--almost once per second while running workloads like bees. Replace the WARN_ON() with a comment rationale for its removal. The rationale is paraphrased from an explanation by Edmund Nadolski <enadolski(a)suse.de> on the linux-btrfs mailing list. Fixes: 8da6d5815c59 ("Btrfs: added btrfs_find_all_roots()") Signed-off-by: Zygo Blaxell <ce3g8jdj(a)umail.furryterror.org> Reviewed-by: Lu Fengqi <lufq.fnst(a)cn.fujitsu.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/backref.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) --- a/fs/btrfs/backref.c +++ b/fs/btrfs/backref.c @@ -1263,7 +1263,16 @@ again: while (node) { ref = rb_entry(node, struct prelim_ref, rbnode); node = rb_next(&ref->rbnode); - WARN_ON(ref->count < 0); + /* + * ref->count < 0 can happen here if there are delayed + * refs with a node->action of BTRFS_DROP_DELAYED_REF. + * prelim_ref_insert() relies on this when merging + * identical refs to keep the overall count correct. + * prelim_ref_insert() will merge only those refs + * which compare identically. Any refs having + * e.g. different offsets would not be merged, + * and would retain their original ref->count < 0. + */ if (roots && ref->count && ref->root_id && ref->parent == 0) { if (sc && sc->root_objectid && ref->root_id != sc->root_objectid) { Patches currently in stable-queue which might be from ce3g8jdj(a)umail.furryterror.org are queue-4.15/btrfs-remove-spurious-warn_on-ref-count-0-in-find_parent_nodes.patch

7 years, 1 month

1
0
0 0

Patch "btrfs: Fix use-after-free when cleaning up fs_devs with a single stale device" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled btrfs: Fix use-after-free when cleaning up fs_devs with a single stale device to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-use-after-free-when-cleaning-up-fs_devs-with-a-single-stale-device.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From fd649f10c3d21ee9d7542c609f29978bdf73ab94 Mon Sep 17 00:00:00 2001 From: Nikolay Borisov <nborisov(a)suse.com> Date: Tue, 30 Jan 2018 16:07:37 +0200 Subject: btrfs: Fix use-after-free when cleaning up fs_devs with a single stale device From: Nikolay Borisov <nborisov(a)suse.com> commit fd649f10c3d21ee9d7542c609f29978bdf73ab94 upstream. Commit 4fde46f0cc71 ("Btrfs: free the stale device") introduced btrfs_free_stale_device which iterates the device lists for all registered btrfs filesystems and deletes those devices which aren't mounted. In a btrfs_devices structure has only 1 device attached to it and it is unused then btrfs_free_stale_devices will proceed to also free the btrfs_fs_devices struct itself. Currently this leads to a use after free since list_for_each_entry will try to perform a check on the already freed memory to see if it has to terminate the loop. The fix is to use 'break' when we know we are freeing the current fs_devs. Fixes: 4fde46f0cc71 ("Btrfs: free the stale device") Signed-off-by: Nikolay Borisov <nborisov(a)suse.com> Reviewed-by: Anand Jain <anand.jain(a)oracle.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/volumes.c | 1 + 1 file changed, 1 insertion(+) --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -574,6 +574,7 @@ static void btrfs_free_stale_device(stru btrfs_sysfs_remove_fsid(fs_devs); list_del(&fs_devs->list); free_fs_devices(fs_devs); + break; } else { fs_devs->num_devices--; list_del(&dev->dev_list); Patches currently in stable-queue which might be from nborisov(a)suse.com are queue-4.15/btrfs-fix-memory-barriers-usage-with-device-stats-counters.patch queue-4.15/btrfs-fix-use-after-free-when-cleaning-up-fs_devs-with-a-single-stale-device.patch

7 years, 1 month

1
0
0 0

Patch "btrfs: Fix NULL pointer exception in find_bio_stripe" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled btrfs: Fix NULL pointer exception in find_bio_stripe to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-null-pointer-exception-in-find_bio_stripe.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 047fdea6341966a0898e3b16c51f54d4f5ba030a Mon Sep 17 00:00:00 2001 From: Dmitriy Gorokh <Dmitriy.Gorokh(a)wdc.com> Date: Fri, 16 Feb 2018 19:51:38 +0000 Subject: btrfs: Fix NULL pointer exception in find_bio_stripe MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Dmitriy Gorokh <Dmitriy.Gorokh(a)wdc.com> commit 047fdea6341966a0898e3b16c51f54d4f5ba030a upstream. On detaching of a disk which is a part of a RAID6 filesystem, the following kernel OOPS may happen: [63122.680461] BTRFS error (device sdo): bdev /dev/sdo errs: wr 0, rd 0, flush 1, corrupt 0, gen 0 [63122.719584] BTRFS warning (device sdo): lost page write due to IO error on /dev/sdo [63122.719587] BTRFS error (device sdo): bdev /dev/sdo errs: wr 1, rd 0, flush 1, corrupt 0, gen 0 [63122.803516] BTRFS warning (device sdo): lost page write due to IO error on /dev/sdo [63122.803519] BTRFS error (device sdo): bdev /dev/sdo errs: wr 2, rd 0, flush 1, corrupt 0, gen 0 [63122.863902] BTRFS critical (device sdo): fatal error on device /dev/sdo [63122.935338] BUG: unable to handle kernel NULL pointer dereference at 0000000000000080 [63122.946554] IP: fail_bio_stripe+0x58/0xa0 [btrfs] [63122.958185] PGD 9ecda067 P4D 9ecda067 PUD b2b37067 PMD 0 [63122.971202] Oops: 0000 [#1] SMP [63123.006760] CPU: 0 PID: 3979 Comm: kworker/u8:9 Tainted: G W 4.14.2-16-scst34x+ #8 [63123.007091] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [63123.007402] Workqueue: btrfs-worker btrfs_worker_helper [btrfs] [63123.007595] task: ffff880036ea4040 task.stack: ffffc90006384000 [63123.007796] RIP: 0010:fail_bio_stripe+0x58/0xa0 [btrfs] [63123.007968] RSP: 0018:ffffc90006387ad8 EFLAGS: 00010287 [63123.008140] RAX: 0000000000000002 RBX: ffff88004beaa0b8 RCX: ffff8800b2bd5690 [63123.008359] RDX: 0000000000000000 RSI: ffff88007bb43500 RDI: ffff88004beaa000 [63123.008621] RBP: ffffc90006387ae8 R08: 0000000099100000 R09: ffff8800b2bd5600 [63123.008840] R10: 0000000000000004 R11: 0000000000010000 R12: ffff88007bb43500 [63123.009059] R13: 00000000fffffffb R14: ffff880036fc5180 R15: 0000000000000004 [63123.009278] FS: 0000000000000000(0000) GS:ffff8800b7000000(0000) knlGS:0000000000000000 [63123.009564] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [63123.009748] CR2: 0000000000000080 CR3: 00000000b0866000 CR4: 00000000000406f0 [63123.009969] Call Trace: [63123.010085] raid_write_end_io+0x7e/0x80 [btrfs] [63123.010251] bio_endio+0xa1/0x120 [63123.010378] generic_make_request+0x218/0x270 [63123.010921] submit_bio+0x66/0x130 [63123.011073] finish_rmw+0x3fc/0x5b0 [btrfs] [63123.011245] full_stripe_write+0x96/0xc0 [btrfs] [63123.011428] raid56_parity_write+0x117/0x170 [btrfs] [63123.011604] btrfs_map_bio+0x2ec/0x320 [btrfs] [63123.011759] ? ___cache_free+0x1c5/0x300 [63123.011909] __btrfs_submit_bio_done+0x26/0x50 [btrfs] [63123.012087] run_one_async_done+0x9c/0xc0 [btrfs] [63123.012257] normal_work_helper+0x19e/0x300 [btrfs] [63123.012429] btrfs_worker_helper+0x12/0x20 [btrfs] [63123.012656] process_one_work+0x14d/0x350 [63123.012888] worker_thread+0x4d/0x3a0 [63123.013026] ? _raw_spin_unlock_irqrestore+0x15/0x20 [63123.013192] kthread+0x109/0x140 [63123.013315] ? process_scheduled_works+0x40/0x40 [63123.013472] ? kthread_stop+0x110/0x110 [63123.013610] ret_from_fork+0x25/0x30 [63123.014469] RIP: fail_bio_stripe+0x58/0xa0 [btrfs] RSP: ffffc90006387ad8 [63123.014678] CR2: 0000000000000080 [63123.016590] ---[ end trace a295ea7259c17880 ]— This is reproducible in a cycle, where a series of writes is followed by SCSI device delete command. The test may take up to few minutes. Fixes: 74d46992e0d9 ("block: replace bi_bdev with a gendisk pointer and partitions index") [ no signed-off-by provided ] Author: Dmitriy Gorokh <Dmitriy.Gorokh(a)wdc.com> Reviewed-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/raid56.c | 1 + 1 file changed, 1 insertion(+) --- a/fs/btrfs/raid56.c +++ b/fs/btrfs/raid56.c @@ -1351,6 +1351,7 @@ static int find_bio_stripe(struct btrfs_ stripe_start = stripe->physical; if (physical >= stripe_start && physical < stripe_start + rbio->stripe_len && + stripe->dev->bdev && bio->bi_disk == stripe->dev->bdev->bd_disk && bio->bi_partno == stripe->dev->bdev->bd_partno) { return i; Patches currently in stable-queue which might be from Dmitriy.Gorokh(a)wdc.com are queue-4.15/btrfs-fix-null-pointer-exception-in-find_bio_stripe.patch

7 years, 1 month

1
0
0 0

Patch "btrfs: Fix memory barriers usage with device stats counters" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled btrfs: Fix memory barriers usage with device stats counters to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-memory-barriers-usage-with-device-stats-counters.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 9deae9689231964972a94bb56a79b669f9d47ac1 Mon Sep 17 00:00:00 2001 From: Nikolay Borisov <nborisov(a)suse.com> Date: Tue, 24 Oct 2017 13:47:37 +0300 Subject: btrfs: Fix memory barriers usage with device stats counters From: Nikolay Borisov <nborisov(a)suse.com> commit 9deae9689231964972a94bb56a79b669f9d47ac1 upstream. Commit addc3fa74e5b ("Btrfs: Fix the problem that the dirty flag of dev stats is cleared") reworked the way device stats changes are tracked. A new atomic dev_stats_ccnt counter was introduced which is incremented every time any of the device stats counters are changed. This serves as a flag whether there are any pending stats changes. However, this patch only partially implemented the correct memory barriers necessary: - It only ordered the stores to the counters but not the reads e.g. btrfs_run_dev_stats - It completely omitted any comments documenting the intended design and how the memory barriers pair with each-other This patch provides the necessary comments as well as adds a missing smp_rmb in btrfs_run_dev_stats. Furthermore since dev_stats_cnt is only a snapshot at best there was no point in reading the counter twice - once in btrfs_dev_stats_dirty and then again when assigning stats_cnt. Just collapse both reads into 1. Fixes: addc3fa74e5b ("Btrfs: Fix the problem that the dirty flag of dev stats is cleared") Signed-off-by: Nikolay Borisov <nborisov(a)suse.com> Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/volumes.c | 18 ++++++++++++++++-- fs/btrfs/volumes.h | 12 ++++++++++++ 2 files changed, 28 insertions(+), 2 deletions(-) --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -7093,10 +7093,24 @@ int btrfs_run_dev_stats(struct btrfs_tra mutex_lock(&fs_devices->device_list_mutex); list_for_each_entry(device, &fs_devices->devices, dev_list) { - if (!device->dev_stats_valid || !btrfs_dev_stats_dirty(device)) + stats_cnt = atomic_read(&device->dev_stats_ccnt); + if (!device->dev_stats_valid || stats_cnt == 0) continue; - stats_cnt = atomic_read(&device->dev_stats_ccnt); + + /* + * There is a LOAD-LOAD control dependency between the value of + * dev_stats_ccnt and updating the on-disk values which requires + * reading the in-memory counters. Such control dependencies + * require explicit read memory barriers. + * + * This memory barriers pairs with smp_mb__before_atomic in + * btrfs_dev_stat_inc/btrfs_dev_stat_set and with the full + * barrier implied by atomic_xchg in + * btrfs_dev_stats_read_and_reset + */ + smp_rmb(); + ret = update_dev_stat_item(trans, fs_info, device); if (!ret) atomic_sub(stats_cnt, &device->dev_stats_ccnt); --- a/fs/btrfs/volumes.h +++ b/fs/btrfs/volumes.h @@ -498,6 +498,12 @@ static inline void btrfs_dev_stat_inc(st int index) { atomic_inc(dev->dev_stat_values + index); + /* + * This memory barrier orders stores updating statistics before stores + * updating dev_stats_ccnt. + * + * It pairs with smp_rmb() in btrfs_run_dev_stats(). + */ smp_mb__before_atomic(); atomic_inc(&dev->dev_stats_ccnt); } @@ -523,6 +529,12 @@ static inline void btrfs_dev_stat_set(st int index, unsigned long val) { atomic_set(dev->dev_stat_values + index, val); + /* + * This memory barrier orders stores updating statistics before stores + * updating dev_stats_ccnt. + * + * It pairs with smp_rmb() in btrfs_run_dev_stats(). + */ smp_mb__before_atomic(); atomic_inc(&dev->dev_stats_ccnt); } Patches currently in stable-queue which might be from nborisov(a)suse.com are queue-4.15/btrfs-fix-memory-barriers-usage-with-device-stats-counters.patch queue-4.15/btrfs-fix-use-after-free-when-cleaning-up-fs_devs-with-a-single-stale-device.patch

7 years, 1 month

1
0
0 0

Patch "btrfs: alloc_chunk: fix DUP stripe size handling" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled btrfs: alloc_chunk: fix DUP stripe size handling to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-alloc_chunk-fix-dup-stripe-size-handling.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 92e222df7b8f05c565009c7383321b593eca488b Mon Sep 17 00:00:00 2001 From: Hans van Kranenburg <hans.van.kranenburg(a)mendix.com> Date: Mon, 5 Feb 2018 17:45:11 +0100 Subject: btrfs: alloc_chunk: fix DUP stripe size handling From: Hans van Kranenburg <hans.van.kranenburg(a)mendix.com> commit 92e222df7b8f05c565009c7383321b593eca488b upstream. In case of using DUP, we search for enough unallocated disk space on a device to hold two stripes. The devices_info[ndevs-1].max_avail that holds the amount of unallocated space found is directly assigned to stripe_size, while it's actually twice the stripe size. Later on in the code, an unconditional division of stripe_size by dev_stripes corrects the value, but in the meantime there's a check to see if the stripe_size does not exceed max_chunk_size. Since during this check stripe_size is twice the amount as intended, the check will reduce the stripe_size to max_chunk_size if the actual correct to be used stripe_size is more than half the amount of max_chunk_size. The unconditional division later tries to correct stripe_size, but will actually make sure we can't allocate more than half the max_chunk_size. Fix this by moving the division by dev_stripes before the max chunk size check, so it always contains the right value, instead of putting a duct tape division in further on to get it fixed again. Since in all other cases than DUP, dev_stripes is 1, this change only affects DUP. Other attempts in the past were made to fix this: * 37db63a400 "Btrfs: fix max chunk size check in chunk allocator" tried to fix the same problem, but still resulted in part of the code acting on a wrongly doubled stripe_size value. * 86db25785a "Btrfs: fix max chunk size on raid5/6" unintentionally broke this fix again. The real problem was already introduced with the rest of the code in 73c5de0051. The user visible result however will be that the max chunk size for DUP will suddenly double, while it's actually acting according to the limits in the code again like it was 5 years ago. Reported-by: Naohiro Aota <naohiro.aota(a)wdc.com> Link: https://www.spinics.net/lists/linux-btrfs/msg69752.html Fixes: 73c5de0051 ("btrfs: quasi-round-robin for chunk allocation") Fixes: 86db25785a ("Btrfs: fix max chunk size on raid5/6") Signed-off-by: Hans van Kranenburg <hans.van.kranenburg(a)mendix.com> Reviewed-by: David Sterba <dsterba(a)suse.com> [ update comment ] Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/volumes.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -4737,10 +4737,13 @@ static int __btrfs_alloc_chunk(struct bt ndevs = min(ndevs, devs_max); /* - * the primary goal is to maximize the number of stripes, so use as many - * devices as possible, even if the stripes are not maximum sized. + * The primary goal is to maximize the number of stripes, so use as + * many devices as possible, even if the stripes are not maximum sized. + * + * The DUP profile stores more than one stripe per device, the + * max_avail is the total size so we have to adjust. */ - stripe_size = devices_info[ndevs-1].max_avail; + stripe_size = div_u64(devices_info[ndevs - 1].max_avail, dev_stripes); num_stripes = ndevs * dev_stripes; /* @@ -4775,8 +4778,6 @@ static int __btrfs_alloc_chunk(struct bt stripe_size = devices_info[ndevs-1].max_avail; } - stripe_size = div_u64(stripe_size, dev_stripes); - /* align to BTRFS_STRIPE_LEN */ stripe_size = round_down(stripe_size, BTRFS_STRIPE_LEN); Patches currently in stable-queue which might be from hans.van.kranenburg(a)mendix.com are queue-4.15/btrfs-alloc_chunk-fix-dup-stripe-size-handling.patch

7 years, 1 month

1
0
0 0

Patch "btrfs: add missing initialization in btrfs_check_shared" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled btrfs: add missing initialization in btrfs_check_shared to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-add-missing-initialization-in-btrfs_check_shared.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 18bf591ba9753e3e5ba91f38f756a800693408f4 Mon Sep 17 00:00:00 2001 From: Edmund Nadolski <enadolski(a)suse.com> Date: Wed, 14 Mar 2018 09:03:11 -0600 Subject: btrfs: add missing initialization in btrfs_check_shared From: Edmund Nadolski <enadolski(a)suse.com> commit 18bf591ba9753e3e5ba91f38f756a800693408f4 upstream. This patch addresses an issue that causes fiemap to falsely report a shared extent. The test case is as follows: xfs_io -f -d -c "pwrite -b 16k 0 64k" -c "fiemap -v" /media/scratch/file5 sync xfs_io -c "fiemap -v" /media/scratch/file5 which gives the resulting output: wrote 65536/65536 bytes at offset 0 64 KiB, 4 ops; 0.0000 sec (121.359 MiB/sec and 7766.9903 ops/sec) /media/scratch/file5: EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS 0: [0..127]: 24576..24703 128 0x2001 /media/scratch/file5: EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS 0: [0..127]: 24576..24703 128 0x1 This is because btrfs_check_shared calls find_parent_nodes repeatedly in a loop, passing a share_check struct to report the count of shared extent. But btrfs_check_shared does not re-initialize the count value to zero for subsequent calls from the loop, resulting in a false share count value. This is a regressive behavior from 4.13. With proper re-initialization the test result is as follows: wrote 65536/65536 bytes at offset 0 64 KiB, 4 ops; 0.0000 sec (110.035 MiB/sec and 7042.2535 ops/sec) /media/scratch/file5: EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS 0: [0..127]: 24576..24703 128 0x1 /media/scratch/file5: EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS 0: [0..127]: 24576..24703 128 0x1 which corrects the regression. Fixes: 3ec4d3238ab ("btrfs: allow backref search checks for shared extents") Signed-off-by: Edmund Nadolski <enadolski(a)suse.com> [ add text from cover letter to changelog ] Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/backref.c | 1 + 1 file changed, 1 insertion(+) --- a/fs/btrfs/backref.c +++ b/fs/btrfs/backref.c @@ -1509,6 +1509,7 @@ int btrfs_check_shared(struct btrfs_root if (!node) break; bytenr = node->val; + shared.share_count = 0; cond_resched(); } Patches currently in stable-queue which might be from enadolski(a)suse.com are queue-4.15/btrfs-add-missing-initialization-in-btrfs_check_shared.patch

7 years, 1 month

1
0
0 0

Patch "btrfs: remove spurious WARN_ON(ref->count < 0) in find_parent_nodes" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled btrfs: remove spurious WARN_ON(ref->count < 0) in find_parent_nodes to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-remove-spurious-warn_on-ref-count-0-in-find_parent_nodes.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From c8195a7b1ad5648857ce20ba24f384faed8512bc Mon Sep 17 00:00:00 2001 From: Zygo Blaxell <ce3g8jdj(a)umail.furryterror.org> Date: Tue, 23 Jan 2018 22:22:09 -0500 Subject: btrfs: remove spurious WARN_ON(ref->count < 0) in find_parent_nodes From: Zygo Blaxell <ce3g8jdj(a)umail.furryterror.org> commit c8195a7b1ad5648857ce20ba24f384faed8512bc upstream. Until v4.14, this warning was very infrequent: WARNING: CPU: 3 PID: 18172 at fs/btrfs/backref.c:1391 find_parent_nodes+0xc41/0x14e0 Modules linked in: [...] CPU: 3 PID: 18172 Comm: bees Tainted: G D W L 4.11.9-zb64+ #1 Hardware name: System manufacturer System Product Name/M5A78L-M/USB3, BIOS 2101 12/02/2014 Call Trace: dump_stack+0x85/0xc2 __warn+0xd1/0xf0 warn_slowpath_null+0x1d/0x20 find_parent_nodes+0xc41/0x14e0 __btrfs_find_all_roots+0xad/0x120 ? extent_same_check_offsets+0x70/0x70 iterate_extent_inodes+0x168/0x300 iterate_inodes_from_logical+0x87/0xb0 ? iterate_inodes_from_logical+0x87/0xb0 ? extent_same_check_offsets+0x70/0x70 btrfs_ioctl+0x8ac/0x2820 ? lock_acquire+0xc2/0x200 do_vfs_ioctl+0x91/0x700 ? __fget+0x112/0x200 SyS_ioctl+0x79/0x90 entry_SYSCALL_64_fastpath+0x23/0xc6 ? trace_hardirqs_off_caller+0x1f/0x140 Starting with v4.14 (specifically 86d5f9944252 ("btrfs: convert prelimary reference tracking to use rbtrees")) the WARN_ON occurs three orders of magnitude more frequently--almost once per second while running workloads like bees. Replace the WARN_ON() with a comment rationale for its removal. The rationale is paraphrased from an explanation by Edmund Nadolski <enadolski(a)suse.de> on the linux-btrfs mailing list. Fixes: 8da6d5815c59 ("Btrfs: added btrfs_find_all_roots()") Signed-off-by: Zygo Blaxell <ce3g8jdj(a)umail.furryterror.org> Reviewed-by: Lu Fengqi <lufq.fnst(a)cn.fujitsu.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/backref.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) --- a/fs/btrfs/backref.c +++ b/fs/btrfs/backref.c @@ -1252,7 +1252,16 @@ again: while (node) { ref = rb_entry(node, struct prelim_ref, rbnode); node = rb_next(&ref->rbnode); - WARN_ON(ref->count < 0); + /* + * ref->count < 0 can happen here if there are delayed + * refs with a node->action of BTRFS_DROP_DELAYED_REF. + * prelim_ref_insert() relies on this when merging + * identical refs to keep the overall count correct. + * prelim_ref_insert() will merge only those refs + * which compare identically. Any refs having + * e.g. different offsets would not be merged, + * and would retain their original ref->count < 0. + */ if (roots && ref->count && ref->root_id && ref->parent == 0) { if (sc && sc->root_objectid && ref->root_id != sc->root_objectid) { Patches currently in stable-queue which might be from ce3g8jdj(a)umail.furryterror.org are queue-4.14/btrfs-remove-spurious-warn_on-ref-count-0-in-find_parent_nodes.patch

7 years, 1 month

1
0
0 0

Patch "btrfs: Fix use-after-free when cleaning up fs_devs with a single stale device" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled btrfs: Fix use-after-free when cleaning up fs_devs with a single stale device to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-use-after-free-when-cleaning-up-fs_devs-with-a-single-stale-device.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From fd649f10c3d21ee9d7542c609f29978bdf73ab94 Mon Sep 17 00:00:00 2001 From: Nikolay Borisov <nborisov(a)suse.com> Date: Tue, 30 Jan 2018 16:07:37 +0200 Subject: btrfs: Fix use-after-free when cleaning up fs_devs with a single stale device From: Nikolay Borisov <nborisov(a)suse.com> commit fd649f10c3d21ee9d7542c609f29978bdf73ab94 upstream. Commit 4fde46f0cc71 ("Btrfs: free the stale device") introduced btrfs_free_stale_device which iterates the device lists for all registered btrfs filesystems and deletes those devices which aren't mounted. In a btrfs_devices structure has only 1 device attached to it and it is unused then btrfs_free_stale_devices will proceed to also free the btrfs_fs_devices struct itself. Currently this leads to a use after free since list_for_each_entry will try to perform a check on the already freed memory to see if it has to terminate the loop. The fix is to use 'break' when we know we are freeing the current fs_devs. Fixes: 4fde46f0cc71 ("Btrfs: free the stale device") Signed-off-by: Nikolay Borisov <nborisov(a)suse.com> Reviewed-by: Anand Jain <anand.jain(a)oracle.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/volumes.c | 1 + 1 file changed, 1 insertion(+) --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -589,6 +589,7 @@ void btrfs_free_stale_device(struct btrf btrfs_sysfs_remove_fsid(fs_devs); list_del(&fs_devs->list); free_fs_devices(fs_devs); + break; } else { fs_devs->num_devices--; list_del(&dev->dev_list); Patches currently in stable-queue which might be from nborisov(a)suse.com are queue-4.14/btrfs-fix-memory-barriers-usage-with-device-stats-counters.patch queue-4.14/btrfs-fix-use-after-free-when-cleaning-up-fs_devs-with-a-single-stale-device.patch

7 years, 1 month

1
0
0 0

Patch "btrfs: Fix NULL pointer exception in find_bio_stripe" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled btrfs: Fix NULL pointer exception in find_bio_stripe to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-null-pointer-exception-in-find_bio_stripe.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 047fdea6341966a0898e3b16c51f54d4f5ba030a Mon Sep 17 00:00:00 2001 From: Dmitriy Gorokh <Dmitriy.Gorokh(a)wdc.com> Date: Fri, 16 Feb 2018 19:51:38 +0000 Subject: btrfs: Fix NULL pointer exception in find_bio_stripe MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Dmitriy Gorokh <Dmitriy.Gorokh(a)wdc.com> commit 047fdea6341966a0898e3b16c51f54d4f5ba030a upstream. On detaching of a disk which is a part of a RAID6 filesystem, the following kernel OOPS may happen: [63122.680461] BTRFS error (device sdo): bdev /dev/sdo errs: wr 0, rd 0, flush 1, corrupt 0, gen 0 [63122.719584] BTRFS warning (device sdo): lost page write due to IO error on /dev/sdo [63122.719587] BTRFS error (device sdo): bdev /dev/sdo errs: wr 1, rd 0, flush 1, corrupt 0, gen 0 [63122.803516] BTRFS warning (device sdo): lost page write due to IO error on /dev/sdo [63122.803519] BTRFS error (device sdo): bdev /dev/sdo errs: wr 2, rd 0, flush 1, corrupt 0, gen 0 [63122.863902] BTRFS critical (device sdo): fatal error on device /dev/sdo [63122.935338] BUG: unable to handle kernel NULL pointer dereference at 0000000000000080 [63122.946554] IP: fail_bio_stripe+0x58/0xa0 [btrfs] [63122.958185] PGD 9ecda067 P4D 9ecda067 PUD b2b37067 PMD 0 [63122.971202] Oops: 0000 [#1] SMP [63123.006760] CPU: 0 PID: 3979 Comm: kworker/u8:9 Tainted: G W 4.14.2-16-scst34x+ #8 [63123.007091] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [63123.007402] Workqueue: btrfs-worker btrfs_worker_helper [btrfs] [63123.007595] task: ffff880036ea4040 task.stack: ffffc90006384000 [63123.007796] RIP: 0010:fail_bio_stripe+0x58/0xa0 [btrfs] [63123.007968] RSP: 0018:ffffc90006387ad8 EFLAGS: 00010287 [63123.008140] RAX: 0000000000000002 RBX: ffff88004beaa0b8 RCX: ffff8800b2bd5690 [63123.008359] RDX: 0000000000000000 RSI: ffff88007bb43500 RDI: ffff88004beaa000 [63123.008621] RBP: ffffc90006387ae8 R08: 0000000099100000 R09: ffff8800b2bd5600 [63123.008840] R10: 0000000000000004 R11: 0000000000010000 R12: ffff88007bb43500 [63123.009059] R13: 00000000fffffffb R14: ffff880036fc5180 R15: 0000000000000004 [63123.009278] FS: 0000000000000000(0000) GS:ffff8800b7000000(0000) knlGS:0000000000000000 [63123.009564] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [63123.009748] CR2: 0000000000000080 CR3: 00000000b0866000 CR4: 00000000000406f0 [63123.009969] Call Trace: [63123.010085] raid_write_end_io+0x7e/0x80 [btrfs] [63123.010251] bio_endio+0xa1/0x120 [63123.010378] generic_make_request+0x218/0x270 [63123.010921] submit_bio+0x66/0x130 [63123.011073] finish_rmw+0x3fc/0x5b0 [btrfs] [63123.011245] full_stripe_write+0x96/0xc0 [btrfs] [63123.011428] raid56_parity_write+0x117/0x170 [btrfs] [63123.011604] btrfs_map_bio+0x2ec/0x320 [btrfs] [63123.011759] ? ___cache_free+0x1c5/0x300 [63123.011909] __btrfs_submit_bio_done+0x26/0x50 [btrfs] [63123.012087] run_one_async_done+0x9c/0xc0 [btrfs] [63123.012257] normal_work_helper+0x19e/0x300 [btrfs] [63123.012429] btrfs_worker_helper+0x12/0x20 [btrfs] [63123.012656] process_one_work+0x14d/0x350 [63123.012888] worker_thread+0x4d/0x3a0 [63123.013026] ? _raw_spin_unlock_irqrestore+0x15/0x20 [63123.013192] kthread+0x109/0x140 [63123.013315] ? process_scheduled_works+0x40/0x40 [63123.013472] ? kthread_stop+0x110/0x110 [63123.013610] ret_from_fork+0x25/0x30 [63123.014469] RIP: fail_bio_stripe+0x58/0xa0 [btrfs] RSP: ffffc90006387ad8 [63123.014678] CR2: 0000000000000080 [63123.016590] ---[ end trace a295ea7259c17880 ]— This is reproducible in a cycle, where a series of writes is followed by SCSI device delete command. The test may take up to few minutes. Fixes: 74d46992e0d9 ("block: replace bi_bdev with a gendisk pointer and partitions index") [ no signed-off-by provided ] Author: Dmitriy Gorokh <Dmitriy.Gorokh(a)wdc.com> Reviewed-by: Liu Bo <bo.li.liu(a)oracle.com> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/raid56.c | 1 + 1 file changed, 1 insertion(+) --- a/fs/btrfs/raid56.c +++ b/fs/btrfs/raid56.c @@ -1348,6 +1348,7 @@ static int find_bio_stripe(struct btrfs_ stripe_start = stripe->physical; if (physical >= stripe_start && physical < stripe_start + rbio->stripe_len && + stripe->dev->bdev && bio->bi_disk == stripe->dev->bdev->bd_disk && bio->bi_partno == stripe->dev->bdev->bd_partno) { return i; Patches currently in stable-queue which might be from Dmitriy.Gorokh(a)wdc.com are queue-4.14/btrfs-fix-null-pointer-exception-in-find_bio_stripe.patch

7 years, 1 month

1
0
0 0

Patch "btrfs: Fix memory barriers usage with device stats counters" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled btrfs: Fix memory barriers usage with device stats counters to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-fix-memory-barriers-usage-with-device-stats-counters.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 9deae9689231964972a94bb56a79b669f9d47ac1 Mon Sep 17 00:00:00 2001 From: Nikolay Borisov <nborisov(a)suse.com> Date: Tue, 24 Oct 2017 13:47:37 +0300 Subject: btrfs: Fix memory barriers usage with device stats counters From: Nikolay Borisov <nborisov(a)suse.com> commit 9deae9689231964972a94bb56a79b669f9d47ac1 upstream. Commit addc3fa74e5b ("Btrfs: Fix the problem that the dirty flag of dev stats is cleared") reworked the way device stats changes are tracked. A new atomic dev_stats_ccnt counter was introduced which is incremented every time any of the device stats counters are changed. This serves as a flag whether there are any pending stats changes. However, this patch only partially implemented the correct memory barriers necessary: - It only ordered the stores to the counters but not the reads e.g. btrfs_run_dev_stats - It completely omitted any comments documenting the intended design and how the memory barriers pair with each-other This patch provides the necessary comments as well as adds a missing smp_rmb in btrfs_run_dev_stats. Furthermore since dev_stats_cnt is only a snapshot at best there was no point in reading the counter twice - once in btrfs_dev_stats_dirty and then again when assigning stats_cnt. Just collapse both reads into 1. Fixes: addc3fa74e5b ("Btrfs: Fix the problem that the dirty flag of dev stats is cleared") Signed-off-by: Nikolay Borisov <nborisov(a)suse.com> Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> Reviewed-by: David Sterba <dsterba(a)suse.com> Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/volumes.c | 18 ++++++++++++++++-- fs/btrfs/volumes.h | 12 ++++++++++++ 2 files changed, 28 insertions(+), 2 deletions(-) --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -7082,10 +7082,24 @@ int btrfs_run_dev_stats(struct btrfs_tra mutex_lock(&fs_devices->device_list_mutex); list_for_each_entry(device, &fs_devices->devices, dev_list) { - if (!device->dev_stats_valid || !btrfs_dev_stats_dirty(device)) + stats_cnt = atomic_read(&device->dev_stats_ccnt); + if (!device->dev_stats_valid || stats_cnt == 0) continue; - stats_cnt = atomic_read(&device->dev_stats_ccnt); + + /* + * There is a LOAD-LOAD control dependency between the value of + * dev_stats_ccnt and updating the on-disk values which requires + * reading the in-memory counters. Such control dependencies + * require explicit read memory barriers. + * + * This memory barriers pairs with smp_mb__before_atomic in + * btrfs_dev_stat_inc/btrfs_dev_stat_set and with the full + * barrier implied by atomic_xchg in + * btrfs_dev_stats_read_and_reset + */ + smp_rmb(); + ret = update_dev_stat_item(trans, fs_info, device); if (!ret) atomic_sub(stats_cnt, &device->dev_stats_ccnt); --- a/fs/btrfs/volumes.h +++ b/fs/btrfs/volumes.h @@ -498,6 +498,12 @@ static inline void btrfs_dev_stat_inc(st int index) { atomic_inc(dev->dev_stat_values + index); + /* + * This memory barrier orders stores updating statistics before stores + * updating dev_stats_ccnt. + * + * It pairs with smp_rmb() in btrfs_run_dev_stats(). + */ smp_mb__before_atomic(); atomic_inc(&dev->dev_stats_ccnt); } @@ -523,6 +529,12 @@ static inline void btrfs_dev_stat_set(st int index, unsigned long val) { atomic_set(dev->dev_stat_values + index, val); + /* + * This memory barrier orders stores updating statistics before stores + * updating dev_stats_ccnt. + * + * It pairs with smp_rmb() in btrfs_run_dev_stats(). + */ smp_mb__before_atomic(); atomic_inc(&dev->dev_stats_ccnt); } Patches currently in stable-queue which might be from nborisov(a)suse.com are queue-4.14/btrfs-fix-memory-barriers-usage-with-device-stats-counters.patch queue-4.14/btrfs-fix-use-after-free-when-cleaning-up-fs_devs-with-a-single-stale-device.patch

7 years, 1 month

1
0
0 0

Patch "btrfs: alloc_chunk: fix DUP stripe size handling" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled btrfs: alloc_chunk: fix DUP stripe size handling to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-alloc_chunk-fix-dup-stripe-size-handling.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 92e222df7b8f05c565009c7383321b593eca488b Mon Sep 17 00:00:00 2001 From: Hans van Kranenburg <hans.van.kranenburg(a)mendix.com> Date: Mon, 5 Feb 2018 17:45:11 +0100 Subject: btrfs: alloc_chunk: fix DUP stripe size handling From: Hans van Kranenburg <hans.van.kranenburg(a)mendix.com> commit 92e222df7b8f05c565009c7383321b593eca488b upstream. In case of using DUP, we search for enough unallocated disk space on a device to hold two stripes. The devices_info[ndevs-1].max_avail that holds the amount of unallocated space found is directly assigned to stripe_size, while it's actually twice the stripe size. Later on in the code, an unconditional division of stripe_size by dev_stripes corrects the value, but in the meantime there's a check to see if the stripe_size does not exceed max_chunk_size. Since during this check stripe_size is twice the amount as intended, the check will reduce the stripe_size to max_chunk_size if the actual correct to be used stripe_size is more than half the amount of max_chunk_size. The unconditional division later tries to correct stripe_size, but will actually make sure we can't allocate more than half the max_chunk_size. Fix this by moving the division by dev_stripes before the max chunk size check, so it always contains the right value, instead of putting a duct tape division in further on to get it fixed again. Since in all other cases than DUP, dev_stripes is 1, this change only affects DUP. Other attempts in the past were made to fix this: * 37db63a400 "Btrfs: fix max chunk size check in chunk allocator" tried to fix the same problem, but still resulted in part of the code acting on a wrongly doubled stripe_size value. * 86db25785a "Btrfs: fix max chunk size on raid5/6" unintentionally broke this fix again. The real problem was already introduced with the rest of the code in 73c5de0051. The user visible result however will be that the max chunk size for DUP will suddenly double, while it's actually acting according to the limits in the code again like it was 5 years ago. Reported-by: Naohiro Aota <naohiro.aota(a)wdc.com> Link: https://www.spinics.net/lists/linux-btrfs/msg69752.html Fixes: 73c5de0051 ("btrfs: quasi-round-robin for chunk allocation") Fixes: 86db25785a ("Btrfs: fix max chunk size on raid5/6") Signed-off-by: Hans van Kranenburg <hans.van.kranenburg(a)mendix.com> Reviewed-by: David Sterba <dsterba(a)suse.com> [ update comment ] Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/volumes.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -4733,10 +4733,13 @@ static int __btrfs_alloc_chunk(struct bt ndevs = min(ndevs, devs_max); /* - * the primary goal is to maximize the number of stripes, so use as many - * devices as possible, even if the stripes are not maximum sized. + * The primary goal is to maximize the number of stripes, so use as + * many devices as possible, even if the stripes are not maximum sized. + * + * The DUP profile stores more than one stripe per device, the + * max_avail is the total size so we have to adjust. */ - stripe_size = devices_info[ndevs-1].max_avail; + stripe_size = div_u64(devices_info[ndevs - 1].max_avail, dev_stripes); num_stripes = ndevs * dev_stripes; /* @@ -4771,8 +4774,6 @@ static int __btrfs_alloc_chunk(struct bt stripe_size = devices_info[ndevs-1].max_avail; } - stripe_size = div_u64(stripe_size, dev_stripes); - /* align to BTRFS_STRIPE_LEN */ stripe_size = round_down(stripe_size, BTRFS_STRIPE_LEN); Patches currently in stable-queue which might be from hans.van.kranenburg(a)mendix.com are queue-4.14/btrfs-alloc_chunk-fix-dup-stripe-size-handling.patch

7 years, 1 month

1
0
0 0

Patch "btrfs: add missing initialization in btrfs_check_shared" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled btrfs: add missing initialization in btrfs_check_shared to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: btrfs-add-missing-initialization-in-btrfs_check_shared.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 18bf591ba9753e3e5ba91f38f756a800693408f4 Mon Sep 17 00:00:00 2001 From: Edmund Nadolski <enadolski(a)suse.com> Date: Wed, 14 Mar 2018 09:03:11 -0600 Subject: btrfs: add missing initialization in btrfs_check_shared From: Edmund Nadolski <enadolski(a)suse.com> commit 18bf591ba9753e3e5ba91f38f756a800693408f4 upstream. This patch addresses an issue that causes fiemap to falsely report a shared extent. The test case is as follows: xfs_io -f -d -c "pwrite -b 16k 0 64k" -c "fiemap -v" /media/scratch/file5 sync xfs_io -c "fiemap -v" /media/scratch/file5 which gives the resulting output: wrote 65536/65536 bytes at offset 0 64 KiB, 4 ops; 0.0000 sec (121.359 MiB/sec and 7766.9903 ops/sec) /media/scratch/file5: EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS 0: [0..127]: 24576..24703 128 0x2001 /media/scratch/file5: EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS 0: [0..127]: 24576..24703 128 0x1 This is because btrfs_check_shared calls find_parent_nodes repeatedly in a loop, passing a share_check struct to report the count of shared extent. But btrfs_check_shared does not re-initialize the count value to zero for subsequent calls from the loop, resulting in a false share count value. This is a regressive behavior from 4.13. With proper re-initialization the test result is as follows: wrote 65536/65536 bytes at offset 0 64 KiB, 4 ops; 0.0000 sec (110.035 MiB/sec and 7042.2535 ops/sec) /media/scratch/file5: EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS 0: [0..127]: 24576..24703 128 0x1 /media/scratch/file5: EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS 0: [0..127]: 24576..24703 128 0x1 which corrects the regression. Fixes: 3ec4d3238ab ("btrfs: allow backref search checks for shared extents") Signed-off-by: Edmund Nadolski <enadolski(a)suse.com> [ add text from cover letter to changelog ] Signed-off-by: David Sterba <dsterba(a)suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/btrfs/backref.c | 1 + 1 file changed, 1 insertion(+) --- a/fs/btrfs/backref.c +++ b/fs/btrfs/backref.c @@ -1496,6 +1496,7 @@ int btrfs_check_shared(struct btrfs_root if (!node) break; bytenr = node->val; + shared.share_count = 0; cond_resched(); } Patches currently in stable-queue which might be from enadolski(a)suse.com are queue-4.14/btrfs-add-missing-initialization-in-btrfs_check_shared.patch

7 years, 1 month

1
0
0 0

[PATCH AUTOSEL for 4.14 01/97] i40iw: Fix sequence number for the first partial FPDU

by Sasha Levin

From: Shiraz Saleem <shiraz.saleem(a)intel.com> [ Upstream commit df8b13a1b23356d01dfc4647a5629cdb0f4ce566 ] Partial FPDU processing is broken as the sequence number for the first partial FPDU is wrong due to incorrect Q2 buffer offset. The offset should be 64 rather than 16. Fixes: 786c6adb3a94 ("i40iw: add puda code") Signed-off-by: Shiraz Saleem <shiraz.saleem(a)intel.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> --- drivers/infiniband/hw/i40iw/i40iw_d.h | 1 + drivers/infiniband/hw/i40iw/i40iw_puda.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/infiniband/hw/i40iw/i40iw_d.h b/drivers/infiniband/hw/i40iw/i40iw_d.h index 24eabcad5e40..019ad3b939f9 100644 --- a/drivers/infiniband/hw/i40iw/i40iw_d.h +++ b/drivers/infiniband/hw/i40iw/i40iw_d.h @@ -93,6 +93,7 @@ #define RDMA_OPCODE_MASK 0x0f #define RDMA_READ_REQ_OPCODE 1 #define Q2_BAD_FRAME_OFFSET 72 +#define Q2_FPSN_OFFSET 64 #define CQE_MAJOR_DRV 0x8000 #define I40IW_TERM_SENT 0x01 diff --git a/drivers/infiniband/hw/i40iw/i40iw_puda.c b/drivers/infiniband/hw/i40iw/i40iw_puda.c index 59f70676f0e0..14d38d733cb4 100644 --- a/drivers/infiniband/hw/i40iw/i40iw_puda.c +++ b/drivers/infiniband/hw/i40iw/i40iw_puda.c @@ -1376,7 +1376,7 @@ static void i40iw_ieq_handle_exception(struct i40iw_puda_rsrc *ieq, u32 *hw_host_ctx = (u32 *)qp->hw_host_ctx; u32 rcv_wnd = hw_host_ctx[23]; /* first partial seq # in q2 */ - u32 fps = qp->q2_buf[16]; + u32 fps = *(u32 *)(qp->q2_buf + Q2_FPSN_OFFSET); struct list_head *rxlist = &pfpdu->rxlist; struct list_head *plist; -- 2.14.1

7 years, 1 month

1
96
0 0

patch "staging: ncpfs: memory corruption in ncp_read_kernel()" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled staging: ncpfs: memory corruption in ncp_read_kernel() to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 4c41aa24baa4ed338241d05494f2c595c885af8f Mon Sep 17 00:00:00 2001 From: Dan Carpenter <dan.carpenter(a)oracle.com> Date: Mon, 19 Mar 2018 14:07:45 +0300 Subject: staging: ncpfs: memory corruption in ncp_read_kernel() If the server is malicious then *bytes_read could be larger than the size of the "target" buffer. It would lead to memory corruption when we do the memcpy(). Reported-by: Dr Silvio Cesare of InfoSect <Silvio Cesare <silvio.cesare(a)gmail.com> Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/staging/ncpfs/ncplib_kernel.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/staging/ncpfs/ncplib_kernel.c b/drivers/staging/ncpfs/ncplib_kernel.c index 804adfebba2f..3e047eb4cc7c 100644 --- a/drivers/staging/ncpfs/ncplib_kernel.c +++ b/drivers/staging/ncpfs/ncplib_kernel.c @@ -981,6 +981,10 @@ ncp_read_kernel(struct ncp_server *server, const char *file_id, goto out; } *bytes_read = ncp_reply_be16(server, 0); + if (*bytes_read > to_read) { + result = -EINVAL; + goto out; + } source = ncp_reply_data(server, 2 + (offset & 1)); memcpy(target, source, *bytes_read); -- 2.16.2

7 years, 1 month

1
0
0 0

patch "iio: adc: meson-saradc: unlock on error in meson_sar_adc_lock()" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: adc: meson-saradc: unlock on error in meson_sar_adc_lock() to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From 3c3e4b3a708a9d6451052e348981f37d2b3e92b0 Mon Sep 17 00:00:00 2001 From: Dan Carpenter <dan.carpenter(a)oracle.com> Date: Thu, 8 Mar 2018 12:31:53 +0300 Subject: iio: adc: meson-saradc: unlock on error in meson_sar_adc_lock() The meson_sar_adc_lock() function is not supposed to hold the "indio_dev->mlock" on the error path. Fixes: 3adbf3427330 ("iio: adc: add a driver for the SAR ADC found in Amlogic Meson SoCs") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/adc/meson_saradc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/iio/adc/meson_saradc.c b/drivers/iio/adc/meson_saradc.c index 29fa7736d80c..ede955d9b2a4 100644 --- a/drivers/iio/adc/meson_saradc.c +++ b/drivers/iio/adc/meson_saradc.c @@ -462,8 +462,10 @@ static int meson_sar_adc_lock(struct iio_dev *indio_dev) regmap_read(priv->regmap, MESON_SAR_ADC_DELAY, &val); } while (val & MESON_SAR_ADC_DELAY_BL30_BUSY && timeout--); - if (timeout < 0) + if (timeout < 0) { + mutex_unlock(&indio_dev->mlock); return -ETIMEDOUT; + } } return 0; -- 2.16.2

7 years, 1 month

1
0
0 0

patch "iio: chemical: ccs811: Corrected firmware boot/application mode" added to staging-linus

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iio: chemical: ccs811: Corrected firmware boot/application mode to my staging git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git in the staging-linus branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will hopefully also be merged in Linus's tree for the next -rc kernel release. If you have any questions about this process, please let me know. >From b91e146c38b003c899710ede6d05fc824675e386 Mon Sep 17 00:00:00 2001 From: Richard Lai <richard(a)richardman.com> Date: Sat, 17 Feb 2018 16:28:24 +0000 Subject: iio: chemical: ccs811: Corrected firmware boot/application mode transition CCS811 has different I2C register maps in boot and application mode. When CCS811 is in boot mode, register APP_START (0xF4) is used to transit the firmware state from boot to application mode. However, APP_START is not a valid register location when CCS811 is in application mode (refer to "CCS811 Bootloader Register Map" and "CCS811 Application Register Map" in CCS811 datasheet). The driver should not attempt to perform a write to APP_START while CCS811 is in application mode, as this is not a valid or documented register location. When prob function is being called, the driver assumes the CCS811 sensor is in boot mode, and attempts to perform a write to APP_START. Although CCS811 powers-up in boot mode, it may have already been transited to application mode by previous instances, e.g. unload and reload device driver by the system, or explicitly by user. Depending on the system design, CCS811 sensor may be permanently connected to system power source rather than power controlled by GPIO, hence it is possible that the sensor is never power reset, thus the firmware could be in either boot or application mode at any given time when driver prob function is being called. This patch checks the STATUS register before attempting to send a write to APP_START. Only if the firmware is not in application mode and has valid firmware application loaded, then it will continue to start transiting the firmware boot to application mode. Signed-off-by: Richard Lai <richard(a)richardman.com> Cc: <Stable(a)vger.kernel.org> Signed-off-by: Jonathan Cameron <Jonathan.Cameron(a)huawei.com> --- drivers/iio/chemical/ccs811.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/iio/chemical/ccs811.c b/drivers/iio/chemical/ccs811.c index fbe2431f5b81..1ea9f5513b02 100644 --- a/drivers/iio/chemical/ccs811.c +++ b/drivers/iio/chemical/ccs811.c @@ -133,6 +133,9 @@ static int ccs811_start_sensor_application(struct i2c_client *client) if (ret < 0) return ret; + if ((ret & CCS811_STATUS_FW_MODE_APPLICATION)) + return 0; + if ((ret & CCS811_STATUS_APP_VALID_MASK) != CCS811_STATUS_APP_VALID_LOADED) return -EIO; -- 2.16.2

7 years, 1 month

1
0
0 0

[PATCH 1/3] libata: Apply NOLPM quirk to Crucial M500 480 and 960GB SSDs

by Hans de Goede

There have been reports of the Crucial M500 480GB model not working with LPM set to min_power / med_power_with_dipm level. It has not been tested with medium_power, but that typically has no measurable power-savings. Note the reporters Crucial_CT480M500SSD3 has a firmware version of MU03 and there is a MU05 update available, but that update does not mention any LPM fixes in its changelog, so the quirk matches all firmware versions. In my experience the LPM problems with (older) Crucial SSDs seem to be limited to higher capacity versions of the SSDs (different firmware?), so this commit adds a NOLPM quirk for the 480 and 960GB versions of the M500, to avoid LPM causing issues with these SSDs. Cc: stable(a)vger.kernel.org Reported-and-tested-by: Martin Steigerwald <martin(a)lichtvoll.de> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- drivers/ata/libata-core.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index aec609f80c4e..53400ce09818 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -4538,6 +4538,14 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = { ATA_HORKAGE_ZERO_AFTER_TRIM | ATA_HORKAGE_NOLPM, }, + /* 480GB+ M500 SSDs have both queued TRIM and LPM issues */ + { "Crucial_CT480M500*", NULL, ATA_HORKAGE_NO_NCQ_TRIM | + ATA_HORKAGE_ZERO_AFTER_TRIM | + ATA_HORKAGE_NOLPM, }, + { "Crucial_CT960M500*", NULL, ATA_HORKAGE_NO_NCQ_TRIM | + ATA_HORKAGE_ZERO_AFTER_TRIM | + ATA_HORKAGE_NOLPM, }, + /* devices that don't properly handle queued TRIM commands */ { "Micron_M500_*", NULL, ATA_HORKAGE_NO_NCQ_TRIM | ATA_HORKAGE_ZERO_AFTER_TRIM, }, -- 2.14.3

7 years, 1 month

2
3
0 0

[PATCH AUTOSEL for 4.15 01/78] ipmi_si: Fix error handling of platform device

by Sasha Levin

From: Corey Minyard <cminyard(a)mvista.com> [ Upstream commit 174134ac760275457bb0d1560a0dbe6cf8a12ad6 ] Cleanup of platform devices created by the IPMI driver was not being done correctly and could result in a memory leak. So create a local boolean to know how to clean up those platform devices. Reported-by: David Binderman <dcb314(a)hotmail.com> Signed-off-by: Corey Minyard <cminyard(a)mvista.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> --- drivers/char/ipmi/ipmi_si_intf.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/char/ipmi/ipmi_si_intf.c b/drivers/char/ipmi/ipmi_si_intf.c index 71fad747c0c7..7499b0cd8326 100644 --- a/drivers/char/ipmi/ipmi_si_intf.c +++ b/drivers/char/ipmi/ipmi_si_intf.c @@ -2045,6 +2045,7 @@ static int try_smi_init(struct smi_info *new_smi) int rv = 0; int i; char *init_name = NULL; + bool platform_device_registered = false; pr_info(PFX "Trying %s-specified %s state machine at %s address 0x%lx, slave address 0x%x, irq %d\n", ipmi_addr_src_to_str(new_smi->io.addr_source), @@ -2173,6 +2174,7 @@ static int try_smi_init(struct smi_info *new_smi) rv); goto out_err; } + platform_device_registered = true; } dev_set_drvdata(new_smi->io.dev, new_smi); @@ -2279,10 +2281,11 @@ static int try_smi_init(struct smi_info *new_smi) } if (new_smi->pdev) { - platform_device_unregister(new_smi->pdev); + if (platform_device_registered) + platform_device_unregister(new_smi->pdev); + else + platform_device_put(new_smi->pdev); new_smi->pdev = NULL; - } else if (new_smi->pdev) { - platform_device_put(new_smi->pdev); } kfree(init_name); -- 2.14.1

7 years, 1 month

3
80
0 0

[PATCH AUTOSEL for 4.14 01/67] Bluetooth: hci_qca: Avoid setup failure on missing rampatch

by Sasha Levin

From: Loic Poulain <loic.poulain(a)linaro.org> [ Upstream commit ba8f3597900291a93604643017fff66a14546015 ] Assuming that the original code idea was to enable in-band sleeping only if the setup_rome method returns succes and run in 'standard' mode otherwise, we should not return setup_rome return value which makes qca_setup fail if no rampatch/nvm file found. This fixes BT issue on the dragonboard-820C p4 which includes the following QCA controller: hci0: Product:0x00000008 hci0: Patch :0x00000111 hci0: ROM :0x00000302 hci0: SOC :0x00000044 Since there is no rampatch for this controller revision, just make it work as is. Signed-off-by: Loic Poulain <loic.poulain(a)linaro.org> Signed-off-by: Marcel Holtmann <marcel(a)holtmann.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> --- drivers/bluetooth/hci_qca.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/bluetooth/hci_qca.c b/drivers/bluetooth/hci_qca.c index 392f412b4575..c9f0ac083a3e 100644 --- a/drivers/bluetooth/hci_qca.c +++ b/drivers/bluetooth/hci_qca.c @@ -933,6 +933,9 @@ static int qca_setup(struct hci_uart *hu) if (!ret) { set_bit(STATE_IN_BAND_SLEEP_ENABLED, &qca->flags); qca_debugfs_init(hdev); + } else if (ret == -ENOENT) { + /* No patch/nvm-config found, run with original fw/config */ + ret = 0; } /* Setup bdaddr */ -- 2.14.1

7 years, 1 month

3
70
0 0

[PATCH] acpi, numa: fix pxm to online numa node associations

by Dan Williams

Commit 99759869faf1 "acpi: Add acpi_map_pxm_to_online_node()" added support for mapping a given proximity to its nearest, by SLIT distance, online node. However, it sometimes returns unexpected results due to the fact that it switches from comparing the PXM node to the last node that was closer than the current max. for_each_online_node(n) { dist = node_distance(node, n); if (dist < min_dist) { min_dist = dist; node = n; <---- from this point we're using the wrong node for node_distance() Fixes: 99759869faf1 ("acpi: Add acpi_map_pxm_to_online_node()") Cc: <stable(a)vger.kernel.org> Cc: Toshi Kani <toshi.kani(a)hp.com> Cc: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com>> Signed-off-by: Dan Williams <dan.j.williams(a)intel.com> --- Rafael, I can take this through the nvdimm tree with your ack. I have a few other nvdimm fixes pending for 4.16. drivers/acpi/numa.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/acpi/numa.c b/drivers/acpi/numa.c index 8ccaae3550d2..85167603b9c9 100644 --- a/drivers/acpi/numa.c +++ b/drivers/acpi/numa.c @@ -103,25 +103,27 @@ int acpi_map_pxm_to_node(int pxm) */ int acpi_map_pxm_to_online_node(int pxm) { - int node, n, dist, min_dist; + int node, min_node; node = acpi_map_pxm_to_node(pxm); if (node == NUMA_NO_NODE) node = 0; + min_node = node; if (!node_online(node)) { - min_dist = INT_MAX; + int min_dist = INT_MAX, dist, n; + for_each_online_node(n) { dist = node_distance(node, n); if (dist < min_dist) { min_dist = dist; - node = n; + min_node = n; } } } - return node; + return min_node; } EXPORT_SYMBOL(acpi_map_pxm_to_online_node);

7 years, 1 month

3
3
0 0

[PATCH] ARM: dts: LogicPD Torpedo: Fix I2C1 pinmux

by Adam Ford

commit 74402055a2d3ec998a1ded599e86185a27d9bbf4 upstream. The pinmuxing was missing for I2C1 which was causing intermittent issues with the PMIC which is connected to I2C1. The bootloader did not quite configure the I2C1 either, so when running at 2.6MHz, it was generating errors at time. This correctly sets the I2C1 pinmuxing so it can operate at 2.6MHz Fixes: 687c27676151 ("ARM: dts: Add minimal support for LogicPD Torpedo DM3730 devkit") For linux-4.4.y Signed-off-by: Adam Ford <aford173(a)gmail.com> diff --git a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi index 80f6c78..e056704 100644 --- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi +++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi @@ -90,6 +90,8 @@ }; &i2c1 { + pinctrl-names = "default"; + pinctrl-0 = <&i2c1_pins>; clock-frequency = <2600000>; twl: twl@48 { @@ -137,6 +139,12 @@ OMAP3_CORE1_IOPAD(0x218e, PIN_OUTPUT | MUX_MODE4) /* mcbsp1_fsr.gpio_157 */ >; }; + i2c1_pins: pinmux_i2c1_pins { + pinctrl-single,pins = < + OMAP3_CORE1_IOPAD(0x21ba, PIN_INPUT | MUX_MODE0) /* i2c1_scl.i2c1_scl */ + OMAP3_CORE1_IOPAD(0x21bc, PIN_INPUT | MUX_MODE0) /* i2c1_sda.i2c1_sda */ + >; + }; }; &omap3_pmx_core2 { -- 2.7.4

7 years, 1 month

2
1
0 0

Re: [PATCH v2] xfs: preserve i_rdev when recycling a reclaimable inode

by Amir Goldstein

On Tue, Mar 13, 2018 at 11:50 PM, Dave Chinner <david(a)fromorbit.com> wrote: > On Tue, Mar 13, 2018 at 04:33:15PM +0200, Amir Goldstein wrote: >> On Tue, Mar 13, 2018 at 3:11 PM, Christoph Hellwig <hch(a)lst.de> wrote: >> > On Tue, Mar 13, 2018 at 02:46:09PM +0200, Amir Goldstein wrote: >> >> OK, found the patches the fix soft lockups in generic/269 and >> >> assertion in generic/232, so expunging those 2 tests from v4.15.y >> >> test runs. >> > >> > Which patches are those? We should probably backport them to 4.15-stable. >> >> Probably, but I guess Darrick has those in his TODO. >> >> There is this series that refers to failure in generic/232: >> https://marc.info/?l=linux-xfs&m=151701545720824&w=2 >> >> These 2 commits refer to generic/269 specifically in commit message: >> 70c57dcd606f xfs: skip CoW writes past EOF when writeback races with truncate >> be78ff0e7277 xfs: recheck reflink / dirty page status before freeing >> CoW reservations >> and the thread on the second commit also mentions generic/270 >> (I found out the hard way that it also soft locks). >> >> But there are surely more patches for stable in master. >> I recon CC: stable and/or Fixes: tags could have been helpful, >> but I don't see any of those in v4.16-rcX from the core xfs developers. > > AS I always say: if you want to maintain a stable backport kernel > with all the fixes that go into the bleeding edge, you're more than > welcome to do it. > > Everyone else is flat out just keeping up with on going development > and fixing bugs in the kernel as it's moving forward. So if you have > the need for stable backports, please keep backporting patches you > need, testing them and asking the stable maintainers to include > them. > Greg, I tested the patch in question per Darrick's request. I found no regressions with full "auto" run on xfs with reflinks enabled. Please include this patch in stable 4.15. Dave, It is often the case, though maybe not always, that the author of a patch has the knowledge of the 'Fixes' commit and/or the stable kernel version patch is relevant to or would easily apply to. It is therefore a relatively low effort for a developer to include this information as courtesy to stable maintainers, whether they are maintaining kernel.org stable kernels or distro stable kernels. That's just my opinion. Christoph/Darrick, FYI, with stable kernel 4.15.y, I found the following failures with -g auto: Assert (mostly on quota related): generic/232 xfs/222 xfs/305 xfs/440 xfs/442 Soft lockup (likely fixed by be78ff0e7277): generic/269 generic/270 xfs/442 Failures (output mismatch): xfs/170 xfs/191-input-validation xfs/348 Thanks, Amir.

7 years, 1 month

5
8
0 0

Patch "xfs: preserve i_rdev when recycling a reclaimable inode" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled xfs: preserve i_rdev when recycling a reclaimable inode to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: xfs-preserve-i_rdev-when-recycling-a-reclaimable-inode.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From acd1d71598f7654b6d7718bcbe979992295c672a Mon Sep 17 00:00:00 2001 From: Amir Goldstein <amir73il(a)gmail.com> Date: Fri, 26 Jan 2018 11:24:40 -0800 Subject: xfs: preserve i_rdev when recycling a reclaimable inode From: Amir Goldstein <amir73il(a)gmail.com> commit acd1d71598f7654b6d7718bcbe979992295c672a upstream. Commit 66f364649d870 ("xfs: remove if_rdev") moved storing of rdev value for special inodes to VFS inodes, but forgot to preserve the value of i_rdev when recycling a reclaimable xfs_inode. This was detected by xfstest overlay/017 with inodex=on mount option and xfs base fs. The test does a lookup of overlay chardev and blockdev right after drop caches. Overlayfs inodes hold a reference on underlying xfs inodes when mount option index=on is configured. If drop caches reclaim xfs inodes, before it relclaims overlayfs inodes, that can sometimes leave a reclaimable xfs inode and that test hits that case quite often. When that happens, the xfs inode cache remains broken (zere i_rdev) until the next cycle mount or drop caches. Fixes: 66f364649d870 ("xfs: remove if_rdev") Signed-off-by: Amir Goldstein <amir73il(a)gmail.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Darrick J. Wong <darrick.wong(a)oracle.com> Signed-off-by: Darrick J. Wong <darrick.wong(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/xfs/xfs_icache.c | 2 ++ 1 file changed, 2 insertions(+) --- a/fs/xfs/xfs_icache.c +++ b/fs/xfs/xfs_icache.c @@ -295,6 +295,7 @@ xfs_reinit_inode( uint32_t generation = inode->i_generation; uint64_t version = inode->i_version; umode_t mode = inode->i_mode; + dev_t dev = inode->i_rdev; error = inode_init_always(mp->m_super, inode); @@ -302,6 +303,7 @@ xfs_reinit_inode( inode->i_generation = generation; inode->i_version = version; inode->i_mode = mode; + inode->i_rdev = dev; return error; } Patches currently in stable-queue which might be from amir73il(a)gmail.com are queue-4.15/xfs-preserve-i_rdev-when-recycling-a-reclaimable-inode.patch

7 years, 1 month

1
0
0 0

Patch "scsi: sg: only check for dxfer_len greater than 256M" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: sg: only check for dxfer_len greater than 256M to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From f930c7043663188429cd9b254e9d761edfc101ce Mon Sep 17 00:00:00 2001 From: Johannes Thumshirn <jthumshirn(a)suse.de> Date: Thu, 27 Jul 2017 09:11:26 +0200 Subject: scsi: sg: only check for dxfer_len greater than 256M From: Johannes Thumshirn <jthumshirn(a)suse.de> commit f930c7043663188429cd9b254e9d761edfc101ce upstream. Don't make any assumptions on the sg_io_hdr_t::dxfer_direction or the sg_io_hdr_t::dxferp in order to determine if it is a valid request. The only way we can check for bad requests is by checking if the length exceeds 256M. Signed-off-by: Johannes Thumshirn <jthumshirn(a)suse.de> Fixes: 28676d869bbb (scsi: sg: check for valid direction before starting the request) Reported-by: Jason L Tibbitts III <tibbs(a)math.uh.edu> Tested-by: Jason L Tibbitts III <tibbs(a)math.uh.edu> Suggested-by: Doug Gilbert <dgilbert(a)interlog.com> Cc: Doug Gilbert <dgilbert(a)interlog.com> Cc: <stable(a)vger.kernel.org> Reviewed-by: Hannes Reinecke <hare(a)suse.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/sg.c | 31 +------------------------------ 1 file changed, 1 insertion(+), 30 deletions(-) --- a/drivers/scsi/sg.c +++ b/drivers/scsi/sg.c @@ -751,35 +751,6 @@ sg_new_write(Sg_fd *sfp, struct file *fi return count; } -static bool sg_is_valid_dxfer(sg_io_hdr_t *hp) -{ - switch (hp->dxfer_direction) { - case SG_DXFER_NONE: - if (hp->dxferp || hp->dxfer_len > 0) - return false; - return true; - case SG_DXFER_FROM_DEV: - /* - * for SG_DXFER_FROM_DEV we always set dxfer_len to > 0. dxferp - * can either be NULL or != NULL so there's no point in checking - * it either. So just return true. - */ - return true; - case SG_DXFER_TO_DEV: - case SG_DXFER_TO_FROM_DEV: - if (!hp->dxferp || hp->dxfer_len == 0) - return false; - return true; - case SG_DXFER_UNKNOWN: - if ((!hp->dxferp && hp->dxfer_len) || - (hp->dxferp && hp->dxfer_len == 0)) - return false; - return true; - default: - return false; - } -} - static int sg_common_write(Sg_fd * sfp, Sg_request * srp, unsigned char *cmnd, int timeout, int blocking) @@ -800,7 +771,7 @@ sg_common_write(Sg_fd * sfp, Sg_request "sg_common_write: scsi opcode=0x%02x, cmd_size=%d\n", (int) cmnd[0], (int) hp->cmd_len)); - if (!sg_is_valid_dxfer(hp)) + if (hp->dxfer_len >= SZ_256M) return -EINVAL; k = sg_start_req(srp, cmnd); Patches currently in stable-queue which might be from jthumshirn(a)suse.de are queue-4.9/scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch queue-4.9/scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch queue-4.9/scsi-sg-check-for-valid-direction-before-starting-the-request.patch queue-4.9/scsi-sg-close-race-condition-in-sg_remove_sfp_usercontext.patch queue-4.9/scsi-sg-fix-sg_dxfer_from_dev-transfers.patch queue-4.9/scsi-core-scsi_get_device_flags_keyed-always-return-device-flags.patch

7 years, 1 month

1
0
0 0

Patch "scsi: sg: fix static checker warning in sg_is_valid_dxfer" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: sg: fix static checker warning in sg_is_valid_dxfer to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 14074aba4bcda3764c9a702b276308b89901d5b6 Mon Sep 17 00:00:00 2001 From: Johannes Thumshirn <jthumshirn(a)suse.de> Date: Mon, 17 Jul 2017 15:11:42 +0200 Subject: scsi: sg: fix static checker warning in sg_is_valid_dxfer From: Johannes Thumshirn <jthumshirn(a)suse.de> commit 14074aba4bcda3764c9a702b276308b89901d5b6 upstream. dxfer_len is an unsigned int and we always assign a value > 0 to it, so it doesn't make any sense to check if it is < 0. We can't really check dxferp as well as we have both NULL and not NULL cases in the possible call paths. So just return true for SG_DXFER_FROM_DEV transfer in sg_is_valid_dxfer(). Signed-off-by: Johannes Thumshirn <jthumshirn(a)suse.de> Reported-by: Colin Ian King <colin.king(a)canonical.com> Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com> Cc: Douglas Gilbert <dgilbert(a)interlog.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/sg.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/drivers/scsi/sg.c +++ b/drivers/scsi/sg.c @@ -759,8 +759,11 @@ static bool sg_is_valid_dxfer(sg_io_hdr_ return false; return true; case SG_DXFER_FROM_DEV: - if (hp->dxfer_len < 0) - return false; + /* + * for SG_DXFER_FROM_DEV we always set dxfer_len to > 0. dxferp + * can either be NULL or != NULL so there's no point in checking + * it either. So just return true. + */ return true; case SG_DXFER_TO_DEV: case SG_DXFER_TO_FROM_DEV: Patches currently in stable-queue which might be from jthumshirn(a)suse.de are queue-4.9/scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch queue-4.9/scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch queue-4.9/scsi-sg-check-for-valid-direction-before-starting-the-request.patch queue-4.9/scsi-sg-close-race-condition-in-sg_remove_sfp_usercontext.patch queue-4.9/scsi-sg-fix-sg_dxfer_from_dev-transfers.patch queue-4.9/scsi-core-scsi_get_device_flags_keyed-always-return-device-flags.patch

7 years, 1 month

1
0
0 0

Patch "scsi: sg: fix SG_DXFER_FROM_DEV transfers" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: sg: fix SG_DXFER_FROM_DEV transfers to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-sg-fix-sg_dxfer_from_dev-transfers.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 68c59fcea1f2c6a54c62aa896cc623c1b5bc9b47 Mon Sep 17 00:00:00 2001 From: Johannes Thumshirn <jthumshirn(a)suse.de> Date: Fri, 7 Jul 2017 10:56:38 +0200 Subject: scsi: sg: fix SG_DXFER_FROM_DEV transfers From: Johannes Thumshirn <jthumshirn(a)suse.de> commit 68c59fcea1f2c6a54c62aa896cc623c1b5bc9b47 upstream. SG_DXFER_FROM_DEV transfers do not necessarily have a dxferp as we set it to NULL for the old sg_io read/write interface, but must have a length bigger than 0. This fixes a regression introduced by commit 28676d869bbb ("scsi: sg: check for valid direction before starting the request") Signed-off-by: Johannes Thumshirn <jthumshirn(a)suse.de> Fixes: 28676d869bbb ("scsi: sg: check for valid direction before starting the request") Reported-by: Chris Clayton <chris2553(a)googlemail.com> Tested-by: Chris Clayton <chris2553(a)googlemail.com> Cc: Douglas Gilbert <dgilbert(a)interlog.com> Reviewed-by: Hannes Reinecke <hare(a)suse.com> Tested-by: Chris Clayton <chris2553(a)googlemail.com> Acked-by: Douglas Gilbert <dgilbert(a)interlog.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Cc: Cristian Crinteanu <crinteanu.cristian(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/sg.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/scsi/sg.c +++ b/drivers/scsi/sg.c @@ -758,8 +758,11 @@ static bool sg_is_valid_dxfer(sg_io_hdr_ if (hp->dxferp || hp->dxfer_len > 0) return false; return true; - case SG_DXFER_TO_DEV: case SG_DXFER_FROM_DEV: + if (hp->dxfer_len < 0) + return false; + return true; + case SG_DXFER_TO_DEV: case SG_DXFER_TO_FROM_DEV: if (!hp->dxferp || hp->dxfer_len == 0) return false; Patches currently in stable-queue which might be from jthumshirn(a)suse.de are queue-4.9/scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch queue-4.9/scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch queue-4.9/scsi-sg-check-for-valid-direction-before-starting-the-request.patch queue-4.9/scsi-sg-close-race-condition-in-sg_remove_sfp_usercontext.patch queue-4.9/scsi-sg-fix-sg_dxfer_from_dev-transfers.patch queue-4.9/scsi-core-scsi_get_device_flags_keyed-always-return-device-flags.patch

7 years, 1 month

1
0
0 0

Patch "irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: irqchip-gic-v3-its-ensure-nr_ites-nr_lpis.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 4f2c7583e33eb08dc09dd2e25574b80175ba7d93 Mon Sep 17 00:00:00 2001 From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Date: Tue, 6 Mar 2018 15:51:32 +0000 Subject: irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> commit 4f2c7583e33eb08dc09dd2e25574b80175ba7d93 upstream. When struct its_device instances are created, the nr_ites member will be set to a power of 2 that equals or exceeds the requested number of MSIs passed to the msi_prepare() callback. At the same time, the LPI map is allocated to be some multiple of 32 in size, where the allocated size may be less than the requested size depending on whether a contiguous range of sufficient size is available in the global LPI bitmap. This may result in the situation where the nr_ites < nr_lpis, and since nr_ites is what we program into the hardware when we map the device, the additional LPIs will be non-functional. For bog standard hardware, this does not really matter. However, in cases where ITS device IDs are shared between different PCIe devices, we may end up allocating these additional LPIs without taking into account that they don't actually work. So let's make nr_ites at least 32. This ensures that all allocated LPIs are 'live', and that its_alloc_device_irq() will fail when attempts are made to allocate MSIs beyond what was allocated in the first place. Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> [maz: updated comment] Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> [ardb: trivial tweak of unrelated context] Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/irqchip/irq-gic-v3-its.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -684,7 +684,7 @@ static struct irq_chip its_irq_chip = { * This gives us (((1UL << id_bits) - 8192) >> 5) possible allocations. */ #define IRQS_PER_CHUNK_SHIFT 5 -#define IRQS_PER_CHUNK (1 << IRQS_PER_CHUNK_SHIFT) +#define IRQS_PER_CHUNK (1UL << IRQS_PER_CHUNK_SHIFT) static unsigned long *lpi_bitmap; static u32 lpi_chunks; @@ -1320,11 +1320,10 @@ static struct its_device *its_create_dev dev = kzalloc(sizeof(*dev), GFP_KERNEL); /* - * At least one bit of EventID is being used, hence a minimum - * of two entries. No, the architecture doesn't let you - * express an ITT with a single entry. + * We allocate at least one chunk worth of LPIs bet device, + * and thus that many ITEs. The device may require less though. */ - nr_ites = max(2UL, roundup_pow_of_two(nvecs)); + nr_ites = max(IRQS_PER_CHUNK, roundup_pow_of_two(nvecs)); sz = nr_ites * its->ite_size; sz = max(sz, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1; itt = kzalloc(sz, GFP_KERNEL); Patches currently in stable-queue which might be from ard.biesheuvel(a)linaro.org are queue-4.9/x86-boot-32-defer-resyncing-initial_page_table-until-per-cpu-is-set-up.patch queue-4.9/x86-boot-32-fix-up-boot-on-quark-and-possibly-other-platforms.patch queue-4.9/irqchip-gic-v3-its-ensure-nr_ites-nr_lpis.patch

7 years, 1 month

1
0
0 0

Patch "nvme: fix subsystem multiple controllers support check" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled nvme: fix subsystem multiple controllers support check to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: nvme-fix-subsystem-multiple-controllers-support-check.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From b837b28394fb76993c28bb242db7061ee0417da6 Mon Sep 17 00:00:00 2001 From: Israel Rukshin <israelr(a)mellanox.com> Date: Thu, 4 Jan 2018 17:56:14 +0200 Subject: nvme: fix subsystem multiple controllers support check From: Israel Rukshin <israelr(a)mellanox.com> commit b837b28394fb76993c28bb242db7061ee0417da6 upstream. There is a problem when another module (e.g. nvmet) takes a reference on the nvme block device and the physical nvme drive is removed. In that case nvme_free_ctrl() will not be called and the controller state will be "deleting" or "dead" unless nvmet module releases the block device. Later on, the same nvme drive probes back and nvme_init_subsystem() will be called and fail due to duplicate subnqn (if the nvme device doesn't support subsystem with multiple controllers). This will cause a probe failure. This commit changes the check of multiple controllers support at nvme_init_subsystem() by not counting all the controllers at "dead" or "deleting" state (this is safe because controllers at this state will never be active again). Fixes: ab9e00cc72fa ("nvme: track subsystems") Reviewed-by: Max Gurtovoy <maxg(a)mellanox.com> Signed-off-by: Israel Rukshin <israelr(a)mellanox.com> Signed-off-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Keith Busch <keith.busch(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/nvme/host/core.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) --- a/drivers/nvme/host/core.c +++ b/drivers/nvme/host/core.c @@ -2052,6 +2052,22 @@ static const struct attribute_group *nvm NULL, }; +static int nvme_active_ctrls(struct nvme_subsystem *subsys) +{ + int count = 0; + struct nvme_ctrl *ctrl; + + mutex_lock(&subsys->lock); + list_for_each_entry(ctrl, &subsys->ctrls, subsys_entry) { + if (ctrl->state != NVME_CTRL_DELETING && + ctrl->state != NVME_CTRL_DEAD) + count++; + } + mutex_unlock(&subsys->lock); + + return count; +} + static int nvme_init_subsystem(struct nvme_ctrl *ctrl, struct nvme_id_ctrl *id) { struct nvme_subsystem *subsys, *found; @@ -2090,7 +2106,7 @@ static int nvme_init_subsystem(struct nv * Verify that the subsystem actually supports multiple * controllers, else bail out. */ - if (!(id->cmic & (1 << 1))) { + if (nvme_active_ctrls(found) && !(id->cmic & (1 << 1))) { dev_err(ctrl->device, "ignoring ctrl due to duplicate subnqn (%s).\n", found->subnqn); Patches currently in stable-queue which might be from israelr(a)mellanox.com are queue-4.15/nvme-fix-subsystem-multiple-controllers-support-check.patch

7 years, 1 month

1
0
0 0

Patch "irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: irqchip-gic-v3-its-ensure-nr_ites-nr_lpis.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 4f2c7583e33eb08dc09dd2e25574b80175ba7d93 Mon Sep 17 00:00:00 2001 From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Date: Tue, 6 Mar 2018 15:51:32 +0000 Subject: irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> commit 4f2c7583e33eb08dc09dd2e25574b80175ba7d93 upstream. When struct its_device instances are created, the nr_ites member will be set to a power of 2 that equals or exceeds the requested number of MSIs passed to the msi_prepare() callback. At the same time, the LPI map is allocated to be some multiple of 32 in size, where the allocated size may be less than the requested size depending on whether a contiguous range of sufficient size is available in the global LPI bitmap. This may result in the situation where the nr_ites < nr_lpis, and since nr_ites is what we program into the hardware when we map the device, the additional LPIs will be non-functional. For bog standard hardware, this does not really matter. However, in cases where ITS device IDs are shared between different PCIe devices, we may end up allocating these additional LPIs without taking into account that they don't actually work. So let's make nr_ites at least 32. This ensures that all allocated LPIs are 'live', and that its_alloc_device_irq() will fail when attempts are made to allocate MSIs beyond what was allocated in the first place. Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> [maz: updated comment] Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/irqchip/irq-gic-v3-its.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -1412,7 +1412,7 @@ static struct irq_chip its_irq_chip = { * This gives us (((1UL << id_bits) - 8192) >> 5) possible allocations. */ #define IRQS_PER_CHUNK_SHIFT 5 -#define IRQS_PER_CHUNK (1 << IRQS_PER_CHUNK_SHIFT) +#define IRQS_PER_CHUNK (1UL << IRQS_PER_CHUNK_SHIFT) #define ITS_MAX_LPI_NRBITS 16 /* 64K LPIs */ static unsigned long *lpi_bitmap; @@ -2119,11 +2119,10 @@ static struct its_device *its_create_dev dev = kzalloc(sizeof(*dev), GFP_KERNEL); /* - * At least one bit of EventID is being used, hence a minimum - * of two entries. No, the architecture doesn't let you - * express an ITT with a single entry. + * We allocate at least one chunk worth of LPIs bet device, + * and thus that many ITEs. The device may require less though. */ - nr_ites = max(2UL, roundup_pow_of_two(nvecs)); + nr_ites = max(IRQS_PER_CHUNK, roundup_pow_of_two(nvecs)); sz = nr_ites * its->ite_size; sz = max(sz, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1; itt = kzalloc(sz, GFP_KERNEL); Patches currently in stable-queue which might be from ard.biesheuvel(a)linaro.org are queue-4.15/kvm-arm-arm64-reduce-verbosity-of-kvm-init-log.patch queue-4.15/irqchip-gic-v3-its-ensure-nr_ites-nr_lpis.patch

7 years, 1 month

1
0
0 0

Patch "irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis" has been added to the 4.14-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis to the 4.14-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: irqchip-gic-v3-its-ensure-nr_ites-nr_lpis.patch and it can be found in the queue-4.14 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 4f2c7583e33eb08dc09dd2e25574b80175ba7d93 Mon Sep 17 00:00:00 2001 From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Date: Tue, 6 Mar 2018 15:51:32 +0000 Subject: irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> commit 4f2c7583e33eb08dc09dd2e25574b80175ba7d93 upstream. When struct its_device instances are created, the nr_ites member will be set to a power of 2 that equals or exceeds the requested number of MSIs passed to the msi_prepare() callback. At the same time, the LPI map is allocated to be some multiple of 32 in size, where the allocated size may be less than the requested size depending on whether a contiguous range of sufficient size is available in the global LPI bitmap. This may result in the situation where the nr_ites < nr_lpis, and since nr_ites is what we program into the hardware when we map the device, the additional LPIs will be non-functional. For bog standard hardware, this does not really matter. However, in cases where ITS device IDs are shared between different PCIe devices, we may end up allocating these additional LPIs without taking into account that they don't actually work. So let's make nr_ites at least 32. This ensures that all allocated LPIs are 'live', and that its_alloc_device_irq() will fail when attempts are made to allocate MSIs beyond what was allocated in the first place. Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> [maz: updated comment] Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/irqchip/irq-gic-v3-its.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -1310,7 +1310,7 @@ static struct irq_chip its_irq_chip = { * This gives us (((1UL << id_bits) - 8192) >> 5) possible allocations. */ #define IRQS_PER_CHUNK_SHIFT 5 -#define IRQS_PER_CHUNK (1 << IRQS_PER_CHUNK_SHIFT) +#define IRQS_PER_CHUNK (1UL << IRQS_PER_CHUNK_SHIFT) #define ITS_MAX_LPI_NRBITS 16 /* 64K LPIs */ static unsigned long *lpi_bitmap; @@ -2026,11 +2026,10 @@ static struct its_device *its_create_dev dev = kzalloc(sizeof(*dev), GFP_KERNEL); /* - * At least one bit of EventID is being used, hence a minimum - * of two entries. No, the architecture doesn't let you - * express an ITT with a single entry. + * We allocate at least one chunk worth of LPIs bet device, + * and thus that many ITEs. The device may require less though. */ - nr_ites = max(2UL, roundup_pow_of_two(nvecs)); + nr_ites = max(IRQS_PER_CHUNK, roundup_pow_of_two(nvecs)); sz = nr_ites * its->ite_size; sz = max(sz, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1; itt = kzalloc(sz, GFP_KERNEL); Patches currently in stable-queue which might be from ard.biesheuvel(a)linaro.org are queue-4.14/kvm-arm-arm64-reduce-verbosity-of-kvm-init-log.patch queue-4.14/irqchip-gic-v3-its-ensure-nr_ites-nr_lpis.patch

7 years, 1 month

1
0
0 0

Patch "scsi: sg: only check for dxfer_len greater than 256M" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: sg: only check for dxfer_len greater than 256M to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From f930c7043663188429cd9b254e9d761edfc101ce Mon Sep 17 00:00:00 2001 From: Johannes Thumshirn <jthumshirn(a)suse.de> Date: Thu, 27 Jul 2017 09:11:26 +0200 Subject: scsi: sg: only check for dxfer_len greater than 256M From: Johannes Thumshirn <jthumshirn(a)suse.de> commit f930c7043663188429cd9b254e9d761edfc101ce upstream. Don't make any assumptions on the sg_io_hdr_t::dxfer_direction or the sg_io_hdr_t::dxferp in order to determine if it is a valid request. The only way we can check for bad requests is by checking if the length exceeds 256M. Signed-off-by: Johannes Thumshirn <jthumshirn(a)suse.de> Fixes: 28676d869bbb (scsi: sg: check for valid direction before starting the request) Reported-by: Jason L Tibbitts III <tibbs(a)math.uh.edu> Tested-by: Jason L Tibbitts III <tibbs(a)math.uh.edu> Suggested-by: Doug Gilbert <dgilbert(a)interlog.com> Cc: Doug Gilbert <dgilbert(a)interlog.com> Cc: <stable(a)vger.kernel.org> Reviewed-by: Hannes Reinecke <hare(a)suse.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/sg.c | 31 +------------------------------ 1 file changed, 1 insertion(+), 30 deletions(-) --- a/drivers/scsi/sg.c +++ b/drivers/scsi/sg.c @@ -762,35 +762,6 @@ sg_new_write(Sg_fd *sfp, struct file *fi return count; } -static bool sg_is_valid_dxfer(sg_io_hdr_t *hp) -{ - switch (hp->dxfer_direction) { - case SG_DXFER_NONE: - if (hp->dxferp || hp->dxfer_len > 0) - return false; - return true; - case SG_DXFER_FROM_DEV: - /* - * for SG_DXFER_FROM_DEV we always set dxfer_len to > 0. dxferp - * can either be NULL or != NULL so there's no point in checking - * it either. So just return true. - */ - return true; - case SG_DXFER_TO_DEV: - case SG_DXFER_TO_FROM_DEV: - if (!hp->dxferp || hp->dxfer_len == 0) - return false; - return true; - case SG_DXFER_UNKNOWN: - if ((!hp->dxferp && hp->dxfer_len) || - (hp->dxferp && hp->dxfer_len == 0)) - return false; - return true; - default: - return false; - } -} - static int sg_common_write(Sg_fd * sfp, Sg_request * srp, unsigned char *cmnd, int timeout, int blocking) @@ -811,7 +782,7 @@ sg_common_write(Sg_fd * sfp, Sg_request "sg_common_write: scsi opcode=0x%02x, cmd_size=%d\n", (int) cmnd[0], (int) hp->cmd_len)); - if (!sg_is_valid_dxfer(hp)) + if (hp->dxfer_len >= SZ_256M) return -EINVAL; k = sg_start_req(srp, cmnd); Patches currently in stable-queue which might be from jthumshirn(a)suse.de are queue-4.4/scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch queue-4.4/scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch queue-4.4/scsi-sg-check-for-valid-direction-before-starting-the-request.patch queue-4.4/scsi-sg-close-race-condition-in-sg_remove_sfp_usercontext.patch queue-4.4/scsi-sg-fix-sg_dxfer_from_dev-transfers.patch queue-4.4/scsi-core-scsi_get_device_flags_keyed-always-return-device-flags.patch

7 years, 1 month

1
0
0 0

Patch "scsi: sg: fix static checker warning in sg_is_valid_dxfer" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: sg: fix static checker warning in sg_is_valid_dxfer to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 14074aba4bcda3764c9a702b276308b89901d5b6 Mon Sep 17 00:00:00 2001 From: Johannes Thumshirn <jthumshirn(a)suse.de> Date: Mon, 17 Jul 2017 15:11:42 +0200 Subject: scsi: sg: fix static checker warning in sg_is_valid_dxfer From: Johannes Thumshirn <jthumshirn(a)suse.de> commit 14074aba4bcda3764c9a702b276308b89901d5b6 upstream. dxfer_len is an unsigned int and we always assign a value > 0 to it, so it doesn't make any sense to check if it is < 0. We can't really check dxferp as well as we have both NULL and not NULL cases in the possible call paths. So just return true for SG_DXFER_FROM_DEV transfer in sg_is_valid_dxfer(). Signed-off-by: Johannes Thumshirn <jthumshirn(a)suse.de> Reported-by: Colin Ian King <colin.king(a)canonical.com> Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com> Cc: Douglas Gilbert <dgilbert(a)interlog.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/sg.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/drivers/scsi/sg.c +++ b/drivers/scsi/sg.c @@ -770,8 +770,11 @@ static bool sg_is_valid_dxfer(sg_io_hdr_ return false; return true; case SG_DXFER_FROM_DEV: - if (hp->dxfer_len < 0) - return false; + /* + * for SG_DXFER_FROM_DEV we always set dxfer_len to > 0. dxferp + * can either be NULL or != NULL so there's no point in checking + * it either. So just return true. + */ return true; case SG_DXFER_TO_DEV: case SG_DXFER_TO_FROM_DEV: Patches currently in stable-queue which might be from jthumshirn(a)suse.de are queue-4.4/scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch queue-4.4/scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch queue-4.4/scsi-sg-check-for-valid-direction-before-starting-the-request.patch queue-4.4/scsi-sg-close-race-condition-in-sg_remove_sfp_usercontext.patch queue-4.4/scsi-sg-fix-sg_dxfer_from_dev-transfers.patch queue-4.4/scsi-core-scsi_get_device_flags_keyed-always-return-device-flags.patch

7 years, 1 month

1
0
0 0

Patch "scsi: sg: fix SG_DXFER_FROM_DEV transfers" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: sg: fix SG_DXFER_FROM_DEV transfers to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-sg-fix-sg_dxfer_from_dev-transfers.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 68c59fcea1f2c6a54c62aa896cc623c1b5bc9b47 Mon Sep 17 00:00:00 2001 From: Johannes Thumshirn <jthumshirn(a)suse.de> Date: Fri, 7 Jul 2017 10:56:38 +0200 Subject: scsi: sg: fix SG_DXFER_FROM_DEV transfers From: Johannes Thumshirn <jthumshirn(a)suse.de> commit 68c59fcea1f2c6a54c62aa896cc623c1b5bc9b47 upstream. SG_DXFER_FROM_DEV transfers do not necessarily have a dxferp as we set it to NULL for the old sg_io read/write interface, but must have a length bigger than 0. This fixes a regression introduced by commit 28676d869bbb ("scsi: sg: check for valid direction before starting the request") Signed-off-by: Johannes Thumshirn <jthumshirn(a)suse.de> Fixes: 28676d869bbb ("scsi: sg: check for valid direction before starting the request") Reported-by: Chris Clayton <chris2553(a)googlemail.com> Tested-by: Chris Clayton <chris2553(a)googlemail.com> Cc: Douglas Gilbert <dgilbert(a)interlog.com> Reviewed-by: Hannes Reinecke <hare(a)suse.com> Tested-by: Chris Clayton <chris2553(a)googlemail.com> Acked-by: Douglas Gilbert <dgilbert(a)interlog.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Cc: Cristian Crinteanu <crinteanu.cristian(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/sg.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/scsi/sg.c +++ b/drivers/scsi/sg.c @@ -769,8 +769,11 @@ static bool sg_is_valid_dxfer(sg_io_hdr_ if (hp->dxferp || hp->dxfer_len > 0) return false; return true; - case SG_DXFER_TO_DEV: case SG_DXFER_FROM_DEV: + if (hp->dxfer_len < 0) + return false; + return true; + case SG_DXFER_TO_DEV: case SG_DXFER_TO_FROM_DEV: if (!hp->dxferp || hp->dxfer_len == 0) return false; Patches currently in stable-queue which might be from jthumshirn(a)suse.de are queue-4.4/scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch queue-4.4/scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch queue-4.4/scsi-sg-check-for-valid-direction-before-starting-the-request.patch queue-4.4/scsi-sg-close-race-condition-in-sg_remove_sfp_usercontext.patch queue-4.4/scsi-sg-fix-sg_dxfer_from_dev-transfers.patch queue-4.4/scsi-core-scsi_get_device_flags_keyed-always-return-device-flags.patch

7 years, 1 month

1
0
0 0

Patch "irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: irqchip-gic-v3-its-ensure-nr_ites-nr_lpis.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 4f2c7583e33eb08dc09dd2e25574b80175ba7d93 Mon Sep 17 00:00:00 2001 From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Date: Tue, 6 Mar 2018 15:51:32 +0000 Subject: irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> commit 4f2c7583e33eb08dc09dd2e25574b80175ba7d93 upstream. When struct its_device instances are created, the nr_ites member will be set to a power of 2 that equals or exceeds the requested number of MSIs passed to the msi_prepare() callback. At the same time, the LPI map is allocated to be some multiple of 32 in size, where the allocated size may be less than the requested size depending on whether a contiguous range of sufficient size is available in the global LPI bitmap. This may result in the situation where the nr_ites < nr_lpis, and since nr_ites is what we program into the hardware when we map the device, the additional LPIs will be non-functional. For bog standard hardware, this does not really matter. However, in cases where ITS device IDs are shared between different PCIe devices, we may end up allocating these additional LPIs without taking into account that they don't actually work. So let's make nr_ites at least 32. This ensures that all allocated LPIs are 'live', and that its_alloc_device_irq() will fail when attempts are made to allocate MSIs beyond what was allocated in the first place. Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> [maz: updated comment] Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> [ardb: trivial tweak of unrelated context] Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/irqchip/irq-gic-v3-its.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -663,7 +663,7 @@ static struct irq_chip its_irq_chip = { * This gives us (((1UL << id_bits) - 8192) >> 5) possible allocations. */ #define IRQS_PER_CHUNK_SHIFT 5 -#define IRQS_PER_CHUNK (1 << IRQS_PER_CHUNK_SHIFT) +#define IRQS_PER_CHUNK (1UL << IRQS_PER_CHUNK_SHIFT) static unsigned long *lpi_bitmap; static u32 lpi_chunks; @@ -1168,11 +1168,10 @@ static struct its_device *its_create_dev dev = kzalloc(sizeof(*dev), GFP_KERNEL); /* - * At least one bit of EventID is being used, hence a minimum - * of two entries. No, the architecture doesn't let you - * express an ITT with a single entry. + * We allocate at least one chunk worth of LPIs bet device, + * and thus that many ITEs. The device may require less though. */ - nr_ites = max(2UL, roundup_pow_of_two(nvecs)); + nr_ites = max(IRQS_PER_CHUNK, roundup_pow_of_two(nvecs)); sz = nr_ites * its->ite_size; sz = max(sz, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1; itt = kzalloc(sz, GFP_KERNEL); Patches currently in stable-queue which might be from ard.biesheuvel(a)linaro.org are queue-4.4/irqchip-gic-v3-its-ensure-nr_ites-nr_lpis.patch

7 years, 1 month

1
0
0 0

Patch "scsi: sg: only check for dxfer_len greater than 256M" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: sg: only check for dxfer_len greater than 256M to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From f930c7043663188429cd9b254e9d761edfc101ce Mon Sep 17 00:00:00 2001 From: Johannes Thumshirn <jthumshirn(a)suse.de> Date: Thu, 27 Jul 2017 09:11:26 +0200 Subject: scsi: sg: only check for dxfer_len greater than 256M From: Johannes Thumshirn <jthumshirn(a)suse.de> commit f930c7043663188429cd9b254e9d761edfc101ce upstream. Don't make any assumptions on the sg_io_hdr_t::dxfer_direction or the sg_io_hdr_t::dxferp in order to determine if it is a valid request. The only way we can check for bad requests is by checking if the length exceeds 256M. Signed-off-by: Johannes Thumshirn <jthumshirn(a)suse.de> Fixes: 28676d869bbb (scsi: sg: check for valid direction before starting the request) Reported-by: Jason L Tibbitts III <tibbs(a)math.uh.edu> Tested-by: Jason L Tibbitts III <tibbs(a)math.uh.edu> Suggested-by: Doug Gilbert <dgilbert(a)interlog.com> Cc: Doug Gilbert <dgilbert(a)interlog.com> Cc: <stable(a)vger.kernel.org> Reviewed-by: Hannes Reinecke <hare(a)suse.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/sg.c | 31 +------------------------------ 1 file changed, 1 insertion(+), 30 deletions(-) --- a/drivers/scsi/sg.c +++ b/drivers/scsi/sg.c @@ -762,35 +762,6 @@ sg_new_write(Sg_fd *sfp, struct file *fi return count; } -static bool sg_is_valid_dxfer(sg_io_hdr_t *hp) -{ - switch (hp->dxfer_direction) { - case SG_DXFER_NONE: - if (hp->dxferp || hp->dxfer_len > 0) - return false; - return true; - case SG_DXFER_FROM_DEV: - /* - * for SG_DXFER_FROM_DEV we always set dxfer_len to > 0. dxferp - * can either be NULL or != NULL so there's no point in checking - * it either. So just return true. - */ - return true; - case SG_DXFER_TO_DEV: - case SG_DXFER_TO_FROM_DEV: - if (!hp->dxferp || hp->dxfer_len == 0) - return false; - return true; - case SG_DXFER_UNKNOWN: - if ((!hp->dxferp && hp->dxfer_len) || - (hp->dxferp && hp->dxfer_len == 0)) - return false; - return true; - default: - return false; - } -} - static int sg_common_write(Sg_fd * sfp, Sg_request * srp, unsigned char *cmnd, int timeout, int blocking) @@ -811,7 +782,7 @@ sg_common_write(Sg_fd * sfp, Sg_request "sg_common_write: scsi opcode=0x%02x, cmd_size=%d\n", (int) cmnd[0], (int) hp->cmd_len)); - if (!sg_is_valid_dxfer(hp)) + if (hp->dxfer_len >= SZ_256M) return -EINVAL; k = sg_start_req(srp, cmnd); Patches currently in stable-queue which might be from jthumshirn(a)suse.de are queue-3.18/scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch queue-3.18/scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch queue-3.18/scsi-sg-check-for-valid-direction-before-starting-the-request.patch queue-3.18/scsi-sg-close-race-condition-in-sg_remove_sfp_usercontext.patch queue-3.18/scsi-sg-fix-sg_dxfer_from_dev-transfers.patch

7 years, 1 month

1
0
0 0

Patch "scsi: sg: fix static checker warning in sg_is_valid_dxfer" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: sg: fix static checker warning in sg_is_valid_dxfer to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 14074aba4bcda3764c9a702b276308b89901d5b6 Mon Sep 17 00:00:00 2001 From: Johannes Thumshirn <jthumshirn(a)suse.de> Date: Mon, 17 Jul 2017 15:11:42 +0200 Subject: scsi: sg: fix static checker warning in sg_is_valid_dxfer From: Johannes Thumshirn <jthumshirn(a)suse.de> commit 14074aba4bcda3764c9a702b276308b89901d5b6 upstream. dxfer_len is an unsigned int and we always assign a value > 0 to it, so it doesn't make any sense to check if it is < 0. We can't really check dxferp as well as we have both NULL and not NULL cases in the possible call paths. So just return true for SG_DXFER_FROM_DEV transfer in sg_is_valid_dxfer(). Signed-off-by: Johannes Thumshirn <jthumshirn(a)suse.de> Reported-by: Colin Ian King <colin.king(a)canonical.com> Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com> Cc: Douglas Gilbert <dgilbert(a)interlog.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/sg.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/drivers/scsi/sg.c +++ b/drivers/scsi/sg.c @@ -770,8 +770,11 @@ static bool sg_is_valid_dxfer(sg_io_hdr_ return false; return true; case SG_DXFER_FROM_DEV: - if (hp->dxfer_len < 0) - return false; + /* + * for SG_DXFER_FROM_DEV we always set dxfer_len to > 0. dxferp + * can either be NULL or != NULL so there's no point in checking + * it either. So just return true. + */ return true; case SG_DXFER_TO_DEV: case SG_DXFER_TO_FROM_DEV: Patches currently in stable-queue which might be from jthumshirn(a)suse.de are queue-3.18/scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch queue-3.18/scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch queue-3.18/scsi-sg-check-for-valid-direction-before-starting-the-request.patch queue-3.18/scsi-sg-close-race-condition-in-sg_remove_sfp_usercontext.patch queue-3.18/scsi-sg-fix-sg_dxfer_from_dev-transfers.patch

7 years, 1 month

1
0
0 0

Patch "scsi: sg: fix SG_DXFER_FROM_DEV transfers" has been added to the 3.18-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled scsi: sg: fix SG_DXFER_FROM_DEV transfers to the 3.18-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: scsi-sg-fix-sg_dxfer_from_dev-transfers.patch and it can be found in the queue-3.18 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 68c59fcea1f2c6a54c62aa896cc623c1b5bc9b47 Mon Sep 17 00:00:00 2001 From: Johannes Thumshirn <jthumshirn(a)suse.de> Date: Fri, 7 Jul 2017 10:56:38 +0200 Subject: scsi: sg: fix SG_DXFER_FROM_DEV transfers From: Johannes Thumshirn <jthumshirn(a)suse.de> commit 68c59fcea1f2c6a54c62aa896cc623c1b5bc9b47 upstream. SG_DXFER_FROM_DEV transfers do not necessarily have a dxferp as we set it to NULL for the old sg_io read/write interface, but must have a length bigger than 0. This fixes a regression introduced by commit 28676d869bbb ("scsi: sg: check for valid direction before starting the request") Signed-off-by: Johannes Thumshirn <jthumshirn(a)suse.de> Fixes: 28676d869bbb ("scsi: sg: check for valid direction before starting the request") Reported-by: Chris Clayton <chris2553(a)googlemail.com> Tested-by: Chris Clayton <chris2553(a)googlemail.com> Cc: Douglas Gilbert <dgilbert(a)interlog.com> Reviewed-by: Hannes Reinecke <hare(a)suse.com> Tested-by: Chris Clayton <chris2553(a)googlemail.com> Acked-by: Douglas Gilbert <dgilbert(a)interlog.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Cc: Cristian Crinteanu <crinteanu.cristian(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/scsi/sg.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/drivers/scsi/sg.c +++ b/drivers/scsi/sg.c @@ -769,8 +769,11 @@ static bool sg_is_valid_dxfer(sg_io_hdr_ if (hp->dxferp || hp->dxfer_len > 0) return false; return true; - case SG_DXFER_TO_DEV: case SG_DXFER_FROM_DEV: + if (hp->dxfer_len < 0) + return false; + return true; + case SG_DXFER_TO_DEV: case SG_DXFER_TO_FROM_DEV: if (!hp->dxferp || hp->dxfer_len == 0) return false; Patches currently in stable-queue which might be from jthumshirn(a)suse.de are queue-3.18/scsi-sg-fix-static-checker-warning-in-sg_is_valid_dxfer.patch queue-3.18/scsi-sg-only-check-for-dxfer_len-greater-than-256m.patch queue-3.18/scsi-sg-check-for-valid-direction-before-starting-the-request.patch queue-3.18/scsi-sg-close-race-condition-in-sg_remove_sfp_usercontext.patch queue-3.18/scsi-sg-fix-sg_dxfer_from_dev-transfers.patch

7 years, 1 month

1
0
0 0

[GIT PULL] commits for Linux 3.18

by Sasha Levin

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Greg, Pleae pull commits for Linux 3.18 . I've sent a review request for all commits over a week ago and all comments were addressed. Thanks, Sasha ===== The following changes since commit 43a69271f55a952895915b69f6c50c90c4abdbcd: Linux 3.18.97 (2018-02-28 10:16:18 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git tags/for-greg-3.18-15032018 for you to fetch changes up to 205e84a2faf04f381dd449aa9915faad389b14ae: ima: relax requiring a file signature for new files with zero length (2018-03-13 16:20:01 -0400) - ---------------------------------------------------------------- for-greg-3.18-15032018 - ---------------------------------------------------------------- Akinobu Mita (1): spi: omap2-mcspi: poll OMAP2_MCSPI_CHSTAT_RXS for PIO transfer Alexander Potapenko (1): selinux: check for address length in selinux_socket_bind() Andreas Pape (1): batman-adv: handle race condition for claims between gateways Andrew F. Davis (2): ARM: dts: am335x-pepper: Fix the audio CODEC's reset pin ARM: dts: omap3-n900: Fix the audio CODEC's reset pin Andrew Lunn (1): net/faraday: Add missing include of of.h Anton Blanchard (1): powerpc: Avoid taking a data miss on every userspace instruction miss Brian King (1): scsi: ipr: Fix missed EH wakeup Chris Wilson (1): drm: Defer disabling the vblank IRQ until the next interrupt (for instant-off) Christopher James Halse Rogers (1): drm/radeon: Fail fb creation from imported dma-bufs. Dan Carpenter (2): media: cpia2: Fix a couple off by one bugs ASoC: nuc900: Fix a loop timeout test David Carrillo-Cisneros (2): perf inject: Copy events when reordering events in pipe mode perf session: Don't rely on evlist in pipe mode David Daney (1): MIPS: BPF: Quit clobbering callee saved registers in JIT code. David Engraf (1): timers, sched_clock: Update timeout for clock wrap Davide Caratti (1): sched: act_csum: don't mangle TCP and UDP GSO packets Dedy Lansky (1): wil6210: fix memory access violation in wil_memcpy_from/toio_32 Gao Feng (1): tcp: sysctl: Fix a race to avoid unexpected 0 window from space Geert Uytterhoeven (2): ARM: dts: r8a7790: Correct parent of SSI[0-9] clocks ARM: dts: r8a7791: Correct parent of SSI[0-9] clocks H. Nikolaus Schaller (1): Input: tsc2007 - check for presence and power down tsc2007 during probe Hannes Reinecke (1): scsi: sg: close race condition in sg_remove_sfp_usercontext() Jagdish Gediya (1): mtd: nand: ifc: update bufnum mask for ver >= 2.0.0 Jan Kara (1): reiserfs: Make cancel_old_flush() reliable Janusz Krzysztofik (1): [media] media: i2c/soc_camera: fix ov6650 sensor getting wrong clock Jiri Kosina (1): HID: elo: clear BTN_LEFT mapping Johannes Thumshirn (1): scsi: sg: check for valid direction before starting the request John Johansen (1): apparmor: Make path_max parameter readonly Julien BOIBESSOT (1): tools/usbip: fixes build with musl libc toolchain Kirill A. Shutemov (1): mm: Fix false-positive VM_BUG_ON() in page_cache_{get,add}_speculative() Liam Beguin (1): video: ARM CLCD: fix dma allocation size Linus Walleij (1): ARM: dts: Adjust moxart IRQ controller and flags Lorenzo Colitti (1): net: xfrm: allow clearing socket xfrm policies. Luca Coelho (1): mac80211: remove BUG() when interface type is invalid Masami Hiramatsu (2): kprobes/x86: Fix kprobe-booster not to boost far call instructions kprobes/x86: Set kprobes pages read-only Mimi Zohar (1): ima: relax requiring a file signature for new files with zero length Miquel Raynal (1): mtd: nand: fix interpretation of NAND_CMD_NONE in nand_command[_lp]() Mohammed Shafi Shajakhan (1): ath10k: disallow DFS simulation if DFS channel is not enabled Nate Watterson (1): iommu/iova: Fix underflow bug in __alloc_and_insert_iova_range Pan Xinhui (1): powerpc/xmon: Fix an unexpected xmon on/off state change Paul E. McKenney (1): sched: Stop resched_cpu() from sending IPIs to offline CPUs Phil Turnbull (1): fm10k: correctly check if interface is removed Prarit Bhargava (1): PCI/MSI: Stop disabling MSI/MSI-X in pci_device_shutdown() Quan Nguyen (1): drivers: net: xgene: Fix hardware checksum setting Rob Herring (1): of: fix of_device_get_modalias returned length when truncating buffers Roger Quadros (1): ARM: DRA7: hwmod_data: Prevent wait_target_disable error for usb_otg_ss Samuel Thibault (1): braille-console: Fix value returned by _braille_console_setup SeongJae Park (1): rcutorture/configinit: Fix build directory error message Shaohua Li (1): blk-throttle: make sure expire time isn't too big Stephane Eranian (1): perf tools: Make perf_event__synthesize_mmap_events() scale Stephen Hemminger (1): veth: set peer GSO values Thomas Petazzoni (1): net: mvpp2: set dma mask and coherent dma mask on PPv2.2 Tobias Jordan (1): spi: sun6i: disable/unprepare clocks on remove Tomasz Kramkowski (1): HID: clamp input to logical range if no null state Valtteri HeikkilÃ¤ (1): HID: reject input outside logical range only if null state is set Vincent StehlÃ© (1): regulator: isl9305: fix array size Xose Vazquez Perez (1): scsi: devinfo: apply to HP XP the same flags as Hitachi VSP Yuyang Du (1): usb: gadget: dummy_hcd: Fix wrong power status bit clear/reset in dummy_hub_control() arch/arm/boot/dts/am335x-pepper.dts | 2 +- arch/arm/boot/dts/moxart-uc7112lx.dts | 2 +- arch/arm/boot/dts/moxart.dtsi | 17 ++++--- arch/arm/boot/dts/omap3-n900.dts | 4 +- arch/arm/boot/dts/r8a7790.dtsi | 7 ++- arch/arm/boot/dts/r8a7791.dtsi | 7 ++- arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 2 + arch/mips/net/bpf_jit.c | 16 ++++-- arch/powerpc/mm/fault.c | 2 +- arch/powerpc/xmon/xmon.c | 17 ++++--- arch/x86/kernel/kprobes/core.c | 6 +++ arch/x86/kernel/kprobes/opt.c | 3 ++ block/blk-throttle.c | 11 ++++ drivers/gpu/drm/drm_irq.c | 14 +++++- drivers/gpu/drm/radeon/radeon_display.c | 6 +++ drivers/hid/hid-elo.c | 6 +++ drivers/hid/hid-input.c | 20 +++++--- drivers/input/touchscreen/tsc2007.c | 8 +++ drivers/iommu/iova.c | 2 +- drivers/media/i2c/soc_camera/ov6650.c | 2 +- drivers/media/usb/cpia2/cpia2_v4l.c | 4 +- drivers/mtd/nand/fsl_ifc_nand.c | 7 +++ drivers/mtd/nand/nand_base.c | 9 +++- drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 1 + drivers/net/ethernet/apm/xgene/xgene_enet_hw.h | 1 + drivers/net/ethernet/faraday/ftgmac100.c | 1 + drivers/net/ethernet/intel/fm10k/fm10k_ethtool.c | 2 +- drivers/net/ethernet/marvell/mvpp2.c | 14 ++++++ drivers/net/veth.c | 3 ++ drivers/net/wireless/ath/ath10k/debug.c | 9 ++++ drivers/net/wireless/ath/wil6210/main.c | 20 ++++++-- drivers/of/device.c | 2 +- drivers/pci/pci-driver.c | 2 - drivers/scsi/ipr.c | 16 ++++-- drivers/scsi/scsi_devinfo.c | 2 +- drivers/scsi/sg.c | 58 ++++++++++++++++------ drivers/spi/spi-omap2-mcspi.c | 9 ++-- drivers/spi/spi-sun6i.c | 2 +- drivers/usb/gadget/udc/dummy_hcd.c | 20 +++----- drivers/video/fbdev/amba-clcd.c | 4 +- fs/reiserfs/journal.c | 2 +- fs/reiserfs/reiserfs.h | 1 + fs/reiserfs/super.c | 21 +++++--- include/linux/pagemap.h | 4 +- include/linux/platform_data/isl9305.h | 2 +- include/net/tcp.h | 8 +-- kernel/printk/braille.c | 15 +++--- kernel/printk/braille.h | 13 +++-- kernel/sched/core.c | 3 +- kernel/time/sched_clock.c | 5 ++ net/batman-adv/bridge_loop_avoidance.c | 20 ++++++-- net/mac80211/iface.c | 2 +- net/sched/act_csum.c | 12 +++++ net/xfrm/xfrm_policy.c | 2 +- net/xfrm/xfrm_state.c | 7 +++ security/apparmor/lsm.c | 2 +- security/integrity/ima/ima_appraise.c | 3 +- security/selinux/hooks.c | 8 +++ sound/soc/nuc900/nuc900-ac97.c | 4 +- tools/perf/util/event.c | 4 +- tools/perf/util/ordered-events.c | 3 +- tools/perf/util/session.c | 17 +++++-- .../testing/selftests/rcutorture/bin/configinit.sh | 2 +- tools/usb/usbip/src/usbipd.c | 2 +- 64 files changed, 373 insertions(+), 129 deletions(-) -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaqvaSAAoJEN6mb/eXdyzc7tYQALBsyf0U6YOF46kIyVK3e/U7 Ti2BOwSqJOdXz3bcOcNMQlja7E6IZOndxKFRgr81JombUMGRpgtQBhsK3MVpcNSd /f6wJ80zvOs+kcGHcn3dUr6EWzUWxbudlq8M6EeL6GiXcd3Kus6yicPTVhC8SvIm 03jVwS5xAOTbKH9lMTXqqxZ1Hu8hAWEuloKsHQBD/PGy6bzKfqv4ob/kTEqvY1oU 31nmmlbgTi9xL+tcDrTz1RTYgXvcO7uAXuss4pfnaeqTCEJMK1SO6o0Pm3OocF+n axMsAptbO48tZRejQQ+HpwatPjS+3APheiXg1l4B7PEBoe1kXNiQLXc8m96a96sm ce+hYwHZydgj6gBLPCAA0nfo0j+Fm8pFdJ3WdlgtJDRRF3urx7zXlLJN3I3djd3m YYd+Y/HKb0CDarAotuBqQKhIbUYDqz4eLPbwJGa66JMKY0HvAahKxlKJRvUMvbiY /moN2hJ3IX732bHuiYPzTGRu06AvUs+PAWaYxNIXA1VC75Bff3momUCd8/jTzeD9 umd9y5Tt/i2e4MicMjO6Eh3UEMvoDEHmqNZpFen+YQeifdrEUDKmbYxUrRWuvFQO dpNURdjChlDzN2HdZ54Zf+suId67J2te8/jAWrRIifhcvME/+50bO27aHiInxKW4 UOtW14rBfo7b7oilwFT8 =MB7b -----END PGP SIGNATURE-----

7 years, 1 month

2
1
0 0

[PATCH] irqchip/gic-v3-its: Ensure nr_ites >= nr_lpis

by Ard Biesheuvel

Commit 4f2c7583e33e upstream. When struct its_device instances are created, the nr_ites member will be set to a power of 2 that equals or exceeds the requested number of MSIs passed to the msi_prepare() callback. At the same time, the LPI map is allocated to be some multiple of 32 in size, where the allocated size may be less than the requested size depending on whether a contiguous range of sufficient size is available in the global LPI bitmap. This may result in the situation where the nr_ites < nr_lpis, and since nr_ites is what we program into the hardware when we map the device, the additional LPIs will be non-functional. For bog standard hardware, this does not really matter. However, in cases where ITS device IDs are shared between different PCIe devices, we may end up allocating these additional LPIs without taking into account that they don't actually work. So let's make nr_ites at least 32. This ensures that all allocated LPIs are 'live', and that its_alloc_device_irq() will fail when attempts are made to allocate MSIs beyond what was allocated in the first place. Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> [maz: updated comment] Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> [ardb: trivial tweak of unrelated context] Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> --- drivers/irqchip/irq-gic-v3-its.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index acb9d250a905..ac15e5d5d9b2 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -684,7 +684,7 @@ static struct irq_chip its_irq_chip = { * This gives us (((1UL << id_bits) - 8192) >> 5) possible allocations. */ #define IRQS_PER_CHUNK_SHIFT 5 -#define IRQS_PER_CHUNK (1 << IRQS_PER_CHUNK_SHIFT) +#define IRQS_PER_CHUNK (1UL << IRQS_PER_CHUNK_SHIFT) static unsigned long *lpi_bitmap; static u32 lpi_chunks; @@ -1320,11 +1320,10 @@ static struct its_device *its_create_device(struct its_node *its, u32 dev_id, dev = kzalloc(sizeof(*dev), GFP_KERNEL); /* - * At least one bit of EventID is being used, hence a minimum - * of two entries. No, the architecture doesn't let you - * express an ITT with a single entry. + * We allocate at least one chunk worth of LPIs bet device, + * and thus that many ITEs. The device may require less though. */ - nr_ites = max(2UL, roundup_pow_of_two(nvecs)); + nr_ites = max(IRQS_PER_CHUNK, roundup_pow_of_two(nvecs)); sz = nr_ites * its->ite_size; sz = max(sz, ITS_ITT_ALIGN) + ITS_ITT_ALIGN - 1; itt = kzalloc(sz, GFP_KERNEL); -- 2.11.0

7 years, 1 month

2
5
0 0

v3.9.11 build: 9 failures 9 warnings (v3.9.11)

by Build bot for Mark Brown

Tree/Branch: v3.9.11 Git describe: v3.9.11 Commit: 896f5009ed Linux 3.9.11 Build Time: 0 min 12 sec Passed: 0 / 9 ( 0.00 %) Failed: 9 / 9 (100.00 %) Errors: 4 Warnings: 9 Section Mismatches: 0 Failed defconfigs: arm64-allnoconfig arm64-allmodconfig arm-multi_v7_defconfig x86_64-defconfig arm-allmodconfig arm-allnoconfig x86_64-allnoconfig x86_64-allmodconfig arm64-defconfig Errors: arm64-allnoconfig /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory arm64-allmodconfig /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory arm-multi_v7_defconfig /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory x86_64-defconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/scripts/mod/devicetable-offsets.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode arm-allmodconfig /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory arm-allnoconfig /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory x86_64-allnoconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/scripts/mod/devicetable-offsets.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode x86_64-allmodconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/scripts/mod/devicetable-offsets.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode arm64-defconfig /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 5 warnings 0 mismatches : arm64-allmodconfig 3 warnings 0 mismatches : arm-multi_v7_defconfig 8 warnings 0 mismatches : arm-allmodconfig 1 warnings 0 mismatches : arm-allnoconfig 4 warnings 0 mismatches : x86_64-allnoconfig 5 warnings 0 mismatches : x86_64-allmodconfig 1 warnings 0 mismatches : arm64-defconfig ------------------------------------------------------------------------------- Errors summary: 4 12 /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory 3 /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode 3 /home/broonie/build/linux-stable/scripts/mod/devicetable-offsets.c:1:0: error: code model kernel does not support PIC mode 3 /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode Warnings Summary: 9 4 /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized] 3 warning: (VIDEO_DM6446_CCDC && VIDEO_DM355_CCDC && VIDEO_ISIF && VIDEO_DAVINCI_VPBE_DISPLAY) selects VIDEO_VPSS_SYSTEM which has unmet direct dependencies (MEDIA_SUPPORT && V4L_PLATFORM_DRIVERS && ARCH_DAVINCI) 3 /home/broonie/build/linux-stable/scripts/kconfig/menu.c:561:18: warning: 'jump' may be used uninitialized in this function [-Wmaybe-uninitialized] 3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TYPE_REF' not handled in switch [-Wswitch] 3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TAG_OVERRIDE' not handled in switch [-Wswitch] 3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'NOT_COMPOUND' not handled in switch [-Wswitch] 3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'CHOICE' not handled in switch [-Wswitch] 3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'ANY' not handled in switch [-Wswitch] 2 /home/broonie/build/linux-stable/scripts/sortextable.c:64:1: warning: 'succeed_file' defined but not used [-Wunused-function] =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- arm64-allnoconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory ------------------------------------------------------------------------------- arm64-allmodconfig : FAIL, 2 errors, 5 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory Warnings: /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'NOT_COMPOUND' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'CHOICE' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'ANY' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TYPE_REF' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TAG_OVERRIDE' not handled in switch [-Wswitch] ------------------------------------------------------------------------------- arm-multi_v7_defconfig : FAIL, 2 errors, 3 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory Warnings: /home/broonie/build/linux-stable/scripts/sortextable.c:64:1: warning: 'succeed_file' defined but not used [-Wunused-function] /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized] /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized] ------------------------------------------------------------------------------- x86_64-defconfig : FAIL, 3 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/scripts/mod/devicetable-offsets.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- arm-allmodconfig : FAIL, 2 errors, 8 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory Warnings: warning: (VIDEO_DM6446_CCDC && VIDEO_DM355_CCDC && VIDEO_ISIF && VIDEO_DAVINCI_VPBE_DISPLAY) selects VIDEO_VPSS_SYSTEM which has unmet direct dependencies (MEDIA_SUPPORT && V4L_PLATFORM_DRIVERS && ARCH_DAVINCI) warning: (VIDEO_DM6446_CCDC && VIDEO_DM355_CCDC && VIDEO_ISIF && VIDEO_DAVINCI_VPBE_DISPLAY) selects VIDEO_VPSS_SYSTEM which has unmet direct dependencies (MEDIA_SUPPORT && V4L_PLATFORM_DRIVERS && ARCH_DAVINCI) warning: (VIDEO_DM6446_CCDC && VIDEO_DM355_CCDC && VIDEO_ISIF && VIDEO_DAVINCI_VPBE_DISPLAY) selects VIDEO_VPSS_SYSTEM which has unmet direct dependencies (MEDIA_SUPPORT && V4L_PLATFORM_DRIVERS && ARCH_DAVINCI) /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'NOT_COMPOUND' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'CHOICE' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'ANY' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TYPE_REF' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TAG_OVERRIDE' not handled in switch [-Wswitch] ------------------------------------------------------------------------------- arm-allnoconfig : FAIL, 2 errors, 1 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory Warnings: /home/broonie/build/linux-stable/scripts/kconfig/menu.c:561:18: warning: 'jump' may be used uninitialized in this function [-Wmaybe-uninitialized] ------------------------------------------------------------------------------- x86_64-allnoconfig : FAIL, 3 errors, 4 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/scripts/mod/devicetable-offsets.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode Warnings: /home/broonie/build/linux-stable/scripts/kconfig/menu.c:561:18: warning: 'jump' may be used uninitialized in this function [-Wmaybe-uninitialized] /home/broonie/build/linux-stable/scripts/sortextable.c:64:1: warning: 'succeed_file' defined but not used [-Wunused-function] /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized] /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized] ------------------------------------------------------------------------------- x86_64-allmodconfig : FAIL, 3 errors, 5 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/scripts/mod/devicetable-offsets.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode Warnings: /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'NOT_COMPOUND' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'CHOICE' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'ANY' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TYPE_REF' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TAG_OVERRIDE' not handled in switch [-Wswitch] ------------------------------------------------------------------------------- arm64-defconfig : FAIL, 2 errors, 1 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory Warnings: /home/broonie/build/linux-stable/scripts/kconfig/menu.c:561:18: warning: 'jump' may be used uninitialized in this function [-Wmaybe-uninitialized] ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches:

7 years, 1 month

1
0
0 0

v3.8.13 build: 9 failures 10 warnings (v3.8.13)

by Build bot for Mark Brown

Tree/Branch: v3.8.13 Git describe: v3.8.13 Commit: dbf932a9b3 Linux 3.8.13 Build Time: 0 min 12 sec Passed: 0 / 9 ( 0.00 %) Failed: 9 / 9 (100.00 %) Errors: 3 Warnings: 10 Section Mismatches: 0 Failed defconfigs: arm64-allnoconfig arm64-allmodconfig arm-multi_v7_defconfig x86_64-defconfig arm-allmodconfig arm-allnoconfig x86_64-allnoconfig x86_64-allmodconfig arm64-defconfig Errors: arm64-allnoconfig /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory arm64-allmodconfig /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory arm-multi_v7_defconfig /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory x86_64-defconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode arm-allmodconfig /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory arm-allnoconfig /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory x86_64-allnoconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode x86_64-allmodconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode arm64-defconfig /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 8 warnings 0 mismatches : arm64-allmodconfig 3 warnings 0 mismatches : arm-multi_v7_defconfig 8 warnings 0 mismatches : arm-allmodconfig 1 warnings 0 mismatches : arm-allnoconfig 4 warnings 0 mismatches : x86_64-allnoconfig 5 warnings 0 mismatches : x86_64-allmodconfig 1 warnings 0 mismatches : arm64-defconfig ------------------------------------------------------------------------------- Errors summary: 3 6 /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory 3 /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode 3 /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode Warnings Summary: 10 4 /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized] 3 warning: (LOCKDEP && FAULT_INJECTION_STACKTRACE_FILTER && LATENCYTOP && KMEMCHECK) selects FRAME_POINTER which has unmet direct dependencies (DEBUG_KERNEL && (CRIS || M68K || FRV || UML || AVR32 || SUPERH || BLACKFIN || MN10300) || ARCH_WANT_FRAME_POINTERS) 3 warning: (DVB_USB_PCTV452E) selects TTPCI_EEPROM which has unmet direct dependencies (MEDIA_SUPPORT && MEDIA_PCI_SUPPORT && MEDIA_DIGITAL_TV_SUPPORT && I2C) 3 /home/broonie/build/linux-stable/scripts/kconfig/menu.c:561:18: warning: 'jump' may be used uninitialized in this function [-Wmaybe-uninitialized] 3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TYPE_REF' not handled in switch [-Wswitch] 3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TAG_OVERRIDE' not handled in switch [-Wswitch] 3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'NOT_COMPOUND' not handled in switch [-Wswitch] 3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'CHOICE' not handled in switch [-Wswitch] 3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'ANY' not handled in switch [-Wswitch] 2 /home/broonie/build/linux-stable/scripts/sortextable.c:64:1: warning: 'succeed_file' defined but not used [-Wunused-function] =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- arm64-allnoconfig : FAIL, 1 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory ------------------------------------------------------------------------------- arm64-allmodconfig : FAIL, 1 errors, 8 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory Warnings: warning: (LOCKDEP && FAULT_INJECTION_STACKTRACE_FILTER && LATENCYTOP && KMEMCHECK) selects FRAME_POINTER which has unmet direct dependencies (DEBUG_KERNEL && (CRIS || M68K || FRV || UML || AVR32 || SUPERH || BLACKFIN || MN10300) || ARCH_WANT_FRAME_POINTERS) warning: (LOCKDEP && FAULT_INJECTION_STACKTRACE_FILTER && LATENCYTOP && KMEMCHECK) selects FRAME_POINTER which has unmet direct dependencies (DEBUG_KERNEL && (CRIS || M68K || FRV || UML || AVR32 || SUPERH || BLACKFIN || MN10300) || ARCH_WANT_FRAME_POINTERS) warning: (LOCKDEP && FAULT_INJECTION_STACKTRACE_FILTER && LATENCYTOP && KMEMCHECK) selects FRAME_POINTER which has unmet direct dependencies (DEBUG_KERNEL && (CRIS || M68K || FRV || UML || AVR32 || SUPERH || BLACKFIN || MN10300) || ARCH_WANT_FRAME_POINTERS) /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'NOT_COMPOUND' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'CHOICE' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'ANY' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TYPE_REF' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TAG_OVERRIDE' not handled in switch [-Wswitch] ------------------------------------------------------------------------------- arm-multi_v7_defconfig : FAIL, 1 errors, 3 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory Warnings: /home/broonie/build/linux-stable/scripts/sortextable.c:64:1: warning: 'succeed_file' defined but not used [-Wunused-function] /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized] /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized] ------------------------------------------------------------------------------- x86_64-defconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- arm-allmodconfig : FAIL, 1 errors, 8 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory Warnings: warning: (DVB_USB_PCTV452E) selects TTPCI_EEPROM which has unmet direct dependencies (MEDIA_SUPPORT && MEDIA_PCI_SUPPORT && MEDIA_DIGITAL_TV_SUPPORT && I2C) warning: (DVB_USB_PCTV452E) selects TTPCI_EEPROM which has unmet direct dependencies (MEDIA_SUPPORT && MEDIA_PCI_SUPPORT && MEDIA_DIGITAL_TV_SUPPORT && I2C) warning: (DVB_USB_PCTV452E) selects TTPCI_EEPROM which has unmet direct dependencies (MEDIA_SUPPORT && MEDIA_PCI_SUPPORT && MEDIA_DIGITAL_TV_SUPPORT && I2C) /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'NOT_COMPOUND' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'CHOICE' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'ANY' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TYPE_REF' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TAG_OVERRIDE' not handled in switch [-Wswitch] ------------------------------------------------------------------------------- arm-allnoconfig : FAIL, 1 errors, 1 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory Warnings: /home/broonie/build/linux-stable/scripts/kconfig/menu.c:561:18: warning: 'jump' may be used uninitialized in this function [-Wmaybe-uninitialized] ------------------------------------------------------------------------------- x86_64-allnoconfig : FAIL, 2 errors, 4 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode Warnings: /home/broonie/build/linux-stable/scripts/kconfig/menu.c:561:18: warning: 'jump' may be used uninitialized in this function [-Wmaybe-uninitialized] /home/broonie/build/linux-stable/scripts/sortextable.c:64:1: warning: 'succeed_file' defined but not used [-Wunused-function] /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized] /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized] ------------------------------------------------------------------------------- x86_64-allmodconfig : FAIL, 2 errors, 5 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode Warnings: /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'NOT_COMPOUND' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'CHOICE' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'ANY' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TYPE_REF' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TAG_OVERRIDE' not handled in switch [-Wswitch] ------------------------------------------------------------------------------- arm64-defconfig : FAIL, 1 errors, 1 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory Warnings: /home/broonie/build/linux-stable/scripts/kconfig/menu.c:561:18: warning: 'jump' may be used uninitialized in this function [-Wmaybe-uninitialized] ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches:

7 years, 1 month

1
0
0 0

v3.7.10 build: 9 failures 10 warnings (v3.7.10)

by Build bot for Mark Brown

Tree/Branch: v3.7.10 Git describe: v3.7.10 Commit: 356d8c6fb2 Linux 3.7.10 Build Time: 0 min 11 sec Passed: 0 / 9 ( 0.00 %) Failed: 9 / 9 (100.00 %) Errors: 3 Warnings: 10 Section Mismatches: 0 Failed defconfigs: arm64-allnoconfig arm64-allmodconfig arm-multi_v7_defconfig x86_64-defconfig arm-allmodconfig arm-allnoconfig x86_64-allnoconfig x86_64-allmodconfig arm64-defconfig Errors: arm64-allnoconfig /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory arm64-allmodconfig /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory arm-multi_v7_defconfig /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory x86_64-defconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode arm-allmodconfig /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory arm-allnoconfig /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory x86_64-allnoconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode x86_64-allmodconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode arm64-defconfig /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 8 warnings 0 mismatches : arm64-allmodconfig 8 warnings 0 mismatches : arm-allmodconfig 1 warnings 0 mismatches : arm-allnoconfig 4 warnings 0 mismatches : x86_64-allnoconfig 5 warnings 0 mismatches : x86_64-allmodconfig 1 warnings 0 mismatches : arm64-defconfig ------------------------------------------------------------------------------- Errors summary: 3 6 /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory 3 /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode 3 /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode Warnings Summary: 10 3 warning: (LOCKDEP && FAULT_INJECTION_STACKTRACE_FILTER && LATENCYTOP && KMEMCHECK) selects FRAME_POINTER which has unmet direct dependencies (DEBUG_KERNEL && (CRIS || M68K || FRV || UML || AVR32 || SUPERH || BLACKFIN || MN10300) || ARCH_WANT_FRAME_POINTERS) 3 warning: (DVB_USB_PCTV452E) selects TTPCI_EEPROM which has unmet direct dependencies (MEDIA_SUPPORT && MEDIA_PCI_SUPPORT && MEDIA_DIGITAL_TV_SUPPORT && I2C) 3 /home/broonie/build/linux-stable/scripts/kconfig/menu.c:561:18: warning: 'jump' may be used uninitialized in this function [-Wmaybe-uninitialized] 3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TYPE_REF' not handled in switch [-Wswitch] 3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TAG_OVERRIDE' not handled in switch [-Wswitch] 3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'NOT_COMPOUND' not handled in switch [-Wswitch] 3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'CHOICE' not handled in switch [-Wswitch] 3 /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'ANY' not handled in switch [-Wswitch] 2 /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized] 1 /home/broonie/build/linux-stable/scripts/sortextable.c:64:1: warning: 'succeed_file' defined but not used [-Wunused-function] =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- arm64-allnoconfig : FAIL, 1 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory ------------------------------------------------------------------------------- arm64-allmodconfig : FAIL, 1 errors, 8 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory Warnings: warning: (LOCKDEP && FAULT_INJECTION_STACKTRACE_FILTER && LATENCYTOP && KMEMCHECK) selects FRAME_POINTER which has unmet direct dependencies (DEBUG_KERNEL && (CRIS || M68K || FRV || UML || AVR32 || SUPERH || BLACKFIN || MN10300) || ARCH_WANT_FRAME_POINTERS) warning: (LOCKDEP && FAULT_INJECTION_STACKTRACE_FILTER && LATENCYTOP && KMEMCHECK) selects FRAME_POINTER which has unmet direct dependencies (DEBUG_KERNEL && (CRIS || M68K || FRV || UML || AVR32 || SUPERH || BLACKFIN || MN10300) || ARCH_WANT_FRAME_POINTERS) warning: (LOCKDEP && FAULT_INJECTION_STACKTRACE_FILTER && LATENCYTOP && KMEMCHECK) selects FRAME_POINTER which has unmet direct dependencies (DEBUG_KERNEL && (CRIS || M68K || FRV || UML || AVR32 || SUPERH || BLACKFIN || MN10300) || ARCH_WANT_FRAME_POINTERS) /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'NOT_COMPOUND' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'CHOICE' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'ANY' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TYPE_REF' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TAG_OVERRIDE' not handled in switch [-Wswitch] ------------------------------------------------------------------------------- arm-multi_v7_defconfig : FAIL, 1 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory ------------------------------------------------------------------------------- x86_64-defconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- arm-allmodconfig : FAIL, 1 errors, 8 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory Warnings: warning: (DVB_USB_PCTV452E) selects TTPCI_EEPROM which has unmet direct dependencies (MEDIA_SUPPORT && MEDIA_PCI_SUPPORT && MEDIA_DIGITAL_TV_SUPPORT && I2C) warning: (DVB_USB_PCTV452E) selects TTPCI_EEPROM which has unmet direct dependencies (MEDIA_SUPPORT && MEDIA_PCI_SUPPORT && MEDIA_DIGITAL_TV_SUPPORT && I2C) warning: (DVB_USB_PCTV452E) selects TTPCI_EEPROM which has unmet direct dependencies (MEDIA_SUPPORT && MEDIA_PCI_SUPPORT && MEDIA_DIGITAL_TV_SUPPORT && I2C) /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'NOT_COMPOUND' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'CHOICE' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'ANY' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TYPE_REF' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TAG_OVERRIDE' not handled in switch [-Wswitch] ------------------------------------------------------------------------------- arm-allnoconfig : FAIL, 1 errors, 1 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory Warnings: /home/broonie/build/linux-stable/scripts/kconfig/menu.c:561:18: warning: 'jump' may be used uninitialized in this function [-Wmaybe-uninitialized] ------------------------------------------------------------------------------- x86_64-allnoconfig : FAIL, 2 errors, 4 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode Warnings: /home/broonie/build/linux-stable/scripts/kconfig/menu.c:561:18: warning: 'jump' may be used uninitialized in this function [-Wmaybe-uninitialized] /home/broonie/build/linux-stable/scripts/sortextable.c:64:1: warning: 'succeed_file' defined but not used [-Wunused-function] /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized] /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized] ------------------------------------------------------------------------------- x86_64-allmodconfig : FAIL, 2 errors, 5 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode Warnings: /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'NOT_COMPOUND' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'CHOICE' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'ANY' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TYPE_REF' not handled in switch [-Wswitch] /home/broonie/build/linux-stable/scripts/asn1_compiler.c:1341:3: warning: enumeration value 'TAG_OVERRIDE' not handled in switch [-Wswitch] ------------------------------------------------------------------------------- arm64-defconfig : FAIL, 1 errors, 1 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory Warnings: /home/broonie/build/linux-stable/scripts/kconfig/menu.c:561:18: warning: 'jump' may be used uninitialized in this function [-Wmaybe-uninitialized] ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches:

7 years, 1 month

1
0
0 0

v3.6.11 build: 5 failures 3 warnings (v3.6.11)

by Build bot for Mark Brown

Tree/Branch: v3.6.11 Git describe: v3.6.11 Commit: b2824f4e09 Linux 3.6.11 Build Time: 0 min 5 sec Passed: 0 / 5 ( 0.00 %) Failed: 5 / 5 (100.00 %) Errors: 3 Warnings: 3 Section Mismatches: 0 Failed defconfigs: x86_64-allnoconfig arm-allmodconfig arm-allnoconfig x86_64-allmodconfig x86_64-defconfig Errors: x86_64-allnoconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode arm-allnoconfig /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory x86_64-allmodconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode x86_64-defconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 3 warnings 0 mismatches : x86_64-allnoconfig 2 warnings 0 mismatches : arm-allmodconfig ------------------------------------------------------------------------------- Errors summary: 3 3 /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode 3 /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode 1 /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory Warnings Summary: 3 2 /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized] 2 .config:20:warning: symbol value '' invalid for PHYS_OFFSET 1 /home/broonie/build/linux-stable/scripts/sortextable.c:64:1: warning: 'succeed_file' defined but not used [-Wunused-function] =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- x86_64-allnoconfig : FAIL, 2 errors, 3 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode Warnings: /home/broonie/build/linux-stable/scripts/sortextable.c:64:1: warning: 'succeed_file' defined but not used [-Wunused-function] /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized] /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized] ------------------------------------------------------------------------------- arm-allmodconfig : FAIL, 0 errors, 2 warnings, 0 section mismatches Warnings: .config:20:warning: symbol value '' invalid for PHYS_OFFSET .config:20:warning: symbol value '' invalid for PHYS_OFFSET ------------------------------------------------------------------------------- arm-allnoconfig : FAIL, 1 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory ------------------------------------------------------------------------------- x86_64-allmodconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- x86_64-defconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches:

7 years, 1 month

1
0
0 0

v3.5.7 build: 5 failures 3 warnings (v3.5.7)

by Build bot for Mark Brown

Tree/Branch: v3.5.7 Git describe: v3.5.7 Commit: f2b152564a Linux 3.5.7 Build Time: 0 min 3 sec Passed: 0 / 5 ( 0.00 %) Failed: 5 / 5 (100.00 %) Errors: 3 Warnings: 3 Section Mismatches: 0 Failed defconfigs: x86_64-allnoconfig arm-allmodconfig arm-allnoconfig x86_64-allmodconfig x86_64-defconfig Errors: x86_64-allnoconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode arm-allnoconfig /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory x86_64-allmodconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode x86_64-defconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 3 warnings 0 mismatches : x86_64-allnoconfig 2 warnings 0 mismatches : arm-allmodconfig ------------------------------------------------------------------------------- Errors summary: 3 3 /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode 3 /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode 1 /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory Warnings Summary: 3 2 /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized] 2 .config:20:warning: symbol value '' invalid for PHYS_OFFSET 1 /home/broonie/build/linux-stable/scripts/sortextable.c:64:1: warning: 'succeed_file' defined but not used [-Wunused-function] =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- x86_64-allnoconfig : FAIL, 2 errors, 3 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode Warnings: /home/broonie/build/linux-stable/scripts/sortextable.c:64:1: warning: 'succeed_file' defined but not used [-Wunused-function] /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized] /home/broonie/build/linux-stable/scripts/sortextable.h:158:3: warning: 'relocs_size' may be used uninitialized in this function [-Wmaybe-uninitialized] ------------------------------------------------------------------------------- arm-allmodconfig : FAIL, 0 errors, 2 warnings, 0 section mismatches Warnings: .config:20:warning: symbol value '' invalid for PHYS_OFFSET .config:20:warning: symbol value '' invalid for PHYS_OFFSET ------------------------------------------------------------------------------- arm-allnoconfig : FAIL, 1 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:100:30: fatal error: linux/compiler-gcc5.h: No such file or directory ------------------------------------------------------------------------------- x86_64-allmodconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- x86_64-defconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches:

7 years, 1 month

1
0
0 0

v3.4.113 build: 5 failures 20 warnings (v3.4.113)

by Build bot for Mark Brown

Tree/Branch: v3.4.113 Git describe: v3.4.113 Commit: 8d1988f838 Linux 3.4.113 Build Time: 0 min 4 sec Passed: 0 / 5 ( 0.00 %) Failed: 5 / 5 (100.00 %) Errors: 6 Warnings: 20 Section Mismatches: 0 Failed defconfigs: x86_64-allnoconfig arm-allmodconfig arm-allnoconfig x86_64-allmodconfig x86_64-defconfig Errors: x86_64-allnoconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode arm-allnoconfig /home/broonie/build/linux-stable/arch/arm/include/asm/div64.h:77:7: error: '__LINUX_ARM_ARCH__' undeclared (first use in this function) /home/broonie/build/linux-stable/arch/arm/include/asm/glue-cache.h:129:2: error: #error Unknown cache maintenance model /home/broonie/build/linux-stable/arch/arm/include/asm/glue-df.h:107:2: error: #error Unknown data abort handler type /home/broonie/build/linux-stable/arch/arm/include/asm/glue-pf.h:54:2: error: #error Unknown prefetch abort handler type x86_64-allmodconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode x86_64-defconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 2 warnings 0 mismatches : arm-allmodconfig 19 warnings 0 mismatches : arm-allnoconfig ------------------------------------------------------------------------------- Errors summary: 6 3 /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode 3 /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode 1 /home/broonie/build/linux-stable/arch/arm/include/asm/glue-pf.h:54:2: error: #error Unknown prefetch abort handler type 1 /home/broonie/build/linux-stable/arch/arm/include/asm/glue-df.h:107:2: error: #error Unknown data abort handler type 1 /home/broonie/build/linux-stable/arch/arm/include/asm/glue-cache.h:129:2: error: #error Unknown cache maintenance model 1 /home/broonie/build/linux-stable/arch/arm/include/asm/div64.h:77:7: error: '__LINUX_ARM_ARCH__' undeclared (first use in this function) Warnings Summary: 20 2 .config:26:warning: symbol value '' invalid for PHYS_OFFSET 1 /home/broonie/build/linux-stable/arch/arm/include/asm/swab.h:46:29: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/swab.h:26:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:81:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:103:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/irqflags.h:11:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/fpstate.h:32:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/cmpxchg.h:40:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/cmpxchg.h:33:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/cmpxchg.h:108:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:33:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:28:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:196:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:194:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/bitops.h:217:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/barrier.h:9:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/barrier.h:20:35: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/barrier.h:16:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/barrier.h:10:3: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/atomic.h:32:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- x86_64-allnoconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- arm-allmodconfig : FAIL, 0 errors, 2 warnings, 0 section mismatches Warnings: .config:26:warning: symbol value '' invalid for PHYS_OFFSET .config:26:warning: symbol value '' invalid for PHYS_OFFSET ------------------------------------------------------------------------------- arm-allnoconfig : FAIL, 4 errors, 19 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/arch/arm/include/asm/div64.h:77:7: error: '__LINUX_ARM_ARCH__' undeclared (first use in this function) /home/broonie/build/linux-stable/arch/arm/include/asm/glue-cache.h:129:2: error: #error Unknown cache maintenance model /home/broonie/build/linux-stable/arch/arm/include/asm/glue-df.h:107:2: error: #error Unknown data abort handler type /home/broonie/build/linux-stable/arch/arm/include/asm/glue-pf.h:54:2: error: #error Unknown prefetch abort handler type Warnings: /home/broonie/build/linux-stable/arch/arm/include/asm/irqflags.h:11:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/bitops.h:217:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/swab.h:26:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/swab.h:46:29: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/fpstate.h:32:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/barrier.h:9:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/barrier.h:10:3: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/barrier.h:16:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/barrier.h:20:35: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:81:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:103:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/cmpxchg.h:33:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/cmpxchg.h:40:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/cmpxchg.h:108:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/atomic.h:32:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:28:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:33:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:194:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:196:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] ------------------------------------------------------------------------------- x86_64-allmodconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- x86_64-defconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches:

7 years, 1 month

1
0
0 0

v3.3.8 build: 5 failures 2 warnings (v3.3.8)

by Build bot for Mark Brown

Tree/Branch: v3.3.8 Git describe: v3.3.8 Commit: 845720650c Linux 3.3.8 Build Time: 0 min 3 sec Passed: 0 / 5 ( 0.00 %) Failed: 5 / 5 (100.00 %) Errors: 3 Warnings: 2 Section Mismatches: 0 Failed defconfigs: x86_64-allnoconfig arm-allmodconfig arm-allnoconfig x86_64-allmodconfig x86_64-defconfig Errors: x86_64-allnoconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode arm-allnoconfig /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:99:30: fatal error: linux/compiler-gcc5.h: No such file or directory x86_64-allmodconfig /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode x86_64-defconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 5 warnings 0 mismatches : arm-allmodconfig ------------------------------------------------------------------------------- Errors summary: 3 3 /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode 3 /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode 1 /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:99:30: fatal error: linux/compiler-gcc5.h: No such file or directory Warnings Summary: 2 3 warning: (IMA) selects TCG_TIS which has unmet direct dependencies (TCG_TPM && X86) 2 .config:26:warning: symbol value '' invalid for PHYS_OFFSET =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- x86_64-allnoconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- arm-allmodconfig : FAIL, 0 errors, 5 warnings, 0 section mismatches Warnings: warning: (IMA) selects TCG_TIS which has unmet direct dependencies (TCG_TPM && X86) .config:26:warning: symbol value '' invalid for PHYS_OFFSET warning: (IMA) selects TCG_TIS which has unmet direct dependencies (TCG_TPM && X86) .config:26:warning: symbol value '' invalid for PHYS_OFFSET warning: (IMA) selects TCG_TIS which has unmet direct dependencies (TCG_TPM && X86) ------------------------------------------------------------------------------- arm-allnoconfig : FAIL, 1 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/include/linux/compiler-gcc.h:99:30: fatal error: linux/compiler-gcc5.h: No such file or directory ------------------------------------------------------------------------------- x86_64-allmodconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- x86_64-defconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches:

7 years, 1 month

1
0
0 0

v3.2.100 build: 5 failures 20 warnings (v3.2.100)

by Build bot for Mark Brown

Tree/Branch: v3.2.100 Git describe: v3.2.100 Commit: 1c7cb8cda9 Linux 3.2.100 Build Time: 0 min 4 sec Passed: 0 / 5 ( 0.00 %) Failed: 5 / 5 (100.00 %) Errors: 6 Warnings: 20 Section Mismatches: 0 Failed defconfigs: x86_64-allnoconfig arm-allmodconfig arm-allnoconfig x86_64-allmodconfig x86_64-defconfig Errors: x86_64-allnoconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode arm-allnoconfig /home/broonie/build/linux-stable/arch/arm/include/asm/div64.h:77:7: error: '__LINUX_ARM_ARCH__' undeclared (first use in this function) /home/broonie/build/linux-stable/arch/arm/include/asm/glue-cache.h:129:2: error: #error Unknown cache maintenance model /home/broonie/build/linux-stable/arch/arm/include/asm/glue-df.h:107:2: error: #error Unknown data abort handler type /home/broonie/build/linux-stable/arch/arm/include/asm/glue-pf.h:54:2: error: #error Unknown prefetch abort handler type x86_64-allmodconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode x86_64-defconfig /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 2 warnings 0 mismatches : arm-allmodconfig 19 warnings 0 mismatches : arm-allnoconfig ------------------------------------------------------------------------------- Errors summary: 6 3 /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode 3 /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode 1 /home/broonie/build/linux-stable/arch/arm/include/asm/glue-pf.h:54:2: error: #error Unknown prefetch abort handler type 1 /home/broonie/build/linux-stable/arch/arm/include/asm/glue-df.h:107:2: error: #error Unknown data abort handler type 1 /home/broonie/build/linux-stable/arch/arm/include/asm/glue-cache.h:129:2: error: #error Unknown cache maintenance model 1 /home/broonie/build/linux-stable/arch/arm/include/asm/div64.h:77:7: error: '__LINUX_ARM_ARCH__' undeclared (first use in this function) Warnings Summary: 20 2 .config:27:warning: symbol value '' invalid for PHYS_OFFSET 1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:342:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:272:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:265:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:131:35: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:127:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:121:3: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:120:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:114:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/swab.h:25:28: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:82:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:102:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/irqflags.h:11:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/fpstate.h:32:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:33:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:28:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:196:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:194:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/bitops.h:217:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] 1 /home/broonie/build/linux-stable/arch/arm/include/asm/atomic.h:30:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- x86_64-allnoconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- arm-allmodconfig : FAIL, 0 errors, 2 warnings, 0 section mismatches Warnings: .config:27:warning: symbol value '' invalid for PHYS_OFFSET .config:27:warning: symbol value '' invalid for PHYS_OFFSET ------------------------------------------------------------------------------- arm-allnoconfig : FAIL, 4 errors, 19 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/arch/arm/include/asm/div64.h:77:7: error: '__LINUX_ARM_ARCH__' undeclared (first use in this function) /home/broonie/build/linux-stable/arch/arm/include/asm/glue-cache.h:129:2: error: #error Unknown cache maintenance model /home/broonie/build/linux-stable/arch/arm/include/asm/glue-df.h:107:2: error: #error Unknown data abort handler type /home/broonie/build/linux-stable/arch/arm/include/asm/glue-pf.h:54:2: error: #error Unknown prefetch abort handler type Warnings: /home/broonie/build/linux-stable/arch/arm/include/asm/irqflags.h:11:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:114:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:120:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:121:3: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:127:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:131:35: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:265:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:272:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/system.h:342:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/bitops.h:217:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/swab.h:25:28: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/fpstate.h:32:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:82:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/processor.h:102:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/atomic.h:30:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:28:5: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/cachetype.h:33:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:194:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] /home/broonie/build/linux-stable/arch/arm/include/asm/cacheflush.h:196:7: warning: "__LINUX_ARM_ARCH__" is not defined [-Wundef] ------------------------------------------------------------------------------- x86_64-allmodconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- x86_64-defconfig : FAIL, 2 errors, 0 warnings, 0 section mismatches Errors: /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode /home/broonie/build/linux-stable/kernel/bounds.c:1:0: error: code model kernel does not support PIC mode ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches:

7 years, 1 month

1
0
0 0

Applied "spi: Fix unregistration of controller with fixed SPI bus number" to the regulator tree

by Mark Brown

The patch spi: Fix unregistration of controller with fixed SPI bus number has been applied to the regulator tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From 9fca7d15487654dab119d0868501db30f80ac46a Mon Sep 17 00:00:00 2001 From: Jarkko Nikula <jarkko.nikula(a)linux.intel.com> Date: Tue, 6 Mar 2018 17:47:22 +0200 Subject: [PATCH] spi: Fix unregistration of controller with fixed SPI bus number Commit 9b61e302210e (spi: Pick spi bus number from Linux idr or spi alias) ceased to unregister SPI buses with fixed bus numbers. Moreover this is visible only if CONFIG_SPI_DEBUG=y is set or when trying to re-register the same SPI controller. rmmod spi_pxa2xx_platform (with CONFIG_SPI_DEBUG=y): [ 26.788362] spi_master spi1: attempting to delete unregistered controller [spi1] modprobe spi_pxa2xx_platform: [ 37.883137] sysfs: cannot create duplicate filename '/devices/pci0000:00/0000:00:19.0/pxa2xx-spi.12/spi_master/spi1' [ 37.894984] CPU: 1 PID: 1467 Comm: modprobe Not tainted 4.16.0-rc4+ #21 [ 37.902384] Call Trace: ... [ 38.122680] kobject_add_internal failed for spi1 with -EEXIST, don't try to register things with the same name in the same directory. [ 38.136154] WARNING: CPU: 1 PID: 1467 at lib/kobject.c:238 kobject_add_internal+0x2a5/0x2f0 ... [ 38.513817] pxa2xx-spi pxa2xx-spi.12: problem registering spi master [ 38.521036] pxa2xx-spi: probe of pxa2xx-spi.12 failed with error -17 Fix this by not returning immediately from spi_unregister_controller() if idr_find() doesn't find controller with given ID/bus number. It finds only those controllers that were registered with dynamic SPI bus numbers. Only conditional cleanup between dynamic and fixed bus numbers is to remove allocated IDR. Fixes: 9b61e302210e (spi: Pick spi bus number from Linux idr or spi alias) Signed-off-by: Jarkko Nikula <jarkko.nikula(a)linux.intel.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> Cc: stable(a)vger.kernel.org --- drivers/spi/spi.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index b33a727a0158..e90fd442b3f0 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -2254,12 +2254,6 @@ void spi_unregister_controller(struct spi_controller *ctlr) mutex_lock(&board_lock); found = idr_find(&spi_master_idr, id); mutex_unlock(&board_lock); - if (found != ctlr) { - dev_dbg(&ctlr->dev, - "attempting to delete unregistered controller [%s]\n", - dev_name(&ctlr->dev)); - return; - } if (ctlr->queued) { if (spi_destroy_queue(ctlr)) dev_err(&ctlr->dev, "queue remove failed\n"); @@ -2272,7 +2266,8 @@ void spi_unregister_controller(struct spi_controller *ctlr) device_unregister(&ctlr->dev); /* free bus id */ mutex_lock(&board_lock); - idr_remove(&spi_master_idr, id); + if (found == ctlr) + idr_remove(&spi_master_idr, id); mutex_unlock(&board_lock); } EXPORT_SYMBOL_GPL(spi_unregister_controller); -- 2.16.2

7 years, 1 month

2
1
0 0

v3.18.100 build: 0 failures 1 warnings (v3.18.100)

by Build bot for Mark Brown

Tree/Branch: v3.18.100 Git describe: v3.18.100 Commit: 5fcd937491 Linux 3.18.100 Build Time: 45 min 12 sec Passed: 10 / 10 (100.00 %) Failed: 0 / 10 ( 0.00 %) Errors: 0 Warnings: 1 Section Mismatches: 0 ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 7 warnings 0 mismatches : x86_64-allmodconfig 2 warnings 0 mismatches : x86_64-defconfig ------------------------------------------------------------------------------- Warnings Summary: 1 9 ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- x86_64-allmodconfig : PASS, 0 errors, 7 warnings, 0 section mismatches Warnings: ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ------------------------------------------------------------------------------- x86_64-defconfig : PASS, 0 errors, 2 warnings, 0 section mismatches Warnings: ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ../include/linux/ftrace.h:632:36: warning: calling '__builtin_return_address' with a nonzero argument is unsafe [-Wframe-address] ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: arm64-allnoconfig arm64-allmodconfig arm-multi_v5_defconfig arm-multi_v7_defconfig arm-allmodconfig arm-allnoconfig x86_64-allnoconfig arm64-defconfig

7 years, 1 month

1
0
0 0

[PATCH] mtd: rawnand: fsl_ifc: Fix nand waitfunc return value

by Jagdish Gediya

As per the IFC hardware manual, Most significant 2 bytes in nand_fsr register are the outcome of NAND READ STATUS command. So status value need to be shifted and aligned as per the nand framework requirement. Cc: stable(a)vger.kernel.org Signed-off-by: Jagdish Gediya <jagdish.gediya(a)nxp.com> Reviewed-by: Prabhakar Kushwaha <prabhakar.kushwaha(a)nxp.com> --- drivers/mtd/nand/fsl_ifc_nand.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c index d9ce398..951dd89 100644 --- a/drivers/mtd/nand/fsl_ifc_nand.c +++ b/drivers/mtd/nand/fsl_ifc_nand.c @@ -643,12 +643,13 @@ static int fsl_ifc_wait(struct mtd_info *mtd, struct nand_chip *chip) fsl_ifc_run_command(mtd); nand_fsr = ifc_in32(&ifc->ifc_nand.nand_fsr); - + nand_fsr >>= 16; + nand_fsr = (nand_fsr >> 8) | (nand_fsr << 8); /* * The chip always seems to report that it is * write-protected, even when it is not. */ - return nand_fsr | NAND_STATUS_WP; + return (nand_fsr & 0xff) | NAND_STATUS_WP; } /* -- 1.9.1

7 years, 1 month

2
1
0 0

[PATCH][v2] mtd: rawnand: fsl_ifc: Fix eccstat array overflow for IFC ver >= 2.0.0

by Jagdish Gediya

Number of ECC status registers i.e. (ECCSTATx) has been increased in IFC version 2.0.0 due to increase in SRAM size. This is causing eccstat array to over flow. So, replace eccstat array with u32 variable to make it fail-safe and independent of number of ECC status registers or SRAM size. Cc: stable(a)vger.kernel.org Signed-off-by: Prabhakar Kushwaha <prabhakar.kushwaha(a)nxp.com> Signed-off-by: Jagdish Gediya <jagdish.gediya(a)nxp.com> --- Changes for v2: Incorporated comments from Miquel Raynal and Boris Brezillon - Updated patch subject - Remove usage of eccstat array - Added Cc: stable(a)vger.kernel.org drivers/mtd/nand/fsl_ifc_nand.c | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-) diff --git a/drivers/mtd/nand/fsl_ifc_nand.c b/drivers/mtd/nand/fsl_ifc_nand.c index 4872a7b..d9ce398 100644 --- a/drivers/mtd/nand/fsl_ifc_nand.c +++ b/drivers/mtd/nand/fsl_ifc_nand.c @@ -173,14 +173,9 @@ static void set_addr(struct mtd_info *mtd, int column, int page_addr, int oob) /* returns nonzero if entire page is blank */ static int check_read_ecc(struct mtd_info *mtd, struct fsl_ifc_ctrl *ctrl, - u32 *eccstat, unsigned int bufnum) + u32 eccstat, unsigned int bufnum) { - u32 reg = eccstat[bufnum / 4]; - int errors; - - errors = (reg >> ((3 - bufnum % 4) * 8)) & 15; - - return errors; + return (eccstat >> ((3 - bufnum % 4) * 8)) & 15; } /* @@ -193,7 +188,7 @@ static void fsl_ifc_run_command(struct mtd_info *mtd) struct fsl_ifc_ctrl *ctrl = priv->ctrl; struct fsl_ifc_nand_ctrl *nctrl = ifc_nand_ctrl; struct fsl_ifc_runtime __iomem *ifc = ctrl->rregs; - u32 eccstat[4]; + u32 eccstat; int i; /* set the chip select for NAND Transaction */ @@ -237,10 +232,18 @@ static void fsl_ifc_run_command(struct mtd_info *mtd) else eccstat_regs = ifc->ifc_nand.v1_nand_eccstat; - for (i = sector / 4; i <= sector_end / 4; i++) - eccstat[i] = ifc_in32(&eccstat_regs[i]); + eccstat = 0; for (i = sector; i <= sector_end; i++) { + + /* + * if page size and sector size both are 512B then + * sector may not be multiple of 4 but sector and + * sector_end will be same. + */ + if ((i % 4 == 0) || (sector == sector_end)) + eccstat = ifc_in32(&eccstat_regs[i / 4]); + errors = check_read_ecc(mtd, ctrl, eccstat, i); if (errors == 15) { -- 1.9.1

7 years, 1 month

2
1
0 0

[PATCH] PCI / PM: Always check PME wakeup capability for runtime wakeup support

by Kai-Heng Feng

USB controller ASM1042 stops working after commit de3ef1eb1cd0 ("PM / core: Drop run_wake flag from struct dev_pm_info"). The device in question is not power managed by platform firmware, furthermore, it only supports PME# from D3cold: Capabilities: [78] Power Management version 3 Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0-,D1-,D2-,D3hot-,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Before the commit, the device never gets runtime suspended. After the commit, the device gets runtime suspended, so it does not respond to any PME#. usb_hcd_pci_probe() mandatorily calls device_wakeup_enable(), hence device_can_wakeup() in pci_dev_run_wake() always returns true. So pci_dev_run_wake() needs to check PME wakeup capability as its first condition. Fixes: de3ef1eb1cd0 ("PM / core: Drop run_wake flag from struct dev_pm_info") Cc: stable(a)vger.kernel.org # 4.13+ Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> --- drivers/pci/pci.c | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index f6a4dd10d9b0..e026d8f313ec 100644 --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -2125,16 +2125,13 @@ bool pci_dev_run_wake(struct pci_dev *dev) { struct pci_bus *bus = dev->bus; - if (device_can_wakeup(&dev->dev)) - return true; - - if (!dev->pme_support) - return false; - /* PME-capable in principle, but not from the target power state */ - if (!pci_pme_capable(dev, pci_target_state(dev, false))) + if (!pci_pme_capable(dev, pci_target_state(dev, true))) return false; + if (device_can_wakeup(&dev->dev)) + return true; + while (bus->parent) { struct pci_dev *bridge = bus->self; -- 2.15.1

7 years, 1 month

3
2
0 0

[PATCH] can: cc770: Fix use after free in cc770_tx_interrupt()

by Marc Kleine-Budde

From: Andri Yngvason <andri.yngvason(a)marel.com> This fixes use after free introduced by the last cc770 patch. Signed-off-by: Andri Yngvason <andri.yngvason(a)marel.com> Fixes: 746201235b3f ("can: cc770: Fix queue stall & dropped RTR reply") Cc: linux-stable <stable(a)vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> --- drivers/net/can/cc770/cc770.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/net/can/cc770/cc770.c b/drivers/net/can/cc770/cc770.c index 2743d82d4424..6da69af103e6 100644 --- a/drivers/net/can/cc770/cc770.c +++ b/drivers/net/can/cc770/cc770.c @@ -706,13 +706,12 @@ static void cc770_tx_interrupt(struct net_device *dev, unsigned int o) return; } - can_put_echo_skb(priv->tx_skb, dev, 0); - can_get_echo_skb(dev, 0); - cf = (struct can_frame *)priv->tx_skb->data; stats->tx_bytes += cf->can_dlc; stats->tx_packets++; + can_put_echo_skb(priv->tx_skb, dev, 0); + can_get_echo_skb(dev, 0); priv->tx_skb = NULL; netif_wake_queue(dev); -- 2.16.2

7 years, 1 month

1
0
0 0

Patch "x86/vm86/32: Fix POPF emulation" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/vm86/32: Fix POPF emulation to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-vm86-32-fix-popf-emulation.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From b5069782453459f6ec1fdeb495d9901a4545fcb5 Mon Sep 17 00:00:00 2001 From: Andy Lutomirski <luto(a)kernel.org> Date: Tue, 13 Mar 2018 22:03:12 -0700 Subject: x86/vm86/32: Fix POPF emulation From: Andy Lutomirski <luto(a)kernel.org> commit b5069782453459f6ec1fdeb495d9901a4545fcb5 upstream. POPF would trap if VIP was set regardless of whether IF was set. Fix it. Suggested-by: Stas Sergeev <stsp(a)list.ru> Reported-by: Bart Oldeman <bartoldeman(a)gmail.com> Signed-off-by: Andy Lutomirski <luto(a)kernel.org> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Denys Vlasenko <dvlasenk(a)redhat.com> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Fixes: 5ed92a8ab71f ("x86/vm86: Use the normal pt_regs area for vm86") Link: http://lkml.kernel.org/r/ce95f40556e7b2178b6bc06ee9557827ff94bd28.152100360… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/vm86_32.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/arch/x86/kernel/vm86_32.c +++ b/arch/x86/kernel/vm86_32.c @@ -719,7 +719,8 @@ void handle_vm86_fault(struct kernel_vm8 return; check_vip: - if (VEFLAGS & X86_EFLAGS_VIP) { + if ((VEFLAGS & (X86_EFLAGS_VIP | X86_EFLAGS_VIF)) == + (X86_EFLAGS_VIP | X86_EFLAGS_VIF)) { save_v86_state(regs, VM86_STI); return; } Patches currently in stable-queue which might be from luto(a)kernel.org are queue-4.9/selftests-x86-add-tests-for-the-str-and-sldt-instructions.patch queue-4.9/x86-speculation-objtool-annotate-indirect-calls-jumps-for-objtool-on-32-bit-kernels.patch queue-4.9/x86-vm86-32-fix-popf-emulation.patch queue-4.9/selftests-x86-add-tests-for-user-mode-instruction-prevention.patch queue-4.9/perf-tools-make-perf_event__synthesize_mmap_events-scale.patch queue-4.9/x86-mm-fix-vmalloc_fault-to-use-pxd_large.patch queue-4.9/x86-mm-make-mmap-map_32bit-work-correctly.patch queue-4.9/selftests-x86-entry_from_vm86-add-test-cases-for-popf.patch queue-4.9/x86-boot-32-defer-resyncing-initial_page_table-until-per-cpu-is-set-up.patch queue-4.9/x86-boot-32-fix-up-boot-on-quark-and-possibly-other-platforms.patch queue-4.9/selftests-x86-entry_from_vm86-exit-with-1-if-we-fail.patch

7 years, 1 month

1
0
0 0

Patch "x86/speculation, objtool: Annotate indirect calls/jumps for objtool on 32-bit kernels" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/speculation, objtool: Annotate indirect calls/jumps for objtool on 32-bit kernels to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-speculation-objtool-annotate-indirect-calls-jumps-for-objtool-on-32-bit-kernels.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From a14bff131108faf50cc0cf864589fd71ee216c96 Mon Sep 17 00:00:00 2001 From: Andy Whitcroft <apw(a)canonical.com> Date: Wed, 14 Mar 2018 11:24:27 +0000 Subject: x86/speculation, objtool: Annotate indirect calls/jumps for objtool on 32-bit kernels From: Andy Whitcroft <apw(a)canonical.com> commit a14bff131108faf50cc0cf864589fd71ee216c96 upstream. In the following commit: 9e0e3c5130e9 ("x86/speculation, objtool: Annotate indirect calls/jumps for objtool") ... we added annotations for CALL_NOSPEC/JMP_NOSPEC on 64-bit x86 kernels, but we did not annotate the 32-bit path. Annotate it similarly. Signed-off-by: Andy Whitcroft <apw(a)canonical.com> Acked-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Arjan van de Ven <arjan(a)linux.intel.com> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Dan Williams <dan.j.williams(a)intel.com> Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: David Woodhouse <dwmw2(a)infradead.org> Cc: David Woodhouse <dwmw(a)amazon.co.uk> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Link: http://lkml.kernel.org/r/20180314112427.22351-1-apw@canonical.com Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/include/asm/nospec-branch.h | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/arch/x86/include/asm/nospec-branch.h +++ b/arch/x86/include/asm/nospec-branch.h @@ -183,7 +183,10 @@ * otherwise we'll run out of registers. We don't care about CET * here, anyway. */ -# define CALL_NOSPEC ALTERNATIVE("call *%[thunk_target]\n", \ +# define CALL_NOSPEC \ + ALTERNATIVE( \ + ANNOTATE_RETPOLINE_SAFE \ + "call *%[thunk_target]\n", \ " jmp 904f;\n" \ " .align 16\n" \ "901: call 903f;\n" \ Patches currently in stable-queue which might be from apw(a)canonical.com are queue-4.9/x86-speculation-objtool-annotate-indirect-calls-jumps-for-objtool-on-32-bit-kernels.patch

7 years, 1 month

1
0
0 0

Patch "x86/speculation: Remove Skylake C2 from Speculation Control microcode blacklist" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/speculation: Remove Skylake C2 from Speculation Control microcode blacklist to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-speculation-remove-skylake-c2-from-speculation-control-microcode-blacklist.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From e3b3121fa8da94cb20f9e0c64ab7981ae47fd085 Mon Sep 17 00:00:00 2001 From: Alexander Sergeyev <sergeev917(a)gmail.com> Date: Tue, 13 Mar 2018 22:38:56 +0300 Subject: x86/speculation: Remove Skylake C2 from Speculation Control microcode blacklist From: Alexander Sergeyev <sergeev917(a)gmail.com> commit e3b3121fa8da94cb20f9e0c64ab7981ae47fd085 upstream. In accordance with Intel's microcode revision guidance from March 6 MCU rev 0xc2 is cleared on both Skylake H/S and Skylake Xeon E3 processors that share CPUID 506E3. Signed-off-by: Alexander Sergeyev <sergeev917(a)gmail.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: Jia Zhang <qianyue.zj(a)alibaba-inc.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Kyle Huey <me(a)kylehuey.com> Cc: David Woodhouse <dwmw(a)amazon.co.uk> Link: https://lkml.kernel.org/r/20180313193856.GA8580@localhost.localdomain Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/cpu/intel.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/arch/x86/kernel/cpu/intel.c +++ b/arch/x86/kernel/cpu/intel.c @@ -64,7 +64,7 @@ void check_mpx_erratum(struct cpuinfo_x8 /* * Early microcode releases for the Spectre v2 mitigation were broken. * Information taken from; - * - https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/microcode-up… + * - https://newsroom.intel.com/wp-content/uploads/sites/11/2018/03/microcode-up… * - https://kb.vmware.com/s/article/52345 * - Microcode revisions observed in the wild * - Release note from 20180108 microcode release @@ -82,7 +82,6 @@ static const struct sku_microcode spectr { INTEL_FAM6_KABYLAKE_MOBILE, 0x09, 0x80 }, { INTEL_FAM6_SKYLAKE_X, 0x03, 0x0100013e }, { INTEL_FAM6_SKYLAKE_X, 0x04, 0x0200003c }, - { INTEL_FAM6_SKYLAKE_DESKTOP, 0x03, 0xc2 }, { INTEL_FAM6_BROADWELL_CORE, 0x04, 0x28 }, { INTEL_FAM6_BROADWELL_GT3E, 0x01, 0x1b }, { INTEL_FAM6_BROADWELL_XEON_D, 0x02, 0x14 }, Patches currently in stable-queue which might be from sergeev917(a)gmail.com are queue-4.9/x86-speculation-remove-skylake-c2-from-speculation-control-microcode-blacklist.patch

7 years, 1 month

1
0
0 0

Patch "x86/cpufeatures: Add Intel PCONFIG cpufeature" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/cpufeatures: Add Intel PCONFIG cpufeature to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-cpufeatures-add-intel-pconfig-cpufeature.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 7958b2246fadf54b7ff820a2a5a2c5ca1554716f Mon Sep 17 00:00:00 2001 From: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com> Date: Mon, 5 Mar 2018 19:25:51 +0300 Subject: x86/cpufeatures: Add Intel PCONFIG cpufeature From: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> commit 7958b2246fadf54b7ff820a2a5a2c5ca1554716f upstream. CPUID.0x7.0x0:EDX[18] indicates whether Intel CPU support PCONFIG instruction. Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Dave Hansen <dave.hansen(a)intel.com> Cc: Kai Huang <kai.huang(a)linux.intel.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Tom Lendacky <thomas.lendacky(a)amd.com> Cc: linux-mm(a)kvack.org Link: http://lkml.kernel.org/r/20180305162610.37510-4-kirill.shutemov@linux.intel… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/include/asm/cpufeatures.h | 1 + 1 file changed, 1 insertion(+) --- a/arch/x86/include/asm/cpufeatures.h +++ b/arch/x86/include/asm/cpufeatures.h @@ -302,6 +302,7 @@ /* Intel-defined CPU features, CPUID level 0x00000007:0 (EDX), word 18 */ #define X86_FEATURE_AVX512_4VNNIW (18*32+ 2) /* AVX-512 Neural Network Instructions */ #define X86_FEATURE_AVX512_4FMAPS (18*32+ 3) /* AVX-512 Multiply Accumulation Single precision */ +#define X86_FEATURE_PCONFIG (18*32+18) /* Intel PCONFIG */ #define X86_FEATURE_SPEC_CTRL (18*32+26) /* "" Speculation Control (IBRS + IBPB) */ #define X86_FEATURE_INTEL_STIBP (18*32+27) /* "" Single Thread Indirect Branch Predictors */ #define X86_FEATURE_ARCH_CAPABILITIES (18*32+29) /* IA32_ARCH_CAPABILITIES MSR (Intel) */ Patches currently in stable-queue which might be from kirill.shutemov(a)linux.intel.com are queue-4.9/x86-cpufeatures-add-intel-pconfig-cpufeature.patch queue-4.9/mm-fix-false-positive-vm_bug_on-in-page_cache_-get-add-_speculative.patch queue-4.9/x86-mm-make-mmap-map_32bit-work-correctly.patch

7 years, 1 month

1
0
0 0

Patch "x86/mm: Fix vmalloc_fault to use pXd_large" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/mm: Fix vmalloc_fault to use pXd_large to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-mm-fix-vmalloc_fault-to-use-pxd_large.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 18a955219bf7d9008ce480d4451b6b8bf4483a22 Mon Sep 17 00:00:00 2001 From: Toshi Kani <toshi.kani(a)hpe.com> Date: Tue, 13 Mar 2018 11:03:46 -0600 Subject: x86/mm: Fix vmalloc_fault to use pXd_large From: Toshi Kani <toshi.kani(a)hpe.com> commit 18a955219bf7d9008ce480d4451b6b8bf4483a22 upstream. Gratian Crisan reported that vmalloc_fault() crashes when CONFIG_HUGETLBFS is not set since the function inadvertently uses pXn_huge(), which always return 0 in this case. ioremap() does not depend on CONFIG_HUGETLBFS. Fix vmalloc_fault() to call pXd_large() instead. Fixes: f4eafd8bcd52 ("x86/mm: Fix vmalloc_fault() to handle large pages properly") Reported-by: Gratian Crisan <gratian.crisan(a)ni.com> Signed-off-by: Toshi Kani <toshi.kani(a)hpe.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Cc: linux-mm(a)kvack.org Cc: Borislav Petkov <bp(a)alien8.de> Cc: Andy Lutomirski <luto(a)kernel.org> Link: https://lkml.kernel.org/r/20180313170347.3829-2-toshi.kani@hpe.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/mm/fault.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/arch/x86/mm/fault.c +++ b/arch/x86/mm/fault.c @@ -343,7 +343,7 @@ static noinline int vmalloc_fault(unsign if (!pmd_k) return -1; - if (pmd_huge(*pmd_k)) + if (pmd_large(*pmd_k)) return 0; pte_k = pte_offset_kernel(pmd_k, address); @@ -463,7 +463,7 @@ static noinline int vmalloc_fault(unsign if (pud_none(*pud) || pud_pfn(*pud) != pud_pfn(*pud_ref)) BUG(); - if (pud_huge(*pud)) + if (pud_large(*pud)) return 0; pmd = pmd_offset(pud, address); @@ -474,7 +474,7 @@ static noinline int vmalloc_fault(unsign if (pmd_none(*pmd) || pmd_pfn(*pmd) != pmd_pfn(*pmd_ref)) BUG(); - if (pmd_huge(*pmd)) + if (pmd_large(*pmd)) return 0; pte_ref = pte_offset_kernel(pmd_ref, address); Patches currently in stable-queue which might be from toshi.kani(a)hpe.com are queue-4.9/x86-mm-fix-vmalloc_fault-to-use-pxd_large.patch

7 years, 1 month

1
0
0 0

Patch "selftests/x86/entry_from_vm86: Add test cases for POPF" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled selftests/x86/entry_from_vm86: Add test cases for POPF to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: selftests-x86-entry_from_vm86-add-test-cases-for-popf.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 78393fdde2a456cafa414b171c90f26a3df98b20 Mon Sep 17 00:00:00 2001 From: Andy Lutomirski <luto(a)kernel.org> Date: Tue, 13 Mar 2018 22:03:11 -0700 Subject: selftests/x86/entry_from_vm86: Add test cases for POPF From: Andy Lutomirski <luto(a)kernel.org> commit 78393fdde2a456cafa414b171c90f26a3df98b20 upstream. POPF is currently broken -- add tests to catch the error. This results in: [RUN] POPF with VIP set and IF clear from vm86 mode [INFO] Exited vm86 mode due to STI [FAIL] Incorrect return reason (started at eip = 0xd, ended at eip = 0xf) because POPF currently fails to check IF before reporting a pending interrupt. This patch also makes the FAIL message a bit more informative. Reported-by: Bart Oldeman <bartoldeman(a)gmail.com> Signed-off-by: Andy Lutomirski <luto(a)kernel.org> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Denys Vlasenko <dvlasenk(a)redhat.com> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Stas Sergeev <stsp(a)list.ru> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Link: http://lkml.kernel.org/r/a16270b5cfe7832d6d00c479d0f871066cbdb52b.152100360… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/x86/entry_from_vm86.c | 30 +++++++++++++++++++++++--- 1 file changed, 27 insertions(+), 3 deletions(-) --- a/tools/testing/selftests/x86/entry_from_vm86.c +++ b/tools/testing/selftests/x86/entry_from_vm86.c @@ -95,6 +95,10 @@ asm ( "int3\n\t" "vmcode_int80:\n\t" "int $0x80\n\t" + "vmcode_popf_hlt:\n\t" + "push %ax\n\t" + "popf\n\t" + "hlt\n\t" "vmcode_umip:\n\t" /* addressing via displacements */ "smsw (2052)\n\t" @@ -124,8 +128,8 @@ asm ( extern unsigned char vmcode[], end_vmcode[]; extern unsigned char vmcode_bound[], vmcode_sysenter[], vmcode_syscall[], - vmcode_sti[], vmcode_int3[], vmcode_int80[], vmcode_umip[], - vmcode_umip_str[], vmcode_umip_sldt[]; + vmcode_sti[], vmcode_int3[], vmcode_int80[], vmcode_popf_hlt[], + vmcode_umip[], vmcode_umip_str[], vmcode_umip_sldt[]; /* Returns false if the test was skipped. */ static bool do_test(struct vm86plus_struct *v86, unsigned long eip, @@ -175,7 +179,7 @@ static bool do_test(struct vm86plus_stru (VM86_TYPE(ret) == rettype && VM86_ARG(ret) == retarg)) { printf("[OK]\tReturned correctly\n"); } else { - printf("[FAIL]\tIncorrect return reason\n"); + printf("[FAIL]\tIncorrect return reason (started at eip = 0x%lx, ended at eip = 0x%lx)\n", eip, v86->regs.eip); nerrs++; } @@ -264,6 +268,9 @@ int main(void) v86.regs.ds = load_addr / 16; v86.regs.es = load_addr / 16; + /* Use the end of the page as our stack. */ + v86.regs.esp = 4096; + assert((v86.regs.cs & 3) == 0); /* Looks like RPL = 0 */ /* #BR -- should deliver SIG??? */ @@ -295,6 +302,23 @@ int main(void) v86.regs.eflags &= ~X86_EFLAGS_IF; do_test(&v86, vmcode_sti - vmcode, VM86_STI, 0, "STI with VIP set"); + /* POPF with VIP set but IF clear: should not trap */ + v86.regs.eflags = X86_EFLAGS_VIP; + v86.regs.eax = 0; + do_test(&v86, vmcode_popf_hlt - vmcode, VM86_UNKNOWN, 0, "POPF with VIP set and IF clear"); + + /* POPF with VIP set and IF set: should trap */ + v86.regs.eflags = X86_EFLAGS_VIP; + v86.regs.eax = X86_EFLAGS_IF; + do_test(&v86, vmcode_popf_hlt - vmcode, VM86_STI, 0, "POPF with VIP and IF set"); + + /* POPF with VIP clear and IF set: should not trap */ + v86.regs.eflags = 0; + v86.regs.eax = X86_EFLAGS_IF; + do_test(&v86, vmcode_popf_hlt - vmcode, VM86_UNKNOWN, 0, "POPF with VIP clear and IF set"); + + v86.regs.eflags = 0; + /* INT3 -- should cause #BP */ do_test(&v86, vmcode_int3 - vmcode, VM86_TRAP, 3, "INT3"); Patches currently in stable-queue which might be from luto(a)kernel.org are queue-4.9/selftests-x86-add-tests-for-the-str-and-sldt-instructions.patch queue-4.9/x86-speculation-objtool-annotate-indirect-calls-jumps-for-objtool-on-32-bit-kernels.patch queue-4.9/x86-vm86-32-fix-popf-emulation.patch queue-4.9/selftests-x86-add-tests-for-user-mode-instruction-prevention.patch queue-4.9/perf-tools-make-perf_event__synthesize_mmap_events-scale.patch queue-4.9/x86-mm-fix-vmalloc_fault-to-use-pxd_large.patch queue-4.9/x86-mm-make-mmap-map_32bit-work-correctly.patch queue-4.9/selftests-x86-entry_from_vm86-add-test-cases-for-popf.patch queue-4.9/x86-boot-32-defer-resyncing-initial_page_table-until-per-cpu-is-set-up.patch queue-4.9/x86-boot-32-fix-up-boot-on-quark-and-possibly-other-platforms.patch queue-4.9/selftests-x86-entry_from_vm86-exit-with-1-if-we-fail.patch

7 years, 1 month

1
0
0 0

Patch "selftests/x86/entry_from_vm86: Exit with 1 if we fail" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled selftests/x86/entry_from_vm86: Exit with 1 if we fail to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: selftests-x86-entry_from_vm86-exit-with-1-if-we-fail.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 327d53d005ca47b10eae940616ed11c569f75a9b Mon Sep 17 00:00:00 2001 From: Andy Lutomirski <luto(a)kernel.org> Date: Tue, 13 Mar 2018 22:03:10 -0700 Subject: selftests/x86/entry_from_vm86: Exit with 1 if we fail From: Andy Lutomirski <luto(a)kernel.org> commit 327d53d005ca47b10eae940616ed11c569f75a9b upstream. Fix a logic error that caused the test to exit with 0 even if test cases failed. Signed-off-by: Andy Lutomirski <luto(a)kernel.org> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Denys Vlasenko <dvlasenk(a)redhat.com> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Stas Sergeev <stsp(a)list.ru> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: bartoldeman(a)gmail.com Cc: stable(a)vger.kernel.org Link: http://lkml.kernel.org/r/b1cc37144038958a469c8f70a5f47a6a5638636a.152100360… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/x86/entry_from_vm86.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/tools/testing/selftests/x86/entry_from_vm86.c +++ b/tools/testing/selftests/x86/entry_from_vm86.c @@ -231,7 +231,7 @@ int main(void) clearhandler(SIGSEGV); /* Make sure nothing explodes if we fork. */ - if (fork() > 0) + if (fork() == 0) return 0; return (nerrs == 0 ? 0 : 1); Patches currently in stable-queue which might be from luto(a)kernel.org are queue-4.9/selftests-x86-add-tests-for-the-str-and-sldt-instructions.patch queue-4.9/x86-speculation-objtool-annotate-indirect-calls-jumps-for-objtool-on-32-bit-kernels.patch queue-4.9/x86-vm86-32-fix-popf-emulation.patch queue-4.9/selftests-x86-add-tests-for-user-mode-instruction-prevention.patch queue-4.9/perf-tools-make-perf_event__synthesize_mmap_events-scale.patch queue-4.9/x86-mm-fix-vmalloc_fault-to-use-pxd_large.patch queue-4.9/x86-mm-make-mmap-map_32bit-work-correctly.patch queue-4.9/selftests-x86-entry_from_vm86-add-test-cases-for-popf.patch queue-4.9/x86-boot-32-defer-resyncing-initial_page_table-until-per-cpu-is-set-up.patch queue-4.9/x86-boot-32-fix-up-boot-on-quark-and-possibly-other-platforms.patch queue-4.9/selftests-x86-entry_from_vm86-exit-with-1-if-we-fail.patch

7 years, 1 month

1
0
0 0

Patch "selftests/x86: Add tests for User-Mode Instruction Prevention" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled selftests/x86: Add tests for User-Mode Instruction Prevention to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: selftests-x86-add-tests-for-user-mode-instruction-prevention.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 9390afebe1d3f5a0be18b1afdd0ce09d67cebf9e Mon Sep 17 00:00:00 2001 From: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> Date: Sun, 5 Nov 2017 18:27:56 -0800 Subject: selftests/x86: Add tests for User-Mode Instruction Prevention From: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> commit 9390afebe1d3f5a0be18b1afdd0ce09d67cebf9e upstream. Certain user space programs that run on virtual-8086 mode may utilize instructions protected by the User-Mode Instruction Prevention (UMIP) security feature present in new Intel processors: SGDT, SIDT and SMSW. In such a case, a general protection fault is issued if UMIP is enabled. When such a fault happens, the kernel traps it and emulates the results of these instructions with dummy values. The purpose of this new test is to verify whether the impacted instructions can be executed without causing such #GP. If no #GP exceptions occur, we expect to exit virtual-8086 mode from INT3. The instructions protected by UMIP are executed in representative use cases: a) displacement-only memory addressing b) register-indirect memory addressing c) results stored directly in operands Unfortunately, it is not possible to check the results against a set of expected values because no emulation will occur in systems that do not have the UMIP feature. Instead, results are printed for verification. A simple verification is done to ensure that results of all tests are identical. Signed-off-by: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> Reviewed-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Borislav Petkov <bp(a)suse.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Chen Yucong <slaoub(a)gmail.com> Cc: Chris Metcalf <cmetcalf(a)mellanox.com> Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: Denys Vlasenko <dvlasenk(a)redhat.com> Cc: Fenghua Yu <fenghua.yu(a)intel.com> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Huang Rui <ray.huang(a)amd.com> Cc: Jiri Slaby <jslaby(a)suse.cz> Cc: Jonathan Corbet <corbet(a)lwn.net> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Michael S. Tsirkin <mst(a)redhat.com> Cc: Paolo Bonzini <pbonzini(a)redhat.com> Cc: Paul Gortmaker <paul.gortmaker(a)windriver.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Ravi V. Shankar <ravi.v.shankar(a)intel.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: Tony Luck <tony.luck(a)intel.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: ricardo.neri(a)intel.com Link: http://lkml.kernel.org/r/1509935277-22138-12-git-send-email-ricardo.neri-ca… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/x86/entry_from_vm86.c | 73 +++++++++++++++++++++++++- 1 file changed, 72 insertions(+), 1 deletion(-) --- a/tools/testing/selftests/x86/entry_from_vm86.c +++ b/tools/testing/selftests/x86/entry_from_vm86.c @@ -95,6 +95,22 @@ asm ( "int3\n\t" "vmcode_int80:\n\t" "int $0x80\n\t" + "vmcode_umip:\n\t" + /* addressing via displacements */ + "smsw (2052)\n\t" + "sidt (2054)\n\t" + "sgdt (2060)\n\t" + /* addressing via registers */ + "mov $2066, %bx\n\t" + "smsw (%bx)\n\t" + "mov $2068, %bx\n\t" + "sidt (%bx)\n\t" + "mov $2074, %bx\n\t" + "sgdt (%bx)\n\t" + /* register operands, only for smsw */ + "smsw %ax\n\t" + "mov %ax, (2080)\n\t" + "int3\n\t" ".size vmcode, . - vmcode\n\t" "end_vmcode:\n\t" ".code32\n\t" @@ -103,7 +119,7 @@ asm ( extern unsigned char vmcode[], end_vmcode[]; extern unsigned char vmcode_bound[], vmcode_sysenter[], vmcode_syscall[], - vmcode_sti[], vmcode_int3[], vmcode_int80[]; + vmcode_sti[], vmcode_int3[], vmcode_int80[], vmcode_umip[]; /* Returns false if the test was skipped. */ static bool do_test(struct vm86plus_struct *v86, unsigned long eip, @@ -160,6 +176,58 @@ static bool do_test(struct vm86plus_stru return true; } +void do_umip_tests(struct vm86plus_struct *vm86, unsigned char *test_mem) +{ + struct table_desc { + unsigned short limit; + unsigned long base; + } __attribute__((packed)); + + /* Initialize variables with arbitrary values */ + struct table_desc gdt1 = { .base = 0x3c3c3c3c, .limit = 0x9999 }; + struct table_desc gdt2 = { .base = 0x1a1a1a1a, .limit = 0xaeae }; + struct table_desc idt1 = { .base = 0x7b7b7b7b, .limit = 0xf1f1 }; + struct table_desc idt2 = { .base = 0x89898989, .limit = 0x1313 }; + unsigned short msw1 = 0x1414, msw2 = 0x2525, msw3 = 3737; + + /* UMIP -- exit with INT3 unless kernel emulation did not trap #GP */ + do_test(vm86, vmcode_umip - vmcode, VM86_TRAP, 3, "UMIP tests"); + + /* Results from displacement-only addressing */ + msw1 = *(unsigned short *)(test_mem + 2052); + memcpy(&idt1, test_mem + 2054, sizeof(idt1)); + memcpy(&gdt1, test_mem + 2060, sizeof(gdt1)); + + /* Results from register-indirect addressing */ + msw2 = *(unsigned short *)(test_mem + 2066); + memcpy(&idt2, test_mem + 2068, sizeof(idt2)); + memcpy(&gdt2, test_mem + 2074, sizeof(gdt2)); + + /* Results when using register operands */ + msw3 = *(unsigned short *)(test_mem + 2080); + + printf("[INFO]\tResult from SMSW:[0x%04x]\n", msw1); + printf("[INFO]\tResult from SIDT: limit[0x%04x]base[0x%08lx]\n", + idt1.limit, idt1.base); + printf("[INFO]\tResult from SGDT: limit[0x%04x]base[0x%08lx]\n", + gdt1.limit, gdt1.base); + + if (msw1 != msw2 || msw1 != msw3) + printf("[FAIL]\tAll the results of SMSW should be the same.\n"); + else + printf("[PASS]\tAll the results from SMSW are identical.\n"); + + if (memcmp(&gdt1, &gdt2, sizeof(gdt1))) + printf("[FAIL]\tAll the results of SGDT should be the same.\n"); + else + printf("[PASS]\tAll the results from SGDT are identical.\n"); + + if (memcmp(&idt1, &idt2, sizeof(idt1))) + printf("[FAIL]\tAll the results of SIDT should be the same.\n"); + else + printf("[PASS]\tAll the results from SIDT are identical.\n"); +} + int main(void) { struct vm86plus_struct v86; @@ -218,6 +286,9 @@ int main(void) v86.regs.eax = (unsigned int)-1; do_test(&v86, vmcode_int80 - vmcode, VM86_INTx, 0x80, "int80"); + /* UMIP -- should exit with INTx 0x80 unless UMIP was not disabled */ + do_umip_tests(&v86, addr); + /* Execute a null pointer */ v86.regs.cs = 0; v86.regs.ss = 0; Patches currently in stable-queue which might be from ricardo.neri-calderon(a)linux.intel.com are queue-4.9/selftests-x86-add-tests-for-the-str-and-sldt-instructions.patch queue-4.9/selftests-x86-add-tests-for-user-mode-instruction-prevention.patch

7 years, 1 month

1
0
0 0

Patch "selftests/x86: Add tests for the STR and SLDT instructions" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled selftests/x86: Add tests for the STR and SLDT instructions to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: selftests-x86-add-tests-for-the-str-and-sldt-instructions.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From a9e017d5619eb371460c8e516f4684def62bef3a Mon Sep 17 00:00:00 2001 From: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> Date: Sun, 5 Nov 2017 18:27:57 -0800 Subject: selftests/x86: Add tests for the STR and SLDT instructions From: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> commit a9e017d5619eb371460c8e516f4684def62bef3a upstream. The STR and SLDT instructions are not valid when running on virtual-8086 mode and generate an invalid operand exception. These two instructions are protected by the Intel User-Mode Instruction Prevention (UMIP) security feature. In protected mode, if UMIP is enabled, these instructions generate a general protection fault if called from CPL > 0. Linux traps the general protection fault and emulates the instructions sgdt, sidt and smsw; but not str and sldt. These tests are added to verify that the emulation code does not emulate these two instructions but the expected invalid operand exception is seen. Tests fallback to exit with INT3 in case emulation does happen. Signed-off-by: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> Reviewed-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Borislav Petkov <bp(a)suse.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Chen Yucong <slaoub(a)gmail.com> Cc: Chris Metcalf <cmetcalf(a)mellanox.com> Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: Denys Vlasenko <dvlasenk(a)redhat.com> Cc: Fenghua Yu <fenghua.yu(a)intel.com> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Huang Rui <ray.huang(a)amd.com> Cc: Jiri Slaby <jslaby(a)suse.cz> Cc: Jonathan Corbet <corbet(a)lwn.net> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Michael S. Tsirkin <mst(a)redhat.com> Cc: Paolo Bonzini <pbonzini(a)redhat.com> Cc: Paul Gortmaker <paul.gortmaker(a)windriver.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Ravi V. Shankar <ravi.v.shankar(a)intel.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: Tony Luck <tony.luck(a)intel.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: ricardo.neri(a)intel.com Link: http://lkml.kernel.org/r/1509935277-22138-13-git-send-email-ricardo.neri-ca… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/x86/entry_from_vm86.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) --- a/tools/testing/selftests/x86/entry_from_vm86.c +++ b/tools/testing/selftests/x86/entry_from_vm86.c @@ -111,6 +111,11 @@ asm ( "smsw %ax\n\t" "mov %ax, (2080)\n\t" "int3\n\t" + "vmcode_umip_str:\n\t" + "str %eax\n\t" + "vmcode_umip_sldt:\n\t" + "sldt %eax\n\t" + "int3\n\t" ".size vmcode, . - vmcode\n\t" "end_vmcode:\n\t" ".code32\n\t" @@ -119,7 +124,8 @@ asm ( extern unsigned char vmcode[], end_vmcode[]; extern unsigned char vmcode_bound[], vmcode_sysenter[], vmcode_syscall[], - vmcode_sti[], vmcode_int3[], vmcode_int80[], vmcode_umip[]; + vmcode_sti[], vmcode_int3[], vmcode_int80[], vmcode_umip[], + vmcode_umip_str[], vmcode_umip_sldt[]; /* Returns false if the test was skipped. */ static bool do_test(struct vm86plus_struct *v86, unsigned long eip, @@ -226,6 +232,16 @@ void do_umip_tests(struct vm86plus_struc printf("[FAIL]\tAll the results of SIDT should be the same.\n"); else printf("[PASS]\tAll the results from SIDT are identical.\n"); + + sethandler(SIGILL, sighandler, 0); + do_test(vm86, vmcode_umip_str - vmcode, VM86_SIGNAL, 0, + "STR instruction"); + clearhandler(SIGILL); + + sethandler(SIGILL, sighandler, 0); + do_test(vm86, vmcode_umip_sldt - vmcode, VM86_SIGNAL, 0, + "SLDT instruction"); + clearhandler(SIGILL); } int main(void) Patches currently in stable-queue which might be from ricardo.neri-calderon(a)linux.intel.com are queue-4.9/selftests-x86-add-tests-for-the-str-and-sldt-instructions.patch queue-4.9/selftests-x86-add-tests-for-user-mode-instruction-prevention.patch

7 years, 1 month

1
0
0 0

Patch "parisc: Handle case where flush_cache_range is called with no context" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled parisc: Handle case where flush_cache_range is called with no context to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: parisc-handle-case-where-flush_cache_range-is-called-with-no-context.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 9ef0f88fe5466c2ca1d2975549ba6be502c464c1 Mon Sep 17 00:00:00 2001 From: John David Anglin <dave.anglin(a)bell.net> Date: Wed, 7 Mar 2018 08:18:05 -0500 Subject: parisc: Handle case where flush_cache_range is called with no context MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: John David Anglin <dave.anglin(a)bell.net> commit 9ef0f88fe5466c2ca1d2975549ba6be502c464c1 upstream. Just when I had decided that flush_cache_range() was always called with a valid context, Helge reported two cases where the "BUG_ON(!vma->vm_mm->context);" was hit on the phantom buildd: kernel BUG at /mnt/sdb6/linux/linux-4.15.4/arch/parisc/kernel/cache.c:587! CPU: 1 PID: 3254 Comm: kworker/1:2 Tainted: G D 4.15.0-1-parisc64-smp #1 Debian 4.15.4-1+b1 Workqueue: events free_ioctx IAOQ[0]: flush_cache_range+0x164/0x168 IAOQ[1]: flush_cache_page+0x0/0x1c8 RP(r2): unmap_page_range+0xae8/0xb88 Backtrace: [<00000000404a6980>] unmap_page_range+0xae8/0xb88 [<00000000404a6ae0>] unmap_single_vma+0xc0/0x188 [<00000000404a6cdc>] zap_page_range_single+0x134/0x1f8 [<00000000404a702c>] unmap_mapping_range+0x1cc/0x208 [<0000000040461518>] truncate_pagecache+0x98/0x108 [<0000000040461624>] truncate_setsize+0x9c/0xb8 [<00000000405d7f30>] put_aio_ring_file+0x80/0x100 [<00000000405d803c>] aio_free_ring+0x8c/0x290 [<00000000405d82c0>] free_ioctx+0x80/0x180 [<0000000040284e6c>] process_one_work+0x21c/0x668 [<00000000402854c4>] worker_thread+0x20c/0x778 [<0000000040291d44>] kthread+0x2d4/0x2e0 [<0000000040204020>] end_fault_vector+0x20/0xc0 This indicates that we need to handle the no context case in flush_cache_range() as we do in flush_cache_mm(). In thinking about this, I realized that we don't need to flush the TLB when there is no context. So, I added context checks to the large flush cases in flush_cache_mm() and flush_cache_range(). The large flush case occurs frequently in flush_cache_mm() and the change should improve fork performance. The v2 version of this change removes the BUG_ON from flush_cache_page() by skipping the TLB flush when there is no context. I also added code to flush the TLB in flush_cache_mm() and flush_cache_range() when we have a context that's not current. Now all three routines handle TLB flushes in a similar manner. Signed-off-by: John David Anglin <dave.anglin(a)bell.net> Cc: stable(a)vger.kernel.org # 4.9+ Signed-off-by: Helge Deller <deller(a)gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/parisc/kernel/cache.c | 41 ++++++++++++++++++++++++++++++++--------- 1 file changed, 32 insertions(+), 9 deletions(-) --- a/arch/parisc/kernel/cache.c +++ b/arch/parisc/kernel/cache.c @@ -542,7 +542,8 @@ void flush_cache_mm(struct mm_struct *mm rp3440, etc. So, avoid it if the mm isn't too big. */ if ((!IS_ENABLED(CONFIG_SMP) || !arch_irqs_disabled()) && mm_total_size(mm) >= parisc_cache_flush_threshold) { - flush_tlb_all(); + if (mm->context) + flush_tlb_all(); flush_cache_all(); return; } @@ -570,6 +571,8 @@ void flush_cache_mm(struct mm_struct *mm pfn = pte_pfn(*ptep); if (!pfn_valid(pfn)) continue; + if (unlikely(mm->context)) + flush_tlb_page(vma, addr); __flush_cache_page(vma, addr, PFN_PHYS(pfn)); } } @@ -596,26 +599,46 @@ flush_user_icache_range(unsigned long st void flush_cache_range(struct vm_area_struct *vma, unsigned long start, unsigned long end) { + pgd_t *pgd; + unsigned long addr; + if ((!IS_ENABLED(CONFIG_SMP) || !arch_irqs_disabled()) && end - start >= parisc_cache_flush_threshold) { - flush_tlb_range(vma, start, end); + if (vma->vm_mm->context) + flush_tlb_range(vma, start, end); flush_cache_all(); return; } - flush_user_dcache_range_asm(start, end); - if (vma->vm_flags & VM_EXEC) - flush_user_icache_range_asm(start, end); - flush_tlb_range(vma, start, end); + if (vma->vm_mm->context == mfsp(3)) { + flush_user_dcache_range_asm(start, end); + if (vma->vm_flags & VM_EXEC) + flush_user_icache_range_asm(start, end); + flush_tlb_range(vma, start, end); + return; + } + + pgd = vma->vm_mm->pgd; + for (addr = vma->vm_start; addr < vma->vm_end; addr += PAGE_SIZE) { + unsigned long pfn; + pte_t *ptep = get_ptep(pgd, addr); + if (!ptep) + continue; + pfn = pte_pfn(*ptep); + if (pfn_valid(pfn)) { + if (unlikely(vma->vm_mm->context)) + flush_tlb_page(vma, addr); + __flush_cache_page(vma, addr, PFN_PHYS(pfn)); + } + } } void flush_cache_page(struct vm_area_struct *vma, unsigned long vmaddr, unsigned long pfn) { - BUG_ON(!vma->vm_mm->context); - if (pfn_valid(pfn)) { - flush_tlb_page(vma, vmaddr); + if (likely(vma->vm_mm->context)) + flush_tlb_page(vma, vmaddr); __flush_cache_page(vma, vmaddr, PFN_PHYS(pfn)); } } Patches currently in stable-queue which might be from dave.anglin(a)bell.net are queue-4.9/parisc-handle-case-where-flush_cache_range-is-called-with-no-context.patch

7 years, 1 month

1
0
0 0

Patch "lock_parent() needs to recheck if dentry got __dentry_kill'ed under it" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled lock_parent() needs to recheck if dentry got __dentry_kill'ed under it to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: lock_parent-needs-to-recheck-if-dentry-got-__dentry_kill-ed-under-it.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 3b821409632ab778d46e807516b457dfa72736ed Mon Sep 17 00:00:00 2001 From: Al Viro <viro(a)zeniv.linux.org.uk> Date: Fri, 23 Feb 2018 20:47:17 -0500 Subject: lock_parent() needs to recheck if dentry got __dentry_kill'ed under it From: Al Viro <viro(a)zeniv.linux.org.uk> commit 3b821409632ab778d46e807516b457dfa72736ed upstream. In case when dentry passed to lock_parent() is protected from freeing only by the fact that it's on a shrink list and trylock of parent fails, we could get hit by __dentry_kill() (and subsequent dentry_kill(parent)) between unlocking dentry and locking presumed parent. We need to recheck that dentry is alive once we lock both it and parent *and* postpone rcu_read_unlock() until after that point. Otherwise we could return a pointer to struct dentry that already is rcu-scheduled for freeing, with ->d_lock held on it; caller's subsequent attempt to unlock it can end up with memory corruption. Cc: stable(a)vger.kernel.org # 3.12+, counting backports Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/dcache.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) --- a/fs/dcache.c +++ b/fs/dcache.c @@ -637,11 +637,16 @@ again: spin_unlock(&parent->d_lock); goto again; } - rcu_read_unlock(); - if (parent != dentry) + if (parent != dentry) { spin_lock_nested(&dentry->d_lock, DENTRY_D_LOCK_NESTED); - else + if (unlikely(dentry->d_lockref.count < 0)) { + spin_unlock(&parent->d_lock); + parent = NULL; + } + } else { parent = NULL; + } + rcu_read_unlock(); return parent; } Patches currently in stable-queue which might be from viro(a)zeniv.linux.org.uk are queue-4.9/fs-teach-path_connected-to-handle-nfs-filesystems-with-multiple-roots.patch queue-4.9/lock_parent-needs-to-recheck-if-dentry-got-__dentry_kill-ed-under-it.patch

7 years, 1 month

1
0
0 0

Patch "fs: Teach path_connected to handle nfs filesystems with multiple roots." has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled fs: Teach path_connected to handle nfs filesystems with multiple roots. to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: fs-teach-path_connected-to-handle-nfs-filesystems-with-multiple-roots.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 95dd77580ccd66a0da96e6d4696945b8cea39431 Mon Sep 17 00:00:00 2001 From: "Eric W. Biederman" <ebiederm(a)xmission.com> Date: Wed, 14 Mar 2018 18:20:29 -0500 Subject: fs: Teach path_connected to handle nfs filesystems with multiple roots. From: Eric W. Biederman <ebiederm(a)xmission.com> commit 95dd77580ccd66a0da96e6d4696945b8cea39431 upstream. On nfsv2 and nfsv3 the nfs server can export subsets of the same filesystem and report the same filesystem identifier, so that the nfs client can know they are the same filesystem. The subsets can be from disjoint directory trees. The nfsv2 and nfsv3 filesystems provides no way to find the common root of all directory trees exported form the server with the same filesystem identifier. The practical result is that in struct super s_root for nfs s_root is not necessarily the root of the filesystem. The nfs mount code sets s_root to the root of the first subset of the nfs filesystem that the kernel mounts. This effects the dcache invalidation code in generic_shutdown_super currently called shrunk_dcache_for_umount and that code for years has gone through an additional list of dentries that might be dentry trees that need to be freed to accomodate nfs. When I wrote path_connected I did not realize nfs was so special, and it's hueristic for avoiding calling is_subdir can fail. The practical case where this fails is when there is a move of a directory from the subtree exposed by one nfs mount to the subtree exposed by another nfs mount. This move can happen either locally or remotely. With the remote case requiring that the move directory be cached before the move and that after the move someone walks the path to where the move directory now exists and in so doing causes the already cached directory to be moved in the dcache through the magic of d_splice_alias. If someone whose working directory is in the move directory or a subdirectory and now starts calling .. from the initial mount of nfs (where s_root == mnt_root), then path_connected as a heuristic will not bother with the is_subdir check. As s_root really is not the root of the nfs filesystem this heuristic is wrong, and the path may actually not be connected and path_connected can fail. The is_subdir function might be cheap enough that we can call it unconditionally. Verifying that will take some benchmarking and the result may not be the same on all kernels this fix needs to be backported to. So I am avoiding that for now. Filesystems with snapshots such as nilfs and btrfs do something similar. But as the directory tree of the snapshots are disjoint from one another and from the main directory tree rename won't move things between them and this problem will not occur. Cc: stable(a)vger.kernel.org Reported-by: Al Viro <viro(a)ZenIV.linux.org.uk> Fixes: 397d425dc26d ("vfs: Test for and handle paths that are unreachable from their mnt_root") Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com> Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/namei.c | 5 +++-- fs/nfs/super.c | 2 ++ include/linux/fs.h | 1 + 3 files changed, 6 insertions(+), 2 deletions(-) --- a/fs/namei.c +++ b/fs/namei.c @@ -578,9 +578,10 @@ static int __nd_alloc_stack(struct namei static bool path_connected(const struct path *path) { struct vfsmount *mnt = path->mnt; + struct super_block *sb = mnt->mnt_sb; - /* Only bind mounts can have disconnected paths */ - if (mnt->mnt_root == mnt->mnt_sb->s_root) + /* Bind mounts and multi-root filesystems can have disconnected paths */ + if (!(sb->s_iflags & SB_I_MULTIROOT) && (mnt->mnt_root == sb->s_root)) return true; return is_subdir(path->dentry, mnt->mnt_root); --- a/fs/nfs/super.c +++ b/fs/nfs/super.c @@ -2613,6 +2613,8 @@ struct dentry *nfs_fs_mount_common(struc /* initial superblock/root creation */ mount_info->fill_super(s, mount_info); nfs_get_cache_cookie(s, mount_info->parsed, mount_info->cloned); + if (!(server->flags & NFS_MOUNT_UNSHARED)) + s->s_iflags |= SB_I_MULTIROOT; } mntroot = nfs_get_root(s, mount_info->mntfh, dev_name); --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -1319,6 +1319,7 @@ struct mm_struct; #define SB_I_CGROUPWB 0x00000001 /* cgroup-aware writeback enabled */ #define SB_I_NOEXEC 0x00000002 /* Ignore executables on this fs */ #define SB_I_NODEV 0x00000004 /* Ignore devices on this fs */ +#define SB_I_MULTIROOT 0x00000008 /* Multiple roots to the dentry tree */ /* sb->s_iflags to limit user namespace mounts */ #define SB_I_USERNS_VISIBLE 0x00000010 /* fstype already mounted */ Patches currently in stable-queue which might be from ebiederm(a)xmission.com are queue-4.9/fs-teach-path_connected-to-handle-nfs-filesystems-with-multiple-roots.patch queue-4.9/userns-don-t-fail-follow_automount-based-on-s_user_ns.patch

7 years, 1 month

1
0
0 0

Patch "fs/aio: Use RCU accessors for kioctx_table->table[]" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled fs/aio: Use RCU accessors for kioctx_table->table[] to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: fs-aio-use-rcu-accessors-for-kioctx_table-table.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d0264c01e7587001a8c4608a5d1818dba9a4c11a Mon Sep 17 00:00:00 2001 From: Tejun Heo <tj(a)kernel.org> Date: Wed, 14 Mar 2018 12:10:17 -0700 Subject: fs/aio: Use RCU accessors for kioctx_table->table[] From: Tejun Heo <tj(a)kernel.org> commit d0264c01e7587001a8c4608a5d1818dba9a4c11a upstream. While converting ioctx index from a list to a table, db446a08c23d ("aio: convert the ioctx list to table lookup v3") missed tagging kioctx_table->table[] as an array of RCU pointers and using the appropriate RCU accessors. This introduces a small window in the lookup path where init and access may race. Mark kioctx_table->table[] with __rcu and use the approriate RCU accessors when using the field. Signed-off-by: Tejun Heo <tj(a)kernel.org> Reported-by: Jann Horn <jannh(a)google.com> Fixes: db446a08c23d ("aio: convert the ioctx list to table lookup v3") Cc: Benjamin LaHaise <bcrl(a)kvack.org> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: stable(a)vger.kernel.org # v3.12+ Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/aio.c | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) --- a/fs/aio.c +++ b/fs/aio.c @@ -68,9 +68,9 @@ struct aio_ring { #define AIO_RING_PAGES 8 struct kioctx_table { - struct rcu_head rcu; - unsigned nr; - struct kioctx *table[]; + struct rcu_head rcu; + unsigned nr; + struct kioctx __rcu *table[]; }; struct kioctx_cpu { @@ -330,7 +330,7 @@ static int aio_ring_mremap(struct vm_are for (i = 0; i < table->nr; i++) { struct kioctx *ctx; - ctx = table->table[i]; + ctx = rcu_dereference(table->table[i]); if (ctx && ctx->aio_ring_file == file) { if (!atomic_read(&ctx->dead)) { ctx->user_id = ctx->mmap_base = vma->vm_start; @@ -659,9 +659,9 @@ static int ioctx_add_table(struct kioctx while (1) { if (table) for (i = 0; i < table->nr; i++) - if (!table->table[i]) { + if (!rcu_access_pointer(table->table[i])) { ctx->id = i; - table->table[i] = ctx; + rcu_assign_pointer(table->table[i], ctx); spin_unlock(&mm->ioctx_lock); /* While kioctx setup is in progress, @@ -836,8 +836,8 @@ static int kill_ioctx(struct mm_struct * } table = rcu_dereference_raw(mm->ioctx_table); - WARN_ON(ctx != table->table[ctx->id]); - table->table[ctx->id] = NULL; + WARN_ON(ctx != rcu_access_pointer(table->table[ctx->id])); + RCU_INIT_POINTER(table->table[ctx->id], NULL); spin_unlock(&mm->ioctx_lock); /* free_ioctx_reqs() will do the necessary RCU synchronization */ @@ -882,7 +882,8 @@ void exit_aio(struct mm_struct *mm) skipped = 0; for (i = 0; i < table->nr; ++i) { - struct kioctx *ctx = table->table[i]; + struct kioctx *ctx = + rcu_dereference_protected(table->table[i], true); if (!ctx) { skipped++; @@ -1071,7 +1072,7 @@ static struct kioctx *lookup_ioctx(unsig if (!table || id >= table->nr) goto out; - ctx = table->table[id]; + ctx = rcu_dereference(table->table[id]); if (ctx && ctx->user_id == ctx_id) { percpu_ref_get(&ctx->users); ret = ctx; Patches currently in stable-queue which might be from tj(a)kernel.org are queue-4.9/fs-aio-add-explicit-rcu-grace-period-when-freeing-kioctx.patch queue-4.9/fs-aio-use-rcu-accessors-for-kioctx_table-table.patch

7 years, 1 month

1
0
0 0

Patch "fs/aio: Add explicit RCU grace period when freeing kioctx" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled fs/aio: Add explicit RCU grace period when freeing kioctx to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: fs-aio-add-explicit-rcu-grace-period-when-freeing-kioctx.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From a6d7cff472eea87d96899a20fa718d2bab7109f3 Mon Sep 17 00:00:00 2001 From: Tejun Heo <tj(a)kernel.org> Date: Wed, 14 Mar 2018 12:10:17 -0700 Subject: fs/aio: Add explicit RCU grace period when freeing kioctx From: Tejun Heo <tj(a)kernel.org> commit a6d7cff472eea87d96899a20fa718d2bab7109f3 upstream. While fixing refcounting, e34ecee2ae79 ("aio: Fix a trinity splat") incorrectly removed explicit RCU grace period before freeing kioctx. The intention seems to be depending on the internal RCU grace periods of percpu_ref; however, percpu_ref uses a different flavor of RCU, sched-RCU. This can lead to kioctx being freed while RCU read protected dereferences are still in progress. Fix it by updating free_ioctx() to go through call_rcu() explicitly. v2: Comment added to explain double bouncing. Signed-off-by: Tejun Heo <tj(a)kernel.org> Reported-by: Jann Horn <jannh(a)google.com> Fixes: e34ecee2ae79 ("aio: Fix a trinity splat") Cc: Kent Overstreet <kent.overstreet(a)gmail.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: stable(a)vger.kernel.org # v3.13+ Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/aio.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-) --- a/fs/aio.c +++ b/fs/aio.c @@ -115,7 +115,8 @@ struct kioctx { struct page **ring_pages; long nr_pages; - struct work_struct free_work; + struct rcu_head free_rcu; + struct work_struct free_work; /* see free_ioctx() */ /* * signals when all in-flight requests are done @@ -581,6 +582,12 @@ static int kiocb_cancel(struct aio_kiocb return cancel(&kiocb->common); } +/* + * free_ioctx() should be RCU delayed to synchronize against the RCU + * protected lookup_ioctx() and also needs process context to call + * aio_free_ring(), so the double bouncing through kioctx->free_rcu and + * ->free_work. + */ static void free_ioctx(struct work_struct *work) { struct kioctx *ctx = container_of(work, struct kioctx, free_work); @@ -594,6 +601,14 @@ static void free_ioctx(struct work_struc kmem_cache_free(kioctx_cachep, ctx); } +static void free_ioctx_rcufn(struct rcu_head *head) +{ + struct kioctx *ctx = container_of(head, struct kioctx, free_rcu); + + INIT_WORK(&ctx->free_work, free_ioctx); + schedule_work(&ctx->free_work); +} + static void free_ioctx_reqs(struct percpu_ref *ref) { struct kioctx *ctx = container_of(ref, struct kioctx, reqs); @@ -602,8 +617,8 @@ static void free_ioctx_reqs(struct percp if (ctx->rq_wait && atomic_dec_and_test(&ctx->rq_wait->count)) complete(&ctx->rq_wait->comp); - INIT_WORK(&ctx->free_work, free_ioctx); - schedule_work(&ctx->free_work); + /* Synchronize against RCU protected table->table[] dereferences */ + call_rcu(&ctx->free_rcu, free_ioctx_rcufn); } /* @@ -825,7 +840,7 @@ static int kill_ioctx(struct mm_struct * table->table[ctx->id] = NULL; spin_unlock(&mm->ioctx_lock); - /* percpu_ref_kill() will do the necessary call_rcu() */ + /* free_ioctx_reqs() will do the necessary RCU synchronization */ wake_up_all(&ctx->wait); /* Patches currently in stable-queue which might be from tj(a)kernel.org are queue-4.9/fs-aio-add-explicit-rcu-grace-period-when-freeing-kioctx.patch queue-4.9/fs-aio-use-rcu-accessors-for-kioctx_table-table.patch

7 years, 1 month

1
0
0 0

Patch "drm/amdgpu: fix prime teardown order" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/amdgpu: fix prime teardown order to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-amdgpu-fix-prime-teardown-order.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 342038d92403b3efa1138a8599666b9f026279d6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Christian=20K=C3=B6nig?= <christian.koenig(a)amd.com> Date: Fri, 9 Mar 2018 14:42:54 +0100 Subject: drm/amdgpu: fix prime teardown order MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Christian König <christian.koenig(a)amd.com> commit 342038d92403b3efa1138a8599666b9f026279d6 upstream. We unmapped imported DMA-bufs when the GEM handle was dropped, not when the hardware was done with the buffere. Signed-off-by: Christian König <christian.koenig(a)amd.com> Reviewed-by: Michel Dänzer <michel.daenzer(a)amd.com> CC: stable(a)vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 -- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 ++ 2 files changed, 2 insertions(+), 2 deletions(-) --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c @@ -36,8 +36,6 @@ void amdgpu_gem_object_free(struct drm_g struct amdgpu_bo *robj = gem_to_amdgpu_bo(gobj); if (robj) { - if (robj->gem_base.import_attach) - drm_prime_gem_destroy(&robj->gem_base, robj->tbo.sg); amdgpu_mn_unregister(robj); amdgpu_bo_unref(&robj); } --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c @@ -94,6 +94,8 @@ static void amdgpu_ttm_bo_destroy(struct amdgpu_update_memory_usage(bo->adev, &bo->tbo.mem, NULL); + if (bo->gem_base.import_attach) + drm_prime_gem_destroy(&bo->gem_base, bo->tbo.sg); drm_gem_object_release(&bo->gem_base); amdgpu_bo_unref(&bo->parent); if (!list_empty(&bo->shadow_list)) { Patches currently in stable-queue which might be from christian.koenig(a)amd.com are queue-4.9/drm-ttm-never-add-bo-that-failed-to-validate-to-the-lru-list.patch queue-4.9/drm-amdgpu-fail-fb-creation-from-imported-dma-bufs.-v2.patch queue-4.9/drm-radeon-fail-fb-creation-from-imported-dma-bufs.patch queue-4.9/drm-amdgpu-fix-prime-teardown-order.patch queue-4.9/drm-edid-set-eld-connector-type-in-drm_edid_to_eld.patch

7 years, 1 month

1
0
0 0

Patch "drm/amdgpu/dce: Don't turn off DP sink when disconnected" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/amdgpu/dce: Don't turn off DP sink when disconnected to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-amdgpu-dce-don-t-turn-off-dp-sink-when-disconnected.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 7d617264eb22b18d979eac6e85877a141253034e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Michel=20D=C3=A4nzer?= <michel.daenzer(a)amd.com> Date: Fri, 9 Mar 2018 18:26:18 +0100 Subject: drm/amdgpu/dce: Don't turn off DP sink when disconnected MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Michel Dänzer <michel.daenzer(a)amd.com> commit 7d617264eb22b18d979eac6e85877a141253034e upstream. Turning off the sink in this case causes various issues, because userspace expects it to stay on until it turns it off explicitly. Instead, turn the sink off and back on when a display is connected again. This dance seems necessary for link training to work correctly. Bugzilla: https://bugs.freedesktop.org/105308 Cc: stable(a)vger.kernel.org Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Michel Dänzer <michel.daenzer(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 29 +++++++++---------------- 1 file changed, 11 insertions(+), 18 deletions(-) --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c @@ -69,25 +69,18 @@ void amdgpu_connector_hotplug(struct drm /* don't do anything if sink is not display port, i.e., * passive dp->(dvi|hdmi) adaptor */ - if (dig_connector->dp_sink_type == CONNECTOR_OBJECT_ID_DISPLAYPORT) { - int saved_dpms = connector->dpms; - /* Only turn off the display if it's physically disconnected */ - if (!amdgpu_display_hpd_sense(adev, amdgpu_connector->hpd.hpd)) { - drm_helper_connector_dpms(connector, DRM_MODE_DPMS_OFF); - } else if (amdgpu_atombios_dp_needs_link_train(amdgpu_connector)) { - /* Don't try to start link training before we - * have the dpcd */ - if (amdgpu_atombios_dp_get_dpcd(amdgpu_connector)) - return; + if (dig_connector->dp_sink_type == CONNECTOR_OBJECT_ID_DISPLAYPORT && + amdgpu_display_hpd_sense(adev, amdgpu_connector->hpd.hpd) && + amdgpu_atombios_dp_needs_link_train(amdgpu_connector)) { + /* Don't start link training before we have the DPCD */ + if (amdgpu_atombios_dp_get_dpcd(amdgpu_connector)) + return; - /* set it to OFF so that drm_helper_connector_dpms() - * won't return immediately since the current state - * is ON at this point. - */ - connector->dpms = DRM_MODE_DPMS_OFF; - drm_helper_connector_dpms(connector, DRM_MODE_DPMS_ON); - } - connector->dpms = saved_dpms; + /* Turn the connector off and back on immediately, which + * will trigger link training + */ + drm_helper_connector_dpms(connector, DRM_MODE_DPMS_OFF); + drm_helper_connector_dpms(connector, DRM_MODE_DPMS_ON); } } } Patches currently in stable-queue which might be from michel.daenzer(a)amd.com are queue-4.9/drm-amdgpu-fail-fb-creation-from-imported-dma-bufs.-v2.patch queue-4.9/drm-amdgpu-dce-don-t-turn-off-dp-sink-when-disconnected.patch queue-4.9/drm-radeon-fail-fb-creation-from-imported-dma-bufs.patch queue-4.9/drm-amdgpu-fix-prime-teardown-order.patch

7 years, 1 month

1
0
0 0

Patch "ALSA: seq: Fix possible UAF in snd_seq_check_queue()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: seq: Fix possible UAF in snd_seq_check_queue() to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-seq-fix-possible-uaf-in-snd_seq_check_queue.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d0f833065221cbfcbadf19fd4102bcfa9330006a Mon Sep 17 00:00:00 2001 From: Takashi Iwai <tiwai(a)suse.de> Date: Fri, 9 Mar 2018 21:58:28 +0100 Subject: ALSA: seq: Fix possible UAF in snd_seq_check_queue() From: Takashi Iwai <tiwai(a)suse.de> commit d0f833065221cbfcbadf19fd4102bcfa9330006a upstream. Although we've covered the races between concurrent write() and ioctl() in the previous patch series, there is still a possible UAF in the following scenario: A: user client closed B: timer irq -> snd_seq_release() -> snd_seq_timer_interrupt() -> snd_seq_free_client() -> snd_seq_check_queue() -> cell = snd_seq_prioq_cell_peek() -> snd_seq_prioq_leave() .... removing all cells -> snd_seq_pool_done() .... vfree() -> snd_seq_compare_tick_time(cell) ... Oops So the problem is that a cell is peeked and accessed without any protection until it's retrieved from the queue again via snd_seq_prioq_cell_out(). This patch tries to address it, also cleans up the code by a slight refactoring. snd_seq_prioq_cell_out() now receives an extra pointer argument. When it's non-NULL, the function checks the event timestamp with the given pointer. The caller needs to pass the right reference either to snd_seq_tick or snd_seq_realtime depending on the event timestamp type. A good news is that the above change allows us to remove the snd_seq_prioq_cell_peek(), too, thus the patch actually reduces the code size. Reviewed-by: Nicolai Stange <nstange(a)suse.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/core/seq/seq_prioq.c | 28 ++++++++++++++-------------- sound/core/seq/seq_prioq.h | 6 ++---- sound/core/seq/seq_queue.c | 28 +++++++++------------------- 3 files changed, 25 insertions(+), 37 deletions(-) --- a/sound/core/seq/seq_prioq.c +++ b/sound/core/seq/seq_prioq.c @@ -87,7 +87,7 @@ void snd_seq_prioq_delete(struct snd_seq if (f->cells > 0) { /* drain prioQ */ while (f->cells > 0) - snd_seq_cell_free(snd_seq_prioq_cell_out(f)); + snd_seq_cell_free(snd_seq_prioq_cell_out(f, NULL)); } kfree(f); @@ -214,8 +214,18 @@ int snd_seq_prioq_cell_in(struct snd_seq return 0; } +/* return 1 if the current time >= event timestamp */ +static int event_is_ready(struct snd_seq_event *ev, void *current_time) +{ + if ((ev->flags & SNDRV_SEQ_TIME_STAMP_MASK) == SNDRV_SEQ_TIME_STAMP_TICK) + return snd_seq_compare_tick_time(current_time, &ev->time.tick); + else + return snd_seq_compare_real_time(current_time, &ev->time.time); +} + /* dequeue cell from prioq */ -struct snd_seq_event_cell *snd_seq_prioq_cell_out(struct snd_seq_prioq *f) +struct snd_seq_event_cell *snd_seq_prioq_cell_out(struct snd_seq_prioq *f, + void *current_time) { struct snd_seq_event_cell *cell; unsigned long flags; @@ -227,6 +237,8 @@ struct snd_seq_event_cell *snd_seq_prioq spin_lock_irqsave(&f->lock, flags); cell = f->head; + if (cell && current_time && !event_is_ready(&cell->event, current_time)) + cell = NULL; if (cell) { f->head = cell->next; @@ -252,18 +264,6 @@ int snd_seq_prioq_avail(struct snd_seq_p return f->cells; } - -/* peek at cell at the head of the prioq */ -struct snd_seq_event_cell *snd_seq_prioq_cell_peek(struct snd_seq_prioq * f) -{ - if (f == NULL) { - pr_debug("ALSA: seq: snd_seq_prioq_cell_in() called with NULL prioq\n"); - return NULL; - } - return f->head; -} - - static inline int prioq_match(struct snd_seq_event_cell *cell, int client, int timestamp) { --- a/sound/core/seq/seq_prioq.h +++ b/sound/core/seq/seq_prioq.h @@ -44,14 +44,12 @@ void snd_seq_prioq_delete(struct snd_seq int snd_seq_prioq_cell_in(struct snd_seq_prioq *f, struct snd_seq_event_cell *cell); /* dequeue cell from prioq */ -struct snd_seq_event_cell *snd_seq_prioq_cell_out(struct snd_seq_prioq *f); +struct snd_seq_event_cell *snd_seq_prioq_cell_out(struct snd_seq_prioq *f, + void *current_time); /* return number of events available in prioq */ int snd_seq_prioq_avail(struct snd_seq_prioq *f); -/* peek at cell at the head of the prioq */ -struct snd_seq_event_cell *snd_seq_prioq_cell_peek(struct snd_seq_prioq *f); - /* client left queue */ void snd_seq_prioq_leave(struct snd_seq_prioq *f, int client, int timestamp); --- a/sound/core/seq/seq_queue.c +++ b/sound/core/seq/seq_queue.c @@ -277,30 +277,20 @@ void snd_seq_check_queue(struct snd_seq_ __again: /* Process tick queue... */ - while ((cell = snd_seq_prioq_cell_peek(q->tickq)) != NULL) { - if (snd_seq_compare_tick_time(&q->timer->tick.cur_tick, - &cell->event.time.tick)) { - cell = snd_seq_prioq_cell_out(q->tickq); - if (cell) - snd_seq_dispatch_event(cell, atomic, hop); - } else { - /* event remains in the queue */ + for (;;) { + cell = snd_seq_prioq_cell_out(q->tickq, + &q->timer->tick.cur_tick); + if (!cell) break; - } + snd_seq_dispatch_event(cell, atomic, hop); } - /* Process time queue... */ - while ((cell = snd_seq_prioq_cell_peek(q->timeq)) != NULL) { - if (snd_seq_compare_real_time(&q->timer->cur_time, - &cell->event.time.time)) { - cell = snd_seq_prioq_cell_out(q->timeq); - if (cell) - snd_seq_dispatch_event(cell, atomic, hop); - } else { - /* event remains in the queue */ + for (;;) { + cell = snd_seq_prioq_cell_out(q->timeq, &q->timer->cur_time); + if (!cell) break; - } + snd_seq_dispatch_event(cell, atomic, hop); } /* free lock */ Patches currently in stable-queue which might be from tiwai(a)suse.de are queue-4.9/alsa-hda-add-geminilake-id-to-skl_plus.patch queue-4.9/alsa-firewire-digi00x-handle-all-midi-messages-on-streaming-packets.patch queue-4.9/alsa-firewire-digi00x-add-support-for-console-models-of-digi00x-series.patch queue-4.9/alsa-pcm-fix-uaf-in-snd_pcm_oss_get_formats.patch queue-4.9/alsa-seq-fix-possible-uaf-in-snd_seq_check_queue.patch queue-4.9/alsa-hda-revert-power_save-option-default-value.patch queue-4.9/alsa-seq-clear-client-entry-before-deleting-else-at-closing.patch queue-4.9/alsa-firewire-lib-add-a-quirk-of-packet-without-valid-eoh-in-cip-format.patch

7 years, 1 month

1
0
0 0

Patch "ALSA: seq: Clear client entry before deleting else at closing" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: seq: Clear client entry before deleting else at closing to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-seq-clear-client-entry-before-deleting-else-at-closing.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From a2ff19f7b70118ced291a28d5313469914de451b Mon Sep 17 00:00:00 2001 From: Takashi Iwai <tiwai(a)suse.de> Date: Fri, 9 Mar 2018 22:23:31 +0100 Subject: ALSA: seq: Clear client entry before deleting else at closing From: Takashi Iwai <tiwai(a)suse.de> commit a2ff19f7b70118ced291a28d5313469914de451b upstream. When releasing a client, we need to clear the clienttab[] entry at first, then call snd_seq_queue_client_leave(). Otherwise, the in-flight cell in the queue might be picked up by the timer interrupt via snd_seq_check_queue() before calling snd_seq_queue_client_leave(), and it's delivered to another queue while the client is clearing queues. This may eventually result in an uncleared cell remaining in a queue, and the later snd_seq_pool_delete() may need to wait for a long time until the event gets really processed. By moving the clienttab[] clearance at the beginning of release, any event delivery of a cell belonging to this client will fail at a later point, since snd_seq_client_ptr() returns NULL. Thus the cell that was picked up by the timer interrupt will be returned immediately without further delivery, and the long stall of snd_seq_delete_pool() can be avoided, too. Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/core/seq/seq_clientmgr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/sound/core/seq/seq_clientmgr.c +++ b/sound/core/seq/seq_clientmgr.c @@ -255,12 +255,12 @@ static int seq_free_client1(struct snd_s if (!client) return 0; - snd_seq_delete_all_ports(client); - snd_seq_queue_client_leave(client->number); spin_lock_irqsave(&clients_lock, flags); clienttablock[client->number] = 1; clienttab[client->number] = NULL; spin_unlock_irqrestore(&clients_lock, flags); + snd_seq_delete_all_ports(client); + snd_seq_queue_client_leave(client->number); snd_use_lock_sync(&client->use_lock); snd_seq_queue_client_termination(client->number); if (client->pool) Patches currently in stable-queue which might be from tiwai(a)suse.de are queue-4.9/alsa-hda-add-geminilake-id-to-skl_plus.patch queue-4.9/alsa-firewire-digi00x-handle-all-midi-messages-on-streaming-packets.patch queue-4.9/alsa-firewire-digi00x-add-support-for-console-models-of-digi00x-series.patch queue-4.9/alsa-pcm-fix-uaf-in-snd_pcm_oss_get_formats.patch queue-4.9/alsa-seq-fix-possible-uaf-in-snd_seq_check_queue.patch queue-4.9/alsa-hda-revert-power_save-option-default-value.patch queue-4.9/alsa-seq-clear-client-entry-before-deleting-else-at-closing.patch queue-4.9/alsa-firewire-lib-add-a-quirk-of-packet-without-valid-eoh-in-cip-format.patch

7 years, 1 month

1
0
0 0

Patch "ALSA: pcm: Fix UAF in snd_pcm_oss_get_formats()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: pcm: Fix UAF in snd_pcm_oss_get_formats() to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-pcm-fix-uaf-in-snd_pcm_oss_get_formats.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 01c0b4265cc16bc1f43f475c5944c55c10d5768f Mon Sep 17 00:00:00 2001 From: Takashi Iwai <tiwai(a)suse.de> Date: Sat, 10 Mar 2018 23:04:23 +0100 Subject: ALSA: pcm: Fix UAF in snd_pcm_oss_get_formats() From: Takashi Iwai <tiwai(a)suse.de> commit 01c0b4265cc16bc1f43f475c5944c55c10d5768f upstream. snd_pcm_oss_get_formats() has an obvious use-after-free around snd_mask_test() calls, as spotted by syzbot. The passed format_mask argument is a pointer to the hw_params object that is freed before the loop. What a surprise that it has been present since the original code of decades ago... Reported-by: syzbot+4090700a4f13fccaf648(a)syzkaller.appspotmail.com Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/core/oss/pcm_oss.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) --- a/sound/core/oss/pcm_oss.c +++ b/sound/core/oss/pcm_oss.c @@ -1814,10 +1814,9 @@ static int snd_pcm_oss_get_formats(struc return -ENOMEM; _snd_pcm_hw_params_any(params); err = snd_pcm_hw_refine(substream, params); - format_mask = *hw_param_mask(params, SNDRV_PCM_HW_PARAM_FORMAT); - kfree(params); if (err < 0) - return err; + goto error; + format_mask = hw_param_mask_c(params, SNDRV_PCM_HW_PARAM_FORMAT); for (fmt = 0; fmt < 32; ++fmt) { if (snd_mask_test(&format_mask, fmt)) { int f = snd_pcm_oss_format_to(fmt); @@ -1825,7 +1824,10 @@ static int snd_pcm_oss_get_formats(struc formats |= f; } } - return formats; + + error: + kfree(params); + return err < 0 ? err : formats; } static int snd_pcm_oss_set_format(struct snd_pcm_oss_file *pcm_oss_file, int format) Patches currently in stable-queue which might be from tiwai(a)suse.de are queue-4.9/alsa-hda-add-geminilake-id-to-skl_plus.patch queue-4.9/alsa-firewire-digi00x-handle-all-midi-messages-on-streaming-packets.patch queue-4.9/alsa-firewire-digi00x-add-support-for-console-models-of-digi00x-series.patch queue-4.9/alsa-pcm-fix-uaf-in-snd_pcm_oss_get_formats.patch queue-4.9/alsa-seq-fix-possible-uaf-in-snd_seq_check_queue.patch queue-4.9/alsa-hda-revert-power_save-option-default-value.patch queue-4.9/alsa-seq-clear-client-entry-before-deleting-else-at-closing.patch queue-4.9/alsa-firewire-lib-add-a-quirk-of-packet-without-valid-eoh-in-cip-format.patch

7 years, 1 month

1
0
0 0

Patch "ALSA: hda - Revert power_save option default value" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: hda - Revert power_save option default value to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-hda-revert-power_save-option-default-value.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 40088dc4e1ead7df31728c73f5b51d71da18831d Mon Sep 17 00:00:00 2001 From: Takashi Iwai <tiwai(a)suse.de> Date: Mon, 12 Mar 2018 13:55:48 +0100 Subject: ALSA: hda - Revert power_save option default value From: Takashi Iwai <tiwai(a)suse.de> commit 40088dc4e1ead7df31728c73f5b51d71da18831d upstream. With the commit 1ba8f9d30817 ("ALSA: hda: Add a power_save blacklist"), we changed the default value of power_save option to -1 for processing the power-save blacklist. Unfortunately, this seems breaking user-space applications that actually read the power_save parameter value via sysfs and judge / adjust the power-saving status. They see the value -1 as if the power-save is turned off, although the actual value is taken from CONFIG_SND_HDA_POWER_SAVE_DEFAULT and it can be a positive. So, overall, passing -1 there was no good idea. Let's partially revert it -- at least for power_save option default value is restored again to CONFIG_SND_HDA_POWER_SAVE_DEFAULT. Meanwhile, in this patch, we keep the blacklist behavior and make is adjustable via the new option, pm_blacklist. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199073 Fixes: 1ba8f9d30817 ("ALSA: hda: Add a power_save blacklist") Acked-by: Hans de Goede <hdegoede(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/pci/hda/hda_intel.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -180,11 +180,15 @@ static const struct kernel_param_ops par }; #define param_check_xint param_check_int -static int power_save = -1; +static int power_save = CONFIG_SND_HDA_POWER_SAVE_DEFAULT; module_param(power_save, xint, 0644); MODULE_PARM_DESC(power_save, "Automatic power-saving timeout " "(in second, 0 = disable)."); +static bool pm_blacklist = true; +module_param(pm_blacklist, bool, 0644); +MODULE_PARM_DESC(pm_blacklist, "Enable power-management blacklist"); + /* reset the HD-audio controller in power save mode. * this may give more power-saving, but will take longer time to * wake up. @@ -2153,10 +2157,9 @@ static int azx_probe_continue(struct azx val = power_save; #ifdef CONFIG_PM - if (val == -1) { + if (pm_blacklist) { const struct snd_pci_quirk *q; - val = CONFIG_SND_HDA_POWER_SAVE_DEFAULT; q = snd_pci_quirk_lookup(chip->pci, power_save_blacklist); if (q && val) { dev_info(chip->card->dev, "device %04x:%04x is on the power_save blacklist, forcing power_save to 0\n", Patches currently in stable-queue which might be from tiwai(a)suse.de are queue-4.9/alsa-hda-add-geminilake-id-to-skl_plus.patch queue-4.9/alsa-firewire-digi00x-handle-all-midi-messages-on-streaming-packets.patch queue-4.9/alsa-firewire-digi00x-add-support-for-console-models-of-digi00x-series.patch queue-4.9/alsa-pcm-fix-uaf-in-snd_pcm_oss_get_formats.patch queue-4.9/alsa-seq-fix-possible-uaf-in-snd_seq_check_queue.patch queue-4.9/alsa-hda-revert-power_save-option-default-value.patch queue-4.9/alsa-seq-clear-client-entry-before-deleting-else-at-closing.patch queue-4.9/alsa-firewire-lib-add-a-quirk-of-packet-without-valid-eoh-in-cip-format.patch

7 years, 1 month

1
0
0 0

Patch "x86/vm86/32: Fix POPF emulation" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/vm86/32: Fix POPF emulation to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-vm86-32-fix-popf-emulation.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From b5069782453459f6ec1fdeb495d9901a4545fcb5 Mon Sep 17 00:00:00 2001 From: Andy Lutomirski <luto(a)kernel.org> Date: Tue, 13 Mar 2018 22:03:12 -0700 Subject: x86/vm86/32: Fix POPF emulation From: Andy Lutomirski <luto(a)kernel.org> commit b5069782453459f6ec1fdeb495d9901a4545fcb5 upstream. POPF would trap if VIP was set regardless of whether IF was set. Fix it. Suggested-by: Stas Sergeev <stsp(a)list.ru> Reported-by: Bart Oldeman <bartoldeman(a)gmail.com> Signed-off-by: Andy Lutomirski <luto(a)kernel.org> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Denys Vlasenko <dvlasenk(a)redhat.com> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Fixes: 5ed92a8ab71f ("x86/vm86: Use the normal pt_regs area for vm86") Link: http://lkml.kernel.org/r/ce95f40556e7b2178b6bc06ee9557827ff94bd28.152100360… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/vm86_32.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/arch/x86/kernel/vm86_32.c +++ b/arch/x86/kernel/vm86_32.c @@ -715,7 +715,8 @@ void handle_vm86_fault(struct kernel_vm8 return; check_vip: - if (VEFLAGS & X86_EFLAGS_VIP) { + if ((VEFLAGS & (X86_EFLAGS_VIP | X86_EFLAGS_VIF)) == + (X86_EFLAGS_VIP | X86_EFLAGS_VIF)) { save_v86_state(regs, VM86_STI); return; } Patches currently in stable-queue which might be from luto(a)kernel.org are queue-4.4/selftests-x86-add-tests-for-the-str-and-sldt-instructions.patch queue-4.4/x86-vm86-32-fix-popf-emulation.patch queue-4.4/selftests-x86-add-tests-for-user-mode-instruction-prevention.patch queue-4.4/perf-tools-make-perf_event__synthesize_mmap_events-scale.patch queue-4.4/x86-mm-fix-vmalloc_fault-to-use-pxd_large.patch queue-4.4/selftests-x86-entry_from_vm86-add-test-cases-for-popf.patch queue-4.4/selftests-x86-entry_from_vm86-exit-with-1-if-we-fail.patch

7 years, 1 month

1
0
0 0

Patch "x86/mm: Fix vmalloc_fault to use pXd_large" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/mm: Fix vmalloc_fault to use pXd_large to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-mm-fix-vmalloc_fault-to-use-pxd_large.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 18a955219bf7d9008ce480d4451b6b8bf4483a22 Mon Sep 17 00:00:00 2001 From: Toshi Kani <toshi.kani(a)hpe.com> Date: Tue, 13 Mar 2018 11:03:46 -0600 Subject: x86/mm: Fix vmalloc_fault to use pXd_large From: Toshi Kani <toshi.kani(a)hpe.com> commit 18a955219bf7d9008ce480d4451b6b8bf4483a22 upstream. Gratian Crisan reported that vmalloc_fault() crashes when CONFIG_HUGETLBFS is not set since the function inadvertently uses pXn_huge(), which always return 0 in this case. ioremap() does not depend on CONFIG_HUGETLBFS. Fix vmalloc_fault() to call pXd_large() instead. Fixes: f4eafd8bcd52 ("x86/mm: Fix vmalloc_fault() to handle large pages properly") Reported-by: Gratian Crisan <gratian.crisan(a)ni.com> Signed-off-by: Toshi Kani <toshi.kani(a)hpe.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Cc: linux-mm(a)kvack.org Cc: Borislav Petkov <bp(a)alien8.de> Cc: Andy Lutomirski <luto(a)kernel.org> Link: https://lkml.kernel.org/r/20180313170347.3829-2-toshi.kani@hpe.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/mm/fault.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/arch/x86/mm/fault.c +++ b/arch/x86/mm/fault.c @@ -287,7 +287,7 @@ static noinline int vmalloc_fault(unsign if (!pmd_k) return -1; - if (pmd_huge(*pmd_k)) + if (pmd_large(*pmd_k)) return 0; pte_k = pte_offset_kernel(pmd_k, address); @@ -407,7 +407,7 @@ static noinline int vmalloc_fault(unsign if (pud_none(*pud) || pud_pfn(*pud) != pud_pfn(*pud_ref)) BUG(); - if (pud_huge(*pud)) + if (pud_large(*pud)) return 0; pmd = pmd_offset(pud, address); @@ -418,7 +418,7 @@ static noinline int vmalloc_fault(unsign if (pmd_none(*pmd) || pmd_pfn(*pmd) != pmd_pfn(*pmd_ref)) BUG(); - if (pmd_huge(*pmd)) + if (pmd_large(*pmd)) return 0; pte_ref = pte_offset_kernel(pmd_ref, address); Patches currently in stable-queue which might be from toshi.kani(a)hpe.com are queue-4.4/x86-mm-fix-vmalloc_fault-to-use-pxd_large.patch

7 years, 1 month

1
0
0 0

Patch "selftests/x86/entry_from_vm86: Exit with 1 if we fail" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled selftests/x86/entry_from_vm86: Exit with 1 if we fail to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: selftests-x86-entry_from_vm86-exit-with-1-if-we-fail.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 327d53d005ca47b10eae940616ed11c569f75a9b Mon Sep 17 00:00:00 2001 From: Andy Lutomirski <luto(a)kernel.org> Date: Tue, 13 Mar 2018 22:03:10 -0700 Subject: selftests/x86/entry_from_vm86: Exit with 1 if we fail From: Andy Lutomirski <luto(a)kernel.org> commit 327d53d005ca47b10eae940616ed11c569f75a9b upstream. Fix a logic error that caused the test to exit with 0 even if test cases failed. Signed-off-by: Andy Lutomirski <luto(a)kernel.org> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Denys Vlasenko <dvlasenk(a)redhat.com> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Stas Sergeev <stsp(a)list.ru> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: bartoldeman(a)gmail.com Cc: stable(a)vger.kernel.org Link: http://lkml.kernel.org/r/b1cc37144038958a469c8f70a5f47a6a5638636a.152100360… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/x86/entry_from_vm86.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/tools/testing/selftests/x86/entry_from_vm86.c +++ b/tools/testing/selftests/x86/entry_from_vm86.c @@ -231,7 +231,7 @@ int main(void) clearhandler(SIGSEGV); /* Make sure nothing explodes if we fork. */ - if (fork() > 0) + if (fork() == 0) return 0; return (nerrs == 0 ? 0 : 1); Patches currently in stable-queue which might be from luto(a)kernel.org are queue-4.4/selftests-x86-add-tests-for-the-str-and-sldt-instructions.patch queue-4.4/x86-vm86-32-fix-popf-emulation.patch queue-4.4/selftests-x86-add-tests-for-user-mode-instruction-prevention.patch queue-4.4/perf-tools-make-perf_event__synthesize_mmap_events-scale.patch queue-4.4/x86-mm-fix-vmalloc_fault-to-use-pxd_large.patch queue-4.4/selftests-x86-entry_from_vm86-add-test-cases-for-popf.patch queue-4.4/selftests-x86-entry_from_vm86-exit-with-1-if-we-fail.patch

7 years, 1 month

1
0
0 0

Patch "selftests/x86/entry_from_vm86: Add test cases for POPF" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled selftests/x86/entry_from_vm86: Add test cases for POPF to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: selftests-x86-entry_from_vm86-add-test-cases-for-popf.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 78393fdde2a456cafa414b171c90f26a3df98b20 Mon Sep 17 00:00:00 2001 From: Andy Lutomirski <luto(a)kernel.org> Date: Tue, 13 Mar 2018 22:03:11 -0700 Subject: selftests/x86/entry_from_vm86: Add test cases for POPF From: Andy Lutomirski <luto(a)kernel.org> commit 78393fdde2a456cafa414b171c90f26a3df98b20 upstream. POPF is currently broken -- add tests to catch the error. This results in: [RUN] POPF with VIP set and IF clear from vm86 mode [INFO] Exited vm86 mode due to STI [FAIL] Incorrect return reason (started at eip = 0xd, ended at eip = 0xf) because POPF currently fails to check IF before reporting a pending interrupt. This patch also makes the FAIL message a bit more informative. Reported-by: Bart Oldeman <bartoldeman(a)gmail.com> Signed-off-by: Andy Lutomirski <luto(a)kernel.org> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Denys Vlasenko <dvlasenk(a)redhat.com> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Stas Sergeev <stsp(a)list.ru> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Link: http://lkml.kernel.org/r/a16270b5cfe7832d6d00c479d0f871066cbdb52b.152100360… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/x86/entry_from_vm86.c | 30 +++++++++++++++++++++++--- 1 file changed, 27 insertions(+), 3 deletions(-) --- a/tools/testing/selftests/x86/entry_from_vm86.c +++ b/tools/testing/selftests/x86/entry_from_vm86.c @@ -95,6 +95,10 @@ asm ( "int3\n\t" "vmcode_int80:\n\t" "int $0x80\n\t" + "vmcode_popf_hlt:\n\t" + "push %ax\n\t" + "popf\n\t" + "hlt\n\t" "vmcode_umip:\n\t" /* addressing via displacements */ "smsw (2052)\n\t" @@ -124,8 +128,8 @@ asm ( extern unsigned char vmcode[], end_vmcode[]; extern unsigned char vmcode_bound[], vmcode_sysenter[], vmcode_syscall[], - vmcode_sti[], vmcode_int3[], vmcode_int80[], vmcode_umip[], - vmcode_umip_str[], vmcode_umip_sldt[]; + vmcode_sti[], vmcode_int3[], vmcode_int80[], vmcode_popf_hlt[], + vmcode_umip[], vmcode_umip_str[], vmcode_umip_sldt[]; /* Returns false if the test was skipped. */ static bool do_test(struct vm86plus_struct *v86, unsigned long eip, @@ -175,7 +179,7 @@ static bool do_test(struct vm86plus_stru (VM86_TYPE(ret) == rettype && VM86_ARG(ret) == retarg)) { printf("[OK]\tReturned correctly\n"); } else { - printf("[FAIL]\tIncorrect return reason\n"); + printf("[FAIL]\tIncorrect return reason (started at eip = 0x%lx, ended at eip = 0x%lx)\n", eip, v86->regs.eip); nerrs++; } @@ -264,6 +268,9 @@ int main(void) v86.regs.ds = load_addr / 16; v86.regs.es = load_addr / 16; + /* Use the end of the page as our stack. */ + v86.regs.esp = 4096; + assert((v86.regs.cs & 3) == 0); /* Looks like RPL = 0 */ /* #BR -- should deliver SIG??? */ @@ -295,6 +302,23 @@ int main(void) v86.regs.eflags &= ~X86_EFLAGS_IF; do_test(&v86, vmcode_sti - vmcode, VM86_STI, 0, "STI with VIP set"); + /* POPF with VIP set but IF clear: should not trap */ + v86.regs.eflags = X86_EFLAGS_VIP; + v86.regs.eax = 0; + do_test(&v86, vmcode_popf_hlt - vmcode, VM86_UNKNOWN, 0, "POPF with VIP set and IF clear"); + + /* POPF with VIP set and IF set: should trap */ + v86.regs.eflags = X86_EFLAGS_VIP; + v86.regs.eax = X86_EFLAGS_IF; + do_test(&v86, vmcode_popf_hlt - vmcode, VM86_STI, 0, "POPF with VIP and IF set"); + + /* POPF with VIP clear and IF set: should not trap */ + v86.regs.eflags = 0; + v86.regs.eax = X86_EFLAGS_IF; + do_test(&v86, vmcode_popf_hlt - vmcode, VM86_UNKNOWN, 0, "POPF with VIP clear and IF set"); + + v86.regs.eflags = 0; + /* INT3 -- should cause #BP */ do_test(&v86, vmcode_int3 - vmcode, VM86_TRAP, 3, "INT3"); Patches currently in stable-queue which might be from luto(a)kernel.org are queue-4.4/selftests-x86-add-tests-for-the-str-and-sldt-instructions.patch queue-4.4/x86-vm86-32-fix-popf-emulation.patch queue-4.4/selftests-x86-add-tests-for-user-mode-instruction-prevention.patch queue-4.4/perf-tools-make-perf_event__synthesize_mmap_events-scale.patch queue-4.4/x86-mm-fix-vmalloc_fault-to-use-pxd_large.patch queue-4.4/selftests-x86-entry_from_vm86-add-test-cases-for-popf.patch queue-4.4/selftests-x86-entry_from_vm86-exit-with-1-if-we-fail.patch

7 years, 1 month

1
0
0 0

Patch "selftests/x86: Add tests for User-Mode Instruction Prevention" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled selftests/x86: Add tests for User-Mode Instruction Prevention to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: selftests-x86-add-tests-for-user-mode-instruction-prevention.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 9390afebe1d3f5a0be18b1afdd0ce09d67cebf9e Mon Sep 17 00:00:00 2001 From: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> Date: Sun, 5 Nov 2017 18:27:56 -0800 Subject: selftests/x86: Add tests for User-Mode Instruction Prevention From: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> commit 9390afebe1d3f5a0be18b1afdd0ce09d67cebf9e upstream. Certain user space programs that run on virtual-8086 mode may utilize instructions protected by the User-Mode Instruction Prevention (UMIP) security feature present in new Intel processors: SGDT, SIDT and SMSW. In such a case, a general protection fault is issued if UMIP is enabled. When such a fault happens, the kernel traps it and emulates the results of these instructions with dummy values. The purpose of this new test is to verify whether the impacted instructions can be executed without causing such #GP. If no #GP exceptions occur, we expect to exit virtual-8086 mode from INT3. The instructions protected by UMIP are executed in representative use cases: a) displacement-only memory addressing b) register-indirect memory addressing c) results stored directly in operands Unfortunately, it is not possible to check the results against a set of expected values because no emulation will occur in systems that do not have the UMIP feature. Instead, results are printed for verification. A simple verification is done to ensure that results of all tests are identical. Signed-off-by: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> Reviewed-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Borislav Petkov <bp(a)suse.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Chen Yucong <slaoub(a)gmail.com> Cc: Chris Metcalf <cmetcalf(a)mellanox.com> Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: Denys Vlasenko <dvlasenk(a)redhat.com> Cc: Fenghua Yu <fenghua.yu(a)intel.com> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Huang Rui <ray.huang(a)amd.com> Cc: Jiri Slaby <jslaby(a)suse.cz> Cc: Jonathan Corbet <corbet(a)lwn.net> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Michael S. Tsirkin <mst(a)redhat.com> Cc: Paolo Bonzini <pbonzini(a)redhat.com> Cc: Paul Gortmaker <paul.gortmaker(a)windriver.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Ravi V. Shankar <ravi.v.shankar(a)intel.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: Tony Luck <tony.luck(a)intel.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: ricardo.neri(a)intel.com Link: http://lkml.kernel.org/r/1509935277-22138-12-git-send-email-ricardo.neri-ca… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/x86/entry_from_vm86.c | 73 +++++++++++++++++++++++++- 1 file changed, 72 insertions(+), 1 deletion(-) --- a/tools/testing/selftests/x86/entry_from_vm86.c +++ b/tools/testing/selftests/x86/entry_from_vm86.c @@ -95,6 +95,22 @@ asm ( "int3\n\t" "vmcode_int80:\n\t" "int $0x80\n\t" + "vmcode_umip:\n\t" + /* addressing via displacements */ + "smsw (2052)\n\t" + "sidt (2054)\n\t" + "sgdt (2060)\n\t" + /* addressing via registers */ + "mov $2066, %bx\n\t" + "smsw (%bx)\n\t" + "mov $2068, %bx\n\t" + "sidt (%bx)\n\t" + "mov $2074, %bx\n\t" + "sgdt (%bx)\n\t" + /* register operands, only for smsw */ + "smsw %ax\n\t" + "mov %ax, (2080)\n\t" + "int3\n\t" ".size vmcode, . - vmcode\n\t" "end_vmcode:\n\t" ".code32\n\t" @@ -103,7 +119,7 @@ asm ( extern unsigned char vmcode[], end_vmcode[]; extern unsigned char vmcode_bound[], vmcode_sysenter[], vmcode_syscall[], - vmcode_sti[], vmcode_int3[], vmcode_int80[]; + vmcode_sti[], vmcode_int3[], vmcode_int80[], vmcode_umip[]; /* Returns false if the test was skipped. */ static bool do_test(struct vm86plus_struct *v86, unsigned long eip, @@ -160,6 +176,58 @@ static bool do_test(struct vm86plus_stru return true; } +void do_umip_tests(struct vm86plus_struct *vm86, unsigned char *test_mem) +{ + struct table_desc { + unsigned short limit; + unsigned long base; + } __attribute__((packed)); + + /* Initialize variables with arbitrary values */ + struct table_desc gdt1 = { .base = 0x3c3c3c3c, .limit = 0x9999 }; + struct table_desc gdt2 = { .base = 0x1a1a1a1a, .limit = 0xaeae }; + struct table_desc idt1 = { .base = 0x7b7b7b7b, .limit = 0xf1f1 }; + struct table_desc idt2 = { .base = 0x89898989, .limit = 0x1313 }; + unsigned short msw1 = 0x1414, msw2 = 0x2525, msw3 = 3737; + + /* UMIP -- exit with INT3 unless kernel emulation did not trap #GP */ + do_test(vm86, vmcode_umip - vmcode, VM86_TRAP, 3, "UMIP tests"); + + /* Results from displacement-only addressing */ + msw1 = *(unsigned short *)(test_mem + 2052); + memcpy(&idt1, test_mem + 2054, sizeof(idt1)); + memcpy(&gdt1, test_mem + 2060, sizeof(gdt1)); + + /* Results from register-indirect addressing */ + msw2 = *(unsigned short *)(test_mem + 2066); + memcpy(&idt2, test_mem + 2068, sizeof(idt2)); + memcpy(&gdt2, test_mem + 2074, sizeof(gdt2)); + + /* Results when using register operands */ + msw3 = *(unsigned short *)(test_mem + 2080); + + printf("[INFO]\tResult from SMSW:[0x%04x]\n", msw1); + printf("[INFO]\tResult from SIDT: limit[0x%04x]base[0x%08lx]\n", + idt1.limit, idt1.base); + printf("[INFO]\tResult from SGDT: limit[0x%04x]base[0x%08lx]\n", + gdt1.limit, gdt1.base); + + if (msw1 != msw2 || msw1 != msw3) + printf("[FAIL]\tAll the results of SMSW should be the same.\n"); + else + printf("[PASS]\tAll the results from SMSW are identical.\n"); + + if (memcmp(&gdt1, &gdt2, sizeof(gdt1))) + printf("[FAIL]\tAll the results of SGDT should be the same.\n"); + else + printf("[PASS]\tAll the results from SGDT are identical.\n"); + + if (memcmp(&idt1, &idt2, sizeof(idt1))) + printf("[FAIL]\tAll the results of SIDT should be the same.\n"); + else + printf("[PASS]\tAll the results from SIDT are identical.\n"); +} + int main(void) { struct vm86plus_struct v86; @@ -218,6 +286,9 @@ int main(void) v86.regs.eax = (unsigned int)-1; do_test(&v86, vmcode_int80 - vmcode, VM86_INTx, 0x80, "int80"); + /* UMIP -- should exit with INTx 0x80 unless UMIP was not disabled */ + do_umip_tests(&v86, addr); + /* Execute a null pointer */ v86.regs.cs = 0; v86.regs.ss = 0; Patches currently in stable-queue which might be from ricardo.neri-calderon(a)linux.intel.com are queue-4.4/selftests-x86-add-tests-for-the-str-and-sldt-instructions.patch queue-4.4/selftests-x86-add-tests-for-user-mode-instruction-prevention.patch

7 years, 1 month

1
0
0 0

Patch "selftests/x86: Add tests for the STR and SLDT instructions" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled selftests/x86: Add tests for the STR and SLDT instructions to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: selftests-x86-add-tests-for-the-str-and-sldt-instructions.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From a9e017d5619eb371460c8e516f4684def62bef3a Mon Sep 17 00:00:00 2001 From: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> Date: Sun, 5 Nov 2017 18:27:57 -0800 Subject: selftests/x86: Add tests for the STR and SLDT instructions From: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> commit a9e017d5619eb371460c8e516f4684def62bef3a upstream. The STR and SLDT instructions are not valid when running on virtual-8086 mode and generate an invalid operand exception. These two instructions are protected by the Intel User-Mode Instruction Prevention (UMIP) security feature. In protected mode, if UMIP is enabled, these instructions generate a general protection fault if called from CPL > 0. Linux traps the general protection fault and emulates the instructions sgdt, sidt and smsw; but not str and sldt. These tests are added to verify that the emulation code does not emulate these two instructions but the expected invalid operand exception is seen. Tests fallback to exit with INT3 in case emulation does happen. Signed-off-by: Ricardo Neri <ricardo.neri-calderon(a)linux.intel.com> Reviewed-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Borislav Petkov <bp(a)suse.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Chen Yucong <slaoub(a)gmail.com> Cc: Chris Metcalf <cmetcalf(a)mellanox.com> Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: Denys Vlasenko <dvlasenk(a)redhat.com> Cc: Fenghua Yu <fenghua.yu(a)intel.com> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Huang Rui <ray.huang(a)amd.com> Cc: Jiri Slaby <jslaby(a)suse.cz> Cc: Jonathan Corbet <corbet(a)lwn.net> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Michael S. Tsirkin <mst(a)redhat.com> Cc: Paolo Bonzini <pbonzini(a)redhat.com> Cc: Paul Gortmaker <paul.gortmaker(a)windriver.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Ravi V. Shankar <ravi.v.shankar(a)intel.com> Cc: Shuah Khan <shuah(a)kernel.org> Cc: Tony Luck <tony.luck(a)intel.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: ricardo.neri(a)intel.com Link: http://lkml.kernel.org/r/1509935277-22138-13-git-send-email-ricardo.neri-ca… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/x86/entry_from_vm86.c | 18 +++++++++++++++++- 1 file changed, 17 insertions(+), 1 deletion(-) --- a/tools/testing/selftests/x86/entry_from_vm86.c +++ b/tools/testing/selftests/x86/entry_from_vm86.c @@ -111,6 +111,11 @@ asm ( "smsw %ax\n\t" "mov %ax, (2080)\n\t" "int3\n\t" + "vmcode_umip_str:\n\t" + "str %eax\n\t" + "vmcode_umip_sldt:\n\t" + "sldt %eax\n\t" + "int3\n\t" ".size vmcode, . - vmcode\n\t" "end_vmcode:\n\t" ".code32\n\t" @@ -119,7 +124,8 @@ asm ( extern unsigned char vmcode[], end_vmcode[]; extern unsigned char vmcode_bound[], vmcode_sysenter[], vmcode_syscall[], - vmcode_sti[], vmcode_int3[], vmcode_int80[], vmcode_umip[]; + vmcode_sti[], vmcode_int3[], vmcode_int80[], vmcode_umip[], + vmcode_umip_str[], vmcode_umip_sldt[]; /* Returns false if the test was skipped. */ static bool do_test(struct vm86plus_struct *v86, unsigned long eip, @@ -226,6 +232,16 @@ void do_umip_tests(struct vm86plus_struc printf("[FAIL]\tAll the results of SIDT should be the same.\n"); else printf("[PASS]\tAll the results from SIDT are identical.\n"); + + sethandler(SIGILL, sighandler, 0); + do_test(vm86, vmcode_umip_str - vmcode, VM86_SIGNAL, 0, + "STR instruction"); + clearhandler(SIGILL); + + sethandler(SIGILL, sighandler, 0); + do_test(vm86, vmcode_umip_sldt - vmcode, VM86_SIGNAL, 0, + "SLDT instruction"); + clearhandler(SIGILL); } int main(void) Patches currently in stable-queue which might be from ricardo.neri-calderon(a)linux.intel.com are queue-4.4/selftests-x86-add-tests-for-the-str-and-sldt-instructions.patch queue-4.4/selftests-x86-add-tests-for-user-mode-instruction-prevention.patch

7 years, 1 month

1
0
0 0

Patch "lock_parent() needs to recheck if dentry got __dentry_kill'ed under it" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled lock_parent() needs to recheck if dentry got __dentry_kill'ed under it to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: lock_parent-needs-to-recheck-if-dentry-got-__dentry_kill-ed-under-it.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 3b821409632ab778d46e807516b457dfa72736ed Mon Sep 17 00:00:00 2001 From: Al Viro <viro(a)zeniv.linux.org.uk> Date: Fri, 23 Feb 2018 20:47:17 -0500 Subject: lock_parent() needs to recheck if dentry got __dentry_kill'ed under it From: Al Viro <viro(a)zeniv.linux.org.uk> commit 3b821409632ab778d46e807516b457dfa72736ed upstream. In case when dentry passed to lock_parent() is protected from freeing only by the fact that it's on a shrink list and trylock of parent fails, we could get hit by __dentry_kill() (and subsequent dentry_kill(parent)) between unlocking dentry and locking presumed parent. We need to recheck that dentry is alive once we lock both it and parent *and* postpone rcu_read_unlock() until after that point. Otherwise we could return a pointer to struct dentry that already is rcu-scheduled for freeing, with ->d_lock held on it; caller's subsequent attempt to unlock it can end up with memory corruption. Cc: stable(a)vger.kernel.org # 3.12+, counting backports Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/dcache.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) --- a/fs/dcache.c +++ b/fs/dcache.c @@ -634,11 +634,16 @@ again: spin_unlock(&parent->d_lock); goto again; } - rcu_read_unlock(); - if (parent != dentry) + if (parent != dentry) { spin_lock_nested(&dentry->d_lock, DENTRY_D_LOCK_NESTED); - else + if (unlikely(dentry->d_lockref.count < 0)) { + spin_unlock(&parent->d_lock); + parent = NULL; + } + } else { parent = NULL; + } + rcu_read_unlock(); return parent; } Patches currently in stable-queue which might be from viro(a)zeniv.linux.org.uk are queue-4.4/fs-teach-path_connected-to-handle-nfs-filesystems-with-multiple-roots.patch queue-4.4/lock_parent-needs-to-recheck-if-dentry-got-__dentry_kill-ed-under-it.patch

7 years, 1 month

1
0
0 0

Patch "fs: Teach path_connected to handle nfs filesystems with multiple roots." has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled fs: Teach path_connected to handle nfs filesystems with multiple roots. to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: fs-teach-path_connected-to-handle-nfs-filesystems-with-multiple-roots.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 95dd77580ccd66a0da96e6d4696945b8cea39431 Mon Sep 17 00:00:00 2001 From: "Eric W. Biederman" <ebiederm(a)xmission.com> Date: Wed, 14 Mar 2018 18:20:29 -0500 Subject: fs: Teach path_connected to handle nfs filesystems with multiple roots. From: Eric W. Biederman <ebiederm(a)xmission.com> commit 95dd77580ccd66a0da96e6d4696945b8cea39431 upstream. On nfsv2 and nfsv3 the nfs server can export subsets of the same filesystem and report the same filesystem identifier, so that the nfs client can know they are the same filesystem. The subsets can be from disjoint directory trees. The nfsv2 and nfsv3 filesystems provides no way to find the common root of all directory trees exported form the server with the same filesystem identifier. The practical result is that in struct super s_root for nfs s_root is not necessarily the root of the filesystem. The nfs mount code sets s_root to the root of the first subset of the nfs filesystem that the kernel mounts. This effects the dcache invalidation code in generic_shutdown_super currently called shrunk_dcache_for_umount and that code for years has gone through an additional list of dentries that might be dentry trees that need to be freed to accomodate nfs. When I wrote path_connected I did not realize nfs was so special, and it's hueristic for avoiding calling is_subdir can fail. The practical case where this fails is when there is a move of a directory from the subtree exposed by one nfs mount to the subtree exposed by another nfs mount. This move can happen either locally or remotely. With the remote case requiring that the move directory be cached before the move and that after the move someone walks the path to where the move directory now exists and in so doing causes the already cached directory to be moved in the dcache through the magic of d_splice_alias. If someone whose working directory is in the move directory or a subdirectory and now starts calling .. from the initial mount of nfs (where s_root == mnt_root), then path_connected as a heuristic will not bother with the is_subdir check. As s_root really is not the root of the nfs filesystem this heuristic is wrong, and the path may actually not be connected and path_connected can fail. The is_subdir function might be cheap enough that we can call it unconditionally. Verifying that will take some benchmarking and the result may not be the same on all kernels this fix needs to be backported to. So I am avoiding that for now. Filesystems with snapshots such as nilfs and btrfs do something similar. But as the directory tree of the snapshots are disjoint from one another and from the main directory tree rename won't move things between them and this problem will not occur. Cc: stable(a)vger.kernel.org Reported-by: Al Viro <viro(a)ZenIV.linux.org.uk> Fixes: 397d425dc26d ("vfs: Test for and handle paths that are unreachable from their mnt_root") Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com> Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/namei.c | 5 +++-- fs/nfs/super.c | 2 ++ include/linux/fs.h | 1 + 3 files changed, 6 insertions(+), 2 deletions(-) --- a/fs/namei.c +++ b/fs/namei.c @@ -570,9 +570,10 @@ static int __nd_alloc_stack(struct namei static bool path_connected(const struct path *path) { struct vfsmount *mnt = path->mnt; + struct super_block *sb = mnt->mnt_sb; - /* Only bind mounts can have disconnected paths */ - if (mnt->mnt_root == mnt->mnt_sb->s_root) + /* Bind mounts and multi-root filesystems can have disconnected paths */ + if (!(sb->s_iflags & SB_I_MULTIROOT) && (mnt->mnt_root == sb->s_root)) return true; return is_subdir(path->dentry, mnt->mnt_root); --- a/fs/nfs/super.c +++ b/fs/nfs/super.c @@ -2581,6 +2581,8 @@ struct dentry *nfs_fs_mount_common(struc /* initial superblock/root creation */ mount_info->fill_super(s, mount_info); nfs_get_cache_cookie(s, mount_info->parsed, mount_info->cloned); + if (!(server->flags & NFS_MOUNT_UNSHARED)) + s->s_iflags |= SB_I_MULTIROOT; } mntroot = nfs_get_root(s, mount_info->mntfh, dev_name); --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -1295,6 +1295,7 @@ struct mm_struct; /* sb->s_iflags */ #define SB_I_CGROUPWB 0x00000001 /* cgroup-aware writeback enabled */ #define SB_I_NOEXEC 0x00000002 /* Ignore executables on this fs */ +#define SB_I_MULTIROOT 0x00000008 /* Multiple roots to the dentry tree */ /* Possible states of 'frozen' field */ enum { Patches currently in stable-queue which might be from ebiederm(a)xmission.com are queue-4.4/fs-teach-path_connected-to-handle-nfs-filesystems-with-multiple-roots.patch

7 years, 1 month

1
0
0 0

Patch "fs/aio: Use RCU accessors for kioctx_table->table[]" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled fs/aio: Use RCU accessors for kioctx_table->table[] to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: fs-aio-use-rcu-accessors-for-kioctx_table-table.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d0264c01e7587001a8c4608a5d1818dba9a4c11a Mon Sep 17 00:00:00 2001 From: Tejun Heo <tj(a)kernel.org> Date: Wed, 14 Mar 2018 12:10:17 -0700 Subject: fs/aio: Use RCU accessors for kioctx_table->table[] From: Tejun Heo <tj(a)kernel.org> commit d0264c01e7587001a8c4608a5d1818dba9a4c11a upstream. While converting ioctx index from a list to a table, db446a08c23d ("aio: convert the ioctx list to table lookup v3") missed tagging kioctx_table->table[] as an array of RCU pointers and using the appropriate RCU accessors. This introduces a small window in the lookup path where init and access may race. Mark kioctx_table->table[] with __rcu and use the approriate RCU accessors when using the field. Signed-off-by: Tejun Heo <tj(a)kernel.org> Reported-by: Jann Horn <jannh(a)google.com> Fixes: db446a08c23d ("aio: convert the ioctx list to table lookup v3") Cc: Benjamin LaHaise <bcrl(a)kvack.org> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: stable(a)vger.kernel.org # v3.12+ Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/aio.c | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) --- a/fs/aio.c +++ b/fs/aio.c @@ -68,9 +68,9 @@ struct aio_ring { #define AIO_RING_PAGES 8 struct kioctx_table { - struct rcu_head rcu; - unsigned nr; - struct kioctx *table[]; + struct rcu_head rcu; + unsigned nr; + struct kioctx __rcu *table[]; }; struct kioctx_cpu { @@ -327,7 +327,7 @@ static int aio_ring_mremap(struct vm_are for (i = 0; i < table->nr; i++) { struct kioctx *ctx; - ctx = table->table[i]; + ctx = rcu_dereference(table->table[i]); if (ctx && ctx->aio_ring_file == file) { if (!atomic_read(&ctx->dead)) { ctx->user_id = ctx->mmap_base = vma->vm_start; @@ -651,9 +651,9 @@ static int ioctx_add_table(struct kioctx while (1) { if (table) for (i = 0; i < table->nr; i++) - if (!table->table[i]) { + if (!rcu_access_pointer(table->table[i])) { ctx->id = i; - table->table[i] = ctx; + rcu_assign_pointer(table->table[i], ctx); spin_unlock(&mm->ioctx_lock); /* While kioctx setup is in progress, @@ -828,8 +828,8 @@ static int kill_ioctx(struct mm_struct * } table = rcu_dereference_raw(mm->ioctx_table); - WARN_ON(ctx != table->table[ctx->id]); - table->table[ctx->id] = NULL; + WARN_ON(ctx != rcu_access_pointer(table->table[ctx->id])); + RCU_INIT_POINTER(table->table[ctx->id], NULL); spin_unlock(&mm->ioctx_lock); /* free_ioctx_reqs() will do the necessary RCU synchronization */ @@ -874,7 +874,8 @@ void exit_aio(struct mm_struct *mm) skipped = 0; for (i = 0; i < table->nr; ++i) { - struct kioctx *ctx = table->table[i]; + struct kioctx *ctx = + rcu_dereference_protected(table->table[i], true); if (!ctx) { skipped++; @@ -1063,7 +1064,7 @@ static struct kioctx *lookup_ioctx(unsig if (!table || id >= table->nr) goto out; - ctx = table->table[id]; + ctx = rcu_dereference(table->table[id]); if (ctx && ctx->user_id == ctx_id) { percpu_ref_get(&ctx->users); ret = ctx; Patches currently in stable-queue which might be from tj(a)kernel.org are queue-4.4/fs-aio-add-explicit-rcu-grace-period-when-freeing-kioctx.patch queue-4.4/fs-aio-use-rcu-accessors-for-kioctx_table-table.patch

7 years, 1 month

1
0
0 0

Patch "fs/aio: Add explicit RCU grace period when freeing kioctx" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled fs/aio: Add explicit RCU grace period when freeing kioctx to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: fs-aio-add-explicit-rcu-grace-period-when-freeing-kioctx.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From a6d7cff472eea87d96899a20fa718d2bab7109f3 Mon Sep 17 00:00:00 2001 From: Tejun Heo <tj(a)kernel.org> Date: Wed, 14 Mar 2018 12:10:17 -0700 Subject: fs/aio: Add explicit RCU grace period when freeing kioctx From: Tejun Heo <tj(a)kernel.org> commit a6d7cff472eea87d96899a20fa718d2bab7109f3 upstream. While fixing refcounting, e34ecee2ae79 ("aio: Fix a trinity splat") incorrectly removed explicit RCU grace period before freeing kioctx. The intention seems to be depending on the internal RCU grace periods of percpu_ref; however, percpu_ref uses a different flavor of RCU, sched-RCU. This can lead to kioctx being freed while RCU read protected dereferences are still in progress. Fix it by updating free_ioctx() to go through call_rcu() explicitly. v2: Comment added to explain double bouncing. Signed-off-by: Tejun Heo <tj(a)kernel.org> Reported-by: Jann Horn <jannh(a)google.com> Fixes: e34ecee2ae79 ("aio: Fix a trinity splat") Cc: Kent Overstreet <kent.overstreet(a)gmail.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: stable(a)vger.kernel.org # v3.13+ Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/aio.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-) --- a/fs/aio.c +++ b/fs/aio.c @@ -115,7 +115,8 @@ struct kioctx { struct page **ring_pages; long nr_pages; - struct work_struct free_work; + struct rcu_head free_rcu; + struct work_struct free_work; /* see free_ioctx() */ /* * signals when all in-flight requests are done @@ -573,6 +574,12 @@ static int kiocb_cancel(struct aio_kiocb return cancel(&kiocb->common); } +/* + * free_ioctx() should be RCU delayed to synchronize against the RCU + * protected lookup_ioctx() and also needs process context to call + * aio_free_ring(), so the double bouncing through kioctx->free_rcu and + * ->free_work. + */ static void free_ioctx(struct work_struct *work) { struct kioctx *ctx = container_of(work, struct kioctx, free_work); @@ -586,6 +593,14 @@ static void free_ioctx(struct work_struc kmem_cache_free(kioctx_cachep, ctx); } +static void free_ioctx_rcufn(struct rcu_head *head) +{ + struct kioctx *ctx = container_of(head, struct kioctx, free_rcu); + + INIT_WORK(&ctx->free_work, free_ioctx); + schedule_work(&ctx->free_work); +} + static void free_ioctx_reqs(struct percpu_ref *ref) { struct kioctx *ctx = container_of(ref, struct kioctx, reqs); @@ -594,8 +609,8 @@ static void free_ioctx_reqs(struct percp if (ctx->rq_wait && atomic_dec_and_test(&ctx->rq_wait->count)) complete(&ctx->rq_wait->comp); - INIT_WORK(&ctx->free_work, free_ioctx); - schedule_work(&ctx->free_work); + /* Synchronize against RCU protected table->table[] dereferences */ + call_rcu(&ctx->free_rcu, free_ioctx_rcufn); } /* @@ -817,7 +832,7 @@ static int kill_ioctx(struct mm_struct * table->table[ctx->id] = NULL; spin_unlock(&mm->ioctx_lock); - /* percpu_ref_kill() will do the necessary call_rcu() */ + /* free_ioctx_reqs() will do the necessary RCU synchronization */ wake_up_all(&ctx->wait); /* Patches currently in stable-queue which might be from tj(a)kernel.org are queue-4.4/fs-aio-add-explicit-rcu-grace-period-when-freeing-kioctx.patch queue-4.4/fs-aio-use-rcu-accessors-for-kioctx_table-table.patch

7 years, 1 month

1
0
0 0

Patch "ALSA: seq: Fix possible UAF in snd_seq_check_queue()" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: seq: Fix possible UAF in snd_seq_check_queue() to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-seq-fix-possible-uaf-in-snd_seq_check_queue.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d0f833065221cbfcbadf19fd4102bcfa9330006a Mon Sep 17 00:00:00 2001 From: Takashi Iwai <tiwai(a)suse.de> Date: Fri, 9 Mar 2018 21:58:28 +0100 Subject: ALSA: seq: Fix possible UAF in snd_seq_check_queue() From: Takashi Iwai <tiwai(a)suse.de> commit d0f833065221cbfcbadf19fd4102bcfa9330006a upstream. Although we've covered the races between concurrent write() and ioctl() in the previous patch series, there is still a possible UAF in the following scenario: A: user client closed B: timer irq -> snd_seq_release() -> snd_seq_timer_interrupt() -> snd_seq_free_client() -> snd_seq_check_queue() -> cell = snd_seq_prioq_cell_peek() -> snd_seq_prioq_leave() .... removing all cells -> snd_seq_pool_done() .... vfree() -> snd_seq_compare_tick_time(cell) ... Oops So the problem is that a cell is peeked and accessed without any protection until it's retrieved from the queue again via snd_seq_prioq_cell_out(). This patch tries to address it, also cleans up the code by a slight refactoring. snd_seq_prioq_cell_out() now receives an extra pointer argument. When it's non-NULL, the function checks the event timestamp with the given pointer. The caller needs to pass the right reference either to snd_seq_tick or snd_seq_realtime depending on the event timestamp type. A good news is that the above change allows us to remove the snd_seq_prioq_cell_peek(), too, thus the patch actually reduces the code size. Reviewed-by: Nicolai Stange <nstange(a)suse.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/core/seq/seq_prioq.c | 28 ++++++++++++++-------------- sound/core/seq/seq_prioq.h | 6 ++---- sound/core/seq/seq_queue.c | 28 +++++++++------------------- 3 files changed, 25 insertions(+), 37 deletions(-) --- a/sound/core/seq/seq_prioq.c +++ b/sound/core/seq/seq_prioq.c @@ -87,7 +87,7 @@ void snd_seq_prioq_delete(struct snd_seq if (f->cells > 0) { /* drain prioQ */ while (f->cells > 0) - snd_seq_cell_free(snd_seq_prioq_cell_out(f)); + snd_seq_cell_free(snd_seq_prioq_cell_out(f, NULL)); } kfree(f); @@ -214,8 +214,18 @@ int snd_seq_prioq_cell_in(struct snd_seq return 0; } +/* return 1 if the current time >= event timestamp */ +static int event_is_ready(struct snd_seq_event *ev, void *current_time) +{ + if ((ev->flags & SNDRV_SEQ_TIME_STAMP_MASK) == SNDRV_SEQ_TIME_STAMP_TICK) + return snd_seq_compare_tick_time(current_time, &ev->time.tick); + else + return snd_seq_compare_real_time(current_time, &ev->time.time); +} + /* dequeue cell from prioq */ -struct snd_seq_event_cell *snd_seq_prioq_cell_out(struct snd_seq_prioq *f) +struct snd_seq_event_cell *snd_seq_prioq_cell_out(struct snd_seq_prioq *f, + void *current_time) { struct snd_seq_event_cell *cell; unsigned long flags; @@ -227,6 +237,8 @@ struct snd_seq_event_cell *snd_seq_prioq spin_lock_irqsave(&f->lock, flags); cell = f->head; + if (cell && current_time && !event_is_ready(&cell->event, current_time)) + cell = NULL; if (cell) { f->head = cell->next; @@ -252,18 +264,6 @@ int snd_seq_prioq_avail(struct snd_seq_p return f->cells; } - -/* peek at cell at the head of the prioq */ -struct snd_seq_event_cell *snd_seq_prioq_cell_peek(struct snd_seq_prioq * f) -{ - if (f == NULL) { - pr_debug("ALSA: seq: snd_seq_prioq_cell_in() called with NULL prioq\n"); - return NULL; - } - return f->head; -} - - static inline int prioq_match(struct snd_seq_event_cell *cell, int client, int timestamp) { --- a/sound/core/seq/seq_prioq.h +++ b/sound/core/seq/seq_prioq.h @@ -44,14 +44,12 @@ void snd_seq_prioq_delete(struct snd_seq int snd_seq_prioq_cell_in(struct snd_seq_prioq *f, struct snd_seq_event_cell *cell); /* dequeue cell from prioq */ -struct snd_seq_event_cell *snd_seq_prioq_cell_out(struct snd_seq_prioq *f); +struct snd_seq_event_cell *snd_seq_prioq_cell_out(struct snd_seq_prioq *f, + void *current_time); /* return number of events available in prioq */ int snd_seq_prioq_avail(struct snd_seq_prioq *f); -/* peek at cell at the head of the prioq */ -struct snd_seq_event_cell *snd_seq_prioq_cell_peek(struct snd_seq_prioq *f); - /* client left queue */ void snd_seq_prioq_leave(struct snd_seq_prioq *f, int client, int timestamp); --- a/sound/core/seq/seq_queue.c +++ b/sound/core/seq/seq_queue.c @@ -277,30 +277,20 @@ void snd_seq_check_queue(struct snd_seq_ __again: /* Process tick queue... */ - while ((cell = snd_seq_prioq_cell_peek(q->tickq)) != NULL) { - if (snd_seq_compare_tick_time(&q->timer->tick.cur_tick, - &cell->event.time.tick)) { - cell = snd_seq_prioq_cell_out(q->tickq); - if (cell) - snd_seq_dispatch_event(cell, atomic, hop); - } else { - /* event remains in the queue */ + for (;;) { + cell = snd_seq_prioq_cell_out(q->tickq, + &q->timer->tick.cur_tick); + if (!cell) break; - } + snd_seq_dispatch_event(cell, atomic, hop); } - /* Process time queue... */ - while ((cell = snd_seq_prioq_cell_peek(q->timeq)) != NULL) { - if (snd_seq_compare_real_time(&q->timer->cur_time, - &cell->event.time.time)) { - cell = snd_seq_prioq_cell_out(q->timeq); - if (cell) - snd_seq_dispatch_event(cell, atomic, hop); - } else { - /* event remains in the queue */ + for (;;) { + cell = snd_seq_prioq_cell_out(q->timeq, &q->timer->cur_time); + if (!cell) break; - } + snd_seq_dispatch_event(cell, atomic, hop); } /* free lock */ Patches currently in stable-queue which might be from tiwai(a)suse.de are queue-4.4/alsa-firewire-digi00x-handle-all-midi-messages-on-streaming-packets.patch queue-4.4/alsa-pcm-fix-uaf-in-snd_pcm_oss_get_formats.patch queue-4.4/alsa-seq-fix-possible-uaf-in-snd_seq_check_queue.patch queue-4.4/alsa-hda-revert-power_save-option-default-value.patch queue-4.4/alsa-seq-clear-client-entry-before-deleting-else-at-closing.patch

7 years, 1 month

1
0
0 0

Patch "drm/amdgpu/dce: Don't turn off DP sink when disconnected" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/amdgpu/dce: Don't turn off DP sink when disconnected to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-amdgpu-dce-don-t-turn-off-dp-sink-when-disconnected.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 7d617264eb22b18d979eac6e85877a141253034e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Michel=20D=C3=A4nzer?= <michel.daenzer(a)amd.com> Date: Fri, 9 Mar 2018 18:26:18 +0100 Subject: drm/amdgpu/dce: Don't turn off DP sink when disconnected MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Michel Dänzer <michel.daenzer(a)amd.com> commit 7d617264eb22b18d979eac6e85877a141253034e upstream. Turning off the sink in this case causes various issues, because userspace expects it to stay on until it turns it off explicitly. Instead, turn the sink off and back on when a display is connected again. This dance seems necessary for link training to work correctly. Bugzilla: https://bugs.freedesktop.org/105308 Cc: stable(a)vger.kernel.org Reviewed-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Michel Dänzer <michel.daenzer(a)amd.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 29 +++++++++---------------- 1 file changed, 11 insertions(+), 18 deletions(-) --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c @@ -69,25 +69,18 @@ void amdgpu_connector_hotplug(struct drm /* don't do anything if sink is not display port, i.e., * passive dp->(dvi|hdmi) adaptor */ - if (dig_connector->dp_sink_type == CONNECTOR_OBJECT_ID_DISPLAYPORT) { - int saved_dpms = connector->dpms; - /* Only turn off the display if it's physically disconnected */ - if (!amdgpu_display_hpd_sense(adev, amdgpu_connector->hpd.hpd)) { - drm_helper_connector_dpms(connector, DRM_MODE_DPMS_OFF); - } else if (amdgpu_atombios_dp_needs_link_train(amdgpu_connector)) { - /* Don't try to start link training before we - * have the dpcd */ - if (amdgpu_atombios_dp_get_dpcd(amdgpu_connector)) - return; + if (dig_connector->dp_sink_type == CONNECTOR_OBJECT_ID_DISPLAYPORT && + amdgpu_display_hpd_sense(adev, amdgpu_connector->hpd.hpd) && + amdgpu_atombios_dp_needs_link_train(amdgpu_connector)) { + /* Don't start link training before we have the DPCD */ + if (amdgpu_atombios_dp_get_dpcd(amdgpu_connector)) + return; - /* set it to OFF so that drm_helper_connector_dpms() - * won't return immediately since the current state - * is ON at this point. - */ - connector->dpms = DRM_MODE_DPMS_OFF; - drm_helper_connector_dpms(connector, DRM_MODE_DPMS_ON); - } - connector->dpms = saved_dpms; + /* Turn the connector off and back on immediately, which + * will trigger link training + */ + drm_helper_connector_dpms(connector, DRM_MODE_DPMS_OFF); + drm_helper_connector_dpms(connector, DRM_MODE_DPMS_ON); } } } Patches currently in stable-queue which might be from michel.daenzer(a)amd.com are queue-4.4/drm-amdgpu-fail-fb-creation-from-imported-dma-bufs.-v2.patch queue-4.4/drm-amdgpu-dce-don-t-turn-off-dp-sink-when-disconnected.patch queue-4.4/drm-radeon-fail-fb-creation-from-imported-dma-bufs.patch

7 years, 1 month

1
0
0 0

Patch "ALSA: seq: Clear client entry before deleting else at closing" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: seq: Clear client entry before deleting else at closing to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-seq-clear-client-entry-before-deleting-else-at-closing.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From a2ff19f7b70118ced291a28d5313469914de451b Mon Sep 17 00:00:00 2001 From: Takashi Iwai <tiwai(a)suse.de> Date: Fri, 9 Mar 2018 22:23:31 +0100 Subject: ALSA: seq: Clear client entry before deleting else at closing From: Takashi Iwai <tiwai(a)suse.de> commit a2ff19f7b70118ced291a28d5313469914de451b upstream. When releasing a client, we need to clear the clienttab[] entry at first, then call snd_seq_queue_client_leave(). Otherwise, the in-flight cell in the queue might be picked up by the timer interrupt via snd_seq_check_queue() before calling snd_seq_queue_client_leave(), and it's delivered to another queue while the client is clearing queues. This may eventually result in an uncleared cell remaining in a queue, and the later snd_seq_pool_delete() may need to wait for a long time until the event gets really processed. By moving the clienttab[] clearance at the beginning of release, any event delivery of a cell belonging to this client will fail at a later point, since snd_seq_client_ptr() returns NULL. Thus the cell that was picked up by the timer interrupt will be returned immediately without further delivery, and the long stall of snd_seq_delete_pool() can be avoided, too. Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/core/seq/seq_clientmgr.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/sound/core/seq/seq_clientmgr.c +++ b/sound/core/seq/seq_clientmgr.c @@ -270,12 +270,12 @@ static int seq_free_client1(struct snd_s if (!client) return 0; - snd_seq_delete_all_ports(client); - snd_seq_queue_client_leave(client->number); spin_lock_irqsave(&clients_lock, flags); clienttablock[client->number] = 1; clienttab[client->number] = NULL; spin_unlock_irqrestore(&clients_lock, flags); + snd_seq_delete_all_ports(client); + snd_seq_queue_client_leave(client->number); snd_use_lock_sync(&client->use_lock); snd_seq_queue_client_termination(client->number); if (client->pool) Patches currently in stable-queue which might be from tiwai(a)suse.de are queue-4.4/alsa-firewire-digi00x-handle-all-midi-messages-on-streaming-packets.patch queue-4.4/alsa-pcm-fix-uaf-in-snd_pcm_oss_get_formats.patch queue-4.4/alsa-seq-fix-possible-uaf-in-snd_seq_check_queue.patch queue-4.4/alsa-hda-revert-power_save-option-default-value.patch queue-4.4/alsa-seq-clear-client-entry-before-deleting-else-at-closing.patch

7 years, 1 month

1
0
0 0

Patch "ALSA: pcm: Fix UAF in snd_pcm_oss_get_formats()" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: pcm: Fix UAF in snd_pcm_oss_get_formats() to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-pcm-fix-uaf-in-snd_pcm_oss_get_formats.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 01c0b4265cc16bc1f43f475c5944c55c10d5768f Mon Sep 17 00:00:00 2001 From: Takashi Iwai <tiwai(a)suse.de> Date: Sat, 10 Mar 2018 23:04:23 +0100 Subject: ALSA: pcm: Fix UAF in snd_pcm_oss_get_formats() From: Takashi Iwai <tiwai(a)suse.de> commit 01c0b4265cc16bc1f43f475c5944c55c10d5768f upstream. snd_pcm_oss_get_formats() has an obvious use-after-free around snd_mask_test() calls, as spotted by syzbot. The passed format_mask argument is a pointer to the hw_params object that is freed before the loop. What a surprise that it has been present since the original code of decades ago... Reported-by: syzbot+4090700a4f13fccaf648(a)syzkaller.appspotmail.com Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/core/oss/pcm_oss.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) --- a/sound/core/oss/pcm_oss.c +++ b/sound/core/oss/pcm_oss.c @@ -1814,10 +1814,9 @@ static int snd_pcm_oss_get_formats(struc return -ENOMEM; _snd_pcm_hw_params_any(params); err = snd_pcm_hw_refine(substream, params); - format_mask = *hw_param_mask(params, SNDRV_PCM_HW_PARAM_FORMAT); - kfree(params); if (err < 0) - return err; + goto error; + format_mask = hw_param_mask_c(params, SNDRV_PCM_HW_PARAM_FORMAT); for (fmt = 0; fmt < 32; ++fmt) { if (snd_mask_test(&format_mask, fmt)) { int f = snd_pcm_oss_format_to(fmt); @@ -1825,7 +1824,10 @@ static int snd_pcm_oss_get_formats(struc formats |= f; } } - return formats; + + error: + kfree(params); + return err < 0 ? err : formats; } static int snd_pcm_oss_set_format(struct snd_pcm_oss_file *pcm_oss_file, int format) Patches currently in stable-queue which might be from tiwai(a)suse.de are queue-4.4/alsa-firewire-digi00x-handle-all-midi-messages-on-streaming-packets.patch queue-4.4/alsa-pcm-fix-uaf-in-snd_pcm_oss_get_formats.patch queue-4.4/alsa-seq-fix-possible-uaf-in-snd_seq_check_queue.patch queue-4.4/alsa-hda-revert-power_save-option-default-value.patch queue-4.4/alsa-seq-clear-client-entry-before-deleting-else-at-closing.patch

7 years, 1 month

1
0
0 0

Patch "ALSA: hda - Revert power_save option default value" has been added to the 4.4-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: hda - Revert power_save option default value to the 4.4-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-hda-revert-power_save-option-default-value.patch and it can be found in the queue-4.4 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 40088dc4e1ead7df31728c73f5b51d71da18831d Mon Sep 17 00:00:00 2001 From: Takashi Iwai <tiwai(a)suse.de> Date: Mon, 12 Mar 2018 13:55:48 +0100 Subject: ALSA: hda - Revert power_save option default value From: Takashi Iwai <tiwai(a)suse.de> commit 40088dc4e1ead7df31728c73f5b51d71da18831d upstream. With the commit 1ba8f9d30817 ("ALSA: hda: Add a power_save blacklist"), we changed the default value of power_save option to -1 for processing the power-save blacklist. Unfortunately, this seems breaking user-space applications that actually read the power_save parameter value via sysfs and judge / adjust the power-saving status. They see the value -1 as if the power-save is turned off, although the actual value is taken from CONFIG_SND_HDA_POWER_SAVE_DEFAULT and it can be a positive. So, overall, passing -1 there was no good idea. Let's partially revert it -- at least for power_save option default value is restored again to CONFIG_SND_HDA_POWER_SAVE_DEFAULT. Meanwhile, in this patch, we keep the blacklist behavior and make is adjustable via the new option, pm_blacklist. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199073 Fixes: 1ba8f9d30817 ("ALSA: hda: Add a power_save blacklist") Acked-by: Hans de Goede <hdegoede(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/pci/hda/hda_intel.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -179,11 +179,15 @@ static const struct kernel_param_ops par }; #define param_check_xint param_check_int -static int power_save = -1; +static int power_save = CONFIG_SND_HDA_POWER_SAVE_DEFAULT; module_param(power_save, xint, 0644); MODULE_PARM_DESC(power_save, "Automatic power-saving timeout " "(in second, 0 = disable)."); +static bool pm_blacklist = true; +module_param(pm_blacklist, bool, 0644); +MODULE_PARM_DESC(pm_blacklist, "Enable power-management blacklist"); + /* reset the HD-audio controller in power save mode. * this may give more power-saving, but will take longer time to * wake up. @@ -2164,10 +2168,9 @@ static int azx_probe_continue(struct azx val = power_save; #ifdef CONFIG_PM - if (val == -1) { + if (pm_blacklist) { const struct snd_pci_quirk *q; - val = CONFIG_SND_HDA_POWER_SAVE_DEFAULT; q = snd_pci_quirk_lookup(chip->pci, power_save_blacklist); if (q && val) { dev_info(chip->card->dev, "device %04x:%04x is on the power_save blacklist, forcing power_save to 0\n", Patches currently in stable-queue which might be from tiwai(a)suse.de are queue-4.4/alsa-firewire-digi00x-handle-all-midi-messages-on-streaming-packets.patch queue-4.4/alsa-pcm-fix-uaf-in-snd_pcm_oss_get_formats.patch queue-4.4/alsa-seq-fix-possible-uaf-in-snd_seq_check_queue.patch queue-4.4/alsa-hda-revert-power_save-option-default-value.patch queue-4.4/alsa-seq-clear-client-entry-before-deleting-else-at-closing.patch

7 years, 1 month

1
0
0 0

Patch "x86/vm86/32: Fix POPF emulation" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/vm86/32: Fix POPF emulation to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-vm86-32-fix-popf-emulation.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From b5069782453459f6ec1fdeb495d9901a4545fcb5 Mon Sep 17 00:00:00 2001 From: Andy Lutomirski <luto(a)kernel.org> Date: Tue, 13 Mar 2018 22:03:12 -0700 Subject: x86/vm86/32: Fix POPF emulation From: Andy Lutomirski <luto(a)kernel.org> commit b5069782453459f6ec1fdeb495d9901a4545fcb5 upstream. POPF would trap if VIP was set regardless of whether IF was set. Fix it. Suggested-by: Stas Sergeev <stsp(a)list.ru> Reported-by: Bart Oldeman <bartoldeman(a)gmail.com> Signed-off-by: Andy Lutomirski <luto(a)kernel.org> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Denys Vlasenko <dvlasenk(a)redhat.com> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Fixes: 5ed92a8ab71f ("x86/vm86: Use the normal pt_regs area for vm86") Link: http://lkml.kernel.org/r/ce95f40556e7b2178b6bc06ee9557827ff94bd28.152100360… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/vm86_32.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/arch/x86/kernel/vm86_32.c +++ b/arch/x86/kernel/vm86_32.c @@ -727,7 +727,8 @@ void handle_vm86_fault(struct kernel_vm8 return; check_vip: - if (VEFLAGS & X86_EFLAGS_VIP) { + if ((VEFLAGS & (X86_EFLAGS_VIP | X86_EFLAGS_VIF)) == + (X86_EFLAGS_VIP | X86_EFLAGS_VIF)) { save_v86_state(regs, VM86_STI); return; } Patches currently in stable-queue which might be from luto(a)kernel.org are queue-4.15/x86-speculation-objtool-annotate-indirect-calls-jumps-for-objtool-on-32-bit-kernels.patch queue-4.15/x86-vm86-32-fix-popf-emulation.patch queue-4.15/x86-mm-fix-vmalloc_fault-to-use-pxd_large.patch queue-4.15/selftests-x86-entry_from_vm86-add-test-cases-for-popf.patch queue-4.15/selftests-x86-entry_from_vm86-exit-with-1-if-we-fail.patch

7 years, 1 month

1
0
0 0

Patch "x86/speculation: Remove Skylake C2 from Speculation Control microcode blacklist" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/speculation: Remove Skylake C2 from Speculation Control microcode blacklist to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-speculation-remove-skylake-c2-from-speculation-control-microcode-blacklist.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From e3b3121fa8da94cb20f9e0c64ab7981ae47fd085 Mon Sep 17 00:00:00 2001 From: Alexander Sergeyev <sergeev917(a)gmail.com> Date: Tue, 13 Mar 2018 22:38:56 +0300 Subject: x86/speculation: Remove Skylake C2 from Speculation Control microcode blacklist From: Alexander Sergeyev <sergeev917(a)gmail.com> commit e3b3121fa8da94cb20f9e0c64ab7981ae47fd085 upstream. In accordance with Intel's microcode revision guidance from March 6 MCU rev 0xc2 is cleared on both Skylake H/S and Skylake Xeon E3 processors that share CPUID 506E3. Signed-off-by: Alexander Sergeyev <sergeev917(a)gmail.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: Jia Zhang <qianyue.zj(a)alibaba-inc.com> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Kyle Huey <me(a)kylehuey.com> Cc: David Woodhouse <dwmw(a)amazon.co.uk> Link: https://lkml.kernel.org/r/20180313193856.GA8580@localhost.localdomain Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/cpu/intel.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/arch/x86/kernel/cpu/intel.c +++ b/arch/x86/kernel/cpu/intel.c @@ -105,7 +105,7 @@ static void probe_xeon_phi_r3mwait(struc /* * Early microcode releases for the Spectre v2 mitigation were broken. * Information taken from; - * - https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/microcode-up… + * - https://newsroom.intel.com/wp-content/uploads/sites/11/2018/03/microcode-up… * - https://kb.vmware.com/s/article/52345 * - Microcode revisions observed in the wild * - Release note from 20180108 microcode release @@ -123,7 +123,6 @@ static const struct sku_microcode spectr { INTEL_FAM6_KABYLAKE_MOBILE, 0x09, 0x80 }, { INTEL_FAM6_SKYLAKE_X, 0x03, 0x0100013e }, { INTEL_FAM6_SKYLAKE_X, 0x04, 0x0200003c }, - { INTEL_FAM6_SKYLAKE_DESKTOP, 0x03, 0xc2 }, { INTEL_FAM6_BROADWELL_CORE, 0x04, 0x28 }, { INTEL_FAM6_BROADWELL_GT3E, 0x01, 0x1b }, { INTEL_FAM6_BROADWELL_XEON_D, 0x02, 0x14 }, Patches currently in stable-queue which might be from sergeev917(a)gmail.com are queue-4.15/x86-speculation-remove-skylake-c2-from-speculation-control-microcode-blacklist.patch

7 years, 1 month

1
0
0 0

Patch "x86/speculation, objtool: Annotate indirect calls/jumps for objtool on 32-bit kernels" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/speculation, objtool: Annotate indirect calls/jumps for objtool on 32-bit kernels to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-speculation-objtool-annotate-indirect-calls-jumps-for-objtool-on-32-bit-kernels.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From a14bff131108faf50cc0cf864589fd71ee216c96 Mon Sep 17 00:00:00 2001 From: Andy Whitcroft <apw(a)canonical.com> Date: Wed, 14 Mar 2018 11:24:27 +0000 Subject: x86/speculation, objtool: Annotate indirect calls/jumps for objtool on 32-bit kernels From: Andy Whitcroft <apw(a)canonical.com> commit a14bff131108faf50cc0cf864589fd71ee216c96 upstream. In the following commit: 9e0e3c5130e9 ("x86/speculation, objtool: Annotate indirect calls/jumps for objtool") ... we added annotations for CALL_NOSPEC/JMP_NOSPEC on 64-bit x86 kernels, but we did not annotate the 32-bit path. Annotate it similarly. Signed-off-by: Andy Whitcroft <apw(a)canonical.com> Acked-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Cc: Andy Lutomirski <luto(a)kernel.org> Cc: Arjan van de Ven <arjan(a)linux.intel.com> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Dan Williams <dan.j.williams(a)intel.com> Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: David Woodhouse <dwmw2(a)infradead.org> Cc: David Woodhouse <dwmw(a)amazon.co.uk> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Link: http://lkml.kernel.org/r/20180314112427.22351-1-apw@canonical.com Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/include/asm/nospec-branch.h | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) --- a/arch/x86/include/asm/nospec-branch.h +++ b/arch/x86/include/asm/nospec-branch.h @@ -183,7 +183,10 @@ * otherwise we'll run out of registers. We don't care about CET * here, anyway. */ -# define CALL_NOSPEC ALTERNATIVE("call *%[thunk_target]\n", \ +# define CALL_NOSPEC \ + ALTERNATIVE( \ + ANNOTATE_RETPOLINE_SAFE \ + "call *%[thunk_target]\n", \ " jmp 904f;\n" \ " .align 16\n" \ "901: call 903f;\n" \ Patches currently in stable-queue which might be from apw(a)canonical.com are queue-4.15/x86-speculation-objtool-annotate-indirect-calls-jumps-for-objtool-on-32-bit-kernels.patch

7 years, 1 month

1
0
0 0

Patch "x86/mm: Fix vmalloc_fault to use pXd_large" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/mm: Fix vmalloc_fault to use pXd_large to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-mm-fix-vmalloc_fault-to-use-pxd_large.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 18a955219bf7d9008ce480d4451b6b8bf4483a22 Mon Sep 17 00:00:00 2001 From: Toshi Kani <toshi.kani(a)hpe.com> Date: Tue, 13 Mar 2018 11:03:46 -0600 Subject: x86/mm: Fix vmalloc_fault to use pXd_large From: Toshi Kani <toshi.kani(a)hpe.com> commit 18a955219bf7d9008ce480d4451b6b8bf4483a22 upstream. Gratian Crisan reported that vmalloc_fault() crashes when CONFIG_HUGETLBFS is not set since the function inadvertently uses pXn_huge(), which always return 0 in this case. ioremap() does not depend on CONFIG_HUGETLBFS. Fix vmalloc_fault() to call pXd_large() instead. Fixes: f4eafd8bcd52 ("x86/mm: Fix vmalloc_fault() to handle large pages properly") Reported-by: Gratian Crisan <gratian.crisan(a)ni.com> Signed-off-by: Toshi Kani <toshi.kani(a)hpe.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Cc: linux-mm(a)kvack.org Cc: Borislav Petkov <bp(a)alien8.de> Cc: Andy Lutomirski <luto(a)kernel.org> Link: https://lkml.kernel.org/r/20180313170347.3829-2-toshi.kani@hpe.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/mm/fault.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/arch/x86/mm/fault.c +++ b/arch/x86/mm/fault.c @@ -330,7 +330,7 @@ static noinline int vmalloc_fault(unsign if (!pmd_k) return -1; - if (pmd_huge(*pmd_k)) + if (pmd_large(*pmd_k)) return 0; pte_k = pte_offset_kernel(pmd_k, address); @@ -475,7 +475,7 @@ static noinline int vmalloc_fault(unsign if (pud_none(*pud) || pud_pfn(*pud) != pud_pfn(*pud_ref)) BUG(); - if (pud_huge(*pud)) + if (pud_large(*pud)) return 0; pmd = pmd_offset(pud, address); @@ -486,7 +486,7 @@ static noinline int vmalloc_fault(unsign if (pmd_none(*pmd) || pmd_pfn(*pmd) != pmd_pfn(*pmd_ref)) BUG(); - if (pmd_huge(*pmd)) + if (pmd_large(*pmd)) return 0; pte_ref = pte_offset_kernel(pmd_ref, address); Patches currently in stable-queue which might be from toshi.kani(a)hpe.com are queue-4.15/x86-mm-fix-vmalloc_fault-to-use-pxd_large.patch

7 years, 1 month

1
0
0 0

Patch "x86/cpufeatures: Add Intel Total Memory Encryption cpufeature" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/cpufeatures: Add Intel Total Memory Encryption cpufeature to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-cpufeatures-add-intel-total-memory-encryption-cpufeature.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 1da961d72ab0cfbe8b7c26cba731dc2bb6b9494b Mon Sep 17 00:00:00 2001 From: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com> Date: Mon, 5 Mar 2018 19:25:49 +0300 Subject: x86/cpufeatures: Add Intel Total Memory Encryption cpufeature From: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> commit 1da961d72ab0cfbe8b7c26cba731dc2bb6b9494b upstream. CPUID.0x7.0x0:ECX[13] indicates whether CPU supports Intel Total Memory Encryption. Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Dave Hansen <dave.hansen(a)intel.com> Cc: Kai Huang <kai.huang(a)linux.intel.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Tom Lendacky <thomas.lendacky(a)amd.com> Cc: linux-mm(a)kvack.org Link: http://lkml.kernel.org/r/20180305162610.37510-2-kirill.shutemov@linux.intel… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/include/asm/cpufeatures.h | 1 + 1 file changed, 1 insertion(+) --- a/arch/x86/include/asm/cpufeatures.h +++ b/arch/x86/include/asm/cpufeatures.h @@ -314,6 +314,7 @@ #define X86_FEATURE_VPCLMULQDQ (16*32+10) /* Carry-Less Multiplication Double Quadword */ #define X86_FEATURE_AVX512_VNNI (16*32+11) /* Vector Neural Network Instructions */ #define X86_FEATURE_AVX512_BITALG (16*32+12) /* Support for VPOPCNT[B,W] and VPSHUF-BITQMB instructions */ +#define X86_FEATURE_TME (16*32+13) /* Intel Total Memory Encryption */ #define X86_FEATURE_AVX512_VPOPCNTDQ (16*32+14) /* POPCNT for vectors of DW/QW */ #define X86_FEATURE_LA57 (16*32+16) /* 5-level page tables */ #define X86_FEATURE_RDPID (16*32+22) /* RDPID instruction */ Patches currently in stable-queue which might be from kirill.shutemov(a)linux.intel.com are queue-4.15/x86-cpufeatures-add-intel-pconfig-cpufeature.patch queue-4.15/x86-cpufeatures-add-intel-total-memory-encryption-cpufeature.patch

7 years, 1 month

1
0
0 0

Patch "x86/cpufeatures: Add Intel PCONFIG cpufeature" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/cpufeatures: Add Intel PCONFIG cpufeature to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: x86-cpufeatures-add-intel-pconfig-cpufeature.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 7958b2246fadf54b7ff820a2a5a2c5ca1554716f Mon Sep 17 00:00:00 2001 From: "Kirill A. Shutemov" <kirill.shutemov(a)linux.intel.com> Date: Mon, 5 Mar 2018 19:25:51 +0300 Subject: x86/cpufeatures: Add Intel PCONFIG cpufeature From: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> commit 7958b2246fadf54b7ff820a2a5a2c5ca1554716f upstream. CPUID.0x7.0x0:EDX[18] indicates whether Intel CPU support PCONFIG instruction. Signed-off-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Dave Hansen <dave.hansen(a)intel.com> Cc: Kai Huang <kai.huang(a)linux.intel.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Tom Lendacky <thomas.lendacky(a)amd.com> Cc: linux-mm(a)kvack.org Link: http://lkml.kernel.org/r/20180305162610.37510-4-kirill.shutemov@linux.intel… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/include/asm/cpufeatures.h | 1 + 1 file changed, 1 insertion(+) --- a/arch/x86/include/asm/cpufeatures.h +++ b/arch/x86/include/asm/cpufeatures.h @@ -327,6 +327,7 @@ /* Intel-defined CPU features, CPUID level 0x00000007:0 (EDX), word 18 */ #define X86_FEATURE_AVX512_4VNNIW (18*32+ 2) /* AVX-512 Neural Network Instructions */ #define X86_FEATURE_AVX512_4FMAPS (18*32+ 3) /* AVX-512 Multiply Accumulation Single precision */ +#define X86_FEATURE_PCONFIG (18*32+18) /* Intel PCONFIG */ #define X86_FEATURE_SPEC_CTRL (18*32+26) /* "" Speculation Control (IBRS + IBPB) */ #define X86_FEATURE_INTEL_STIBP (18*32+27) /* "" Single Thread Indirect Branch Predictors */ #define X86_FEATURE_ARCH_CAPABILITIES (18*32+29) /* IA32_ARCH_CAPABILITIES MSR (Intel) */ Patches currently in stable-queue which might be from kirill.shutemov(a)linux.intel.com are queue-4.15/x86-cpufeatures-add-intel-pconfig-cpufeature.patch queue-4.15/x86-cpufeatures-add-intel-total-memory-encryption-cpufeature.patch

7 years, 1 month

1
0
0 0

Patch "selftests/x86/entry_from_vm86: Exit with 1 if we fail" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled selftests/x86/entry_from_vm86: Exit with 1 if we fail to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: selftests-x86-entry_from_vm86-exit-with-1-if-we-fail.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 327d53d005ca47b10eae940616ed11c569f75a9b Mon Sep 17 00:00:00 2001 From: Andy Lutomirski <luto(a)kernel.org> Date: Tue, 13 Mar 2018 22:03:10 -0700 Subject: selftests/x86/entry_from_vm86: Exit with 1 if we fail From: Andy Lutomirski <luto(a)kernel.org> commit 327d53d005ca47b10eae940616ed11c569f75a9b upstream. Fix a logic error that caused the test to exit with 0 even if test cases failed. Signed-off-by: Andy Lutomirski <luto(a)kernel.org> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Denys Vlasenko <dvlasenk(a)redhat.com> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Stas Sergeev <stsp(a)list.ru> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: bartoldeman(a)gmail.com Cc: stable(a)vger.kernel.org Link: http://lkml.kernel.org/r/b1cc37144038958a469c8f70a5f47a6a5638636a.152100360… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/x86/entry_from_vm86.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/tools/testing/selftests/x86/entry_from_vm86.c +++ b/tools/testing/selftests/x86/entry_from_vm86.c @@ -318,7 +318,7 @@ int main(void) clearhandler(SIGSEGV); /* Make sure nothing explodes if we fork. */ - if (fork() > 0) + if (fork() == 0) return 0; return (nerrs == 0 ? 0 : 1); Patches currently in stable-queue which might be from luto(a)kernel.org are queue-4.15/x86-speculation-objtool-annotate-indirect-calls-jumps-for-objtool-on-32-bit-kernels.patch queue-4.15/x86-vm86-32-fix-popf-emulation.patch queue-4.15/x86-mm-fix-vmalloc_fault-to-use-pxd_large.patch queue-4.15/selftests-x86-entry_from_vm86-add-test-cases-for-popf.patch queue-4.15/selftests-x86-entry_from_vm86-exit-with-1-if-we-fail.patch

7 years, 1 month

1
0
0 0

Patch "RDMAVT: Fix synchronization around percpu_ref" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled RDMAVT: Fix synchronization around percpu_ref to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: rdmavt-fix-synchronization-around-percpu_ref.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 74b44bbe80b4c62113ac1501482ea1ee40eb9d67 Mon Sep 17 00:00:00 2001 From: Tejun Heo <tj(a)kernel.org> Date: Wed, 14 Mar 2018 12:10:18 -0700 Subject: RDMAVT: Fix synchronization around percpu_ref From: Tejun Heo <tj(a)kernel.org> commit 74b44bbe80b4c62113ac1501482ea1ee40eb9d67 upstream. rvt_mregion uses percpu_ref for reference counting and RCU to protect accesses from lkey_table. When a rvt_mregion needs to be freed, it first gets unregistered from lkey_table and then rvt_check_refs() is called to wait for in-flight usages before the rvt_mregion is freed. rvt_check_refs() seems to have a couple issues. * It has a fast exit path which tests percpu_ref_is_zero(). However, a percpu_ref reading zero doesn't mean that the object can be released. In fact, the ->release() callback might not even have started executing yet. Proceeding with freeing can lead to use-after-free. * lkey_table is RCU protected but there is no RCU grace period in the free path. percpu_ref uses RCU internally but it's sched-RCU whose grace periods are different from regular RCU. Also, it generally isn't a good idea to depend on internal behaviors like this. To address the above issues, this patch removes the fast exit and adds an explicit synchronize_rcu(). Signed-off-by: Tejun Heo <tj(a)kernel.org> Acked-by: Dennis Dalessandro <dennis.dalessandro(a)intel.com> Cc: Mike Marciniszyn <mike.marciniszyn(a)intel.com> Cc: linux-rdma(a)vger.kernel.org Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/sw/rdmavt/mr.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) --- a/drivers/infiniband/sw/rdmavt/mr.c +++ b/drivers/infiniband/sw/rdmavt/mr.c @@ -489,11 +489,13 @@ static int rvt_check_refs(struct rvt_mre unsigned long timeout; struct rvt_dev_info *rdi = ib_to_rvt(mr->pd->device); - if (percpu_ref_is_zero(&mr->refcount)) - return 0; - /* avoid dma mr */ - if (mr->lkey) + if (mr->lkey) { + /* avoid dma mr */ rvt_dereg_clean_qps(mr); + /* @mr was indexed on rcu protected @lkey_table */ + synchronize_rcu(); + } + timeout = wait_for_completion_timeout(&mr->comp, 5 * HZ); if (!timeout) { rvt_pr_err(rdi, Patches currently in stable-queue which might be from tj(a)kernel.org are queue-4.15/rdmavt-fix-synchronization-around-percpu_ref.patch queue-4.15/fs-aio-add-explicit-rcu-grace-period-when-freeing-kioctx.patch queue-4.15/fs-aio-use-rcu-accessors-for-kioctx_table-table.patch

7 years, 1 month

1
0
0 0

Patch "selftests/x86/entry_from_vm86: Add test cases for POPF" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled selftests/x86/entry_from_vm86: Add test cases for POPF to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: selftests-x86-entry_from_vm86-add-test-cases-for-popf.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 78393fdde2a456cafa414b171c90f26a3df98b20 Mon Sep 17 00:00:00 2001 From: Andy Lutomirski <luto(a)kernel.org> Date: Tue, 13 Mar 2018 22:03:11 -0700 Subject: selftests/x86/entry_from_vm86: Add test cases for POPF From: Andy Lutomirski <luto(a)kernel.org> commit 78393fdde2a456cafa414b171c90f26a3df98b20 upstream. POPF is currently broken -- add tests to catch the error. This results in: [RUN] POPF with VIP set and IF clear from vm86 mode [INFO] Exited vm86 mode due to STI [FAIL] Incorrect return reason (started at eip = 0xd, ended at eip = 0xf) because POPF currently fails to check IF before reporting a pending interrupt. This patch also makes the FAIL message a bit more informative. Reported-by: Bart Oldeman <bartoldeman(a)gmail.com> Signed-off-by: Andy Lutomirski <luto(a)kernel.org> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Brian Gerst <brgerst(a)gmail.com> Cc: Denys Vlasenko <dvlasenk(a)redhat.com> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Josh Poimboeuf <jpoimboe(a)redhat.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Stas Sergeev <stsp(a)list.ru> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Link: http://lkml.kernel.org/r/a16270b5cfe7832d6d00c479d0f871066cbdb52b.152100360… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/x86/entry_from_vm86.c | 30 +++++++++++++++++++++++--- 1 file changed, 27 insertions(+), 3 deletions(-) --- a/tools/testing/selftests/x86/entry_from_vm86.c +++ b/tools/testing/selftests/x86/entry_from_vm86.c @@ -95,6 +95,10 @@ asm ( "int3\n\t" "vmcode_int80:\n\t" "int $0x80\n\t" + "vmcode_popf_hlt:\n\t" + "push %ax\n\t" + "popf\n\t" + "hlt\n\t" "vmcode_umip:\n\t" /* addressing via displacements */ "smsw (2052)\n\t" @@ -124,8 +128,8 @@ asm ( extern unsigned char vmcode[], end_vmcode[]; extern unsigned char vmcode_bound[], vmcode_sysenter[], vmcode_syscall[], - vmcode_sti[], vmcode_int3[], vmcode_int80[], vmcode_umip[], - vmcode_umip_str[], vmcode_umip_sldt[]; + vmcode_sti[], vmcode_int3[], vmcode_int80[], vmcode_popf_hlt[], + vmcode_umip[], vmcode_umip_str[], vmcode_umip_sldt[]; /* Returns false if the test was skipped. */ static bool do_test(struct vm86plus_struct *v86, unsigned long eip, @@ -175,7 +179,7 @@ static bool do_test(struct vm86plus_stru (VM86_TYPE(ret) == rettype && VM86_ARG(ret) == retarg)) { printf("[OK]\tReturned correctly\n"); } else { - printf("[FAIL]\tIncorrect return reason\n"); + printf("[FAIL]\tIncorrect return reason (started at eip = 0x%lx, ended at eip = 0x%lx)\n", eip, v86->regs.eip); nerrs++; } @@ -264,6 +268,9 @@ int main(void) v86.regs.ds = load_addr / 16; v86.regs.es = load_addr / 16; + /* Use the end of the page as our stack. */ + v86.regs.esp = 4096; + assert((v86.regs.cs & 3) == 0); /* Looks like RPL = 0 */ /* #BR -- should deliver SIG??? */ @@ -295,6 +302,23 @@ int main(void) v86.regs.eflags &= ~X86_EFLAGS_IF; do_test(&v86, vmcode_sti - vmcode, VM86_STI, 0, "STI with VIP set"); + /* POPF with VIP set but IF clear: should not trap */ + v86.regs.eflags = X86_EFLAGS_VIP; + v86.regs.eax = 0; + do_test(&v86, vmcode_popf_hlt - vmcode, VM86_UNKNOWN, 0, "POPF with VIP set and IF clear"); + + /* POPF with VIP set and IF set: should trap */ + v86.regs.eflags = X86_EFLAGS_VIP; + v86.regs.eax = X86_EFLAGS_IF; + do_test(&v86, vmcode_popf_hlt - vmcode, VM86_STI, 0, "POPF with VIP and IF set"); + + /* POPF with VIP clear and IF set: should not trap */ + v86.regs.eflags = 0; + v86.regs.eax = X86_EFLAGS_IF; + do_test(&v86, vmcode_popf_hlt - vmcode, VM86_UNKNOWN, 0, "POPF with VIP clear and IF set"); + + v86.regs.eflags = 0; + /* INT3 -- should cause #BP */ do_test(&v86, vmcode_int3 - vmcode, VM86_TRAP, 3, "INT3"); Patches currently in stable-queue which might be from luto(a)kernel.org are queue-4.15/x86-speculation-objtool-annotate-indirect-calls-jumps-for-objtool-on-32-bit-kernels.patch queue-4.15/x86-vm86-32-fix-popf-emulation.patch queue-4.15/x86-mm-fix-vmalloc_fault-to-use-pxd_large.patch queue-4.15/selftests-x86-entry_from_vm86-add-test-cases-for-popf.patch queue-4.15/selftests-x86-entry_from_vm86-exit-with-1-if-we-fail.patch

7 years, 1 month

1
0
0 0

Patch "parisc: Handle case where flush_cache_range is called with no context" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled parisc: Handle case where flush_cache_range is called with no context to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: parisc-handle-case-where-flush_cache_range-is-called-with-no-context.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 9ef0f88fe5466c2ca1d2975549ba6be502c464c1 Mon Sep 17 00:00:00 2001 From: John David Anglin <dave.anglin(a)bell.net> Date: Wed, 7 Mar 2018 08:18:05 -0500 Subject: parisc: Handle case where flush_cache_range is called with no context MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: John David Anglin <dave.anglin(a)bell.net> commit 9ef0f88fe5466c2ca1d2975549ba6be502c464c1 upstream. Just when I had decided that flush_cache_range() was always called with a valid context, Helge reported two cases where the "BUG_ON(!vma->vm_mm->context);" was hit on the phantom buildd: kernel BUG at /mnt/sdb6/linux/linux-4.15.4/arch/parisc/kernel/cache.c:587! CPU: 1 PID: 3254 Comm: kworker/1:2 Tainted: G D 4.15.0-1-parisc64-smp #1 Debian 4.15.4-1+b1 Workqueue: events free_ioctx IAOQ[0]: flush_cache_range+0x164/0x168 IAOQ[1]: flush_cache_page+0x0/0x1c8 RP(r2): unmap_page_range+0xae8/0xb88 Backtrace: [<00000000404a6980>] unmap_page_range+0xae8/0xb88 [<00000000404a6ae0>] unmap_single_vma+0xc0/0x188 [<00000000404a6cdc>] zap_page_range_single+0x134/0x1f8 [<00000000404a702c>] unmap_mapping_range+0x1cc/0x208 [<0000000040461518>] truncate_pagecache+0x98/0x108 [<0000000040461624>] truncate_setsize+0x9c/0xb8 [<00000000405d7f30>] put_aio_ring_file+0x80/0x100 [<00000000405d803c>] aio_free_ring+0x8c/0x290 [<00000000405d82c0>] free_ioctx+0x80/0x180 [<0000000040284e6c>] process_one_work+0x21c/0x668 [<00000000402854c4>] worker_thread+0x20c/0x778 [<0000000040291d44>] kthread+0x2d4/0x2e0 [<0000000040204020>] end_fault_vector+0x20/0xc0 This indicates that we need to handle the no context case in flush_cache_range() as we do in flush_cache_mm(). In thinking about this, I realized that we don't need to flush the TLB when there is no context. So, I added context checks to the large flush cases in flush_cache_mm() and flush_cache_range(). The large flush case occurs frequently in flush_cache_mm() and the change should improve fork performance. The v2 version of this change removes the BUG_ON from flush_cache_page() by skipping the TLB flush when there is no context. I also added code to flush the TLB in flush_cache_mm() and flush_cache_range() when we have a context that's not current. Now all three routines handle TLB flushes in a similar manner. Signed-off-by: John David Anglin <dave.anglin(a)bell.net> Cc: stable(a)vger.kernel.org # 4.9+ Signed-off-by: Helge Deller <deller(a)gmx.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/parisc/kernel/cache.c | 41 ++++++++++++++++++++++++++++++++--------- 1 file changed, 32 insertions(+), 9 deletions(-) --- a/arch/parisc/kernel/cache.c +++ b/arch/parisc/kernel/cache.c @@ -543,7 +543,8 @@ void flush_cache_mm(struct mm_struct *mm rp3440, etc. So, avoid it if the mm isn't too big. */ if ((!IS_ENABLED(CONFIG_SMP) || !arch_irqs_disabled()) && mm_total_size(mm) >= parisc_cache_flush_threshold) { - flush_tlb_all(); + if (mm->context) + flush_tlb_all(); flush_cache_all(); return; } @@ -571,6 +572,8 @@ void flush_cache_mm(struct mm_struct *mm pfn = pte_pfn(*ptep); if (!pfn_valid(pfn)) continue; + if (unlikely(mm->context)) + flush_tlb_page(vma, addr); __flush_cache_page(vma, addr, PFN_PHYS(pfn)); } } @@ -579,26 +582,46 @@ void flush_cache_mm(struct mm_struct *mm void flush_cache_range(struct vm_area_struct *vma, unsigned long start, unsigned long end) { + pgd_t *pgd; + unsigned long addr; + if ((!IS_ENABLED(CONFIG_SMP) || !arch_irqs_disabled()) && end - start >= parisc_cache_flush_threshold) { - flush_tlb_range(vma, start, end); + if (vma->vm_mm->context) + flush_tlb_range(vma, start, end); flush_cache_all(); return; } - flush_user_dcache_range_asm(start, end); - if (vma->vm_flags & VM_EXEC) - flush_user_icache_range_asm(start, end); - flush_tlb_range(vma, start, end); + if (vma->vm_mm->context == mfsp(3)) { + flush_user_dcache_range_asm(start, end); + if (vma->vm_flags & VM_EXEC) + flush_user_icache_range_asm(start, end); + flush_tlb_range(vma, start, end); + return; + } + + pgd = vma->vm_mm->pgd; + for (addr = vma->vm_start; addr < vma->vm_end; addr += PAGE_SIZE) { + unsigned long pfn; + pte_t *ptep = get_ptep(pgd, addr); + if (!ptep) + continue; + pfn = pte_pfn(*ptep); + if (pfn_valid(pfn)) { + if (unlikely(vma->vm_mm->context)) + flush_tlb_page(vma, addr); + __flush_cache_page(vma, addr, PFN_PHYS(pfn)); + } + } } void flush_cache_page(struct vm_area_struct *vma, unsigned long vmaddr, unsigned long pfn) { - BUG_ON(!vma->vm_mm->context); - if (pfn_valid(pfn)) { - flush_tlb_page(vma, vmaddr); + if (likely(vma->vm_mm->context)) + flush_tlb_page(vma, vmaddr); __flush_cache_page(vma, vmaddr, PFN_PHYS(pfn)); } } Patches currently in stable-queue which might be from dave.anglin(a)bell.net are queue-4.15/parisc-handle-case-where-flush_cache_range-is-called-with-no-context.patch

7 years, 1 month

1
0
0 0

Patch "lock_parent() needs to recheck if dentry got __dentry_kill'ed under it" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled lock_parent() needs to recheck if dentry got __dentry_kill'ed under it to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: lock_parent-needs-to-recheck-if-dentry-got-__dentry_kill-ed-under-it.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 3b821409632ab778d46e807516b457dfa72736ed Mon Sep 17 00:00:00 2001 From: Al Viro <viro(a)zeniv.linux.org.uk> Date: Fri, 23 Feb 2018 20:47:17 -0500 Subject: lock_parent() needs to recheck if dentry got __dentry_kill'ed under it From: Al Viro <viro(a)zeniv.linux.org.uk> commit 3b821409632ab778d46e807516b457dfa72736ed upstream. In case when dentry passed to lock_parent() is protected from freeing only by the fact that it's on a shrink list and trylock of parent fails, we could get hit by __dentry_kill() (and subsequent dentry_kill(parent)) between unlocking dentry and locking presumed parent. We need to recheck that dentry is alive once we lock both it and parent *and* postpone rcu_read_unlock() until after that point. Otherwise we could return a pointer to struct dentry that already is rcu-scheduled for freeing, with ->d_lock held on it; caller's subsequent attempt to unlock it can end up with memory corruption. Cc: stable(a)vger.kernel.org # 3.12+, counting backports Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/dcache.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) --- a/fs/dcache.c +++ b/fs/dcache.c @@ -644,11 +644,16 @@ again: spin_unlock(&parent->d_lock); goto again; } - rcu_read_unlock(); - if (parent != dentry) + if (parent != dentry) { spin_lock_nested(&dentry->d_lock, DENTRY_D_LOCK_NESTED); - else + if (unlikely(dentry->d_lockref.count < 0)) { + spin_unlock(&parent->d_lock); + parent = NULL; + } + } else { parent = NULL; + } + rcu_read_unlock(); return parent; } Patches currently in stable-queue which might be from viro(a)zeniv.linux.org.uk are queue-4.15/fs-teach-path_connected-to-handle-nfs-filesystems-with-multiple-roots.patch queue-4.15/lock_parent-needs-to-recheck-if-dentry-got-__dentry_kill-ed-under-it.patch

7 years, 1 month

1
0
0 0

Patch "kvm: arm/arm64: vgic-v3: Tighten synchronization for guests using v2 on v3" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled kvm: arm/arm64: vgic-v3: Tighten synchronization for guests using v2 on v3 to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-arm-arm64-vgic-v3-tighten-synchronization-for-guests-using-v2-on-v3.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 27e91ad1e746e341ca2312f29bccb9736be7b476 Mon Sep 17 00:00:00 2001 From: Marc Zyngier <marc.zyngier(a)arm.com> Date: Tue, 6 Mar 2018 21:44:37 +0000 Subject: kvm: arm/arm64: vgic-v3: Tighten synchronization for guests using v2 on v3 From: Marc Zyngier <marc.zyngier(a)arm.com> commit 27e91ad1e746e341ca2312f29bccb9736be7b476 upstream. On guest exit, and when using GICv2 on GICv3, we use a dsb(st) to force synchronization between the memory-mapped guest view and the system-register view that the hypervisor uses. This is incorrect, as the spec calls out the need for "a DSB whose required access type is both loads and stores with any Shareability attribute", while we're only synchronizing stores. We also lack an isb after the dsb to ensure that the latter has actually been executed before we start reading stuff from the sysregs. The fix is pretty easy: turn dsb(st) into dsb(sy), and slap an isb() just after. Cc: stable(a)vger.kernel.org Fixes: f68d2b1b73cc ("arm64: KVM: Implement vgic-v3 save/restore") Acked-by: Christoffer Dall <cdall(a)kernel.org> Reviewed-by: Andre Przywara <andre.przywara(a)arm.com> Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- virt/kvm/arm/hyp/vgic-v3-sr.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/virt/kvm/arm/hyp/vgic-v3-sr.c +++ b/virt/kvm/arm/hyp/vgic-v3-sr.c @@ -215,7 +215,8 @@ void __hyp_text __vgic_v3_save_state(str * are now visible to the system register interface. */ if (!cpu_if->vgic_sre) { - dsb(st); + dsb(sy); + isb(); cpu_if->vgic_vmcr = read_gicreg(ICH_VMCR_EL2); } Patches currently in stable-queue which might be from marc.zyngier(a)arm.com are queue-4.15/kvm-arm-arm64-vgic-don-t-populate-multiple-lrs-with-the-same-vintid.patch queue-4.15/kvm-arm-arm64-vgic-v3-tighten-synchronization-for-guests-using-v2-on-v3.patch queue-4.15/kvm-arm-arm64-reset-mapped-irqs-on-vm-reset.patch queue-4.15/kvm-arm-arm64-reduce-verbosity-of-kvm-init-log.patch

7 years, 1 month

1
0
0 0

Patch "KVM: x86: Fix device passthrough when SME is active" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: x86: Fix device passthrough when SME is active to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-x86-fix-device-passthrough-when-sme-is-active.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From daaf216c06fba4ee4dc3f62715667da929d68774 Mon Sep 17 00:00:00 2001 From: Tom Lendacky <thomas.lendacky(a)amd.com> Date: Thu, 8 Mar 2018 17:17:31 -0600 Subject: KVM: x86: Fix device passthrough when SME is active From: Tom Lendacky <thomas.lendacky(a)amd.com> commit daaf216c06fba4ee4dc3f62715667da929d68774 upstream. When using device passthrough with SME active, the MMIO range that is mapped for the device should not be mapped encrypted. Add a check in set_spte() to insure that a page is not mapped encrypted if that page is a device MMIO page as indicated by kvm_is_mmio_pfn(). Cc: <stable(a)vger.kernel.org> # 4.14.x- Signed-off-by: Tom Lendacky <thomas.lendacky(a)amd.com> Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kvm/mmu.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/arch/x86/kvm/mmu.c +++ b/arch/x86/kvm/mmu.c @@ -2758,8 +2758,10 @@ static int set_spte(struct kvm_vcpu *vcp else pte_access &= ~ACC_WRITE_MASK; + if (!kvm_is_mmio_pfn(pfn)) + spte |= shadow_me_mask; + spte |= (u64)pfn << PAGE_SHIFT; - spte |= shadow_me_mask; if (pte_access & ACC_WRITE_MASK) { Patches currently in stable-queue which might be from thomas.lendacky(a)amd.com are queue-4.15/kvm-x86-fix-device-passthrough-when-sme-is-active.patch queue-4.15/x86-cpufeatures-add-intel-pconfig-cpufeature.patch queue-4.15/x86-cpufeatures-add-intel-total-memory-encryption-cpufeature.patch

7 years, 1 month

1
0
0 0

Patch "KVM: arm/arm64: vgic: Don't populate multiple LRs with the same vintid" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: arm/arm64: vgic: Don't populate multiple LRs with the same vintid to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-arm-arm64-vgic-don-t-populate-multiple-lrs-with-the-same-vintid.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 16ca6a607d84bef0129698d8d808f501afd08d43 Mon Sep 17 00:00:00 2001 From: Marc Zyngier <marc.zyngier(a)arm.com> Date: Tue, 6 Mar 2018 21:48:01 +0000 Subject: KVM: arm/arm64: vgic: Don't populate multiple LRs with the same vintid From: Marc Zyngier <marc.zyngier(a)arm.com> commit 16ca6a607d84bef0129698d8d808f501afd08d43 upstream. The vgic code is trying to be clever when injecting GICv2 SGIs, and will happily populate LRs with the same interrupt number if they come from multiple vcpus (after all, they are distinct interrupt sources). Unfortunately, this is against the letter of the architecture, and the GICv2 architecture spec says "Each valid interrupt stored in the List registers must have a unique VirtualID for that virtual CPU interface.". GICv3 has similar (although slightly ambiguous) restrictions. This results in guests locking up when using GICv2-on-GICv3, for example. The obvious fix is to stop trying so hard, and inject a single vcpu per SGI per guest entry. After all, pending SGIs with multiple source vcpus are pretty rare, and are mostly seen in scenario where the physical CPUs are severely overcomitted. But as we now only inject a single instance of a multi-source SGI per vcpu entry, we may delay those interrupts for longer than strictly necessary, and run the risk of injecting lower priority interrupts in the meantime. In order to address this, we adopt a three stage strategy: - If we encounter a multi-source SGI in the AP list while computing its depth, we force the list to be sorted - When populating the LRs, we prevent the injection of any interrupt of lower priority than that of the first multi-source SGI we've injected. - Finally, the injection of a multi-source SGI triggers the request of a maintenance interrupt when there will be no pending interrupt in the LRs (HCR_NPIE). At the point where the last pending interrupt in the LRs switches from Pending to Active, the maintenance interrupt will be delivered, allowing us to add the remaining SGIs using the same process. Cc: stable(a)vger.kernel.org Fixes: 0919e84c0fc1 ("KVM: arm/arm64: vgic-new: Add IRQ sync/flush framework") Acked-by: Christoffer Dall <cdall(a)kernel.org> Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/linux/irqchip/arm-gic-v3.h | 1 include/linux/irqchip/arm-gic.h | 1 virt/kvm/arm/vgic/vgic-v2.c | 9 ++++- virt/kvm/arm/vgic/vgic-v3.c | 9 ++++- virt/kvm/arm/vgic/vgic.c | 61 ++++++++++++++++++++++++++++--------- virt/kvm/arm/vgic/vgic.h | 2 + 6 files changed, 67 insertions(+), 16 deletions(-) --- a/include/linux/irqchip/arm-gic-v3.h +++ b/include/linux/irqchip/arm-gic-v3.h @@ -503,6 +503,7 @@ #define ICH_HCR_EN (1 << 0) #define ICH_HCR_UIE (1 << 1) +#define ICH_HCR_NPIE (1 << 3) #define ICH_HCR_TC (1 << 10) #define ICH_HCR_TALL0 (1 << 11) #define ICH_HCR_TALL1 (1 << 12) --- a/include/linux/irqchip/arm-gic.h +++ b/include/linux/irqchip/arm-gic.h @@ -84,6 +84,7 @@ #define GICH_HCR_EN (1 << 0) #define GICH_HCR_UIE (1 << 1) +#define GICH_HCR_NPIE (1 << 3) #define GICH_LR_VIRTUALID (0x3ff << 0) #define GICH_LR_PHYSID_CPUID_SHIFT (10) --- a/virt/kvm/arm/vgic/vgic-v2.c +++ b/virt/kvm/arm/vgic/vgic-v2.c @@ -37,6 +37,13 @@ void vgic_v2_init_lrs(void) vgic_v2_write_lr(i, 0); } +void vgic_v2_set_npie(struct kvm_vcpu *vcpu) +{ + struct vgic_v2_cpu_if *cpuif = &vcpu->arch.vgic_cpu.vgic_v2; + + cpuif->vgic_hcr |= GICH_HCR_NPIE; +} + void vgic_v2_set_underflow(struct kvm_vcpu *vcpu) { struct vgic_v2_cpu_if *cpuif = &vcpu->arch.vgic_cpu.vgic_v2; @@ -64,7 +71,7 @@ void vgic_v2_fold_lr_state(struct kvm_vc int lr; unsigned long flags; - cpuif->vgic_hcr &= ~GICH_HCR_UIE; + cpuif->vgic_hcr &= ~(GICH_HCR_UIE | GICH_HCR_NPIE); for (lr = 0; lr < vgic_cpu->used_lrs; lr++) { u32 val = cpuif->vgic_lr[lr]; --- a/virt/kvm/arm/vgic/vgic-v3.c +++ b/virt/kvm/arm/vgic/vgic-v3.c @@ -26,6 +26,13 @@ static bool group1_trap; static bool common_trap; static bool gicv4_enable; +void vgic_v3_set_npie(struct kvm_vcpu *vcpu) +{ + struct vgic_v3_cpu_if *cpuif = &vcpu->arch.vgic_cpu.vgic_v3; + + cpuif->vgic_hcr |= ICH_HCR_NPIE; +} + void vgic_v3_set_underflow(struct kvm_vcpu *vcpu) { struct vgic_v3_cpu_if *cpuif = &vcpu->arch.vgic_cpu.vgic_v3; @@ -47,7 +54,7 @@ void vgic_v3_fold_lr_state(struct kvm_vc int lr; unsigned long flags; - cpuif->vgic_hcr &= ~ICH_HCR_UIE; + cpuif->vgic_hcr &= ~(ICH_HCR_UIE | ICH_HCR_NPIE); for (lr = 0; lr < vgic_cpu->used_lrs; lr++) { u64 val = cpuif->vgic_lr[lr]; --- a/virt/kvm/arm/vgic/vgic.c +++ b/virt/kvm/arm/vgic/vgic.c @@ -675,22 +675,37 @@ static inline void vgic_set_underflow(st vgic_v3_set_underflow(vcpu); } +static inline void vgic_set_npie(struct kvm_vcpu *vcpu) +{ + if (kvm_vgic_global_state.type == VGIC_V2) + vgic_v2_set_npie(vcpu); + else + vgic_v3_set_npie(vcpu); +} + /* Requires the ap_list_lock to be held. */ -static int compute_ap_list_depth(struct kvm_vcpu *vcpu) +static int compute_ap_list_depth(struct kvm_vcpu *vcpu, + bool *multi_sgi) { struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu; struct vgic_irq *irq; int count = 0; + *multi_sgi = false; + DEBUG_SPINLOCK_BUG_ON(!spin_is_locked(&vgic_cpu->ap_list_lock)); list_for_each_entry(irq, &vgic_cpu->ap_list_head, ap_list) { spin_lock(&irq->irq_lock); /* GICv2 SGIs can count for more than one... */ - if (vgic_irq_is_sgi(irq->intid) && irq->source) - count += hweight8(irq->source); - else + if (vgic_irq_is_sgi(irq->intid) && irq->source) { + int w = hweight8(irq->source); + + count += w; + *multi_sgi |= (w > 1); + } else { count++; + } spin_unlock(&irq->irq_lock); } return count; @@ -701,28 +716,43 @@ static void vgic_flush_lr_state(struct k { struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu; struct vgic_irq *irq; - int count = 0; + int count; + bool npie = false; + bool multi_sgi; + u8 prio = 0xff; DEBUG_SPINLOCK_BUG_ON(!spin_is_locked(&vgic_cpu->ap_list_lock)); - if (compute_ap_list_depth(vcpu) > kvm_vgic_global_state.nr_lr) + count = compute_ap_list_depth(vcpu, &multi_sgi); + if (count > kvm_vgic_global_state.nr_lr || multi_sgi) vgic_sort_ap_list(vcpu); + count = 0; + list_for_each_entry(irq, &vgic_cpu->ap_list_head, ap_list) { spin_lock(&irq->irq_lock); - if (unlikely(vgic_target_oracle(irq) != vcpu)) - goto next; - /* - * If we get an SGI with multiple sources, try to get - * them in all at once. + * If we have multi-SGIs in the pipeline, we need to + * guarantee that they are all seen before any IRQ of + * lower priority. In that case, we need to filter out + * these interrupts by exiting early. This is easy as + * the AP list has been sorted already. */ - do { + if (multi_sgi && irq->priority > prio) { + spin_unlock(&irq->irq_lock); + break; + } + + if (likely(vgic_target_oracle(irq) == vcpu)) { vgic_populate_lr(vcpu, irq, count++); - } while (irq->source && count < kvm_vgic_global_state.nr_lr); -next: + if (irq->source) { + npie = true; + prio = irq->priority; + } + } + spin_unlock(&irq->irq_lock); if (count == kvm_vgic_global_state.nr_lr) { @@ -733,6 +763,9 @@ next: } } + if (npie) + vgic_set_npie(vcpu); + vcpu->arch.vgic_cpu.used_lrs = count; /* Nuke remaining LRs */ --- a/virt/kvm/arm/vgic/vgic.h +++ b/virt/kvm/arm/vgic/vgic.h @@ -151,6 +151,7 @@ void vgic_v2_fold_lr_state(struct kvm_vc void vgic_v2_populate_lr(struct kvm_vcpu *vcpu, struct vgic_irq *irq, int lr); void vgic_v2_clear_lr(struct kvm_vcpu *vcpu, int lr); void vgic_v2_set_underflow(struct kvm_vcpu *vcpu); +void vgic_v2_set_npie(struct kvm_vcpu *vcpu); int vgic_v2_has_attr_regs(struct kvm_device *dev, struct kvm_device_attr *attr); int vgic_v2_dist_uaccess(struct kvm_vcpu *vcpu, bool is_write, int offset, u32 *val); @@ -180,6 +181,7 @@ void vgic_v3_fold_lr_state(struct kvm_vc void vgic_v3_populate_lr(struct kvm_vcpu *vcpu, struct vgic_irq *irq, int lr); void vgic_v3_clear_lr(struct kvm_vcpu *vcpu, int lr); void vgic_v3_set_underflow(struct kvm_vcpu *vcpu); +void vgic_v3_set_npie(struct kvm_vcpu *vcpu); void vgic_v3_set_vmcr(struct kvm_vcpu *vcpu, struct vgic_vmcr *vmcr); void vgic_v3_get_vmcr(struct kvm_vcpu *vcpu, struct vgic_vmcr *vmcr); void vgic_v3_enable(struct kvm_vcpu *vcpu); Patches currently in stable-queue which might be from marc.zyngier(a)arm.com are queue-4.15/kvm-arm-arm64-vgic-don-t-populate-multiple-lrs-with-the-same-vintid.patch queue-4.15/kvm-arm-arm64-vgic-v3-tighten-synchronization-for-guests-using-v2-on-v3.patch queue-4.15/kvm-arm-arm64-reset-mapped-irqs-on-vm-reset.patch queue-4.15/kvm-arm-arm64-reduce-verbosity-of-kvm-init-log.patch

7 years, 1 month

1
0
0 0

Patch "KVM: arm/arm64: Reduce verbosity of KVM init log" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: arm/arm64: Reduce verbosity of KVM init log to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-arm-arm64-reduce-verbosity-of-kvm-init-log.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 76600428c3677659e3c3633bb4f2ea302220a275 Mon Sep 17 00:00:00 2001 From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Date: Fri, 2 Mar 2018 08:16:30 +0000 Subject: KVM: arm/arm64: Reduce verbosity of KVM init log From: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> commit 76600428c3677659e3c3633bb4f2ea302220a275 upstream. On my GICv3 system, the following is printed to the kernel log at boot: kvm [1]: 8-bit VMID kvm [1]: IDMAP page: d20e35000 kvm [1]: HYP VA range: 800000000000:ffffffffffff kvm [1]: vgic-v2@2c020000 kvm [1]: GIC system register CPU interface enabled kvm [1]: vgic interrupt IRQ1 kvm [1]: virtual timer IRQ4 kvm [1]: Hyp mode initialized successfully The KVM IDMAP is a mapping of a statically allocated kernel structure, and so printing its physical address leaks the physical placement of the kernel when physical KASLR in effect. So change the kvm_info() to kvm_debug() to remove it from the log output. While at it, trim the output a bit more: IRQ numbers can be found in /proc/interrupts, and the HYP VA and vgic-v2 lines are not highly informational either. Cc: <stable(a)vger.kernel.org> Acked-by: Will Deacon <will.deacon(a)arm.com> Acked-by: Christoffer Dall <cdall(a)kernel.org> Signed-off-by: Ard Biesheuvel <ard.biesheuvel(a)linaro.org> Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- virt/kvm/arm/arch_timer.c | 2 +- virt/kvm/arm/mmu.c | 6 +++--- virt/kvm/arm/vgic/vgic-v2.c | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) --- a/virt/kvm/arm/arch_timer.c +++ b/virt/kvm/arm/arch_timer.c @@ -773,7 +773,7 @@ int kvm_timer_hyp_init(bool has_gic) } } - kvm_info("virtual timer IRQ%d\n", host_vtimer_irq); + kvm_debug("virtual timer IRQ%d\n", host_vtimer_irq); cpuhp_setup_state(CPUHP_AP_KVM_ARM_TIMER_STARTING, "kvm/arm/timer:starting", kvm_timer_starting_cpu, --- a/virt/kvm/arm/mmu.c +++ b/virt/kvm/arm/mmu.c @@ -1760,9 +1760,9 @@ int kvm_mmu_init(void) */ BUG_ON((hyp_idmap_start ^ (hyp_idmap_end - 1)) & PAGE_MASK); - kvm_info("IDMAP page: %lx\n", hyp_idmap_start); - kvm_info("HYP VA range: %lx:%lx\n", - kern_hyp_va(PAGE_OFFSET), kern_hyp_va(~0UL)); + kvm_debug("IDMAP page: %lx\n", hyp_idmap_start); + kvm_debug("HYP VA range: %lx:%lx\n", + kern_hyp_va(PAGE_OFFSET), kern_hyp_va(~0UL)); if (hyp_idmap_start >= kern_hyp_va(PAGE_OFFSET) && hyp_idmap_start < kern_hyp_va(~0UL) && --- a/virt/kvm/arm/vgic/vgic-v2.c +++ b/virt/kvm/arm/vgic/vgic-v2.c @@ -381,7 +381,7 @@ int vgic_v2_probe(const struct gic_kvm_i kvm_vgic_global_state.type = VGIC_V2; kvm_vgic_global_state.max_gic_vcpus = VGIC_V2_MAX_CPUS; - kvm_info("vgic-v2@%llx\n", info->vctrl.start); + kvm_debug("vgic-v2@%llx\n", info->vctrl.start); return 0; out: Patches currently in stable-queue which might be from ard.biesheuvel(a)linaro.org are queue-4.15/kvm-arm-arm64-reduce-verbosity-of-kvm-init-log.patch

7 years, 1 month

1
0
0 0

Patch "KVM: arm/arm64: Reset mapped IRQs on VM reset" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: arm/arm64: Reset mapped IRQs on VM reset to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-arm-arm64-reset-mapped-irqs-on-vm-reset.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 413aa807ae39fed7e387c175d2d0ae9fcf6c0c9d Mon Sep 17 00:00:00 2001 From: Christoffer Dall <cdall(a)kernel.org> Date: Mon, 5 Mar 2018 11:36:38 +0100 Subject: KVM: arm/arm64: Reset mapped IRQs on VM reset From: Christoffer Dall <cdall(a)kernel.org> commit 413aa807ae39fed7e387c175d2d0ae9fcf6c0c9d upstream. We currently don't allow resetting mapped IRQs from userspace, because their state is controlled by the hardware. But we do need to reset the state when the VM is reset, so we provide a function for the 'owner' of the mapped interrupt to reset the interrupt state. Currently only the timer uses mapped interrupts, so we call this function from the timer reset logic. Cc: stable(a)vger.kernel.org Fixes: 4c60e360d6df ("KVM: arm/arm64: Provide a get_input_level for the arch timer") Signed-off-by: Christoffer Dall <cdall(a)kernel.org> Signed-off-by: Marc Zyngier <marc.zyngier(a)arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/kvm/arm_vgic.h | 1 + virt/kvm/arm/arch_timer.c | 4 ++++ virt/kvm/arm/vgic/vgic.c | 26 ++++++++++++++++++++++++++ 3 files changed, 31 insertions(+) --- a/include/kvm/arm_vgic.h +++ b/include/kvm/arm_vgic.h @@ -349,6 +349,7 @@ void kvm_vgic_put(struct kvm_vcpu *vcpu) bool kvm_vcpu_has_pending_irqs(struct kvm_vcpu *vcpu); void kvm_vgic_sync_hwstate(struct kvm_vcpu *vcpu); void kvm_vgic_flush_hwstate(struct kvm_vcpu *vcpu); +void kvm_vgic_reset_mapped_irq(struct kvm_vcpu *vcpu, u32 vintid); void vgic_v3_dispatch_sgi(struct kvm_vcpu *vcpu, u64 reg); --- a/virt/kvm/arm/arch_timer.c +++ b/virt/kvm/arm/arch_timer.c @@ -589,6 +589,7 @@ void kvm_timer_sync_hwstate(struct kvm_v int kvm_timer_vcpu_reset(struct kvm_vcpu *vcpu) { + struct arch_timer_cpu *timer = &vcpu->arch.timer_cpu; struct arch_timer_context *vtimer = vcpu_vtimer(vcpu); struct arch_timer_context *ptimer = vcpu_ptimer(vcpu); @@ -602,6 +603,9 @@ int kvm_timer_vcpu_reset(struct kvm_vcpu ptimer->cnt_ctl = 0; kvm_timer_update_state(vcpu); + if (timer->enabled && irqchip_in_kernel(vcpu->kvm)) + kvm_vgic_reset_mapped_irq(vcpu, vtimer->irq.irq); + return 0; } --- a/virt/kvm/arm/vgic/vgic.c +++ b/virt/kvm/arm/vgic/vgic.c @@ -460,6 +460,32 @@ int kvm_vgic_map_phys_irq(struct kvm_vcp return ret; } +/** + * kvm_vgic_reset_mapped_irq - Reset a mapped IRQ + * @vcpu: The VCPU pointer + * @vintid: The INTID of the interrupt + * + * Reset the active and pending states of a mapped interrupt. Kernel + * subsystems injecting mapped interrupts should reset their interrupt lines + * when we are doing a reset of the VM. + */ +void kvm_vgic_reset_mapped_irq(struct kvm_vcpu *vcpu, u32 vintid) +{ + struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, vintid); + unsigned long flags; + + if (!irq->hw) + goto out; + + spin_lock_irqsave(&irq->irq_lock, flags); + irq->active = false; + irq->pending_latch = false; + irq->line_level = false; + spin_unlock_irqrestore(&irq->irq_lock, flags); +out: + vgic_put_irq(vcpu->kvm, irq); +} + int kvm_vgic_unmap_phys_irq(struct kvm_vcpu *vcpu, unsigned int vintid) { struct vgic_irq *irq; Patches currently in stable-queue which might be from cdall(a)kernel.org are queue-4.15/kvm-arm-arm64-vgic-don-t-populate-multiple-lrs-with-the-same-vintid.patch queue-4.15/kvm-arm-arm64-vgic-v3-tighten-synchronization-for-guests-using-v2-on-v3.patch queue-4.15/kvm-arm-arm64-reset-mapped-irqs-on-vm-reset.patch queue-4.15/kvm-arm-arm64-reduce-verbosity-of-kvm-init-log.patch

7 years, 1 month

1
0
0 0

Patch "fs: Teach path_connected to handle nfs filesystems with multiple roots." has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled fs: Teach path_connected to handle nfs filesystems with multiple roots. to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: fs-teach-path_connected-to-handle-nfs-filesystems-with-multiple-roots.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 95dd77580ccd66a0da96e6d4696945b8cea39431 Mon Sep 17 00:00:00 2001 From: "Eric W. Biederman" <ebiederm(a)xmission.com> Date: Wed, 14 Mar 2018 18:20:29 -0500 Subject: fs: Teach path_connected to handle nfs filesystems with multiple roots. From: Eric W. Biederman <ebiederm(a)xmission.com> commit 95dd77580ccd66a0da96e6d4696945b8cea39431 upstream. On nfsv2 and nfsv3 the nfs server can export subsets of the same filesystem and report the same filesystem identifier, so that the nfs client can know they are the same filesystem. The subsets can be from disjoint directory trees. The nfsv2 and nfsv3 filesystems provides no way to find the common root of all directory trees exported form the server with the same filesystem identifier. The practical result is that in struct super s_root for nfs s_root is not necessarily the root of the filesystem. The nfs mount code sets s_root to the root of the first subset of the nfs filesystem that the kernel mounts. This effects the dcache invalidation code in generic_shutdown_super currently called shrunk_dcache_for_umount and that code for years has gone through an additional list of dentries that might be dentry trees that need to be freed to accomodate nfs. When I wrote path_connected I did not realize nfs was so special, and it's hueristic for avoiding calling is_subdir can fail. The practical case where this fails is when there is a move of a directory from the subtree exposed by one nfs mount to the subtree exposed by another nfs mount. This move can happen either locally or remotely. With the remote case requiring that the move directory be cached before the move and that after the move someone walks the path to where the move directory now exists and in so doing causes the already cached directory to be moved in the dcache through the magic of d_splice_alias. If someone whose working directory is in the move directory or a subdirectory and now starts calling .. from the initial mount of nfs (where s_root == mnt_root), then path_connected as a heuristic will not bother with the is_subdir check. As s_root really is not the root of the nfs filesystem this heuristic is wrong, and the path may actually not be connected and path_connected can fail. The is_subdir function might be cheap enough that we can call it unconditionally. Verifying that will take some benchmarking and the result may not be the same on all kernels this fix needs to be backported to. So I am avoiding that for now. Filesystems with snapshots such as nilfs and btrfs do something similar. But as the directory tree of the snapshots are disjoint from one another and from the main directory tree rename won't move things between them and this problem will not occur. Cc: stable(a)vger.kernel.org Reported-by: Al Viro <viro(a)ZenIV.linux.org.uk> Fixes: 397d425dc26d ("vfs: Test for and handle paths that are unreachable from their mnt_root") Signed-off-by: "Eric W. Biederman" <ebiederm(a)xmission.com> Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/namei.c | 5 +++-- fs/nfs/super.c | 2 ++ include/linux/fs.h | 1 + 3 files changed, 6 insertions(+), 2 deletions(-) --- a/fs/namei.c +++ b/fs/namei.c @@ -578,9 +578,10 @@ static int __nd_alloc_stack(struct namei static bool path_connected(const struct path *path) { struct vfsmount *mnt = path->mnt; + struct super_block *sb = mnt->mnt_sb; - /* Only bind mounts can have disconnected paths */ - if (mnt->mnt_root == mnt->mnt_sb->s_root) + /* Bind mounts and multi-root filesystems can have disconnected paths */ + if (!(sb->s_iflags & SB_I_MULTIROOT) && (mnt->mnt_root == sb->s_root)) return true; return is_subdir(path->dentry, mnt->mnt_root); --- a/fs/nfs/super.c +++ b/fs/nfs/super.c @@ -2631,6 +2631,8 @@ struct dentry *nfs_fs_mount_common(struc /* initial superblock/root creation */ mount_info->fill_super(s, mount_info); nfs_get_cache_cookie(s, mount_info->parsed, mount_info->cloned); + if (!(server->flags & NFS_MOUNT_UNSHARED)) + s->s_iflags |= SB_I_MULTIROOT; } mntroot = nfs_get_root(s, mount_info->mntfh, dev_name); --- a/include/linux/fs.h +++ b/include/linux/fs.h @@ -1312,6 +1312,7 @@ extern int send_sigurg(struct fown_struc #define SB_I_CGROUPWB 0x00000001 /* cgroup-aware writeback enabled */ #define SB_I_NOEXEC 0x00000002 /* Ignore executables on this fs */ #define SB_I_NODEV 0x00000004 /* Ignore devices on this fs */ +#define SB_I_MULTIROOT 0x00000008 /* Multiple roots to the dentry tree */ /* sb->s_iflags to limit user namespace mounts */ #define SB_I_USERNS_VISIBLE 0x00000010 /* fstype already mounted */ Patches currently in stable-queue which might be from ebiederm(a)xmission.com are queue-4.15/fs-teach-path_connected-to-handle-nfs-filesystems-with-multiple-roots.patch

7 years, 1 month

1
0
0 0

Patch "fs/aio: Use RCU accessors for kioctx_table->table[]" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled fs/aio: Use RCU accessors for kioctx_table->table[] to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: fs-aio-use-rcu-accessors-for-kioctx_table-table.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d0264c01e7587001a8c4608a5d1818dba9a4c11a Mon Sep 17 00:00:00 2001 From: Tejun Heo <tj(a)kernel.org> Date: Wed, 14 Mar 2018 12:10:17 -0700 Subject: fs/aio: Use RCU accessors for kioctx_table->table[] From: Tejun Heo <tj(a)kernel.org> commit d0264c01e7587001a8c4608a5d1818dba9a4c11a upstream. While converting ioctx index from a list to a table, db446a08c23d ("aio: convert the ioctx list to table lookup v3") missed tagging kioctx_table->table[] as an array of RCU pointers and using the appropriate RCU accessors. This introduces a small window in the lookup path where init and access may race. Mark kioctx_table->table[] with __rcu and use the approriate RCU accessors when using the field. Signed-off-by: Tejun Heo <tj(a)kernel.org> Reported-by: Jann Horn <jannh(a)google.com> Fixes: db446a08c23d ("aio: convert the ioctx list to table lookup v3") Cc: Benjamin LaHaise <bcrl(a)kvack.org> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: stable(a)vger.kernel.org # v3.12+ Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/aio.c | 21 +++++++++++---------- 1 file changed, 11 insertions(+), 10 deletions(-) --- a/fs/aio.c +++ b/fs/aio.c @@ -68,9 +68,9 @@ struct aio_ring { #define AIO_RING_PAGES 8 struct kioctx_table { - struct rcu_head rcu; - unsigned nr; - struct kioctx *table[]; + struct rcu_head rcu; + unsigned nr; + struct kioctx __rcu *table[]; }; struct kioctx_cpu { @@ -330,7 +330,7 @@ static int aio_ring_mremap(struct vm_are for (i = 0; i < table->nr; i++) { struct kioctx *ctx; - ctx = table->table[i]; + ctx = rcu_dereference(table->table[i]); if (ctx && ctx->aio_ring_file == file) { if (!atomic_read(&ctx->dead)) { ctx->user_id = ctx->mmap_base = vma->vm_start; @@ -666,9 +666,9 @@ static int ioctx_add_table(struct kioctx while (1) { if (table) for (i = 0; i < table->nr; i++) - if (!table->table[i]) { + if (!rcu_access_pointer(table->table[i])) { ctx->id = i; - table->table[i] = ctx; + rcu_assign_pointer(table->table[i], ctx); spin_unlock(&mm->ioctx_lock); /* While kioctx setup is in progress, @@ -849,8 +849,8 @@ static int kill_ioctx(struct mm_struct * } table = rcu_dereference_raw(mm->ioctx_table); - WARN_ON(ctx != table->table[ctx->id]); - table->table[ctx->id] = NULL; + WARN_ON(ctx != rcu_access_pointer(table->table[ctx->id])); + RCU_INIT_POINTER(table->table[ctx->id], NULL); spin_unlock(&mm->ioctx_lock); /* free_ioctx_reqs() will do the necessary RCU synchronization */ @@ -895,7 +895,8 @@ void exit_aio(struct mm_struct *mm) skipped = 0; for (i = 0; i < table->nr; ++i) { - struct kioctx *ctx = table->table[i]; + struct kioctx *ctx = + rcu_dereference_protected(table->table[i], true); if (!ctx) { skipped++; @@ -1084,7 +1085,7 @@ static struct kioctx *lookup_ioctx(unsig if (!table || id >= table->nr) goto out; - ctx = table->table[id]; + ctx = rcu_dereference(table->table[id]); if (ctx && ctx->user_id == ctx_id) { percpu_ref_get(&ctx->users); ret = ctx; Patches currently in stable-queue which might be from tj(a)kernel.org are queue-4.15/rdmavt-fix-synchronization-around-percpu_ref.patch queue-4.15/fs-aio-add-explicit-rcu-grace-period-when-freeing-kioctx.patch queue-4.15/fs-aio-use-rcu-accessors-for-kioctx_table-table.patch

7 years, 1 month

1
0
0 0

Patch "fs/aio: Add explicit RCU grace period when freeing kioctx" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled fs/aio: Add explicit RCU grace period when freeing kioctx to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: fs-aio-add-explicit-rcu-grace-period-when-freeing-kioctx.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From a6d7cff472eea87d96899a20fa718d2bab7109f3 Mon Sep 17 00:00:00 2001 From: Tejun Heo <tj(a)kernel.org> Date: Wed, 14 Mar 2018 12:10:17 -0700 Subject: fs/aio: Add explicit RCU grace period when freeing kioctx From: Tejun Heo <tj(a)kernel.org> commit a6d7cff472eea87d96899a20fa718d2bab7109f3 upstream. While fixing refcounting, e34ecee2ae79 ("aio: Fix a trinity splat") incorrectly removed explicit RCU grace period before freeing kioctx. The intention seems to be depending on the internal RCU grace periods of percpu_ref; however, percpu_ref uses a different flavor of RCU, sched-RCU. This can lead to kioctx being freed while RCU read protected dereferences are still in progress. Fix it by updating free_ioctx() to go through call_rcu() explicitly. v2: Comment added to explain double bouncing. Signed-off-by: Tejun Heo <tj(a)kernel.org> Reported-by: Jann Horn <jannh(a)google.com> Fixes: e34ecee2ae79 ("aio: Fix a trinity splat") Cc: Kent Overstreet <kent.overstreet(a)gmail.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: stable(a)vger.kernel.org # v3.13+ Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/aio.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-) --- a/fs/aio.c +++ b/fs/aio.c @@ -115,7 +115,8 @@ struct kioctx { struct page **ring_pages; long nr_pages; - struct work_struct free_work; + struct rcu_head free_rcu; + struct work_struct free_work; /* see free_ioctx() */ /* * signals when all in-flight requests are done @@ -588,6 +589,12 @@ static int kiocb_cancel(struct aio_kiocb return cancel(&kiocb->common); } +/* + * free_ioctx() should be RCU delayed to synchronize against the RCU + * protected lookup_ioctx() and also needs process context to call + * aio_free_ring(), so the double bouncing through kioctx->free_rcu and + * ->free_work. + */ static void free_ioctx(struct work_struct *work) { struct kioctx *ctx = container_of(work, struct kioctx, free_work); @@ -601,6 +608,14 @@ static void free_ioctx(struct work_struc kmem_cache_free(kioctx_cachep, ctx); } +static void free_ioctx_rcufn(struct rcu_head *head) +{ + struct kioctx *ctx = container_of(head, struct kioctx, free_rcu); + + INIT_WORK(&ctx->free_work, free_ioctx); + schedule_work(&ctx->free_work); +} + static void free_ioctx_reqs(struct percpu_ref *ref) { struct kioctx *ctx = container_of(ref, struct kioctx, reqs); @@ -609,8 +624,8 @@ static void free_ioctx_reqs(struct percp if (ctx->rq_wait && atomic_dec_and_test(&ctx->rq_wait->count)) complete(&ctx->rq_wait->comp); - INIT_WORK(&ctx->free_work, free_ioctx); - schedule_work(&ctx->free_work); + /* Synchronize against RCU protected table->table[] dereferences */ + call_rcu(&ctx->free_rcu, free_ioctx_rcufn); } /* @@ -838,7 +853,7 @@ static int kill_ioctx(struct mm_struct * table->table[ctx->id] = NULL; spin_unlock(&mm->ioctx_lock); - /* percpu_ref_kill() will do the necessary call_rcu() */ + /* free_ioctx_reqs() will do the necessary RCU synchronization */ wake_up_all(&ctx->wait); /* Patches currently in stable-queue which might be from tj(a)kernel.org are queue-4.15/rdmavt-fix-synchronization-around-percpu_ref.patch queue-4.15/fs-aio-add-explicit-rcu-grace-period-when-freeing-kioctx.patch queue-4.15/fs-aio-use-rcu-accessors-for-kioctx_table-table.patch

7 years, 1 month

1
0
0 0

Patch "drm/radeon: fix prime teardown order" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/radeon: fix prime teardown order to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-radeon-fix-prime-teardown-order.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 0f4f715bc6bed3bf14c5cd7d5fe88d443e756b14 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Christian=20K=C3=B6nig?= <christian.koenig(a)amd.com> Date: Fri, 9 Mar 2018 14:44:32 +0100 Subject: drm/radeon: fix prime teardown order MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Christian König <christian.koenig(a)amd.com> commit 0f4f715bc6bed3bf14c5cd7d5fe88d443e756b14 upstream. We unmapped imported DMA-bufs when the GEM handle was dropped, not when the hardware was done with the buffere. Signed-off-by: Christian König <christian.koenig(a)amd.com> Reviewed-by: Michel Dänzer <michel.daenzer(a)amd.com> CC: stable(a)vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/radeon/radeon_gem.c | 2 -- drivers/gpu/drm/radeon/radeon_object.c | 2 ++ 2 files changed, 2 insertions(+), 2 deletions(-) --- a/drivers/gpu/drm/radeon/radeon_gem.c +++ b/drivers/gpu/drm/radeon/radeon_gem.c @@ -34,8 +34,6 @@ void radeon_gem_object_free(struct drm_g struct radeon_bo *robj = gem_to_radeon_bo(gobj); if (robj) { - if (robj->gem_base.import_attach) - drm_prime_gem_destroy(&robj->gem_base, robj->tbo.sg); radeon_mn_unregister(robj); radeon_bo_unref(&robj); } --- a/drivers/gpu/drm/radeon/radeon_object.c +++ b/drivers/gpu/drm/radeon/radeon_object.c @@ -82,6 +82,8 @@ static void radeon_ttm_bo_destroy(struct mutex_unlock(&bo->rdev->gem.mutex); radeon_bo_clear_surface_reg(bo); WARN_ON_ONCE(!list_empty(&bo->va)); + if (bo->gem_base.import_attach) + drm_prime_gem_destroy(&bo->gem_base, bo->tbo.sg); drm_gem_object_release(&bo->gem_base); kfree(bo); } Patches currently in stable-queue which might be from christian.koenig(a)amd.com are queue-4.15/drm-amdgpu-fix-prime-teardown-order.patch queue-4.15/drm-radeon-fix-prime-teardown-order.patch

7 years, 1 month

1
0
0 0

Patch "drm/nouveau/mmu: ALIGN_DOWN correct variable" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/nouveau/mmu: ALIGN_DOWN correct variable to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-nouveau-mmu-align_down-correct-variable.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From da5e45e619b3f101420c38b3006a9ae4f3ad19b0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?M=C4=81ris=20Narti=C5=A1s?= <maris.nartiss(a)gmail.com> Date: Fri, 16 Mar 2018 11:38:43 +1000 Subject: drm/nouveau/mmu: ALIGN_DOWN correct variable From: Māris Nartišs <maris.nartiss(a)gmail.com> commit da5e45e619b3f101420c38b3006a9ae4f3ad19b0 upstream. Commit 7110c89bb8852ff8b0f88ce05b332b3fe22bd11e ("mmu: swap out round for ALIGN") replaced two calls to round/rounddown with ALIGN/ALIGN_DOWN, but erroneously applied ALIGN_DOWN to a different variable (addr) and left intended variable (tail) not rounded/ALIGNed. As a result screen corruption, X lockups are observable. An example of kernel log of affected system with NV98 card where it was bisected: nouveau 0000:01:00.0: gr: TRAP_M2MF 00000002 [IN] nouveau 0000:01:00.0: gr: TRAP_M2MF 00320951 400007c0 00000000 04000000 nouveau 0000:01:00.0: gr: 00200000 [] ch 1 [000fbbe000 DRM] subc 4 class 5039 mthd 0100 data 00000000 nouveau 0000:01:00.0: fb: trapped read at 0040000000 on channel 1 [0fbbe000 DRM] engine 00 [PGRAPH] client 03 [DISPATCH] subclient 04 [M2M_IN] reason 00000006 [NULL_DMAOBJ] Fixes bug 105173 ("[MCP79][Regression] Unhandled NULL pointer dereference in nvkm_object_unmap since kernel 4.15") https://bugs.freedesktop.org/show_bug.cgi?id=105173 Fixes: 7110c89bb885 ("mmu: swap out round for ALIGN ") Tested-by: Pierre Moreau <pierre.morrow(a)free.fr> Reviewed-by: Pierre Moreau <pierre.morrow(a)free.fr> Signed-off-by: Maris Nartiss <maris.nartiss(a)gmail.com> Signed-off-by: Ben Skeggs <bskeggs(a)redhat.com> Cc: stable(a)vger.kernel.org # v4.15+ Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c @@ -1354,7 +1354,7 @@ nvkm_vmm_get_locked(struct nvkm_vmm *vmm tail = this->addr + this->size; if (vmm->func->page_block && next && next->page != p) - tail = ALIGN_DOWN(addr, vmm->func->page_block); + tail = ALIGN_DOWN(tail, vmm->func->page_block); if (addr <= tail && tail - addr >= size) { rb_erase(&this->tree, &vmm->free); Patches currently in stable-queue which might be from maris.nartiss(a)gmail.com are queue-4.15/drm-nouveau-mmu-align_down-correct-variable.patch

7 years, 1 month

1
0
0 0

Patch "drm/nouveau/bl: Fix oops on driver unbind" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/nouveau/bl: Fix oops on driver unbind to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-nouveau-bl-fix-oops-on-driver-unbind.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 76f2e2bc627f7d08360ac731b6277d744d4eb599 Mon Sep 17 00:00:00 2001 From: Lukas Wunner <lukas(a)wunner.de> Date: Sat, 17 Feb 2018 13:40:23 +0100 Subject: drm/nouveau/bl: Fix oops on driver unbind From: Lukas Wunner <lukas(a)wunner.de> commit 76f2e2bc627f7d08360ac731b6277d744d4eb599 upstream. Unbinding nouveau on a dual GPU MacBook Pro oopses because we iterate over the bl_connectors list in nouveau_backlight_exit() but skipped initializing it in nouveau_backlight_init(). Stacktrace for posterity: BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 IP: nouveau_backlight_exit+0x2b/0x70 [nouveau] nouveau_display_destroy+0x29/0x80 [nouveau] nouveau_drm_unload+0x65/0xe0 [nouveau] drm_dev_unregister+0x3c/0xe0 [drm] drm_put_dev+0x2e/0x60 [drm] nouveau_drm_device_remove+0x47/0x70 [nouveau] pci_device_remove+0x36/0xb0 device_release_driver_internal+0x157/0x220 driver_detach+0x39/0x70 bus_remove_driver+0x51/0xd0 pci_unregister_driver+0x2a/0xa0 nouveau_drm_exit+0x15/0xfb0 [nouveau] SyS_delete_module+0x18c/0x290 system_call_fast_compare_end+0xc/0x6f Fixes: b53ac1ee12a3 ("drm/nouveau/bl: Do not register interface if Apple GMUX detected") Cc: stable(a)vger.kernel.org # v4.10+ Cc: Pierre Moreau <pierre.morrow(a)free.fr> Signed-off-by: Lukas Wunner <lukas(a)wunner.de> Signed-off-by: Ben Skeggs <bskeggs(a)redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/nouveau/nouveau_backlight.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c @@ -268,13 +268,13 @@ nouveau_backlight_init(struct drm_device struct nvif_device *device = &drm->client.device; struct drm_connector *connector; + INIT_LIST_HEAD(&drm->bl_connectors); + if (apple_gmux_present()) { NV_INFO(drm, "Apple GMUX detected: not registering Nouveau backlight interface\n"); return 0; } - INIT_LIST_HEAD(&drm->bl_connectors); - list_for_each_entry(connector, &dev->mode_config.connector_list, head) { if (connector->connector_type != DRM_MODE_CONNECTOR_LVDS && connector->connector_type != DRM_MODE_CONNECTOR_eDP) Patches currently in stable-queue which might be from lukas(a)wunner.de are queue-4.15/drm-nouveau-bl-fix-oops-on-driver-unbind.patch

7 years, 1 month

1
0
0 0

Patch "drm/amdgpu: fix prime teardown order" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/amdgpu: fix prime teardown order to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: drm-amdgpu-fix-prime-teardown-order.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From 342038d92403b3efa1138a8599666b9f026279d6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Christian=20K=C3=B6nig?= <christian.koenig(a)amd.com> Date: Fri, 9 Mar 2018 14:42:54 +0100 Subject: drm/amdgpu: fix prime teardown order MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Christian König <christian.koenig(a)amd.com> commit 342038d92403b3efa1138a8599666b9f026279d6 upstream. We unmapped imported DMA-bufs when the GEM handle was dropped, not when the hardware was done with the buffere. Signed-off-by: Christian König <christian.koenig(a)amd.com> Reviewed-by: Michel Dänzer <michel.daenzer(a)amd.com> CC: stable(a)vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 -- drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 2 ++ 2 files changed, 2 insertions(+), 2 deletions(-) --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c @@ -36,8 +36,6 @@ void amdgpu_gem_object_free(struct drm_g struct amdgpu_bo *robj = gem_to_amdgpu_bo(gobj); if (robj) { - if (robj->gem_base.import_attach) - drm_prime_gem_destroy(&robj->gem_base, robj->tbo.sg); amdgpu_mn_unregister(robj); amdgpu_bo_unref(&robj); } --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c @@ -44,6 +44,8 @@ static void amdgpu_ttm_bo_destroy(struct amdgpu_bo_kunmap(bo); + if (bo->gem_base.import_attach) + drm_prime_gem_destroy(&bo->gem_base, bo->tbo.sg); drm_gem_object_release(&bo->gem_base); amdgpu_bo_unref(&bo->parent); if (!list_empty(&bo->shadow_list)) { Patches currently in stable-queue which might be from christian.koenig(a)amd.com are queue-4.15/drm-amdgpu-fix-prime-teardown-order.patch queue-4.15/drm-radeon-fix-prime-teardown-order.patch

7 years, 1 month

1
0
0 0

Patch "ALSA: seq: Fix possible UAF in snd_seq_check_queue()" has been added to the 4.15-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: seq: Fix possible UAF in snd_seq_check_queue() to the 4.15-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: alsa-seq-fix-possible-uaf-in-snd_seq_check_queue.patch and it can be found in the queue-4.15 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From d0f833065221cbfcbadf19fd4102bcfa9330006a Mon Sep 17 00:00:00 2001 From: Takashi Iwai <tiwai(a)suse.de> Date: Fri, 9 Mar 2018 21:58:28 +0100 Subject: ALSA: seq: Fix possible UAF in snd_seq_check_queue() From: Takashi Iwai <tiwai(a)suse.de> commit d0f833065221cbfcbadf19fd4102bcfa9330006a upstream. Although we've covered the races between concurrent write() and ioctl() in the previous patch series, there is still a possible UAF in the following scenario: A: user client closed B: timer irq -> snd_seq_release() -> snd_seq_timer_interrupt() -> snd_seq_free_client() -> snd_seq_check_queue() -> cell = snd_seq_prioq_cell_peek() -> snd_seq_prioq_leave() .... removing all cells -> snd_seq_pool_done() .... vfree() -> snd_seq_compare_tick_time(cell) ... Oops So the problem is that a cell is peeked and accessed without any protection until it's retrieved from the queue again via snd_seq_prioq_cell_out(). This patch tries to address it, also cleans up the code by a slight refactoring. snd_seq_prioq_cell_out() now receives an extra pointer argument. When it's non-NULL, the function checks the event timestamp with the given pointer. The caller needs to pass the right reference either to snd_seq_tick or snd_seq_realtime depending on the event timestamp type. A good news is that the above change allows us to remove the snd_seq_prioq_cell_peek(), too, thus the patch actually reduces the code size. Reviewed-by: Nicolai Stange <nstange(a)suse.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/core/seq/seq_prioq.c | 28 ++++++++++++++-------------- sound/core/seq/seq_prioq.h | 6 ++---- sound/core/seq/seq_queue.c | 28 +++++++++------------------- 3 files changed, 25 insertions(+), 37 deletions(-) --- a/sound/core/seq/seq_prioq.c +++ b/sound/core/seq/seq_prioq.c @@ -87,7 +87,7 @@ void snd_seq_prioq_delete(struct snd_seq if (f->cells > 0) { /* drain prioQ */ while (f->cells > 0) - snd_seq_cell_free(snd_seq_prioq_cell_out(f)); + snd_seq_cell_free(snd_seq_prioq_cell_out(f, NULL)); } kfree(f); @@ -214,8 +214,18 @@ int snd_seq_prioq_cell_in(struct snd_seq return 0; } +/* return 1 if the current time >= event timestamp */ +static int event_is_ready(struct snd_seq_event *ev, void *current_time) +{ + if ((ev->flags & SNDRV_SEQ_TIME_STAMP_MASK) == SNDRV_SEQ_TIME_STAMP_TICK) + return snd_seq_compare_tick_time(current_time, &ev->time.tick); + else + return snd_seq_compare_real_time(current_time, &ev->time.time); +} + /* dequeue cell from prioq */ -struct snd_seq_event_cell *snd_seq_prioq_cell_out(struct snd_seq_prioq *f) +struct snd_seq_event_cell *snd_seq_prioq_cell_out(struct snd_seq_prioq *f, + void *current_time) { struct snd_seq_event_cell *cell; unsigned long flags; @@ -227,6 +237,8 @@ struct snd_seq_event_cell *snd_seq_prioq spin_lock_irqsave(&f->lock, flags); cell = f->head; + if (cell && current_time && !event_is_ready(&cell->event, current_time)) + cell = NULL; if (cell) { f->head = cell->next; @@ -252,18 +264,6 @@ int snd_seq_prioq_avail(struct snd_seq_p return f->cells; } - -/* peek at cell at the head of the prioq */ -struct snd_seq_event_cell *snd_seq_prioq_cell_peek(struct snd_seq_prioq * f) -{ - if (f == NULL) { - pr_debug("ALSA: seq: snd_seq_prioq_cell_in() called with NULL prioq\n"); - return NULL; - } - return f->head; -} - - static inline int prioq_match(struct snd_seq_event_cell *cell, int client, int timestamp) { --- a/sound/core/seq/seq_prioq.h +++ b/sound/core/seq/seq_prioq.h @@ -44,14 +44,12 @@ void snd_seq_prioq_delete(struct snd_seq int snd_seq_prioq_cell_in(struct snd_seq_prioq *f, struct snd_seq_event_cell *cell); /* dequeue cell from prioq */ -struct snd_seq_event_cell *snd_seq_prioq_cell_out(struct snd_seq_prioq *f); +struct snd_seq_event_cell *snd_seq_prioq_cell_out(struct snd_seq_prioq *f, + void *current_time); /* return number of events available in prioq */ int snd_seq_prioq_avail(struct snd_seq_prioq *f); -/* peek at cell at the head of the prioq */ -struct snd_seq_event_cell *snd_seq_prioq_cell_peek(struct snd_seq_prioq *f); - /* client left queue */ void snd_seq_prioq_leave(struct snd_seq_prioq *f, int client, int timestamp); --- a/sound/core/seq/seq_queue.c +++ b/sound/core/seq/seq_queue.c @@ -277,30 +277,20 @@ void snd_seq_check_queue(struct snd_seq_ __again: /* Process tick queue... */ - while ((cell = snd_seq_prioq_cell_peek(q->tickq)) != NULL) { - if (snd_seq_compare_tick_time(&q->timer->tick.cur_tick, - &cell->event.time.tick)) { - cell = snd_seq_prioq_cell_out(q->tickq); - if (cell) - snd_seq_dispatch_event(cell, atomic, hop); - } else { - /* event remains in the queue */ + for (;;) { + cell = snd_seq_prioq_cell_out(q->tickq, + &q->timer->tick.cur_tick); + if (!cell) break; - } + snd_seq_dispatch_event(cell, atomic, hop); } - /* Process time queue... */ - while ((cell = snd_seq_prioq_cell_peek(q->timeq)) != NULL) { - if (snd_seq_compare_real_time(&q->timer->cur_time, - &cell->event.time.time)) { - cell = snd_seq_prioq_cell_out(q->timeq); - if (cell) - snd_seq_dispatch_event(cell, atomic, hop); - } else { - /* event remains in the queue */ + for (;;) { + cell = snd_seq_prioq_cell_out(q->timeq, &q->timer->cur_time); + if (!cell) break; - } + snd_seq_dispatch_event(cell, atomic, hop); } /* free lock */ Patches currently in stable-queue which might be from tiwai(a)suse.de are queue-4.15/alsa-pcm-fix-uaf-in-snd_pcm_oss_get_formats.patch queue-4.15/alsa-seq-fix-possible-uaf-in-snd_seq_check_queue.patch queue-4.15/alsa-hda-revert-power_save-option-default-value.patch queue-4.15/alsa-seq-clear-client-entry-before-deleting-else-at-closing.patch

7 years, 1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror