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

[PATCH 4.14 1/4] powerpc/mm/slice: Remove intermediate bitmap copy

by Christophe Leroy

[ Upstream commit 326691ad4f179e6edc7eb1271e618dd673e4736d ] bitmap_or() and bitmap_andnot() can work properly with dst identical to src1 or src2. There is no need of an intermediate result bitmap that is copied back to dst in a second step. Signed-off-by: Christophe Leroy <christophe.leroy(a)c-s.fr> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar(a)linux.vnet.ibm.com> Reviewed-by: Nicholas Piggin <npiggin(a)gmail.com> Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au> --- arch/powerpc/mm/slice.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/arch/powerpc/mm/slice.c b/arch/powerpc/mm/slice.c index a4f93699194b..b79897bb89e3 100644 --- a/arch/powerpc/mm/slice.c +++ b/arch/powerpc/mm/slice.c @@ -379,21 +379,17 @@ static unsigned long slice_find_area(struct mm_struct *mm, unsigned long len, static inline void slice_or_mask(struct slice_mask *dst, struct slice_mask *src) { - DECLARE_BITMAP(result, SLICE_NUM_HIGH); - dst->low_slices |= src->low_slices; - bitmap_or(result, dst->high_slices, src->high_slices, SLICE_NUM_HIGH); - bitmap_copy(dst->high_slices, result, SLICE_NUM_HIGH); + bitmap_or(dst->high_slices, dst->high_slices, src->high_slices, + SLICE_NUM_HIGH); } static inline void slice_andnot_mask(struct slice_mask *dst, struct slice_mask *src) { - DECLARE_BITMAP(result, SLICE_NUM_HIGH); - dst->low_slices &= ~src->low_slices; - bitmap_andnot(result, dst->high_slices, src->high_slices, SLICE_NUM_HIGH); - bitmap_copy(dst->high_slices, result, SLICE_NUM_HIGH); + bitmap_andnot(dst->high_slices, dst->high_slices, src->high_slices, + SLICE_NUM_HIGH); } #ifdef CONFIG_PPC_64K_PAGES -- 2.13.3

7 years, 2 months

2
7
0 0

More gcc related patches for stable releases

by Guenter Roeck

Hi Greg, The following patches are needed in various stable releases to build sparc/sparc64 images with gcc 7.3.0. v4.4: 56962f8b250a Kbuild: change CC_OPTIMIZE_FOR_SIZE definition v4.9 and earlier: 0fde7ad71ee3 sparc64: Fix build warnings with gcc 7. v4.9: 009615ab7fd4 USB: serial: cp210x: use tcflag_t to fix incompatible pointer type Thanks, Guenter

7 years, 2 months

3
3
0 0

FAILED: patch "[PATCH] drm/amd/display: Make atomic-check validate underscan changes" failed to apply to 4.16-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.16-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From a9e8d27574f26700575473011cb607d4abdbda5f Mon Sep 17 00:00:00 2001 From: David Francis <David.Francis(a)amd.com> Date: Thu, 31 May 2018 13:48:31 -0400 Subject: [PATCH] drm/amd/display: Make atomic-check validate underscan changes When the underscan state was changed, atomic-check was triggering a validation but passing the old underscan values. This change adds a somewhat hacky check in dm_update_crtcs_state that will update the stream if old and newunderscan values are different. This was causing 4k on Fiji to allow underscan when it wasn't permitted. Signed-off-by: David Francis <David.Francis(a)amd.com> Reviewed-by: David Francis <David.Francis(a)amd.com> Acked-by: Harry Wentland <harry.wentland(a)amd.com> Cc: stable(a)vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index ad1ad333012a..1a7e96ee6051 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -4555,8 +4555,8 @@ static int dm_update_crtcs_state(struct dc *dc, for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, new_crtc_state, i) { struct amdgpu_crtc *acrtc = NULL; struct amdgpu_dm_connector *aconnector = NULL; - struct drm_connector_state *new_con_state = NULL; - struct dm_connector_state *dm_conn_state = NULL; + struct drm_connector_state *drm_new_conn_state = NULL, *drm_old_conn_state = NULL; + struct dm_connector_state *dm_new_conn_state = NULL, *dm_old_conn_state = NULL; struct drm_plane_state *new_plane_state = NULL; new_stream = NULL; @@ -4577,19 +4577,23 @@ static int dm_update_crtcs_state(struct dc *dc, /* TODO This hack should go away */ if (aconnector && enable) { // Make sure fake sink is created in plug-in scenario - new_con_state = drm_atomic_get_connector_state(state, + drm_new_conn_state = drm_atomic_get_new_connector_state(state, &aconnector->base); + drm_old_conn_state = drm_atomic_get_old_connector_state(state, + &aconnector->base); - if (IS_ERR(new_con_state)) { - ret = PTR_ERR_OR_ZERO(new_con_state); + + if (IS_ERR(drm_new_conn_state)) { + ret = PTR_ERR_OR_ZERO(drm_new_conn_state); break; } - dm_conn_state = to_dm_connector_state(new_con_state); + dm_new_conn_state = to_dm_connector_state(drm_new_conn_state); + dm_old_conn_state = to_dm_connector_state(drm_old_conn_state); new_stream = create_stream_for_sink(aconnector, &new_crtc_state->mode, - dm_conn_state); + dm_new_conn_state); /* * we can have no stream on ACTION_SET if a display @@ -4708,6 +4712,11 @@ static int dm_update_crtcs_state(struct dc *dc, */ BUG_ON(dm_new_crtc_state->stream == NULL); + /* Scaling or underscan settings */ + if (is_scaling_state_different(dm_old_conn_state, dm_new_conn_state)) + update_stream_scaling_settings( + &new_crtc_state->mode, dm_new_conn_state, dm_new_crtc_state->stream); + /* Color managment settings */ if (dm_new_crtc_state->base.color_mgmt_changed) { ret = amdgpu_dm_set_regamma_lut(dm_new_crtc_state);

7 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] drm/amd/display: Update color props when modeset is required" failed to apply to 4.16-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.16-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From bc13f2f88eae63af943ab967cb14bb602f8f2eeb Mon Sep 17 00:00:00 2001 From: "Leo (Sunpeng) Li" <sunpeng.li(a)amd.com> Date: Thu, 31 May 2018 10:23:37 -0400 Subject: [PATCH] drm/amd/display: Update color props when modeset is required This fixes issues where color management properties don't persist over DPMS on/off, or when the CRTC is moved across connectors. Signed-off-by: Leo (Sunpeng) Li <sunpeng.li(a)amd.com> Reviewed-by: Harry Wentland <Harry.Wentland(a)amd.com> Cc: stable(a)vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 1a7e96ee6051..27579443cdc5 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -4717,8 +4717,12 @@ static int dm_update_crtcs_state(struct dc *dc, update_stream_scaling_settings( &new_crtc_state->mode, dm_new_conn_state, dm_new_crtc_state->stream); - /* Color managment settings */ - if (dm_new_crtc_state->base.color_mgmt_changed) { + /* + * Color management settings. We also update color properties + * when a modeset is needed, to ensure it gets reprogrammed. + */ + if (dm_new_crtc_state->base.color_mgmt_changed || + drm_atomic_crtc_needs_modeset(new_crtc_state)) { ret = amdgpu_dm_set_regamma_lut(dm_new_crtc_state); if (ret) goto fail;

7 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] drm/i915/lvds: Move acpi lid notification registration to" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From b9eb9c92899a509fe258d38dd6c214b1de69eee0 Mon Sep 17 00:00:00 2001 From: Chris Wilson <chris(a)chris-wilson.co.uk> Date: Fri, 18 May 2018 08:48:40 +0100 Subject: [PATCH] drm/i915/lvds: Move acpi lid notification registration to registration phase MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Delay registering ourselves with the acpi lid notification mechanism until we are registering the connectors after initialisation is complete. This prevents a possibility of trying to handle the lid notification before we are ready with the danger of chasing uninitialised function pointers. BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 IP: (null) PGD 0 P4D 0 Oops: 0010 [#1] PREEMPT SMP PTI Modules linked in: arc4(+) iwldvm(+) i915(+) mac80211 i2c_algo_bit coretemp mei_wdt iwlwifi drm_kms_helper kvm_intel wmi_bmof iTCO_wdt iTCO_vendor_support kvm snd_hda_codec_conexant snd_hda_codec_generic drm psmouse cfg80211 irqbypass input_leds pcspkr i2c_i801 snd_hda_intel snd_hda_codec thinkpad_acpi snd_hda_core mei_me lpc_ich snd_hwdep e1000e wmi nvram snd_pcm mei snd_timer shpchp ptp pps_core rfkill syscopyarea snd intel_agp sysfillrect intel_gtt soundcore sysimgblt battery led_class fb_sys_fops ac rtc_cmos agpgart evdev mac_hid acpi_cpufreq ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 fscrypto crypto_simd glue_helper cryptd aes_x86_64 xts algif_skcipher af_alg dm_crypt dm_mod sd_mod uas usb_storage serio_raw atkbd libps2 ahci libahci uhci_hcd libata scsi_mod ehci_pci ehci_hcd usbcore usb_common i8042 serio CPU: 1 PID: 378 Comm: systemd-logind Not tainted 4.16.8-1-ARCH #1 Hardware name: LENOVO 7454CTO/7454CTO, BIOS 6DET72WW (3.22 ) 10/25/2012 RIP: 0010: (null) RSP: 0018:ffffaf4580c33a18 EFLAGS: 00010287 RAX: 0000000000000000 RBX: ffff947533558000 RCX: 000000000000003e RDX: ffffffffc0aa80c0 RSI: ffffaf4580c33a3c RDI: ffff947534e4c000 RBP: ffff947533558338 R08: ffff947534598930 R09: ffffffffc0a928b1 R10: ffffd8f181d5fd40 R11: 0000000000000000 R12: ffffffffc0a928b1 R13: ffff947533558368 R14: ffffffffc0a928a9 R15: ffff947534e4c000 FS: 00007f3dc4ddb940(0000) GS:ffff947539280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000006e214000 CR4: 00000000000406e0 Call Trace: ? intel_modeset_setup_hw_state+0x385/0xf60 [i915] ? __intel_display_resume+0x1e/0xc0 [i915] ? intel_display_resume+0xcc/0x120 [i915] ? intel_lid_notify+0xbc/0xc0 [i915] ? notifier_call_chain+0x47/0x70 ? blocking_notifier_call_chain+0x3e/0x60 ? acpi_lid_notify_state+0x8f/0x1d0 ? acpi_lid_update_state+0x49/0x70 ? acpi_lid_input_open+0x60/0x90 ? input_open_device+0x5d/0xa0 ? evdev_open+0x1ba/0x1e0 [evdev] ? chrdev_open+0xa3/0x1b0 ? cdev_put.part.0+0x20/0x20 ? do_dentry_open+0x14c/0x300 ? path_openat+0x30c/0x1240 ? current_time+0x16/0x60 ? do_filp_open+0x93/0x100 ? __check_object_size+0xfb/0x180 ? do_sys_open+0x186/0x210 ? do_syscall_64+0x74/0x190 ? entry_SYSCALL_64_after_hwframe+0x3d/0xa2 Code: Bad RIP value. RIP: (null) RSP: ffffaf4580c33a18 CR2: 0000000000000000 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106559 Fixes: c1c7af608920 ("drm/i915: force mode set at lid open time") Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Reviewed-by: Jani Nikula <jani.nikula(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180518074840.16194-1-chris@… Cc: stable(a)vger.kernel.org (cherry picked from commit e578a570dc7c20475774d1ff993825e3bd7a7011) Signed-off-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c index d0d9988bb661..e125d16a1aa7 100644 --- a/drivers/gpu/drm/i915/intel_lvds.c +++ b/drivers/gpu/drm/i915/intel_lvds.c @@ -574,6 +574,36 @@ static int intel_lid_notify(struct notifier_block *nb, unsigned long val, return NOTIFY_OK; } +static int +intel_lvds_connector_register(struct drm_connector *connector) +{ + struct intel_lvds_connector *lvds = to_lvds_connector(connector); + int ret; + + ret = intel_connector_register(connector); + if (ret) + return ret; + + lvds->lid_notifier.notifier_call = intel_lid_notify; + if (acpi_lid_notifier_register(&lvds->lid_notifier)) { + DRM_DEBUG_KMS("lid notifier registration failed\n"); + lvds->lid_notifier.notifier_call = NULL; + } + + return 0; +} + +static void +intel_lvds_connector_unregister(struct drm_connector *connector) +{ + struct intel_lvds_connector *lvds = to_lvds_connector(connector); + + if (lvds->lid_notifier.notifier_call) + acpi_lid_notifier_unregister(&lvds->lid_notifier); + + intel_connector_unregister(connector); +} + /** * intel_lvds_destroy - unregister and free LVDS structures * @connector: connector to free @@ -586,9 +616,6 @@ static void intel_lvds_destroy(struct drm_connector *connector) struct intel_lvds_connector *lvds_connector = to_lvds_connector(connector); - if (lvds_connector->lid_notifier.notifier_call) - acpi_lid_notifier_unregister(&lvds_connector->lid_notifier); - if (!IS_ERR_OR_NULL(lvds_connector->base.edid)) kfree(lvds_connector->base.edid); @@ -609,8 +636,8 @@ static const struct drm_connector_funcs intel_lvds_connector_funcs = { .fill_modes = drm_helper_probe_single_connector_modes, .atomic_get_property = intel_digital_connector_atomic_get_property, .atomic_set_property = intel_digital_connector_atomic_set_property, - .late_register = intel_connector_register, - .early_unregister = intel_connector_unregister, + .late_register = intel_lvds_connector_register, + .early_unregister = intel_lvds_connector_unregister, .destroy = intel_lvds_destroy, .atomic_destroy_state = drm_atomic_helper_connector_destroy_state, .atomic_duplicate_state = intel_digital_connector_duplicate_state, @@ -1158,12 +1185,6 @@ void intel_lvds_init(struct drm_i915_private *dev_priv) lvds_encoder->a3_power = lvds & LVDS_A3_POWER_MASK; - lvds_connector->lid_notifier.notifier_call = intel_lid_notify; - if (acpi_lid_notifier_register(&lvds_connector->lid_notifier)) { - DRM_DEBUG_KMS("lid notifier registration failed\n"); - lvds_connector->lid_notifier.notifier_call = NULL; - } - return; failed:

7 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] drm/i915/lvds: Move acpi lid notification registration to" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From b9eb9c92899a509fe258d38dd6c214b1de69eee0 Mon Sep 17 00:00:00 2001 From: Chris Wilson <chris(a)chris-wilson.co.uk> Date: Fri, 18 May 2018 08:48:40 +0100 Subject: [PATCH] drm/i915/lvds: Move acpi lid notification registration to registration phase MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Delay registering ourselves with the acpi lid notification mechanism until we are registering the connectors after initialisation is complete. This prevents a possibility of trying to handle the lid notification before we are ready with the danger of chasing uninitialised function pointers. BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 IP: (null) PGD 0 P4D 0 Oops: 0010 [#1] PREEMPT SMP PTI Modules linked in: arc4(+) iwldvm(+) i915(+) mac80211 i2c_algo_bit coretemp mei_wdt iwlwifi drm_kms_helper kvm_intel wmi_bmof iTCO_wdt iTCO_vendor_support kvm snd_hda_codec_conexant snd_hda_codec_generic drm psmouse cfg80211 irqbypass input_leds pcspkr i2c_i801 snd_hda_intel snd_hda_codec thinkpad_acpi snd_hda_core mei_me lpc_ich snd_hwdep e1000e wmi nvram snd_pcm mei snd_timer shpchp ptp pps_core rfkill syscopyarea snd intel_agp sysfillrect intel_gtt soundcore sysimgblt battery led_class fb_sys_fops ac rtc_cmos agpgart evdev mac_hid acpi_cpufreq ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 fscrypto crypto_simd glue_helper cryptd aes_x86_64 xts algif_skcipher af_alg dm_crypt dm_mod sd_mod uas usb_storage serio_raw atkbd libps2 ahci libahci uhci_hcd libata scsi_mod ehci_pci ehci_hcd usbcore usb_common i8042 serio CPU: 1 PID: 378 Comm: systemd-logind Not tainted 4.16.8-1-ARCH #1 Hardware name: LENOVO 7454CTO/7454CTO, BIOS 6DET72WW (3.22 ) 10/25/2012 RIP: 0010: (null) RSP: 0018:ffffaf4580c33a18 EFLAGS: 00010287 RAX: 0000000000000000 RBX: ffff947533558000 RCX: 000000000000003e RDX: ffffffffc0aa80c0 RSI: ffffaf4580c33a3c RDI: ffff947534e4c000 RBP: ffff947533558338 R08: ffff947534598930 R09: ffffffffc0a928b1 R10: ffffd8f181d5fd40 R11: 0000000000000000 R12: ffffffffc0a928b1 R13: ffff947533558368 R14: ffffffffc0a928a9 R15: ffff947534e4c000 FS: 00007f3dc4ddb940(0000) GS:ffff947539280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000006e214000 CR4: 00000000000406e0 Call Trace: ? intel_modeset_setup_hw_state+0x385/0xf60 [i915] ? __intel_display_resume+0x1e/0xc0 [i915] ? intel_display_resume+0xcc/0x120 [i915] ? intel_lid_notify+0xbc/0xc0 [i915] ? notifier_call_chain+0x47/0x70 ? blocking_notifier_call_chain+0x3e/0x60 ? acpi_lid_notify_state+0x8f/0x1d0 ? acpi_lid_update_state+0x49/0x70 ? acpi_lid_input_open+0x60/0x90 ? input_open_device+0x5d/0xa0 ? evdev_open+0x1ba/0x1e0 [evdev] ? chrdev_open+0xa3/0x1b0 ? cdev_put.part.0+0x20/0x20 ? do_dentry_open+0x14c/0x300 ? path_openat+0x30c/0x1240 ? current_time+0x16/0x60 ? do_filp_open+0x93/0x100 ? __check_object_size+0xfb/0x180 ? do_sys_open+0x186/0x210 ? do_syscall_64+0x74/0x190 ? entry_SYSCALL_64_after_hwframe+0x3d/0xa2 Code: Bad RIP value. RIP: (null) RSP: ffffaf4580c33a18 CR2: 0000000000000000 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106559 Fixes: c1c7af608920 ("drm/i915: force mode set at lid open time") Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Reviewed-by: Jani Nikula <jani.nikula(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180518074840.16194-1-chris@… Cc: stable(a)vger.kernel.org (cherry picked from commit e578a570dc7c20475774d1ff993825e3bd7a7011) Signed-off-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c index d0d9988bb661..e125d16a1aa7 100644 --- a/drivers/gpu/drm/i915/intel_lvds.c +++ b/drivers/gpu/drm/i915/intel_lvds.c @@ -574,6 +574,36 @@ static int intel_lid_notify(struct notifier_block *nb, unsigned long val, return NOTIFY_OK; } +static int +intel_lvds_connector_register(struct drm_connector *connector) +{ + struct intel_lvds_connector *lvds = to_lvds_connector(connector); + int ret; + + ret = intel_connector_register(connector); + if (ret) + return ret; + + lvds->lid_notifier.notifier_call = intel_lid_notify; + if (acpi_lid_notifier_register(&lvds->lid_notifier)) { + DRM_DEBUG_KMS("lid notifier registration failed\n"); + lvds->lid_notifier.notifier_call = NULL; + } + + return 0; +} + +static void +intel_lvds_connector_unregister(struct drm_connector *connector) +{ + struct intel_lvds_connector *lvds = to_lvds_connector(connector); + + if (lvds->lid_notifier.notifier_call) + acpi_lid_notifier_unregister(&lvds->lid_notifier); + + intel_connector_unregister(connector); +} + /** * intel_lvds_destroy - unregister and free LVDS structures * @connector: connector to free @@ -586,9 +616,6 @@ static void intel_lvds_destroy(struct drm_connector *connector) struct intel_lvds_connector *lvds_connector = to_lvds_connector(connector); - if (lvds_connector->lid_notifier.notifier_call) - acpi_lid_notifier_unregister(&lvds_connector->lid_notifier); - if (!IS_ERR_OR_NULL(lvds_connector->base.edid)) kfree(lvds_connector->base.edid); @@ -609,8 +636,8 @@ static const struct drm_connector_funcs intel_lvds_connector_funcs = { .fill_modes = drm_helper_probe_single_connector_modes, .atomic_get_property = intel_digital_connector_atomic_get_property, .atomic_set_property = intel_digital_connector_atomic_set_property, - .late_register = intel_connector_register, - .early_unregister = intel_connector_unregister, + .late_register = intel_lvds_connector_register, + .early_unregister = intel_lvds_connector_unregister, .destroy = intel_lvds_destroy, .atomic_destroy_state = drm_atomic_helper_connector_destroy_state, .atomic_duplicate_state = intel_digital_connector_duplicate_state, @@ -1158,12 +1185,6 @@ void intel_lvds_init(struct drm_i915_private *dev_priv) lvds_encoder->a3_power = lvds & LVDS_A3_POWER_MASK; - lvds_connector->lid_notifier.notifier_call = intel_lid_notify; - if (acpi_lid_notifier_register(&lvds_connector->lid_notifier)) { - DRM_DEBUG_KMS("lid notifier registration failed\n"); - lvds_connector->lid_notifier.notifier_call = NULL; - } - return; failed:

7 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] IB/core: Fix error code for invalid GID entry" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From a840c93ca7582bb6c88df2345a33f979b7a67874 Mon Sep 17 00:00:00 2001 From: Parav Pandit <parav(a)mellanox.com> Date: Sun, 27 May 2018 14:49:16 +0300 Subject: [PATCH] IB/core: Fix error code for invalid GID entry When a GID entry is invalid EAGAIN is returned. This is an incorrect error code, there is nothing that will make this GID entry valid again in bounded time. Some user space tools fail incorrectly if EAGAIN is returned here, and this represents a small ABI change from earlier kernels. The first patch in the Fixes list makes entries that were valid before to become invalid, allowing this code to trigger, while the second patch in the Fixes list introduced the wrong EAGAIN. Therefore revert the return result to EINVAL which matches the historical expectations of the ibv_query_gid_type() API of the libibverbs user space library. Cc: <stable(a)vger.kernel.org> Fixes: 598ff6bae689 ("IB/core: Refactor GID modify code for RoCE") Fixes: 03db3a2d81e6 ("IB/core: Add RoCE GID table management") Reviewed-by: Daniel Jurgens <danielj(a)mellanox.com> Signed-off-by: Parav Pandit <parav(a)mellanox.com> Signed-off-by: Leon Romanovsky <leonro(a)mellanox.com> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> diff --git a/drivers/infiniband/core/cache.c b/drivers/infiniband/core/cache.c index fb2d347f760f..ecc55e98ddd3 100644 --- a/drivers/infiniband/core/cache.c +++ b/drivers/infiniband/core/cache.c @@ -502,7 +502,7 @@ static int __ib_cache_gid_get(struct ib_device *ib_dev, u8 port, int index, return -EINVAL; if (table->data_vec[index].props & GID_TABLE_ENTRY_INVALID) - return -EAGAIN; + return -EINVAL; memcpy(gid, &table->data_vec[index].gid, sizeof(*gid)); if (attr) {

7 years, 2 months

1
0
0 0

[PATCH] softirq: reorder trace_softirqs_on to prevent lockdep splat

by Joel Fernandes

I'm able to reproduce a lockdep splat with config options: CONFIG_PROVE_LOCKING=y, CONFIG_DEBUG_LOCK_ALLOC=y and CONFIG_PREEMPTIRQ_EVENTS=y $ echo 1 > /d/tracing/events/preemptirq/preempt_enable/enable --- [ 26.112609] DEBUG_LOCKS_WARN_ON(current->softirqs_enabled) [ 26.112636] WARNING: CPU: 0 PID: 118 at kernel/locking/lockdep.c:3854 [...] [ 26.144229] Call Trace: [ 26.144926] <IRQ> [ 26.145506] lock_acquire+0x55/0x1b0 [ 26.146499] ? __do_softirq+0x46f/0x4d9 [ 26.147571] ? __do_softirq+0x46f/0x4d9 [ 26.148646] trace_preempt_on+0x8f/0x240 [ 26.149744] ? trace_preempt_on+0x4d/0x240 [ 26.150862] ? __do_softirq+0x46f/0x4d9 [ 26.151930] preempt_count_sub+0x18a/0x1a0 [ 26.152985] __do_softirq+0x46f/0x4d9 [ 26.153937] irq_exit+0x68/0xe0 [ 26.154755] smp_apic_timer_interrupt+0x271/0x280 [ 26.156056] apic_timer_interrupt+0xf/0x20 [ 26.157105] </IRQ> The issue was this: preempt_count = 1 << SOFTIRQ_SHIFT __local_bh_enable(cnt = 1 << SOFTIRQ_SHIFT) { if (softirq_count() == (cnt && SOFTIRQ_MASK)) { trace_softirqs_on() { current->softirqs_enabled = 1; } } preempt_count_sub(cnt) { trace_preempt_on() { tracepoint() { rcu_read_lock_sched() { // jumps into lockdep Where preempt_count still has softirqs disabled, but current->softirqs_enabled is true, and we get a splat. Cc: Steven Rostedt <rostedt(a)goodmis.org> Cc: Peter Zilstra <peterz(a)infradead.org> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> Cc: Tom Zanussi <tom.zanussi(a)linux.intel.com> Cc: Namhyung Kim <namhyung(a)kernel.org> Cc: Thomas Glexiner <tglx(a)linutronix.de> Cc: Boqun Feng <boqun.feng(a)gmail.com> Cc: Paul McKenney <paulmck(a)linux.vnet.ibm.com> Cc: Frederic Weisbecker <fweisbec(a)gmail.com> Cc: Randy Dunlap <rdunlap(a)infradead.org> Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Fenguang Wu <fengguang.wu(a)intel.com> Cc: Baohong Liu <baohong.liu(a)intel.com> Cc: Vedang Patel <vedang.patel(a)intel.com> Cc: kernel-team(a)android.com Cc: stable(a)vger.kernel.org Reviewed-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> Fixes: d59158162e032 ("tracing: Add support for preempt and irq enable/disable events") Signed-off-by: Joel Fernandes <joelaf(a)google.com> --- kernel/softirq.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/kernel/softirq.c b/kernel/softirq.c index 24d243ef8e71..47e2f61938c0 100644 --- a/kernel/softirq.c +++ b/kernel/softirq.c @@ -139,9 +139,13 @@ static void __local_bh_enable(unsigned int cnt) { lockdep_assert_irqs_disabled(); + if (preempt_count() == cnt) + trace_preempt_on(CALLER_ADDR0, get_lock_parent_ip()); + if (softirq_count() == (cnt & SOFTIRQ_MASK)) trace_softirqs_on(_RET_IP_); - preempt_count_sub(cnt); + + __preempt_count_sub(cnt); } /* -- 2.17.0.441.gb46fe60e1d-goog

7 years, 2 months

3
3
0 0

[PATCH v3] net/mlx4_en: fix potential use-after-free with dma_unmap_page

by Sarah Newman

[ Not relevant upstream, therefore no upstream commit. ] To fix, unmap the page as soon as possible. When swiotlb is in use, calling dma_unmap_page means that the original page mapped with dma_map_page must still be valid, as swiotlb will copy data from its internal cache back to the originally requested DMA location. When GRO is enabled, before this patch all references to the original frag may be put and the page freed before dma_unmap_page in mlx4_en_free_frag is called. It is possible there is a path where the use-after-free occurs even with GRO disabled, but this has not been observed so far. The bug can be trivially detected by doing the following: * Compile the kernel with DEBUG_PAGEALLOC * Run the kernel as a Xen Dom0 * Leave GRO enabled on the interface * Run a 10 second or more test with iperf over the interface. This bug was likely introduced in commit 4cce66cdd14a ("mlx4_en: map entire pages to increase throughput"), first part of u3.6. It was incidentally fixed in commit 34db548bfb95 ("mlx4: add page recycling in receive path"), first part of v4.12. This version applies to the v4.9 series. Signed-off-by: Sarah Newman <srn(a)prgmr.com> Tested-by: Sarah Newman <srn(a)prgmr.com> --- drivers/net/ethernet/mellanox/mlx4/en_rx.c | 32 +++++++++++++++++++----------- 1 file changed, 20 insertions(+), 12 deletions(-) diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c index 844f5ad..abe2b43 100644 --- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c +++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c @@ -142,16 +142,17 @@ static void mlx4_en_free_frag(struct mlx4_en_priv *priv, struct mlx4_en_rx_alloc *frags, int i) { - const struct mlx4_en_frag_info *frag_info = &priv->frag_info[i]; - u32 next_frag_end = frags[i].page_offset + 2 * frag_info->frag_stride; - - - if (next_frag_end > frags[i].page_size) - dma_unmap_page(priv->ddev, frags[i].dma, frags[i].page_size, - frag_info->dma_dir); + if (frags[i].page) { + const struct mlx4_en_frag_info *frag_info = &priv->frag_info[i]; + u32 next_frag_end = frags[i].page_offset + + 2 * frag_info->frag_stride; - if (frags[i].page) + if (next_frag_end > frags[i].page_size) { + dma_unmap_page(priv->ddev, frags[i].dma, + frags[i].page_size, frag_info->dma_dir); + } put_page(frags[i].page); + } } static int mlx4_en_init_allocator(struct mlx4_en_priv *priv, @@ -586,21 +587,28 @@ static int mlx4_en_complete_rx_desc(struct mlx4_en_priv *priv, int length) { struct skb_frag_struct *skb_frags_rx = skb_shinfo(skb)->frags; - struct mlx4_en_frag_info *frag_info; int nr; dma_addr_t dma; /* Collect used fragments while replacing them in the HW descriptors */ for (nr = 0; nr < priv->num_frags; nr++) { - frag_info = &priv->frag_info[nr]; + struct mlx4_en_frag_info *frag_info = &priv->frag_info[nr]; + u32 next_frag_end = frags[nr].page_offset + + 2 * frag_info->frag_stride; + if (length <= frag_info->frag_prefix_size) break; if (unlikely(!frags[nr].page)) goto fail; dma = be64_to_cpu(rx_desc->data[nr].addr); - dma_sync_single_for_cpu(priv->ddev, dma, frag_info->frag_size, - DMA_FROM_DEVICE); + if (next_frag_end > frags[nr].page_size) + dma_unmap_page(priv->ddev, frags[nr].dma, + frags[nr].page_size, frag_info->dma_dir); + else + dma_sync_single_for_cpu(priv->ddev, dma, + frag_info->frag_size, + DMA_FROM_DEVICE); /* Save page reference in skb */ __skb_frag_set_page(&skb_frags_rx[nr], frags[nr].page); -- 1.9.1

7 years, 2 months

2
3
0 0

[PATCH 0/3] scsi:ufs: Fix failure to read the string descriptor.

by Li Wei

This patch fix failure to read the string descriptor. In kernel v4.9.100,we encountered the following error info: [3.141326] ufshcd-hi3660 ff3b0000.ufs: ufshcd_read_desc_param: Failed reading descriptor. desc_id 0 param_offset 0 buff_len 31 ret 0 [3.141331] ufshcd-hi3660 ff3b0000.ufs: ufs_get_device_info: Failed reading Device Desc. err = -22 [3.141336] ufshcd-hi3660 ff3b0000.ufs: ufs_advertise_fixup_device: Failed getting device info. err = -22 [3.145923] ufs final power mode: gear = 3, lane = 2, pwr = 1, rate = 2 [3.145927] ufshcd-hi3660 ff3b0000.ufs: set TX_EQUALIZER 3.5db [3.157229] ufshcd-hi3660 ff3b0000.ufs: check TX_EQUALIZER DB value lane0 = 0x1 [3.157716] ufshcd-hi3660 ff3b0000.ufs: check TX_EQUALIZER DB value lane1 = 0x1 [3.190446] ufshcd-hi3660 ff3b0000.ufs: ufshcd_query_flag: Sending flag query for idn 3 failed, err = -11 [3.227484] ufshcd-hi3660 ff3b0000.ufs: ufshcd_query_flag: Sending flag query for idn 3 failed, err = -11 [3.263496] ufshcd-hi3660 ff3b0000.ufs: ufshcd_query_flag: Sending flag query for idn 3 failed, err = -11 [3.299509] ufshcd-hi3660 ff3b0000.ufs: ufshcd_query_flag: Sending flag query for idn 3 failed, err = -11 [3.335528] ufshcd-hi3660 ff3b0000.ufs: ufshcd_query_flag: Sending flag query for idn 3 failed, err = -11 [3.371501] ufshcd-hi3660 ff3b0000.ufs: ufshcd_query_flag: Sending flag query for idn 3 failed, err = -11 [3.407493] ufshcd-hi3660 ff3b0000.ufs: ufshcd_query_flag: Sending flag query for idn 3 failed, err = -11 [3.443501] ufshcd-hi3660 ff3b0000.ufs: ufshcd_query_flag: Sending flag query for idn 3 failed, err = -11 [3.479491] ufshcd-hi3660 ff3b0000.ufs: ufshcd_query_flag: Sending flag query for idn 3 failed, err = -11 If failed to read device desc, card_data->wmanufacturerid and card_data->model will not get the correct value, meaning that hba->dev_quirks will no longer work. And some ufs device's quirks handling will even cause ufs can't work. In fact, our hikey960 board using Hynix ufs device failed to initialize on v4.9 because a quirk of the hynix device was not handled. We test with hikey960 & hikey970 boards in aosp-master hikey-linaro-4.9 (v4.9.100), this patch can solve the above problem perfectly. [3.223550] ufs final power mode: gear = 3, lane = 2, pwr = 1, rate = 2 [3.223565] ufshcd-hi3660 ff3b0000.ufs: set TX_EQUALIZER 3.5db [3.223609] ufs flash device must set VS_DebugSaveConfigTime 0x10 [3.226218] ufshcd-hi3660 ff3b0000.ufs: check TX_EQUALIZER DB value lane0 = 0x1 [3.226247] ufshcd-hi3660 ff3b0000.ufs: check TX_EQUALIZER DB value lane1 = 0x1 [3.226400] ufshcd-hi3660 ff3b0000.ufs: ufshcd_find_max_sup_active_icc_level: Regulator capability was not set, actvIccLevel=0 [3.232847] scsi 0:0:0:49488: Well-known LUN SKhynix H28U62301AMR H109 PQ: 0 ANSI: 6 [3.321453] scsi 0:0:0:49456: Well-known LUN SKhynix H28U62301AMR H109 PQ: 0 ANSI: 6 [3.383820] scsi 0:0:0:49476: Well-known LUN SKhynix H28U62301AMR H109 PQ: 0 ANSI: 6 [3.447615] scsi 0:0:0:0: Direct-Access SKhynix H28U62301AMR H109 PQ: 0 ANSI: 6 [3.503504] sd 0:0:0:0: [sda] 1024 4096-byte logical blocks: (4.19 MB/4.00 MiB) [3.503863] sd 0:0:0:0: [sda] Write Protect is off [3.503867] sd 0:0:0:0: [sda] Mode Sense: 00 32 00 10 [3.503963] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA [3.504017] scsi 0:0:0:1: Direct-Access SKhynix H28U62301AMR H109 PQ: 0 ANSI: 6 [3.505615] sd 0:0:0:0: [sda] Attached SCSI disk [3.547425] sd 0:0:0:1: [sdb] 1024 4096-byte logical blocks: (4.19 MB/4.00 MiB) [3.547768] scsi 0:0:0:2: Direct-Access SKhynix H28U62301AMR H109 PQ: 0 ANSI: 6 [3.548003] sd 0:0:0:1: [sdb] Write Protect is off [3.548005] sd 0:0:0:1: [sdb] Mode Sense: 00 32 00 10 [3.548428] sd 0:0:0:1: [sdb] Write cache: enabled, read cache: enabled, supports DPO and FUA [3.553383] sd 0:0:0:1: [sdb] Attached SCSI disk [3.591547] sd 0:0:0:2: [sdc] 2048 4096-byte logical blocks: (8.39 MB/8.00 MiB) [3.592056] scsi 0:0:0:3: Direct-Access SKhynix H28U62301AMR H109 PQ: 0 ANSI: 6 [3.593336] sd 0:0:0:2: [sdc] Write Protect is off [3.593340] sd 0:0:0:2: [sdc] Mode Sense: 00 32 00 10 [3.593638] sd 0:0:0:2: [sdc] Write cache: enabled, read cache: enabled, supports DPO and FUA [3.596473] Alternate GPT is invalid, using primary GPT. [3.596480] sdc: sdc1 [3.597069] random: fast init done [3.597168] sd 0:0:0:2: [sdc] Attached SCSI disk [3.644460] sd 0:0:0:3: [sdd] 7805952 4096-byte logical blocks: (32.0 GB/29.8 GiB) [3.644867] sd 0:0:0:3: [sdd] Write Protect is off [3.644869] sd 0:0:0:3: [sdd] Mode Sense: 00 32 00 10 [3.644992] sd 0:0:0:3: [sdd] Write cache: enabled, read cache: enabled, supports DPO and FUA [3.646506] Alternate GPT is invalid, using primary GPT. [3.646518] sdd: sdd1 sdd2 sdd3 sdd4 sdd5 sdd6 sdd7 sdd8 sdd9 sdd10 sdd11 sdd12 sdd13 [3.647956] sd 0:0:0:3: [sdd] Attached SCSI disk We hope merge this patch to 4.9-stable to avoid other similar problems. Potomski, MichalX (1): scsi: ufs: Factor out ufshcd_read_desc_param Tomas Winkler (1): scsi: ufs: refactor device descriptor reading subhashj(a)codeaurora.org (1): scsi: ufs: fix failure to read the string descriptor drivers/scsi/ufs/ufs.h | 34 +++--- drivers/scsi/ufs/ufs_quirks.h | 28 +---- drivers/scsi/ufs/ufshcd.c | 272 +++++++++++++++++++++++++++++++----------- drivers/scsi/ufs/ufshcd.h | 16 +++ 4 files changed, 246 insertions(+), 104 deletions(-) -- 2.15.0

7 years, 2 months

2
4
0 0

[PATCH 0/2] 4.14 long term stable ZBC fixes

by Damien Le Moal

Patch 0aa3fdb8b3a6 ("scsi: sd_zbc: Fix potential memory leak") was added in 4.16 and 4.15 stable but did not make it to long term stable 4.14 (as far as I can tell). Patch ccce20fc7968 ("scsi: sd_zbc: Avoid that resetting a zone fails sporadically") is included in 4.16 but does not apply to 4.15 stable nor to 4.14 long term stable and requires extensive modifications. This small series provides a backport of both patches against 4.14. Please consider these patches for inclusion in this long term stable kernel. Bart Van Assche (1): scsi: sd_zbc: Avoid that resetting a zone fails sporadically Damien Le Moal (1): scsi: sd_zbc: Fix potential memory leak drivers/scsi/sd_zbc.c | 128 +++++++++++++++++++++++++----------------- 1 file changed, 76 insertions(+), 52 deletions(-) -- 2.17.0

7 years, 2 months

2
3
0 0

[PATCH ] dmaengine: usb-dmac: fix endless loop in usb_dmac_chan_terminate_all()

by Biju Das

From: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com> commit d9f5efade2cfd729138a7cafb46d01044da40f5e upstream This patch fixes an issue that list_for_each_entry() in usb_dmac_chan_terminate_all() is possible to cause endless loop because this will move own desc to the desc_freed. So, this driver should use list_for_each_entry_safe() instead of list_for_each_entry(). Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com> Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> [biju: cherry-pick to 4.4] Signed-off-by: Biju Das <biju.das(a)bp.renesas.com> --- Hello Greg, I have observed a CPU lock condition with USB DMAC driver on koelsch platform. This patch fixes the issue on 4.4 stable. It is reproducible with ethernet(RNDIS/ECM) gadget configuration. regards, Biju drivers/dma/sh/usb-dmac.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma/sh/usb-dmac.c b/drivers/dma/sh/usb-dmac.c index 56410ea..6682b3e 100644 --- a/drivers/dma/sh/usb-dmac.c +++ b/drivers/dma/sh/usb-dmac.c @@ -448,7 +448,7 @@ usb_dmac_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl, static int usb_dmac_chan_terminate_all(struct dma_chan *chan) { struct usb_dmac_chan *uchan = to_usb_dmac_chan(chan); - struct usb_dmac_desc *desc; + struct usb_dmac_desc *desc, *_desc; unsigned long flags; LIST_HEAD(head); LIST_HEAD(list); @@ -459,7 +459,7 @@ static int usb_dmac_chan_terminate_all(struct dma_chan *chan) if (uchan->desc) uchan->desc = NULL; list_splice_init(&uchan->desc_got, &list); - list_for_each_entry(desc, &list, node) + list_for_each_entry_safe(desc, _desc, &list, node) list_move_tail(&desc->node, &uchan->desc_freed); spin_unlock_irqrestore(&uchan->vc.lock, flags); vchan_dma_desc_free_list(&uchan->vc, &head); -- 2.7.4

7 years, 2 months

2
1
0 0

[PATCH 0/3] Fix double address byte issue

by Fabrizio Castro

Hello Greg, Wolfram recommends the backporting of this series in order to improve the situation with a race condition. Do you think you can take this series for 4.4 stable? This series applies on 4.4.133, and depends on series: "Fix R-Car I2C data byte sent twice issue" Thanks, Fab Wolfram Sang (3): i2c: rcar: don't issue stop when HW does it automatically i2c: rcar: check master irqs before slave irqs i2c: rcar: revoke START request early drivers/i2c/busses/i2c-rcar.c | 36 ++++++++++++------------------------ 1 file changed, 12 insertions(+), 24 deletions(-) -- 2.7.4

7 years, 2 months

2
4
0 0

[PATCH 0/6] Fix R-Car I2C data byte sent twice issue

by Fabrizio Castro

Hello Greg, this series fixes an issue with the I2C driver of the Renesas R-Car and RZ/G1 family of chips. The issue is clearly visible with the CIP kernel (4.4) running on a iwg20d board from iWave due to the way the bq32000 driver/device is interacting with the I2C driver/controller. In the stable kernel (4.4) there is no support for the iwg20d, I tried to replicate the same problem on a Koelsch board with no success, but the problem is there. Do you think this series is suitable for (4.4) stable considering I can't reproduce the problem on the Koelsch board? This patches apply on top of 4.4.133. Thanks, Fab Wolfram Sang (6): i2c: rcar: make sure clocks are on when doing clock calculation i2c: rcar: rework hw init i2c: rcar: remove unused IOERROR state i2c: rcar: remove spinlock i2c: rcar: refactor setup of a msg i2c: rcar: init new messages in irq drivers/i2c/busses/i2c-rcar.c | 166 ++++++++++++++++++------------------------ 1 file changed, 72 insertions(+), 94 deletions(-) -- 2.7.4

7 years, 2 months

3
12
0 0

[PATCH v4.4.y..v4.14.y] tcp: avoid integer overflows in tcp_rcv_space_adjust()

by Guenter Roeck

From: Eric Dumazet <edumazet(a)google.com> commit 607065bad9931e72207b0cac365d7d4abc06bd99 upstream. When using large tcp_rmem[2] values (I did tests with 500 MB), I noticed overflows while computing rcvwin. Lets fix this before the following patch. Signed-off-by: Eric Dumazet <edumazet(a)google.com> Acked-by: Soheil Hassas Yeganeh <soheil(a)google.com> Acked-by: Wei Wang <weiwan(a)google.com> Acked-by: Neal Cardwell <ncardwell(a)google.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> [Backport: sysctl_tcp_rmem is not Namespace-ify'd in older kernels] Signed-off-by: Guenter Roeck <linux(a)roeck-us.net> --- Applies cleanly to v4.4.y and v4.9.y; v4.14.y needs "git am -3". include/linux/tcp.h | 2 +- net/ipv4/tcp_input.c | 10 ++++++---- 2 files changed, 7 insertions(+), 5 deletions(-) diff --git a/include/linux/tcp.h b/include/linux/tcp.h index 2260f92f1492..5b6df1a8dc74 100644 --- a/include/linux/tcp.h +++ b/include/linux/tcp.h @@ -324,7 +324,7 @@ struct tcp_sock { /* Receiver queue space */ struct { - int space; + u32 space; u32 seq; u32 time; } rcvq_space; diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c index ed018760502e..23b95aead897 100644 --- a/net/ipv4/tcp_input.c +++ b/net/ipv4/tcp_input.c @@ -557,8 +557,8 @@ static inline void tcp_rcv_rtt_measure_ts(struct sock *sk, void tcp_rcv_space_adjust(struct sock *sk) { struct tcp_sock *tp = tcp_sk(sk); + u32 copied; int time; - int copied; time = tcp_time_stamp - tp->rcvq_space.time; if (time < (tp->rcv_rtt_est.rtt >> 3) || tp->rcv_rtt_est.rtt == 0) @@ -580,12 +580,13 @@ void tcp_rcv_space_adjust(struct sock *sk) if (sysctl_tcp_moderate_rcvbuf && !(sk->sk_userlocks & SOCK_RCVBUF_LOCK)) { - int rcvwin, rcvmem, rcvbuf; + int rcvmem, rcvbuf; + u64 rcvwin; /* minimal window to cope with packet losses, assuming * steady state. Add some cushion because of small variations. */ - rcvwin = (copied << 1) + 16 * tp->advmss; + rcvwin = ((u64)copied << 1) + 16 * tp->advmss; /* If rate increased by 25%, * assume slow start, rcvwin = 3 * copied @@ -605,7 +606,8 @@ void tcp_rcv_space_adjust(struct sock *sk) while (tcp_win_from_space(rcvmem) < tp->advmss) rcvmem += 128; - rcvbuf = min(rcvwin / tp->advmss * rcvmem, sysctl_tcp_rmem[2]); + do_div(rcvwin, tp->advmss); + rcvbuf = min_t(u64, rcvwin * rcvmem, sysctl_tcp_rmem[2]); if (rcvbuf > sk->sk_rcvbuf) { sk->sk_rcvbuf = rcvbuf; -- 2.7.4

7 years, 2 months

2
1
0 0

[PATCH 0/3] Correct 4.9 stable commit 944e0fc51a89c98

by Juergen Gross

Above commit is a wrong backport, as it is based on a missing prerequisite patch. Correct that by reverting said commit, include the missing patch, and do the backport correctly. Juergen Gross (3): x86/amd: revert commit 944e0fc51a89c9827b98813d65dc083274777c7f xen: set cpu capabilities from xen_start_kernel() x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS when running under Xen arch/x86/xen/enlighten.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) -- 2.13.6

7 years, 2 months

2
4
0 0

stable release patches (gcc, clang)

by Guenter Roeck

Hi Greg, the following are some more patches for stable releases. I collected the following clang patches from chromeos-4.14. They are not really needed to build x86_64:defconfig in v4.14.y with clang (5.0), but they do fix a couple of build warnings if the respective drivers are enabled. I'll leave it up to you if you want to apply them or not. I did make sure that defconfig and allmodconfig still build using gcc with the patches applied. df16aaac26e9 kbuild: clang: remove crufty HOSTCFLAGS cad9946c2a43 drm/i915: Always sanity check engine state upon idling 531beb067c61 dma-buf: remove redundant initialization of sg_table 42b5122e828a drm/amd/powerplay: Fix enum mismatch fb239c1209bb rtlwifi: rtl8192cu: Remove variable self-assignment in rf.c 271ef65b5882 ASoC: Intel: sst: remove redundant variable dma_dev_name d3b56c566d4b platform/chrome: cros_ec_lpc: remove redundant pointer request 0a5f41767444 kbuild: clang: disable unused variable warnings The following patch is needed in v4.4.y to be able to build arm:footbridge_defconfig with gcc 7.3.0. c9bd28233b6d irda: fix overly long udelay() Thanks, Guenter

7 years, 2 months

2
1
0 0

[patch 1/2] mm/huge_memory.c: __split_huge_page() use atomic ClearPageDirty()

by akpm＠linux-foundation.org

From: Hugh Dickins <hughd(a)google.com> Subject: mm/huge_memory.c: __split_huge_page() use atomic ClearPageDirty() Swapping load on huge=always tmpfs (with khugepaged tuned up to be very eager, but I'm not sure that is relevant) soon hung uninterruptibly, waiting for page lock in shmem_getpage_gfp()'s find_lock_entry(), most often when "cp -a" was trying to write to a smallish file. Debug showed that the page in question was not locked, and page->mapping NULL by now, but page->index consistent with having been in a huge page before. Reproduced in minutes on a 4.15 kernel, even with 4.17's 605ca5ede764 ("mm/huge_memory.c: reorder operations in __split_huge_page_tail()") added in; but took hours to reproduce on a 4.17 kernel (no idea why). The culprit proved to be the __ClearPageDirty() on tails beyond i_size in __split_huge_page(): the non-atomic __bitoperation may have been safe when 4.8's baa355fd3314 ("thp: file pages support for split_huge_page()") introduced it, but liable to erase PageWaiters after 4.10's 62906027091f ("mm: add PageWaiters indicating tasks are waiting for a page bit"). Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1805291841070.3197@eggly.anvils Fixes: 62906027091f ("mm: add PageWaiters indicating tasks are waiting for a page bit") Signed-off-by: Hugh Dickins <hughd(a)google.com> Acked-by: Kirill A. Shutemov <kirill.shutemov(a)linux.intel.com> Cc: Konstantin Khlebnikov <khlebnikov(a)yandex-team.ru> Cc: Nicholas Piggin <npiggin(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/huge_memory.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN mm/huge_memory.c~mm-huge_memoryc-__split_huge_page-use-atomic-clearpagedirty mm/huge_memory.c --- a/mm/huge_memory.c~mm-huge_memoryc-__split_huge_page-use-atomic-clearpagedirty +++ a/mm/huge_memory.c @@ -2431,7 +2431,7 @@ static void __split_huge_page(struct pag __split_huge_page_tail(head, i, lruvec, list); /* Some pages can be beyond i_size: drop them from page cache */ if (head[i].index >= end) { - __ClearPageDirty(head + i); + ClearPageDirty(head + i); __delete_from_page_cache(head + i, NULL); if (IS_ENABLED(CONFIG_SHMEM) && PageSwapBacked(head)) shmem_uncharge(head->mapping->host, 1); _

7 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] tracing: Make the snapshot trigger work with instances" failed to apply to 4.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.4-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 2824f5033248600673e3e126a4d135363cbfd9ac Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org> Date: Mon, 28 May 2018 10:56:36 -0400 Subject: [PATCH] tracing: Make the snapshot trigger work with instances The snapshot trigger currently only affects the main ring buffer, even when it is used by the instances. This can be confusing as the snapshot trigger is listed in the instance. > # cd /sys/kernel/tracing > # mkdir instances/foo > # echo snapshot > instances/foo/events/syscalls/sys_enter_fchownat/trigger > # echo top buffer > trace_marker > # echo foo buffer > instances/foo/trace_marker > # touch /tmp/bar > # chown rostedt /tmp/bar > # cat instances/foo/snapshot # tracer: nop # # # * Snapshot is freed * # # Snapshot commands: # echo 0 > snapshot : Clears and frees snapshot buffer # echo 1 > snapshot : Allocates snapshot buffer, if not already allocated. # Takes a snapshot of the main buffer. # echo 2 > snapshot : Clears snapshot buffer (but does not allocate or free) # (Doesn't have to be '2' works with any number that # is not a '0' or '1') > # cat snapshot # tracer: nop # # _-----=> irqs-off # / _----=> need-resched # | / _---=> hardirq/softirq # || / _--=> preempt-depth # ||| / delay # TASK-PID CPU# |||| TIMESTAMP FUNCTION # | | | |||| | | bash-1189 [000] .... 111.488323: tracing_mark_write: top buffer Not only did the snapshot occur in the top level buffer, but the instance snapshot buffer should have been allocated, and it is still free. Cc: stable(a)vger.kernel.org Fixes: 85f2b08268c01 ("tracing: Add basic event trigger framework") Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index 414d7210b2ec..bcd93031d042 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -893,7 +893,7 @@ int __trace_bputs(unsigned long ip, const char *str) EXPORT_SYMBOL_GPL(__trace_bputs); #ifdef CONFIG_TRACER_SNAPSHOT -static void tracing_snapshot_instance(struct trace_array *tr) +void tracing_snapshot_instance(struct trace_array *tr) { struct tracer *tracer = tr->current_trace; unsigned long flags; @@ -949,7 +949,7 @@ static int resize_buffer_duplicate_size(struct trace_buffer *trace_buf, struct trace_buffer *size_buf, int cpu_id); static void set_buffer_entries(struct trace_buffer *buf, unsigned long val); -static int alloc_snapshot(struct trace_array *tr) +int tracing_alloc_snapshot_instance(struct trace_array *tr) { int ret; @@ -995,7 +995,7 @@ int tracing_alloc_snapshot(void) struct trace_array *tr = &global_trace; int ret; - ret = alloc_snapshot(tr); + ret = tracing_alloc_snapshot_instance(tr); WARN_ON(ret < 0); return ret; @@ -5408,7 +5408,7 @@ static int tracing_set_tracer(struct trace_array *tr, const char *buf) #ifdef CONFIG_TRACER_MAX_TRACE if (t->use_max_tr && !had_max_tr) { - ret = alloc_snapshot(tr); + ret = tracing_alloc_snapshot_instance(tr); if (ret < 0) goto out; } @@ -6451,7 +6451,7 @@ tracing_snapshot_write(struct file *filp, const char __user *ubuf, size_t cnt, } #endif if (!tr->allocated_snapshot) { - ret = alloc_snapshot(tr); + ret = tracing_alloc_snapshot_instance(tr); if (ret < 0) break; } @@ -7179,7 +7179,7 @@ ftrace_trace_snapshot_callback(struct trace_array *tr, struct ftrace_hash *hash, return ret; out_reg: - ret = alloc_snapshot(tr); + ret = tracing_alloc_snapshot_instance(tr); if (ret < 0) goto out; diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h index 6fb46a06c9dc..507954b4e058 100644 --- a/kernel/trace/trace.h +++ b/kernel/trace/trace.h @@ -1817,6 +1817,17 @@ static inline void __init trace_event_init(void) { } static inline void trace_event_eval_update(struct trace_eval_map **map, int len) { } #endif +#ifdef CONFIG_TRACER_SNAPSHOT +void tracing_snapshot_instance(struct trace_array *tr); +int tracing_alloc_snapshot_instance(struct trace_array *tr); +#else +static inline void tracing_snapshot_instance(struct trace_array *tr) { } +static inline int tracing_alloc_snapshot_instance(struct trace_array *tr) +{ + return 0; +} +#endif + extern struct trace_iterator *tracepoint_print_iter; #endif /* _LINUX_KERNEL_TRACE_H */ diff --git a/kernel/trace/trace_events_trigger.c b/kernel/trace/trace_events_trigger.c index 9be317d388c5..8b5bdcf64871 100644 --- a/kernel/trace/trace_events_trigger.c +++ b/kernel/trace/trace_events_trigger.c @@ -643,6 +643,7 @@ event_trigger_callback(struct event_command *cmd_ops, trigger_data->count = -1; trigger_data->ops = trigger_ops; trigger_data->cmd_ops = cmd_ops; + trigger_data->private_data = file; INIT_LIST_HEAD(&trigger_data->list); INIT_LIST_HEAD(&trigger_data->named_list); @@ -1054,7 +1055,12 @@ static void snapshot_trigger(struct event_trigger_data *data, void *rec, struct ring_buffer_event *event) { - tracing_snapshot(); + struct trace_event_file *file = data->private_data; + + if (file) + tracing_snapshot_instance(file->tr); + else + tracing_snapshot(); } static void @@ -1077,7 +1083,7 @@ register_snapshot_trigger(char *glob, struct event_trigger_ops *ops, { int ret = register_trigger(glob, ops, data, file); - if (ret > 0 && tracing_alloc_snapshot() != 0) { + if (ret > 0 && tracing_alloc_snapshot_instance(file->tr) != 0) { unregister_trigger(glob, ops, data, file); ret = 0; }

7 years, 2 months

1
0
0 0

FAILED: patch "[PATCH] tracing: Make the snapshot trigger work with instances" failed to apply to 4.9-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.9-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 2824f5033248600673e3e126a4d135363cbfd9ac Mon Sep 17 00:00:00 2001 From: "Steven Rostedt (VMware)" <rostedt(a)goodmis.org> Date: Mon, 28 May 2018 10:56:36 -0400 Subject: [PATCH] tracing: Make the snapshot trigger work with instances The snapshot trigger currently only affects the main ring buffer, even when it is used by the instances. This can be confusing as the snapshot trigger is listed in the instance. > # cd /sys/kernel/tracing > # mkdir instances/foo > # echo snapshot > instances/foo/events/syscalls/sys_enter_fchownat/trigger > # echo top buffer > trace_marker > # echo foo buffer > instances/foo/trace_marker > # touch /tmp/bar > # chown rostedt /tmp/bar > # cat instances/foo/snapshot # tracer: nop # # # * Snapshot is freed * # # Snapshot commands: # echo 0 > snapshot : Clears and frees snapshot buffer # echo 1 > snapshot : Allocates snapshot buffer, if not already allocated. # Takes a snapshot of the main buffer. # echo 2 > snapshot : Clears snapshot buffer (but does not allocate or free) # (Doesn't have to be '2' works with any number that # is not a '0' or '1') > # cat snapshot # tracer: nop # # _-----=> irqs-off # / _----=> need-resched # | / _---=> hardirq/softirq # || / _--=> preempt-depth # ||| / delay # TASK-PID CPU# |||| TIMESTAMP FUNCTION # | | | |||| | | bash-1189 [000] .... 111.488323: tracing_mark_write: top buffer Not only did the snapshot occur in the top level buffer, but the instance snapshot buffer should have been allocated, and it is still free. Cc: stable(a)vger.kernel.org Fixes: 85f2b08268c01 ("tracing: Add basic event trigger framework") Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c index 414d7210b2ec..bcd93031d042 100644 --- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -893,7 +893,7 @@ int __trace_bputs(unsigned long ip, const char *str) EXPORT_SYMBOL_GPL(__trace_bputs); #ifdef CONFIG_TRACER_SNAPSHOT -static void tracing_snapshot_instance(struct trace_array *tr) +void tracing_snapshot_instance(struct trace_array *tr) { struct tracer *tracer = tr->current_trace; unsigned long flags; @@ -949,7 +949,7 @@ static int resize_buffer_duplicate_size(struct trace_buffer *trace_buf, struct trace_buffer *size_buf, int cpu_id); static void set_buffer_entries(struct trace_buffer *buf, unsigned long val); -static int alloc_snapshot(struct trace_array *tr) +int tracing_alloc_snapshot_instance(struct trace_array *tr) { int ret; @@ -995,7 +995,7 @@ int tracing_alloc_snapshot(void) struct trace_array *tr = &global_trace; int ret; - ret = alloc_snapshot(tr); + ret = tracing_alloc_snapshot_instance(tr); WARN_ON(ret < 0); return ret; @@ -5408,7 +5408,7 @@ static int tracing_set_tracer(struct trace_array *tr, const char *buf) #ifdef CONFIG_TRACER_MAX_TRACE if (t->use_max_tr && !had_max_tr) { - ret = alloc_snapshot(tr); + ret = tracing_alloc_snapshot_instance(tr); if (ret < 0) goto out; } @@ -6451,7 +6451,7 @@ tracing_snapshot_write(struct file *filp, const char __user *ubuf, size_t cnt, } #endif if (!tr->allocated_snapshot) { - ret = alloc_snapshot(tr); + ret = tracing_alloc_snapshot_instance(tr); if (ret < 0) break; } @@ -7179,7 +7179,7 @@ ftrace_trace_snapshot_callback(struct trace_array *tr, struct ftrace_hash *hash, return ret; out_reg: - ret = alloc_snapshot(tr); + ret = tracing_alloc_snapshot_instance(tr); if (ret < 0) goto out; diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h index 6fb46a06c9dc..507954b4e058 100644 --- a/kernel/trace/trace.h +++ b/kernel/trace/trace.h @@ -1817,6 +1817,17 @@ static inline void __init trace_event_init(void) { } static inline void trace_event_eval_update(struct trace_eval_map **map, int len) { } #endif +#ifdef CONFIG_TRACER_SNAPSHOT +void tracing_snapshot_instance(struct trace_array *tr); +int tracing_alloc_snapshot_instance(struct trace_array *tr); +#else +static inline void tracing_snapshot_instance(struct trace_array *tr) { } +static inline int tracing_alloc_snapshot_instance(struct trace_array *tr) +{ + return 0; +} +#endif + extern struct trace_iterator *tracepoint_print_iter; #endif /* _LINUX_KERNEL_TRACE_H */ diff --git a/kernel/trace/trace_events_trigger.c b/kernel/trace/trace_events_trigger.c index 9be317d388c5..8b5bdcf64871 100644 --- a/kernel/trace/trace_events_trigger.c +++ b/kernel/trace/trace_events_trigger.c @@ -643,6 +643,7 @@ event_trigger_callback(struct event_command *cmd_ops, trigger_data->count = -1; trigger_data->ops = trigger_ops; trigger_data->cmd_ops = cmd_ops; + trigger_data->private_data = file; INIT_LIST_HEAD(&trigger_data->list); INIT_LIST_HEAD(&trigger_data->named_list); @@ -1054,7 +1055,12 @@ static void snapshot_trigger(struct event_trigger_data *data, void *rec, struct ring_buffer_event *event) { - tracing_snapshot(); + struct trace_event_file *file = data->private_data; + + if (file) + tracing_snapshot_instance(file->tr); + else + tracing_snapshot(); } static void @@ -1077,7 +1083,7 @@ register_snapshot_trigger(char *glob, struct event_trigger_ops *ops, { int ret = register_trigger(glob, ops, data, file); - if (ret > 0 && tracing_alloc_snapshot() != 0) { + if (ret > 0 && tracing_alloc_snapshot_instance(file->tr) != 0) { unregister_trigger(glob, ops, data, file); ret = 0; }

7 years, 2 months

1
0
0 0

[PATCH v4.9.y 0/2] arm64: prevent boot-time crashes when detecting local features

by Mark Rutland

Marc reported that v4.9.y hung at boot time on his GICv3 system, since the spectre backports. This is because the errata detection logic tries to enable a static key in the secondary bringup path, before the secondary CPU has configured its GICv3 CPU interface, causing it to blow up when it tries to IPI the other CPUs. This affects any local cpu feature detection in systems with heterogeneous CPUs. Some prior rework upstream moved this out of the secondary bringup path, which avoids the issue, so this series backports said rework. Thanks, Mark. Mark Rutland (1): arm64/cpufeature: don't use mutex in bringup path Suzuki K Poulose (1): arm64: Add hypervisor safe helper for checking constant capabilities arch/arm64/include/asm/cpufeature.h | 27 ++++++++++++++++++++------- arch/arm64/include/asm/kvm_host.h | 10 +++++++--- arch/arm64/include/asm/kvm_mmu.h | 2 +- arch/arm64/include/asm/mmu.h | 2 +- arch/arm64/kernel/cpufeature.c | 28 ++++++++++++++++++++++++---- arch/arm64/kernel/process.c | 2 +- drivers/irqchip/irq-gic-v3.c | 13 +------------ 7 files changed, 55 insertions(+), 29 deletions(-) -- 2.11.0

7 years, 2 months

1
2
0 0

[PATCH] Revert "ima: limit file hash setting by user to fix and log modes"

by Mike Rapoport

Hi, On a system that has IMA appraisal enabled it is impossible to create security.ima extended attribute files that contain IMA hash. For instance, consider the following use case: 1) extract application files to a staging area as non root user 2) verify that installation is correct 3) create IMA extended attributes for the installed files 4) move the files to their destination 5) change the files ownership to root With the longterm kernels 4.4.x and 4.9.x step 3 will fail. The issues is fixed in upstream kernels by the commit f5acb3dcba1ffb7f0b8cbb9dba61500eea5d610b ("Revert "ima: limit file hash setting by user to fix and log modes"), with the patch also quoted below. -- Sincerely yours, Mike. >From f5acb3dcba1ffb7f0b8cbb9dba61500eea5d610b Mon Sep 17 00:00:00 2001 From: Mimi Zohar <zohar(a)linux.vnet.ibm.com> Date: Wed, 2 Nov 2016 09:14:16 -0400 Subject: [PATCH] Revert "ima: limit file hash setting by user to fix and log modes" Userspace applications have been modified to write security xattrs, but they are not context aware. In the case of security.ima, the security xattr can be either a file hash or a file signature. Permitting writing one, but not the other requires the application to be context aware. In addition, userspace applications might write files to a staging area, which might not be in policy, and then change some file metadata (eg. owner) making it in policy. As a result, these files are not labeled properly. This reverts commit c68ed80c97d9720f51ef31fe91560fdd1e121533, which prevents writing file hashes as security.ima xattrs. Requested-by: Patrick Ohly <patrick.ohly(a)intel.com> Cc: Dmitry Kasatkin <dmitry.kasatkin(a)gmail.com> Signed-off-by: Mimi Zohar <zohar(a)linux.vnet.ibm.com> --- security/integrity/ima/ima_appraise.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/security/integrity/ima/ima_appraise.c b/security/integrity/ima/ima_appraise.c index 389325ac6067..a705598ced5f 100644 --- a/security/integrity/ima/ima_appraise.c +++ b/security/integrity/ima/ima_appraise.c @@ -384,14 +384,10 @@ int ima_inode_setxattr(struct dentry *dentry, const char *xattr_name, result = ima_protect_xattr(dentry, xattr_name, xattr_value, xattr_value_len); if (result == 1) { - bool digsig; - if (!xattr_value_len || (xvalue->type >= IMA_XATTR_LAST)) return -EINVAL; - digsig = (xvalue->type == EVM_IMA_XATTR_DIGSIG); - if (!digsig && (ima_appraise & IMA_APPRAISE_ENFORCE)) - return -EPERM; - ima_reset_appraise_flags(d_backing_inode(dentry), digsig); + ima_reset_appraise_flags(d_backing_inode(dentry), + (xvalue->type == EVM_IMA_XATTR_DIGSIG) ? 1 : 0); result = 0; } return result; -- 2.7.4

7 years, 2 months

2
1
0 0

[PATCH 0/1] Fix for xfs agfl wrap crash for stable kernels

by Dave Chiluk

When moving xfs volumes between kernels that have 96f859d52 and don't have 96f859d52, there is potential for a filesystem crash if the agfl has wrapped (flfirst > fllast). Depending on which filesystem this is this can take down the whole machine. Such is the case when upgrading from the stock Centos 7 3.13 to the kernel.org stable kernels (via elrepo). Another possible common boundary cross I noticed was early Ubuntu kernel v4.4 to recent v4.4. We've been hitting this crash roughly once a week in our cloud, and it has produced the below stack trace. The solution prefers to reset the agfl and leak a few blocks instead of shutting down the filesystem. The leaked blocks can be recovered using a xfs_repair. The attached patch is a backport of a27ba2607 due to a78ee256c. It is intended for and tested on the v4.4 stream, but should apply to all kernels that lack upstream a78ee256c. Thanks, Dave Chiluk vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv XFS (dm-4): Internal error XFS_WANT_CORRUPTED_GOTO at line 3505 of file fs/xfs/libxfs/xfs_btree.c. Caller xfs_free_ag_extent+0x35d/0x7a0 [xfs] CPU: 18 PID: 9896 Comm: mesos-slave Not tainted 4.10.10-1.el7.elrepo.x86_64 #1 Hardware name: Supermicro PIO-618U-TR4T+-ST031/X10DRU-i+, BIOS 2.0 12/17/2015 Call Trace: dump_stack+0x63/0x87 xfs_error_report+0x3b/0x40 [xfs] ? xfs_free_ag_extent+0x35d/0x7a0 [xfs] xfs_btree_insert+0x1b0/0x1c0 [xfs] xfs_free_ag_extent+0x35d/0x7a0 [xfs] xfs_free_extent+0xbb/0x150 [xfs] xfs_trans_free_extent+0x4f/0x110 [xfs] ? xfs_trans_add_item+0x5d/0x90 [xfs] xfs_extent_free_finish_item+0x26/0x40 [xfs] xfs_defer_finish+0x149/0x410 [xfs] xfs_remove+0x281/0x330 [xfs] xfs_vn_unlink+0x55/0xa0 [xfs] vfs_rmdir+0xb6/0x130 do_rmdir+0x1b3/0x1d0 SyS_rmdir+0x16/0x20 do_syscall_64+0x67/0x180 entry_SYSCALL64_slow_path+0x25/0x25 RIP: 0033:0x7f85d8d92397 RSP: 002b:00007f85cef9b758 EFLAGS: 00000246 ORIG_RAX: 0000000000000054 RAX: ffffffffffffffda RBX: 00007f858c00b4c0 RCX: 00007f85d8d92397 RDX: 00007f858c09ad70 RSI: 0000000000000000 RDI: 00007f858c09ad70 RBP: 00007f85cef9bc30 R08: 0000000000000001 R09: 0000000000000002 R10: 0000006f74656c67 R11: 0000000000000246 R12: 00007f85cef9c640 R13: 00007f85cef9bc50 R14: 00007f85cef9bcc0 R15: 00007f85cef9bc40 XFS (dm-4): xfs_do_force_shutdown(0x8) called from line 236 of file fs/xfs/libxfs/xfs_defer.c. Return address = 0xffffffffa028f087 XFS (dm-4): Corruption of in-memory data detected. Shutting down filesystem XFS (dm-4): Please umount the filesystem and rectify the problem(s) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

7 years, 2 months

2
2
0 0

Please apply this commit to v4.14.y: de0aa7b2f97d ("PCI: hv: Fix 2 hang issues in hv_compose_msi_msg()")

by Dexuan Cui

Hi, The patch has been in v4.15.y and v4.16.y, but not in v4.14.y: de0aa7b2f97d ("PCI: hv: Fix 2 hang issues in hv_compose_msi_msg()") The second issue described in the changelog of the commit can happen to v4.14.y too. Since the v4.14.y is a longterm kernel, we should apply the patch to it. I have verified the commit can be cherry-picked cleanly. Thanks! -- Dexuan

7 years, 2 months

2
2
0 0

[PATCH-RESEND] cxl: Disable prefault_mode in Radix mode

by Vaibhav Jain

From: Vaibhav Jain <vaibhav(a)linux.ibm.com> Currently we see a kernel-oops reported on Power-9 while attaching a context to an AFU, with radix-mode and sysfs attr 'prefault_mode' set to anything other than 'none'. The backtrace of the oops is of this form: Unable to handle kernel paging request for data at address 0x00000080 Faulting instruction address: 0xc00800000bcf3b20 cpu 0x1: Vector: 300 (Data Access) at [c00000037f003800] pc: c00800000bcf3b20: cxl_load_segment+0x178/0x290 [cxl] lr: c00800000bcf39f0: cxl_load_segment+0x48/0x290 [cxl] sp: c00000037f003a80 msr: 9000000000009033 dar: 80 dsisr: 40000000 current = 0xc00000037f280000 paca = 0xc0000003ffffe600 softe: 3 irq_happened: 0x01 pid = 3529, comm = afp_no_int <snip> [c00000037f003af0] c00800000bcf4424 cxl_prefault+0xfc/0x248 [cxl] [c00000037f003b50] c00800000bcf8a40 process_element_entry_psl9+0xd8/0x1a0 [cxl] [c00000037f003b90] c00800000bcf944c cxl_attach_dedicated_process_psl9+0x44/0x130 [cxl] [c00000037f003bd0] c00800000bcf5448 native_attach_process+0xc0/0x130 [cxl] [c00000037f003c50] c00800000bcf16cc afu_ioctl+0x3f4/0x5e0 [cxl] [c00000037f003d00] c00000000039d98c do_vfs_ioctl+0xdc/0x890 [c00000037f003da0] c00000000039e1a8 ksys_ioctl+0x68/0xf0 [c00000037f003df0] c00000000039e270 sys_ioctl+0x40/0xa0 [c00000037f003e30] c00000000000b320 system_call+0x58/0x6c --- Exception: c01 (System Call) at 0000000010053bb0 The issue is caused as on Power-8 the AFU attr 'prefault_mode' was used to improve initial storage fault performance by prefaulting process segments. However on Power-9 with radix mode we don't have Storage-Segments that we can prefault. Also prefaulting process Pages will be too costly and fine-grained. Hence, since the prefaulting mechanism doesn't makes sense of radix-mode, this patch updates prefault_mode_store() to not allow any other value apart from CXL_PREFAULT_NONE when radix mode is enabled. Cc: <stable(a)vger.kernel.org> Fixes: f24be42aab37 ("cxl: Add psl9 specific code") Signed-off-by: Vaibhav Jain <vaibhav(a)linux.ibm.com> --- Change-log: Resend -> Updated the commit description to add more info on the issue seen [Andrew] --- Documentation/ABI/testing/sysfs-class-cxl | 4 +++- drivers/misc/cxl/sysfs.c | 16 ++++++++++++---- 2 files changed, 15 insertions(+), 5 deletions(-) diff --git a/Documentation/ABI/testing/sysfs-class-cxl b/Documentation/ABI/testing/sysfs-class-cxl index 640f65e79ef1..267920a1874b 100644 --- a/Documentation/ABI/testing/sysfs-class-cxl +++ b/Documentation/ABI/testing/sysfs-class-cxl @@ -69,7 +69,9 @@ Date: September 2014 Contact: linuxppc-dev(a)lists.ozlabs.org Description: read/write Set the mode for prefaulting in segments into the segment table - when performing the START_WORK ioctl. Possible values: + when performing the START_WORK ioctl. Only applicable when + running under hashed page table mmu. + Possible values: none: No prefaulting (default) work_element_descriptor: Treat the work element descriptor as an effective address and diff --git a/drivers/misc/cxl/sysfs.c b/drivers/misc/cxl/sysfs.c index 4b5a4c5d3c01..629e2e156412 100644 --- a/drivers/misc/cxl/sysfs.c +++ b/drivers/misc/cxl/sysfs.c @@ -353,12 +353,20 @@ static ssize_t prefault_mode_store(struct device *device, struct cxl_afu *afu = to_cxl_afu(device); enum prefault_modes mode = -1; - if (!strncmp(buf, "work_element_descriptor", 23)) - mode = CXL_PREFAULT_WED; - if (!strncmp(buf, "all", 3)) - mode = CXL_PREFAULT_ALL; if (!strncmp(buf, "none", 4)) mode = CXL_PREFAULT_NONE; + else { + if (!radix_enabled()) { + + /* only allowed when not in radix mode */ + if (!strncmp(buf, "work_element_descriptor", 23)) + mode = CXL_PREFAULT_WED; + if (!strncmp(buf, "all", 3)) + mode = CXL_PREFAULT_ALL; + } else { + dev_err(device, "Cannot prefault with radix enabled\n"); + } + } if (mode == -1) return -EINVAL; -- 2.17.0

7 years, 2 months

5
5
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror