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

[Linux-stable-mirror] [PATCH 1/1] hv: kvp: Avoid reading past allocated blocks from KVP file

by kys＠exchange.microsoft.com

From: Paul Meyer <Paul.Meyer(a)microsoft.com> While reading in more than one block (50) of KVP records, the allocation goes per block, but the reads used the total number of allocated records (without resetting the pointer/stream). This causes the records buffer to overrun when the refresh reads more than one block over the previous capacity (e.g. reading more than 100 KVP records whereas the in-memory database was empty before). Fix this by reading the correct number of KVP records from file each time. Signed-off-by: Paul Meyer <Paul.Meyer(a)microsoft.com> Signed-off-by: Long Li <longli(a)microsoft.com> Cc: stable(a)vger.kernel.org Signed-off-by: K. Y. Srinivasan <kys(a)microsoft.com> --- tools/hv/hv_kvp_daemon.c | 70 +++++++++------------------------------------ 1 files changed, 14 insertions(+), 56 deletions(-) diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c index eaa3bec..4c99c57 100644 --- a/tools/hv/hv_kvp_daemon.c +++ b/tools/hv/hv_kvp_daemon.c @@ -193,11 +193,14 @@ static void kvp_update_mem_state(int pool) for (;;) { readp = &record[records_read]; records_read += fread(readp, sizeof(struct kvp_record), - ENTRIES_PER_BLOCK * num_blocks, - filep); + ENTRIES_PER_BLOCK * num_blocks - records_read, + filep); if (ferror(filep)) { - syslog(LOG_ERR, "Failed to read file, pool: %d", pool); + syslog(LOG_ERR, + "Failed to read file, pool: %d; error: %d %s", + pool, errno, strerror(errno)); + kvp_release_lock(pool); exit(EXIT_FAILURE); } @@ -210,6 +213,7 @@ static void kvp_update_mem_state(int pool) if (record == NULL) { syslog(LOG_ERR, "malloc failed"); + kvp_release_lock(pool); exit(EXIT_FAILURE); } continue; @@ -224,15 +228,11 @@ static void kvp_update_mem_state(int pool) fclose(filep); kvp_release_lock(pool); } + static int kvp_file_init(void) { int fd; - FILE *filep; - size_t records_read; char *fname; - struct kvp_record *record; - struct kvp_record *readp; - int num_blocks; int i; int alloc_unit = sizeof(struct kvp_record) * ENTRIES_PER_BLOCK; @@ -246,61 +246,19 @@ static int kvp_file_init(void) for (i = 0; i < KVP_POOL_COUNT; i++) { fname = kvp_file_info[i].fname; - records_read = 0; - num_blocks = 1; sprintf(fname, "%s/.kvp_pool_%d", KVP_CONFIG_LOC, i); fd = open(fname, O_RDWR | O_CREAT | O_CLOEXEC, 0644 /* rw-r--r-- */); if (fd == -1) return 1; - - filep = fopen(fname, "re"); - if (!filep) { - close(fd); - return 1; - } - - record = malloc(alloc_unit * num_blocks); - if (record == NULL) { - fclose(filep); - close(fd); - return 1; - } - for (;;) { - readp = &record[records_read]; - records_read += fread(readp, sizeof(struct kvp_record), - ENTRIES_PER_BLOCK, - filep); - - if (ferror(filep)) { - syslog(LOG_ERR, "Failed to read file, pool: %d", - i); - exit(EXIT_FAILURE); - } - - if (!feof(filep)) { - /* - * We have more data to read. - */ - num_blocks++; - record = realloc(record, alloc_unit * - num_blocks); - if (record == NULL) { - fclose(filep); - close(fd); - return 1; - } - continue; - } - break; - } kvp_file_info[i].fd = fd; - kvp_file_info[i].num_blocks = num_blocks; - kvp_file_info[i].records = record; - kvp_file_info[i].num_records = records_read; - fclose(filep); - + kvp_file_info[i].num_blocks = 1; + kvp_file_info[i].records = malloc(alloc_unit); + if (kvp_file_info[i].records == NULL) + return 1; + kvp_file_info[i].num_records = 0; + kvp_update_mem_state(i); } return 0; -- 1.7.1

7 years, 7 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH] watchdog: indydog: Add dependency on SGI_HAS_INDYDOG

by Ralf Baechle

On Tue, Nov 14, 2017 at 11:17:38AM +0000, James Hogan wrote: > On Tue, Nov 14, 2017 at 10:52:54AM +0000, Matt Redfearn wrote: > > Commit da2a68b3eb47 ("watchdog: Enable COMPILE_TEST where possible") > > enabled building the Indy watchdog driver when COMPILE_TEST is enabled. > > However, the driver makes reference to symbols that are only defined for > > certain platforms are selected in the config. These platforms select > > SGI_HAS_INDYDOG. Without this, link time errors result, for example > > when building a MIPS allyesconfig. > > > > drivers/watchdog/indydog.o: In function `indydog_write': > > indydog.c:(.text+0x18): undefined reference to `sgimc' > > indydog.c:(.text+0x1c): undefined reference to `sgimc' > > drivers/watchdog/indydog.o: In function `indydog_start': > > indydog.c:(.text+0x54): undefined reference to `sgimc' > > indydog.c:(.text+0x58): undefined reference to `sgimc' > > drivers/watchdog/indydog.o: In function `indydog_stop': > > indydog.c:(.text+0xa4): undefined reference to `sgimc' > > drivers/watchdog/indydog.o:indydog.c:(.text+0xa8): more undefined > > references to `sgimc' follow > > make: *** [Makefile:1005: vmlinux] Error 1 > > > > Fix this by ensuring that CONFIG_INDIDOG can only be selected when the > > necessary dependent platform symbols are built in. > > > > Fixes: da2a68b3eb47 ("watchdog: Enable COMPILE_TEST where possible") > > Signed-off-by: Matt Redfearn <matt.redfearn(a)mips.com> > > Cc: <stable(a)vger.kernel.org> # 4.11 + > > --- > > > > drivers/watchdog/Kconfig | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig > > index ca200d1f310a..d96e2e7544fc 100644 > > --- a/drivers/watchdog/Kconfig > > +++ b/drivers/watchdog/Kconfig > > @@ -1451,7 +1451,7 @@ config RC32434_WDT > > > > config INDYDOG > > tristate "Indy/I2 Hardware Watchdog" > > - depends on SGI_HAS_INDYDOG || (MIPS && COMPILE_TEST) > > + depends on SGI_HAS_INDYDOG || (MIPS && COMPILE_TEST && SGI_HAS_INDYDOG) > > (MIPS && COMPILE_TEST && SGI_HAS_INDYDOG) implies SGI_HAS_INDYDOG > > So I think you can just do: > - depends on SGI_HAS_INDYDOG || (MIPS && COMPILE_TEST) > + depends on SGI_HAS_INDYDOG > > I.e. COMPILE_TEST isn't of any value in this case. I agree, due to the references to sgimc this driver will only compile for the platforms which set SGI_HAS_INDYDOG; MIPS as the dependency is too generic. Updated patch for the watchdog maintainers' ease below. Ralf Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org> Reported-by: Matt Redfearn <matt.redfearn(a)mips.com> Suggested-by: James Hogan <james.hogan(a)mips.com> drivers/watchdog/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index c722cbfdc7e6..3ece1335ba84 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -1451,7 +1451,7 @@ config RC32434_WDT config INDYDOG tristate "Indy/I2 Hardware Watchdog" - depends on SGI_HAS_INDYDOG || (MIPS && COMPILE_TEST) + depends on SGI_HAS_INDYDOG help Hardware driver for the Indy's/I2's watchdog. This is a watchdog timer that will reboot the machine after a 60 second

7 years, 7 months

2
1
0 0

[Linux-stable-mirror] [PATCH] ibmveth: Kernel crash LSO offload flag toggle

by Bryant G. Ly

The following script when run (along with some iperf traffic recreates the crash within 5-10 mins or so). while true do ethtool -k ibmveth0 | grep tcp-segmentation-offload ethtool -K ibmveth0 tso off ethtool -k ibmveth0 | grep tcp-segmentation-offload ethtool -K ibmveth0 tso on done Note: This issue happens the very first time largsesend offload is turned off too (but the above script recreates the issue all the times) Stack trace output: [76563.914380] NIP [c000000000063940] memcpy_power7+0x40/0x800 [76563.914387] LR [d000000000d31788] ibmveth_start_xmit+0x1c8/0x8d0 [ibmveth] [76563.914392] Call Trace: [76563.914396] [c0000000feab3270] [c0000000feab32d0] 0xc0000000feab32d0 (unreliable) [76563.914407] [c0000000feab3360] [c0000000009816f4] dev_hard_start_xmit+0x304/0x530 [76563.914415] [c0000000feab3440] [c0000000009b6564] sch_direct_xmit+0x124/0x330 [76563.914423] [c0000000feab34e0] [c000000000981ddc] __dev_queue_xmit+0x26c/0x770 [76563.914431] [c0000000feab3580] [c000000000a1efc0] arp_xmit+0x30/0xd0 [76563.914438] [c0000000feab35f0] [c000000000a1f0f4] arp_send_dst.part.0+0x94/0xb0 [76563.914445] [c0000000feab3660] [c000000000a1fcb4] arp_solicit+0x114/0x2b0 [76563.914452] [c0000000feab3730] [c00000000098d8f4] neigh_probe+0x84/0xd0 [76563.914460] [c0000000feab3760] [c0000000009937cc] neigh_timer_handler+0xbc/0x320 [76563.914468] [c0000000feab37a0] [c00000000014a3fc] call_timer_fn+0x5c/0x1c0 [76563.914474] [c0000000feab3830] [c00000000014a8bc] run_timer_softirq+0x31c/0x3f0 [76563.914483] [c0000000feab3900] [c0000000000bec58] __do_softirq+0x188/0x3e0 [76563.914490] [c0000000feab39f0] [c0000000000bf128] irq_exit+0xc8/0x100 [76563.914498] [c0000000feab3a10] [c00000000001f974] timer_interrupt+0xa4/0xe0 [76563.914505] [c0000000feab3a40] [c000000000002714] decrementer_common+0x114/0x180 Oops output: [76563.914173] Unable to handle kernel paging request for data at address 0x00000000 [76563.914197] Faulting instruction address: 0xc000000000063940 [76563.914205] Oops: Kernel access of bad area, sig: 11 [#1] [76563.914210] SMP NR_CPUS=2048 NUMA pSeries [76563.914217] Modules linked in: rpadlpar_io rpaphp dccp_diag dccp tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag nls_utf8 isofs binfmt_misc pseries_rng rtc_generic autofs4 ibmvfc scsi_transport_fc ibmvscsi ibmveth [76563.914251] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.4.0-34-generic #53-Ubuntu [76563.914258] task: c0000000fe9efcc0 ti: c0000000feab0000 task.ti: c0000000feab0000 [76563.914265] NIP: c000000000063940 LR: d000000000d31788 CTR: c000000000064100 [76563.914271] REGS: c0000000feab2ff0 TRAP: 0300 Not tainted (4.4.0-34-generic) [76563.914277] MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 4800284e XER: 0000001a [76563.914294] CFAR: c000000000008468 DAR: 0000000000000000 DSISR: 42000000 SOFTE: 1 GPR00: 000000000000f240 c0000000feab3270 c0000000015b5d00 0000000000000000 GPR04: c00000000d9b0004 000000000000002a 0000000000000006 c0000000efc0ccac GPR08: d000000000d3dd28 0000000000000080 0000000000000000 d000000000d34758 GPR12: c000000000064100 c00000000e7f1c80 c0000000ffdca938 0000000000000100 GPR16: c0000000ffdca738 c0000000ffdca538 c0000000feab34a0 c0000000015f4d00 GPR20: 0000000000000000 c0000000015f4cf0 c0000000f5945900 0000000000000000 GPR24: 0000000000000000 0000000080000000 c0000000feab32d0 c0000000efc0ccac GPR28: c0000000f23ccb00 c0000000f5945000 c0000000f23ccb00 c0000000efc0cc00 [76563.914380] NIP [c000000000063940] memcpy_power7+0x40/0x800 [76563.914387] LR [d000000000d31788] ibmveth_start_xmit+0x1c8/0x8d0 [ibmveth] [76563.914392] Call Trace: [76563.914396] [c0000000feab3270] [c0000000feab32d0] 0xc0000000feab32d0 (unreliable) [76563.914407] [c0000000feab3360] [c0000000009816f4] dev_hard_start_xmit+0x304/0x530 [76563.914415] [c0000000feab3440] [c0000000009b6564] sch_direct_xmit+0x124/0x330 [76563.914423] [c0000000feab34e0] [c000000000981ddc] __dev_queue_xmit+0x26c/0x770 [76563.914431] [c0000000feab3580] [c000000000a1efc0] arp_xmit+0x30/0xd0 [76563.914438] [c0000000feab35f0] [c000000000a1f0f4] arp_send_dst.part.0+0x94/0xb0 [76563.914445] [c0000000feab3660] [c000000000a1fcb4] arp_solicit+0x114/0x2b0 [76563.914452] [c0000000feab3730] [c00000000098d8f4] neigh_probe+0x84/0xd0 [76563.914460] [c0000000feab3760] [c0000000009937cc] neigh_timer_handler+0xbc/0x320 [76563.914468] [c0000000feab37a0] [c00000000014a3fc] call_timer_fn+0x5c/0x1c0 [76563.914474] [c0000000feab3830] [c00000000014a8bc] run_timer_softirq+0x31c/0x3f0 [76563.914483] [c0000000feab3900] [c0000000000bec58] __do_softirq+0x188/0x3e0 [76563.914490] [c0000000feab39f0] [c0000000000bf128] irq_exit+0xc8/0x100 [76563.914498] [c0000000feab3a10] [c00000000001f974] timer_interrupt+0xa4/0xe0 [76563.914505] [c0000000feab3a40] [c000000000002714] decrementer_common+0x114/0x180 [76563.914515] --- interrupt: 901 at plpar_hcall_norets+0x1c/0x28 [76563.914515] LR = check_and_cede_processor+0x34/0x50 [76563.914525] [c0000000feab3d30] [c000000000916bf0] check_and_cede_processor+0x20/0x50 (unreliable) [76563.914534] [c0000000feab3d90] [c000000000916e18] shared_cede_loop+0x68/0x170 [76563.914541] [c0000000feab3dd0] [c000000000913e20] cpuidle_enter_state+0x160/0x410 [76563.914549] [c0000000feab3e30] [c000000000119d48] call_cpuidle+0x78/0xd0 [76563.914556] [c0000000feab3e70] [c00000000011a11c] cpu_startup_entry+0x37c/0x480 [76563.914564] [c0000000feab3f30] [c00000000004563c] start_secondary+0x33c/0x360 [76563.914572] [c0000000feab3f90] [c000000000008b6c] start_secondary_prolog+0x10/0x14 [76563.914579] Instruction dump: [76563.914584] 4185024c 7cc400d0 7cd01120 78c60760 409f0014 88040000 38840001 98030000 [76563.914596] 38630001 409e0014 a0040000 38840002 <b0030000> 38630002 409d0014 80040000 [76563.914613] ---[ end trace 5382b3d78671418e ]--- [76563.916817] [76565.916870] Kernel panic - not syncing: Fatal exception in interrupt [76565.919468] ---[ end Kernel panic - not syncing: Fatal exception in interrupt Signed-off-by: Bryant G. Ly <bryantly(a)linux.vnet.ibm.com> Cc: <stable(a)vger.kernel.org> # 4.14+ --- drivers/net/ethernet/ibm/ibmveth.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/net/ethernet/ibm/ibmveth.c b/drivers/net/ethernet/ibm/ibmveth.c index f210398200ece..971ed54332d42 100644 --- a/drivers/net/ethernet/ibm/ibmveth.c +++ b/drivers/net/ethernet/ibm/ibmveth.c @@ -1092,8 +1092,14 @@ static netdev_tx_t ibmveth_start_xmit(struct sk_buff *skb, */ if (force_bounce || (!skb_is_nonlinear(skb) && (skb->len < tx_copybreak))) { - skb_copy_from_linear_data(skb, adapter->bounce_buffer, - skb->len); + if (adapter->bounce_buffer) { + skb_copy_from_linear_data(skb, adapter->bounce_buffer, + skb->len); + } else { + adapter->tx_send_failed++; + netdev->stats.tx_dropped++; + goto out; + } descs[0].fields.flags_len = desc_flags | skb->len; descs[0].fields.address = adapter->bounce_buffer_dma; @@ -1691,9 +1697,6 @@ static int ibmveth_probe(struct vio_dev *dev, const struct vio_device_id *id) netdev->features |= NETIF_F_FRAGLIST; } - netdev->min_mtu = IBMVETH_MIN_MTU; - netdev->max_mtu = ETH_MAX_MTU; - memcpy(netdev->dev_addr, mac_addr_p, ETH_ALEN); if (firmware_has_feature(FW_FEATURE_CMO)) -- 2.13.6 (Apple Git-96)

7 years, 7 months

2
2
0 0

[Linux-stable-mirror] [PATCH 1/2] drm/i915: Re-register PMIC bus access notifier on runtime resume

by Hans de Goede

intel_uncore_suspend() unregisters the uncore code's PMIC bus access notifier and gets called on both normal and runtime suspend. intel_uncore_resume_early() re-registers the notifier, but only on normal resume. Add a new intel_uncore_runtime_resume() function which only re-registers the notifier and call that on runtime resume. Cc: stable(a)vger.kernel.org Reported-by: Imre Deak <imre.deak(a)intel.com> Reviewed-by: Imre Deak <imre.deak(a)intel.com> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- drivers/gpu/drm/i915/i915_drv.c | 2 ++ drivers/gpu/drm/i915/intel_uncore.c | 6 ++++++ drivers/gpu/drm/i915/intel_uncore.h | 1 + 3 files changed, 9 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index e7e9e061073b..cdff9825a3da 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -2627,6 +2627,8 @@ static int intel_runtime_resume(struct device *kdev) ret = vlv_resume_prepare(dev_priv, true); } + intel_uncore_runtime_resume(dev_priv); + /* * No point of rolling back things in case of an error, as the best * we can do is to hope that things will still work (and disable RPM). diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c index dbc5cc309cbc..9567ba385f41 100644 --- a/drivers/gpu/drm/i915/intel_uncore.c +++ b/drivers/gpu/drm/i915/intel_uncore.c @@ -557,6 +557,12 @@ void intel_uncore_resume_early(struct drm_i915_private *dev_priv) i915_check_and_clear_faults(dev_priv); } +void intel_uncore_runtime_resume(struct drm_i915_private *dev_priv) +{ + iosf_mbi_register_pmic_bus_access_notifier( + &dev_priv->uncore.pmic_bus_access_nb); +} + void intel_uncore_sanitize(struct drm_i915_private *dev_priv) { i915_modparams.enable_rc6 = diff --git a/drivers/gpu/drm/i915/intel_uncore.h b/drivers/gpu/drm/i915/intel_uncore.h index 582771251b57..9ce079b5dd0d 100644 --- a/drivers/gpu/drm/i915/intel_uncore.h +++ b/drivers/gpu/drm/i915/intel_uncore.h @@ -134,6 +134,7 @@ bool intel_uncore_arm_unclaimed_mmio_detection(struct drm_i915_private *dev_priv void intel_uncore_fini(struct drm_i915_private *dev_priv); void intel_uncore_suspend(struct drm_i915_private *dev_priv); void intel_uncore_resume_early(struct drm_i915_private *dev_priv); +void intel_uncore_runtime_resume(struct drm_i915_private *dev_priv); u64 intel_uncore_edram_size(struct drm_i915_private *dev_priv); void assert_forcewakes_inactive(struct drm_i915_private *dev_priv); -- 2.14.3

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH 2/2] Drivers: hv: vmbus: Fix a rescind issue

by kys＠exchange.microsoft.com

From: K. Y. Srinivasan <kys(a)microsoft.com> The current rescind processing code will not correctly handle the case where the host immediately rescinds a channel that has been offerred. In this case, we could be blocked in the open call and since the channel is rescinded, the host will not respond and we could be blocked forever in the vmbus open call.i Fix this problem. Signed-off-by: K. Y. Srinivasan <kys(a)microsoft.com> Cc: stable(a)vger.kernel.org --- drivers/hv/channel.c | 10 ++++++++-- drivers/hv/channel_mgmt.c | 7 ++++--- include/linux/hyperv.h | 1 + 3 files changed, 13 insertions(+), 5 deletions(-) diff --git a/drivers/hv/channel.c b/drivers/hv/channel.c index 19f0cf3..ba0a092 100644 --- a/drivers/hv/channel.c +++ b/drivers/hv/channel.c @@ -659,22 +659,28 @@ void vmbus_close(struct vmbus_channel *channel) */ return; } - mutex_lock(&vmbus_connection.channel_mutex); /* * Close all the sub-channels first and then close the * primary channel. */ list_for_each_safe(cur, tmp, &channel->sc_list) { cur_channel = list_entry(cur, struct vmbus_channel, sc_list); - vmbus_close_internal(cur_channel); if (cur_channel->rescind) { + wait_for_completion(&cur_channel->rescind_event); + mutex_lock(&vmbus_connection.channel_mutex); + vmbus_close_internal(cur_channel); hv_process_channel_removal( cur_channel->offermsg.child_relid); + } else { + mutex_lock(&vmbus_connection.channel_mutex); + vmbus_close_internal(cur_channel); } + mutex_unlock(&vmbus_connection.channel_mutex); } /* * Now close the primary. */ + mutex_lock(&vmbus_connection.channel_mutex); vmbus_close_internal(channel); mutex_unlock(&vmbus_connection.channel_mutex); } diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c index ec5454f..c21020b 100644 --- a/drivers/hv/channel_mgmt.c +++ b/drivers/hv/channel_mgmt.c @@ -333,6 +333,7 @@ bool vmbus_prep_negotiate_resp(struct icmsg_hdr *icmsghdrp, return NULL; spin_lock_init(&channel->lock); + init_completion(&channel->rescind_event); INIT_LIST_HEAD(&channel->sc_list); INIT_LIST_HEAD(&channel->percpu_list); @@ -898,6 +899,7 @@ static void vmbus_onoffer_rescind(struct vmbus_channel_message_header *hdr) /* * Now wait for offer handling to complete. */ + vmbus_rescind_cleanup(channel); while (READ_ONCE(channel->probe_done) == false) { /* * We wait here until any channel offer is currently @@ -913,7 +915,6 @@ static void vmbus_onoffer_rescind(struct vmbus_channel_message_header *hdr) if (channel->device_obj) { if (channel->chn_rescind_callback) { channel->chn_rescind_callback(channel); - vmbus_rescind_cleanup(channel); return; } /* @@ -922,7 +923,6 @@ static void vmbus_onoffer_rescind(struct vmbus_channel_message_header *hdr) */ dev = get_device(&channel->device_obj->device); if (dev) { - vmbus_rescind_cleanup(channel); vmbus_device_unregister(channel->device_obj); put_device(dev); } @@ -936,13 +936,14 @@ static void vmbus_onoffer_rescind(struct vmbus_channel_message_header *hdr) * 2. Then close the primary channel. */ mutex_lock(&vmbus_connection.channel_mutex); - vmbus_rescind_cleanup(channel); if (channel->state == CHANNEL_OPEN_STATE) { /* * The channel is currently not open; * it is safe for us to cleanup the channel. */ hv_process_channel_removal(rescind->child_relid); + } else { + complete(&channel->rescind_event); } mutex_unlock(&vmbus_connection.channel_mutex); } diff --git a/include/linux/hyperv.h b/include/linux/hyperv.h index f3e97c5..6c93366 100644 --- a/include/linux/hyperv.h +++ b/include/linux/hyperv.h @@ -708,6 +708,7 @@ struct vmbus_channel { u8 monitor_bit; bool rescind; /* got rescind msg */ + struct completion rescind_event; u32 ringbuffer_gpadlhandle; -- 1.7.1

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH] net: mvneta: fix handling of the Tx descriptor counter

by Simon Guinot

The mvneta controller provides a 8-bit register to update the pending Tx descriptor counter. Then, a maximum of 255 Tx descriptors can be added at once. In the current code the mvneta_txq_pend_desc_add function assumes the caller takes care of this limit. But it is not the case. In some situations (xmit_more flag), more than 255 descriptors are added. When this happens, the Tx descriptor counter register is updated with a wrong value, which breaks the whole Tx queue management. This patch fixes the issue by allowing the mvneta_txq_pend_desc_add function to process more than 255 Tx descriptors. Fixes: 2a90f7e1d5d0 ("net: mvneta: add xmit_more support") Cc: stable(a)vger.kernel.org # 4.11+ Signed-off-by: Simon Guinot <simon.guinot(a)sequanux.org> --- drivers/net/ethernet/marvell/mvneta.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c index 64a04975bcf8..027c08ce4e5d 100644 --- a/drivers/net/ethernet/marvell/mvneta.c +++ b/drivers/net/ethernet/marvell/mvneta.c @@ -816,11 +816,14 @@ static void mvneta_txq_pend_desc_add(struct mvneta_port *pp, { u32 val; - /* Only 255 descriptors can be added at once ; Assume caller - * process TX desriptors in quanta less than 256 - */ - val = pend_desc + txq->pending; - mvreg_write(pp, MVNETA_TXQ_UPDATE_REG(txq->id), val); + pend_desc += txq->pending; + + /* Only 255 Tx descriptors can be added at once */ + while (pend_desc > 0) { + val = min(pend_desc, 255); + mvreg_write(pp, MVNETA_TXQ_UPDATE_REG(txq->id), val); + pend_desc -= val; + } txq->pending = 0; } @@ -2413,8 +2416,7 @@ static int mvneta_tx(struct sk_buff *skb, struct net_device *dev) if (txq->count >= txq->tx_stop_threshold) netif_tx_stop_queue(nq); - if (!skb->xmit_more || netif_xmit_stopped(nq) || - txq->pending + frags > MVNETA_TXQ_DEC_SENT_MASK) + if (!skb->xmit_more || netif_xmit_stopped(nq)) mvneta_txq_pend_desc_add(pp, txq, frags); else txq->pending += frags; -- 2.9.3

7 years, 7 months

3
4
0 0

[Linux-stable-mirror] [PATCH] net: dsa: lan9303: correctly check return value of devm_gpiod_get_optional

by Pan Bian

Function devm_gpiod_get_optional() returns an ERR_PTR on failure. Its return value should not be validated by a NULL check. Instead, use IS_ERR. Signed-off-by: Pan Bian <bianpan2016(a)163.com> --- drivers/net/dsa/lan9303-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/dsa/lan9303-core.c b/drivers/net/dsa/lan9303-core.c index b471413..6d3fc8f 100644 --- a/drivers/net/dsa/lan9303-core.c +++ b/drivers/net/dsa/lan9303-core.c @@ -828,7 +828,7 @@ static void lan9303_probe_reset_gpio(struct lan9303 *chip, chip->reset_gpio = devm_gpiod_get_optional(chip->dev, "reset", GPIOD_OUT_LOW); - if (!chip->reset_gpio) { + if (IS_ERR(chip->reset_gpio)) { dev_dbg(chip->dev, "No reset GPIO defined\n"); return; } -- 1.9.1

7 years, 7 months

4
4
0 0

[Linux-stable-mirror] [PATCH for-next 0/6] IB/hfi1, qib, cm, sa: Last set for 4.15 merge window

by Dennis Dalessandro

Hi Doug, Here is the latest set of patches I have that we'd like to land in 4.15. There are some driver fixes, including a qib that is marked as stable. We also have a CM and SA patch thrown in the mix. As always patches available for browsing at: https://github.com/ddalessa/kernel/tree/for-4.15 --- Dennis Dalessandro (1): IB/hfi1: Initialize bth1 in 16B rc ack builder Don Hiatt (2): IB/hfi1: Mask the path bits with the LMC for 16B RC Acks IB/CM: Change sgid to IB GID when handling CM request Jan Sokolowski (1): IB/hfi1: Use 4096 for default active MTU in query_qp Mike Marciniszyn (1): IB/qib: Fix comparison error with qperf compare/swap test Venkata Sandeep Dhanalakota (1): IB/SA: Check dlid before SA agent queries for ClassPortInfo drivers/infiniband/core/cm.c | 38 ++++++++++++++++++++++++++++++++++-- drivers/infiniband/core/sa_query.c | 10 +++++++++ drivers/infiniband/hw/hfi1/rc.c | 10 +++++---- drivers/infiniband/hw/hfi1/verbs.c | 2 +- drivers/infiniband/hw/qib/qib_rc.c | 6 +++--- 5 files changed, 55 insertions(+), 11 deletions(-) -- -Denny

7 years, 7 months

1
1
0 0

[Linux-stable-mirror] [PATCH] iwlwifi: fix firmware names for 9xxx and a0 series hw

by Thomas Backlund

iwlwifi 9xxx and a0 series hw contains an extra dash in firmware file name as seeen in modinfo output for kernel 4.14: firmware: iwlwifi-9260-th-b0-jf-b0--34.ucode firmware: iwlwifi-9260-th-a0-jf-a0--34.ucode firmware: iwlwifi-9000-pu-a0-jf-b0--34.ucode firmware: iwlwifi-9000-pu-a0-jf-a0--34.ucode firmware: iwlwifi-QuQnj-a0-hr-a0--34.ucode firmware: iwlwifi-QuQnj-a0-jf-b0--34.ucode firmware: iwlwifi-QuQnj-f0-hr-a0--34.ucode firmware: iwlwifi-Qu-a0-jf-b0--34.ucode firmware: iwlwifi-Qu-a0-hr-a0--34.ucode Fix that by dropping the extra adding of '"-"'. Signed-off-by: Thomas Backlund <tmb(a)mageia.org> cc: Luca Coelho <luciano.coelho(a)intel.com> cc: stable(a)vger.kernel.org --- drivers/net/wireless/intel/iwlwifi/cfg/9000.c | 8 ++++---- drivers/net/wireless/intel/iwlwifi/cfg/a000.c | 10 +++++----- 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/net/wireless/intel/iwlwifi/cfg/9000.c b/drivers/net/wireless/intel/iwlwifi/cfg/9000.c index e8b5ff42f5a8..0b3fe4971fc9 100644 --- a/drivers/net/wireless/intel/iwlwifi/cfg/9000.c +++ b/drivers/net/wireless/intel/iwlwifi/cfg/9000.c @@ -77,13 +77,13 @@ #define IWL9260A_FW_PRE "iwlwifi-9260-th-a0-jf-a0-" #define IWL9260B_FW_PRE "iwlwifi-9260-th-b0-jf-b0-" #define IWL9000_MODULE_FIRMWARE(api) \ - IWL9000_FW_PRE "-" __stringify(api) ".ucode" + IWL9000_FW_PRE __stringify(api) ".ucode" #define IWL9000RFB_MODULE_FIRMWARE(api) \ - IWL9000RFB_FW_PRE "-" __stringify(api) ".ucode" + IWL9000RFB_FW_PRE __stringify(api) ".ucode" #define IWL9260A_MODULE_FIRMWARE(api) \ - IWL9260A_FW_PRE "-" __stringify(api) ".ucode" + IWL9260A_FW_PRE __stringify(api) ".ucode" #define IWL9260B_MODULE_FIRMWARE(api) \ - IWL9260B_FW_PRE "-" __stringify(api) ".ucode" + IWL9260B_FW_PRE __stringify(api) ".ucode" #define NVM_HW_SECTION_NUM_FAMILY_9000 10 diff --git a/drivers/net/wireless/intel/iwlwifi/cfg/a000.c b/drivers/net/wireless/intel/iwlwifi/cfg/a000.c index a440140ed8dd..7eade165b747 100644 --- a/drivers/net/wireless/intel/iwlwifi/cfg/a000.c +++ b/drivers/net/wireless/intel/iwlwifi/cfg/a000.c @@ -80,15 +80,15 @@ #define IWL_A000_HR_A0_FW_PRE "iwlwifi-QuQnj-a0-hr-a0-" #define IWL_A000_HR_MODULE_FIRMWARE(api) \ - IWL_A000_HR_FW_PRE "-" __stringify(api) ".ucode" + IWL_A000_HR_FW_PRE __stringify(api) ".ucode" #define IWL_A000_JF_MODULE_FIRMWARE(api) \ - IWL_A000_JF_FW_PRE "-" __stringify(api) ".ucode" + IWL_A000_JF_FW_PRE __stringify(api) ".ucode" #define IWL_A000_HR_F0_QNJ_MODULE_FIRMWARE(api) \ - IWL_A000_HR_F0_FW_PRE "-" __stringify(api) ".ucode" + IWL_A000_HR_F0_FW_PRE __stringify(api) ".ucode" #define IWL_A000_JF_B0_QNJ_MODULE_FIRMWARE(api) \ - IWL_A000_JF_B0_FW_PRE "-" __stringify(api) ".ucode" + IWL_A000_JF_B0_FW_PRE __stringify(api) ".ucode" #define IWL_A000_HR_A0_QNJ_MODULE_FIRMWARE(api) \ - IWL_A000_HR_A0_FW_PRE "-" __stringify(api) ".ucode" + IWL_A000_HR_A0_FW_PRE __stringify(api) ".ucode" #define NVM_HW_SECTION_NUM_FAMILY_A000 10 -- 2.14.3

7 years, 7 months

4
5
0 0

Re: [Linux-stable-mirror] [v2] cpufreq: powernv: Fix the frequency read by /proc/cpuinfo

by Michael Ellerman

On Fri, 2017-10-13 at 04:36:41 UTC, Shriya wrote: > The call to /proc/cpuinfo in turn calls cpufreq_quick_get() which > returns the last frequency requested by the kernel, but may not > reflect the actual frequency the processor is running at. > This patch makes a call to cpufreq_get() instead which returns the > current frequency reported by the hardware. > > Fixes : commit fb5153d05a7d ("powerpc: powernv: Implement > ppc_md.get_proc_freq()") > Cc: stable(a)vger.kernel.org > > Signed-off-by: Shriya <shriyak(a)linux.vnet.ibm.com> Applied to powerpc next, thanks. https://git.kernel.org/powerpc/c/cd77b5ce208c153260ed7882d8910f cheers

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH] watchdog: indydog: Add dependency on SGI_HAS_INDYDOG

by Matt Redfearn

Commit da2a68b3eb47 ("watchdog: Enable COMPILE_TEST where possible") enabled building the Indy watchdog driver when COMPILE_TEST is enabled. However, the driver makes reference to symbols that are only defined for certain platforms are selected in the config. These platforms select SGI_HAS_INDYDOG. Without this, link time errors result, for example when building a MIPS allyesconfig. drivers/watchdog/indydog.o: In function `indydog_write': indydog.c:(.text+0x18): undefined reference to `sgimc' indydog.c:(.text+0x1c): undefined reference to `sgimc' drivers/watchdog/indydog.o: In function `indydog_start': indydog.c:(.text+0x54): undefined reference to `sgimc' indydog.c:(.text+0x58): undefined reference to `sgimc' drivers/watchdog/indydog.o: In function `indydog_stop': indydog.c:(.text+0xa4): undefined reference to `sgimc' drivers/watchdog/indydog.o:indydog.c:(.text+0xa8): more undefined references to `sgimc' follow make: *** [Makefile:1005: vmlinux] Error 1 Fix this by ensuring that CONFIG_INDIDOG can only be selected when the necessary dependent platform symbols are built in. Fixes: da2a68b3eb47 ("watchdog: Enable COMPILE_TEST where possible") Signed-off-by: Matt Redfearn <matt.redfearn(a)mips.com> Cc: <stable(a)vger.kernel.org> # 4.11 + --- drivers/watchdog/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index ca200d1f310a..d96e2e7544fc 100644 --- a/drivers/watchdog/Kconfig +++ b/drivers/watchdog/Kconfig @@ -1451,7 +1451,7 @@ config RC32434_WDT config INDYDOG tristate "Indy/I2 Hardware Watchdog" - depends on SGI_HAS_INDYDOG || (MIPS && COMPILE_TEST) + depends on SGI_HAS_INDYDOG || (MIPS && COMPILE_TEST && SGI_HAS_INDYDOG) help Hardware driver for the Indy's/I2's watchdog. This is a watchdog timer that will reboot the machine after a 60 second -- 2.7.4

7 years, 7 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH 4.13 00/33] 4.13.13-stable review

by Greg Kroah-Hartman

On Mon, Nov 13, 2017 at 02:02:12PM -0800, kernelci.org bot wrote: > stable-rc/linux-4.13.y boot: 127 boots: 10 failed, 116 passed with 1 conflict (v4.13.12-34-g109b28ca1340) > > Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.13.y/kernel/v4.1… > Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.13.y/kernel/v4.13.12-34… > > Tree: stable-rc > Branch: linux-4.13.y > Git Describe: v4.13.12-34-g109b28ca1340 > Git Commit: 109b28ca1340961002d4bede168f07823451b8e4 > Git URL: http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git > Tested: 51 unique boards, 17 SoC families, 18 builds out of 188 > > Boot Regressions Detected: > > arm: > > at91_dt_defconfig: > at91rm9200ek_rootfs:nfs: > lab-free-electrons: new failure (last pass: v4.13.12) > > exynos_defconfig: > exynos4412-odroidx2_rootfs:nfs: > lab-collabora: failing since 4 days (last pass: v4.13.11-37-g2295c8345797 - first fail: v4.13.12) > exynos5250-snow_rootfs:nfs: > lab-collabora: failing since 4 days (last pass: v4.13.11-37-g2295c8345797 - first fail: v4.13.12) Thanks for these "failing since..." markings, that makes me feel better that I didn't break anything on my end :) greg k-h

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] brcmfmac: remove setting IBSS mode when stopping AP

by Philipp Rosenberger

Hi, commit 9029679f66d976f8c720eb03c4898274803c9923 upstream. the patch "brcmfmac: remove setting IBSS mode when stopping AP" fixes a recurring warning[1] when we run our wifi in AP mode after we stopped an AP on the same card. We are using the 4.9 stable tree. But every kernel < 4.13 and >= 3.9 is affected by this problem. Best regards Philipp [1] The warning message with backtrace: [ 517.577475] brcmfmac: brcmf_update_bss_info: wl dtim_assoc failed (-23) [ 517.584567] ------------[ cut here ]------------ [ 517.594906] WARNING: CPU: 0 PID: 963 at /home/ilu/src/linux/net/wireless/sme.c:738 __cfg80211_connect_result+0x2dc/0x400 [cfg80211] [ 517.610126] Modules linked in: brcmfmac brcmutil cfg80211 [ 517.615752] CPU: 0 PID: 963 Comm: kworker/u2:2 Tainted: G W 4.9.56-sde-00010-g3b9115e #18 [ 517.627723] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree) [ 517.634647] Workqueue: cfg80211 cfg80211_event_work [cfg80211] [ 517.642070] [<c010f270>] (unwind_backtrace) from [<c010c4f0>] (show_stack+0x10/0x14) [ 517.652696] [<c010c4f0>] (show_stack) from [<c011cab4>] (__warn+0xe8/0x100) [ 517.661193] [<c011cab4>] (__warn) from [<c011cb7c>] (warn_slowpath_null+0x20/0x28) [ 517.670507] [<c011cb7c>] (warn_slowpath_null) from [<bf02f6a4>] (__cfg80211_connect_result+0x2dc/0x400 [cfg80211]) [ 517.682888] [<bf02f6a4>] (__cfg80211_connect_result [cfg80211]) from [<bf00564c>] (cfg80211_process_wdev_events+0x178/0x1f8 [cfg80211]) [ 517.696985] [<bf00564c>] (cfg80211_process_wdev_events [cfg80211]) from [<bf0056f8>] (cfg80211_process_rdev_events+0x2c/0x60 [cfg80211]) [ 517.711110] [<bf0056f8>] (cfg80211_process_rdev_events [cfg80211]) from [<bf00027c>] (cfg80211_event_work+0x14/0x1c [cfg80211]) [ 517.724539] [<bf00027c>] (cfg80211_event_work [cfg80211]) from [<c01358cc>] (process_one_work+0x12c/0x518) [ 517.735875] [<c01358cc>] (process_one_work) from [<c0135cf0>] (worker_thread+0x38/0x5d8) [ 517.745234] [<c0135cf0>] (worker_thread) from [<c013b32c>] (kthread+0xf0/0x108) [ 517.754090] [<c013b32c>] (kthread) from [<c0108498>] (ret_from_fork+0x14/0x3c) [ 517.762967] ---[ end trace f68728a0d3053b54 ]--- [ 517.770431] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

7 years, 7 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH 1/2] arm64: mm: abort uaccess retries upon fatal signal

by Rabin Vincent

On Tue, Aug 22, 2017 at 10:45:24AM +0100, Will Deacon wrote: > On Mon, Aug 21, 2017 at 02:42:03PM +0100, Mark Rutland wrote: > > On Tue, Jul 11, 2017 at 03:58:49PM +0100, Will Deacon wrote: > > > On Tue, Jul 11, 2017 at 03:19:22PM +0100, Mark Rutland wrote: > > > > When there's a fatal signal pending, arm64's do_page_fault() > > > > implementation returns 0. The intent is that we'll return to the > > > > faulting userspace instruction, delivering the signal on the way. > > > > > > > > However, if we take a fatal signal during fixing up a uaccess, this > > > > results in a return to the faulting kernel instruction, which will be > > > > instantly retried, resulting in the same fault being taken forever. As > > > > the task never reaches userspace, the signal is not delivered, and the > > > > task is left unkillable. While the task is stuck in this state, it can > > > > inhibit the forward progress of the system. > > > > > > > > To avoid this, we must ensure that when a fatal signal is pending, we > > > > apply any necessary fixup for a faulting kernel instruction. Thus we > > > > will return to an error path, and it is up to that code to make forward > > > > progress towards delivering the fatal signal. > > > > > > > > Signed-off-by: Mark Rutland <mark.rutland(a)arm.com> > > > > Reviewed-by: Steve Capper <steve.capper(a)arm.com> > > > > Tested-by: Steve Capper <steve.capper(a)arm.com> > > > > Cc: Catalin Marinas <catalin.marinas(a)arm.com> > > > > Cc: James Morse <james.morse(a)arm.com> > > > > Cc: Laura Abbott <labbott(a)redhat.com> > > > > Cc: Will Deacon <will.deacon(a)arm.com> > > > > Cc: stable(a)vger.kernel.org > > > > --- > > > > arch/arm64/mm/fault.c | 5 ++++- > > > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > > > > > > diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c > > > > index 37b95df..3952d5e 100644 > > > > --- a/arch/arm64/mm/fault.c > > > > +++ b/arch/arm64/mm/fault.c > > > > @@ -397,8 +397,11 @@ static int __kprobes do_page_fault(unsigned long addr, unsigned int esr, > > > > * signal first. We do not need to release the mmap_sem because it > > > > * would already be released in __lock_page_or_retry in mm/filemap.c. > > > > */ > > > > - if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current)) > > > > + if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current)) { > > > > + if (!user_mode(regs)) > > > > + goto no_context; > > > > return 0; > > > > + } > > > > > > This will need rebasing at -rc1 (take a look at current HEAD). > > > > > > Also, I think it introduces a weird corner case where we take a page fault > > > when writing the signal frame to the user stack to deliver a SIGSEGV. If > > > we end up with VM_FAULT_RETRY and somebody has sent a SIGKILL to the task, > > > then we'll fail setup_sigframe and force an un-handleable SIGSEGV instead > > > of SIGKILL. > > > > > > The end result (task is killed) is the same, but the fatal signal is wrong. > > > > That doesn't seem to be the case, testing on v4.13-rc5. > > > > I used sigaltstack() to use the userfaultfd region as signal stack, > > registerd a SIGSEGV handler, and dereferenced NULL. The task locks up, > > but when killed with a SIGINT or SIGKILL, the exit status reflects that > > signal, rather than the SIGSEGV. > > > > If I move the SIGINT handler onto the userfaultfd-monitored stack, then > > delivering SIGINT hangs, but can be killed with SIGKILL, and the exit > > status reflects that SIGKILL. > > > > As you say, it does look like we'd try to set up a deferred SIGSEGV for > > the failed signal delivery. > > > > I haven't yet figured out exactly how that works; I'll keep digging. > > The SEGV makes it all the way into do_group_exit, but then signal_group_exit > is set and the exit_code is overridden with SIGKILL at the last minute (see > complete_signal). Unfortunately, this last minute is too late for print-fatal-signals. With print-fatal-signals enabled, this patch leads to misleading "potentially unexpected fatal signal 11" warnings if a process is SIGKILL'd at the right time. I've seen it without userfaultfd, but it's easiest reproduced by patching Mark's original test code [1] with the following patch and simply running "pkill -WINCH foo; pkill -KILL foo". This results in: foo: potentially unexpected fatal signal 11. CPU: 1 PID: 1793 Comm: foo Not tainted 4.9.58-devel #3 task: b3534780 task.stack: b4b7c000 PC is at 0x76effb60 LR is at 0x4227f4 pc : [<76effb60>] lr : [<004227f4>] psr: 600b0010 sp : 7eaf7bb4 ip : 00000000 fp : 00000000 r10: 00000001 r9 : 00000003 r8 : 76fcd000 r7 : 0000001d r6 : 76fd0cf0 r5 : 7eaf7c08 r4 : 00000000 r3 : 00000000 r2 : 00000000 r1 : 7eaf7a88 r0 : fffffffc Flags: nZCv IRQs on FIQs on Mode USER_32 ISA ARM Segment user Control: 10c5387d Table: 3357404a DAC: 00000055 CPU: 1 PID: 1793 Comm: foo Not tainted 4.9.58-devel #3 [<801113f0>] (unwind_backtrace) from [<8010cfb0>] (show_stack+0x18/0x1c) [<8010cfb0>] (show_stack) from [<8039725c>] (dump_stack+0x84/0x98) [<8039725c>] (dump_stack) from [<8012f448>] (get_signal+0x384/0x684) [<8012f448>] (get_signal) from [<8010c2ec>] (do_signal+0xcc/0x470) [<8010c2ec>] (do_signal) from [<8010c868>] (do_work_pending+0xb8/0xc8) [<8010c868>] (do_work_pending) from [<801086d4>] (slow_work_pending+0xc/0x20) This is ARM and I haven't tested ARM64, but the same problem even exists on x86. --- foo.c.orig 2017-11-13 23:45:47.802167284 +0100 +++ foo.c 2017-11-14 07:16:13.906363466 +0100 @@ -6,6 +6,11 @@ #include <sys/syscall.h> #include <sys/vfs.h> #include <unistd.h> +#include <signal.h> + +static void handler(int sig) +{ +} int main(int argc, char *argv[]) { @@ -47,13 +52,17 @@ if (ret < 0) return errno; + sigaltstack(&(stack_t){.ss_sp = mem, .ss_size = pagesz}, NULL); + sigaction(SIGWINCH, &(struct sigaction){ .sa_handler = handler, .sa_flags = SA_ONSTACK, }, NULL); + /* * Force an arbitrary uaccess to memory monitored by the userfaultfd. * This will block, but when a SIGKILL is sent, will consume all * available CPU time without being killed, and may inhibit forward * progress of the system. */ - ret = fstatfs(0, (struct statfs *)mem); + // ret = fstatfs(0, (struct statfs *)mem); + pause(); return 0; } [1] https://lkml.kernel.org/r/1499782590-31366-1-git-send-email-mark.rutland@ar…

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH 1/2] drm/i915: Fix vblank timestamp/frame counter jumps on gen2

by Ville Syrjala

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Previously I was under the impression that the scanline counter reads 0 when the pipe is off. Turns out that's not correct, and instead the scanline counter simply stops when the pipe stops, and it retains it's last value until the pipe starts up again, at which point the scanline counter jumps to vblank start. These jumps can cause the timestamp to jump backwards by one frame. Since we use the timestamps to guesstimage also the frame counter value on gen2, that would cause the frame counter to also jump backwards, which leads to a massice difference from the previous value. The end result is that flips/vblank events don't appear to complete as they're stuck waiting for the frame counter to catch up to that massive difference. Fix the problem properly by actually making sure the scanline counter has started to move before we assume that it's safe to enable vblank processing. Cc: stable(a)vger.kernel.org Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Fixes: b7792d8b54cc ("drm/i915: Wait for pipe to start before sampling vblank timestamps on gen2") Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> --- drivers/gpu/drm/i915/intel_display.c | 34 ++++++++++++++++++++++------------ 1 file changed, 22 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 0ebf3f283b87..810b1147a0ac 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -998,7 +998,8 @@ enum transcoder intel_pipe_to_cpu_transcoder(struct drm_i915_private *dev_priv, return crtc->config->cpu_transcoder; } -static bool pipe_dsl_stopped(struct drm_i915_private *dev_priv, enum pipe pipe) +static bool pipe_dsl_stopped(struct drm_i915_private *dev_priv, + enum pipe pipe, bool stopped) { i915_reg_t reg = PIPEDSL(pipe); u32 line1, line2; @@ -1013,7 +1014,7 @@ static bool pipe_dsl_stopped(struct drm_i915_private *dev_priv, enum pipe pipe) msleep(5); line2 = I915_READ(reg) & line_mask; - return line1 == line2; + return (line1 == line2) == stopped; } /* @@ -1048,11 +1049,21 @@ static void intel_wait_for_pipe_off(struct intel_crtc *crtc) WARN(1, "pipe_off wait timed out\n"); } else { /* Wait for the display line to settle */ - if (wait_for(pipe_dsl_stopped(dev_priv, pipe), 100)) + if (wait_for(pipe_dsl_stopped(dev_priv, pipe, true), 100)) WARN(1, "pipe_off wait timed out\n"); } } +static void intel_wait_for_pipe_on(struct intel_crtc *crtc) +{ + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); + enum pipe pipe = crtc->pipe; + + /* Wait for the display line to start moving */ + if (wait_for(pipe_dsl_stopped(dev_priv, pipe, false), 100)) + WARN(1, "pipe_on wait timed out\n"); +} + /* Only for pre-ILK configs */ void assert_pll(struct drm_i915_private *dev_priv, enum pipe pipe, bool state) @@ -1935,15 +1946,14 @@ static void intel_enable_pipe(struct intel_crtc *crtc) POSTING_READ(reg); /* - * Until the pipe starts DSL will read as 0, which would cause - * an apparent vblank timestamp jump, which messes up also the - * frame count when it's derived from the timestamps. So let's - * wait for the pipe to start properly before we call - * drm_crtc_vblank_on() + * Until the pipe starts DSL can give a bogus value, which cause + * an apparent vblank timestamp jump when the DSL resets to its + * proper value, which messes up also the frame count when it's + * derived from the timestamps. So let's wait for the pipe to + * start properly before we call drm_crtc_vblank_on() */ - if (dev->max_vblank_count == 0 && - wait_for(intel_get_crtc_scanline(crtc) != crtc->scanline_offset, 50)) - DRM_ERROR("pipe %c didn't start\n", pipe_name(pipe)); + if (dev->max_vblank_count == 0) + intel_wait_for_pipe_on(crtc); } /** @@ -14707,7 +14717,7 @@ void i830_disable_pipe(struct drm_i915_private *dev_priv, enum pipe pipe) I915_WRITE(PIPECONF(pipe), 0); POSTING_READ(PIPECONF(pipe)); - if (wait_for(pipe_dsl_stopped(dev_priv, pipe), 100)) + if (wait_for(pipe_dsl_stopped(dev_priv, pipe, true), 100)) DRM_ERROR("pipe %c off wait timed out\n", pipe_name(pipe)); I915_WRITE(DPLL(pipe), DPLL_VGA_MODE_DIS); -- 2.13.6

7 years, 7 months

3
2
0 0

Re: [Linux-stable-mirror] [PATCH 4.4 34/46] crypto: xts - Add ECB dependency

by Ben Hutchings

On Thu, 2017-10-19 at 15:49 +0200, Greg Kroah-Hartman wrote: > 4.4-stable review patch. If anyone has any objections, please let me > know. > > ------------------ > > From: Milan Broz <gmazyland(a)gmail.com> > > > [ Upstream commit 12cb3a1c4184f891d965d1f39f8cfcc9ef617647 ] > > Since the > commit f1c131b45410a202eb45cc55980a7a9e4e4b4f40 > crypto: xts - Convert to skcipher That commit went into 4.10, and not any stable branches. So this fix doesn't appear to be appropriate for the older branches it was applied to. Ben. > the XTS mode is based on ECB, so the mode must select > ECB otherwise it can fail to initialize. > > Signed-off-by: Milan Broz <gmazyland(a)gmail.com> > Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> > Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> > Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> > --- > crypto/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > --- a/crypto/Kconfig > +++ b/crypto/Kconfig > @@ -343,6 +343,7 @@ config CRYPTO_XTS > select CRYPTO_BLKCIPHER > select CRYPTO_MANAGER > select CRYPTO_GF128MUL > + select CRYPTO_ECB > help > XTS: IEEE1619/D16 narrow block cipher use with aes-xts- > plain, > key size 256, 384 or 512 bits. This implementation > currently > > > -- Ben Hutchings Software Developer, Codethink Ltd.

7 years, 7 months

2
1
0 0

Re: [Linux-stable-mirror] [PATCH 4.4 41/46] uapi: fix linux/rds.h userspace compilation errors

by Ben Hutchings

On Thu, 2017-10-19 at 15:49 +0200, Greg Kroah-Hartman wrote: > 4.4-stable review patch. If anyone has any objections, please let me know. > > ------------------ > > From: "Dmitry V. Levin" <ldv(a)altlinux.org> > > > [ Upstream commit feb0869d90e51ce8b6fd8a46588465b1b5a26d09 ] > > Consistently use types from linux/types.h to fix the following > linux/rds.h userspace compilation errors: [...] > --- a/include/uapi/linux/rds.h > +++ b/include/uapi/linux/rds.h > @@ -35,6 +35,7 @@ > #define _LINUX_RDS_H > > #include <linux/types.h> > +#include <linux/socket.h> /* For __kernel_sockaddr_storage. */ > > #define RDS_IB_ABI_VERSION 0x301 > > @@ -223,7 +224,7 @@ struct rds_get_mr_args { > }; > > struct rds_get_mr_for_dest_args { > - struct sockaddr_storage dest_addr; > + struct __kernel_sockaddr_storage dest_addr; > struct rds_iovec vec; > uint64_t cookie_addr; > uint64_t flags; This is a valid fix but not the one that the commit message and upstream commit hash refer to. This diff matches: commit 1786dbf3702e33ce3afd2d3dbe630bd04b1d2e58 Author: Dmitry V. Levin <ldv(a)altlinux.org> Date: Thu Feb 16 18:05:45 2017 +0300 uapi: fix linux/rds.h userspace compilation error which has almost the same subject line. Maybe you should cherry-pick commit feb0869d90e51ce8b6fd8a46588465b1b5a26d09 for real as well (in all branches). Ben. -- Ben Hutchings Software Developer, Codethink Ltd.

7 years, 7 months

2
1
0 0

[Linux-stable-mirror] [PATCH] arm64: dts: marvell: mark the cp110 crypto engine as dma coherent

by Antoine Tenart

commit ec0aef9881d18aa781268ec9cba8eba5b202f5b4 upstream. The crypto engines found on the cp110 master and slave are dma coherent. This patch adds the relevant property to their dt nodes. Cc: stable(a)vger.kernel.org # v4.12+ Fixes: 973020fd9498 ("arm64: marvell: dts: add crypto engine description for 7k/8k") Signed-off-by: Antoine Tenart <antoine.tenart(a)free-electrons.com> Signed-off-by: Gregory CLEMENT <gregory.clement(a)free-electrons.com> Signed-off-by: Antoine Tenart <antoine.tenart(a)free-electrons.com> --- Hi, This patch did not apply to the 4.12-stable tree. Since the original patch made it to Linus tree, this is a version which applies nicely to the 4.12-stable tree. Thanks, Antoine arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi | 1 + arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi | 1 + 2 files changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi index b4bc42ece754..4e81130ae84a 100644 --- a/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi +++ b/arch/arm64/boot/dts/marvell/armada-cp110-master.dtsi @@ -240,6 +240,7 @@ interrupt-names = "mem", "ring0", "ring1", "ring2", "ring3", "eip"; clocks = <&cpm_syscon0 1 26>; + dma-coherent; status = "disabled"; }; }; diff --git a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi index 6e2058847ddc..b987565107f3 100644 --- a/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi +++ b/arch/arm64/boot/dts/marvell/armada-cp110-slave.dtsi @@ -230,6 +230,7 @@ interrupt-names = "mem", "ring0", "ring1", "ring2", "ring3", "eip"; clocks = <&cps_syscon0 1 26>; + dma-coherent; status = "disabled"; }; }; -- 2.14.3

7 years, 7 months

2
3
0 0

[Linux-stable-mirror] v4.14 build: 0 failures 0 warnings (v4.14)

by Build bot for Mark Brown

Tree/Branch: v4.14 Git describe: v4.14 Commit: bebc6082da Linux 4.14 Build Time: 97 min 53 sec Passed: 10 / 10 (100.00 %) Failed: 0 / 10 ( 0.00 %) Errors: 0 Warnings: 0 Section Mismatches: 0 ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): ------------------------------------------------------------------------------- =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches: arm64-allnoconfig arm64-allmodconfig arm-multi_v5_defconfig arm-multi_v7_defconfig x86_64-defconfig arm-allmodconfig arm-allnoconfig x86_64-allnoconfig arm-multi_v4t_defconfig arm64-defconfig close failed in file object destructor: sys.excepthook is missing lost sys.stderr

7 years, 7 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH] net: mvneta: fix handling of the Tx descriptor counter

by David Miller

From: Simon Guinot <simon.guinot(a)sequanux.org> Date: Mon, 13 Nov 2017 15:51:15 +0100 > IIUC the driver stops the queue if a threshold of 316 Tx descriptors is > reached (default and worst value). That's a lot of latency.

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH 4.13 00/33] 4.13.13-stable review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 4.13.13 release. There are 33 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 Nov 15 12:55:46 UTC 2017. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.13.13-rc1.gz or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.13.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.13.13-rc1 Borislav Petkov <bp(a)suse.de> x86/oprofile/ppro: Do not use __this_cpu*() in preemptible context Pavel Tatashin <pasha.tatashin(a)oracle.com> x86/smpboot: Make optimization of delay calibration work correctly Alexander Shishkin <alexander.shishkin(a)linux.intel.com> x86/debug: Handle warnings before the notifier chain, to fix KGDB crash Richard Schütz <rschuetz(a)uni-koblenz.de> can: c_can: don't indicate triple sampling support for D_CAN Marek Vasut <marex(a)denx.de> can: ifi: Fix transmitter delay calculation Stephane Grosjean <s.grosjean(a)peak-system.com> can: peak: Add support for new PCIe/M2 CAN FD interfaces Gerhard Bertelsmann <info(a)gerhard-bertelsmann.de> can: sun4i: handle overrun in RX FIFO Linus Torvalds <torvalds(a)linux-foundation.org> Revert "x86: CPU: Fix up "cpu MHz" in /proc/cpuinfo" Sinclair Yeh <syeh(a)vmware.com> drm/vmwgfx: Fix Ubuntu 17.10 Wayland black screen issue Ilya Dryomov <idryomov(a)gmail.com> rbd: use GFP_NOIO for parent stat and data requests Kai-Heng Feng <kai.heng.feng(a)canonical.com> Input: elan_i2c - add ELAN060C to the ACPI table Paul Mackerras <paulus(a)ozlabs.org> KVM: PPC: Book3S HV: Fix exclusion between HPT resizing and other HPT updates Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de> MIPS: AR7: Ensure that serial ports are properly set up Jonas Gorski <jonas.gorski(a)gmail.com> MIPS: AR7: Defer registration of GPIO Jaedon Shin <jaedon.shin(a)gmail.com> MIPS: BMIPS: Fix missing cbr address Paul Burton <paul.burton(a)mips.com> MIPS: Fix CM region target definitions Takashi Iwai <tiwai(a)suse.de> ALSA: seq: Avoid invalid lockdep class warning Takashi Iwai <tiwai(a)suse.de> ALSA: seq: Fix OSS sysex delivery in OSS emulation Hui Wang <hui.wang(a)canonical.com> ALSA: hda - fix headset mic problem for Dell machines with alc274 Jussi Laako <jussi(a)sonarnerd.net> ALSA: usb-audio: support new Amanero Combo384 firmware version Takashi Iwai <tiwai(a)suse.de> ALSA: timer: Limit max instances per timer Mark Rutland <mark.rutland(a)arm.com> ARM: 8720/1: ensure dump_instr() checks addr_limit Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> ACPI / scan: Enable GPEs before scanning the namespace Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> ACPICA: Make it possible to enable runtime GPEs earlier Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> ACPICA: Dispatch active GPEs at init time Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> ACPI / PM: Blacklist Low Power S0 Idle _DSM for Dell XPS13 9360 Eric Biggers <ebiggers(a)google.com> KEYS: fix NULL pointer dereference during ASN.1 parsing [ver #2] Andrey Ryabinin <aryabinin(a)virtuozzo.com> crypto: x86/sha256-mb - fix panic due to unaligned access Andrey Ryabinin <aryabinin(a)virtuozzo.com> crypto: x86/sha1-mb - fix panic due to unaligned access Romain Izard <romain.izard.pro(a)gmail.com> crypto: ccm - preserve the IV buffer Li Bin <huawei.libin(a)huawei.com> workqueue: Fix NULL pointer dereference Anatole Denis <anatole(a)rezel.net> netfilter: nft_set_hash: disable fast_ops for 2-len keys Florian Westphal <fw(a)strlen.de> netfilter: nat: Revert "netfilter: nat: convert nat bysrc hash to rhashtable" ------------- Diffstat: Makefile | 4 +- arch/arm/kernel/traps.c | 28 +++-- arch/mips/ar7/platform.c | 5 + arch/mips/ar7/prom.c | 2 - arch/mips/include/asm/mips-cm.h | 4 +- arch/mips/kernel/smp-bmips.c | 4 +- arch/powerpc/kvm/book3s_64_mmu_hv.c | 10 ++ arch/powerpc/kvm/book3s_hv.c | 29 +++-- arch/x86/crypto/sha1-mb/sha1_mb_mgr_flush_avx2.S | 12 +- .../crypto/sha256-mb/sha256_mb_mgr_flush_avx2.S | 12 +- arch/x86/kernel/cpu/Makefile | 2 +- arch/x86/kernel/cpu/aperfmperf.c | 11 +- arch/x86/kernel/cpu/proc.c | 4 +- arch/x86/kernel/smpboot.c | 11 +- arch/x86/kernel/traps.c | 10 +- arch/x86/kernel/tsc.c | 8 +- arch/x86/oprofile/op_model_ppro.c | 4 +- crypto/ccm.c | 4 +- drivers/acpi/acpica/evgpeblk.c | 30 +++-- drivers/acpi/acpica/evxfgpe.c | 8 ++ drivers/acpi/scan.c | 6 +- drivers/acpi/sleep.c | 28 +++++ drivers/block/rbd.c | 4 +- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +- drivers/input/mouse/elan_i2c_core.c | 1 + drivers/net/can/c_can/c_can_pci.c | 1 - drivers/net/can/c_can/c_can_platform.c | 1 - drivers/net/can/ifi_canfd/ifi_canfd.c | 6 +- drivers/net/can/peak_canfd/peak_pciefd_main.c | 14 ++- drivers/net/can/sun4i_can.c | 12 +- include/acpi/actypes.h | 3 +- include/net/netfilter/nf_conntrack.h | 3 +- include/net/netfilter/nf_nat.h | 1 - include/sound/seq_kernel.h | 3 +- include/sound/timer.h | 2 + kernel/workqueue_internal.h | 3 +- lib/asn1_decoder.c | 4 +- net/netfilter/nf_nat_core.c | 130 +++++++++------------ net/netfilter/nft_set_hash.c | 1 - sound/core/hrtimer.c | 1 + sound/core/seq/oss/seq_oss_midi.c | 4 +- sound/core/seq/oss/seq_oss_readq.c | 29 +++++ sound/core/seq/oss/seq_oss_readq.h | 2 + sound/core/timer.c | 67 ++++++++--- sound/pci/hda/patch_realtek.c | 5 + sound/usb/quirks.c | 1 + 46 files changed, 343 insertions(+), 193 deletions(-)

7 years, 7 months

3
34
0 0

Re: [Linux-stable-mirror] Patch "ASoC: sunxi: Add bindings for sun8i to SPDIF" has been added to the 4.9-stable tree

by alexander.levin＠verizon.com

On Fri, Nov 10, 2017 at 04:44:00PM +0000, Mark Brown wrote: >On Fri, Nov 10, 2017 at 05:36:32PM +0100, gregkh(a)linuxfoundation.org wrote: >> On Fri, Nov 10, 2017 at 04:04:22PM +0000, alexander.levin(a)verizon.com wrote: > >> > - 96e53c41e1f81c9e9d1ce38d3f28b95668b71dcf - just dead code removal, >> > avoids conflicts later. > >> This commit claims the hardware is now supported by a different driver. >> Is that support in 4.9? I couldn't figure it out :( >From what I can tell its that way since 3.11. >I suspect this isn't worth the effort - it's defintely more than a >simple quirk anyway. But as Mark points out, this is getting a bit too complicated and risky. -- Thanks, Sasha

7 years, 7 months

2
1
0 0

Re: [Linux-stable-mirror] Request for stable 4.13.x inclusion: netfilter: nft_set_hash: disable fast_ops for 2-len keys

by Pablo Neira Ayuso

On Fri, Nov 10, 2017 at 12:56:46PM +0100, Thomas Deutschmann wrote: > Hi, > > please consider to add > > > From 0414c78f14861cb704d6e6888efd53dd36e3bdde Mon Sep 17 00:00:00 2001 [...] > This commit fixes a problem in 4.13+ with latest >=nftables-0.8 release. > > Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=880145 > Bug: https://bugs.gentoo.org/636968 Already flying into -stable 4.13. https://marc.info/?l=netfilter-devel&m=151031414718199&w=2 Thanks.

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] v3.2.95 build: 4 failures 20 warnings (v3.2.95)

by Build bot for Mark Brown

Tree/Branch: v3.2.95 Git describe: v3.2.95 Commit: 8518814021 Linux 3.2.95 Build Time: 0 min 3 sec Passed: 0 / 4 ( 0.00 %) Failed: 4 / 4 (100.00 %) Errors: 6 Warnings: 20 Section Mismatches: 0 Failed defconfigs: x86_64-allnoconfig arm-allmodconfig arm-allnoconfig 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-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 2 /home/broonie/build/linux-stable/scripts/mod/empty.c:1:0: error: code model kernel does not support PIC mode 2 /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-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, 7 months

1
0
0 0

[Linux-stable-mirror] v3.16.50 build: 0 failures 7 warnings (v3.16.50)

by Build bot for Mark Brown

Tree/Branch: v3.16.50 Git describe: v3.16.50 Commit: 2447a018c3 Linux 3.16.50 Build Time: 31 min 1 sec Passed: 9 / 9 (100.00 %) Failed: 0 / 9 ( 0.00 %) Errors: 0 Warnings: 7 Section Mismatches: 0 ------------------------------------------------------------------------------- defconfigs with issues (other than build errors): 1 warnings 0 mismatches : arm64-allnoconfig 2 warnings 0 mismatches : arm64-allmodconfig 1 warnings 0 mismatches : arm-multi_v5_defconfig 1 warnings 0 mismatches : arm-multi_v7_defconfig 1 warnings 0 mismatches : x86_64-defconfig 4 warnings 0 mismatches : arm-allmodconfig 1 warnings 0 mismatches : arm-allnoconfig 1 warnings 0 mismatches : x86_64-allnoconfig 3 warnings 0 mismatches : arm64-defconfig ------------------------------------------------------------------------------- Warnings Summary: 7 7 ../include/linux/stddef.h:8:14: warning: 'return' with a value, in function returning void 2 ../ipc/sem.c:377:6: warning: '___p1' may be used uninitialized in this function [-Wmaybe-uninitialized] 2 ../drivers/net/ethernet/broadcom/genet/bcmgenet.c:1346:17: warning: unused variable 'kdev' [-Wunused-variable] 1 ../drivers/platform/x86/eeepc-laptop.c:279:10: warning: 'value' may be used uninitialized in this function [-Wmaybe-uninitialized] 1 ../drivers/media/platform/davinci/vpfe_capture.c:291:12: warning: 'vpfe_get_ccdc_image_format' defined but not used [-Wunused-function] 1 ../drivers/media/platform/davinci/vpfe_capture.c:1718:1: warning: label 'unlock_out' defined but not used [-Wunused-label] 1 ../arch/x86/kernel/cpu/common.c:961:13: warning: 'syscall32_cpu_init' defined but not used [-Wunused-function] =============================================================================== Detailed per-defconfig build reports below: ------------------------------------------------------------------------------- arm64-allnoconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: ../include/linux/stddef.h:8:14: warning: 'return' with a value, in function returning void ------------------------------------------------------------------------------- arm64-allmodconfig : PASS, 0 errors, 2 warnings, 0 section mismatches Warnings: ../include/linux/stddef.h:8:14: warning: 'return' with a value, in function returning void ../drivers/net/ethernet/broadcom/genet/bcmgenet.c:1346:17: warning: unused variable 'kdev' [-Wunused-variable] ------------------------------------------------------------------------------- arm-multi_v5_defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: ../include/linux/stddef.h:8:14: warning: 'return' with a value, in function returning void ------------------------------------------------------------------------------- arm-multi_v7_defconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: ../include/linux/stddef.h:8:14: warning: 'return' with a value, in function returning void ------------------------------------------------------------------------------- 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] ------------------------------------------------------------------------------- arm-allmodconfig : PASS, 0 errors, 4 warnings, 0 section mismatches Warnings: ../include/linux/stddef.h:8:14: warning: 'return' with a value, in function returning void ../drivers/media/platform/davinci/vpfe_capture.c:1718:1: warning: label 'unlock_out' defined but not used [-Wunused-label] ../drivers/media/platform/davinci/vpfe_capture.c:291:12: warning: 'vpfe_get_ccdc_image_format' defined but not used [-Wunused-function] ../drivers/net/ethernet/broadcom/genet/bcmgenet.c:1346:17: warning: unused variable 'kdev' [-Wunused-variable] ------------------------------------------------------------------------------- arm-allnoconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: ../include/linux/stddef.h:8:14: warning: 'return' with a value, in function returning void ------------------------------------------------------------------------------- x86_64-allnoconfig : PASS, 0 errors, 1 warnings, 0 section mismatches Warnings: ../arch/x86/kernel/cpu/common.c:961:13: warning: 'syscall32_cpu_init' defined but not used [-Wunused-function] ------------------------------------------------------------------------------- arm64-defconfig : PASS, 0 errors, 3 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] ../include/linux/stddef.h:8:14: warning: 'return' with a value, in function returning void ------------------------------------------------------------------------------- Passed with no errors, warnings or mismatches:

7 years, 7 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH 2/3] Input: twl6040-vibra: fix child-node lookup

by Johan Hovold

On Mon, Nov 13, 2017 at 08:30:53AM +0100, H. Nikolaus Schaller wrote: > Hi Johan, > > > Am 11.11.2017 um 16:43 schrieb Johan Hovold <johan(a)kernel.org>: > > > > Fix child-node lookup during probe, which ended up searching the whole > > device tree depth-first starting at parent rather than just matching on > > its children. > > > > Later sanity checks on node properties (which would likely be missing) > > should prevent this from causing much trouble however, especially as the > > original premature free of the parent node has already been fixed > > separately (but that "fix" was apparently never backported to stable). > > > > Fixes: e7ec014a47e4 ("Input: twl6040-vibra - update for device tree support") > > Fixes: c52c545ead97 ("Input: twl6040-vibra - fix DT node memory management") > > Cc: stable <stable(a)vger.kernel.org> # 3.6 > > Cc: Peter Ujfalusi <peter.ujfalusi(a)ti.com> > > Cc: H. Nikolaus Schaller <hns(a)goldelico.com> > > Signed-off-by: Johan Hovold <johan(a)kernel.org> > > Tested-By: H. Nikolaus Schaller <hns(a)goldelico.com> (on Pyra OMAP5 hardware) > > I also tested your twl4030-vibra patch on GTA04. > > No regressions observed. Thanks for testing. Johan

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "x86/smpboot: Make optimization of delay calibration work correctly" 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/smpboot: Make optimization of delay calibration work correctly 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-smpboot-make-optimization-of-delay-calibration-work-correctly.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 76ce7cfe35ef58f34e6ba85327afb5fbf6c3ff9b Mon Sep 17 00:00:00 2001 From: Pavel Tatashin <pasha.tatashin(a)oracle.com> Date: Fri, 27 Oct 2017 20:11:00 -0400 Subject: x86/smpboot: Make optimization of delay calibration work correctly From: Pavel Tatashin <pasha.tatashin(a)oracle.com> commit 76ce7cfe35ef58f34e6ba85327afb5fbf6c3ff9b upstream. If the TSC has constant frequency then the delay calibration can be skipped when it has been calibrated for a package already. This is checked in calibrate_delay_is_known(), but that function is buggy in two aspects: It returns 'false' if (!tsc_disabled && !cpu_has(&cpu_data(cpu), X86_FEATURE_CONSTANT_TSC) which is obviously the reverse of the intended check and the check for the sibling mask cannot work either because the topology links have not been set up yet. Correct the condition and move the call to set_cpu_sibling_map() before invoking calibrate_delay() so the sibling check works correctly. [ tglx: Rewrote changelong ] Fixes: c25323c07345 ("x86/tsc: Use topology functions") Signed-off-by: Pavel Tatashin <pasha.tatashin(a)oracle.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: peterz(a)infradead.org Cc: bob.picco(a)oracle.com Cc: steven.sistare(a)oracle.com Cc: daniel.m.jordan(a)oracle.com Link: https://lkml.kernel.org/r/20171028001100.26603-1-pasha.tatashin@oracle.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/smpboot.c | 11 ++++++----- arch/x86/kernel/tsc.c | 8 +++----- 2 files changed, 9 insertions(+), 10 deletions(-) --- a/arch/x86/kernel/smpboot.c +++ b/arch/x86/kernel/smpboot.c @@ -181,6 +181,12 @@ static void smp_callin(void) smp_store_cpu_info(cpuid); /* + * The topology information must be up to date before + * calibrate_delay() and notify_cpu_starting(). + */ + set_cpu_sibling_map(raw_smp_processor_id()); + + /* * Get our bogomips. * Update loops_per_jiffy in cpu_data. Previous call to * smp_store_cpu_info() stored a value that is close but not as @@ -190,11 +196,6 @@ static void smp_callin(void) cpu_data(cpuid).loops_per_jiffy = loops_per_jiffy; pr_debug("Stack at about %p\n", &cpuid); - /* - * This must be done before setting cpu_online_mask - * or calling notify_cpu_starting. - */ - set_cpu_sibling_map(raw_smp_processor_id()); wmb(); notify_cpu_starting(cpuid); --- a/arch/x86/kernel/tsc.c +++ b/arch/x86/kernel/tsc.c @@ -1382,12 +1382,10 @@ void __init tsc_init(void) unsigned long calibrate_delay_is_known(void) { int sibling, cpu = smp_processor_id(); - struct cpumask *mask = topology_core_cpumask(cpu); + int constant_tsc = cpu_has(&cpu_data(cpu), X86_FEATURE_CONSTANT_TSC); + const struct cpumask *mask = topology_core_cpumask(cpu); - if (!tsc_disabled && !cpu_has(&cpu_data(cpu), X86_FEATURE_CONSTANT_TSC)) - return 0; - - if (!mask) + if (tsc_disabled || !constant_tsc || !mask) return 0; sibling = cpumask_any_but(mask, cpu); Patches currently in stable-queue which might be from pasha.tatashin(a)oracle.com are queue-4.9/x86-smpboot-make-optimization-of-delay-calibration-work-correctly.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "x86/oprofile/ppro: Do not use __this_cpu*() in preemptible 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 x86/oprofile/ppro: Do not use __this_cpu*() in preemptible 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: x86-oprofile-ppro-do-not-use-__this_cpu-in-preemptible-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 a743bbeef27b9176987ec0cb7f906ab0ab52d1da Mon Sep 17 00:00:00 2001 From: Borislav Petkov <bp(a)suse.de> Date: Tue, 7 Nov 2017 18:53:07 +0100 Subject: x86/oprofile/ppro: Do not use __this_cpu*() in preemptible context From: Borislav Petkov <bp(a)suse.de> commit a743bbeef27b9176987ec0cb7f906ab0ab52d1da upstream. The warning below says it all: BUG: using __this_cpu_read() in preemptible [00000000] code: swapper/0/1 caller is __this_cpu_preempt_check CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.0-rc8 #4 Call Trace: dump_stack check_preemption_disabled ? do_early_param __this_cpu_preempt_check arch_perfmon_init op_nmi_init ? alloc_pci_root_info oprofile_arch_init oprofile_init do_one_initcall ... These accessors should not have been used in the first place: it is PPro so no mixed silicon revisions and thus it can simply use boot_cpu_data. Reported-by: Fengguang Wu <fengguang.wu(a)intel.com> Tested-by: Fengguang Wu <fengguang.wu(a)intel.com> Fix-creation-mandated-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Borislav Petkov <bp(a)suse.de> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: Robert Richter <rric(a)kernel.org> Cc: x86(a)kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/oprofile/op_model_ppro.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/arch/x86/oprofile/op_model_ppro.c +++ b/arch/x86/oprofile/op_model_ppro.c @@ -212,8 +212,8 @@ static void arch_perfmon_setup_counters( eax.full = cpuid_eax(0xa); /* Workaround for BIOS bugs in 6/15. Taken from perfmon2 */ - if (eax.split.version_id == 0 && __this_cpu_read(cpu_info.x86) == 6 && - __this_cpu_read(cpu_info.x86_model) == 15) { + if (eax.split.version_id == 0 && boot_cpu_data.x86 == 6 && + boot_cpu_data.x86_model == 15) { eax.split.version_id = 2; eax.split.num_counters = 2; eax.split.bit_width = 40; Patches currently in stable-queue which might be from bp(a)suse.de are queue-4.9/edac-amd64-add-x86cpuid-sanity-check-during-init.patch queue-4.9/edac-amd64-save-and-return-err-code-from-probe_one_instance.patch queue-4.9/x86-oprofile-ppro-do-not-use-__this_cpu-in-preemptible-context.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "x86/oprofile/ppro: Do not use __this_cpu*() in preemptible context" 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/oprofile/ppro: Do not use __this_cpu*() in preemptible context 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-oprofile-ppro-do-not-use-__this_cpu-in-preemptible-context.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 a743bbeef27b9176987ec0cb7f906ab0ab52d1da Mon Sep 17 00:00:00 2001 From: Borislav Petkov <bp(a)suse.de> Date: Tue, 7 Nov 2017 18:53:07 +0100 Subject: x86/oprofile/ppro: Do not use __this_cpu*() in preemptible context From: Borislav Petkov <bp(a)suse.de> commit a743bbeef27b9176987ec0cb7f906ab0ab52d1da upstream. The warning below says it all: BUG: using __this_cpu_read() in preemptible [00000000] code: swapper/0/1 caller is __this_cpu_preempt_check CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.0-rc8 #4 Call Trace: dump_stack check_preemption_disabled ? do_early_param __this_cpu_preempt_check arch_perfmon_init op_nmi_init ? alloc_pci_root_info oprofile_arch_init oprofile_init do_one_initcall ... These accessors should not have been used in the first place: it is PPro so no mixed silicon revisions and thus it can simply use boot_cpu_data. Reported-by: Fengguang Wu <fengguang.wu(a)intel.com> Tested-by: Fengguang Wu <fengguang.wu(a)intel.com> Fix-creation-mandated-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Borislav Petkov <bp(a)suse.de> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: Robert Richter <rric(a)kernel.org> Cc: x86(a)kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/oprofile/op_model_ppro.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/arch/x86/oprofile/op_model_ppro.c +++ b/arch/x86/oprofile/op_model_ppro.c @@ -212,8 +212,8 @@ static void arch_perfmon_setup_counters( eax.full = cpuid_eax(0xa); /* Workaround for BIOS bugs in 6/15. Taken from perfmon2 */ - if (eax.split.version_id == 0 && __this_cpu_read(cpu_info.x86) == 6 && - __this_cpu_read(cpu_info.x86_model) == 15) { + if (eax.split.version_id == 0 && boot_cpu_data.x86 == 6 && + boot_cpu_data.x86_model == 15) { eax.split.version_id = 2; eax.split.num_counters = 2; eax.split.bit_width = 40; Patches currently in stable-queue which might be from bp(a)suse.de are queue-4.4/x86-oprofile-ppro-do-not-use-__this_cpu-in-preemptible-context.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "PKCS#7: fix unitialized boolean 'want'" 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 PKCS#7: fix unitialized boolean 'want' 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: pkcs-7-fix-unitialized-boolean-want.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 06aae592425701851e02bb850cb9f4997f0ae163 Mon Sep 17 00:00:00 2001 From: Colin Ian King <colin.king(a)canonical.com> Date: Sat, 27 Feb 2016 12:45:26 +0000 Subject: PKCS#7: fix unitialized boolean 'want' From: Colin Ian King <colin.king(a)canonical.com> commit 06aae592425701851e02bb850cb9f4997f0ae163 upstream. The boolean want is not initialized and hence garbage. The default should be false (later it is only set to true on tne sinfo->authattrs check). Found with static analysis using CoverityScan Signed-off-by: Colin Ian King <colin.king(a)canonical.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Cc: Ben Hutchings <ben.hutchings(a)codethink.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- crypto/asymmetric_keys/pkcs7_parser.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/crypto/asymmetric_keys/pkcs7_parser.c +++ b/crypto/asymmetric_keys/pkcs7_parser.c @@ -87,7 +87,7 @@ EXPORT_SYMBOL_GPL(pkcs7_free_message); static int pkcs7_check_authattrs(struct pkcs7_message *msg) { struct pkcs7_signed_info *sinfo; - bool want; + bool want = false; sinfo = msg->signed_infos; if (!sinfo) Patches currently in stable-queue which might be from colin.king(a)canonical.com are queue-4.4/pkcs-7-fix-unitialized-boolean-want.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "x86/smpboot: Make optimization of delay calibration work correctly" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/smpboot: Make optimization of delay calibration work correctly to the 4.13-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-smpboot-make-optimization-of-delay-calibration-work-correctly.patch and it can be found in the queue-4.13 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 76ce7cfe35ef58f34e6ba85327afb5fbf6c3ff9b Mon Sep 17 00:00:00 2001 From: Pavel Tatashin <pasha.tatashin(a)oracle.com> Date: Fri, 27 Oct 2017 20:11:00 -0400 Subject: x86/smpboot: Make optimization of delay calibration work correctly From: Pavel Tatashin <pasha.tatashin(a)oracle.com> commit 76ce7cfe35ef58f34e6ba85327afb5fbf6c3ff9b upstream. If the TSC has constant frequency then the delay calibration can be skipped when it has been calibrated for a package already. This is checked in calibrate_delay_is_known(), but that function is buggy in two aspects: It returns 'false' if (!tsc_disabled && !cpu_has(&cpu_data(cpu), X86_FEATURE_CONSTANT_TSC) which is obviously the reverse of the intended check and the check for the sibling mask cannot work either because the topology links have not been set up yet. Correct the condition and move the call to set_cpu_sibling_map() before invoking calibrate_delay() so the sibling check works correctly. [ tglx: Rewrote changelong ] Fixes: c25323c07345 ("x86/tsc: Use topology functions") Signed-off-by: Pavel Tatashin <pasha.tatashin(a)oracle.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: peterz(a)infradead.org Cc: bob.picco(a)oracle.com Cc: steven.sistare(a)oracle.com Cc: daniel.m.jordan(a)oracle.com Link: https://lkml.kernel.org/r/20171028001100.26603-1-pasha.tatashin@oracle.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/smpboot.c | 11 ++++++----- arch/x86/kernel/tsc.c | 8 +++----- 2 files changed, 9 insertions(+), 10 deletions(-) --- a/arch/x86/kernel/smpboot.c +++ b/arch/x86/kernel/smpboot.c @@ -194,6 +194,12 @@ static void smp_callin(void) smp_store_cpu_info(cpuid); /* + * The topology information must be up to date before + * calibrate_delay() and notify_cpu_starting(). + */ + set_cpu_sibling_map(raw_smp_processor_id()); + + /* * Get our bogomips. * Update loops_per_jiffy in cpu_data. Previous call to * smp_store_cpu_info() stored a value that is close but not as @@ -203,11 +209,6 @@ static void smp_callin(void) cpu_data(cpuid).loops_per_jiffy = loops_per_jiffy; pr_debug("Stack at about %p\n", &cpuid); - /* - * This must be done before setting cpu_online_mask - * or calling notify_cpu_starting. - */ - set_cpu_sibling_map(raw_smp_processor_id()); wmb(); notify_cpu_starting(cpuid); --- a/arch/x86/kernel/tsc.c +++ b/arch/x86/kernel/tsc.c @@ -1346,12 +1346,10 @@ void __init tsc_init(void) unsigned long calibrate_delay_is_known(void) { int sibling, cpu = smp_processor_id(); - struct cpumask *mask = topology_core_cpumask(cpu); + int constant_tsc = cpu_has(&cpu_data(cpu), X86_FEATURE_CONSTANT_TSC); + const struct cpumask *mask = topology_core_cpumask(cpu); - if (!tsc_disabled && !cpu_has(&cpu_data(cpu), X86_FEATURE_CONSTANT_TSC)) - return 0; - - if (!mask) + if (tsc_disabled || !constant_tsc || !mask) return 0; sibling = cpumask_any_but(mask, cpu); Patches currently in stable-queue which might be from pasha.tatashin(a)oracle.com are queue-4.13/x86-smpboot-make-optimization-of-delay-calibration-work-correctly.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "x86/oprofile/ppro: Do not use __this_cpu*() in preemptible context" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/oprofile/ppro: Do not use __this_cpu*() in preemptible context to the 4.13-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-oprofile-ppro-do-not-use-__this_cpu-in-preemptible-context.patch and it can be found in the queue-4.13 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 a743bbeef27b9176987ec0cb7f906ab0ab52d1da Mon Sep 17 00:00:00 2001 From: Borislav Petkov <bp(a)suse.de> Date: Tue, 7 Nov 2017 18:53:07 +0100 Subject: x86/oprofile/ppro: Do not use __this_cpu*() in preemptible context From: Borislav Petkov <bp(a)suse.de> commit a743bbeef27b9176987ec0cb7f906ab0ab52d1da upstream. The warning below says it all: BUG: using __this_cpu_read() in preemptible [00000000] code: swapper/0/1 caller is __this_cpu_preempt_check CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.0-rc8 #4 Call Trace: dump_stack check_preemption_disabled ? do_early_param __this_cpu_preempt_check arch_perfmon_init op_nmi_init ? alloc_pci_root_info oprofile_arch_init oprofile_init do_one_initcall ... These accessors should not have been used in the first place: it is PPro so no mixed silicon revisions and thus it can simply use boot_cpu_data. Reported-by: Fengguang Wu <fengguang.wu(a)intel.com> Tested-by: Fengguang Wu <fengguang.wu(a)intel.com> Fix-creation-mandated-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Borislav Petkov <bp(a)suse.de> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: Robert Richter <rric(a)kernel.org> Cc: x86(a)kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/oprofile/op_model_ppro.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/arch/x86/oprofile/op_model_ppro.c +++ b/arch/x86/oprofile/op_model_ppro.c @@ -212,8 +212,8 @@ static void arch_perfmon_setup_counters( eax.full = cpuid_eax(0xa); /* Workaround for BIOS bugs in 6/15. Taken from perfmon2 */ - if (eax.split.version_id == 0 && __this_cpu_read(cpu_info.x86) == 6 && - __this_cpu_read(cpu_info.x86_model) == 15) { + if (eax.split.version_id == 0 && boot_cpu_data.x86 == 6 && + boot_cpu_data.x86_model == 15) { eax.split.version_id = 2; eax.split.num_counters = 2; eax.split.bit_width = 40; Patches currently in stable-queue which might be from bp(a)suse.de are queue-4.13/x86-oprofile-ppro-do-not-use-__this_cpu-in-preemptible-context.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "x86/debug: Handle warnings before the notifier chain, to fix KGDB crash" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled x86/debug: Handle warnings before the notifier chain, to fix KGDB crash to the 4.13-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-debug-handle-warnings-before-the-notifier-chain-to-fix-kgdb-crash.patch and it can be found in the queue-4.13 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 b8347c2196492f4e1cccde3d92fda1cc2cc7de7e Mon Sep 17 00:00:00 2001 From: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Date: Mon, 24 Jul 2017 13:04:28 +0300 Subject: x86/debug: Handle warnings before the notifier chain, to fix KGDB crash From: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> commit b8347c2196492f4e1cccde3d92fda1cc2cc7de7e upstream. Commit: 9a93848fe787 ("x86/debug: Implement __WARN() using UD0") turned warnings into UD0, but the fixup code only runs after the notify_die() chain. This is a problem, in particular, with kgdb, which kicks in as if it was a BUG(). Fix this by running the fixup code before the notifier chain in the invalid op handler path. Signed-off-by: Alexander Shishkin <alexander.shishkin(a)linux.intel.com> Tested-by: Ilya Dryomov <idryomov(a)gmail.com> Acked-by: Daniel Thompson <daniel.thompson(a)linaro.org> Acked-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: Jason Wessel <jason.wessel(a)windriver.com> Cc: Arjan van de Ven <arjan(a)linux.intel.com> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Richard Weinberger <richard.weinberger(a)gmail.com> Link: http://lkml.kernel.org/r/20170724100428.19173-1-alexander.shishkin@linux.in… Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/traps.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) --- a/arch/x86/kernel/traps.c +++ b/arch/x86/kernel/traps.c @@ -221,9 +221,6 @@ do_trap_no_signal(struct task_struct *ts if (fixup_exception(regs, trapnr)) return 0; - if (fixup_bug(regs, trapnr)) - return 0; - tsk->thread.error_code = error_code; tsk->thread.trap_nr = trapnr; die(str, regs, error_code); @@ -304,6 +301,13 @@ static void do_error_trap(struct pt_regs RCU_LOCKDEP_WARN(!rcu_is_watching(), "entry code didn't wake RCU"); + /* + * WARN*()s end up here; fix them up before we call the + * notifier chain. + */ + if (!user_mode(regs) && fixup_bug(regs, trapnr)) + return; + if (notify_die(DIE_TRAP, str, regs, error_code, trapnr, signr) != NOTIFY_STOP) { cond_local_irq_enable(regs); Patches currently in stable-queue which might be from alexander.shishkin(a)linux.intel.com are queue-4.13/x86-debug-handle-warnings-before-the-notifier-chain-to-fix-kgdb-crash.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH] usb: gadget: udc: renesas_usb3: fix number of the pipes

by Yoshihiro Shimoda

This controller on R-Car Gen3 has 6 pipes that included PIPE 0 for control actually. But, the datasheet has error in writing as it has 31 pipes. (However, the previous code defined 30 pipes wrongly...) Anyway, this patch fixes it. Fixes: 746bfe63bba3 ("usb: gadget: renesas_usb3: add support for Renesas USB3.0 peripheral controller") Cc: <stable(a)vger.kernel.org> # v4.5+ Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh(a)renesas.com> --- drivers/usb/gadget/udc/renesas_usb3.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/udc/renesas_usb3.c b/drivers/usb/gadget/udc/renesas_usb3.c index 63a2061..6b3e8ad 100644 --- a/drivers/usb/gadget/udc/renesas_usb3.c +++ b/drivers/usb/gadget/udc/renesas_usb3.c @@ -254,7 +254,7 @@ #define USB3_EP0_SS_MAX_PACKET_SIZE 512 #define USB3_EP0_HSFS_MAX_PACKET_SIZE 64 #define USB3_EP0_BUF_SIZE 8 -#define USB3_MAX_NUM_PIPES 30 +#define USB3_MAX_NUM_PIPES 6 /* This includes PIPE 0 */ #define USB3_WAIT_US 3 #define USB3_DMA_NUM_SETTING_AREA 4 /* -- 1.9.1

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [stable] PKCS#7: fix unitialized boolean 'want'

by Ben Hutchings

Please cherry-pick this fix for 4.4 and later stable branches: commit 06aae592425701851e02bb850cb9f4997f0ae163 Author: Colin Ian King <colin.king(a)canonical.com> Date: Sat Feb 27 12:45:26 2016 +0000 PKCS#7: fix unitialized boolean 'want' Ben. -- Ben Hutchings Software Developer, Codethink Ltd.

7 years, 7 months

2
1
0 0

[Linux-stable-mirror] Patch "x86/oprofile/ppro: Do not use __this_cpu*() in preemptible context" 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 x86/oprofile/ppro: Do not use __this_cpu*() in preemptible context 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: x86-oprofile-ppro-do-not-use-__this_cpu-in-preemptible-context.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 a743bbeef27b9176987ec0cb7f906ab0ab52d1da Mon Sep 17 00:00:00 2001 From: Borislav Petkov <bp(a)suse.de> Date: Tue, 7 Nov 2017 18:53:07 +0100 Subject: x86/oprofile/ppro: Do not use __this_cpu*() in preemptible context From: Borislav Petkov <bp(a)suse.de> commit a743bbeef27b9176987ec0cb7f906ab0ab52d1da upstream. The warning below says it all: BUG: using __this_cpu_read() in preemptible [00000000] code: swapper/0/1 caller is __this_cpu_preempt_check CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.0-rc8 #4 Call Trace: dump_stack check_preemption_disabled ? do_early_param __this_cpu_preempt_check arch_perfmon_init op_nmi_init ? alloc_pci_root_info oprofile_arch_init oprofile_init do_one_initcall ... These accessors should not have been used in the first place: it is PPro so no mixed silicon revisions and thus it can simply use boot_cpu_data. Reported-by: Fengguang Wu <fengguang.wu(a)intel.com> Tested-by: Fengguang Wu <fengguang.wu(a)intel.com> Fix-creation-mandated-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Borislav Petkov <bp(a)suse.de> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: Robert Richter <rric(a)kernel.org> Cc: x86(a)kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/oprofile/op_model_ppro.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/arch/x86/oprofile/op_model_ppro.c +++ b/arch/x86/oprofile/op_model_ppro.c @@ -212,8 +212,8 @@ static void arch_perfmon_setup_counters( eax.full = cpuid_eax(0xa); /* Workaround for BIOS bugs in 6/15. Taken from perfmon2 */ - if (eax.split.version_id == 0 && __this_cpu_read(cpu_info.x86) == 6 && - __this_cpu_read(cpu_info.x86_model) == 15) { + if (eax.split.version_id == 0 && boot_cpu_data.x86 == 6 && + boot_cpu_data.x86_model == 15) { eax.split.version_id = 2; eax.split.num_counters = 2; eax.split.bit_width = 40; Patches currently in stable-queue which might be from bp(a)suse.de are queue-3.18/x86-oprofile-ppro-do-not-use-__this_cpu-in-preemptible-context.patch

7 years, 7 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH V9 1/4] dma-mapping: Rework dma_get_cache_alignment()

by Christoph Hellwig

> diff --git a/drivers/net/ethernet/broadcom/b44.c b/drivers/net/ethernet/broadcom/b44.c > index a1125d1..2f6ffe5 100644 > --- a/drivers/net/ethernet/broadcom/b44.c > +++ b/drivers/net/ethernet/broadcom/b44.c > @@ -2344,6 +2344,10 @@ static int b44_init_one(struct ssb_device *sdev, > struct net_device *dev; > struct b44 *bp; > int err; > + unsigned int dma_desc_align_size = dma_get_cache_alignment(sdev->dma_dev); > + > + /* Setup paramaters for syncing RX/TX DMA descriptors */ > + dma_desc_sync_size = max_t(unsigned int, dma_desc_align_size, sizeof(struct dma_desc)); > > instance++; > > @@ -2587,12 +2591,8 @@ static inline void b44_pci_exit(void) > > static int __init b44_init(void) > { > - unsigned int dma_desc_align_size = dma_get_cache_alignment(); > int err; > > - /* Setup paramaters for syncing RX/TX DMA descriptors */ > - dma_desc_sync_size = max_t(unsigned int, dma_desc_align_size, sizeof(struct dma_desc)); > - This looks wrong - you override a global variable for each probed device.

7 years, 7 months

2
1
0 0

[Linux-stable-mirror] Patch "netfilter: nat: Revert "netfilter: nat: convert nat bysrc hash to rhashtable"" 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 netfilter: nat: Revert "netfilter: nat: convert nat bysrc hash to rhashtable" 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: netfilter-nat-revert-netfilter-nat-convert-nat-bysrc-hash-to-rhashtable.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 e1bf1687740ce1a3598a1c5e452b852ff2190682 Mon Sep 17 00:00:00 2001 From: Florian Westphal <fw(a)strlen.de> Date: Wed, 6 Sep 2017 14:39:51 +0200 Subject: netfilter: nat: Revert "netfilter: nat: convert nat bysrc hash to rhashtable" From: Florian Westphal <fw(a)strlen.de> commit e1bf1687740ce1a3598a1c5e452b852ff2190682 upstream. This reverts commit 870190a9ec9075205c0fa795a09fa931694a3ff1. It was not a good idea. The custom hash table was a much better fit for this purpose. A fast lookup is not essential, in fact for most cases there is no lookup at all because original tuple is not taken and can be used as-is. What needs to be fast is insertion and deletion. rhlist removal however requires a rhlist walk. We can have thousands of entries in such a list if source port/addresses are reused for multiple flows, if this happens removal requests are so expensive that deletions of a few thousand flows can take several seconds(!). The advantages that we got from rhashtable are: 1) table auto-sizing 2) multiple locks 1) would be nice to have, but it is not essential as we have at most one lookup per new flow, so even a million flows in the bysource table are not a problem compared to current deletion cost. 2) is easy to add to custom hash table. I tried to add hlist_node to rhlist to speed up rhltable_remove but this isn't doable without changing semantics. rhltable_remove_fast will check that the to-be-deleted object is part of the table and that requires a list walk that we want to avoid. Furthermore, using hlist_node increases size of struct rhlist_head, which in turn increases nf_conn size. Link: https://bugzilla.kernel.org/show_bug.cgi?id=196821 Reported-by: Ivan Babrou <ibobrik(a)gmail.com> Signed-off-by: Florian Westphal <fw(a)strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/net/netfilter/nf_conntrack.h | 3 include/net/netfilter/nf_nat.h | 1 net/netfilter/nf_nat_core.c | 131 ++++++++++++++--------------------- 3 files changed, 56 insertions(+), 79 deletions(-) --- a/include/net/netfilter/nf_conntrack.h +++ b/include/net/netfilter/nf_conntrack.h @@ -17,7 +17,6 @@ #include <linux/bitops.h> #include <linux/compiler.h> #include <linux/atomic.h> -#include <linux/rhashtable.h> #include <linux/netfilter/nf_conntrack_tcp.h> #include <linux/netfilter/nf_conntrack_dccp.h> @@ -101,7 +100,7 @@ struct nf_conn { possible_net_t ct_net; #if IS_ENABLED(CONFIG_NF_NAT) - struct rhlist_head nat_bysource; + struct hlist_node nat_bysource; #endif /* all members below initialized via memset */ u8 __nfct_init_offset[0]; --- a/include/net/netfilter/nf_nat.h +++ b/include/net/netfilter/nf_nat.h @@ -1,6 +1,5 @@ #ifndef _NF_NAT_H #define _NF_NAT_H -#include <linux/rhashtable.h> #include <linux/netfilter_ipv4.h> #include <linux/netfilter/nf_nat.h> #include <net/netfilter/nf_conntrack_tuple.h> --- a/net/netfilter/nf_nat_core.c +++ b/net/netfilter/nf_nat_core.c @@ -30,19 +30,17 @@ #include <net/netfilter/nf_conntrack_zones.h> #include <linux/netfilter/nf_nat.h> +static DEFINE_SPINLOCK(nf_nat_lock); + static DEFINE_MUTEX(nf_nat_proto_mutex); static const struct nf_nat_l3proto __rcu *nf_nat_l3protos[NFPROTO_NUMPROTO] __read_mostly; static const struct nf_nat_l4proto __rcu **nf_nat_l4protos[NFPROTO_NUMPROTO] __read_mostly; -struct nf_nat_conn_key { - const struct net *net; - const struct nf_conntrack_tuple *tuple; - const struct nf_conntrack_zone *zone; -}; - -static struct rhltable nf_nat_bysource_table; +static struct hlist_head *nf_nat_bysource __read_mostly; +static unsigned int nf_nat_htable_size __read_mostly; +static unsigned int nf_nat_hash_rnd __read_mostly; inline const struct nf_nat_l3proto * __nf_nat_l3proto_find(u8 family) @@ -121,17 +119,19 @@ int nf_xfrm_me_harder(struct net *net, s EXPORT_SYMBOL(nf_xfrm_me_harder); #endif /* CONFIG_XFRM */ -static u32 nf_nat_bysource_hash(const void *data, u32 len, u32 seed) +/* We keep an extra hash for each conntrack, for fast searching. */ +static inline unsigned int +hash_by_src(const struct net *n, const struct nf_conntrack_tuple *tuple) { - const struct nf_conntrack_tuple *t; - const struct nf_conn *ct = data; + unsigned int hash; + + get_random_once(&nf_nat_hash_rnd, sizeof(nf_nat_hash_rnd)); - t = &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple; /* Original src, to ensure we map it consistently if poss. */ + hash = jhash2((u32 *)&tuple->src, sizeof(tuple->src) / sizeof(u32), + tuple->dst.protonum ^ nf_nat_hash_rnd ^ net_hash_mix(n)); - seed ^= net_hash_mix(nf_ct_net(ct)); - return jhash2((const u32 *)&t->src, sizeof(t->src) / sizeof(u32), - t->dst.protonum ^ seed); + return reciprocal_scale(hash, nf_nat_htable_size); } /* Is this tuple already taken? (not by us) */ @@ -187,28 +187,6 @@ same_src(const struct nf_conn *ct, t->src.u.all == tuple->src.u.all); } -static int nf_nat_bysource_cmp(struct rhashtable_compare_arg *arg, - const void *obj) -{ - const struct nf_nat_conn_key *key = arg->key; - const struct nf_conn *ct = obj; - - if (!same_src(ct, key->tuple) || - !net_eq(nf_ct_net(ct), key->net) || - !nf_ct_zone_equal(ct, key->zone, IP_CT_DIR_ORIGINAL)) - return 1; - - return 0; -} - -static struct rhashtable_params nf_nat_bysource_params = { - .head_offset = offsetof(struct nf_conn, nat_bysource), - .obj_hashfn = nf_nat_bysource_hash, - .obj_cmpfn = nf_nat_bysource_cmp, - .nelem_hint = 256, - .min_size = 1024, -}; - /* Only called for SRC manip */ static int find_appropriate_src(struct net *net, @@ -219,26 +197,22 @@ find_appropriate_src(struct net *net, struct nf_conntrack_tuple *result, const struct nf_nat_range *range) { + unsigned int h = hash_by_src(net, tuple); const struct nf_conn *ct; - struct nf_nat_conn_key key = { - .net = net, - .tuple = tuple, - .zone = zone - }; - struct rhlist_head *hl, *h; - - hl = rhltable_lookup(&nf_nat_bysource_table, &key, - nf_nat_bysource_params); - rhl_for_each_entry_rcu(ct, h, hl, nat_bysource) { - nf_ct_invert_tuplepr(result, - &ct->tuplehash[IP_CT_DIR_REPLY].tuple); - result->dst = tuple->dst; + hlist_for_each_entry_rcu(ct, &nf_nat_bysource[h], nat_bysource) { + if (same_src(ct, tuple) && + net_eq(net, nf_ct_net(ct)) && + nf_ct_zone_equal(ct, zone, IP_CT_DIR_ORIGINAL)) { + /* Copy source part from reply tuple. */ + nf_ct_invert_tuplepr(result, + &ct->tuplehash[IP_CT_DIR_REPLY].tuple); + result->dst = tuple->dst; - if (in_range(l3proto, l4proto, result, range)) - return 1; + if (in_range(l3proto, l4proto, result, range)) + return 1; + } } - return 0; } @@ -411,6 +385,7 @@ nf_nat_setup_info(struct nf_conn *ct, const struct nf_nat_range *range, enum nf_nat_manip_type maniptype) { + struct net *net = nf_ct_net(ct); struct nf_conntrack_tuple curr_tuple, new_tuple; struct nf_conn_nat *nat; @@ -452,19 +427,16 @@ nf_nat_setup_info(struct nf_conn *ct, } if (maniptype == NF_NAT_MANIP_SRC) { - struct nf_nat_conn_key key = { - .net = nf_ct_net(ct), - .tuple = &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple, - .zone = nf_ct_zone(ct), - }; - int err; - - err = rhltable_insert_key(&nf_nat_bysource_table, - &key, - &ct->nat_bysource, - nf_nat_bysource_params); - if (err) - return NF_DROP; + unsigned int srchash; + + srchash = hash_by_src(net, + &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple); + spin_lock_bh(&nf_nat_lock); + /* nf_conntrack_alter_reply might re-allocate extension aera */ + nat = nfct_nat(ct); + hlist_add_head_rcu(&ct->nat_bysource, + &nf_nat_bysource[srchash]); + spin_unlock_bh(&nf_nat_lock); } /* It's done. */ @@ -578,9 +550,10 @@ static int nf_nat_proto_clean(struct nf_ * Else, when the conntrack is destoyed, nf_nat_cleanup_conntrack() * will delete entry from already-freed table. */ + spin_lock_bh(&nf_nat_lock); + hlist_del_rcu(&ct->nat_bysource); ct->status &= ~IPS_NAT_DONE_MASK; - rhltable_remove(&nf_nat_bysource_table, &ct->nat_bysource, - nf_nat_bysource_params); + spin_unlock_bh(&nf_nat_lock); /* don't delete conntrack. Although that would make things a lot * simpler, we'd end up flushing all conntracks on nat rmmod. @@ -710,8 +683,11 @@ static void nf_nat_cleanup_conntrack(str if (!nat) return; - rhltable_remove(&nf_nat_bysource_table, &ct->nat_bysource, - nf_nat_bysource_params); + NF_CT_ASSERT(ct->status & IPS_SRC_NAT_DONE); + + spin_lock_bh(&nf_nat_lock); + hlist_del_rcu(&ct->nat_bysource); + spin_unlock_bh(&nf_nat_lock); } static struct nf_ct_ext_type nat_extend __read_mostly = { @@ -846,13 +822,16 @@ static int __init nf_nat_init(void) { int ret; - ret = rhltable_init(&nf_nat_bysource_table, &nf_nat_bysource_params); - if (ret) - return ret; + /* Leave them the same for the moment. */ + nf_nat_htable_size = nf_conntrack_htable_size; + + nf_nat_bysource = nf_ct_alloc_hashtable(&nf_nat_htable_size, 0); + if (!nf_nat_bysource) + return -ENOMEM; ret = nf_ct_extend_register(&nat_extend); if (ret < 0) { - rhltable_destroy(&nf_nat_bysource_table); + nf_ct_free_hashtable(nf_nat_bysource, nf_nat_htable_size); printk(KERN_ERR "nf_nat_core: Unable to register extension\n"); return ret; } @@ -876,7 +855,7 @@ static int __init nf_nat_init(void) return 0; cleanup_extend: - rhltable_destroy(&nf_nat_bysource_table); + nf_ct_free_hashtable(nf_nat_bysource, nf_nat_htable_size); nf_ct_extend_unregister(&nat_extend); return ret; } @@ -896,8 +875,8 @@ static void __exit nf_nat_cleanup(void) for (i = 0; i < NFPROTO_NUMPROTO; i++) kfree(nf_nat_l4protos[i]); - - rhltable_destroy(&nf_nat_bysource_table); + synchronize_net(); + nf_ct_free_hashtable(nf_nat_bysource, nf_nat_htable_size); } MODULE_LICENSE("GPL"); Patches currently in stable-queue which might be from fw(a)strlen.de are queue-4.9/netfilter-nat-revert-netfilter-nat-convert-nat-bysrc-hash-to-rhashtable.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH] KVM: x86: inject exceptions produced by x86_decode_insn

by Paolo Bonzini

Sometimes, a processor might execute an instruction while another processor is updating the page tables for that instruction's code page, but before the TLB shootdown completes. The interesting case happens if the page is in the TLB. In general, the processor will succeed in executing the instruction and nothing bad happens. However, what if the instruction is an MMIO access? If *that* happens, KVM invokes the emulator, and the emulator gets the updated page tables. If the update side had marked the code page as non present, the page table walk then will fail and so will x86_decode_insn. Unfortunately, even though kvm_fetch_guest_virt is correctly returning X86EMUL_PROPAGATE_FAULT, x86_decode_insn's caller treats the failure as a fatal error if the instruction cannot simply be reexecuted (as is the case for MMIO). And this in fact happened sometimes when rebooting Windows 2012r2 guests. Just checking ctxt->have_exception and injecting the exception if true is enough to fix the case. Thanks to Eduardo Habkost for helping in the debugging of this issue. Reported-by: Yanan Fu <yfu(a)redhat.com> Cc: Eduardo Habkost <ehabkost(a)redhat.com> Cc: stable(a)vger.kernel.org Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> --- arch/x86/kvm/x86.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 34c85aa2e2d1..6dbed9022797 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -5722,6 +5722,8 @@ int x86_emulate_instruction(struct kvm_vcpu *vcpu, if (reexecute_instruction(vcpu, cr2, write_fault_to_spt, emulation_type)) return EMULATE_DONE; + if (ctxt->have_exception && inject_emulated_exception(vcpu)) + return EMULATE_DONE; if (emulation_type & EMULTYPE_SKIP) return EMULATE_FAIL; return handle_emulation_failure(vcpu); -- 1.8.3.1

7 years, 7 months

3
2
0 0

Re: [Linux-stable-mirror] [PATCH 3.16 076/294] batman-adv: fix TT sync flag inconsistencies

by Linus Lüssing

Hi Ben, On Tue, Nov 07, 2017 at 01:42:35PM +0000, Ben Hutchings wrote: > That function didn't exist in 3.16 (at least not under that name). Ah, you're right, back then the netlink interface did not exist in batman-adv yet, only the debugfs one. batadv_tt_global_print_entry would be the equivalent function for debugfs. But not worth the effort now, in my opinion. I'm fine with this proposed patch for 3.16 now. Thanks for the clarification! And I'm happy to see this patch backported. Regards, Linus

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH] fs: avoid NULL pointer dereference for nobh on write error

by jglisse＠redhat.com

From: Jérôme Glisse <jglisse(a)redhat.com> (Result of code inspection only, i do not have a bug, nor know a bug that would be explain by this issue. Is there a kernel trace database one can query for that ?) When fs is mounted with nobh temporary buffer_head are created during write and they are only associated with the page when a filesystem error happen. When this happen nobh_write_begin() or nobh_write_end() call attach_nobh_buffers() which expect that provided buffer_head list is circular (ie tail entry point to head entry). If it is not the case it will dereference the last pointer in the list which is NULL (last item in the list point to NULL see alloc_page_buffers()) and thus SEGFAULT. Hence nobh_write_begin() must make the buffer_head list circular as alloc_page_buffers() is not responsible for doing that. (This might worth including in 4.14 as i don't think it can regress anything but i am not a filesystem expert). Note i did not make the list circular inside attach_nobh_buffers() as some patchset i am working on also expect the list to be circular no matter what. But if people are more confortable with me doing that in my patchset the fix can be move to attach_nobh_buffers(). Signed-off-by: Jérôme Glisse <jglisse(a)redhat.com> Cc: Al Viro <viro(a)zeniv.linux.org.uk> Cc: linux-fsdevel(a)vger.kernel.org Cc: linux-kernel(a)vger.kernel.org Cc: stable(a)vger.kernel.org Cc: Linus Torvalds <torvalds(a)linux-foundation.org> --- fs/buffer.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/fs/buffer.c b/fs/buffer.c index 170df856bdb9..6bc47c11d6ac 100644 --- a/fs/buffer.c +++ b/fs/buffer.c @@ -2598,7 +2598,7 @@ int nobh_write_begin(struct address_space *mapping, struct inode *inode = mapping->host; const unsigned blkbits = inode->i_blkbits; const unsigned blocksize = 1 << blkbits; - struct buffer_head *head, *bh; + struct buffer_head *head, *bh, *tail; struct page *page; pgoff_t index; unsigned from, to; @@ -2643,6 +2643,13 @@ int nobh_write_begin(struct address_space *mapping, ret = -ENOMEM; goto out_release; } + /* We need to make buffer_head list circular to avoid NULL SEGFAULT */ + bh = head; + do { + tail = bh; + bh = bh->b_this_page; + } while (bh); + tail->b_this_page = head; block_in_file = (sector_t)page->index << (PAGE_SHIFT - blkbits); -- 2.13.6

7 years, 7 months

3
2
0 0

[Linux-stable-mirror] [PATCH] irqchip/gic-v3: fix ppi-partitions lookup

by Johan Hovold

Fix child-node lookup during initialisation, which ended up searching the whole device tree depth-first starting at the parent rather than just matching on its children. To make things worse, the parent giq node was prematurely freed, while the ppi-partitions node was leaked. Fixes: e3825ba1af3a ("irqchip/gic-v3: Add support for partitioned PPIs") Cc: stable <stable(a)vger.kernel.org> # 4.7 Cc: Marc Zyngier <marc.zyngier(a)arm.com> Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/irqchip/irq-gic-v3.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c index 17221143f505..af1f8373d8bf 100644 --- a/drivers/irqchip/irq-gic-v3.c +++ b/drivers/irqchip/irq-gic-v3.c @@ -1103,18 +1103,18 @@ static void __init gic_populate_ppi_partitions(struct device_node *gic_node) int nr_parts; struct partition_affinity *parts; - parts_node = of_find_node_by_name(gic_node, "ppi-partitions"); + parts_node = of_get_child_by_name(gic_node, "ppi-partitions"); if (!parts_node) return; nr_parts = of_get_child_count(parts_node); if (!nr_parts) - return; + goto out_put_node; parts = kzalloc(sizeof(*parts) * nr_parts, GFP_KERNEL); if (WARN_ON(!parts)) - return; + goto out_put_node; for_each_child_of_node(parts_node, child_part) { struct partition_affinity *part; @@ -1181,6 +1181,9 @@ static void __init gic_populate_ppi_partitions(struct device_node *gic_node) gic_data.ppi_descs[i] = desc; } + +out_put_node: + of_node_put(parts_node); } static void __init gic_of_setup_kvm_info(struct device_node *node) -- 2.15.0

7 years, 7 months

2
3
0 0

[Linux-stable-mirror] Patch "can: sun4i: handle overrun in RX FIFO" 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 can: sun4i: handle overrun in RX FIFO 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: can-sun4i-handle-overrun-in-rx-fifo.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 4dcf924c2eda0c47a5c53b7703e3dc65ddaa8920 Mon Sep 17 00:00:00 2001 From: Gerhard Bertelsmann <info(a)gerhard-bertelsmann.de> Date: Mon, 6 Nov 2017 18:16:56 +0100 Subject: can: sun4i: handle overrun in RX FIFO From: Gerhard Bertelsmann <info(a)gerhard-bertelsmann.de> commit 4dcf924c2eda0c47a5c53b7703e3dc65ddaa8920 upstream. SUN4Is CAN IP has a 64 byte deep FIFO buffer. If the buffer is not drained fast enough (overrun) it's getting mangled. Already received frames are dropped - the data can't be restored. Signed-off-by: Gerhard Bertelsmann <info(a)gerhard-bertelsmann.de> Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/can/sun4i_can.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) --- a/drivers/net/can/sun4i_can.c +++ b/drivers/net/can/sun4i_can.c @@ -539,6 +539,13 @@ static int sun4i_can_err(struct net_devi } stats->rx_over_errors++; stats->rx_errors++; + + /* reset the CAN IP by entering reset mode + * ignoring timeout error + */ + set_reset_mode(dev); + set_normal_mode(dev); + /* clear bit */ sun4i_can_write_cmdreg(priv, SUN4I_CMD_CLEAR_OR_FLAG); } @@ -653,8 +660,9 @@ static irqreturn_t sun4i_can_interrupt(i netif_wake_queue(dev); can_led_event(dev, CAN_LED_EVENT_TX); } - if (isrc & SUN4I_INT_RBUF_VLD) { - /* receive interrupt */ + if ((isrc & SUN4I_INT_RBUF_VLD) && + !(isrc & SUN4I_INT_DATA_OR)) { + /* receive interrupt - don't read if overrun occurred */ while (status & SUN4I_STA_RBUF_RDY) { /* RX buffer is not empty */ sun4i_can_rx(dev); Patches currently in stable-queue which might be from info(a)gerhard-bertelsmann.de are queue-4.9/can-sun4i-handle-overrun-in-rx-fifo.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "can: ifi: Fix transmitter delay calculation" 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 can: ifi: Fix transmitter delay calculation 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: can-ifi-fix-transmitter-delay-calculation.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 4f7116757b4bd99e4ef2636c7d957a6d63035d11 Mon Sep 17 00:00:00 2001 From: Marek Vasut <marex(a)denx.de> Date: Fri, 10 Nov 2017 11:22:39 +0100 Subject: can: ifi: Fix transmitter delay calculation From: Marek Vasut <marex(a)denx.de> commit 4f7116757b4bd99e4ef2636c7d957a6d63035d11 upstream. The CANFD transmitter delay calculation formula was updated in the latest software drop from IFI and improves the behavior of the IFI CANFD core during bitrate switching. Use the new formula to improve stability of the CANFD operation. Signed-off-by: Marek Vasut <marex(a)denx.de> Cc: Markus Marb <markus(a)marb.org> Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/can/ifi_canfd/ifi_canfd.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/drivers/net/can/ifi_canfd/ifi_canfd.c +++ b/drivers/net/can/ifi_canfd/ifi_canfd.c @@ -670,9 +670,9 @@ static void ifi_canfd_set_bittiming(stru priv->base + IFI_CANFD_FTIME); /* Configure transmitter delay */ - tdc = (dbt->brp * (dbt->phase_seg1 + 1)) & IFI_CANFD_TDELAY_MASK; - writel(IFI_CANFD_TDELAY_EN | IFI_CANFD_TDELAY_ABS | tdc, - priv->base + IFI_CANFD_TDELAY); + tdc = dbt->brp * (dbt->prop_seg + dbt->phase_seg1); + tdc &= IFI_CANFD_TDELAY_MASK; + writel(IFI_CANFD_TDELAY_EN | tdc, priv->base + IFI_CANFD_TDELAY); } static void ifi_canfd_set_filter(struct net_device *ndev, const u32 id, Patches currently in stable-queue which might be from marex(a)denx.de are queue-4.9/can-ifi-fix-transmitter-delay-calculation.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "can: c_can: don't indicate triple sampling support for D_CAN" 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 can: c_can: don't indicate triple sampling support for D_CAN 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: can-c_can-don-t-indicate-triple-sampling-support-for-d_can.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 fb5f0b3ef69b95e665e4bbe8a3de7201f09f1071 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Richard=20Sch=C3=BCtz?= <rschuetz(a)uni-koblenz.de> Date: Sun, 29 Oct 2017 13:03:22 +0100 Subject: can: c_can: don't indicate triple sampling support for D_CAN MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Richard Schütz <rschuetz(a)uni-koblenz.de> commit fb5f0b3ef69b95e665e4bbe8a3de7201f09f1071 upstream. The D_CAN controller doesn't provide a triple sampling mode, so don't set the CAN_CTRLMODE_3_SAMPLES flag in ctrlmode_supported. Currently enabling triple sampling is a no-op. Signed-off-by: Richard Schütz <rschuetz(a)uni-koblenz.de> Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/can/c_can/c_can_pci.c | 1 - drivers/net/can/c_can/c_can_platform.c | 1 - 2 files changed, 2 deletions(-) --- a/drivers/net/can/c_can/c_can_pci.c +++ b/drivers/net/can/c_can/c_can_pci.c @@ -178,7 +178,6 @@ static int c_can_pci_probe(struct pci_de break; case BOSCH_D_CAN: priv->regs = reg_map_d_can; - priv->can.ctrlmode_supported |= CAN_CTRLMODE_3_SAMPLES; break; default: ret = -EINVAL; --- a/drivers/net/can/c_can/c_can_platform.c +++ b/drivers/net/can/c_can/c_can_platform.c @@ -320,7 +320,6 @@ static int c_can_plat_probe(struct platf break; case BOSCH_D_CAN: priv->regs = reg_map_d_can; - priv->can.ctrlmode_supported |= CAN_CTRLMODE_3_SAMPLES; priv->read_reg = c_can_plat_read_reg_aligned_to_16bit; priv->write_reg = c_can_plat_write_reg_aligned_to_16bit; priv->read_reg32 = d_can_plat_read_reg32; Patches currently in stable-queue which might be from rschuetz(a)uni-koblenz.de are queue-4.9/can-c_can-don-t-indicate-triple-sampling-support-for-d_can.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "can: sun4i: handle overrun in RX FIFO" 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 can: sun4i: handle overrun in RX FIFO 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: can-sun4i-handle-overrun-in-rx-fifo.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 4dcf924c2eda0c47a5c53b7703e3dc65ddaa8920 Mon Sep 17 00:00:00 2001 From: Gerhard Bertelsmann <info(a)gerhard-bertelsmann.de> Date: Mon, 6 Nov 2017 18:16:56 +0100 Subject: can: sun4i: handle overrun in RX FIFO From: Gerhard Bertelsmann <info(a)gerhard-bertelsmann.de> commit 4dcf924c2eda0c47a5c53b7703e3dc65ddaa8920 upstream. SUN4Is CAN IP has a 64 byte deep FIFO buffer. If the buffer is not drained fast enough (overrun) it's getting mangled. Already received frames are dropped - the data can't be restored. Signed-off-by: Gerhard Bertelsmann <info(a)gerhard-bertelsmann.de> Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/can/sun4i_can.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) --- a/drivers/net/can/sun4i_can.c +++ b/drivers/net/can/sun4i_can.c @@ -539,6 +539,13 @@ static int sun4i_can_err(struct net_devi } stats->rx_over_errors++; stats->rx_errors++; + + /* reset the CAN IP by entering reset mode + * ignoring timeout error + */ + set_reset_mode(dev); + set_normal_mode(dev); + /* clear bit */ sun4i_can_write_cmdreg(priv, SUN4I_CMD_CLEAR_OR_FLAG); } @@ -653,8 +660,9 @@ static irqreturn_t sun4i_can_interrupt(i netif_wake_queue(dev); can_led_event(dev, CAN_LED_EVENT_TX); } - if (isrc & SUN4I_INT_RBUF_VLD) { - /* receive interrupt */ + if ((isrc & SUN4I_INT_RBUF_VLD) && + !(isrc & SUN4I_INT_DATA_OR)) { + /* receive interrupt - don't read if overrun occurred */ while (status & SUN4I_STA_RBUF_RDY) { /* RX buffer is not empty */ sun4i_can_rx(dev); Patches currently in stable-queue which might be from info(a)gerhard-bertelsmann.de are queue-4.4/can-sun4i-handle-overrun-in-rx-fifo.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "can: c_can: don't indicate triple sampling support for D_CAN" 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 can: c_can: don't indicate triple sampling support for D_CAN 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: can-c_can-don-t-indicate-triple-sampling-support-for-d_can.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 fb5f0b3ef69b95e665e4bbe8a3de7201f09f1071 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Richard=20Sch=C3=BCtz?= <rschuetz(a)uni-koblenz.de> Date: Sun, 29 Oct 2017 13:03:22 +0100 Subject: can: c_can: don't indicate triple sampling support for D_CAN MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Richard Schütz <rschuetz(a)uni-koblenz.de> commit fb5f0b3ef69b95e665e4bbe8a3de7201f09f1071 upstream. The D_CAN controller doesn't provide a triple sampling mode, so don't set the CAN_CTRLMODE_3_SAMPLES flag in ctrlmode_supported. Currently enabling triple sampling is a no-op. Signed-off-by: Richard Schütz <rschuetz(a)uni-koblenz.de> Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/can/c_can/c_can_pci.c | 1 - drivers/net/can/c_can/c_can_platform.c | 1 - 2 files changed, 2 deletions(-) --- a/drivers/net/can/c_can/c_can_pci.c +++ b/drivers/net/can/c_can/c_can_pci.c @@ -178,7 +178,6 @@ static int c_can_pci_probe(struct pci_de break; case BOSCH_D_CAN: priv->regs = reg_map_d_can; - priv->can.ctrlmode_supported |= CAN_CTRLMODE_3_SAMPLES; break; default: ret = -EINVAL; --- a/drivers/net/can/c_can/c_can_platform.c +++ b/drivers/net/can/c_can/c_can_platform.c @@ -320,7 +320,6 @@ static int c_can_plat_probe(struct platf break; case BOSCH_D_CAN: priv->regs = reg_map_d_can; - priv->can.ctrlmode_supported |= CAN_CTRLMODE_3_SAMPLES; priv->read_reg = c_can_plat_read_reg_aligned_to_16bit; priv->write_reg = c_can_plat_write_reg_aligned_to_16bit; priv->read_reg32 = d_can_plat_read_reg32; Patches currently in stable-queue which might be from rschuetz(a)uni-koblenz.de are queue-4.4/can-c_can-don-t-indicate-triple-sampling-support-for-d_can.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "can: sun4i: handle overrun in RX FIFO" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled can: sun4i: handle overrun in RX FIFO to the 4.13-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: can-sun4i-handle-overrun-in-rx-fifo.patch and it can be found in the queue-4.13 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 4dcf924c2eda0c47a5c53b7703e3dc65ddaa8920 Mon Sep 17 00:00:00 2001 From: Gerhard Bertelsmann <info(a)gerhard-bertelsmann.de> Date: Mon, 6 Nov 2017 18:16:56 +0100 Subject: can: sun4i: handle overrun in RX FIFO From: Gerhard Bertelsmann <info(a)gerhard-bertelsmann.de> commit 4dcf924c2eda0c47a5c53b7703e3dc65ddaa8920 upstream. SUN4Is CAN IP has a 64 byte deep FIFO buffer. If the buffer is not drained fast enough (overrun) it's getting mangled. Already received frames are dropped - the data can't be restored. Signed-off-by: Gerhard Bertelsmann <info(a)gerhard-bertelsmann.de> Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/can/sun4i_can.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) --- a/drivers/net/can/sun4i_can.c +++ b/drivers/net/can/sun4i_can.c @@ -539,6 +539,13 @@ static int sun4i_can_err(struct net_devi } stats->rx_over_errors++; stats->rx_errors++; + + /* reset the CAN IP by entering reset mode + * ignoring timeout error + */ + set_reset_mode(dev); + set_normal_mode(dev); + /* clear bit */ sun4i_can_write_cmdreg(priv, SUN4I_CMD_CLEAR_OR_FLAG); } @@ -653,8 +660,9 @@ static irqreturn_t sun4i_can_interrupt(i netif_wake_queue(dev); can_led_event(dev, CAN_LED_EVENT_TX); } - if (isrc & SUN4I_INT_RBUF_VLD) { - /* receive interrupt */ + if ((isrc & SUN4I_INT_RBUF_VLD) && + !(isrc & SUN4I_INT_DATA_OR)) { + /* receive interrupt - don't read if overrun occurred */ while (status & SUN4I_STA_RBUF_RDY) { /* RX buffer is not empty */ sun4i_can_rx(dev); Patches currently in stable-queue which might be from info(a)gerhard-bertelsmann.de are queue-4.13/can-sun4i-handle-overrun-in-rx-fifo.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "can: ifi: Fix transmitter delay calculation" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled can: ifi: Fix transmitter delay calculation to the 4.13-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: can-ifi-fix-transmitter-delay-calculation.patch and it can be found in the queue-4.13 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 4f7116757b4bd99e4ef2636c7d957a6d63035d11 Mon Sep 17 00:00:00 2001 From: Marek Vasut <marex(a)denx.de> Date: Fri, 10 Nov 2017 11:22:39 +0100 Subject: can: ifi: Fix transmitter delay calculation From: Marek Vasut <marex(a)denx.de> commit 4f7116757b4bd99e4ef2636c7d957a6d63035d11 upstream. The CANFD transmitter delay calculation formula was updated in the latest software drop from IFI and improves the behavior of the IFI CANFD core during bitrate switching. Use the new formula to improve stability of the CANFD operation. Signed-off-by: Marek Vasut <marex(a)denx.de> Cc: Markus Marb <markus(a)marb.org> Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/can/ifi_canfd/ifi_canfd.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/drivers/net/can/ifi_canfd/ifi_canfd.c +++ b/drivers/net/can/ifi_canfd/ifi_canfd.c @@ -670,9 +670,9 @@ static void ifi_canfd_set_bittiming(stru priv->base + IFI_CANFD_FTIME); /* Configure transmitter delay */ - tdc = (dbt->brp * (dbt->phase_seg1 + 1)) & IFI_CANFD_TDELAY_MASK; - writel(IFI_CANFD_TDELAY_EN | IFI_CANFD_TDELAY_ABS | tdc, - priv->base + IFI_CANFD_TDELAY); + tdc = dbt->brp * (dbt->prop_seg + dbt->phase_seg1); + tdc &= IFI_CANFD_TDELAY_MASK; + writel(IFI_CANFD_TDELAY_EN | tdc, priv->base + IFI_CANFD_TDELAY); } static void ifi_canfd_set_filter(struct net_device *ndev, const u32 id, Patches currently in stable-queue which might be from marex(a)denx.de are queue-4.13/can-ifi-fix-transmitter-delay-calculation.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "can: peak: Add support for new PCIe/M2 CAN FD interfaces" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled can: peak: Add support for new PCIe/M2 CAN FD interfaces to the 4.13-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: can-peak-add-support-for-new-pcie-m2-can-fd-interfaces.patch and it can be found in the queue-4.13 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 4cbdd0ee67191481ec57ceed94febdfef95c9f25 Mon Sep 17 00:00:00 2001 From: Stephane Grosjean <s.grosjean(a)peak-system.com> Date: Thu, 9 Nov 2017 14:42:14 +0100 Subject: can: peak: Add support for new PCIe/M2 CAN FD interfaces From: Stephane Grosjean <s.grosjean(a)peak-system.com> commit 4cbdd0ee67191481ec57ceed94febdfef95c9f25 upstream. This adds support for the following PEAK-System CAN FD interfaces: PCAN-cPCIe FD CAN FD Interface for cPCI Serial (2 or 4 channels) PCAN-PCIe/104-Express CAN FD Interface for PCIe/104-Express (1, 2 or 4 ch.) PCAN-miniPCIe FD CAN FD Interface for PCIe Mini (1, 2 or 4 channels) PCAN-PCIe FD OEM CAN FD Interface for PCIe OEM version (1, 2 or 4 ch.) PCAN-M.2 CAN FD Interface for M.2 (1 or 2 channels) Like the PCAN-PCIe FD interface, all of these boards run the same IP Core that is able to handle CAN FD (see also http://www.peak-system.com). Signed-off-by: Stephane Grosjean <s.grosjean(a)peak-system.com> Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/can/peak_canfd/peak_pciefd_main.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) --- a/drivers/net/can/peak_canfd/peak_pciefd_main.c +++ b/drivers/net/can/peak_canfd/peak_pciefd_main.c @@ -29,14 +29,19 @@ #include "peak_canfd_user.h" MODULE_AUTHOR("Stephane Grosjean <s.grosjean(a)peak-system.com>"); -MODULE_DESCRIPTION("Socket-CAN driver for PEAK PCAN PCIe FD family cards"); -MODULE_SUPPORTED_DEVICE("PEAK PCAN PCIe FD CAN cards"); +MODULE_DESCRIPTION("Socket-CAN driver for PEAK PCAN PCIe/M.2 FD family cards"); +MODULE_SUPPORTED_DEVICE("PEAK PCAN PCIe/M.2 FD CAN cards"); MODULE_LICENSE("GPL v2"); #define PCIEFD_DRV_NAME "peak_pciefd" #define PEAK_PCI_VENDOR_ID 0x001c /* The PCI device and vendor IDs */ #define PEAK_PCIEFD_ID 0x0013 /* for PCIe slot cards */ +#define PCAN_CPCIEFD_ID 0x0014 /* for Compact-PCI Serial slot cards */ +#define PCAN_PCIE104FD_ID 0x0017 /* for PCIe-104 Express slot cards */ +#define PCAN_MINIPCIEFD_ID 0x0018 /* for mini-PCIe slot cards */ +#define PCAN_PCIEFD_OEM_ID 0x0019 /* for PCIe slot OEM cards */ +#define PCAN_M2_ID 0x001a /* for M2 slot cards */ /* PEAK PCIe board access description */ #define PCIEFD_BAR0_SIZE (64 * 1024) @@ -203,6 +208,11 @@ struct pciefd_board { /* supported device ids. */ static const struct pci_device_id peak_pciefd_tbl[] = { {PEAK_PCI_VENDOR_ID, PEAK_PCIEFD_ID, PCI_ANY_ID, PCI_ANY_ID,}, + {PEAK_PCI_VENDOR_ID, PCAN_CPCIEFD_ID, PCI_ANY_ID, PCI_ANY_ID,}, + {PEAK_PCI_VENDOR_ID, PCAN_PCIE104FD_ID, PCI_ANY_ID, PCI_ANY_ID,}, + {PEAK_PCI_VENDOR_ID, PCAN_MINIPCIEFD_ID, PCI_ANY_ID, PCI_ANY_ID,}, + {PEAK_PCI_VENDOR_ID, PCAN_PCIEFD_OEM_ID, PCI_ANY_ID, PCI_ANY_ID,}, + {PEAK_PCI_VENDOR_ID, PCAN_M2_ID, PCI_ANY_ID, PCI_ANY_ID,}, {0,} }; Patches currently in stable-queue which might be from s.grosjean(a)peak-system.com are queue-4.13/can-peak-add-support-for-new-pcie-m2-can-fd-interfaces.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "can: c_can: don't indicate triple sampling support for D_CAN" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled can: c_can: don't indicate triple sampling support for D_CAN to the 4.13-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: can-c_can-don-t-indicate-triple-sampling-support-for-d_can.patch and it can be found in the queue-4.13 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 fb5f0b3ef69b95e665e4bbe8a3de7201f09f1071 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Richard=20Sch=C3=BCtz?= <rschuetz(a)uni-koblenz.de> Date: Sun, 29 Oct 2017 13:03:22 +0100 Subject: can: c_can: don't indicate triple sampling support for D_CAN MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Richard Schütz <rschuetz(a)uni-koblenz.de> commit fb5f0b3ef69b95e665e4bbe8a3de7201f09f1071 upstream. The D_CAN controller doesn't provide a triple sampling mode, so don't set the CAN_CTRLMODE_3_SAMPLES flag in ctrlmode_supported. Currently enabling triple sampling is a no-op. Signed-off-by: Richard Schütz <rschuetz(a)uni-koblenz.de> Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/can/c_can/c_can_pci.c | 1 - drivers/net/can/c_can/c_can_platform.c | 1 - 2 files changed, 2 deletions(-) --- a/drivers/net/can/c_can/c_can_pci.c +++ b/drivers/net/can/c_can/c_can_pci.c @@ -178,7 +178,6 @@ static int c_can_pci_probe(struct pci_de break; case BOSCH_D_CAN: priv->regs = reg_map_d_can; - priv->can.ctrlmode_supported |= CAN_CTRLMODE_3_SAMPLES; break; default: ret = -EINVAL; --- a/drivers/net/can/c_can/c_can_platform.c +++ b/drivers/net/can/c_can/c_can_platform.c @@ -320,7 +320,6 @@ static int c_can_plat_probe(struct platf break; case BOSCH_D_CAN: priv->regs = reg_map_d_can; - priv->can.ctrlmode_supported |= CAN_CTRLMODE_3_SAMPLES; priv->read_reg = c_can_plat_read_reg_aligned_to_16bit; priv->write_reg = c_can_plat_write_reg_aligned_to_16bit; priv->read_reg32 = d_can_plat_read_reg32; Patches currently in stable-queue which might be from rschuetz(a)uni-koblenz.de are queue-4.13/can-c_can-don-t-indicate-triple-sampling-support-for-d_can.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "can: c_can: don't indicate triple sampling support for D_CAN" 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 can: c_can: don't indicate triple sampling support for D_CAN 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: can-c_can-don-t-indicate-triple-sampling-support-for-d_can.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 fb5f0b3ef69b95e665e4bbe8a3de7201f09f1071 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Richard=20Sch=C3=BCtz?= <rschuetz(a)uni-koblenz.de> Date: Sun, 29 Oct 2017 13:03:22 +0100 Subject: can: c_can: don't indicate triple sampling support for D_CAN MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Richard Schütz <rschuetz(a)uni-koblenz.de> commit fb5f0b3ef69b95e665e4bbe8a3de7201f09f1071 upstream. The D_CAN controller doesn't provide a triple sampling mode, so don't set the CAN_CTRLMODE_3_SAMPLES flag in ctrlmode_supported. Currently enabling triple sampling is a no-op. Signed-off-by: Richard Schütz <rschuetz(a)uni-koblenz.de> Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/can/c_can/c_can_pci.c | 1 - drivers/net/can/c_can/c_can_platform.c | 1 - 2 files changed, 2 deletions(-) --- a/drivers/net/can/c_can/c_can_pci.c +++ b/drivers/net/can/c_can/c_can_pci.c @@ -177,7 +177,6 @@ static int c_can_pci_probe(struct pci_de break; case BOSCH_D_CAN: priv->regs = reg_map_d_can; - priv->can.ctrlmode_supported |= CAN_CTRLMODE_3_SAMPLES; break; default: ret = -EINVAL; --- a/drivers/net/can/c_can/c_can_platform.c +++ b/drivers/net/can/c_can/c_can_platform.c @@ -257,7 +257,6 @@ static int c_can_plat_probe(struct platf break; case BOSCH_D_CAN: priv->regs = reg_map_d_can; - priv->can.ctrlmode_supported |= CAN_CTRLMODE_3_SAMPLES; priv->read_reg = c_can_plat_read_reg_aligned_to_16bit; priv->write_reg = c_can_plat_write_reg_aligned_to_16bit; priv->read_reg32 = d_can_plat_read_reg32; Patches currently in stable-queue which might be from rschuetz(a)uni-koblenz.de are queue-3.18/can-c_can-don-t-indicate-triple-sampling-support-for-d_can.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH v2] mtd: Avoid probe failures when mtd->dbg.dfs_dir is invalid

by Boris Brezillon

Commit e8e3edb95ce6 ("mtd: create per-device and module-scope debugfs entries") tried to make MTD related debugfs stuff consistent across the MTD framework by creating a root <debugfs>/mtd/ directory containing one directory per MTD device. The problem is that, by default, the MTD layer only registers the master device if no partitions are defined for this master. This behavior breaks all drivers that expect mtd->dbg.dfs_dir to be filled correctly after calling mtd_device_register() in order to add their own debugfs entries. The only way we can force all MTD masters to be registered no matter if they expose partitions or not is by enabling the CONFIG_MTD_PARTITIONED_MASTER option. In such situations, there's no other solution but to accept skipping debugfs initialization when dbg.dfs_dir is invalid, and when this happens, inform the user that he should consider enabling CONFIG_MTD_PARTITIONED_MASTER. Fixes: e8e3edb95ce6 ("mtd: create per-device and module-scope debugfs entries") Cc: <stable(a)vger.kernel.org> Cc: Mario J. Rugiero <mrugiero(a)gmail.com> Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com> --- drivers/mtd/devices/docg3.c | 7 ++++++- drivers/mtd/nand/nandsim.c | 13 +++++++++---- 2 files changed, 15 insertions(+), 5 deletions(-) diff --git a/drivers/mtd/devices/docg3.c b/drivers/mtd/devices/docg3.c index 84b16133554b..0806f72102c0 100644 --- a/drivers/mtd/devices/docg3.c +++ b/drivers/mtd/devices/docg3.c @@ -1814,8 +1814,13 @@ static void __init doc_dbg_register(struct mtd_info *floor) struct dentry *root = floor->dbg.dfs_dir; struct docg3 *docg3 = floor->priv; - if (IS_ERR_OR_NULL(root)) + if (IS_ERR_OR_NULL(root)) { + if (IS_ENABLED(CONFIG_DEBUG_FS) && + !IS_ENABLED(CONFIG_MTD_PARTITIONED_MASTER)) + dev_warn(floor->dev.parent, + "CONFIG_MTD_PARTITIONED_MASTER must be enabled to expose debugfs stuff\n"); return; + } debugfs_create_file("docg3_flashcontrol", S_IRUSR, root, docg3, &flashcontrol_fops); diff --git a/drivers/mtd/nand/nandsim.c b/drivers/mtd/nand/nandsim.c index 246b4393118e..44322a363ba5 100644 --- a/drivers/mtd/nand/nandsim.c +++ b/drivers/mtd/nand/nandsim.c @@ -520,11 +520,16 @@ static int nandsim_debugfs_create(struct nandsim *dev) struct dentry *root = nsmtd->dbg.dfs_dir; struct dentry *dent; - if (!IS_ENABLED(CONFIG_DEBUG_FS)) + /* + * Just skip debugfs initialization when the debugfs directory is + * missing. + */ + if (IS_ERR_OR_NULL(root)) { + if (IS_ENABLED(CONFIG_DEBUG_FS) && + !IS_ENABLED(CONFIG_MTD_PARTITIONED_MASTER)) + NS_WARN("CONFIG_MTD_PARTITIONED_MASTER must be enabled to expose debugfs stuff\n"); return 0; - - if (IS_ERR_OR_NULL(root)) - return -1; + } dent = debugfs_create_file("nandsim_wear_report", S_IRUSR, root, dev, &dfs_fops); -- 2.11.0

7 years, 7 months

1
1
0 0

[Linux-stable-mirror] [PATCH] USB: ulpi: fix bus-node lookup

by Johan Hovold

Fix bus-node lookup during registration, which ended up searching the whole device tree depth-first starting at the parent (or grand parent) rather than just matching on its children. To make things worse, the parent (or grand-parent) node could end being prematurely freed as well. Fixes: ef6a7bcfb01c ("usb: ulpi: Support device discovery via DT") Reported-by: Peter Robinson <pbrobinson(a)gmail.com> Reported-by: Stephen Boyd <sboyd(a)codeaurora.org> Cc: stable <stable(a)vger.kernel.org> # 4.10 Signed-off-by: Johan Hovold <johan(a)kernel.org> --- drivers/usb/common/ulpi.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/common/ulpi.c b/drivers/usb/common/ulpi.c index 8b351444cc40..9a2ab6751a23 100644 --- a/drivers/usb/common/ulpi.c +++ b/drivers/usb/common/ulpi.c @@ -180,9 +180,9 @@ static int ulpi_of_register(struct ulpi *ulpi) /* Find a ulpi bus underneath the parent or the grandparent */ parent = ulpi->dev.parent; if (parent->of_node) - np = of_find_node_by_name(parent->of_node, "ulpi"); + np = of_get_child_by_name(parent->of_node, "ulpi"); else if (parent->parent && parent->parent->of_node) - np = of_find_node_by_name(parent->parent->of_node, "ulpi"); + np = of_get_child_by_name(parent->parent->of_node, "ulpi"); if (!np) return 0; -- 2.15.0

7 years, 7 months

1
0
0 0

Re: [Linux-stable-mirror] [RFC PATCH v2] Fix: x86: Add missing core serializing instruction on migration

by Mathieu Desnoyers

Fixing the stable(a)kernel.org CC. ----- On Nov 11, 2017, at 10:03 AM, Mathieu Desnoyers mathieu.desnoyers(a)efficios.com wrote: > x86 has a missing core serializing instruction in migration scenarios. > > Given that x86-32 can return to user-space with sysexit, and x86-64 > through sysretq and sysretl, which are not core serializing, the > following user-space self-modifiying code (JIT) scenario can occur: > > CPU 0 CPU 1 > > User-space self-modify code > Preempted > migrated -> > scheduler selects task > Return to user-space (iret or sysexit) > User-space issues sync_core() > <- migrated > scheduler selects task > Return to user-space (sysexit) > jump to modified code > Run modified code without sync_core() -> bug. > > This migration pattern can return to user-space through sysexit, > sysretl, or sysretq, which are not core serializing, and therefore > breaks sequential consistency expectations from a single-threaded > process. > > Fix this issue by introducing sync_core_before_usermode(), invoked the > first time a runqueue finishes a task switch after receiving a migrated > thread. > > Architectures defining the sync_core_before_usermode() static inline > need to define ARCH_HAS_SYNC_CORE_BEFORE_USERMODE. > > Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> > CC: Peter Zijlstra <peterz(a)infradead.org> > CC: Andy Lutomirski <luto(a)kernel.org> > CC: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com> > CC: Boqun Feng <boqun.feng(a)gmail.com> > CC: Andrew Hunter <ahh(a)google.com> > CC: Maged Michael <maged.michael(a)gmail.com> > CC: Avi Kivity <avi(a)scylladb.com> > CC: Benjamin Herrenschmidt <benh(a)kernel.crashing.org> > CC: Paul Mackerras <paulus(a)samba.org> > CC: Michael Ellerman <mpe(a)ellerman.id.au> > CC: Dave Watson <davejwatson(a)fb.com> > CC: Thomas Gleixner <tglx(a)linutronix.de> > CC: Ingo Molnar <mingo(a)redhat.com> > CC: "H. Peter Anvin" <hpa(a)zytor.com> > CC: Andrea Parri <parri.andrea(a)gmail.com> > CC: Russell King <linux(a)armlinux.org.uk> > CC: Greg Hackmann <ghackmann(a)google.com> > CC: Will Deacon <will.deacon(a)arm.com> > CC: David Sehr <sehr(a)google.com> > CC: Linus Torvalds <torvalds(a)linux-foundation.org> > CC: x86(a)kernel.org > CC: linux-arch(a)vger.kernel.org > CC: stable(a)kernel.org > > --- > Changes since v1: > - Fold patch introducing sync_core_before_usermode and the fix > into a single patch. > - CC stable(a)kernel.org > --- > arch/x86/Kconfig | 1 + > arch/x86/include/asm/processor.h | 10 ++++++++++ > include/linux/processor.h | 6 ++++++ > kernel/sched/core.c | 7 +++++++ > kernel/sched/sched.h | 1 + > 5 files changed, 25 insertions(+) > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 2fdb23313dd5..b27456f04cc6 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -62,6 +62,7 @@ config X86 > select ARCH_HAS_SG_CHAIN > select ARCH_HAS_STRICT_KERNEL_RWX > select ARCH_HAS_STRICT_MODULE_RWX > + select ARCH_HAS_SYNC_CORE_BEFORE_USERMODE > select ARCH_HAS_UBSAN_SANITIZE_ALL > select ARCH_HAS_ZONE_DEVICE if X86_64 > select ARCH_HAVE_NMI_SAFE_CMPXCHG > diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h > index bdac19ab2488..6daf70a8c81c 100644 > --- a/arch/x86/include/asm/processor.h > +++ b/arch/x86/include/asm/processor.h > @@ -706,6 +706,16 @@ static inline void sync_core(void) > #endif > } > > +/* > + * Ensure that a core serializing instruction is issued before returning > + * to user-mode. x86 implements return to user-space through sysexit, > + * sysretl, and sysretq, which are not core serializing. > + */ > +static inline void sync_core_before_usermode(void) > +{ > + sync_core(); > +} > + > extern void select_idle_routine(const struct cpuinfo_x86 *c); > extern void amd_e400_c1e_apic_setup(void); > > diff --git a/include/linux/processor.h b/include/linux/processor.h > index dbc952eec869..7d12e6fa050e 100644 > --- a/include/linux/processor.h > +++ b/include/linux/processor.h > @@ -68,4 +68,10 @@ do { \ > > #endif > > +#ifndef ARCH_HAS_SYNC_CORE_BEFORE_USERMODE > +static inline sync_core_before_usermode(void) > +{ > +} > +#endif > + > #endif /* _LINUX_PROCESSOR_H */ > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > index d17c5da523a0..39c0bbe8f259 100644 > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -927,6 +927,7 @@ static struct rq *move_queued_task(struct rq *rq, struct > rq_flags *rf, > > rq_lock(rq, rf); > BUG_ON(task_cpu(p) != new_cpu); > + rq->need_sync_core = 1; > enqueue_task(rq, p, 0); > p->on_rq = TASK_ON_RQ_QUEUED; > check_preempt_curr(rq, p, 0); > @@ -2654,6 +2655,12 @@ static struct rq *finish_task_switch(struct task_struct > *prev) > * to use. > */ > smp_mb__after_unlock_lock(); > +#ifdef CONFIG_SMP > + if (unlikely(rq->need_sync_core)) { > + sync_core_before_usermode(); > + rq->need_sync_core = 0; > + } > +#endif > finish_lock_switch(rq, prev); > finish_arch_post_lock_switch(); > > diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h > index 3b448ba82225..e02cc362637c 100644 > --- a/kernel/sched/sched.h > +++ b/kernel/sched/sched.h > @@ -734,6 +734,7 @@ struct rq { > /* For active balancing */ > int active_balance; > int push_cpu; > + int need_sync_core; > struct cpu_stop_work active_balance_work; > /* cpu of this runqueue: */ > int cpu; > -- > 2.11.0 -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH] mtd: Fix debugfs file creation when mtd->->dbg.dfs_dir is invalid

by Boris Brezillon

Commit e8e3edb95ce6 ("mtd: create per-device and module-scope debugfs entries") tried to make MTD related debugfs stuff consistent across the MTD framework by creating a root <debugfs>/mtd/ directory containing one directory per MTD device. The problem is that, by default, the MTD layer only registers the master device if no partitions are defined for this master. This behavior breaks all drivers that expect mtd->dbg.dfs_dir to be filled correctly after calling mtd_device_register() in order to add their own debugfs entries. The only way we can force all MTD masters to be registered no matter if they expose partitions or not is by enabling the CONFIG_MTD_PARTITIONED_MASTER option. In such situations, there's no other solution but to accept skipping debugfs initialization when dbg.dfs_dir is invalid, and when this happens, inform the user that he should consider enabling CONFIG_MTD_PARTITIONED_MASTER. Fixes: e8e3edb95ce6 ("mtd: create per-device and module-scope debugfs entries") Cc: <stable(a)vger.kernel.org> Cc: Mario J. Rugiero <mrugiero(a)gmail.com> Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com> --- drivers/mtd/devices/docg3.c | 7 ++++++- drivers/mtd/nand/nandsim.c | 12 +++++++++--- 2 files changed, 15 insertions(+), 4 deletions(-) diff --git a/drivers/mtd/devices/docg3.c b/drivers/mtd/devices/docg3.c index 84b16133554b..0806f72102c0 100644 --- a/drivers/mtd/devices/docg3.c +++ b/drivers/mtd/devices/docg3.c @@ -1814,8 +1814,13 @@ static void __init doc_dbg_register(struct mtd_info *floor) struct dentry *root = floor->dbg.dfs_dir; struct docg3 *docg3 = floor->priv; - if (IS_ERR_OR_NULL(root)) + if (IS_ERR_OR_NULL(root)) { + if (IS_ENABLED(CONFIG_DEBUG_FS) && + !IS_ENABLED(CONFIG_MTD_PARTITIONED_MASTER)) + dev_warn(floor->dev.parent, + "CONFIG_MTD_PARTITIONED_MASTER must be enabled to expose debugfs stuff\n"); return; + } debugfs_create_file("docg3_flashcontrol", S_IRUSR, root, docg3, &flashcontrol_fops); diff --git a/drivers/mtd/nand/nandsim.c b/drivers/mtd/nand/nandsim.c index 246b4393118e..a22f4d7ca1cb 100644 --- a/drivers/mtd/nand/nandsim.c +++ b/drivers/mtd/nand/nandsim.c @@ -520,11 +520,17 @@ static int nandsim_debugfs_create(struct nandsim *dev) struct dentry *root = nsmtd->dbg.dfs_dir; struct dentry *dent; - if (!IS_ENABLED(CONFIG_DEBUG_FS)) - return 0; + if (IS_ENABLED(CONFIG_DEBUG_FS) && + !IS_ENABLED(CONFIG_MTD_PARTITIONED_MASTER) && + dev->nbparts) + NS_WARN("CONFIG_MTD_PARTITIONED_MASTER must be enabled to expose debugfs stuff\n"); + /* + * Just skip debugfs initialization when the debugfs directory is + * missing. + */ if (IS_ERR_OR_NULL(root)) - return -1; + return 0; dent = debugfs_create_file("nandsim_wear_report", S_IRUSR, root, dev, &dfs_fops); -- 2.11.0

7 years, 7 months

1
2
0 0

[Linux-stable-mirror] [PATCH v3 01/11] drm/i915: Update watermark state correctly in sanitize_watermarks

by Maarten Lankhorst

We no longer use intel_crtc->wm.active for watermarks any more, which was incorrect. But this uncovered a bug in sanitize_watermarks(), which meant that we wrote the correct watermarks, but the next update would still use the wrong hw watermarks for calculating. This caused all further updates to fail with -EINVAL and the log would reveal an error like the one below: [ 10.043902] [drm:ilk_validate_wm_level.part.8 [i915]] Sprite WM0 too large 56 (max 0) [ 10.043960] [drm:ilk_validate_pipe_wm [i915]] LP0 watermark invalid [ 10.044030] [drm:intel_crtc_atomic_check [i915]] No valid intermediate pipe watermarks are possible Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Fixes: b6b178a77210 ("drm/i915: Calculate ironlake intermediate watermarks correctly, v2.") Cc: stable(a)vger.kernel.org #v4.8+ --- drivers/gpu/drm/i915/intel_display.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 84817ccc5305..17665ee06c9a 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -14442,6 +14442,8 @@ static void sanitize_watermarks(struct drm_device *dev) cs->wm.need_postvbl_update = true; dev_priv->display.optimize_watermarks(intel_state, cs); + + to_intel_crtc_state(crtc->state)->wm = cs->wm; } put_state: -- 2.15.0

7 years, 7 months

2
2
0 0

[Linux-stable-mirror] Patch "drm/bridge: adv7511: Rework adv7511_power_on/off() so they can be reused internally" 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/bridge: adv7511: Rework adv7511_power_on/off() so they can be reused internally 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-bridge-adv7511-rework-adv7511_power_on-off-so-they-can-be-reused-internally.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 651e4769ba2a9f20c4b8a823ae2727bf7fa9c9f0 Mon Sep 17 00:00:00 2001 From: John Stultz <john.stultz(a)linaro.org> Date: Mon, 16 Jan 2017 16:52:50 -0800 Subject: drm/bridge: adv7511: Rework adv7511_power_on/off() so they can be reused internally From: John Stultz <john.stultz(a)linaro.org> commit 651e4769ba2a9f20c4b8a823ae2727bf7fa9c9f0 upstream. In chasing down issues with EDID probing, I found some duplicated but incomplete logic used to power the chip on and off. This patch refactors the adv7511_power_on/off functions, so they can be used for internal needs. Cc: David Airlie <airlied(a)linux.ie> Cc: Archit Taneja <architt(a)codeaurora.org> Cc: Wolfram Sang <wsa+renesas(a)sang-engineering.com> Cc: Lars-Peter Clausen <lars(a)metafoo.de> Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Cc: dri-devel(a)lists.freedesktop.org Signed-off-by: John Stultz <john.stultz(a)linaro.org> Signed-off-by: Archit Taneja <architt(a)codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1484614372-15342-5-git-send-em… Signed-off-by: Nhan Nguyen <nhan.nguyen.yb(a)renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c @@ -325,7 +325,7 @@ static void adv7511_set_link_config(stru adv7511->rgb = config->input_colorspace == HDMI_COLORSPACE_RGB; } -static void adv7511_power_on(struct adv7511 *adv7511) +static void __adv7511_power_on(struct adv7511 *adv7511) { adv7511->current_edid_segment = -1; @@ -354,6 +354,11 @@ static void adv7511_power_on(struct adv7 regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER2, ADV7511_REG_POWER2_HPD_SRC_MASK, ADV7511_REG_POWER2_HPD_SRC_NONE); +} + +static void adv7511_power_on(struct adv7511 *adv7511) +{ + __adv7511_power_on(adv7511); /* * Most of the registers are reset during power down or when HPD is low. @@ -362,21 +367,23 @@ static void adv7511_power_on(struct adv7 if (adv7511->type == ADV7533) adv7533_dsi_power_on(adv7511); - adv7511->powered = true; } -static void adv7511_power_off(struct adv7511 *adv7511) +static void __adv7511_power_off(struct adv7511 *adv7511) { /* TODO: setup additional power down modes */ regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER, ADV7511_POWER_POWER_DOWN, ADV7511_POWER_POWER_DOWN); regcache_mark_dirty(adv7511->regmap); +} +static void adv7511_power_off(struct adv7511 *adv7511) +{ + __adv7511_power_off(adv7511); if (adv7511->type == ADV7533) adv7533_dsi_power_off(adv7511); - adv7511->powered = false; } Patches currently in stable-queue which might be from john.stultz(a)linaro.org are queue-4.9/drm-bridge-adv7511-re-write-the-i2c-address-before-edid-probing.patch queue-4.9/drm-bridge-adv7511-rework-adv7511_power_on-off-so-they-can-be-reused-internally.patch queue-4.9/drm-bridge-adv7511-reuse-__adv7511_power_on-off-when-probing-edid.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/bridge: adv7511: Reuse __adv7511_power_on/off() when probing EDID" 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/bridge: adv7511: Reuse __adv7511_power_on/off() when probing EDID 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-bridge-adv7511-reuse-__adv7511_power_on-off-when-probing-edid.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 4226d9b127cf4758ba0e07931b3f0d59f1b1a50c Mon Sep 17 00:00:00 2001 From: John Stultz <john.stultz(a)linaro.org> Date: Mon, 16 Jan 2017 16:52:51 -0800 Subject: drm/bridge: adv7511: Reuse __adv7511_power_on/off() when probing EDID From: John Stultz <john.stultz(a)linaro.org> commit 4226d9b127cf4758ba0e07931b3f0d59f1b1a50c upstream. Thus this patch changes the EDID probing logic so that we re-use the __adv7511_power_on/off() calls instead of duplciating logic. This does change behavior slightly as it adds the HPD signal pulse to the EDID probe path, but Archit has had a patch to add HPD signal pulse to the EDID probe path before, so this should address the cases where that helped. Another difference is that regcache_mark_dirty() is also called in the power off path once EDID is probed. Cc: David Airlie <airlied(a)linux.ie> Cc: Archit Taneja <architt(a)codeaurora.org> Cc: Wolfram Sang <wsa+renesas(a)sang-engineering.com> Cc: Lars-Peter Clausen <lars(a)metafoo.de> Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Cc: dri-devel(a)lists.freedesktop.org Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Tested-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Signed-off-by: John Stultz <john.stultz(a)linaro.org> Signed-off-by: Archit Taneja <architt(a)codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1484614372-15342-6-git-send-em… Signed-off-by: Nhan Nguyen <nhan.nguyen.yb(a)renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 17 +++-------------- 1 file changed, 3 insertions(+), 14 deletions(-) --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c @@ -573,24 +573,13 @@ static int adv7511_get_modes(struct adv7 unsigned int count; /* Reading the EDID only works if the device is powered */ - if (!adv7511->powered) { - regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER, - ADV7511_POWER_POWER_DOWN, 0); - if (adv7511->i2c_main->irq) { - regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(0), - ADV7511_INT0_EDID_READY); - regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(1), - ADV7511_INT1_DDC_ERROR); - } - adv7511->current_edid_segment = -1; - } + if (!adv7511->powered) + __adv7511_power_on(adv7511); edid = drm_do_get_edid(connector, adv7511_get_edid_block, adv7511); if (!adv7511->powered) - regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER, - ADV7511_POWER_POWER_DOWN, - ADV7511_POWER_POWER_DOWN); + __adv7511_power_off(adv7511); kfree(adv7511->edid); adv7511->edid = edid; Patches currently in stable-queue which might be from john.stultz(a)linaro.org are queue-4.9/drm-bridge-adv7511-re-write-the-i2c-address-before-edid-probing.patch queue-4.9/drm-bridge-adv7511-rework-adv7511_power_on-off-so-they-can-be-reused-internally.patch queue-4.9/drm-bridge-adv7511-reuse-__adv7511_power_on-off-when-probing-edid.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/bridge: adv7511: Re-write the i2c address before EDID probing" 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/bridge: adv7511: Re-write the i2c address before EDID probing 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-bridge-adv7511-re-write-the-i2c-address-before-edid-probing.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 3587c856675c45809010c2cee5b21096f6e8e938 Mon Sep 17 00:00:00 2001 From: John Stultz <john.stultz(a)linaro.org> Date: Mon, 16 Jan 2017 16:52:52 -0800 Subject: drm/bridge: adv7511: Re-write the i2c address before EDID probing From: John Stultz <john.stultz(a)linaro.org> commit 3587c856675c45809010c2cee5b21096f6e8e938 upstream. I've found that by just turning the chip on and off via the POWER_DOWN register, I end up getting i2c_transfer errors on HiKey. Investigating further, it turns out that some of the register state in hardware is getting lost, as the device registers are reset when the chip is powered down. Thus this patch simply re-writes the i2c address to the ADV7511_REG_EDID_I2C_ADDR register to ensure its properly set before we try to read the EDID data. Cc: David Airlie <airlied(a)linux.ie> Cc: Archit Taneja <architt(a)codeaurora.org> Cc: Wolfram Sang <wsa+renesas(a)sang-engineering.com> Cc: Lars-Peter Clausen <lars(a)metafoo.de> Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Cc: dri-devel(a)lists.freedesktop.org Reviewed-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Tested-by: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Signed-off-by: John Stultz <john.stultz(a)linaro.org> Signed-off-by: Archit Taneja <architt(a)codeaurora.org> Link: http://patchwork.freedesktop.org/patch/msgid/1484614372-15342-7-git-send-em… Signed-off-by: Nhan Nguyen <nhan.nguyen.yb(a)renesas.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c @@ -573,9 +573,17 @@ static int adv7511_get_modes(struct adv7 unsigned int count; /* Reading the EDID only works if the device is powered */ - if (!adv7511->powered) + if (!adv7511->powered) { + unsigned int edid_i2c_addr = + (adv7511->i2c_main->addr << 1) + 4; + __adv7511_power_on(adv7511); + /* Reset the EDID_I2C_ADDR register as it might be cleared */ + regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR, + edid_i2c_addr); + } + edid = drm_do_get_edid(connector, adv7511_get_edid_block, adv7511); if (!adv7511->powered) Patches currently in stable-queue which might be from john.stultz(a)linaro.org are queue-4.9/drm-bridge-adv7511-re-write-the-i2c-address-before-edid-probing.patch queue-4.9/drm-bridge-adv7511-rework-adv7511_power_on-off-so-they-can-be-reused-internally.patch queue-4.9/drm-bridge-adv7511-reuse-__adv7511_power_on-off-when-probing-edid.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "rbd: use GFP_NOIO for parent stat and data requests" 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 rbd: use GFP_NOIO for parent stat and data requests 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: rbd-use-gfp_noio-for-parent-stat-and-data-requests.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 1e37f2f84680fa7f8394fd444b6928e334495ccc Mon Sep 17 00:00:00 2001 From: Ilya Dryomov <idryomov(a)gmail.com> Date: Mon, 6 Nov 2017 11:33:36 +0100 Subject: rbd: use GFP_NOIO for parent stat and data requests From: Ilya Dryomov <idryomov(a)gmail.com> commit 1e37f2f84680fa7f8394fd444b6928e334495ccc upstream. rbd_img_obj_exists_submit() and rbd_img_obj_parent_read_full() are on the writeback path for cloned images -- we attempt a stat on the parent object to see if it exists and potentially read it in to call copyup. GFP_NOIO should be used instead of GFP_KERNEL here. Link: http://tracker.ceph.com/issues/22014 Signed-off-by: Ilya Dryomov <idryomov(a)gmail.com> Reviewed-by: David Disseldorp <ddiss(a)suse.de> [idryomov(a)gmail.com: backport to < 4.9: context] Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/block/rbd.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/block/rbd.c +++ b/drivers/block/rbd.c @@ -2736,7 +2736,7 @@ static int rbd_img_obj_parent_read_full( * from the parent. */ page_count = (u32)calc_pages_for(0, length); - pages = ceph_alloc_page_vector(page_count, GFP_KERNEL); + pages = ceph_alloc_page_vector(page_count, GFP_NOIO); if (IS_ERR(pages)) { result = PTR_ERR(pages); pages = NULL; @@ -2863,7 +2863,7 @@ static int rbd_img_obj_exists_submit(str */ size = sizeof (__le64) + sizeof (__le32) + sizeof (__le32); page_count = (u32)calc_pages_for(0, size); - pages = ceph_alloc_page_vector(page_count, GFP_KERNEL); + pages = ceph_alloc_page_vector(page_count, GFP_NOIO); if (IS_ERR(pages)) return PTR_ERR(pages); Patches currently in stable-queue which might be from idryomov(a)gmail.com are queue-4.4/rbd-use-gfp_noio-for-parent-stat-and-data-requests.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH 1/2] KEYS: trusted: sanitize all key material

by Eric Biggers

commit ee618b4619b72527aaed765f0f0b74072b281159 upstream. [Please apply to 3.18-stable.] As the previous patch did for encrypted-keys, zero sensitive any potentially sensitive data related to the "trusted" key type before it is freed. Notably, we were not zeroing the tpm_buf structures in which the actual key is stored for TPM seal and unseal, nor were we zeroing the trusted_key_payload in certain error paths. Cc: Mimi Zohar <zohar(a)linux.vnet.ibm.com> Cc: David Safford <safford(a)us.ibm.com> Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: James Morris <james.l.morris(a)oracle.com> --- security/keys/trusted.c | 49 ++++++++++++++++++++++--------------------------- 1 file changed, 22 insertions(+), 27 deletions(-) diff --git a/security/keys/trusted.c b/security/keys/trusted.c index aeb38f1a12e7..917453895cbc 100644 --- a/security/keys/trusted.c +++ b/security/keys/trusted.c @@ -69,7 +69,7 @@ static int TSS_sha1(const unsigned char *data, unsigned int datalen, } ret = crypto_shash_digest(&sdesc->shash, data, datalen, digest); - kfree(sdesc); + kzfree(sdesc); return ret; } @@ -113,7 +113,7 @@ static int TSS_rawhmac(unsigned char *digest, const unsigned char *key, if (!ret) ret = crypto_shash_final(&sdesc->shash, digest); out: - kfree(sdesc); + kzfree(sdesc); return ret; } @@ -164,7 +164,7 @@ static int TSS_authhmac(unsigned char *digest, const unsigned char *key, paramdigest, TPM_NONCE_SIZE, h1, TPM_NONCE_SIZE, h2, 1, &c, 0, 0); out: - kfree(sdesc); + kzfree(sdesc); return ret; } @@ -245,7 +245,7 @@ static int TSS_checkhmac1(unsigned char *buffer, if (memcmp(testhmac, authdata, SHA1_DIGEST_SIZE)) ret = -EINVAL; out: - kfree(sdesc); + kzfree(sdesc); return ret; } @@ -346,7 +346,7 @@ static int TSS_checkhmac2(unsigned char *buffer, if (memcmp(testhmac2, authdata2, SHA1_DIGEST_SIZE)) ret = -EINVAL; out: - kfree(sdesc); + kzfree(sdesc); return ret; } @@ -563,7 +563,7 @@ static int tpm_seal(struct tpm_buf *tb, uint16_t keytype, *bloblen = storedsize; } out: - kfree(td); + kzfree(td); return ret; } @@ -677,7 +677,7 @@ static int key_seal(struct trusted_key_payload *p, if (ret < 0) pr_info("trusted_key: srkseal failed (%d)\n", ret); - kfree(tb); + kzfree(tb); return ret; } @@ -702,7 +702,7 @@ static int key_unseal(struct trusted_key_payload *p, /* pull migratable flag out of sealed key */ p->migratable = p->key[--p->key_len]; - kfree(tb); + kzfree(tb); return ret; } @@ -961,12 +961,12 @@ static int trusted_instantiate(struct key *key, if (!ret && options->pcrlock) ret = pcrlock(options->pcrlock); out: - kfree(datablob); - kfree(options); + kzfree(datablob); + kzfree(options); if (!ret) rcu_assign_keypointer(key, payload); else - kfree(payload); + kzfree(payload); return ret; } @@ -975,8 +975,7 @@ static void trusted_rcu_free(struct rcu_head *rcu) struct trusted_key_payload *p; p = container_of(rcu, struct trusted_key_payload, rcu); - memset(p->key, 0, p->key_len); - kfree(p); + kzfree(p); } /* @@ -1018,9 +1017,10 @@ static int trusted_update(struct key *key, struct key_preparsed_payload *prep) ret = datablob_parse(datablob, new_p, new_o); if (ret != Opt_update) { ret = -EINVAL; - kfree(new_p); + kzfree(new_p); goto out; } + /* copy old key values, and reseal with new pcrs */ new_p->migratable = p->migratable; new_p->key_len = p->key_len; @@ -1031,22 +1031,22 @@ static int trusted_update(struct key *key, struct key_preparsed_payload *prep) ret = key_seal(new_p, new_o); if (ret < 0) { pr_info("trusted_key: key_seal failed (%d)\n", ret); - kfree(new_p); + kzfree(new_p); goto out; } if (new_o->pcrlock) { ret = pcrlock(new_o->pcrlock); if (ret < 0) { pr_info("trusted_key: pcrlock failed (%d)\n", ret); - kfree(new_p); + kzfree(new_p); goto out; } } rcu_assign_keypointer(key, new_p); call_rcu(&p->rcu, trusted_rcu_free); out: - kfree(datablob); - kfree(new_o); + kzfree(datablob); + kzfree(new_o); return ret; } @@ -1075,24 +1075,19 @@ static long trusted_read(const struct key *key, char __user *buffer, for (i = 0; i < p->blob_len; i++) bufp = hex_byte_pack(bufp, p->blob[i]); if ((copy_to_user(buffer, ascii_buf, 2 * p->blob_len)) != 0) { - kfree(ascii_buf); + kzfree(ascii_buf); return -EFAULT; } - kfree(ascii_buf); + kzfree(ascii_buf); return 2 * p->blob_len; } /* - * trusted_destroy - before freeing the key, clear the decrypted data + * trusted_destroy - clear and free the key's payload */ static void trusted_destroy(struct key *key) { - struct trusted_key_payload *p = key->payload.data; - - if (!p) - return; - memset(p->key, 0, p->key_len); - kfree(key->payload.data); + kzfree(key->payload.data); } struct key_type key_type_trusted = { -- 2.15.0.448.gf294e3d99a-goog

7 years, 7 months

2
2
0 0

[Linux-stable-mirror] Patch "rbd: use GFP_NOIO for parent stat and data requests" 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 rbd: use GFP_NOIO for parent stat and data requests 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: rbd-use-gfp_noio-for-parent-stat-and-data-requests.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 1e37f2f84680fa7f8394fd444b6928e334495ccc Mon Sep 17 00:00:00 2001 From: Ilya Dryomov <idryomov(a)gmail.com> Date: Mon, 6 Nov 2017 11:33:36 +0100 Subject: rbd: use GFP_NOIO for parent stat and data requests From: Ilya Dryomov <idryomov(a)gmail.com> commit 1e37f2f84680fa7f8394fd444b6928e334495ccc upstream. rbd_img_obj_exists_submit() and rbd_img_obj_parent_read_full() are on the writeback path for cloned images -- we attempt a stat on the parent object to see if it exists and potentially read it in to call copyup. GFP_NOIO should be used instead of GFP_KERNEL here. Link: http://tracker.ceph.com/issues/22014 Signed-off-by: Ilya Dryomov <idryomov(a)gmail.com> Reviewed-by: David Disseldorp <ddiss(a)suse.de> [idryomov(a)gmail.com: backport to < 4.9: context] Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/block/rbd.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/block/rbd.c +++ b/drivers/block/rbd.c @@ -2700,7 +2700,7 @@ static int rbd_img_obj_parent_read_full( * from the parent. */ page_count = (u32)calc_pages_for(0, length); - pages = ceph_alloc_page_vector(page_count, GFP_KERNEL); + pages = ceph_alloc_page_vector(page_count, GFP_NOIO); if (IS_ERR(pages)) { result = PTR_ERR(pages); pages = NULL; @@ -2827,7 +2827,7 @@ static int rbd_img_obj_exists_submit(str */ size = sizeof (__le64) + sizeof (__le32) + sizeof (__le32); page_count = (u32)calc_pages_for(0, size); - pages = ceph_alloc_page_vector(page_count, GFP_KERNEL); + pages = ceph_alloc_page_vector(page_count, GFP_NOIO); if (IS_ERR(pages)) return PTR_ERR(pages); Patches currently in stable-queue which might be from idryomov(a)gmail.com are queue-3.18/rbd-use-gfp_noio-for-parent-stat-and-data-requests.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "KEYS: trusted: fix writing past end of buffer in trusted_read()" 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 KEYS: trusted: fix writing past end of buffer in trusted_read() 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: keys-trusted-fix-writing-past-end-of-buffer-in-trusted_read.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 a3c812f7cfd80cf51e8f5b7034f7418f6beb56c1 Mon Sep 17 00:00:00 2001 From: Eric Biggers <ebiggers(a)google.com> Date: Thu, 2 Nov 2017 00:47:12 +0000 Subject: KEYS: trusted: fix writing past end of buffer in trusted_read() From: Eric Biggers <ebiggers(a)google.com> commit a3c812f7cfd80cf51e8f5b7034f7418f6beb56c1 upstream. When calling keyctl_read() on a key of type "trusted", if the user-supplied buffer was too small, the kernel ignored the buffer length and just wrote past the end of the buffer, potentially corrupting userspace memory. Fix it by instead returning the size required, as per the documentation for keyctl_read(). We also don't even fill the buffer at all in this case, as this is slightly easier to implement than doing a short read, and either behavior appears to be permitted. It also makes it match the behavior of the "encrypted" key type. Fixes: d00a1c72f7f4 ("keys: add new trusted key-type") Reported-by: Ben Hutchings <ben(a)decadent.org.uk> Cc: <stable(a)vger.kernel.org> # v2.6.38+ Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Reviewed-by: Mimi Zohar <zohar(a)linux.vnet.ibm.com> Reviewed-by: James Morris <james.l.morris(a)oracle.com> Signed-off-by: James Morris <james.l.morris(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- security/keys/trusted.c | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) --- a/security/keys/trusted.c +++ b/security/keys/trusted.c @@ -1065,20 +1065,21 @@ static long trusted_read(const struct ke p = rcu_dereference_key(key); if (!p) return -EINVAL; - if (!buffer || buflen <= 0) - return 2 * p->blob_len; - ascii_buf = kmalloc(2 * p->blob_len, GFP_KERNEL); - if (!ascii_buf) - return -ENOMEM; - bufp = ascii_buf; - for (i = 0; i < p->blob_len; i++) - bufp = hex_byte_pack(bufp, p->blob[i]); - if ((copy_to_user(buffer, ascii_buf, 2 * p->blob_len)) != 0) { + if (buffer && buflen >= 2 * p->blob_len) { + ascii_buf = kmalloc(2 * p->blob_len, GFP_KERNEL); + if (!ascii_buf) + return -ENOMEM; + + bufp = ascii_buf; + for (i = 0; i < p->blob_len; i++) + bufp = hex_byte_pack(bufp, p->blob[i]); + if (copy_to_user(buffer, ascii_buf, 2 * p->blob_len) != 0) { + kzfree(ascii_buf); + return -EFAULT; + } kzfree(ascii_buf); - return -EFAULT; } - kzfree(ascii_buf); return 2 * p->blob_len; } Patches currently in stable-queue which might be from ebiggers(a)google.com are queue-3.18/keys-trusted-sanitize-all-key-material.patch queue-3.18/keys-trusted-fix-writing-past-end-of-buffer-in-trusted_read.patch queue-3.18/keys-fix-null-pointer-dereference-during-asn.1-parsing.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Backport of 1e37f2f84680

by Ilya Dryomov

Hi stable, Please apply the following backport of 1e37f2f84680 ("rbd: use GFP_NOIO for parent stat and data requests") to 4.4, 4.1 and earlier kernels. Thanks, Ilya

7 years, 7 months

2
2
0 0

[Linux-stable-mirror] Patch "rbd: use GFP_NOIO for parent stat and data requests" 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 rbd: use GFP_NOIO for parent stat and data requests 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: rbd-use-gfp_noio-for-parent-stat-and-data-requests.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 1e37f2f84680fa7f8394fd444b6928e334495ccc Mon Sep 17 00:00:00 2001 From: Ilya Dryomov <idryomov(a)gmail.com> Date: Mon, 6 Nov 2017 11:33:36 +0100 Subject: rbd: use GFP_NOIO for parent stat and data requests From: Ilya Dryomov <idryomov(a)gmail.com> commit 1e37f2f84680fa7f8394fd444b6928e334495ccc upstream. rbd_img_obj_exists_submit() and rbd_img_obj_parent_read_full() are on the writeback path for cloned images -- we attempt a stat on the parent object to see if it exists and potentially read it in to call copyup. GFP_NOIO should be used instead of GFP_KERNEL here. Link: http://tracker.ceph.com/issues/22014 Signed-off-by: Ilya Dryomov <idryomov(a)gmail.com> Reviewed-by: David Disseldorp <ddiss(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/block/rbd.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/block/rbd.c +++ b/drivers/block/rbd.c @@ -2788,7 +2788,7 @@ static int rbd_img_obj_parent_read_full( * from the parent. */ page_count = (u32)calc_pages_for(0, length); - pages = ceph_alloc_page_vector(page_count, GFP_KERNEL); + pages = ceph_alloc_page_vector(page_count, GFP_NOIO); if (IS_ERR(pages)) { result = PTR_ERR(pages); pages = NULL; @@ -2922,7 +2922,7 @@ static int rbd_img_obj_exists_submit(str */ size = sizeof (__le64) + sizeof (__le32) + sizeof (__le32); page_count = (u32)calc_pages_for(0, size); - pages = ceph_alloc_page_vector(page_count, GFP_KERNEL); + pages = ceph_alloc_page_vector(page_count, GFP_NOIO); if (IS_ERR(pages)) { ret = PTR_ERR(pages); goto fail_stat_request; Patches currently in stable-queue which might be from idryomov(a)gmail.com are queue-4.9/rbd-use-gfp_noio-for-parent-stat-and-data-requests.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "MIPS: BMIPS: Fix missing cbr address" 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 MIPS: BMIPS: Fix missing cbr address 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: mips-bmips-fix-missing-cbr-address.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 ea4b3afe1eac8f88bb453798a084fba47a1f155a Mon Sep 17 00:00:00 2001 From: Jaedon Shin <jaedon.shin(a)gmail.com> Date: Fri, 16 Jun 2017 20:03:01 +0900 Subject: MIPS: BMIPS: Fix missing cbr address From: Jaedon Shin <jaedon.shin(a)gmail.com> commit ea4b3afe1eac8f88bb453798a084fba47a1f155a upstream. Fix NULL pointer access in BMIPS3300 RAC flush. Fixes: 738a3f79027b ("MIPS: BMIPS: Add early CPU initialization code") Signed-off-by: Jaedon Shin <jaedon.shin(a)gmail.com> Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com> Cc: Kevin Cernekee <cernekee(a)gmail.com> Cc: linux-mips(a)linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/16423/ Signed-off-by: James Hogan <jhogan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/kernel/smp-bmips.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/arch/mips/kernel/smp-bmips.c +++ b/arch/mips/kernel/smp-bmips.c @@ -587,11 +587,11 @@ void __init bmips_cpu_setup(void) /* Flush and enable RAC */ cfg = __raw_readl(cbr + BMIPS_RAC_CONFIG); - __raw_writel(cfg | 0x100, BMIPS_RAC_CONFIG); + __raw_writel(cfg | 0x100, cbr + BMIPS_RAC_CONFIG); __raw_readl(cbr + BMIPS_RAC_CONFIG); cfg = __raw_readl(cbr + BMIPS_RAC_CONFIG); - __raw_writel(cfg | 0xf, BMIPS_RAC_CONFIG); + __raw_writel(cfg | 0xf, cbr + BMIPS_RAC_CONFIG); __raw_readl(cbr + BMIPS_RAC_CONFIG); cfg = __raw_readl(cbr + BMIPS_RAC_ADDRESS_RANGE); Patches currently in stable-queue which might be from jaedon.shin(a)gmail.com are queue-4.9/mips-bmips-fix-missing-cbr-address.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "MIPS: AR7: Ensure that serial ports are properly set up" 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 MIPS: AR7: Ensure that serial ports are properly set up 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: mips-ar7-ensure-that-serial-ports-are-properly-set-up.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 b084116f8587b222a2c5ef6dcd846f40f24b9420 Mon Sep 17 00:00:00 2001 From: Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de> Date: Sun, 29 Oct 2017 16:27:20 +0100 Subject: MIPS: AR7: Ensure that serial ports are properly set up From: Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de> commit b084116f8587b222a2c5ef6dcd846f40f24b9420 upstream. Without UPF_FIXED_TYPE, the data from the PORT_AR7 uart_config entry is never copied, resulting in a dead port. Fixes: 154615d55459 ("MIPS: AR7: Use correct UART port type") Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de> [jonas.gorski: add Fixes tag] Signed-off-by: Jonas Gorski <jonas.gorski(a)gmail.com> Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com> Cc: Ralf Baechle <ralf(a)linux-mips.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez(a)hitachi.com> Cc: Nicolas Schichan <nschichan(a)freebox.fr> Cc: Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de> Cc: linux-mips(a)linux-mips.org Cc: linux-serial(a)vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/17543/ Signed-off-by: James Hogan <jhogan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/ar7/platform.c | 1 + 1 file changed, 1 insertion(+) --- a/arch/mips/ar7/platform.c +++ b/arch/mips/ar7/platform.c @@ -576,6 +576,7 @@ static int __init ar7_register_uarts(voi uart_port.type = PORT_AR7; uart_port.uartclk = clk_get_rate(bus_clk) / 2; uart_port.iotype = UPIO_MEM32; + uart_port.flags = UPF_FIXED_TYPE; uart_port.regshift = 2; uart_port.line = 0; Patches currently in stable-queue which might be from oswald.buddenhagen(a)gmx.de are queue-4.9/mips-ar7-ensure-that-serial-ports-are-properly-set-up.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "MIPS: AR7: Defer registration of GPIO" 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 MIPS: AR7: Defer registration of GPIO 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: mips-ar7-defer-registration-of-gpio.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 e6b03ab63b4d270e0249f96536fde632409dc1dc Mon Sep 17 00:00:00 2001 From: Jonas Gorski <jonas.gorski(a)gmail.com> Date: Sun, 29 Oct 2017 16:27:19 +0100 Subject: MIPS: AR7: Defer registration of GPIO From: Jonas Gorski <jonas.gorski(a)gmail.com> commit e6b03ab63b4d270e0249f96536fde632409dc1dc upstream. When called from prom init code, ar7_gpio_init() will fail as it will call gpiochip_add() which relies on a working kmalloc() to alloc the gpio_desc array and kmalloc is not useable yet at prom init time. Move ar7_gpio_init() to ar7_register_devices() (a device_initcall) where kmalloc works. Fixes: 14e85c0e69d5 ("gpio: remove gpio_descs global array") Signed-off-by: Jonas Gorski <jonas.gorski(a)gmail.com> Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com> Cc: Ralf Baechle <ralf(a)linux-mips.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez(a)hitachi.com> Cc: Nicolas Schichan <nschichan(a)freebox.fr> Cc: linux-mips(a)linux-mips.org Cc: linux-serial(a)vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/17542/ Signed-off-by: James Hogan <jhogan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/ar7/platform.c | 4 ++++ arch/mips/ar7/prom.c | 2 -- 2 files changed, 4 insertions(+), 2 deletions(-) --- a/arch/mips/ar7/platform.c +++ b/arch/mips/ar7/platform.c @@ -654,6 +654,10 @@ static int __init ar7_register_devices(v u32 val; int res; + res = ar7_gpio_init(); + if (res) + pr_warn("unable to register gpios: %d\n", res); + res = ar7_register_uarts(); if (res) pr_err("unable to setup uart(s): %d\n", res); --- a/arch/mips/ar7/prom.c +++ b/arch/mips/ar7/prom.c @@ -246,8 +246,6 @@ void __init prom_init(void) ar7_init_cmdline(fw_arg0, (char **)fw_arg1); ar7_init_env((struct env_var *)fw_arg2); console_config(); - - ar7_gpio_init(); } #define PORT(offset) (KSEG1ADDR(AR7_REGS_UART0 + (offset * 4))) Patches currently in stable-queue which might be from jonas.gorski(a)gmail.com are queue-4.9/mips-ar7-ensure-that-serial-ports-are-properly-set-up.patch queue-4.9/mips-ar7-defer-registration-of-gpio.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "Input: elan_i2c - add ELAN060C to the ACPI 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 Input: elan_i2c - add ELAN060C to the ACPI 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: input-elan_i2c-add-elan060c-to-the-acpi-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 cdea6a30c2689cc33b34c6691b57cca277f0c5dc Mon Sep 17 00:00:00 2001 From: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Date: Tue, 7 Nov 2017 16:19:24 -0800 Subject: Input: elan_i2c - add ELAN060C to the ACPI table From: Kai-Heng Feng <kai.heng.feng(a)canonical.com> commit cdea6a30c2689cc33b34c6691b57cca277f0c5dc upstream. ELAN060C touchpad uses elan_i2c as its driver. It can be found on Lenovo ideapad 320-14AST. BugLink: https://bugs.launchpad.net/bugs/1727544 Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/input/mouse/elan_i2c_core.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/input/mouse/elan_i2c_core.c +++ b/drivers/input/mouse/elan_i2c_core.c @@ -1240,6 +1240,7 @@ static const struct acpi_device_id elan_ { "ELAN0605", 0 }, { "ELAN0609", 0 }, { "ELAN060B", 0 }, + { "ELAN060C", 0 }, { "ELAN0611", 0 }, { "ELAN1000", 0 }, { } Patches currently in stable-queue which might be from kai.heng.feng(a)canonical.com are queue-4.9/input-elan_i2c-add-elan060c-to-the-acpi-table.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/vmwgfx: Fix Ubuntu 17.10 Wayland black screen issue" 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/vmwgfx: Fix Ubuntu 17.10 Wayland black screen issue 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-vmwgfx-fix-ubuntu-17.10-wayland-black-screen-issue.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 cef75036c40408ba3bc308bcb00a3d440da713fc Mon Sep 17 00:00:00 2001 From: Sinclair Yeh <syeh(a)vmware.com> Date: Wed, 1 Nov 2017 10:47:05 -0700 Subject: drm/vmwgfx: Fix Ubuntu 17.10 Wayland black screen issue From: Sinclair Yeh <syeh(a)vmware.com> commit cef75036c40408ba3bc308bcb00a3d440da713fc upstream. This is an extension of Commit 7c20d213dd3c ("drm/vmwgfx: Work around mode set failure in 2D VMs") With Wayland desktop and atomic mode set, during the mode setting process there is a moment when two framebuffer sized surfaces are being pinned. This was not an issue with Xorg. Since this only happens during a mode change, there should be no performance impact by increasing allowable mem_size. Signed-off-by: Sinclair Yeh <syeh(a)vmware.com> Reviewed-by: Thomas Hellstrom <thellstrom(a)vmware.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c @@ -721,7 +721,7 @@ static int vmw_driver_load(struct drm_de * allocation taken by fbdev */ if (!(dev_priv->capabilities & SVGA_CAP_3D)) - mem_size *= 2; + mem_size *= 3; dev_priv->max_mob_pages = mem_size * 1024 / PAGE_SIZE; dev_priv->prim_bb_mem = Patches currently in stable-queue which might be from syeh(a)vmware.com are queue-4.9/drm-vmwgfx-fix-ubuntu-17.10-wayland-black-screen-issue.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "ASoC: sun4i-spdif: remove legacy dapm components" 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 ASoC: sun4i-spdif: remove legacy dapm components 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: asoc-sun4i-spdif-remove-legacy-dapm-components.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 96e53c41e1f81c9e9d1ce38d3f28b95668b71dcf Mon Sep 17 00:00:00 2001 From: Marcus Cooper <codekipper(a)gmail.com> Date: Tue, 20 Dec 2016 15:49:13 +0100 Subject: ASoC: sun4i-spdif: remove legacy dapm components From: Marcus Cooper <codekipper(a)gmail.com> commit 96e53c41e1f81c9e9d1ce38d3f28b95668b71dcf upstream. The dapm components are now handled by the ALSA SoC SPDIF DIT driver so can be removed. Signed-off-by: Marcus Cooper <codekipper(a)gmail.com> Acked-by: Maxime Ripard <maxime.ripard(a)free-electrons.com> Signed-off-by: Mark Brown <broonie(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/soc/sunxi/sun4i-spdif.c | 8 -------- 1 file changed, 8 deletions(-) --- a/sound/soc/sunxi/sun4i-spdif.c +++ b/sound/soc/sunxi/sun4i-spdif.c @@ -403,14 +403,6 @@ static struct snd_soc_dai_driver sun4i_s .name = "spdif", }; -static const struct snd_soc_dapm_widget dit_widgets[] = { - SND_SOC_DAPM_OUTPUT("spdif-out"), -}; - -static const struct snd_soc_dapm_route dit_routes[] = { - { "spdif-out", NULL, "Playback" }, -}; - static const struct of_device_id sun4i_spdif_of_match[] = { { .compatible = "allwinner,sun4i-a10-spdif", }, { .compatible = "allwinner,sun6i-a31-spdif", }, Patches currently in stable-queue which might be from codekipper(a)gmail.com are queue-4.9/asoc-sun4i-spdif-remove-legacy-dapm-components.patch queue-4.9/asoc-sunxi-add-bindings-for-sun8i-to-spdif.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "MIPS: AR7: Ensure that serial ports are properly set up" 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 MIPS: AR7: Ensure that serial ports are properly set up 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: mips-ar7-ensure-that-serial-ports-are-properly-set-up.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 b084116f8587b222a2c5ef6dcd846f40f24b9420 Mon Sep 17 00:00:00 2001 From: Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de> Date: Sun, 29 Oct 2017 16:27:20 +0100 Subject: MIPS: AR7: Ensure that serial ports are properly set up From: Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de> commit b084116f8587b222a2c5ef6dcd846f40f24b9420 upstream. Without UPF_FIXED_TYPE, the data from the PORT_AR7 uart_config entry is never copied, resulting in a dead port. Fixes: 154615d55459 ("MIPS: AR7: Use correct UART port type") Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de> [jonas.gorski: add Fixes tag] Signed-off-by: Jonas Gorski <jonas.gorski(a)gmail.com> Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com> Cc: Ralf Baechle <ralf(a)linux-mips.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez(a)hitachi.com> Cc: Nicolas Schichan <nschichan(a)freebox.fr> Cc: Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de> Cc: linux-mips(a)linux-mips.org Cc: linux-serial(a)vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/17543/ Signed-off-by: James Hogan <jhogan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/ar7/platform.c | 1 + 1 file changed, 1 insertion(+) --- a/arch/mips/ar7/platform.c +++ b/arch/mips/ar7/platform.c @@ -576,6 +576,7 @@ static int __init ar7_register_uarts(voi uart_port.type = PORT_AR7; uart_port.uartclk = clk_get_rate(bus_clk) / 2; uart_port.iotype = UPIO_MEM32; + uart_port.flags = UPF_FIXED_TYPE; uart_port.regshift = 2; uart_port.line = 0; Patches currently in stable-queue which might be from oswald.buddenhagen(a)gmx.de are queue-4.4/mips-ar7-ensure-that-serial-ports-are-properly-set-up.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "MIPS: AR7: Defer registration of GPIO" 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 MIPS: AR7: Defer registration of GPIO 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: mips-ar7-defer-registration-of-gpio.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 e6b03ab63b4d270e0249f96536fde632409dc1dc Mon Sep 17 00:00:00 2001 From: Jonas Gorski <jonas.gorski(a)gmail.com> Date: Sun, 29 Oct 2017 16:27:19 +0100 Subject: MIPS: AR7: Defer registration of GPIO From: Jonas Gorski <jonas.gorski(a)gmail.com> commit e6b03ab63b4d270e0249f96536fde632409dc1dc upstream. When called from prom init code, ar7_gpio_init() will fail as it will call gpiochip_add() which relies on a working kmalloc() to alloc the gpio_desc array and kmalloc is not useable yet at prom init time. Move ar7_gpio_init() to ar7_register_devices() (a device_initcall) where kmalloc works. Fixes: 14e85c0e69d5 ("gpio: remove gpio_descs global array") Signed-off-by: Jonas Gorski <jonas.gorski(a)gmail.com> Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com> Cc: Ralf Baechle <ralf(a)linux-mips.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez(a)hitachi.com> Cc: Nicolas Schichan <nschichan(a)freebox.fr> Cc: linux-mips(a)linux-mips.org Cc: linux-serial(a)vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/17542/ Signed-off-by: James Hogan <jhogan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/ar7/platform.c | 4 ++++ arch/mips/ar7/prom.c | 2 -- 2 files changed, 4 insertions(+), 2 deletions(-) --- a/arch/mips/ar7/platform.c +++ b/arch/mips/ar7/platform.c @@ -654,6 +654,10 @@ static int __init ar7_register_devices(v u32 val; int res; + res = ar7_gpio_init(); + if (res) + pr_warn("unable to register gpios: %d\n", res); + res = ar7_register_uarts(); if (res) pr_err("unable to setup uart(s): %d\n", res); --- a/arch/mips/ar7/prom.c +++ b/arch/mips/ar7/prom.c @@ -246,8 +246,6 @@ void __init prom_init(void) ar7_init_cmdline(fw_arg0, (char **)fw_arg1); ar7_init_env((struct env_var *)fw_arg2); console_config(); - - ar7_gpio_init(); } #define PORT(offset) (KSEG1ADDR(AR7_REGS_UART0 + (offset * 4))) Patches currently in stable-queue which might be from jonas.gorski(a)gmail.com are queue-4.4/mips-ar7-ensure-that-serial-ports-are-properly-set-up.patch queue-4.4/mips-ar7-defer-registration-of-gpio.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "Input: elan_i2c - add ELAN060C to the ACPI 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 Input: elan_i2c - add ELAN060C to the ACPI 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: input-elan_i2c-add-elan060c-to-the-acpi-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 cdea6a30c2689cc33b34c6691b57cca277f0c5dc Mon Sep 17 00:00:00 2001 From: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Date: Tue, 7 Nov 2017 16:19:24 -0800 Subject: Input: elan_i2c - add ELAN060C to the ACPI table From: Kai-Heng Feng <kai.heng.feng(a)canonical.com> commit cdea6a30c2689cc33b34c6691b57cca277f0c5dc upstream. ELAN060C touchpad uses elan_i2c as its driver. It can be found on Lenovo ideapad 320-14AST. BugLink: https://bugs.launchpad.net/bugs/1727544 Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/input/mouse/elan_i2c_core.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/input/mouse/elan_i2c_core.c +++ b/drivers/input/mouse/elan_i2c_core.c @@ -1240,6 +1240,7 @@ static const struct acpi_device_id elan_ { "ELAN0605", 0 }, { "ELAN0609", 0 }, { "ELAN060B", 0 }, + { "ELAN060C", 0 }, { "ELAN0611", 0 }, { "ELAN1000", 0 }, { } Patches currently in stable-queue which might be from kai.heng.feng(a)canonical.com are queue-4.4/input-elan_i2c-add-elan060c-to-the-acpi-table.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/vmwgfx: Fix Ubuntu 17.10 Wayland black screen issue" 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/vmwgfx: Fix Ubuntu 17.10 Wayland black screen issue 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-vmwgfx-fix-ubuntu-17.10-wayland-black-screen-issue.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 cef75036c40408ba3bc308bcb00a3d440da713fc Mon Sep 17 00:00:00 2001 From: Sinclair Yeh <syeh(a)vmware.com> Date: Wed, 1 Nov 2017 10:47:05 -0700 Subject: drm/vmwgfx: Fix Ubuntu 17.10 Wayland black screen issue From: Sinclair Yeh <syeh(a)vmware.com> commit cef75036c40408ba3bc308bcb00a3d440da713fc upstream. This is an extension of Commit 7c20d213dd3c ("drm/vmwgfx: Work around mode set failure in 2D VMs") With Wayland desktop and atomic mode set, during the mode setting process there is a moment when two framebuffer sized surfaces are being pinned. This was not an issue with Xorg. Since this only happens during a mode change, there should be no performance impact by increasing allowable mem_size. Signed-off-by: Sinclair Yeh <syeh(a)vmware.com> Reviewed-by: Thomas Hellstrom <thellstrom(a)vmware.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c @@ -708,7 +708,7 @@ static int vmw_driver_load(struct drm_de * allocation taken by fbdev */ if (!(dev_priv->capabilities & SVGA_CAP_3D)) - mem_size *= 2; + mem_size *= 3; dev_priv->max_mob_pages = mem_size * 1024 / PAGE_SIZE; dev_priv->prim_bb_mem = Patches currently in stable-queue which might be from syeh(a)vmware.com are queue-4.4/drm-vmwgfx-fix-ubuntu-17.10-wayland-black-screen-issue.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "Revert "x86: CPU: Fix up "cpu MHz" in /proc/cpuinfo"" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Revert "x86: CPU: Fix up "cpu MHz" in /proc/cpuinfo" to the 4.13-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: revert-x86-cpu-fix-up-cpu-mhz-in-proc-cpuinfo.patch and it can be found in the queue-4.13 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 ea0ee33988778fb73e4f45e7c73fb735787e2f32 Mon Sep 17 00:00:00 2001 From: Linus Torvalds <torvalds(a)linux-foundation.org> Date: Fri, 10 Nov 2017 11:19:11 -0800 Subject: Revert "x86: CPU: Fix up "cpu MHz" in /proc/cpuinfo" From: Linus Torvalds <torvalds(a)linux-foundation.org> commit ea0ee33988778fb73e4f45e7c73fb735787e2f32 upstream. This reverts commit 941f5f0f6ef5338814145cf2b813cf1f98873e2f. Sadly, it turns out that we really can't just do the cross-CPU IPI to all CPU's to get their proper frequencies, because it's much too expensive on systems with lots of cores. So we'll have to revert this for now, and revisit it using a smarter model (probably doing one system-wide IPI at open time, and doing all the frequency calculations in parallel). Reported-by: WANG Chao <chao.wang(a)ucloud.cn> Reported-by: Ingo Molnar <mingo(a)kernel.org> Cc: Rafael J Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/kernel/cpu/Makefile | 2 +- arch/x86/kernel/cpu/aperfmperf.c | 11 ++++------- arch/x86/kernel/cpu/proc.c | 4 +--- 3 files changed, 6 insertions(+), 11 deletions(-) --- a/arch/x86/kernel/cpu/Makefile +++ b/arch/x86/kernel/cpu/Makefile @@ -21,7 +21,7 @@ obj-y += common.o obj-y += rdrand.o obj-y += match.o obj-y += bugs.o -obj-y += aperfmperf.o +obj-$(CONFIG_CPU_FREQ) += aperfmperf.o obj-$(CONFIG_PROC_FS) += proc.o obj-$(CONFIG_X86_FEATURE_NAMES) += capflags.o powerflags.o --- a/arch/x86/kernel/cpu/aperfmperf.c +++ b/arch/x86/kernel/cpu/aperfmperf.c @@ -42,6 +42,10 @@ static void aperfmperf_snapshot_khz(void s64 time_delta = ktime_ms_delta(now, s->time); unsigned long flags; + /* Don't bother re-computing within the cache threshold time. */ + if (time_delta < APERFMPERF_CACHE_THRESHOLD_MS) + return; + local_irq_save(flags); rdmsrl(MSR_IA32_APERF, aperf); rdmsrl(MSR_IA32_MPERF, mperf); @@ -70,7 +74,6 @@ static void aperfmperf_snapshot_khz(void unsigned int arch_freq_get_on_cpu(int cpu) { - s64 time_delta; unsigned int khz; if (!cpu_khz) @@ -79,12 +82,6 @@ unsigned int arch_freq_get_on_cpu(int cp if (!static_cpu_has(X86_FEATURE_APERFMPERF)) return 0; - /* Don't bother re-computing within the cache threshold time. */ - time_delta = ktime_ms_delta(ktime_get(), per_cpu(samples.time, cpu)); - khz = per_cpu(samples.khz, cpu); - if (khz && time_delta < APERFMPERF_CACHE_THRESHOLD_MS) - return khz; - smp_call_function_single(cpu, aperfmperf_snapshot_khz, NULL, 1); khz = per_cpu(samples.khz, cpu); if (khz) --- a/arch/x86/kernel/cpu/proc.c +++ b/arch/x86/kernel/cpu/proc.c @@ -77,11 +77,9 @@ static int show_cpuinfo(struct seq_file seq_printf(m, "microcode\t: 0x%x\n", c->microcode); if (cpu_has(c, X86_FEATURE_TSC)) { - unsigned int freq = arch_freq_get_on_cpu(cpu); + unsigned int freq = cpufreq_quick_get(cpu); if (!freq) - freq = cpufreq_quick_get(cpu); - if (!freq) freq = cpu_khz; seq_printf(m, "cpu MHz\t\t: %u.%03u\n", freq / 1000, (freq % 1000)); Patches currently in stable-queue which might be from torvalds(a)linux-foundation.org are queue-4.13/revert-x86-cpu-fix-up-cpu-mhz-in-proc-cpuinfo.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "rbd: use GFP_NOIO for parent stat and data requests" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled rbd: use GFP_NOIO for parent stat and data requests to the 4.13-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: rbd-use-gfp_noio-for-parent-stat-and-data-requests.patch and it can be found in the queue-4.13 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 1e37f2f84680fa7f8394fd444b6928e334495ccc Mon Sep 17 00:00:00 2001 From: Ilya Dryomov <idryomov(a)gmail.com> Date: Mon, 6 Nov 2017 11:33:36 +0100 Subject: rbd: use GFP_NOIO for parent stat and data requests From: Ilya Dryomov <idryomov(a)gmail.com> commit 1e37f2f84680fa7f8394fd444b6928e334495ccc upstream. rbd_img_obj_exists_submit() and rbd_img_obj_parent_read_full() are on the writeback path for cloned images -- we attempt a stat on the parent object to see if it exists and potentially read it in to call copyup. GFP_NOIO should be used instead of GFP_KERNEL here. Link: http://tracker.ceph.com/issues/22014 Signed-off-by: Ilya Dryomov <idryomov(a)gmail.com> Reviewed-by: David Disseldorp <ddiss(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/block/rbd.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/block/rbd.c +++ b/drivers/block/rbd.c @@ -2692,7 +2692,7 @@ static int rbd_img_obj_parent_read_full( * from the parent. */ page_count = (u32)calc_pages_for(0, length); - pages = ceph_alloc_page_vector(page_count, GFP_KERNEL); + pages = ceph_alloc_page_vector(page_count, GFP_NOIO); if (IS_ERR(pages)) { result = PTR_ERR(pages); pages = NULL; @@ -2827,7 +2827,7 @@ static int rbd_img_obj_exists_submit(str */ size = sizeof (__le64) + sizeof (__le32) + sizeof (__le32); page_count = (u32)calc_pages_for(0, size); - pages = ceph_alloc_page_vector(page_count, GFP_KERNEL); + pages = ceph_alloc_page_vector(page_count, GFP_NOIO); if (IS_ERR(pages)) { ret = PTR_ERR(pages); goto fail_stat_request; Patches currently in stable-queue which might be from idryomov(a)gmail.com are queue-4.13/rbd-use-gfp_noio-for-parent-stat-and-data-requests.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "MIPS: BMIPS: Fix missing cbr address" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled MIPS: BMIPS: Fix missing cbr address to the 4.13-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: mips-bmips-fix-missing-cbr-address.patch and it can be found in the queue-4.13 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 ea4b3afe1eac8f88bb453798a084fba47a1f155a Mon Sep 17 00:00:00 2001 From: Jaedon Shin <jaedon.shin(a)gmail.com> Date: Fri, 16 Jun 2017 20:03:01 +0900 Subject: MIPS: BMIPS: Fix missing cbr address From: Jaedon Shin <jaedon.shin(a)gmail.com> commit ea4b3afe1eac8f88bb453798a084fba47a1f155a upstream. Fix NULL pointer access in BMIPS3300 RAC flush. Fixes: 738a3f79027b ("MIPS: BMIPS: Add early CPU initialization code") Signed-off-by: Jaedon Shin <jaedon.shin(a)gmail.com> Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com> Cc: Kevin Cernekee <cernekee(a)gmail.com> Cc: linux-mips(a)linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/16423/ Signed-off-by: James Hogan <jhogan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/kernel/smp-bmips.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/arch/mips/kernel/smp-bmips.c +++ b/arch/mips/kernel/smp-bmips.c @@ -589,11 +589,11 @@ void __init bmips_cpu_setup(void) /* Flush and enable RAC */ cfg = __raw_readl(cbr + BMIPS_RAC_CONFIG); - __raw_writel(cfg | 0x100, BMIPS_RAC_CONFIG); + __raw_writel(cfg | 0x100, cbr + BMIPS_RAC_CONFIG); __raw_readl(cbr + BMIPS_RAC_CONFIG); cfg = __raw_readl(cbr + BMIPS_RAC_CONFIG); - __raw_writel(cfg | 0xf, BMIPS_RAC_CONFIG); + __raw_writel(cfg | 0xf, cbr + BMIPS_RAC_CONFIG); __raw_readl(cbr + BMIPS_RAC_CONFIG); cfg = __raw_readl(cbr + BMIPS_RAC_ADDRESS_RANGE); Patches currently in stable-queue which might be from jaedon.shin(a)gmail.com are queue-4.13/mips-bmips-fix-missing-cbr-address.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "MIPS: AR7: Ensure that serial ports are properly set up" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled MIPS: AR7: Ensure that serial ports are properly set up to the 4.13-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: mips-ar7-ensure-that-serial-ports-are-properly-set-up.patch and it can be found in the queue-4.13 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 b084116f8587b222a2c5ef6dcd846f40f24b9420 Mon Sep 17 00:00:00 2001 From: Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de> Date: Sun, 29 Oct 2017 16:27:20 +0100 Subject: MIPS: AR7: Ensure that serial ports are properly set up From: Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de> commit b084116f8587b222a2c5ef6dcd846f40f24b9420 upstream. Without UPF_FIXED_TYPE, the data from the PORT_AR7 uart_config entry is never copied, resulting in a dead port. Fixes: 154615d55459 ("MIPS: AR7: Use correct UART port type") Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de> [jonas.gorski: add Fixes tag] Signed-off-by: Jonas Gorski <jonas.gorski(a)gmail.com> Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com> Cc: Ralf Baechle <ralf(a)linux-mips.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez(a)hitachi.com> Cc: Nicolas Schichan <nschichan(a)freebox.fr> Cc: Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de> Cc: linux-mips(a)linux-mips.org Cc: linux-serial(a)vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/17543/ Signed-off-by: James Hogan <jhogan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/ar7/platform.c | 1 + 1 file changed, 1 insertion(+) --- a/arch/mips/ar7/platform.c +++ b/arch/mips/ar7/platform.c @@ -575,6 +575,7 @@ static int __init ar7_register_uarts(voi uart_port.type = PORT_AR7; uart_port.uartclk = clk_get_rate(bus_clk) / 2; uart_port.iotype = UPIO_MEM32; + uart_port.flags = UPF_FIXED_TYPE; uart_port.regshift = 2; uart_port.line = 0; Patches currently in stable-queue which might be from oswald.buddenhagen(a)gmx.de are queue-4.13/mips-ar7-ensure-that-serial-ports-are-properly-set-up.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "MIPS: AR7: Defer registration of GPIO" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled MIPS: AR7: Defer registration of GPIO to the 4.13-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: mips-ar7-defer-registration-of-gpio.patch and it can be found in the queue-4.13 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 e6b03ab63b4d270e0249f96536fde632409dc1dc Mon Sep 17 00:00:00 2001 From: Jonas Gorski <jonas.gorski(a)gmail.com> Date: Sun, 29 Oct 2017 16:27:19 +0100 Subject: MIPS: AR7: Defer registration of GPIO From: Jonas Gorski <jonas.gorski(a)gmail.com> commit e6b03ab63b4d270e0249f96536fde632409dc1dc upstream. When called from prom init code, ar7_gpio_init() will fail as it will call gpiochip_add() which relies on a working kmalloc() to alloc the gpio_desc array and kmalloc is not useable yet at prom init time. Move ar7_gpio_init() to ar7_register_devices() (a device_initcall) where kmalloc works. Fixes: 14e85c0e69d5 ("gpio: remove gpio_descs global array") Signed-off-by: Jonas Gorski <jonas.gorski(a)gmail.com> Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com> Cc: Ralf Baechle <ralf(a)linux-mips.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez(a)hitachi.com> Cc: Nicolas Schichan <nschichan(a)freebox.fr> Cc: linux-mips(a)linux-mips.org Cc: linux-serial(a)vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/17542/ Signed-off-by: James Hogan <jhogan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/ar7/platform.c | 4 ++++ arch/mips/ar7/prom.c | 2 -- 2 files changed, 4 insertions(+), 2 deletions(-) --- a/arch/mips/ar7/platform.c +++ b/arch/mips/ar7/platform.c @@ -653,6 +653,10 @@ static int __init ar7_register_devices(v u32 val; int res; + res = ar7_gpio_init(); + if (res) + pr_warn("unable to register gpios: %d\n", res); + res = ar7_register_uarts(); if (res) pr_err("unable to setup uart(s): %d\n", res); --- a/arch/mips/ar7/prom.c +++ b/arch/mips/ar7/prom.c @@ -246,8 +246,6 @@ void __init prom_init(void) ar7_init_cmdline(fw_arg0, (char **)fw_arg1); ar7_init_env((struct env_var *)fw_arg2); console_config(); - - ar7_gpio_init(); } #define PORT(offset) (KSEG1ADDR(AR7_REGS_UART0 + (offset * 4))) Patches currently in stable-queue which might be from jonas.gorski(a)gmail.com are queue-4.13/mips-ar7-ensure-that-serial-ports-are-properly-set-up.patch queue-4.13/mips-ar7-defer-registration-of-gpio.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "KVM: PPC: Book3S HV: Fix exclusion between HPT resizing and other HPT updates" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: PPC: Book3S HV: Fix exclusion between HPT resizing and other HPT updates to the 4.13-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-ppc-book3s-hv-fix-exclusion-between-hpt-resizing-and-other-hpt-updates.patch and it can be found in the queue-4.13 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 38c53af853069adf87181684370d7b8866d6387b Mon Sep 17 00:00:00 2001 From: Paul Mackerras <paulus(a)ozlabs.org> Date: Wed, 8 Nov 2017 14:44:04 +1100 Subject: KVM: PPC: Book3S HV: Fix exclusion between HPT resizing and other HPT updates From: Paul Mackerras <paulus(a)ozlabs.org> commit 38c53af853069adf87181684370d7b8866d6387b upstream. Commit 5e9859699aba ("KVM: PPC: Book3S HV: Outline of KVM-HV HPT resizing implementation", 2016-12-20) added code that tries to exclude any use or update of the hashed page table (HPT) while the HPT resizing code is iterating through all the entries in the HPT. It does this by taking the kvm->lock mutex, clearing the kvm->arch.hpte_setup_done flag and then sending an IPI to all CPUs in the host. The idea is that any VCPU task that tries to enter the guest will see that the hpte_setup_done flag is clear and therefore call kvmppc_hv_setup_htab_rma, which also takes the kvm->lock mutex and will therefore block until we release kvm->lock. However, any VCPU that is already in the guest, or is handling a hypervisor page fault or hypercall, can re-enter the guest without rechecking the hpte_setup_done flag. The IPI will cause a guest exit of any VCPUs that are currently in the guest, but does not prevent those VCPU tasks from immediately re-entering the guest. The result is that after resize_hpt_rehash_hpte() has made a HPTE absent, a hypervisor page fault can occur and make that HPTE present again. This includes updating the rmap array for the guest real page, meaning that we now have a pointer in the rmap array which connects with pointers in the old rev array but not the new rev array. In fact, if the HPT is being reduced in size, the pointer in the rmap array could point outside the bounds of the new rev array. If that happens, we can get a host crash later on such as this one: [91652.628516] Unable to handle kernel paging request for data at address 0xd0000000157fb10c [91652.628668] Faulting instruction address: 0xc0000000000e2640 [91652.628736] Oops: Kernel access of bad area, sig: 11 [#1] [91652.628789] LE SMP NR_CPUS=1024 NUMA PowerNV [91652.628847] Modules linked in: binfmt_misc vhost_net vhost tap xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_mangle ip6table_security ip6table_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack libcrc32c iptable_mangle iptable_security iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables ses enclosure scsi_transport_sas i2c_opal ipmi_powernv ipmi_devintf i2c_core ipmi_msghandler powernv_op_panel nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc kvm_hv kvm_pr kvm scsi_dh_alua dm_service_time dm_multipath tg3 ptp pps_core [last unloaded: stap_552b612747aec2da355051e464fa72a1_14259] [91652.629566] CPU: 136 PID: 41315 Comm: CPU 21/KVM Tainted: G O 4.14.0-1.rc4.dev.gitb27fc5c.el7.centos.ppc64le #1 [91652.629684] task: c0000007a419e400 task.stack: c0000000028d8000 [91652.629750] NIP: c0000000000e2640 LR: d00000000c36e498 CTR: c0000000000e25f0 [91652.629829] REGS: c0000000028db5d0 TRAP: 0300 Tainted: G O (4.14.0-1.rc4.dev.gitb27fc5c.el7.centos.ppc64le) [91652.629932] MSR: 900000010280b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE,TM[E]> CR: 44022422 XER: 00000000 [91652.630034] CFAR: d00000000c373f84 DAR: d0000000157fb10c DSISR: 40000000 SOFTE: 1 [91652.630034] GPR00: d00000000c36e498 c0000000028db850 c000000001403900 c0000007b7960000 [91652.630034] GPR04: d0000000117fb100 d000000007ab00d8 000000000033bb10 0000000000000000 [91652.630034] GPR08: fffffffffffffe7f 801001810073bb10 d00000000e440000 d00000000c373f70 [91652.630034] GPR12: c0000000000e25f0 c00000000fdb9400 f000000003b24680 0000000000000000 [91652.630034] GPR16: 00000000000004fb 00007ff7081a0000 00000000000ec91a 000000000033bb10 [91652.630034] GPR20: 0000000000010000 00000000001b1190 0000000000000001 0000000000010000 [91652.630034] GPR24: c0000007b7ab8038 d0000000117fb100 0000000ec91a1190 c000001e6a000000 [91652.630034] GPR28: 00000000033bb100 000000000073bb10 c0000007b7960000 d0000000157fb100 [91652.630735] NIP [c0000000000e2640] kvmppc_add_revmap_chain+0x50/0x120 [91652.630806] LR [d00000000c36e498] kvmppc_book3s_hv_page_fault+0xbb8/0xc40 [kvm_hv] [91652.630884] Call Trace: [91652.630913] [c0000000028db850] [c0000000028db8b0] 0xc0000000028db8b0 (unreliable) [91652.630996] [c0000000028db8b0] [d00000000c36e498] kvmppc_book3s_hv_page_fault+0xbb8/0xc40 [kvm_hv] [91652.631091] [c0000000028db9e0] [d00000000c36a078] kvmppc_vcpu_run_hv+0xdf8/0x1300 [kvm_hv] [91652.631179] [c0000000028dbb30] [d00000000c2248c4] kvmppc_vcpu_run+0x34/0x50 [kvm] [91652.631266] [c0000000028dbb50] [d00000000c220d54] kvm_arch_vcpu_ioctl_run+0x114/0x2a0 [kvm] [91652.631351] [c0000000028dbbd0] [d00000000c2139d8] kvm_vcpu_ioctl+0x598/0x7a0 [kvm] [91652.631433] [c0000000028dbd40] [c0000000003832e0] do_vfs_ioctl+0xd0/0x8c0 [91652.631501] [c0000000028dbde0] [c000000000383ba4] SyS_ioctl+0xd4/0x130 [91652.631569] [c0000000028dbe30] [c00000000000b8e0] system_call+0x58/0x6c [91652.631635] Instruction dump: [91652.631676] fba1ffe8 fbc1fff0 fbe1fff8 f8010010 f821ffa1 2fa70000 793d0020 e9432110 [91652.631814] 7bbf26e4 7c7e1b78 7feafa14 409e0094 <807f000c> 786326e4 7c6a1a14 93a40008 [91652.631959] ---[ end trace ac85ba6db72e5b2e ]--- To fix this, we tighten up the way that the hpte_setup_done flag is checked to ensure that it does provide the guarantee that the resizing code needs. In kvmppc_run_core(), we check the hpte_setup_done flag after disabling interrupts and refuse to enter the guest if it is clear (for a HPT guest). The code that checks hpte_setup_done and calls kvmppc_hv_setup_htab_rma() is moved from kvmppc_vcpu_run_hv() to a point inside the main loop in kvmppc_run_vcpu(), ensuring that we don't just spin endlessly calling kvmppc_run_core() while hpte_setup_done is clear, but instead have a chance to block on the kvm->lock mutex. Finally we also check hpte_setup_done inside the region in kvmppc_book3s_hv_page_fault() where the HPTE is locked and we are about to update the HPTE, and bail out if it is clear. If another CPU is inside kvm_vm_ioctl_resize_hpt_commit) and has cleared hpte_setup_done, then we know that either we are looking at a HPTE that resize_hpt_rehash_hpte() has not yet processed, which is OK, or else we will see hpte_setup_done clear and refuse to update it, because of the full barrier formed by the unlock of the HPTE in resize_hpt_rehash_hpte() combined with the locking of the HPTE in kvmppc_book3s_hv_page_fault(). Fixes: 5e9859699aba ("KVM: PPC: Book3S HV: Outline of KVM-HV HPT resizing implementation") Reported-by: Satheesh Rajendran <satheera(a)in.ibm.com> Signed-off-by: Paul Mackerras <paulus(a)ozlabs.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/kvm/book3s_64_mmu_hv.c | 10 ++++++++++ arch/powerpc/kvm/book3s_hv.c | 29 +++++++++++++++++++---------- 2 files changed, 29 insertions(+), 10 deletions(-) --- a/arch/powerpc/kvm/book3s_64_mmu_hv.c +++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c @@ -645,6 +645,16 @@ int kvmppc_book3s_hv_page_fault(struct k hnow_v = hpte_new_to_old_v(hnow_v, hnow_r); hnow_r = hpte_new_to_old_r(hnow_r); } + + /* + * If the HPT is being resized, don't update the HPTE, + * instead let the guest retry after the resize operation is complete. + * The synchronization for hpte_setup_done test vs. set is provided + * by the HPTE lock. + */ + if (!kvm->arch.hpte_setup_done) + goto out_unlock; + if ((hnow_v & ~HPTE_V_HVLOCK) != hpte[0] || hnow_r != hpte[1] || rev->guest_rpte != hpte[2]) /* HPTE has been changed under us; let the guest retry */ --- a/arch/powerpc/kvm/book3s_hv.c +++ b/arch/powerpc/kvm/book3s_hv.c @@ -2688,11 +2688,14 @@ static noinline void kvmppc_run_core(str * Hard-disable interrupts, and check resched flag and signals. * If we need to reschedule or deliver a signal, clean up * and return without going into the guest(s). + * If the hpte_setup_done flag has been cleared, don't go into the + * guest because that means a HPT resize operation is in progress. */ local_irq_disable(); hard_irq_disable(); if (lazy_irq_pending() || need_resched() || - recheck_signals(&core_info)) { + recheck_signals(&core_info) || + (!kvm_is_radix(vc->kvm) && !vc->kvm->arch.hpte_setup_done)) { local_irq_enable(); vc->vcore_state = VCORE_INACTIVE; /* Unlock all except the primary vcore */ @@ -3061,7 +3064,7 @@ out: static int kvmppc_run_vcpu(struct kvm_run *kvm_run, struct kvm_vcpu *vcpu) { - int n_ceded, i; + int n_ceded, i, r; struct kvmppc_vcore *vc; struct kvm_vcpu *v; @@ -3115,6 +3118,20 @@ static int kvmppc_run_vcpu(struct kvm_ru while (vcpu->arch.state == KVMPPC_VCPU_RUNNABLE && !signal_pending(current)) { + /* See if the HPT and VRMA are ready to go */ + if (!kvm_is_radix(vcpu->kvm) && + !vcpu->kvm->arch.hpte_setup_done) { + spin_unlock(&vc->lock); + r = kvmppc_hv_setup_htab_rma(vcpu); + spin_lock(&vc->lock); + if (r) { + kvm_run->exit_reason = KVM_EXIT_FAIL_ENTRY; + kvm_run->fail_entry.hardware_entry_failure_reason = 0; + vcpu->arch.ret = r; + break; + } + } + if (vc->vcore_state == VCORE_PREEMPT && vc->runner == NULL) kvmppc_vcore_end_preempt(vc); @@ -3232,13 +3249,6 @@ static int kvmppc_vcpu_run_hv(struct kvm /* Order vcpus_running vs. hpte_setup_done, see kvmppc_alloc_reset_hpt */ smp_mb(); - /* On the first time here, set up HTAB and VRMA */ - if (!kvm_is_radix(vcpu->kvm) && !vcpu->kvm->arch.hpte_setup_done) { - r = kvmppc_hv_setup_htab_rma(vcpu); - if (r) - goto out; - } - flush_all_to_thread(current); /* Save userspace EBB and other register values */ @@ -3286,7 +3296,6 @@ static int kvmppc_vcpu_run_hv(struct kvm } mtspr(SPRN_VRSAVE, user_vrsave); - out: vcpu->arch.state = KVMPPC_VCPU_NOTREADY; atomic_dec(&vcpu->kvm->arch.vcpus_running); return r; Patches currently in stable-queue which might be from paulus(a)ozlabs.org are queue-4.13/kvm-ppc-book3s-hv-fix-exclusion-between-hpt-resizing-and-other-hpt-updates.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "Input: elan_i2c - add ELAN060C to the ACPI table" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled Input: elan_i2c - add ELAN060C to the ACPI table to the 4.13-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: input-elan_i2c-add-elan060c-to-the-acpi-table.patch and it can be found in the queue-4.13 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 cdea6a30c2689cc33b34c6691b57cca277f0c5dc Mon Sep 17 00:00:00 2001 From: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Date: Tue, 7 Nov 2017 16:19:24 -0800 Subject: Input: elan_i2c - add ELAN060C to the ACPI table From: Kai-Heng Feng <kai.heng.feng(a)canonical.com> commit cdea6a30c2689cc33b34c6691b57cca277f0c5dc upstream. ELAN060C touchpad uses elan_i2c as its driver. It can be found on Lenovo ideapad 320-14AST. BugLink: https://bugs.launchpad.net/bugs/1727544 Signed-off-by: Kai-Heng Feng <kai.heng.feng(a)canonical.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/input/mouse/elan_i2c_core.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/input/mouse/elan_i2c_core.c +++ b/drivers/input/mouse/elan_i2c_core.c @@ -1253,6 +1253,7 @@ static const struct acpi_device_id elan_ { "ELAN0605", 0 }, { "ELAN0609", 0 }, { "ELAN060B", 0 }, + { "ELAN060C", 0 }, { "ELAN0611", 0 }, { "ELAN1000", 0 }, { } Patches currently in stable-queue which might be from kai.heng.feng(a)canonical.com are queue-4.13/input-elan_i2c-add-elan060c-to-the-acpi-table.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/vmwgfx: Fix Ubuntu 17.10 Wayland black screen issue" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled drm/vmwgfx: Fix Ubuntu 17.10 Wayland black screen issue to the 4.13-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-vmwgfx-fix-ubuntu-17.10-wayland-black-screen-issue.patch and it can be found in the queue-4.13 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 cef75036c40408ba3bc308bcb00a3d440da713fc Mon Sep 17 00:00:00 2001 From: Sinclair Yeh <syeh(a)vmware.com> Date: Wed, 1 Nov 2017 10:47:05 -0700 Subject: drm/vmwgfx: Fix Ubuntu 17.10 Wayland black screen issue From: Sinclair Yeh <syeh(a)vmware.com> commit cef75036c40408ba3bc308bcb00a3d440da713fc upstream. This is an extension of Commit 7c20d213dd3c ("drm/vmwgfx: Work around mode set failure in 2D VMs") With Wayland desktop and atomic mode set, during the mode setting process there is a moment when two framebuffer sized surfaces are being pinned. This was not an issue with Xorg. Since this only happens during a mode change, there should be no performance impact by increasing allowable mem_size. Signed-off-by: Sinclair Yeh <syeh(a)vmware.com> Reviewed-by: Thomas Hellstrom <thellstrom(a)vmware.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c @@ -722,7 +722,7 @@ static int vmw_driver_load(struct drm_de * allocation taken by fbdev */ if (!(dev_priv->capabilities & SVGA_CAP_3D)) - mem_size *= 2; + mem_size *= 3; dev_priv->max_mob_pages = mem_size * 1024 / PAGE_SIZE; dev_priv->prim_bb_mem = Patches currently in stable-queue which might be from syeh(a)vmware.com are queue-4.13/drm-vmwgfx-fix-ubuntu-17.10-wayland-black-screen-issue.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "MIPS: AR7: Ensure that serial ports are properly set up" 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 MIPS: AR7: Ensure that serial ports are properly set up 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: mips-ar7-ensure-that-serial-ports-are-properly-set-up.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 b084116f8587b222a2c5ef6dcd846f40f24b9420 Mon Sep 17 00:00:00 2001 From: Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de> Date: Sun, 29 Oct 2017 16:27:20 +0100 Subject: MIPS: AR7: Ensure that serial ports are properly set up From: Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de> commit b084116f8587b222a2c5ef6dcd846f40f24b9420 upstream. Without UPF_FIXED_TYPE, the data from the PORT_AR7 uart_config entry is never copied, resulting in a dead port. Fixes: 154615d55459 ("MIPS: AR7: Use correct UART port type") Signed-off-by: Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de> [jonas.gorski: add Fixes tag] Signed-off-by: Jonas Gorski <jonas.gorski(a)gmail.com> Reviewed-by: Florian Fainelli <f.fainelli(a)gmail.com> Cc: Ralf Baechle <ralf(a)linux-mips.org> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: Yoshihiro YUNOMAE <yoshihiro.yunomae.ez(a)hitachi.com> Cc: Nicolas Schichan <nschichan(a)freebox.fr> Cc: Oswald Buddenhagen <oswald.buddenhagen(a)gmx.de> Cc: linux-mips(a)linux-mips.org Cc: linux-serial(a)vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/17543/ Signed-off-by: James Hogan <jhogan(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/ar7/platform.c | 1 + 1 file changed, 1 insertion(+) --- a/arch/mips/ar7/platform.c +++ b/arch/mips/ar7/platform.c @@ -581,6 +581,7 @@ static int __init ar7_register_uarts(voi uart_port.type = PORT_AR7; uart_port.uartclk = clk_get_rate(bus_clk) / 2; uart_port.iotype = UPIO_MEM32; + uart_port.flags = UPF_FIXED_TYPE; uart_port.regshift = 2; uart_port.line = 0; Patches currently in stable-queue which might be from oswald.buddenhagen(a)gmx.de are queue-3.18/mips-ar7-ensure-that-serial-ports-are-properly-set-up.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH 0/4] fix device-dax pud crash and fixup {pte, pmd, pud}_write

by Dan Williams

Andrew, Here is a new version to the pud_write() fix [1], and some follow-on patches to use the '_access_permitted' helpers in fault and get_user_pages() paths where we are checking if the thread has access to write. I explicitly omit conversions for places where the kernel is checking the _PAGE_RW flag for kernel purposes, not for userspace access. Beyond fixing the crash, this series also fixes get_user_pages() and fault paths to honor protection keys in the same manner as get_user_pages_fast(). Only the crash fix is tagged for -stable as the protection key check is done just for consistency reasons since userspace can change protection keys at will. [1]: https://lists.01.org/pipermail/linux-nvdimm/2017-November/013237.html --- Dan Williams (4): mm: fix device-dax pud write-faults triggered by get_user_pages() mm: replace pud_write with pud_access_permitted in fault + gup paths mm: replace pmd_write with pmd_access_permitted in fault + gup paths mm: replace pte_write with pte_access_permitted in fault + gup paths arch/sparc/mm/gup.c | 4 ++-- arch/x86/include/asm/pgtable.h | 6 ++++++ fs/dax.c | 3 ++- include/asm-generic/pgtable.h | 9 +++++++++ include/linux/hugetlb.h | 8 -------- mm/gup.c | 2 +- mm/hmm.c | 8 ++++---- mm/huge_memory.c | 6 +++--- mm/memory.c | 8 ++++---- 9 files changed, 31 insertions(+), 23 deletions(-)

7 years, 7 months

1
1
0 0

Re: [Linux-stable-mirror] [PATCH] KVM: SVM: obey guest PAT

by Radim Krčmář

2017-10-26 09:13+0200, Paolo Bonzini: > For many years some users of assigned devices have reported worse > performance on AMD processors with NPT than on AMD without NPT, > Intel or bare metal. > > The reason turned out to be that SVM is discarding the guest PAT > setting and uses the default (PA0=PA4=WB, PA1=PA5=WT, PA2=PA6=UC-, > PA3=UC). The guest might be using a different setting, and > especially might want write combining but isn't getting it > (instead getting slow UC or UC- accesses). > > Thanks a lot to geoff(a)hostfission.com for noticing the relation > to the g_pat setting. The patch has been tested also by a bunch > of people on VFIO users forums. > > Fixes: 709ddebf81cb40e3c36c6109a7892e8b93a09464 > Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=196409 > Cc: stable(a)vger.kernel.org > Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com> Applied, thanks.

7 years, 7 months

1
0
0 0

Re: [Linux-stable-mirror] FAILED: patch "[PATCH] KEYS: trusted: fix writing past end of buffer in" failed to apply to 4.9-stable tree

by Greg KH

On Mon, Nov 06, 2017 at 06:06:19AM -0500, Mimi Zohar wrote: > Hi Greg, > > On Sun, 2017-11-05 at 15:18 +0100, gregkh(a)linuxfoundation.org wrote: > > 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 > > This commit needs to prereq commit ee618b4619b7 "KEYS: trusted: > sanitize all key material". Thanks, that fixes the issue for 4.4 and 4.9, but not for 3.18 :( thanks, greg k-h

7 years, 7 months

3
2
0 0

Re: [Linux-stable-mirror] [PATCH] lib/mpi: call cond_resched() from mpi_powm() loop

by Herbert Xu

On Mon, Nov 06, 2017 at 10:19:51PM -0800, Eric Biggers wrote: > From: Eric Biggers <ebiggers(a)google.com> > > On a non-preemptible kernel, if KEYCTL_DH_COMPUTE is called with the > largest permitted inputs (16384 bits), the kernel spends 10+ seconds > doing modular exponentiation in mpi_powm() without rescheduling. If all > threads do it, it locks up the system. Moreover, it can cause > rcu_sched-stall warnings. > > Notwithstanding the insanity of doing this calculation in kernel mode > rather than in userspace, fix it by calling cond_resched() as each bit > from the exponent is processed. It's still noninterruptible, but at > least it's preemptible now. > > Cc: stable(a)vger.kernel.org # v4.12+ > Signed-off-by: Eric Biggers <ebiggers(a)google.com> Patch applied. Thanks. -- Email: Herbert Xu <herbert(a)gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

7 years, 7 months

2
1
0 0

Re: [Linux-stable-mirror] [PATCH] usb: f_fs: Drop check on Reserved1 field on OS_DESC_EXT_COMPAT

by John Keeping

On Fri, 10 Nov 2017 12:40:39 +0200, Felipe Balbi wrote: > John Keeping <john(a)metanate.com> writes: > > This check has gone through several incompatible variations in commits > > 53642399aa71 ("usb: gadget: f_fs: Fix wrong check on reserved1 of > > OS_DESC_EXT_COMPAT"), 354bc45bf329 ("usb: gadget: f_fs: Fix ExtCompat > > descriptor validation") and 3ba534df815f ("Revert "usb: gadget: f_fs: > > Fix ExtCompat descriptor validation"") after initially being introduced > > in commit f0175ab51993 ("usb: gadget: f_fs: OS descriptors support"). > > > > The various changes make it impossible for a single userspace > > implementation to work with different kernel versions, so let's just > > drop the condition to avoid breaking userspace. > > > > Fixes: 53642399aa71 ("usb: gadget: f_fs: Fix wrong check on reserved1 of OS_DESC_EXT_COMPAT") > > Cc: stable(a)vger.kernel.org # v4.7+ > > Signed-off-by: John Keeping <john(a)metanate.com> > > --- > > drivers/usb/gadget/function/f_fs.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c > > index 652397eda6d6..0d9962834345 100644 > > --- a/drivers/usb/gadget/function/f_fs.c > > +++ b/drivers/usb/gadget/function/f_fs.c > > @@ -2282,8 +2282,7 @@ static int __ffs_data_do_os_desc(enum ffs_os_desc_type type, > > int i; > > > > if (len < sizeof(*d) || > > - d->bFirstInterfaceNumber >= ffs->interfaces_count || > > - !d->Reserved1) > > + d->bFirstInterfaceNumber >= ffs->interfaces_count) > > return -EINVAL; > > for (i = 0; i < ARRAY_SIZE(d->Reserved2); ++i) > > if (d->Reserved2[i]) > > Sorry, but no. We want to be compliant with the specification. If there > are older still-maintained stable trees which are not working, we need > to backport a fix to them, but we're not allowing uncompliant > implementations. Aren't we allowing non-compliant implementations now? The spec says the value must be 1 but since v4.7 this code has allowed all non-zero values. At this point I don't think the kernel can disallow any values of Reserved1 without breaking someone's userspace.

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH v2] drm/fsl-dcu: Don't set connector DPMS property

by Stefan Agner

From: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com> Since commit 4a97a3da420b ("drm: Don't update property values for atomic drivers") atomic drivers must not update property values as properties are read from the state instead. To catch remaining users, the drm_object_property_set_value() function now throws a warning when called by atomic drivers on non-immutable properties, and we hit that warning when creating connectors. The easy fix is to just remove the drm_object_property_set_value() as it is used here to set the initial value of the connector's DPMS property to OFF. The DPMS property applies on top of the connector's state crtc pointer (initialized to NULL) that is the main connector on/off control, and should thus default to ON. Fixes: 4a97a3da420b ("drm: Don't update property values for atomic drivers") Cc: stable(a)vger.kernel.org Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com> Signed-off-by: Stefan Agner <stefan(a)agner.ch> --- drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c index edd7d8127d19..c54806d08dd7 100644 --- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_rgb.c @@ -102,7 +102,6 @@ static int fsl_dcu_attach_panel(struct fsl_dcu_drm_device *fsl_dev, { struct drm_encoder *encoder = &fsl_dev->encoder; struct drm_connector *connector = &fsl_dev->connector.base; - struct drm_mode_config *mode_config = &fsl_dev->drm->mode_config; int ret; fsl_dev->connector.encoder = encoder; @@ -122,10 +121,6 @@ static int fsl_dcu_attach_panel(struct fsl_dcu_drm_device *fsl_dev, if (ret < 0) goto err_sysfs; - drm_object_property_set_value(&connector->base, - mode_config->dpms_property, - DRM_MODE_DPMS_OFF); - ret = drm_panel_attach(panel, connector); if (ret) { dev_err(fsl_dev->dev, "failed to attach panel\n"); -- 2.14.2

7 years, 7 months

1
0
0 0

Re: [Linux-stable-mirror] Patch "ASoC: sunxi: Add bindings for sun8i to SPDIF" has been added to the 4.9-stable tree

by Levin, Alexander (Sasha Levin)

On Thu, Nov 09, 2017 at 04:17:33PM +0000, Mark Brown wrote: >On Thu, Nov 09, 2017 at 04:09:12PM +0000, Levin, Alexander (Sasha Levin) wrote: >> On Thu, Nov 09, 2017 at 11:07:44AM +0000, Mark Brown wrote: > >> >This doesn't seem like a good idea - note how the changelog says that >> >the transmit FIFO is at a different address, I'd expect this means that >> >people won't be able to use the new compatible without a corresponding >> >code change. > >> Interesting. I keep trying to automate DT patch selection to deal with >> issues as this, but it seems like there is always something... > >> I agree with Mark. I think it would make sense to pick 1bd92af877 as >> well to deal with this issue. > >Yeah, if they both go in together it's fine by me (though it's a little >more than just a device ID). It's a quirk too :) -- Thanks, Sasha

7 years, 7 months

3
3
0 0

[Linux-stable-mirror] [PATCH] uas: Add US_FL_NO_ATA_1X quirk for one more Seagate device

by Hans de Goede

Just like all previous UAS capable Seagate disk enclosures, this one needs a US_FL_NO_ATA_1X quirk. Cc: stable(a)vger.kernel.org # 3.16 Signed-off-by: Andrey Astafyev <1(a)246060.ru> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- drivers/usb/storage/unusual_uas.h | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/usb/storage/unusual_uas.h b/drivers/usb/storage/unusual_uas.h index cde115359793..2fe4fd336446 100644 --- a/drivers/usb/storage/unusual_uas.h +++ b/drivers/usb/storage/unusual_uas.h @@ -121,6 +121,13 @@ UNUSUAL_DEV(0x0bc2, 0xab2a, 0x0000, 0x9999, USB_SC_DEVICE, USB_PR_DEVICE, NULL, US_FL_NO_ATA_1X), +/* Reported-by: Andrey Astafyev <dev(a)246060.ru> */ +UNUSUAL_DEV(0x0bc2, 0xab30, 0x0000, 0x9999, + "Seagate", + "BUP BK", + USB_SC_DEVICE, USB_PR_DEVICE, NULL, + US_FL_NO_ATA_1X), + /* Reported-by: Benjamin Tissoires <benjamin.tissoires(a)redhat.com> */ UNUSUAL_DEV(0x13fd, 0x3940, 0x0000, 0x9999, "Initio Corporation", -- 2.14.3

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH] drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier v2

by Hans de Goede

assert_rpm_wakelock_held is triggered from i915_pmic_bus_access_notifier even though it gets unregistered on (runtime) suspend, this is caused by a race happening under the following circumstances: intel_runtime_pm_put does: atomic_dec(&dev_priv->pm.wakeref_count); pm_runtime_mark_last_busy(kdev); pm_runtime_put_autosuspend(kdev); And pm_runtime_put_autosuspend calls intel_runtime_suspend from a workqueue, so there is ample of time between the atomic_dec() and intel_runtime_suspend() unregistering the notifier. If the notifier gets called in this windowd assert_rpm_wakelock_held falsely triggers (at this point we're not runtime-suspended yet). This commit adds disable_rpm_wakeref_asserts and enable_rpm_wakeref_asserts calls around the intel_uncore_forcewake_get(FORCEWAKE_ALL) call in i915_pmic_bus_access_notifier fixing the false-positive WARN_ON. Changes in v2: -Reword comment explaining why disabling the wakeref asserts is ok and necessary Cc: stable(a)vger.kernel.org Reported-by: FKr <bugs-freedesktop(a)ubermail.me> Reviewed-by: Imre Deak <imre.deak(a)intel.com> Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> --- drivers/gpu/drm/i915/intel_uncore.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c index 211acee7c31d..dbc5cc309cbc 100644 --- a/drivers/gpu/drm/i915/intel_uncore.c +++ b/drivers/gpu/drm/i915/intel_uncore.c @@ -1364,8 +1364,15 @@ static int i915_pmic_bus_access_notifier(struct notifier_block *nb, * bus, which will be busy after this notification, leading to: * "render: timed out waiting for forcewake ack request." * errors. + * + * The notifier is unregistered during intel_runtime_suspend(), + * so it's ok to access the HW here without holding a RPM + * wake reference -> disable wakeref asserts for the time of + * the access. */ + disable_rpm_wakeref_asserts(dev_priv); intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL); + enable_rpm_wakeref_asserts(dev_priv); break; case MBI_PMIC_BUS_ACCESS_END: intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL); -- 2.14.3

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH for-4.4.y 0/4] selftests: firmware: fix mainline test runs

by Amit Pundir

Hi Greg, Please consider following upstream selftest firmware changes to help run mainline/linux-next firmware test scripts on 4.4.y, without breaking 0-day testing. 47e0bbb7fa98 ("test: firmware_class: report errors properly on failure") is the one patch actually needed to make sure mainline/linux-next selftest firmware test scripts run on 4.4.y. Following commits are, however, required to make sure the above commit doesn't break 0-day testing, wherein they run in-kernel selftests. 1b1fe542b6f0 ("selftests: firmware: add empty string and async tests") 880444e214cf ("selftests: firmware: send expected errors to /dev/null") afb999cdef69 ("tools: firmware: check for distro fallback udev cancel rule") Regards, Amit Pundir Brian Norris (2): test: firmware_class: report errors properly on failure selftests: firmware: add empty string and async tests Luis R. Rodriguez (2): selftests: firmware: send expected errors to /dev/null tools: firmware: check for distro fallback udev cancel rule lib/test_firmware.c | 11 ++++++--- tools/testing/selftests/firmware/fw_filesystem.sh | 10 +++++++- tools/testing/selftests/firmware/fw_userhelper.sh | 28 +++++++++++++++++++++-- 3 files changed, 43 insertions(+), 6 deletions(-) -- 2.7.4

7 years, 7 months

3
6
0 0

[Linux-stable-mirror] Patch "tools: firmware: check for distro fallback udev cancel rule" 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 tools: firmware: check for distro fallback udev cancel rule 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: tools-firmware-check-for-distro-fallback-udev-cancel-rule.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 afb999cdef69148f366839e74470d8f5375ba5f1 Mon Sep 17 00:00:00 2001 From: "Luis R. Rodriguez" <mcgrof(a)kernel.org> Date: Mon, 23 Jan 2017 08:11:07 -0800 Subject: tools: firmware: check for distro fallback udev cancel rule From: Luis R. Rodriguez <mcgrof(a)kernel.org> commit afb999cdef69148f366839e74470d8f5375ba5f1 upstream. Some distributions (Debian, OpenSUSE) have a udev rule in place to cancel all fallback mechanism uevents immediately. This would obviously make it hard to test against the fallback mechanism test interface, so we need to check for this. Signed-off-by: Luis R. Rodriguez <mcgrof(a)kernel.org> Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/firmware/fw_userhelper.sh | 28 ++++++++++++++++++++-- 1 file changed, 26 insertions(+), 2 deletions(-) --- a/tools/testing/selftests/firmware/fw_userhelper.sh +++ b/tools/testing/selftests/firmware/fw_userhelper.sh @@ -64,9 +64,33 @@ trap "test_finish" EXIT echo "ABCD0123" >"$FW" NAME=$(basename "$FW") +DEVPATH="$DIR"/"nope-$NAME"/loading + # Test failure when doing nothing (timeout works). -echo 1 >/sys/class/firmware/timeout -echo -n "$NAME" >"$DIR"/trigger_request +echo -n 2 >/sys/class/firmware/timeout +echo -n "nope-$NAME" >"$DIR"/trigger_request 2>/dev/null & + +# Give the kernel some time to load the loading file, must be less +# than the timeout above. +sleep 1 +if [ ! -f $DEVPATH ]; then + echo "$0: fallback mechanism immediately cancelled" + echo "" + echo "The file never appeared: $DEVPATH" + echo "" + echo "This might be a distribution udev rule setup by your distribution" + echo "to immediately cancel all fallback requests, this must be" + echo "removed before running these tests. To confirm look for" + echo "a firmware rule like /lib/udev/rules.d/50-firmware.rules" + echo "and see if you have something like this:" + echo "" + echo "SUBSYSTEM==\"firmware\", ACTION==\"add\", ATTR{loading}=\"-1\"" + echo "" + echo "If you do remove this file or comment out this line before" + echo "proceeding with these tests." + exit 1 +fi + if diff -q "$FW" /dev/test_firmware >/dev/null ; then echo "$0: firmware was not expected to match" >&2 exit 1 Patches currently in stable-queue which might be from mcgrof(a)kernel.org are queue-4.9/tools-firmware-check-for-distro-fallback-udev-cancel-rule.patch queue-4.9/selftests-firmware-send-expected-errors-to-dev-null.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "selftests: firmware: send expected errors to /dev/null" 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: firmware: send expected errors to /dev/null 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-firmware-send-expected-errors-to-dev-null.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 880444e214cfd293a2e8cc4bd3505f7ffa6ce33a Mon Sep 17 00:00:00 2001 From: "Luis R. Rodriguez" <mcgrof(a)kernel.org> Date: Fri, 16 Dec 2016 03:10:35 -0800 Subject: selftests: firmware: send expected errors to /dev/null From: Luis R. Rodriguez <mcgrof(a)kernel.org> commit 880444e214cfd293a2e8cc4bd3505f7ffa6ce33a upstream. Error that we expect should not be spilled to stdout. Without this we get: ./fw_filesystem.sh: line 58: printf: write error: Invalid argument ./fw_filesystem.sh: line 63: printf: write error: No such device ./fw_filesystem.sh: line 69: echo: write error: No such file or directory ./fw_filesystem.sh: filesystem loading works ./fw_filesystem.sh: async filesystem loading works With it: ./fw_filesystem.sh: filesystem loading works ./fw_filesystem.sh: async filesystem loading works Signed-off-by: Luis R. Rodriguez <mcgrof(a)kernel.org> Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/firmware/fw_filesystem.sh | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/tools/testing/selftests/firmware/fw_filesystem.sh +++ b/tools/testing/selftests/firmware/fw_filesystem.sh @@ -48,18 +48,18 @@ echo "ABCD0123" >"$FW" NAME=$(basename "$FW") -if printf '\000' >"$DIR"/trigger_request; then +if printf '\000' >"$DIR"/trigger_request 2> /dev/null; then echo "$0: empty filename should not succeed" >&2 exit 1 fi -if printf '\000' >"$DIR"/trigger_async_request; then +if printf '\000' >"$DIR"/trigger_async_request 2> /dev/null; then echo "$0: empty filename should not succeed (async)" >&2 exit 1 fi # Request a firmware that doesn't exist, it should fail. -if echo -n "nope-$NAME" >"$DIR"/trigger_request; then +if echo -n "nope-$NAME" >"$DIR"/trigger_request 2> /dev/null; then echo "$0: firmware shouldn't have loaded" >&2 exit 1 fi Patches currently in stable-queue which might be from mcgrof(a)kernel.org are queue-4.9/tools-firmware-check-for-distro-fallback-udev-cancel-rule.patch queue-4.9/selftests-firmware-send-expected-errors-to-dev-null.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "tools: firmware: check for distro fallback udev cancel rule" 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 tools: firmware: check for distro fallback udev cancel rule 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: tools-firmware-check-for-distro-fallback-udev-cancel-rule.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 afb999cdef69148f366839e74470d8f5375ba5f1 Mon Sep 17 00:00:00 2001 From: "Luis R. Rodriguez" <mcgrof(a)kernel.org> Date: Mon, 23 Jan 2017 08:11:07 -0800 Subject: tools: firmware: check for distro fallback udev cancel rule From: Luis R. Rodriguez <mcgrof(a)kernel.org> commit afb999cdef69148f366839e74470d8f5375ba5f1 upstream. Some distributions (Debian, OpenSUSE) have a udev rule in place to cancel all fallback mechanism uevents immediately. This would obviously make it hard to test against the fallback mechanism test interface, so we need to check for this. Signed-off-by: Luis R. Rodriguez <mcgrof(a)kernel.org> Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/firmware/fw_userhelper.sh | 28 ++++++++++++++++++++-- 1 file changed, 26 insertions(+), 2 deletions(-) --- a/tools/testing/selftests/firmware/fw_userhelper.sh +++ b/tools/testing/selftests/firmware/fw_userhelper.sh @@ -64,9 +64,33 @@ trap "test_finish" EXIT echo "ABCD0123" >"$FW" NAME=$(basename "$FW") +DEVPATH="$DIR"/"nope-$NAME"/loading + # Test failure when doing nothing (timeout works). -echo 1 >/sys/class/firmware/timeout -echo -n "$NAME" >"$DIR"/trigger_request +echo -n 2 >/sys/class/firmware/timeout +echo -n "nope-$NAME" >"$DIR"/trigger_request 2>/dev/null & + +# Give the kernel some time to load the loading file, must be less +# than the timeout above. +sleep 1 +if [ ! -f $DEVPATH ]; then + echo "$0: fallback mechanism immediately cancelled" + echo "" + echo "The file never appeared: $DEVPATH" + echo "" + echo "This might be a distribution udev rule setup by your distribution" + echo "to immediately cancel all fallback requests, this must be" + echo "removed before running these tests. To confirm look for" + echo "a firmware rule like /lib/udev/rules.d/50-firmware.rules" + echo "and see if you have something like this:" + echo "" + echo "SUBSYSTEM==\"firmware\", ACTION==\"add\", ATTR{loading}=\"-1\"" + echo "" + echo "If you do remove this file or comment out this line before" + echo "proceeding with these tests." + exit 1 +fi + if diff -q "$FW" /dev/test_firmware >/dev/null ; then echo "$0: firmware was not expected to match" >&2 exit 1 Patches currently in stable-queue which might be from mcgrof(a)kernel.org are queue-4.4/tools-firmware-check-for-distro-fallback-udev-cancel-rule.patch queue-4.4/selftests-firmware-send-expected-errors-to-dev-null.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "test: firmware_class: report errors properly on failure" 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 test: firmware_class: report errors properly on failure 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: test-firmware_class-report-errors-properly-on-failure.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 47e0bbb7fa985a0f1b5794a8653fae4f8f49de77 Mon Sep 17 00:00:00 2001 From: Brian Norris <computersforpeace(a)gmail.com> Date: Wed, 9 Dec 2015 14:50:25 -0800 Subject: test: firmware_class: report errors properly on failure From: Brian Norris <computersforpeace(a)gmail.com> commit 47e0bbb7fa985a0f1b5794a8653fae4f8f49de77 upstream. request_firmware() failures currently won't get reported at all (the error code is discarded). What's more, we get confusing messages, like: # echo -n notafile > /sys/devices/virtual/misc/test_firmware/trigger_request [ 8280.311856] test_firmware: loading 'notafile' [ 8280.317042] test_firmware: load of 'notafile' failed: -2 [ 8280.322445] test_firmware: loaded: 0 # echo $? 0 Report the failures via write() errors, and don't say we "loaded" anything. Signed-off-by: Brian Norris <computersforpeace(a)gmail.com> Acked-by: Kees Cook <keescook(a)chromium.org> Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com> Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- lib/test_firmware.c | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) --- a/lib/test_firmware.c +++ b/lib/test_firmware.c @@ -65,14 +65,19 @@ static ssize_t trigger_request_store(str release_firmware(test_firmware); test_firmware = NULL; rc = request_firmware(&test_firmware, name, dev); - if (rc) + if (rc) { pr_info("load of '%s' failed: %d\n", name, rc); - pr_info("loaded: %zu\n", test_firmware ? test_firmware->size : 0); + goto out; + } + pr_info("loaded: %zu\n", test_firmware->size); + rc = count; + +out: mutex_unlock(&test_fw_mutex); kfree(name); - return count; + return rc; } static DEVICE_ATTR_WO(trigger_request); Patches currently in stable-queue which might be from computersforpeace(a)gmail.com are queue-4.4/selftests-firmware-add-empty-string-and-async-tests.patch queue-4.4/test-firmware_class-report-errors-properly-on-failure.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "selftests: firmware: send expected errors to /dev/null" 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: firmware: send expected errors to /dev/null 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-firmware-send-expected-errors-to-dev-null.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 880444e214cfd293a2e8cc4bd3505f7ffa6ce33a Mon Sep 17 00:00:00 2001 From: "Luis R. Rodriguez" <mcgrof(a)kernel.org> Date: Fri, 16 Dec 2016 03:10:35 -0800 Subject: selftests: firmware: send expected errors to /dev/null From: Luis R. Rodriguez <mcgrof(a)kernel.org> commit 880444e214cfd293a2e8cc4bd3505f7ffa6ce33a upstream. Error that we expect should not be spilled to stdout. Without this we get: ./fw_filesystem.sh: line 58: printf: write error: Invalid argument ./fw_filesystem.sh: line 63: printf: write error: No such device ./fw_filesystem.sh: line 69: echo: write error: No such file or directory ./fw_filesystem.sh: filesystem loading works ./fw_filesystem.sh: async filesystem loading works With it: ./fw_filesystem.sh: filesystem loading works ./fw_filesystem.sh: async filesystem loading works Signed-off-by: Luis R. Rodriguez <mcgrof(a)kernel.org> [AmitP: Dropped the async trigger testing parts from original commit] Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/firmware/fw_filesystem.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/tools/testing/selftests/firmware/fw_filesystem.sh +++ b/tools/testing/selftests/firmware/fw_filesystem.sh @@ -48,13 +48,13 @@ echo "ABCD0123" >"$FW" NAME=$(basename "$FW") -if printf '\000' >"$DIR"/trigger_request; then +if printf '\000' >"$DIR"/trigger_request 2> /dev/null; then echo "$0: empty filename should not succeed" >&2 exit 1 fi # Request a firmware that doesn't exist, it should fail. -if echo -n "nope-$NAME" >"$DIR"/trigger_request; then +if echo -n "nope-$NAME" >"$DIR"/trigger_request 2> /dev/null; then echo "$0: firmware shouldn't have loaded" >&2 exit 1 fi Patches currently in stable-queue which might be from mcgrof(a)kernel.org are queue-4.4/tools-firmware-check-for-distro-fallback-udev-cancel-rule.patch queue-4.4/selftests-firmware-send-expected-errors-to-dev-null.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "selftests: firmware: add empty string and async tests" 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: firmware: add empty string and async tests 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-firmware-add-empty-string-and-async-tests.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 1b1fe542b6f010cf6bc7e1c92805e1c0e133e007 Mon Sep 17 00:00:00 2001 From: Brian Norris <computersforpeace(a)gmail.com> Date: Wed, 9 Dec 2015 14:50:29 -0800 Subject: selftests: firmware: add empty string and async tests From: Brian Norris <computersforpeace(a)gmail.com> commit 1b1fe542b6f010cf6bc7e1c92805e1c0e133e007 upstream. Now that we've added a 'trigger_async_request' knob to test the request_firmware_nowait() API, let's use it. Also add tests for the empty ("") string, since there have been a couple errors in that handling already. Since we now have real ways that the sysfs write might fail, let's add the appropriate check on the 'echo' lines too. Signed-off-by: Brian Norris <computersforpeace(a)gmail.com> Acked-by: Kees Cook <keescook(a)chromium.org> Signed-off-by: Shuah Khan <shuahkh(a)osg.samsung.com> [AmitP: Dropped the async trigger testing parts from original commit] Signed-off-by: Amit Pundir <amit.pundir(a)linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- tools/testing/selftests/firmware/fw_filesystem.sh | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) --- a/tools/testing/selftests/firmware/fw_filesystem.sh +++ b/tools/testing/selftests/firmware/fw_filesystem.sh @@ -48,8 +48,16 @@ echo "ABCD0123" >"$FW" NAME=$(basename "$FW") +if printf '\000' >"$DIR"/trigger_request; then + echo "$0: empty filename should not succeed" >&2 + exit 1 +fi + # Request a firmware that doesn't exist, it should fail. -echo -n "nope-$NAME" >"$DIR"/trigger_request +if echo -n "nope-$NAME" >"$DIR"/trigger_request; then + echo "$0: firmware shouldn't have loaded" >&2 + exit 1 +fi if diff -q "$FW" /dev/test_firmware >/dev/null ; then echo "$0: firmware was not expected to match" >&2 exit 1 Patches currently in stable-queue which might be from computersforpeace(a)gmail.com are queue-4.4/selftests-firmware-add-empty-string-and-async-tests.patch queue-4.4/test-firmware_class-report-errors-properly-on-failure.patch

7 years, 7 months

1
0
0 0

Re: [Linux-stable-mirror] FAILED: patch "[PATCH] drm/i915: Do not rely on wm preservation for ILK watermarks" failed to apply to 4.9-stable tree

by Greg KH

On Tue, Nov 07, 2017 at 09:27:49AM +0100, Maarten Lankhorst wrote: > Op 05-11-17 om 16:15 schreef gregkh(a)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 8777b927b92cf5b6c29f9f9d3c737addea9ac8a7 Mon Sep 17 00:00:00 2001 > > From: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> > > Date: Thu, 19 Oct 2017 17:13:40 +0200 > > Subject: [PATCH] drm/i915: Do not rely on wm preservation for ILK watermarks > > MIME-Version: 1.0 > > Content-Type: text/plain; charset=UTF-8 > > Content-Transfer-Encoding: 8bit > > > > The original intent was to preserve watermarks as much as possible > > in intel_pipe_wm.raw_wm, and put the validated ones in intel_pipe_wm.wm. > > > > It seems this approach is insufficient and we don't always preserve > > the raw watermarks, so just use the atomic iterator we're already using > > to get a const pointer to all bound planes on the crtc. > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102373 > > Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> > > Cc: stable(a)vger.kernel.org #v4.8+ > > Acked-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> > > Reviewed-by: Matt Roper <matthew.d.roper(a)intel.com> > > Link: https://patchwork.freedesktop.org/patch/msgid/20171019151341.4579-1-maarten… > > (cherry picked from commit 28283f4f359cd7cfa9e65457bb98c507a2cd0cd0) > > Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com> > > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h > > index fa47285918f4..79fbaf78f604 100644 > > --- a/drivers/gpu/drm/i915/intel_drv.h > > +++ b/drivers/gpu/drm/i915/intel_drv.h > > @@ -496,7 +496,6 @@ struct intel_crtc_scaler_state { > > > > struct intel_pipe_wm { > > struct intel_wm_level wm[5]; > > - struct intel_wm_level raw_wm[5]; > > uint32_t linetime; > > bool fbc_wm_enabled; > > bool pipe_enabled; > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > > index 0a09f8ff6aff..cb950752c346 100644 > > --- a/drivers/gpu/drm/i915/intel_pm.c > > +++ b/drivers/gpu/drm/i915/intel_pm.c > > @@ -2716,9 +2716,9 @@ static void ilk_compute_wm_level(const struct drm_i915_private *dev_priv, > > const struct intel_crtc *intel_crtc, > > int level, > > struct intel_crtc_state *cstate, > > - struct intel_plane_state *pristate, > > - struct intel_plane_state *sprstate, > > - struct intel_plane_state *curstate, > > + const struct intel_plane_state *pristate, > > + const struct intel_plane_state *sprstate, > > + const struct intel_plane_state *curstate, > > struct intel_wm_level *result) > > { > > uint16_t pri_latency = dev_priv->wm.pri_latency[level]; > > @@ -3038,28 +3038,24 @@ static int ilk_compute_pipe_wm(struct intel_crtc_state *cstate) > > struct intel_pipe_wm *pipe_wm; > > struct drm_device *dev = state->dev; > > const struct drm_i915_private *dev_priv = to_i915(dev); > > - struct intel_plane *intel_plane; > > - struct intel_plane_state *pristate = NULL; > > - struct intel_plane_state *sprstate = NULL; > > - struct intel_plane_state *curstate = NULL; > > + struct drm_plane *plane; > > + const struct drm_plane_state *plane_state; > > + const struct intel_plane_state *pristate = NULL; > > + const struct intel_plane_state *sprstate = NULL; > > + const struct intel_plane_state *curstate = NULL; > > int level, max_level = ilk_wm_max_level(dev_priv), usable_level; > > struct ilk_wm_maximums max; > > > > pipe_wm = &cstate->wm.ilk.optimal; > > > > - for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) { > > - struct intel_plane_state *ps; > > - > > - ps = intel_atomic_get_existing_plane_state(state, > > - intel_plane); > > - if (!ps) > > - continue; > > + drm_atomic_crtc_state_for_each_plane_state(plane, plane_state, &cstate->base) { > > + const struct intel_plane_state *ps = to_intel_plane_state(plane_state); > > > > - if (intel_plane->base.type == DRM_PLANE_TYPE_PRIMARY) > > + if (plane->type == DRM_PLANE_TYPE_PRIMARY) > > pristate = ps; > > - else if (intel_plane->base.type == DRM_PLANE_TYPE_OVERLAY) > > + else if (plane->type == DRM_PLANE_TYPE_OVERLAY) > > sprstate = ps; > > - else if (intel_plane->base.type == DRM_PLANE_TYPE_CURSOR) > > + else if (plane->type == DRM_PLANE_TYPE_CURSOR) > > curstate = ps; > > } > > > > @@ -3081,11 +3077,9 @@ static int ilk_compute_pipe_wm(struct intel_crtc_state *cstate) > > if (pipe_wm->sprites_scaled) > > usable_level = 0; > > > > - ilk_compute_wm_level(dev_priv, intel_crtc, 0, cstate, > > - pristate, sprstate, curstate, &pipe_wm->raw_wm[0]); > > - > > memset(&pipe_wm->wm, 0, sizeof(pipe_wm->wm)); > > - pipe_wm->wm[0] = pipe_wm->raw_wm[0]; > > + ilk_compute_wm_level(dev_priv, intel_crtc, 0, cstate, > > + pristate, sprstate, curstate, &pipe_wm->wm[0]); > > > > if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) > > pipe_wm->linetime = hsw_compute_linetime_wm(cstate); > > @@ -3095,8 +3089,8 @@ static int ilk_compute_pipe_wm(struct intel_crtc_state *cstate) > > > > ilk_compute_wm_reg_maximums(dev_priv, 1, &max); > > > > - for (level = 1; level <= max_level; level++) { > > - struct intel_wm_level *wm = &pipe_wm->raw_wm[level]; > > + for (level = 1; level <= usable_level; level++) { > > + struct intel_wm_level *wm = &pipe_wm->wm[level]; > > > > ilk_compute_wm_level(dev_priv, intel_crtc, level, cstate, > > pristate, sprstate, curstate, wm); > > @@ -3106,13 +3100,10 @@ static int ilk_compute_pipe_wm(struct intel_crtc_state *cstate) > > * register maximums since such watermarks are > > * always invalid. > > */ > > - if (level > usable_level) > > - continue; > > - > > - if (ilk_validate_wm_level(level, &max, wm)) > > - pipe_wm->wm[level] = *wm; > > - else > > - usable_level = level; > > + if (!ilk_validate_wm_level(level, &max, wm)) { > > + memset(wm, 0, sizeof(*wm)); > > + break; > > + } > > } > > > > return 0; > > > Is this backport good? > I care about this patch and the followup patch, since it fixes a problem > some v4.9 users experience. Now applied thanks. What is the "followup patch" that I should also apply to the 4.9-stable tree? thanks, greg k-h

7 years, 7 months

2
2
0 0

[Linux-stable-mirror] Patch "x86/uaccess, sched/preempt: Verify access_ok() 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 x86/uaccess, sched/preempt: Verify access_ok() 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: x86-uaccess-sched-preempt-verify-access_ok-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 7c4788950ba5922fde976d80b72baf46f14dee8d Mon Sep 17 00:00:00 2001 From: Peter Zijlstra <peterz(a)infradead.org> Date: Tue, 22 Nov 2016 10:57:15 +0100 Subject: x86/uaccess, sched/preempt: Verify access_ok() context From: Peter Zijlstra <peterz(a)infradead.org> commit 7c4788950ba5922fde976d80b72baf46f14dee8d upstream. I recently encountered wreckage because access_ok() was used where it should not be, add an explicit WARN when access_ok() is used wrongly. Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Cc: Andy Lutomirski <luto(a)amacapital.net> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: linux-kernel(a)vger.kernel.org Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/include/asm/uaccess.h | 13 +++++++++++-- include/linux/preempt.h | 21 +++++++++++++-------- 2 files changed, 24 insertions(+), 10 deletions(-) --- a/arch/x86/include/asm/uaccess.h +++ b/arch/x86/include/asm/uaccess.h @@ -68,6 +68,12 @@ static inline bool __chk_range_not_ok(un __chk_range_not_ok((unsigned long __force)(addr), size, limit); \ }) +#ifdef CONFIG_DEBUG_ATOMIC_SLEEP +# define WARN_ON_IN_IRQ() WARN_ON_ONCE(!in_task()) +#else +# define WARN_ON_IN_IRQ() +#endif + /** * access_ok: - Checks if a user space pointer is valid * @type: Type of access: %VERIFY_READ or %VERIFY_WRITE. Note that @@ -88,8 +94,11 @@ static inline bool __chk_range_not_ok(un * checks that the pointer is in the user space range - after calling * this function, memory access functions may still return -EFAULT. */ -#define access_ok(type, addr, size) \ - likely(!__range_not_ok(addr, size, user_addr_max())) +#define access_ok(type, addr, size) \ +({ \ + WARN_ON_IN_IRQ(); \ + likely(!__range_not_ok(addr, size, user_addr_max())); \ +}) /* * These are the main single-value transfer routines. They automatically --- a/include/linux/preempt.h +++ b/include/linux/preempt.h @@ -65,19 +65,24 @@ /* * Are we doing bottom half or hardware interrupt processing? - * Are we in a softirq context? Interrupt context? - * in_softirq - Are we currently processing softirq or have bh disabled? - * in_serving_softirq - Are we currently processing softirq? + * + * in_irq() - We're in (hard) IRQ context + * in_softirq() - We have BH disabled, or are processing softirqs + * in_interrupt() - We're in NMI,IRQ,SoftIRQ context or have BH disabled + * in_serving_softirq() - We're in softirq context + * in_nmi() - We're in NMI context + * in_task() - We're in task context + * + * Note: due to the BH disabled confusion: in_softirq(),in_interrupt() really + * should not be used in new code. */ #define in_irq() (hardirq_count()) #define in_softirq() (softirq_count()) #define in_interrupt() (irq_count()) #define in_serving_softirq() (softirq_count() & SOFTIRQ_OFFSET) - -/* - * Are we in NMI context? - */ -#define in_nmi() (preempt_count() & NMI_MASK) +#define in_nmi() (preempt_count() & NMI_MASK) +#define in_task() (!(preempt_count() & \ + (NMI_MASK | HARDIRQ_MASK | SOFTIRQ_OFFSET))) /* * The preempt_count offset after preempt_disable(); Patches currently in stable-queue which might be from peterz(a)infradead.org are queue-4.9/x86-uaccess-sched-preempt-verify-access_ok-context.patch queue-4.9/sched-core-add-missing-update_rq_clock-call-in-sched_move_task.patch queue-4.9/sched-cputime-powerpc32-fix-stale-scaled-stime-on-context-switch.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "workqueue: Fix NULL pointer dereference" 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 workqueue: Fix NULL pointer dereference 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: workqueue-fix-null-pointer-dereference.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 cef572ad9bd7f85035ba8272e5352040e8be0152 Mon Sep 17 00:00:00 2001 From: Li Bin <huawei.libin(a)huawei.com> Date: Sat, 28 Oct 2017 11:07:28 +0800 Subject: workqueue: Fix NULL pointer dereference From: Li Bin <huawei.libin(a)huawei.com> commit cef572ad9bd7f85035ba8272e5352040e8be0152 upstream. When queue_work() is used in irq (not in task context), there is a potential case that trigger NULL pointer dereference. ---------------------------------------------------------------- worker_thread() |-spin_lock_irq() |-process_one_work() |-worker->current_pwq = pwq |-spin_unlock_irq() |-worker->current_func(work) |-spin_lock_irq() |-worker->current_pwq = NULL |-spin_unlock_irq() //interrupt here |-irq_handler |-__queue_work() //assuming that the wq is draining |-is_chained_work(wq) |-current_wq_worker() //Here, 'current' is the interrupted worker! |-current->current_pwq is NULL here! |-schedule() ---------------------------------------------------------------- Avoid it by checking for task context in current_wq_worker(), and if not in task context, we shouldn't use the 'current' to check the condition. Reported-by: Xiaofei Tan <tanxiaofei(a)huawei.com> Signed-off-by: Li Bin <huawei.libin(a)huawei.com> Reviewed-by: Lai Jiangshan <jiangshanlai(a)gmail.com> Signed-off-by: Tejun Heo <tj(a)kernel.org> Fixes: 8d03ecfe4718 ("workqueue: reimplement is_chained_work() using current_wq_worker()") Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/workqueue_internal.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/kernel/workqueue_internal.h +++ b/kernel/workqueue_internal.h @@ -9,6 +9,7 @@ #include <linux/workqueue.h> #include <linux/kthread.h> +#include <linux/preempt.h> struct worker_pool; @@ -59,7 +60,7 @@ struct worker { */ static inline struct worker *current_wq_worker(void) { - if (current->flags & PF_WQ_WORKER) + if (in_task() && (current->flags & PF_WQ_WORKER)) return kthread_data(current); return NULL; } Patches currently in stable-queue which might be from huawei.libin(a)huawei.com are queue-4.9/workqueue-fix-null-pointer-dereference.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "platform/x86: hp-wmi: Fix error value for hp_wmi_tablet_state" 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 platform/x86: hp-wmi: Fix error value for hp_wmi_tablet_state 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: platform-x86-hp-wmi-fix-error-value-for-hp_wmi_tablet_state.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 c7dfc2facbd69dad89b75e13c608da709668dcd0 Mon Sep 17 00:00:00 2001 From: Carlo Caione <carlo(a)endlessm.com> Date: Sun, 9 Apr 2017 15:56:07 +0200 Subject: platform/x86: hp-wmi: Fix error value for hp_wmi_tablet_state From: Carlo Caione <carlo(a)endlessm.com> commit c7dfc2facbd69dad89b75e13c608da709668dcd0 upstream. hp_wmi_tablet_state() fails to return the correct error code when hp_wmi_perform_query() returns the HP WMI query specific error code that is a positive value. Signed-off-by: Carlo Caione <carlo(a)endlessm.com> Signed-off-by: Darren Hart (VMware) <dvhart(a)infradead.org> Cc: Philip Müller <philm(a)manjaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/platform/x86/hp-wmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/platform/x86/hp-wmi.c +++ b/drivers/platform/x86/hp-wmi.c @@ -290,7 +290,7 @@ static int hp_wmi_tablet_state(void) int ret = hp_wmi_perform_query(HPWMI_HARDWARE_QUERY, 0, &state, sizeof(state), sizeof(state)); if (ret) - return ret; + return -EINVAL; return (state & 0x4) ? 1 : 0; } Patches currently in stable-queue which might be from carlo(a)endlessm.com are queue-4.9/platform-x86-hp-wmi-do-not-shadow-error-values.patch queue-4.9/platform-x86-hp-wmi-fix-detection-for-dock-and-tablet-mode.patch queue-4.9/platform-x86-hp-wmi-fix-error-value-for-hp_wmi_tablet_state.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "platform/x86: hp-wmi: Do not shadow error 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 platform/x86: hp-wmi: Do not shadow error 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: platform-x86-hp-wmi-do-not-shadow-error-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 d313876925f3e7a480a02773fd333bcab9202d5e Mon Sep 17 00:00:00 2001 From: Carlo Caione <carlo(a)endlessm.com> Date: Wed, 19 Apr 2017 22:36:39 +0200 Subject: platform/x86: hp-wmi: Do not shadow error values From: Carlo Caione <carlo(a)endlessm.com> commit d313876925f3e7a480a02773fd333bcab9202d5e upstream. All the helper functions (i.e. hp_wmi_dock_state, hp_wmi_tablet_state, ...) using hp_wmi_perform_query to perform an HP WMI query shadow the returned value in case of error. We return -EINVAL only when the HP WMI query returns a positive value (the specific error code) to not mix this up with the actual value returned by the helper function. Suggested-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Signed-off-by: Carlo Caione <carlo(a)endlessm.com> Signed-off-by: Darren Hart (VMware) <dvhart(a)infradead.org> Cc: Philip Müller <philm(a)manjaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/platform/x86/hp-wmi.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) --- a/drivers/platform/x86/hp-wmi.c +++ b/drivers/platform/x86/hp-wmi.c @@ -248,7 +248,7 @@ static int hp_wmi_display_state(void) int ret = hp_wmi_perform_query(HPWMI_DISPLAY_QUERY, 0, &state, sizeof(state), sizeof(state)); if (ret) - return -EINVAL; + return ret < 0 ? ret : -EINVAL; return state; } @@ -258,7 +258,7 @@ static int hp_wmi_hddtemp_state(void) int ret = hp_wmi_perform_query(HPWMI_HDDTEMP_QUERY, 0, &state, sizeof(state), sizeof(state)); if (ret) - return -EINVAL; + return ret < 0 ? ret : -EINVAL; return state; } @@ -268,7 +268,7 @@ static int hp_wmi_als_state(void) int ret = hp_wmi_perform_query(HPWMI_ALS_QUERY, 0, &state, sizeof(state), sizeof(state)); if (ret) - return -EINVAL; + return ret < 0 ? ret : -EINVAL; return state; } @@ -279,7 +279,7 @@ static int hp_wmi_dock_state(void) sizeof(state), sizeof(state)); if (ret) - return -EINVAL; + return ret < 0 ? ret : -EINVAL; return state & 0x1; } @@ -290,7 +290,7 @@ static int hp_wmi_tablet_state(void) int ret = hp_wmi_perform_query(HPWMI_HARDWARE_QUERY, 0, &state, sizeof(state), sizeof(state)); if (ret) - return -EINVAL; + return ret < 0 ? ret : -EINVAL; return (state & 0x4) ? 1 : 0; } @@ -323,7 +323,7 @@ static int __init hp_wmi_enable_hotkeys( int ret = hp_wmi_perform_query(HPWMI_BIOS_QUERY, 1, &value, sizeof(value), 0); if (ret) - return -EINVAL; + return ret < 0 ? ret : -EINVAL; return 0; } @@ -336,7 +336,7 @@ static int hp_wmi_set_block(void *data, ret = hp_wmi_perform_query(HPWMI_WIRELESS_QUERY, 1, &query, sizeof(query), 0); if (ret) - return -EINVAL; + return ret < 0 ? ret : -EINVAL; return 0; } @@ -428,7 +428,7 @@ static int hp_wmi_post_code_state(void) int ret = hp_wmi_perform_query(HPWMI_POSTCODEERROR_QUERY, 0, &state, sizeof(state), sizeof(state)); if (ret) - return -EINVAL; + return ret < 0 ? ret : -EINVAL; return state; } @@ -494,7 +494,7 @@ static ssize_t set_als(struct device *de int ret = hp_wmi_perform_query(HPWMI_ALS_QUERY, 1, &tmp, sizeof(tmp), sizeof(tmp)); if (ret) - return -EINVAL; + return ret < 0 ? ret : -EINVAL; return count; } @@ -515,7 +515,7 @@ static ssize_t set_postcode(struct devic ret = hp_wmi_perform_query(HPWMI_POSTCODEERROR_QUERY, 1, &tmp, sizeof(tmp), sizeof(tmp)); if (ret) - return -EINVAL; + return ret < 0 ? ret : -EINVAL; return count; } Patches currently in stable-queue which might be from carlo(a)endlessm.com are queue-4.9/platform-x86-hp-wmi-do-not-shadow-error-values.patch queue-4.9/platform-x86-hp-wmi-fix-detection-for-dock-and-tablet-mode.patch queue-4.9/platform-x86-hp-wmi-fix-error-value-for-hp_wmi_tablet_state.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "MIPS: SMP: Use a completion event to signal CPU up" 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 MIPS: SMP: Use a completion event to signal CPU up 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: mips-smp-use-a-completion-event-to-signal-cpu-up.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 a00eeede507c975087b7b8df8cf2c9f88ba285de Mon Sep 17 00:00:00 2001 From: Matt Redfearn <matt.redfearn(a)imgtec.com> Date: Fri, 4 Nov 2016 09:28:56 +0000 Subject: MIPS: SMP: Use a completion event to signal CPU up From: Matt Redfearn <matt.redfearn(a)imgtec.com> commit a00eeede507c975087b7b8df8cf2c9f88ba285de upstream. If a secondary CPU failed to start, for any reason, the CPU requesting the secondary to start would get stuck in the loop waiting for the secondary to be present in the cpu_callin_map. Rather than that, use a completion event to signal that the secondary CPU has started and is waiting to synchronise counters. Since the CPU presence will no longer be marked in cpu_callin_map, remove the redundant test from arch_cpu_idle_dead(). Signed-off-by: Matt Redfearn <matt.redfearn(a)imgtec.com> Cc: Maciej W. Rozycki <macro(a)imgtec.com> Cc: Jiri Slaby <jslaby(a)suse.cz> Cc: Paul Gortmaker <paul.gortmaker(a)windriver.com> Cc: Chris Metcalf <cmetcalf(a)mellanox.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Qais Yousef <qsyousef(a)gmail.com> Cc: James Hogan <james.hogan(a)imgtec.com> Cc: Paul Burton <paul.burton(a)imgtec.com> Cc: Marcin Nowakowski <marcin.nowakowski(a)imgtec.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: linux-mips(a)linux-mips.org Cc: linux-kernel(a)vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/14502/ Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/kernel/process.c | 4 +--- arch/mips/kernel/smp.c | 15 +++++++++------ 2 files changed, 10 insertions(+), 9 deletions(-) --- a/arch/mips/kernel/process.c +++ b/arch/mips/kernel/process.c @@ -50,9 +50,7 @@ #ifdef CONFIG_HOTPLUG_CPU void arch_cpu_idle_dead(void) { - /* What the heck is this check doing ? */ - if (!cpumask_test_cpu(smp_processor_id(), &cpu_callin_map)) - play_dead(); + play_dead(); } #endif --- a/arch/mips/kernel/smp.c +++ b/arch/mips/kernel/smp.c @@ -68,6 +68,8 @@ EXPORT_SYMBOL(cpu_sibling_map); cpumask_t cpu_core_map[NR_CPUS] __read_mostly; EXPORT_SYMBOL(cpu_core_map); +static DECLARE_COMPLETION(cpu_running); + /* * A logcal cpu mask containing only one VPE per core to * reduce the number of IPIs on large MT systems. @@ -369,7 +371,7 @@ asmlinkage void start_secondary(void) cpumask_set_cpu(cpu, &cpu_coherent_mask); notify_cpu_starting(cpu); - cpumask_set_cpu(cpu, &cpu_callin_map); + complete(&cpu_running); synchronise_count_slave(cpu); set_cpu_online(cpu, true); @@ -430,7 +432,6 @@ void smp_prepare_boot_cpu(void) { set_cpu_possible(0, true); set_cpu_online(0, true); - cpumask_set_cpu(0, &cpu_callin_map); } int __cpu_up(unsigned int cpu, struct task_struct *tidle) @@ -438,11 +439,13 @@ int __cpu_up(unsigned int cpu, struct ta mp_ops->boot_secondary(cpu, tidle); /* - * Trust is futile. We should really have timeouts ... + * We must check for timeout here, as the CPU will not be marked + * online until the counters are synchronised. */ - while (!cpumask_test_cpu(cpu, &cpu_callin_map)) { - udelay(100); - schedule(); + if (!wait_for_completion_timeout(&cpu_running, + msecs_to_jiffies(1000))) { + pr_crit("CPU%u: failed to start\n", cpu); + return -EIO; } synchronise_count_master(cpu); Patches currently in stable-queue which might be from matt.redfearn(a)imgtec.com are queue-4.9/mips-smp-fix-deadlock-online-race.patch queue-4.9/mips-smp-use-a-completion-event-to-signal-cpu-up.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "MIPS: SMP: Fix deadlock & online race" 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 MIPS: SMP: Fix deadlock & online race 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: mips-smp-fix-deadlock-online-race.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 9e8c399a88f0b87e41a894911475ed2a8f8dff9e Mon Sep 17 00:00:00 2001 From: Matt Redfearn <matt.redfearn(a)imgtec.com> Date: Wed, 27 Sep 2017 10:13:25 +0100 Subject: MIPS: SMP: Fix deadlock & online race From: Matt Redfearn <matt.redfearn(a)imgtec.com> commit 9e8c399a88f0b87e41a894911475ed2a8f8dff9e upstream. Commit 6f542ebeaee0 ("MIPS: Fix race on setting and getting cpu_online_mask") effectively reverted commit 8f46cca1e6c06 ("MIPS: SMP: Fix possibility of deadlock when bringing CPUs online") and thus has reinstated the possibility of deadlock. The commit was based on testing of kernel v4.4, where the CPU hotplug core code issued a BUG() if the starting CPU is not marked online when the boot CPU returns from __cpu_up. The commit fixes this race (in v4.4), but re-introduces the deadlock situation. As noted in the commit message, upstream differs in this area. Commit 8df3e07e7f21f ("cpu/hotplug: Let upcoming cpu bring itself fully up") adds a completion event in the CPU hotplug core code, making this race impossible. However, people were unhappy with relying on the core code to do the right thing. To address the issues both commits were trying to fix, add a second completion event in the MIPS smp hotplug path. It removes the possibility of a race, since the MIPS smp hotplug code now synchronises both the boot and secondary CPUs before they return to the hotplug core code. It also addresses the deadlock by ensuring that the secondary CPU is not marked online before it's counters are synchronised. This fix should also be backported to fix the race condition introduced by the backport of commit 8f46cca1e6c06 ("MIPS: SMP: Fix possibility of deadlock when bringing CPUs online"), through really that race only existed before commit 8df3e07e7f21f ("cpu/hotplug: Let upcoming cpu bring itself fully up"). Signed-off-by: Matt Redfearn <matt.redfearn(a)imgtec.com> Fixes: 6f542ebeaee0 ("MIPS: Fix race on setting and getting cpu_online_mask") CC: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext(a)nokia.com> Patchwork: https://patchwork.linux-mips.org/patch/17376/ Signed-off-by: James Hogan <jhogan(a)kernel.org> [jhogan(a)kernel.org: Backported 4.1..4.9] Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/kernel/smp.c | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-) --- a/arch/mips/kernel/smp.c +++ b/arch/mips/kernel/smp.c @@ -68,6 +68,7 @@ EXPORT_SYMBOL(cpu_sibling_map); cpumask_t cpu_core_map[NR_CPUS] __read_mostly; EXPORT_SYMBOL(cpu_core_map); +static DECLARE_COMPLETION(cpu_starting); static DECLARE_COMPLETION(cpu_running); /* @@ -371,6 +372,12 @@ asmlinkage void start_secondary(void) cpumask_set_cpu(cpu, &cpu_coherent_mask); notify_cpu_starting(cpu); + /* Notify boot CPU that we're starting & ready to sync counters */ + complete(&cpu_starting); + + synchronise_count_slave(cpu); + + /* The CPU is running and counters synchronised, now mark it online */ set_cpu_online(cpu, true); set_cpu_sibling_map(cpu); @@ -378,8 +385,11 @@ asmlinkage void start_secondary(void) calculate_cpu_foreign_map(); + /* + * Notify boot CPU that we're up & online and it can safely return + * from __cpu_up + */ complete(&cpu_running); - synchronise_count_slave(cpu); /* * irq will be enabled in ->smp_finish(), enabling it too early @@ -438,17 +448,17 @@ int __cpu_up(unsigned int cpu, struct ta { mp_ops->boot_secondary(cpu, tidle); - /* - * We must check for timeout here, as the CPU will not be marked - * online until the counters are synchronised. - */ - if (!wait_for_completion_timeout(&cpu_running, + /* Wait for CPU to start and be ready to sync counters */ + if (!wait_for_completion_timeout(&cpu_starting, msecs_to_jiffies(1000))) { pr_crit("CPU%u: failed to start\n", cpu); return -EIO; } synchronise_count_master(cpu); + + /* Wait for CPU to finish startup & mark itself online before return */ + wait_for_completion(&cpu_running); return 0; } Patches currently in stable-queue which might be from matt.redfearn(a)imgtec.com are queue-4.9/mips-smp-fix-deadlock-online-race.patch queue-4.9/mips-smp-use-a-completion-event-to-signal-cpu-up.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "MIPS: microMIPS: Fix incorrect mask in insn_table_MM" 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 MIPS: microMIPS: Fix incorrect mask in insn_table_MM 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: mips-micromips-fix-incorrect-mask-in-insn_table_mm.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 77238e76b9156d28d86c1e31c00ed2960df0e4de Mon Sep 17 00:00:00 2001 From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com> Date: Tue, 31 Oct 2017 00:35:03 -0500 Subject: MIPS: microMIPS: Fix incorrect mask in insn_table_MM From: Gustavo A. R. Silva <garsilva(a)embeddedor.com> commit 77238e76b9156d28d86c1e31c00ed2960df0e4de upstream. It seems that this is a typo error and the proper bit masking is "RT | RS" instead of "RS | RS". This issue was detected with the help of Coccinelle. Fixes: d6b3314b49e1 ("MIPS: uasm: Add lh uam instruction") Reported-by: Julia Lawall <julia.lawall(a)lip6.fr> Signed-off-by: Gustavo A. R. Silva <garsilva(a)embeddedor.com> Reviewed-by: James Hogan <jhogan(a)kernel.org> Patchwork: https://patchwork.linux-mips.org/patch/17551/ Signed-off-by: James Hogan <jhogan(a)kernel.org> [jhogan(a)kernel.org: Backported 3.16..4.12] Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/mm/uasm-micromips.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/mips/mm/uasm-micromips.c +++ b/arch/mips/mm/uasm-micromips.c @@ -80,7 +80,7 @@ static struct insn insn_table_MM[] = { { insn_jr, M(mm_pool32a_op, 0, 0, 0, mm_jalr_op, mm_pool32axf_op), RS }, { insn_lb, M(mm_lb32_op, 0, 0, 0, 0, 0), RT | RS | SIMM }, { insn_ld, 0, 0 }, - { insn_lh, M(mm_lh32_op, 0, 0, 0, 0, 0), RS | RS | SIMM }, + { insn_lh, M(mm_lh32_op, 0, 0, 0, 0, 0), RT | RS | SIMM }, { insn_ll, M(mm_pool32c_op, 0, 0, (mm_ll_func << 1), 0, 0), RS | RT | SIMM }, { insn_lld, 0, 0 }, { insn_lui, M(mm_pool32i_op, mm_lui_op, 0, 0, 0, 0), RS | SIMM }, Patches currently in stable-queue which might be from garsilva(a)embeddedor.com are queue-4.9/mips-micromips-fix-incorrect-mask-in-insn_table_mm.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "MIPS: Fix race on setting and getting cpu_online_mask" 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 MIPS: Fix race on setting and getting cpu_online_mask 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: mips-fix-race-on-setting-and-getting-cpu_online_mask.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 6f542ebeaee0ee552a902ce3892220fc22c7ec8e Mon Sep 17 00:00:00 2001 From: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext(a)nokia.com> Date: Thu, 3 Aug 2017 08:20:22 +0200 Subject: MIPS: Fix race on setting and getting cpu_online_mask From: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext(a)nokia.com> commit 6f542ebeaee0ee552a902ce3892220fc22c7ec8e upstream. While testing cpu hoptlug (cpu down and up in loops) on kernel 4.4, it was observed that occasionally check for cpu online will fail in kernel/cpu.c, _cpu_up: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tre… 518 /* Arch-specific enabling code. */ 519 ret = __cpu_up(cpu, idle); 520 521 if (ret != 0) 522 goto out_notify; 523 BUG_ON(!cpu_online(cpu)); Reason is race between start_secondary and _cpu_up. cpu_callin_map is set before cpu_online_mask. In __cpu_up, cpu_callin_map is waited for, but cpu online mask is not, resulting in race in which secondary processor started and set cpu_callin_map, but not yet set the online mask,resulting in above BUG being hit. Upstream differs in the area. cpu_online check is in bringup_wait_for_ap, which is after cpu reached AP_ONLINE_IDLE,where secondary passed its start function. Nonetheless, fix makes start_secondary safe and not depending on other locks throughout the code. It protects as well against cpu_online checks put in between sometimes in the future. Fix this by moving completion after all flags are set. Signed-off-by: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext(a)nokia.com> Cc: Alexander Sverdlin <alexander.sverdlin(a)nokia.com> Cc: linux-mips(a)linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/16925/ Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/kernel/smp.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/arch/mips/kernel/smp.c +++ b/arch/mips/kernel/smp.c @@ -371,9 +371,6 @@ asmlinkage void start_secondary(void) cpumask_set_cpu(cpu, &cpu_coherent_mask); notify_cpu_starting(cpu); - complete(&cpu_running); - synchronise_count_slave(cpu); - set_cpu_online(cpu, true); set_cpu_sibling_map(cpu); @@ -381,6 +378,9 @@ asmlinkage void start_secondary(void) calculate_cpu_foreign_map(); + complete(&cpu_running); + synchronise_count_slave(cpu); + /* * irq will be enabled in ->smp_finish(), enabling it too early * is dangerous. Patches currently in stable-queue which might be from matija.glavinic-pecotic.ext(a)nokia.com are queue-4.9/mips-fix-race-on-setting-and-getting-cpu_online_mask.patch queue-4.9/mips-smp-fix-deadlock-online-race.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "MIPS: Fix CM region target definitions" 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 MIPS: Fix CM region target definitions 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: mips-fix-cm-region-target-definitions.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 6a6cba1d945a7511cdfaf338526871195e420762 Mon Sep 17 00:00:00 2001 From: Paul Burton <paul.burton(a)mips.com> Date: Tue, 31 Oct 2017 15:09:22 -0700 Subject: MIPS: Fix CM region target definitions From: Paul Burton <paul.burton(a)mips.com> commit 6a6cba1d945a7511cdfaf338526871195e420762 upstream. The default CM target field in the GCR_BASE register is encoded with 0 meaning memory & 1 being reserved. However the definitions we use for those bits effectively get these two values backwards - likely because they were copied from the definitions for the CM regions where the target is encoded differently. This results in use setting up GCR_BASE with the reserved target value by default, rather than targeting memory as intended. Although we currently seem to get away with this it's not a great idea to rely upon. Fix this by changing our macros to match the documentated target values. The incorrect encoding became used as of commit 9f98f3dd0c51 ("MIPS: Add generic CM probe & access code") in the Linux v3.15 cycle, and was likely carried forwards from older but unused code introduced by commit 39b8d5254246 ("[MIPS] Add support for MIPS CMP platform.") in the v2.6.26 cycle. Fixes: 9f98f3dd0c51 ("MIPS: Add generic CM probe & access code") Signed-off-by: Paul Burton <paul.burton(a)mips.com> Reported-by: Matt Redfearn <matt.redfearn(a)mips.com> Reviewed-by: James Hogan <jhogan(a)kernel.org> Cc: Matt Redfearn <matt.redfearn(a)mips.com> Cc: Ralf Baechle <ralf(a)linux-mips.org> Cc: linux-mips(a)linux-mips.org Cc: <stable(a)vger.kernel.org> # v3.15+ Patchwork: https://patchwork.linux-mips.org/patch/17562/ Signed-off-by: James Hogan <jhogan(a)kernel.org> [jhogan(a)kernel.org: Backported 3.15..4.13] Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/include/asm/mips-cm.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/arch/mips/include/asm/mips-cm.h +++ b/arch/mips/include/asm/mips-cm.h @@ -239,8 +239,8 @@ BUILD_CM_Cx_R_(tcid_8_priority, 0x80) #define CM_GCR_BASE_GCRBASE_MSK (_ULCAST_(0x1ffff) << 15) #define CM_GCR_BASE_CMDEFTGT_SHF 0 #define CM_GCR_BASE_CMDEFTGT_MSK (_ULCAST_(0x3) << 0) -#define CM_GCR_BASE_CMDEFTGT_DISABLED 0 -#define CM_GCR_BASE_CMDEFTGT_MEM 1 +#define CM_GCR_BASE_CMDEFTGT_MEM 0 +#define CM_GCR_BASE_CMDEFTGT_RESERVED 1 #define CM_GCR_BASE_CMDEFTGT_IOCU0 2 #define CM_GCR_BASE_CMDEFTGT_IOCU1 3 Patches currently in stable-queue which might be from paul.burton(a)mips.com are queue-4.9/mips-fix-cm-region-target-definitions.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "KEYS: fix NULL pointer dereference during ASN.1 parsing [ver #2]" 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 KEYS: fix NULL pointer dereference during ASN.1 parsing [ver #2] 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: keys-fix-null-pointer-dereference-during-asn.1-parsing.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 624f5ab8720b3371367327a822c267699c1823b8 Mon Sep 17 00:00:00 2001 From: Eric Biggers <ebiggers(a)google.com> Date: Tue, 7 Nov 2017 22:29:02 +0000 Subject: KEYS: fix NULL pointer dereference during ASN.1 parsing [ver #2] From: Eric Biggers <ebiggers(a)google.com> commit 624f5ab8720b3371367327a822c267699c1823b8 upstream. syzkaller reported a NULL pointer dereference in asn1_ber_decoder(). It can be reproduced by the following command, assuming CONFIG_PKCS7_TEST_KEY=y: keyctl add pkcs7_test desc '' @s The bug is that if the data buffer is empty, an integer underflow occurs in the following check: if (unlikely(dp >= datalen - 1)) goto data_overrun_error; This results in the NULL data pointer being dereferenced. Fix it by checking for 'datalen - dp < 2' instead. Also fix the similar check for 'dp >= datalen - n' later in the same function. That one possibly could result in a buffer overread. The NULL pointer dereference was reproducible using the "pkcs7_test" key type but not the "asymmetric" key type because the "asymmetric" key type checks for a 0-length payload before calling into the ASN.1 decoder but the "pkcs7_test" key type does not. The bug report was: BUG: unable to handle kernel NULL pointer dereference at (null) IP: asn1_ber_decoder+0x17f/0xe60 lib/asn1_decoder.c:233 PGD 7b708067 P4D 7b708067 PUD 7b6ee067 PMD 0 Oops: 0000 [#1] SMP Modules linked in: CPU: 0 PID: 522 Comm: syz-executor1 Not tainted 4.14.0-rc8 #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.3-20171021_125229-anatol 04/01/2014 task: ffff9b6b3798c040 task.stack: ffff9b6b37970000 RIP: 0010:asn1_ber_decoder+0x17f/0xe60 lib/asn1_decoder.c:233 RSP: 0018:ffff9b6b37973c78 EFLAGS: 00010216 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000021c RDX: ffffffff814a04ed RSI: ffffb1524066e000 RDI: ffffffff910759e0 RBP: ffff9b6b37973d60 R08: 0000000000000001 R09: ffff9b6b3caa4180 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f10ed1f2700(0000) GS:ffff9b6b3ea00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000007b6f3000 CR4: 00000000000006f0 Call Trace: pkcs7_parse_message+0xee/0x240 crypto/asymmetric_keys/pkcs7_parser.c:139 verify_pkcs7_signature+0x33/0x180 certs/system_keyring.c:216 pkcs7_preparse+0x41/0x70 crypto/asymmetric_keys/pkcs7_key_type.c:63 key_create_or_update+0x180/0x530 security/keys/key.c:855 SYSC_add_key security/keys/keyctl.c:122 [inline] SyS_add_key+0xbf/0x250 security/keys/keyctl.c:62 entry_SYSCALL_64_fastpath+0x1f/0xbe RIP: 0033:0x4585c9 RSP: 002b:00007f10ed1f1bd8 EFLAGS: 00000216 ORIG_RAX: 00000000000000f8 RAX: ffffffffffffffda RBX: 00007f10ed1f2700 RCX: 00000000004585c9 RDX: 0000000020000000 RSI: 0000000020008ffb RDI: 0000000020008000 RBP: 0000000000000000 R08: ffffffffffffffff R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000216 R12: 00007fff1b2260ae R13: 00007fff1b2260af R14: 00007f10ed1f2700 R15: 0000000000000000 Code: dd ca ff 48 8b 45 88 48 83 e8 01 4c 39 f0 0f 86 a8 07 00 00 e8 53 dd ca ff 49 8d 46 01 48 89 85 58 ff ff ff 48 8b 85 60 ff ff ff <42> 0f b6 0c 30 89 c8 88 8d 75 ff ff ff 83 e0 1f 89 8d 28 ff ff RIP: asn1_ber_decoder+0x17f/0xe60 lib/asn1_decoder.c:233 RSP: ffff9b6b37973c78 CR2: 0000000000000000 Fixes: 42d5ec27f873 ("X.509: Add an ASN.1 decoder") Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: James Morris <james.l.morris(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- lib/asn1_decoder.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/lib/asn1_decoder.c +++ b/lib/asn1_decoder.c @@ -228,7 +228,7 @@ next_op: hdr = 2; /* Extract a tag from the data */ - if (unlikely(dp >= datalen - 1)) + if (unlikely(datalen - dp < 2)) goto data_overrun_error; tag = data[dp++]; if (unlikely((tag & 0x1f) == ASN1_LONG_TAG)) @@ -274,7 +274,7 @@ next_op: int n = len - 0x80; if (unlikely(n > 2)) goto length_too_long; - if (unlikely(dp >= datalen - n)) + if (unlikely(n > datalen - dp)) goto data_overrun_error; hdr += n; for (len = 0; n > 0; n--) { Patches currently in stable-queue which might be from ebiggers(a)google.com are queue-4.9/keys-trusted-sanitize-all-key-material.patch queue-4.9/keys-trusted-fix-writing-past-end-of-buffer-in-trusted_read.patch queue-4.9/keys-fix-null-pointer-dereference-during-asn.1-parsing.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "crypto: x86/sha256-mb - fix panic due to unaligned access" 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 crypto: x86/sha256-mb - fix panic due to unaligned access 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: crypto-x86-sha256-mb-fix-panic-due-to-unaligned-access.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 5dfeaac15f2b1abb5a53c9146041c7235eb9aa04 Mon Sep 17 00:00:00 2001 From: Andrey Ryabinin <aryabinin(a)virtuozzo.com> Date: Mon, 16 Oct 2017 18:51:30 +0300 Subject: crypto: x86/sha256-mb - fix panic due to unaligned access From: Andrey Ryabinin <aryabinin(a)virtuozzo.com> commit 5dfeaac15f2b1abb5a53c9146041c7235eb9aa04 upstream. struct sha256_ctx_mgr allocated in sha256_mb_mod_init() via kzalloc() and later passed in sha256_mb_flusher_mgr_flush_avx2() function where instructions vmovdqa used to access the struct. vmovdqa requires 16-bytes aligned argument, but nothing guarantees that struct sha256_ctx_mgr will have that alignment. Unaligned vmovdqa will generate GP fault. Fix this by replacing vmovdqa with vmovdqu which doesn't have alignment requirements. Fixes: a377c6b1876e ("crypto: sha256-mb - submit/flush routines for AVX2") Reported-by: Josh Poimboeuf <jpoimboe(a)redhat.com> Signed-off-by: Andrey Ryabinin <aryabinin(a)virtuozzo.com> Acked-by: Tim Chen Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/crypto/sha256-mb/sha256_mb_mgr_flush_avx2.S | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) --- a/arch/x86/crypto/sha256-mb/sha256_mb_mgr_flush_avx2.S +++ b/arch/x86/crypto/sha256-mb/sha256_mb_mgr_flush_avx2.S @@ -155,8 +155,8 @@ LABEL skip_ %I .endr # Find min length - vmovdqa _lens+0*16(state), %xmm0 - vmovdqa _lens+1*16(state), %xmm1 + vmovdqu _lens+0*16(state), %xmm0 + vmovdqu _lens+1*16(state), %xmm1 vpminud %xmm1, %xmm0, %xmm2 # xmm2 has {D,C,B,A} vpalignr $8, %xmm2, %xmm3, %xmm3 # xmm3 has {x,x,D,C} @@ -176,8 +176,8 @@ LABEL skip_ %I vpsubd %xmm2, %xmm0, %xmm0 vpsubd %xmm2, %xmm1, %xmm1 - vmovdqa %xmm0, _lens+0*16(state) - vmovdqa %xmm1, _lens+1*16(state) + vmovdqu %xmm0, _lens+0*16(state) + vmovdqu %xmm1, _lens+1*16(state) # "state" and "args" are the same address, arg1 # len is arg2 @@ -234,8 +234,8 @@ ENTRY(sha256_mb_mgr_get_comp_job_avx2) jc .return_null # Find min length - vmovdqa _lens(state), %xmm0 - vmovdqa _lens+1*16(state), %xmm1 + vmovdqu _lens(state), %xmm0 + vmovdqu _lens+1*16(state), %xmm1 vpminud %xmm1, %xmm0, %xmm2 # xmm2 has {D,C,B,A} vpalignr $8, %xmm2, %xmm3, %xmm3 # xmm3 has {x,x,D,C} Patches currently in stable-queue which might be from aryabinin(a)virtuozzo.com are queue-4.9/crypto-x86-sha256-mb-fix-panic-due-to-unaligned-access.patch queue-4.9/crypto-x86-sha1-mb-fix-panic-due-to-unaligned-access.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "drm/i915: Do not rely on wm preservation for ILK watermarks" 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/i915: Do not rely on wm preservation for ILK watermarks 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-i915-do-not-rely-on-wm-preservation-for-ilk-watermarks.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 8777b927b92cf5b6c29f9f9d3c737addea9ac8a7 Mon Sep 17 00:00:00 2001 From: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Date: Thu, 19 Oct 2017 17:13:40 +0200 Subject: drm/i915: Do not rely on wm preservation for ILK watermarks MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> commit 8777b927b92cf5b6c29f9f9d3c737addea9ac8a7 upstream. The original intent was to preserve watermarks as much as possible in intel_pipe_wm.raw_wm, and put the validated ones in intel_pipe_wm.wm. It seems this approach is insufficient and we don't always preserve the raw watermarks, so just use the atomic iterator we're already using to get a const pointer to all bound planes on the crtc. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102373 Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Acked-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171019151341.4579-1-maarten… (cherry picked from commit 28283f4f359cd7cfa9e65457bb98c507a2cd0cd0) Signed-off-by: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/gpu/drm/i915/intel_drv.h | 1 drivers/gpu/drm/i915/intel_pm.c | 52 ++++++++++++++++----------------------- 2 files changed, 22 insertions(+), 31 deletions(-) --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -457,7 +457,6 @@ struct intel_crtc_scaler_state { struct intel_pipe_wm { struct intel_wm_level wm[5]; - struct intel_wm_level raw_wm[5]; uint32_t linetime; bool fbc_wm_enabled; bool pipe_enabled; --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -27,6 +27,7 @@ #include <linux/cpufreq.h> #include <drm/drm_plane_helper.h> +#include <drm/drm_atomic_helper.h> #include "i915_drv.h" #include "intel_drv.h" #include "../../../platform/x86/intel_ips.h" @@ -2017,9 +2018,9 @@ static void ilk_compute_wm_level(const s const struct intel_crtc *intel_crtc, int level, struct intel_crtc_state *cstate, - struct intel_plane_state *pristate, - struct intel_plane_state *sprstate, - struct intel_plane_state *curstate, + const struct intel_plane_state *pristate, + const struct intel_plane_state *sprstate, + const struct intel_plane_state *curstate, struct intel_wm_level *result) { uint16_t pri_latency = dev_priv->wm.pri_latency[level]; @@ -2341,28 +2342,24 @@ static int ilk_compute_pipe_wm(struct in struct intel_pipe_wm *pipe_wm; struct drm_device *dev = state->dev; const struct drm_i915_private *dev_priv = to_i915(dev); - struct intel_plane *intel_plane; - struct intel_plane_state *pristate = NULL; - struct intel_plane_state *sprstate = NULL; - struct intel_plane_state *curstate = NULL; + struct drm_plane *plane; + const struct drm_plane_state *plane_state; + const struct intel_plane_state *pristate = NULL; + const struct intel_plane_state *sprstate = NULL; + const struct intel_plane_state *curstate = NULL; int level, max_level = ilk_wm_max_level(dev), usable_level; struct ilk_wm_maximums max; pipe_wm = &cstate->wm.ilk.optimal; - for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) { - struct intel_plane_state *ps; + drm_atomic_crtc_state_for_each_plane_state(plane, plane_state, &cstate->base) { + const struct intel_plane_state *ps = to_intel_plane_state(plane_state); - ps = intel_atomic_get_existing_plane_state(state, - intel_plane); - if (!ps) - continue; - - if (intel_plane->base.type == DRM_PLANE_TYPE_PRIMARY) + if (plane->type == DRM_PLANE_TYPE_PRIMARY) pristate = ps; - else if (intel_plane->base.type == DRM_PLANE_TYPE_OVERLAY) + else if (plane->type == DRM_PLANE_TYPE_OVERLAY) sprstate = ps; - else if (intel_plane->base.type == DRM_PLANE_TYPE_CURSOR) + else if (plane->type == DRM_PLANE_TYPE_CURSOR) curstate = ps; } @@ -2384,11 +2381,9 @@ static int ilk_compute_pipe_wm(struct in if (pipe_wm->sprites_scaled) usable_level = 0; - ilk_compute_wm_level(dev_priv, intel_crtc, 0, cstate, - pristate, sprstate, curstate, &pipe_wm->raw_wm[0]); - memset(&pipe_wm->wm, 0, sizeof(pipe_wm->wm)); - pipe_wm->wm[0] = pipe_wm->raw_wm[0]; + ilk_compute_wm_level(dev_priv, intel_crtc, 0, cstate, + pristate, sprstate, curstate, &pipe_wm->wm[0]); if (IS_HASWELL(dev) || IS_BROADWELL(dev)) pipe_wm->linetime = hsw_compute_linetime_wm(cstate); @@ -2398,8 +2393,8 @@ static int ilk_compute_pipe_wm(struct in ilk_compute_wm_reg_maximums(dev, 1, &max); - for (level = 1; level <= max_level; level++) { - struct intel_wm_level *wm = &pipe_wm->raw_wm[level]; + for (level = 1; level <= usable_level; level++) { + struct intel_wm_level *wm = &pipe_wm->wm[level]; ilk_compute_wm_level(dev_priv, intel_crtc, level, cstate, pristate, sprstate, curstate, wm); @@ -2409,13 +2404,10 @@ static int ilk_compute_pipe_wm(struct in * register maximums since such watermarks are * always invalid. */ - if (level > usable_level) - continue; - - if (ilk_validate_wm_level(level, &max, wm)) - pipe_wm->wm[level] = *wm; - else - usable_level = level; + if (!ilk_validate_wm_level(level, &max, wm)) { + memset(wm, 0, sizeof(*wm)); + break; + } } return 0; Patches currently in stable-queue which might be from maarten.lankhorst(a)linux.intel.com are queue-4.9/drm-i915-do-not-rely-on-wm-preservation-for-ilk-watermarks.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "crypto: ccm - preserve the IV buffer" 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 crypto: ccm - preserve the IV buffer 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: crypto-ccm-preserve-the-iv-buffer.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 441f99c90497e15aa3ad1dbabd56187e29614348 Mon Sep 17 00:00:00 2001 From: Romain Izard <romain.izard.pro(a)gmail.com> Date: Tue, 31 Oct 2017 15:42:35 +0100 Subject: crypto: ccm - preserve the IV buffer From: Romain Izard <romain.izard.pro(a)gmail.com> commit 441f99c90497e15aa3ad1dbabd56187e29614348 upstream. The IV buffer used during CCM operations is used twice, during both the hashing step and the ciphering step. When using a hardware accelerator that updates the contents of the IV buffer at the end of ciphering operations, the value will be modified. In the decryption case, the subsequent setup of the hashing algorithm will interpret the updated IV instead of the original value, which can lead to out-of-bounds writes. Reuse the idata buffer, only used in the hashing step, to preserve the IV's value during the ciphering step in the decryption case. Signed-off-by: Romain Izard <romain.izard.pro(a)gmail.com> Reviewed-by: Tudor Ambarus <tudor.ambarus(a)microchip.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- crypto/ccm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/crypto/ccm.c +++ b/crypto/ccm.c @@ -413,7 +413,7 @@ static int crypto_ccm_decrypt(struct aea unsigned int cryptlen = req->cryptlen; u8 *authtag = pctx->auth_tag; u8 *odata = pctx->odata; - u8 *iv = req->iv; + u8 *iv = pctx->idata; int err; cryptlen -= authsize; @@ -429,6 +429,8 @@ static int crypto_ccm_decrypt(struct aea if (req->src != req->dst) dst = pctx->dst; + memcpy(iv, req->iv, 16); + skcipher_request_set_tfm(skreq, ctx->ctr); skcipher_request_set_callback(skreq, pctx->flags, crypto_ccm_decrypt_done, req); Patches currently in stable-queue which might be from romain.izard.pro(a)gmail.com are queue-4.9/crypto-ccm-preserve-the-iv-buffer.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "crypto: x86/sha1-mb - fix panic due to unaligned access" 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 crypto: x86/sha1-mb - fix panic due to unaligned access 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: crypto-x86-sha1-mb-fix-panic-due-to-unaligned-access.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 d041b557792c85677f17e08eee535eafbd6b9aa2 Mon Sep 17 00:00:00 2001 From: Andrey Ryabinin <aryabinin(a)virtuozzo.com> Date: Mon, 16 Oct 2017 18:51:31 +0300 Subject: crypto: x86/sha1-mb - fix panic due to unaligned access From: Andrey Ryabinin <aryabinin(a)virtuozzo.com> commit d041b557792c85677f17e08eee535eafbd6b9aa2 upstream. struct sha1_ctx_mgr allocated in sha1_mb_mod_init() via kzalloc() and later passed in sha1_mb_flusher_mgr_flush_avx2() function where instructions vmovdqa used to access the struct. vmovdqa requires 16-bytes aligned argument, but nothing guarantees that struct sha1_ctx_mgr will have that alignment. Unaligned vmovdqa will generate GP fault. Fix this by replacing vmovdqa with vmovdqu which doesn't have alignment requirements. Fixes: 2249cbb53ead ("crypto: sha-mb - SHA1 multibuffer submit and flush routines for AVX2") Signed-off-by: Andrey Ryabinin <aryabinin(a)virtuozzo.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/crypto/sha1-mb/sha1_mb_mgr_flush_avx2.S | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) --- a/arch/x86/crypto/sha1-mb/sha1_mb_mgr_flush_avx2.S +++ b/arch/x86/crypto/sha1-mb/sha1_mb_mgr_flush_avx2.S @@ -157,8 +157,8 @@ LABEL skip_ %I .endr # Find min length - vmovdqa _lens+0*16(state), %xmm0 - vmovdqa _lens+1*16(state), %xmm1 + vmovdqu _lens+0*16(state), %xmm0 + vmovdqu _lens+1*16(state), %xmm1 vpminud %xmm1, %xmm0, %xmm2 # xmm2 has {D,C,B,A} vpalignr $8, %xmm2, %xmm3, %xmm3 # xmm3 has {x,x,D,C} @@ -178,8 +178,8 @@ LABEL skip_ %I vpsubd %xmm2, %xmm0, %xmm0 vpsubd %xmm2, %xmm1, %xmm1 - vmovdqa %xmm0, _lens+0*16(state) - vmovdqa %xmm1, _lens+1*16(state) + vmovdqu %xmm0, _lens+0*16(state) + vmovdqu %xmm1, _lens+1*16(state) # "state" and "args" are the same address, arg1 # len is arg2 @@ -235,8 +235,8 @@ ENTRY(sha1_mb_mgr_get_comp_job_avx2) jc .return_null # Find min length - vmovdqa _lens(state), %xmm0 - vmovdqa _lens+1*16(state), %xmm1 + vmovdqu _lens(state), %xmm0 + vmovdqu _lens+1*16(state), %xmm1 vpminud %xmm1, %xmm0, %xmm2 # xmm2 has {D,C,B,A} vpalignr $8, %xmm2, %xmm3, %xmm3 # xmm3 has {x,x,D,C} Patches currently in stable-queue which might be from aryabinin(a)virtuozzo.com are queue-4.9/crypto-x86-sha256-mb-fix-panic-due-to-unaligned-access.patch queue-4.9/crypto-x86-sha1-mb-fix-panic-due-to-unaligned-access.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "ALSA: seq: Fix OSS sysex delivery in OSS 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 ALSA: seq: Fix OSS sysex delivery in OSS 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: alsa-seq-fix-oss-sysex-delivery-in-oss-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 132d358b183ac6ad8b3fea32ad5e0663456d18d1 Mon Sep 17 00:00:00 2001 From: Takashi Iwai <tiwai(a)suse.de> Date: Tue, 7 Nov 2017 16:05:24 +0100 Subject: ALSA: seq: Fix OSS sysex delivery in OSS emulation From: Takashi Iwai <tiwai(a)suse.de> commit 132d358b183ac6ad8b3fea32ad5e0663456d18d1 upstream. The SYSEX event delivery in OSS sequencer emulation assumed that the event is encoded in the variable-length data with the straight buffering. This was the normal behavior in the past, but during the development, the chained buffers were introduced for carrying more data, while the OSS code was left intact. As a result, when a SYSEX event with the chained buffer data is passed to OSS sequencer port, it may end up with the wrong memory access, as if it were having a too large buffer. This patch addresses the bug, by applying the buffer data expansion by the generic snd_seq_dump_var_event() helper function. Reported-by: syzbot <syzkaller(a)googlegroups.com> Reported-by: Mark Salyzyn <salyzyn(a)android.com> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/core/seq/oss/seq_oss_midi.c | 4 +--- sound/core/seq/oss/seq_oss_readq.c | 29 +++++++++++++++++++++++++++++ sound/core/seq/oss/seq_oss_readq.h | 2 ++ 3 files changed, 32 insertions(+), 3 deletions(-) --- a/sound/core/seq/oss/seq_oss_midi.c +++ b/sound/core/seq/oss/seq_oss_midi.c @@ -612,9 +612,7 @@ send_midi_event(struct seq_oss_devinfo * if (!dp->timer->running) len = snd_seq_oss_timer_start(dp->timer); if (ev->type == SNDRV_SEQ_EVENT_SYSEX) { - if ((ev->flags & SNDRV_SEQ_EVENT_LENGTH_MASK) == SNDRV_SEQ_EVENT_LENGTH_VARIABLE) - snd_seq_oss_readq_puts(dp->readq, mdev->seq_device, - ev->data.ext.ptr, ev->data.ext.len); + snd_seq_oss_readq_sysex(dp->readq, mdev->seq_device, ev); } else { len = snd_midi_event_decode(mdev->coder, msg, sizeof(msg), ev); if (len > 0) --- a/sound/core/seq/oss/seq_oss_readq.c +++ b/sound/core/seq/oss/seq_oss_readq.c @@ -118,6 +118,35 @@ snd_seq_oss_readq_puts(struct seq_oss_re } /* + * put MIDI sysex bytes; the event buffer may be chained, thus it has + * to be expanded via snd_seq_dump_var_event(). + */ +struct readq_sysex_ctx { + struct seq_oss_readq *readq; + int dev; +}; + +static int readq_dump_sysex(void *ptr, void *buf, int count) +{ + struct readq_sysex_ctx *ctx = ptr; + + return snd_seq_oss_readq_puts(ctx->readq, ctx->dev, buf, count); +} + +int snd_seq_oss_readq_sysex(struct seq_oss_readq *q, int dev, + struct snd_seq_event *ev) +{ + struct readq_sysex_ctx ctx = { + .readq = q, + .dev = dev + }; + + if ((ev->flags & SNDRV_SEQ_EVENT_LENGTH_MASK) != SNDRV_SEQ_EVENT_LENGTH_VARIABLE) + return 0; + return snd_seq_dump_var_event(ev, readq_dump_sysex, &ctx); +} + +/* * copy an event to input queue: * return zero if enqueued */ --- a/sound/core/seq/oss/seq_oss_readq.h +++ b/sound/core/seq/oss/seq_oss_readq.h @@ -44,6 +44,8 @@ void snd_seq_oss_readq_delete(struct seq void snd_seq_oss_readq_clear(struct seq_oss_readq *readq); unsigned int snd_seq_oss_readq_poll(struct seq_oss_readq *readq, struct file *file, poll_table *wait); int snd_seq_oss_readq_puts(struct seq_oss_readq *readq, int dev, unsigned char *data, int len); +int snd_seq_oss_readq_sysex(struct seq_oss_readq *q, int dev, + struct snd_seq_event *ev); int snd_seq_oss_readq_put_event(struct seq_oss_readq *readq, union evrec *ev); int snd_seq_oss_readq_put_timestamp(struct seq_oss_readq *readq, unsigned long curt, int seq_mode); int snd_seq_oss_readq_pick(struct seq_oss_readq *q, union evrec *rec); Patches currently in stable-queue which might be from tiwai(a)suse.de are queue-4.9/alsa-seq-avoid-invalid-lockdep-class-warning.patch queue-4.9/alsa-seq-fix-oss-sysex-delivery-in-oss-emulation.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "ARM: 8720/1: ensure dump_instr() checks addr_limit" 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: 8720/1: ensure dump_instr() checks addr_limit 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-8720-1-ensure-dump_instr-checks-addr_limit.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 b9dd05c7002ee0ca8b676428b2268c26399b5e31 Mon Sep 17 00:00:00 2001 From: Mark Rutland <mark.rutland(a)arm.com> Date: Thu, 2 Nov 2017 18:44:28 +0100 Subject: ARM: 8720/1: ensure dump_instr() checks addr_limit From: Mark Rutland <mark.rutland(a)arm.com> commit b9dd05c7002ee0ca8b676428b2268c26399b5e31 upstream. When CONFIG_DEBUG_USER is enabled, it's possible for a user to deliberately trigger dump_instr() with a chosen kernel address. Let's avoid problems resulting from this by using get_user() rather than __get_user(), ensuring that we don't erroneously access kernel memory. So that we can use the same code to dump user instructions and kernel instructions, the common dumping code is factored out to __dump_instr(), with the fs manipulated appropriately in dump_instr() around calls to this. Signed-off-by: Mark Rutland <mark.rutland(a)arm.com> Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/kernel/traps.c | 28 ++++++++++++++++++---------- 1 file changed, 18 insertions(+), 10 deletions(-) --- a/arch/arm/kernel/traps.c +++ b/arch/arm/kernel/traps.c @@ -152,30 +152,26 @@ static void dump_mem(const char *lvl, co set_fs(fs); } -static void dump_instr(const char *lvl, struct pt_regs *regs) +static void __dump_instr(const char *lvl, struct pt_regs *regs) { unsigned long addr = instruction_pointer(regs); const int thumb = thumb_mode(regs); const int width = thumb ? 4 : 8; - mm_segment_t fs; char str[sizeof("00000000 ") * 5 + 2 + 1], *p = str; int i; /* - * We need to switch to kernel mode so that we can use __get_user - * to safely read from kernel space. Note that we now dump the - * code first, just in case the backtrace kills us. + * Note that we now dump the code first, just in case the backtrace + * kills us. */ - fs = get_fs(); - set_fs(KERNEL_DS); for (i = -4; i < 1 + !!thumb; i++) { unsigned int val, bad; if (thumb) - bad = __get_user(val, &((u16 *)addr)[i]); + bad = get_user(val, &((u16 *)addr)[i]); else - bad = __get_user(val, &((u32 *)addr)[i]); + bad = get_user(val, &((u32 *)addr)[i]); if (!bad) p += sprintf(p, i == 0 ? "(%0*x) " : "%0*x ", @@ -186,8 +182,20 @@ static void dump_instr(const char *lvl, } } printk("%sCode: %s\n", lvl, str); +} - set_fs(fs); +static void dump_instr(const char *lvl, struct pt_regs *regs) +{ + mm_segment_t fs; + + if (!user_mode(regs)) { + fs = get_fs(); + set_fs(KERNEL_DS); + __dump_instr(lvl, regs); + set_fs(fs); + } else { + __dump_instr(lvl, regs); + } } #ifdef CONFIG_ARM_UNWIND Patches currently in stable-queue which might be from mark.rutland(a)arm.com are queue-4.9/arm-8720-1-ensure-dump_instr-checks-addr_limit.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "ALSA: seq: Avoid invalid lockdep class warning" 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: Avoid invalid lockdep class warning 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-avoid-invalid-lockdep-class-warning.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 3510c7aa069aa83a2de6dab2b41401a198317bdc Mon Sep 17 00:00:00 2001 From: Takashi Iwai <tiwai(a)suse.de> Date: Mon, 6 Nov 2017 20:16:50 +0100 Subject: ALSA: seq: Avoid invalid lockdep class warning From: Takashi Iwai <tiwai(a)suse.de> commit 3510c7aa069aa83a2de6dab2b41401a198317bdc upstream. The recent fix for adding rwsem nesting annotation was using the given "hop" argument as the lock subclass key. Although the idea itself works, it may trigger a kernel warning like: BUG: looking up invalid subclass: 8 .... since the lockdep has a smaller number of subclasses (8) than we currently allow for the hops there (10). The current definition is merely a sanity check for avoiding the too deep delivery paths, and the 8 hops are already enough. So, as a quick fix, just follow the max hops as same as the max lockdep subclasses. Fixes: 1f20f9ff57ca ("ALSA: seq: Fix nested rwsem annotation for lockdep splat") Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/sound/seq_kernel.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/include/sound/seq_kernel.h +++ b/include/sound/seq_kernel.h @@ -49,7 +49,8 @@ typedef union snd_seq_timestamp snd_seq_ #define SNDRV_SEQ_DEFAULT_CLIENT_EVENTS 200 /* max delivery path length */ -#define SNDRV_SEQ_MAX_HOPS 10 +/* NOTE: this shouldn't be greater than MAX_LOCKDEP_SUBCLASSES */ +#define SNDRV_SEQ_MAX_HOPS 8 /* max size of event size */ #define SNDRV_SEQ_MAX_EVENT_LEN 0x3fffffff Patches currently in stable-queue which might be from tiwai(a)suse.de are queue-4.9/alsa-seq-avoid-invalid-lockdep-class-warning.patch queue-4.9/alsa-seq-fix-oss-sysex-delivery-in-oss-emulation.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "x86/uaccess, sched/preempt: Verify access_ok() context" 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/uaccess, sched/preempt: Verify access_ok() context 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-uaccess-sched-preempt-verify-access_ok-context.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 7c4788950ba5922fde976d80b72baf46f14dee8d Mon Sep 17 00:00:00 2001 From: Peter Zijlstra <peterz(a)infradead.org> Date: Tue, 22 Nov 2016 10:57:15 +0100 Subject: x86/uaccess, sched/preempt: Verify access_ok() context From: Peter Zijlstra <peterz(a)infradead.org> commit 7c4788950ba5922fde976d80b72baf46f14dee8d upstream. I recently encountered wreckage because access_ok() was used where it should not be, add an explicit WARN when access_ok() is used wrongly. Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Cc: Andy Lutomirski <luto(a)amacapital.net> Cc: H. Peter Anvin <hpa(a)zytor.com> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: linux-kernel(a)vger.kernel.org Signed-off-by: Ingo Molnar <mingo(a)kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/include/asm/uaccess.h | 13 +++++++++++-- include/linux/preempt.h | 21 +++++++++++++-------- 2 files changed, 24 insertions(+), 10 deletions(-) --- a/arch/x86/include/asm/uaccess.h +++ b/arch/x86/include/asm/uaccess.h @@ -66,6 +66,12 @@ static inline bool __chk_range_not_ok(un __chk_range_not_ok((unsigned long __force)(addr), size, limit); \ }) +#ifdef CONFIG_DEBUG_ATOMIC_SLEEP +# define WARN_ON_IN_IRQ() WARN_ON_ONCE(!in_task()) +#else +# define WARN_ON_IN_IRQ() +#endif + /** * access_ok: - Checks if a user space pointer is valid * @type: Type of access: %VERIFY_READ or %VERIFY_WRITE. Note that @@ -86,8 +92,11 @@ static inline bool __chk_range_not_ok(un * checks that the pointer is in the user space range - after calling * this function, memory access functions may still return -EFAULT. */ -#define access_ok(type, addr, size) \ - likely(!__range_not_ok(addr, size, user_addr_max())) +#define access_ok(type, addr, size) \ +({ \ + WARN_ON_IN_IRQ(); \ + likely(!__range_not_ok(addr, size, user_addr_max())); \ +}) /* * The exception table consists of pairs of addresses relative to the --- a/include/linux/preempt.h +++ b/include/linux/preempt.h @@ -65,19 +65,24 @@ /* * Are we doing bottom half or hardware interrupt processing? - * Are we in a softirq context? Interrupt context? - * in_softirq - Are we currently processing softirq or have bh disabled? - * in_serving_softirq - Are we currently processing softirq? + * + * in_irq() - We're in (hard) IRQ context + * in_softirq() - We have BH disabled, or are processing softirqs + * in_interrupt() - We're in NMI,IRQ,SoftIRQ context or have BH disabled + * in_serving_softirq() - We're in softirq context + * in_nmi() - We're in NMI context + * in_task() - We're in task context + * + * Note: due to the BH disabled confusion: in_softirq(),in_interrupt() really + * should not be used in new code. */ #define in_irq() (hardirq_count()) #define in_softirq() (softirq_count()) #define in_interrupt() (irq_count()) #define in_serving_softirq() (softirq_count() & SOFTIRQ_OFFSET) - -/* - * Are we in NMI context? - */ -#define in_nmi() (preempt_count() & NMI_MASK) +#define in_nmi() (preempt_count() & NMI_MASK) +#define in_task() (!(preempt_count() & \ + (NMI_MASK | HARDIRQ_MASK | SOFTIRQ_OFFSET))) /* * The preempt_count offset after preempt_disable(); Patches currently in stable-queue which might be from peterz(a)infradead.org are queue-4.4/x86-uaccess-sched-preempt-verify-access_ok-context.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "platform/x86: hp-wmi: Fix error value for hp_wmi_tablet_state" 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 platform/x86: hp-wmi: Fix error value for hp_wmi_tablet_state 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: platform-x86-hp-wmi-fix-error-value-for-hp_wmi_tablet_state.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 c7dfc2facbd69dad89b75e13c608da709668dcd0 Mon Sep 17 00:00:00 2001 From: Carlo Caione <carlo(a)endlessm.com> Date: Sun, 9 Apr 2017 15:56:07 +0200 Subject: platform/x86: hp-wmi: Fix error value for hp_wmi_tablet_state From: Carlo Caione <carlo(a)endlessm.com> commit c7dfc2facbd69dad89b75e13c608da709668dcd0 upstream. hp_wmi_tablet_state() fails to return the correct error code when hp_wmi_perform_query() returns the HP WMI query specific error code that is a positive value. Signed-off-by: Carlo Caione <carlo(a)endlessm.com> Signed-off-by: Darren Hart (VMware) <dvhart(a)infradead.org> Cc: Philip Müller <philm(a)manjaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/platform/x86/hp-wmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/platform/x86/hp-wmi.c +++ b/drivers/platform/x86/hp-wmi.c @@ -291,7 +291,7 @@ static int hp_wmi_tablet_state(void) int ret = hp_wmi_perform_query(HPWMI_HARDWARE_QUERY, 0, &state, sizeof(state), sizeof(state)); if (ret) - return ret; + return -EINVAL; return (state & 0x4) ? 1 : 0; } Patches currently in stable-queue which might be from carlo(a)endlessm.com are queue-4.4/platform-x86-hp-wmi-do-not-shadow-error-values.patch queue-4.4/platform-x86-hp-wmi-fix-detection-for-dock-and-tablet-mode.patch queue-4.4/platform-x86-hp-wmi-fix-error-value-for-hp_wmi_tablet_state.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "platform/x86: hp-wmi: Do not shadow error values" 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 platform/x86: hp-wmi: Do not shadow error values 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: platform-x86-hp-wmi-do-not-shadow-error-values.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 d313876925f3e7a480a02773fd333bcab9202d5e Mon Sep 17 00:00:00 2001 From: Carlo Caione <carlo(a)endlessm.com> Date: Wed, 19 Apr 2017 22:36:39 +0200 Subject: platform/x86: hp-wmi: Do not shadow error values From: Carlo Caione <carlo(a)endlessm.com> commit d313876925f3e7a480a02773fd333bcab9202d5e upstream. All the helper functions (i.e. hp_wmi_dock_state, hp_wmi_tablet_state, ...) using hp_wmi_perform_query to perform an HP WMI query shadow the returned value in case of error. We return -EINVAL only when the HP WMI query returns a positive value (the specific error code) to not mix this up with the actual value returned by the helper function. Suggested-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Signed-off-by: Carlo Caione <carlo(a)endlessm.com> Signed-off-by: Darren Hart (VMware) <dvhart(a)infradead.org> Cc: Philip Müller <philm(a)manjaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/platform/x86/hp-wmi.c | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) --- a/drivers/platform/x86/hp-wmi.c +++ b/drivers/platform/x86/hp-wmi.c @@ -249,7 +249,7 @@ static int hp_wmi_display_state(void) int ret = hp_wmi_perform_query(HPWMI_DISPLAY_QUERY, 0, &state, sizeof(state), sizeof(state)); if (ret) - return -EINVAL; + return ret < 0 ? ret : -EINVAL; return state; } @@ -259,7 +259,7 @@ static int hp_wmi_hddtemp_state(void) int ret = hp_wmi_perform_query(HPWMI_HDDTEMP_QUERY, 0, &state, sizeof(state), sizeof(state)); if (ret) - return -EINVAL; + return ret < 0 ? ret : -EINVAL; return state; } @@ -269,7 +269,7 @@ static int hp_wmi_als_state(void) int ret = hp_wmi_perform_query(HPWMI_ALS_QUERY, 0, &state, sizeof(state), sizeof(state)); if (ret) - return -EINVAL; + return ret < 0 ? ret : -EINVAL; return state; } @@ -280,7 +280,7 @@ static int hp_wmi_dock_state(void) sizeof(state), sizeof(state)); if (ret) - return -EINVAL; + return ret < 0 ? ret : -EINVAL; return state & 0x1; } @@ -291,7 +291,7 @@ static int hp_wmi_tablet_state(void) int ret = hp_wmi_perform_query(HPWMI_HARDWARE_QUERY, 0, &state, sizeof(state), sizeof(state)); if (ret) - return -EINVAL; + return ret < 0 ? ret : -EINVAL; return (state & 0x4) ? 1 : 0; } @@ -324,7 +324,7 @@ static int __init hp_wmi_enable_hotkeys( int ret = hp_wmi_perform_query(HPWMI_BIOS_QUERY, 1, &value, sizeof(value), 0); if (ret) - return -EINVAL; + return ret < 0 ? ret : -EINVAL; return 0; } @@ -337,7 +337,7 @@ static int hp_wmi_set_block(void *data, ret = hp_wmi_perform_query(HPWMI_WIRELESS_QUERY, 1, &query, sizeof(query), 0); if (ret) - return -EINVAL; + return ret < 0 ? ret : -EINVAL; return 0; } @@ -429,7 +429,7 @@ static int hp_wmi_post_code_state(void) int ret = hp_wmi_perform_query(HPWMI_POSTCODEERROR_QUERY, 0, &state, sizeof(state), sizeof(state)); if (ret) - return -EINVAL; + return ret < 0 ? ret : -EINVAL; return state; } @@ -495,7 +495,7 @@ static ssize_t set_als(struct device *de int ret = hp_wmi_perform_query(HPWMI_ALS_QUERY, 1, &tmp, sizeof(tmp), sizeof(tmp)); if (ret) - return -EINVAL; + return ret < 0 ? ret : -EINVAL; return count; } @@ -516,7 +516,7 @@ static ssize_t set_postcode(struct devic ret = hp_wmi_perform_query(HPWMI_POSTCODEERROR_QUERY, 1, &tmp, sizeof(tmp), sizeof(tmp)); if (ret) - return -EINVAL; + return ret < 0 ? ret : -EINVAL; return count; } Patches currently in stable-queue which might be from carlo(a)endlessm.com are queue-4.4/platform-x86-hp-wmi-do-not-shadow-error-values.patch queue-4.4/platform-x86-hp-wmi-fix-detection-for-dock-and-tablet-mode.patch queue-4.4/platform-x86-hp-wmi-fix-error-value-for-hp_wmi_tablet_state.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "workqueue: Fix NULL pointer dereference" 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 workqueue: Fix NULL pointer dereference 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: workqueue-fix-null-pointer-dereference.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 cef572ad9bd7f85035ba8272e5352040e8be0152 Mon Sep 17 00:00:00 2001 From: Li Bin <huawei.libin(a)huawei.com> Date: Sat, 28 Oct 2017 11:07:28 +0800 Subject: workqueue: Fix NULL pointer dereference From: Li Bin <huawei.libin(a)huawei.com> commit cef572ad9bd7f85035ba8272e5352040e8be0152 upstream. When queue_work() is used in irq (not in task context), there is a potential case that trigger NULL pointer dereference. ---------------------------------------------------------------- worker_thread() |-spin_lock_irq() |-process_one_work() |-worker->current_pwq = pwq |-spin_unlock_irq() |-worker->current_func(work) |-spin_lock_irq() |-worker->current_pwq = NULL |-spin_unlock_irq() //interrupt here |-irq_handler |-__queue_work() //assuming that the wq is draining |-is_chained_work(wq) |-current_wq_worker() //Here, 'current' is the interrupted worker! |-current->current_pwq is NULL here! |-schedule() ---------------------------------------------------------------- Avoid it by checking for task context in current_wq_worker(), and if not in task context, we shouldn't use the 'current' to check the condition. Reported-by: Xiaofei Tan <tanxiaofei(a)huawei.com> Signed-off-by: Li Bin <huawei.libin(a)huawei.com> Reviewed-by: Lai Jiangshan <jiangshanlai(a)gmail.com> Signed-off-by: Tejun Heo <tj(a)kernel.org> Fixes: 8d03ecfe4718 ("workqueue: reimplement is_chained_work() using current_wq_worker()") Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/workqueue_internal.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/kernel/workqueue_internal.h +++ b/kernel/workqueue_internal.h @@ -9,6 +9,7 @@ #include <linux/workqueue.h> #include <linux/kthread.h> +#include <linux/preempt.h> struct worker_pool; @@ -59,7 +60,7 @@ struct worker { */ static inline struct worker *current_wq_worker(void) { - if (current->flags & PF_WQ_WORKER) + if (in_task() && (current->flags & PF_WQ_WORKER)) return kthread_data(current); return NULL; } Patches currently in stable-queue which might be from huawei.libin(a)huawei.com are queue-4.4/workqueue-fix-null-pointer-dereference.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "MIPS: SMP: Use a completion event to signal CPU up" 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 MIPS: SMP: Use a completion event to signal CPU up 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: mips-smp-use-a-completion-event-to-signal-cpu-up.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 a00eeede507c975087b7b8df8cf2c9f88ba285de Mon Sep 17 00:00:00 2001 From: Matt Redfearn <matt.redfearn(a)imgtec.com> Date: Fri, 4 Nov 2016 09:28:56 +0000 Subject: MIPS: SMP: Use a completion event to signal CPU up From: Matt Redfearn <matt.redfearn(a)imgtec.com> commit a00eeede507c975087b7b8df8cf2c9f88ba285de upstream. If a secondary CPU failed to start, for any reason, the CPU requesting the secondary to start would get stuck in the loop waiting for the secondary to be present in the cpu_callin_map. Rather than that, use a completion event to signal that the secondary CPU has started and is waiting to synchronise counters. Since the CPU presence will no longer be marked in cpu_callin_map, remove the redundant test from arch_cpu_idle_dead(). Signed-off-by: Matt Redfearn <matt.redfearn(a)imgtec.com> Cc: Maciej W. Rozycki <macro(a)imgtec.com> Cc: Jiri Slaby <jslaby(a)suse.cz> Cc: Paul Gortmaker <paul.gortmaker(a)windriver.com> Cc: Chris Metcalf <cmetcalf(a)mellanox.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Qais Yousef <qsyousef(a)gmail.com> Cc: James Hogan <james.hogan(a)imgtec.com> Cc: Paul Burton <paul.burton(a)imgtec.com> Cc: Marcin Nowakowski <marcin.nowakowski(a)imgtec.com> Cc: Andrew Morton <akpm(a)linux-foundation.org> Cc: linux-mips(a)linux-mips.org Cc: linux-kernel(a)vger.kernel.org Patchwork: https://patchwork.linux-mips.org/patch/14502/ Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/kernel/process.c | 4 +--- arch/mips/kernel/smp.c | 15 +++++++++------ 2 files changed, 10 insertions(+), 9 deletions(-) --- a/arch/mips/kernel/process.c +++ b/arch/mips/kernel/process.c @@ -49,9 +49,7 @@ #ifdef CONFIG_HOTPLUG_CPU void arch_cpu_idle_dead(void) { - /* What the heck is this check doing ? */ - if (!cpumask_test_cpu(smp_processor_id(), &cpu_callin_map)) - play_dead(); + play_dead(); } #endif --- a/arch/mips/kernel/smp.c +++ b/arch/mips/kernel/smp.c @@ -64,6 +64,8 @@ EXPORT_SYMBOL(cpu_sibling_map); cpumask_t cpu_core_map[NR_CPUS] __read_mostly; EXPORT_SYMBOL(cpu_core_map); +static DECLARE_COMPLETION(cpu_running); + /* * A logcal cpu mask containing only one VPE per core to * reduce the number of IPIs on large MT systems. @@ -174,7 +176,7 @@ asmlinkage void start_secondary(void) cpumask_set_cpu(cpu, &cpu_coherent_mask); notify_cpu_starting(cpu); - cpumask_set_cpu(cpu, &cpu_callin_map); + complete(&cpu_running); synchronise_count_slave(cpu); set_cpu_online(cpu, true); @@ -242,7 +244,6 @@ void smp_prepare_boot_cpu(void) { set_cpu_possible(0, true); set_cpu_online(0, true); - cpumask_set_cpu(0, &cpu_callin_map); } int __cpu_up(unsigned int cpu, struct task_struct *tidle) @@ -250,11 +251,13 @@ int __cpu_up(unsigned int cpu, struct ta mp_ops->boot_secondary(cpu, tidle); /* - * Trust is futile. We should really have timeouts ... + * We must check for timeout here, as the CPU will not be marked + * online until the counters are synchronised. */ - while (!cpumask_test_cpu(cpu, &cpu_callin_map)) { - udelay(100); - schedule(); + if (!wait_for_completion_timeout(&cpu_running, + msecs_to_jiffies(1000))) { + pr_crit("CPU%u: failed to start\n", cpu); + return -EIO; } synchronise_count_master(cpu); Patches currently in stable-queue which might be from matt.redfearn(a)imgtec.com are queue-4.4/mips-smp-fix-deadlock-online-race.patch queue-4.4/mips-smp-use-a-completion-event-to-signal-cpu-up.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "MIPS: SMP: Fix deadlock & online race" 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 MIPS: SMP: Fix deadlock & online race 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: mips-smp-fix-deadlock-online-race.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 9e8c399a88f0b87e41a894911475ed2a8f8dff9e Mon Sep 17 00:00:00 2001 From: Matt Redfearn <matt.redfearn(a)imgtec.com> Date: Wed, 27 Sep 2017 10:13:25 +0100 Subject: MIPS: SMP: Fix deadlock & online race From: Matt Redfearn <matt.redfearn(a)imgtec.com> commit 9e8c399a88f0b87e41a894911475ed2a8f8dff9e upstream. Commit 6f542ebeaee0 ("MIPS: Fix race on setting and getting cpu_online_mask") effectively reverted commit 8f46cca1e6c06 ("MIPS: SMP: Fix possibility of deadlock when bringing CPUs online") and thus has reinstated the possibility of deadlock. The commit was based on testing of kernel v4.4, where the CPU hotplug core code issued a BUG() if the starting CPU is not marked online when the boot CPU returns from __cpu_up. The commit fixes this race (in v4.4), but re-introduces the deadlock situation. As noted in the commit message, upstream differs in this area. Commit 8df3e07e7f21f ("cpu/hotplug: Let upcoming cpu bring itself fully up") adds a completion event in the CPU hotplug core code, making this race impossible. However, people were unhappy with relying on the core code to do the right thing. To address the issues both commits were trying to fix, add a second completion event in the MIPS smp hotplug path. It removes the possibility of a race, since the MIPS smp hotplug code now synchronises both the boot and secondary CPUs before they return to the hotplug core code. It also addresses the deadlock by ensuring that the secondary CPU is not marked online before it's counters are synchronised. This fix should also be backported to fix the race condition introduced by the backport of commit 8f46cca1e6c06 ("MIPS: SMP: Fix possibility of deadlock when bringing CPUs online"), through really that race only existed before commit 8df3e07e7f21f ("cpu/hotplug: Let upcoming cpu bring itself fully up"). Signed-off-by: Matt Redfearn <matt.redfearn(a)imgtec.com> Fixes: 6f542ebeaee0 ("MIPS: Fix race on setting and getting cpu_online_mask") CC: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext(a)nokia.com> Patchwork: https://patchwork.linux-mips.org/patch/17376/ Signed-off-by: James Hogan <jhogan(a)kernel.org> [jhogan(a)kernel.org: Backported 4.1..4.9] Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/kernel/smp.c | 22 ++++++++++++++++------ 1 file changed, 16 insertions(+), 6 deletions(-) --- a/arch/mips/kernel/smp.c +++ b/arch/mips/kernel/smp.c @@ -64,6 +64,7 @@ EXPORT_SYMBOL(cpu_sibling_map); cpumask_t cpu_core_map[NR_CPUS] __read_mostly; EXPORT_SYMBOL(cpu_core_map); +static DECLARE_COMPLETION(cpu_starting); static DECLARE_COMPLETION(cpu_running); /* @@ -176,6 +177,12 @@ asmlinkage void start_secondary(void) cpumask_set_cpu(cpu, &cpu_coherent_mask); notify_cpu_starting(cpu); + /* Notify boot CPU that we're starting & ready to sync counters */ + complete(&cpu_starting); + + synchronise_count_slave(cpu); + + /* The CPU is running and counters synchronised, now mark it online */ set_cpu_online(cpu, true); set_cpu_sibling_map(cpu); @@ -183,8 +190,11 @@ asmlinkage void start_secondary(void) calculate_cpu_foreign_map(); + /* + * Notify boot CPU that we're up & online and it can safely return + * from __cpu_up + */ complete(&cpu_running); - synchronise_count_slave(cpu); /* * irq will be enabled in ->smp_finish(), enabling it too early @@ -250,17 +260,17 @@ int __cpu_up(unsigned int cpu, struct ta { mp_ops->boot_secondary(cpu, tidle); - /* - * We must check for timeout here, as the CPU will not be marked - * online until the counters are synchronised. - */ - if (!wait_for_completion_timeout(&cpu_running, + /* Wait for CPU to start and be ready to sync counters */ + if (!wait_for_completion_timeout(&cpu_starting, msecs_to_jiffies(1000))) { pr_crit("CPU%u: failed to start\n", cpu); return -EIO; } synchronise_count_master(cpu); + + /* Wait for CPU to finish startup & mark itself online before return */ + wait_for_completion(&cpu_running); return 0; } Patches currently in stable-queue which might be from matt.redfearn(a)imgtec.com are queue-4.4/mips-smp-fix-deadlock-online-race.patch queue-4.4/mips-smp-use-a-completion-event-to-signal-cpu-up.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "MIPS: Fix race on setting and getting cpu_online_mask" 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 MIPS: Fix race on setting and getting cpu_online_mask 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: mips-fix-race-on-setting-and-getting-cpu_online_mask.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 6f542ebeaee0ee552a902ce3892220fc22c7ec8e Mon Sep 17 00:00:00 2001 From: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext(a)nokia.com> Date: Thu, 3 Aug 2017 08:20:22 +0200 Subject: MIPS: Fix race on setting and getting cpu_online_mask From: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext(a)nokia.com> commit 6f542ebeaee0ee552a902ce3892220fc22c7ec8e upstream. While testing cpu hoptlug (cpu down and up in loops) on kernel 4.4, it was observed that occasionally check for cpu online will fail in kernel/cpu.c, _cpu_up: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tre… 518 /* Arch-specific enabling code. */ 519 ret = __cpu_up(cpu, idle); 520 521 if (ret != 0) 522 goto out_notify; 523 BUG_ON(!cpu_online(cpu)); Reason is race between start_secondary and _cpu_up. cpu_callin_map is set before cpu_online_mask. In __cpu_up, cpu_callin_map is waited for, but cpu online mask is not, resulting in race in which secondary processor started and set cpu_callin_map, but not yet set the online mask,resulting in above BUG being hit. Upstream differs in the area. cpu_online check is in bringup_wait_for_ap, which is after cpu reached AP_ONLINE_IDLE,where secondary passed its start function. Nonetheless, fix makes start_secondary safe and not depending on other locks throughout the code. It protects as well against cpu_online checks put in between sometimes in the future. Fix this by moving completion after all flags are set. Signed-off-by: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext(a)nokia.com> Cc: Alexander Sverdlin <alexander.sverdlin(a)nokia.com> Cc: linux-mips(a)linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/16925/ Signed-off-by: Ralf Baechle <ralf(a)linux-mips.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/kernel/smp.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/arch/mips/kernel/smp.c +++ b/arch/mips/kernel/smp.c @@ -176,9 +176,6 @@ asmlinkage void start_secondary(void) cpumask_set_cpu(cpu, &cpu_coherent_mask); notify_cpu_starting(cpu); - complete(&cpu_running); - synchronise_count_slave(cpu); - set_cpu_online(cpu, true); set_cpu_sibling_map(cpu); @@ -186,6 +183,9 @@ asmlinkage void start_secondary(void) calculate_cpu_foreign_map(); + complete(&cpu_running); + synchronise_count_slave(cpu); + /* * irq will be enabled in ->smp_finish(), enabling it too early * is dangerous. Patches currently in stable-queue which might be from matija.glavinic-pecotic.ext(a)nokia.com are queue-4.4/mips-fix-race-on-setting-and-getting-cpu_online_mask.patch queue-4.4/mips-smp-fix-deadlock-online-race.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "MIPS: microMIPS: Fix incorrect mask in insn_table_MM" 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 MIPS: microMIPS: Fix incorrect mask in insn_table_MM 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: mips-micromips-fix-incorrect-mask-in-insn_table_mm.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 77238e76b9156d28d86c1e31c00ed2960df0e4de Mon Sep 17 00:00:00 2001 From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com> Date: Tue, 31 Oct 2017 00:35:03 -0500 Subject: MIPS: microMIPS: Fix incorrect mask in insn_table_MM From: Gustavo A. R. Silva <garsilva(a)embeddedor.com> commit 77238e76b9156d28d86c1e31c00ed2960df0e4de upstream. It seems that this is a typo error and the proper bit masking is "RT | RS" instead of "RS | RS". This issue was detected with the help of Coccinelle. Fixes: d6b3314b49e1 ("MIPS: uasm: Add lh uam instruction") Reported-by: Julia Lawall <julia.lawall(a)lip6.fr> Signed-off-by: Gustavo A. R. Silva <garsilva(a)embeddedor.com> Reviewed-by: James Hogan <jhogan(a)kernel.org> Patchwork: https://patchwork.linux-mips.org/patch/17551/ Signed-off-by: James Hogan <jhogan(a)kernel.org> [jhogan(a)kernel.org: Backported 3.16..4.12] Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/mm/uasm-micromips.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/mips/mm/uasm-micromips.c +++ b/arch/mips/mm/uasm-micromips.c @@ -75,7 +75,7 @@ static struct insn insn_table_MM[] = { { insn_jr, M(mm_pool32a_op, 0, 0, 0, mm_jalr_op, mm_pool32axf_op), RS }, { insn_lb, M(mm_lb32_op, 0, 0, 0, 0, 0), RT | RS | SIMM }, { insn_ld, 0, 0 }, - { insn_lh, M(mm_lh32_op, 0, 0, 0, 0, 0), RS | RS | SIMM }, + { insn_lh, M(mm_lh32_op, 0, 0, 0, 0, 0), RT | RS | SIMM }, { insn_ll, M(mm_pool32c_op, 0, 0, (mm_ll_func << 1), 0, 0), RS | RT | SIMM }, { insn_lld, 0, 0 }, { insn_lui, M(mm_pool32i_op, mm_lui_op, 0, 0, 0, 0), RS | SIMM }, Patches currently in stable-queue which might be from garsilva(a)embeddedor.com are queue-4.4/mips-micromips-fix-incorrect-mask-in-insn_table_mm.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "MIPS: Fix CM region target definitions" 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 MIPS: Fix CM region target definitions 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: mips-fix-cm-region-target-definitions.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 6a6cba1d945a7511cdfaf338526871195e420762 Mon Sep 17 00:00:00 2001 From: Paul Burton <paul.burton(a)mips.com> Date: Tue, 31 Oct 2017 15:09:22 -0700 Subject: MIPS: Fix CM region target definitions From: Paul Burton <paul.burton(a)mips.com> commit 6a6cba1d945a7511cdfaf338526871195e420762 upstream. The default CM target field in the GCR_BASE register is encoded with 0 meaning memory & 1 being reserved. However the definitions we use for those bits effectively get these two values backwards - likely because they were copied from the definitions for the CM regions where the target is encoded differently. This results in use setting up GCR_BASE with the reserved target value by default, rather than targeting memory as intended. Although we currently seem to get away with this it's not a great idea to rely upon. Fix this by changing our macros to match the documentated target values. The incorrect encoding became used as of commit 9f98f3dd0c51 ("MIPS: Add generic CM probe & access code") in the Linux v3.15 cycle, and was likely carried forwards from older but unused code introduced by commit 39b8d5254246 ("[MIPS] Add support for MIPS CMP platform.") in the v2.6.26 cycle. Fixes: 9f98f3dd0c51 ("MIPS: Add generic CM probe & access code") Signed-off-by: Paul Burton <paul.burton(a)mips.com> Reported-by: Matt Redfearn <matt.redfearn(a)mips.com> Reviewed-by: James Hogan <jhogan(a)kernel.org> Cc: Matt Redfearn <matt.redfearn(a)mips.com> Cc: Ralf Baechle <ralf(a)linux-mips.org> Cc: linux-mips(a)linux-mips.org Cc: <stable(a)vger.kernel.org> # v3.15+ Patchwork: https://patchwork.linux-mips.org/patch/17562/ Signed-off-by: James Hogan <jhogan(a)kernel.org> [jhogan(a)kernel.org: Backported 3.15..4.13] Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/include/asm/mips-cm.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/arch/mips/include/asm/mips-cm.h +++ b/arch/mips/include/asm/mips-cm.h @@ -238,8 +238,8 @@ BUILD_CM_Cx_R_(tcid_8_priority, 0x80) #define CM_GCR_BASE_GCRBASE_MSK (_ULCAST_(0x1ffff) << 15) #define CM_GCR_BASE_CMDEFTGT_SHF 0 #define CM_GCR_BASE_CMDEFTGT_MSK (_ULCAST_(0x3) << 0) -#define CM_GCR_BASE_CMDEFTGT_DISABLED 0 -#define CM_GCR_BASE_CMDEFTGT_MEM 1 +#define CM_GCR_BASE_CMDEFTGT_MEM 0 +#define CM_GCR_BASE_CMDEFTGT_RESERVED 1 #define CM_GCR_BASE_CMDEFTGT_IOCU0 2 #define CM_GCR_BASE_CMDEFTGT_IOCU1 3 Patches currently in stable-queue which might be from paul.burton(a)mips.com are queue-4.4/mips-fix-cm-region-target-definitions.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "KEYS: fix NULL pointer dereference during ASN.1 parsing [ver #2]" 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 KEYS: fix NULL pointer dereference during ASN.1 parsing [ver #2] 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: keys-fix-null-pointer-dereference-during-asn.1-parsing.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 624f5ab8720b3371367327a822c267699c1823b8 Mon Sep 17 00:00:00 2001 From: Eric Biggers <ebiggers(a)google.com> Date: Tue, 7 Nov 2017 22:29:02 +0000 Subject: KEYS: fix NULL pointer dereference during ASN.1 parsing [ver #2] From: Eric Biggers <ebiggers(a)google.com> commit 624f5ab8720b3371367327a822c267699c1823b8 upstream. syzkaller reported a NULL pointer dereference in asn1_ber_decoder(). It can be reproduced by the following command, assuming CONFIG_PKCS7_TEST_KEY=y: keyctl add pkcs7_test desc '' @s The bug is that if the data buffer is empty, an integer underflow occurs in the following check: if (unlikely(dp >= datalen - 1)) goto data_overrun_error; This results in the NULL data pointer being dereferenced. Fix it by checking for 'datalen - dp < 2' instead. Also fix the similar check for 'dp >= datalen - n' later in the same function. That one possibly could result in a buffer overread. The NULL pointer dereference was reproducible using the "pkcs7_test" key type but not the "asymmetric" key type because the "asymmetric" key type checks for a 0-length payload before calling into the ASN.1 decoder but the "pkcs7_test" key type does not. The bug report was: BUG: unable to handle kernel NULL pointer dereference at (null) IP: asn1_ber_decoder+0x17f/0xe60 lib/asn1_decoder.c:233 PGD 7b708067 P4D 7b708067 PUD 7b6ee067 PMD 0 Oops: 0000 [#1] SMP Modules linked in: CPU: 0 PID: 522 Comm: syz-executor1 Not tainted 4.14.0-rc8 #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.3-20171021_125229-anatol 04/01/2014 task: ffff9b6b3798c040 task.stack: ffff9b6b37970000 RIP: 0010:asn1_ber_decoder+0x17f/0xe60 lib/asn1_decoder.c:233 RSP: 0018:ffff9b6b37973c78 EFLAGS: 00010216 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000021c RDX: ffffffff814a04ed RSI: ffffb1524066e000 RDI: ffffffff910759e0 RBP: ffff9b6b37973d60 R08: 0000000000000001 R09: ffff9b6b3caa4180 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f10ed1f2700(0000) GS:ffff9b6b3ea00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000007b6f3000 CR4: 00000000000006f0 Call Trace: pkcs7_parse_message+0xee/0x240 crypto/asymmetric_keys/pkcs7_parser.c:139 verify_pkcs7_signature+0x33/0x180 certs/system_keyring.c:216 pkcs7_preparse+0x41/0x70 crypto/asymmetric_keys/pkcs7_key_type.c:63 key_create_or_update+0x180/0x530 security/keys/key.c:855 SYSC_add_key security/keys/keyctl.c:122 [inline] SyS_add_key+0xbf/0x250 security/keys/keyctl.c:62 entry_SYSCALL_64_fastpath+0x1f/0xbe RIP: 0033:0x4585c9 RSP: 002b:00007f10ed1f1bd8 EFLAGS: 00000216 ORIG_RAX: 00000000000000f8 RAX: ffffffffffffffda RBX: 00007f10ed1f2700 RCX: 00000000004585c9 RDX: 0000000020000000 RSI: 0000000020008ffb RDI: 0000000020008000 RBP: 0000000000000000 R08: ffffffffffffffff R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000216 R12: 00007fff1b2260ae R13: 00007fff1b2260af R14: 00007f10ed1f2700 R15: 0000000000000000 Code: dd ca ff 48 8b 45 88 48 83 e8 01 4c 39 f0 0f 86 a8 07 00 00 e8 53 dd ca ff 49 8d 46 01 48 89 85 58 ff ff ff 48 8b 85 60 ff ff ff <42> 0f b6 0c 30 89 c8 88 8d 75 ff ff ff 83 e0 1f 89 8d 28 ff ff RIP: asn1_ber_decoder+0x17f/0xe60 lib/asn1_decoder.c:233 RSP: ffff9b6b37973c78 CR2: 0000000000000000 Fixes: 42d5ec27f873 ("X.509: Add an ASN.1 decoder") Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: James Morris <james.l.morris(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- lib/asn1_decoder.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/lib/asn1_decoder.c +++ b/lib/asn1_decoder.c @@ -227,7 +227,7 @@ next_op: hdr = 2; /* Extract a tag from the data */ - if (unlikely(dp >= datalen - 1)) + if (unlikely(datalen - dp < 2)) goto data_overrun_error; tag = data[dp++]; if (unlikely((tag & 0x1f) == ASN1_LONG_TAG)) @@ -273,7 +273,7 @@ next_op: int n = len - 0x80; if (unlikely(n > 2)) goto length_too_long; - if (unlikely(dp >= datalen - n)) + if (unlikely(n > datalen - dp)) goto data_overrun_error; hdr += n; for (len = 0; n > 0; n--) { Patches currently in stable-queue which might be from ebiggers(a)google.com are queue-4.4/keys-trusted-sanitize-all-key-material.patch queue-4.4/keys-trusted-fix-writing-past-end-of-buffer-in-trusted_read.patch queue-4.4/keys-fix-null-pointer-dereference-during-asn.1-parsing.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "ARM: 8720/1: ensure dump_instr() checks addr_limit" 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 ARM: 8720/1: ensure dump_instr() checks addr_limit 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: arm-8720-1-ensure-dump_instr-checks-addr_limit.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 b9dd05c7002ee0ca8b676428b2268c26399b5e31 Mon Sep 17 00:00:00 2001 From: Mark Rutland <mark.rutland(a)arm.com> Date: Thu, 2 Nov 2017 18:44:28 +0100 Subject: ARM: 8720/1: ensure dump_instr() checks addr_limit From: Mark Rutland <mark.rutland(a)arm.com> commit b9dd05c7002ee0ca8b676428b2268c26399b5e31 upstream. When CONFIG_DEBUG_USER is enabled, it's possible for a user to deliberately trigger dump_instr() with a chosen kernel address. Let's avoid problems resulting from this by using get_user() rather than __get_user(), ensuring that we don't erroneously access kernel memory. So that we can use the same code to dump user instructions and kernel instructions, the common dumping code is factored out to __dump_instr(), with the fs manipulated appropriately in dump_instr() around calls to this. Signed-off-by: Mark Rutland <mark.rutland(a)arm.com> Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/kernel/traps.c | 28 ++++++++++++++++++---------- 1 file changed, 18 insertions(+), 10 deletions(-) --- a/arch/arm/kernel/traps.c +++ b/arch/arm/kernel/traps.c @@ -132,30 +132,26 @@ static void dump_mem(const char *lvl, co set_fs(fs); } -static void dump_instr(const char *lvl, struct pt_regs *regs) +static void __dump_instr(const char *lvl, struct pt_regs *regs) { unsigned long addr = instruction_pointer(regs); const int thumb = thumb_mode(regs); const int width = thumb ? 4 : 8; - mm_segment_t fs; char str[sizeof("00000000 ") * 5 + 2 + 1], *p = str; int i; /* - * We need to switch to kernel mode so that we can use __get_user - * to safely read from kernel space. Note that we now dump the - * code first, just in case the backtrace kills us. + * Note that we now dump the code first, just in case the backtrace + * kills us. */ - fs = get_fs(); - set_fs(KERNEL_DS); for (i = -4; i < 1 + !!thumb; i++) { unsigned int val, bad; if (thumb) - bad = __get_user(val, &((u16 *)addr)[i]); + bad = get_user(val, &((u16 *)addr)[i]); else - bad = __get_user(val, &((u32 *)addr)[i]); + bad = get_user(val, &((u32 *)addr)[i]); if (!bad) p += sprintf(p, i == 0 ? "(%0*x) " : "%0*x ", @@ -166,8 +162,20 @@ static void dump_instr(const char *lvl, } } printk("%sCode: %s\n", lvl, str); +} - set_fs(fs); +static void dump_instr(const char *lvl, struct pt_regs *regs) +{ + mm_segment_t fs; + + if (!user_mode(regs)) { + fs = get_fs(); + set_fs(KERNEL_DS); + __dump_instr(lvl, regs); + set_fs(fs); + } else { + __dump_instr(lvl, regs); + } } #ifdef CONFIG_ARM_UNWIND Patches currently in stable-queue which might be from mark.rutland(a)arm.com are queue-4.4/arm-8720-1-ensure-dump_instr-checks-addr_limit.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "crypto: x86/sha1-mb - fix panic due to unaligned access" 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 crypto: x86/sha1-mb - fix panic due to unaligned access 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: crypto-x86-sha1-mb-fix-panic-due-to-unaligned-access.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 d041b557792c85677f17e08eee535eafbd6b9aa2 Mon Sep 17 00:00:00 2001 From: Andrey Ryabinin <aryabinin(a)virtuozzo.com> Date: Mon, 16 Oct 2017 18:51:31 +0300 Subject: crypto: x86/sha1-mb - fix panic due to unaligned access From: Andrey Ryabinin <aryabinin(a)virtuozzo.com> commit d041b557792c85677f17e08eee535eafbd6b9aa2 upstream. struct sha1_ctx_mgr allocated in sha1_mb_mod_init() via kzalloc() and later passed in sha1_mb_flusher_mgr_flush_avx2() function where instructions vmovdqa used to access the struct. vmovdqa requires 16-bytes aligned argument, but nothing guarantees that struct sha1_ctx_mgr will have that alignment. Unaligned vmovdqa will generate GP fault. Fix this by replacing vmovdqa with vmovdqu which doesn't have alignment requirements. Fixes: 2249cbb53ead ("crypto: sha-mb - SHA1 multibuffer submit and flush routines for AVX2") Signed-off-by: Andrey Ryabinin <aryabinin(a)virtuozzo.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/crypto/sha-mb/sha1_mb_mgr_flush_avx2.S | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) --- a/arch/x86/crypto/sha-mb/sha1_mb_mgr_flush_avx2.S +++ b/arch/x86/crypto/sha-mb/sha1_mb_mgr_flush_avx2.S @@ -174,8 +174,8 @@ LABEL skip_ %I .endr # Find min length - vmovdqa _lens+0*16(state), %xmm0 - vmovdqa _lens+1*16(state), %xmm1 + vmovdqu _lens+0*16(state), %xmm0 + vmovdqu _lens+1*16(state), %xmm1 vpminud %xmm1, %xmm0, %xmm2 # xmm2 has {D,C,B,A} vpalignr $8, %xmm2, %xmm3, %xmm3 # xmm3 has {x,x,D,C} @@ -195,8 +195,8 @@ LABEL skip_ %I vpsubd %xmm2, %xmm0, %xmm0 vpsubd %xmm2, %xmm1, %xmm1 - vmovdqa %xmm0, _lens+0*16(state) - vmovdqa %xmm1, _lens+1*16(state) + vmovdqu %xmm0, _lens+0*16(state) + vmovdqu %xmm1, _lens+1*16(state) # "state" and "args" are the same address, arg1 # len is arg2 @@ -260,8 +260,8 @@ ENTRY(sha1_mb_mgr_get_comp_job_avx2) jc .return_null # Find min length - vmovdqa _lens(state), %xmm0 - vmovdqa _lens+1*16(state), %xmm1 + vmovdqu _lens(state), %xmm0 + vmovdqu _lens+1*16(state), %xmm1 vpminud %xmm1, %xmm0, %xmm2 # xmm2 has {D,C,B,A} vpalignr $8, %xmm2, %xmm3, %xmm3 # xmm3 has {x,x,D,C} Patches currently in stable-queue which might be from aryabinin(a)virtuozzo.com are queue-4.4/crypto-x86-sha1-mb-fix-panic-due-to-unaligned-access.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "ALSA: seq: Avoid invalid lockdep class warning" 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: Avoid invalid lockdep class warning 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-avoid-invalid-lockdep-class-warning.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 3510c7aa069aa83a2de6dab2b41401a198317bdc Mon Sep 17 00:00:00 2001 From: Takashi Iwai <tiwai(a)suse.de> Date: Mon, 6 Nov 2017 20:16:50 +0100 Subject: ALSA: seq: Avoid invalid lockdep class warning From: Takashi Iwai <tiwai(a)suse.de> commit 3510c7aa069aa83a2de6dab2b41401a198317bdc upstream. The recent fix for adding rwsem nesting annotation was using the given "hop" argument as the lock subclass key. Although the idea itself works, it may trigger a kernel warning like: BUG: looking up invalid subclass: 8 .... since the lockdep has a smaller number of subclasses (8) than we currently allow for the hops there (10). The current definition is merely a sanity check for avoiding the too deep delivery paths, and the 8 hops are already enough. So, as a quick fix, just follow the max hops as same as the max lockdep subclasses. Fixes: 1f20f9ff57ca ("ALSA: seq: Fix nested rwsem annotation for lockdep splat") Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/sound/seq_kernel.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/include/sound/seq_kernel.h +++ b/include/sound/seq_kernel.h @@ -49,7 +49,8 @@ typedef union snd_seq_timestamp snd_seq_ #define SNDRV_SEQ_DEFAULT_CLIENT_EVENTS 200 /* max delivery path length */ -#define SNDRV_SEQ_MAX_HOPS 10 +/* NOTE: this shouldn't be greater than MAX_LOCKDEP_SUBCLASSES */ +#define SNDRV_SEQ_MAX_HOPS 8 /* max size of event size */ #define SNDRV_SEQ_MAX_EVENT_LEN 0x3fffffff Patches currently in stable-queue which might be from tiwai(a)suse.de are queue-4.4/alsa-seq-avoid-invalid-lockdep-class-warning.patch queue-4.4/alsa-seq-fix-oss-sysex-delivery-in-oss-emulation.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "ALSA: seq: Fix OSS sysex delivery in OSS 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 ALSA: seq: Fix OSS sysex delivery in OSS 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: alsa-seq-fix-oss-sysex-delivery-in-oss-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 132d358b183ac6ad8b3fea32ad5e0663456d18d1 Mon Sep 17 00:00:00 2001 From: Takashi Iwai <tiwai(a)suse.de> Date: Tue, 7 Nov 2017 16:05:24 +0100 Subject: ALSA: seq: Fix OSS sysex delivery in OSS emulation From: Takashi Iwai <tiwai(a)suse.de> commit 132d358b183ac6ad8b3fea32ad5e0663456d18d1 upstream. The SYSEX event delivery in OSS sequencer emulation assumed that the event is encoded in the variable-length data with the straight buffering. This was the normal behavior in the past, but during the development, the chained buffers were introduced for carrying more data, while the OSS code was left intact. As a result, when a SYSEX event with the chained buffer data is passed to OSS sequencer port, it may end up with the wrong memory access, as if it were having a too large buffer. This patch addresses the bug, by applying the buffer data expansion by the generic snd_seq_dump_var_event() helper function. Reported-by: syzbot <syzkaller(a)googlegroups.com> Reported-by: Mark Salyzyn <salyzyn(a)android.com> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/core/seq/oss/seq_oss_midi.c | 4 +--- sound/core/seq/oss/seq_oss_readq.c | 29 +++++++++++++++++++++++++++++ sound/core/seq/oss/seq_oss_readq.h | 2 ++ 3 files changed, 32 insertions(+), 3 deletions(-) --- a/sound/core/seq/oss/seq_oss_midi.c +++ b/sound/core/seq/oss/seq_oss_midi.c @@ -612,9 +612,7 @@ send_midi_event(struct seq_oss_devinfo * if (!dp->timer->running) len = snd_seq_oss_timer_start(dp->timer); if (ev->type == SNDRV_SEQ_EVENT_SYSEX) { - if ((ev->flags & SNDRV_SEQ_EVENT_LENGTH_MASK) == SNDRV_SEQ_EVENT_LENGTH_VARIABLE) - snd_seq_oss_readq_puts(dp->readq, mdev->seq_device, - ev->data.ext.ptr, ev->data.ext.len); + snd_seq_oss_readq_sysex(dp->readq, mdev->seq_device, ev); } else { len = snd_midi_event_decode(mdev->coder, msg, sizeof(msg), ev); if (len > 0) --- a/sound/core/seq/oss/seq_oss_readq.c +++ b/sound/core/seq/oss/seq_oss_readq.c @@ -118,6 +118,35 @@ snd_seq_oss_readq_puts(struct seq_oss_re } /* + * put MIDI sysex bytes; the event buffer may be chained, thus it has + * to be expanded via snd_seq_dump_var_event(). + */ +struct readq_sysex_ctx { + struct seq_oss_readq *readq; + int dev; +}; + +static int readq_dump_sysex(void *ptr, void *buf, int count) +{ + struct readq_sysex_ctx *ctx = ptr; + + return snd_seq_oss_readq_puts(ctx->readq, ctx->dev, buf, count); +} + +int snd_seq_oss_readq_sysex(struct seq_oss_readq *q, int dev, + struct snd_seq_event *ev) +{ + struct readq_sysex_ctx ctx = { + .readq = q, + .dev = dev + }; + + if ((ev->flags & SNDRV_SEQ_EVENT_LENGTH_MASK) != SNDRV_SEQ_EVENT_LENGTH_VARIABLE) + return 0; + return snd_seq_dump_var_event(ev, readq_dump_sysex, &ctx); +} + +/* * copy an event to input queue: * return zero if enqueued */ --- a/sound/core/seq/oss/seq_oss_readq.h +++ b/sound/core/seq/oss/seq_oss_readq.h @@ -44,6 +44,8 @@ void snd_seq_oss_readq_delete(struct seq void snd_seq_oss_readq_clear(struct seq_oss_readq *readq); unsigned int snd_seq_oss_readq_poll(struct seq_oss_readq *readq, struct file *file, poll_table *wait); int snd_seq_oss_readq_puts(struct seq_oss_readq *readq, int dev, unsigned char *data, int len); +int snd_seq_oss_readq_sysex(struct seq_oss_readq *q, int dev, + struct snd_seq_event *ev); int snd_seq_oss_readq_put_event(struct seq_oss_readq *readq, union evrec *ev); int snd_seq_oss_readq_put_timestamp(struct seq_oss_readq *readq, unsigned long curt, int seq_mode); int snd_seq_oss_readq_pick(struct seq_oss_readq *q, union evrec *rec); Patches currently in stable-queue which might be from tiwai(a)suse.de are queue-4.4/alsa-seq-avoid-invalid-lockdep-class-warning.patch queue-4.4/alsa-seq-fix-oss-sysex-delivery-in-oss-emulation.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "workqueue: Fix NULL pointer dereference" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled workqueue: Fix NULL pointer dereference to the 4.13-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: workqueue-fix-null-pointer-dereference.patch and it can be found in the queue-4.13 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 cef572ad9bd7f85035ba8272e5352040e8be0152 Mon Sep 17 00:00:00 2001 From: Li Bin <huawei.libin(a)huawei.com> Date: Sat, 28 Oct 2017 11:07:28 +0800 Subject: workqueue: Fix NULL pointer dereference From: Li Bin <huawei.libin(a)huawei.com> commit cef572ad9bd7f85035ba8272e5352040e8be0152 upstream. When queue_work() is used in irq (not in task context), there is a potential case that trigger NULL pointer dereference. ---------------------------------------------------------------- worker_thread() |-spin_lock_irq() |-process_one_work() |-worker->current_pwq = pwq |-spin_unlock_irq() |-worker->current_func(work) |-spin_lock_irq() |-worker->current_pwq = NULL |-spin_unlock_irq() //interrupt here |-irq_handler |-__queue_work() //assuming that the wq is draining |-is_chained_work(wq) |-current_wq_worker() //Here, 'current' is the interrupted worker! |-current->current_pwq is NULL here! |-schedule() ---------------------------------------------------------------- Avoid it by checking for task context in current_wq_worker(), and if not in task context, we shouldn't use the 'current' to check the condition. Reported-by: Xiaofei Tan <tanxiaofei(a)huawei.com> Signed-off-by: Li Bin <huawei.libin(a)huawei.com> Reviewed-by: Lai Jiangshan <jiangshanlai(a)gmail.com> Signed-off-by: Tejun Heo <tj(a)kernel.org> Fixes: 8d03ecfe4718 ("workqueue: reimplement is_chained_work() using current_wq_worker()") Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/workqueue_internal.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/kernel/workqueue_internal.h +++ b/kernel/workqueue_internal.h @@ -9,6 +9,7 @@ #include <linux/workqueue.h> #include <linux/kthread.h> +#include <linux/preempt.h> struct worker_pool; @@ -59,7 +60,7 @@ struct worker { */ static inline struct worker *current_wq_worker(void) { - if (current->flags & PF_WQ_WORKER) + if (in_task() && (current->flags & PF_WQ_WORKER)) return kthread_data(current); return NULL; } Patches currently in stable-queue which might be from huawei.libin(a)huawei.com are queue-4.13/workqueue-fix-null-pointer-dereference.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "MIPS: Fix CM region target definitions" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled MIPS: Fix CM region target definitions to the 4.13-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: mips-fix-cm-region-target-definitions.patch and it can be found in the queue-4.13 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 6a6cba1d945a7511cdfaf338526871195e420762 Mon Sep 17 00:00:00 2001 From: Paul Burton <paul.burton(a)mips.com> Date: Tue, 31 Oct 2017 15:09:22 -0700 Subject: MIPS: Fix CM region target definitions From: Paul Burton <paul.burton(a)mips.com> commit 6a6cba1d945a7511cdfaf338526871195e420762 upstream. The default CM target field in the GCR_BASE register is encoded with 0 meaning memory & 1 being reserved. However the definitions we use for those bits effectively get these two values backwards - likely because they were copied from the definitions for the CM regions where the target is encoded differently. This results in use setting up GCR_BASE with the reserved target value by default, rather than targeting memory as intended. Although we currently seem to get away with this it's not a great idea to rely upon. Fix this by changing our macros to match the documentated target values. The incorrect encoding became used as of commit 9f98f3dd0c51 ("MIPS: Add generic CM probe & access code") in the Linux v3.15 cycle, and was likely carried forwards from older but unused code introduced by commit 39b8d5254246 ("[MIPS] Add support for MIPS CMP platform.") in the v2.6.26 cycle. Fixes: 9f98f3dd0c51 ("MIPS: Add generic CM probe & access code") Signed-off-by: Paul Burton <paul.burton(a)mips.com> Reported-by: Matt Redfearn <matt.redfearn(a)mips.com> Reviewed-by: James Hogan <jhogan(a)kernel.org> Cc: Matt Redfearn <matt.redfearn(a)mips.com> Cc: Ralf Baechle <ralf(a)linux-mips.org> Cc: linux-mips(a)linux-mips.org Cc: <stable(a)vger.kernel.org> # v3.15+ Patchwork: https://patchwork.linux-mips.org/patch/17562/ Signed-off-by: James Hogan <jhogan(a)kernel.org> [jhogan(a)kernel.org: Backported 3.15..4.13] Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/include/asm/mips-cm.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/arch/mips/include/asm/mips-cm.h +++ b/arch/mips/include/asm/mips-cm.h @@ -240,8 +240,8 @@ BUILD_CM_Cx_R_(tcid_8_priority, 0x80) #define CM_GCR_BASE_GCRBASE_MSK (_ULCAST_(0x1ffff) << 15) #define CM_GCR_BASE_CMDEFTGT_SHF 0 #define CM_GCR_BASE_CMDEFTGT_MSK (_ULCAST_(0x3) << 0) -#define CM_GCR_BASE_CMDEFTGT_DISABLED 0 -#define CM_GCR_BASE_CMDEFTGT_MEM 1 +#define CM_GCR_BASE_CMDEFTGT_MEM 0 +#define CM_GCR_BASE_CMDEFTGT_RESERVED 1 #define CM_GCR_BASE_CMDEFTGT_IOCU0 2 #define CM_GCR_BASE_CMDEFTGT_IOCU1 3 Patches currently in stable-queue which might be from paul.burton(a)mips.com are queue-4.13/mips-fix-cm-region-target-definitions.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "KEYS: fix NULL pointer dereference during ASN.1 parsing [ver #2]" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KEYS: fix NULL pointer dereference during ASN.1 parsing [ver #2] to the 4.13-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: keys-fix-null-pointer-dereference-during-asn.1-parsing.patch and it can be found in the queue-4.13 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 624f5ab8720b3371367327a822c267699c1823b8 Mon Sep 17 00:00:00 2001 From: Eric Biggers <ebiggers(a)google.com> Date: Tue, 7 Nov 2017 22:29:02 +0000 Subject: KEYS: fix NULL pointer dereference during ASN.1 parsing [ver #2] From: Eric Biggers <ebiggers(a)google.com> commit 624f5ab8720b3371367327a822c267699c1823b8 upstream. syzkaller reported a NULL pointer dereference in asn1_ber_decoder(). It can be reproduced by the following command, assuming CONFIG_PKCS7_TEST_KEY=y: keyctl add pkcs7_test desc '' @s The bug is that if the data buffer is empty, an integer underflow occurs in the following check: if (unlikely(dp >= datalen - 1)) goto data_overrun_error; This results in the NULL data pointer being dereferenced. Fix it by checking for 'datalen - dp < 2' instead. Also fix the similar check for 'dp >= datalen - n' later in the same function. That one possibly could result in a buffer overread. The NULL pointer dereference was reproducible using the "pkcs7_test" key type but not the "asymmetric" key type because the "asymmetric" key type checks for a 0-length payload before calling into the ASN.1 decoder but the "pkcs7_test" key type does not. The bug report was: BUG: unable to handle kernel NULL pointer dereference at (null) IP: asn1_ber_decoder+0x17f/0xe60 lib/asn1_decoder.c:233 PGD 7b708067 P4D 7b708067 PUD 7b6ee067 PMD 0 Oops: 0000 [#1] SMP Modules linked in: CPU: 0 PID: 522 Comm: syz-executor1 Not tainted 4.14.0-rc8 #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.3-20171021_125229-anatol 04/01/2014 task: ffff9b6b3798c040 task.stack: ffff9b6b37970000 RIP: 0010:asn1_ber_decoder+0x17f/0xe60 lib/asn1_decoder.c:233 RSP: 0018:ffff9b6b37973c78 EFLAGS: 00010216 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000021c RDX: ffffffff814a04ed RSI: ffffb1524066e000 RDI: ffffffff910759e0 RBP: ffff9b6b37973d60 R08: 0000000000000001 R09: ffff9b6b3caa4180 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f10ed1f2700(0000) GS:ffff9b6b3ea00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000007b6f3000 CR4: 00000000000006f0 Call Trace: pkcs7_parse_message+0xee/0x240 crypto/asymmetric_keys/pkcs7_parser.c:139 verify_pkcs7_signature+0x33/0x180 certs/system_keyring.c:216 pkcs7_preparse+0x41/0x70 crypto/asymmetric_keys/pkcs7_key_type.c:63 key_create_or_update+0x180/0x530 security/keys/key.c:855 SYSC_add_key security/keys/keyctl.c:122 [inline] SyS_add_key+0xbf/0x250 security/keys/keyctl.c:62 entry_SYSCALL_64_fastpath+0x1f/0xbe RIP: 0033:0x4585c9 RSP: 002b:00007f10ed1f1bd8 EFLAGS: 00000216 ORIG_RAX: 00000000000000f8 RAX: ffffffffffffffda RBX: 00007f10ed1f2700 RCX: 00000000004585c9 RDX: 0000000020000000 RSI: 0000000020008ffb RDI: 0000000020008000 RBP: 0000000000000000 R08: ffffffffffffffff R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000216 R12: 00007fff1b2260ae R13: 00007fff1b2260af R14: 00007f10ed1f2700 R15: 0000000000000000 Code: dd ca ff 48 8b 45 88 48 83 e8 01 4c 39 f0 0f 86 a8 07 00 00 e8 53 dd ca ff 49 8d 46 01 48 89 85 58 ff ff ff 48 8b 85 60 ff ff ff <42> 0f b6 0c 30 89 c8 88 8d 75 ff ff ff 83 e0 1f 89 8d 28 ff ff RIP: asn1_ber_decoder+0x17f/0xe60 lib/asn1_decoder.c:233 RSP: ffff9b6b37973c78 CR2: 0000000000000000 Fixes: 42d5ec27f873 ("X.509: Add an ASN.1 decoder") Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: James Morris <james.l.morris(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- lib/asn1_decoder.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/lib/asn1_decoder.c +++ b/lib/asn1_decoder.c @@ -228,7 +228,7 @@ next_op: hdr = 2; /* Extract a tag from the data */ - if (unlikely(dp >= datalen - 1)) + if (unlikely(datalen - dp < 2)) goto data_overrun_error; tag = data[dp++]; if (unlikely((tag & 0x1f) == ASN1_LONG_TAG)) @@ -274,7 +274,7 @@ next_op: int n = len - 0x80; if (unlikely(n > 2)) goto length_too_long; - if (unlikely(dp >= datalen - n)) + if (unlikely(n > datalen - dp)) goto data_overrun_error; hdr += n; for (len = 0; n > 0; n--) { Patches currently in stable-queue which might be from ebiggers(a)google.com are queue-4.13/keys-fix-null-pointer-dereference-during-asn.1-parsing.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "crypto: x86/sha256-mb - fix panic due to unaligned access" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled crypto: x86/sha256-mb - fix panic due to unaligned access to the 4.13-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: crypto-x86-sha256-mb-fix-panic-due-to-unaligned-access.patch and it can be found in the queue-4.13 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 5dfeaac15f2b1abb5a53c9146041c7235eb9aa04 Mon Sep 17 00:00:00 2001 From: Andrey Ryabinin <aryabinin(a)virtuozzo.com> Date: Mon, 16 Oct 2017 18:51:30 +0300 Subject: crypto: x86/sha256-mb - fix panic due to unaligned access From: Andrey Ryabinin <aryabinin(a)virtuozzo.com> commit 5dfeaac15f2b1abb5a53c9146041c7235eb9aa04 upstream. struct sha256_ctx_mgr allocated in sha256_mb_mod_init() via kzalloc() and later passed in sha256_mb_flusher_mgr_flush_avx2() function where instructions vmovdqa used to access the struct. vmovdqa requires 16-bytes aligned argument, but nothing guarantees that struct sha256_ctx_mgr will have that alignment. Unaligned vmovdqa will generate GP fault. Fix this by replacing vmovdqa with vmovdqu which doesn't have alignment requirements. Fixes: a377c6b1876e ("crypto: sha256-mb - submit/flush routines for AVX2") Reported-by: Josh Poimboeuf <jpoimboe(a)redhat.com> Signed-off-by: Andrey Ryabinin <aryabinin(a)virtuozzo.com> Acked-by: Tim Chen Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/crypto/sha256-mb/sha256_mb_mgr_flush_avx2.S | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) --- a/arch/x86/crypto/sha256-mb/sha256_mb_mgr_flush_avx2.S +++ b/arch/x86/crypto/sha256-mb/sha256_mb_mgr_flush_avx2.S @@ -155,8 +155,8 @@ LABEL skip_ %I .endr # Find min length - vmovdqa _lens+0*16(state), %xmm0 - vmovdqa _lens+1*16(state), %xmm1 + vmovdqu _lens+0*16(state), %xmm0 + vmovdqu _lens+1*16(state), %xmm1 vpminud %xmm1, %xmm0, %xmm2 # xmm2 has {D,C,B,A} vpalignr $8, %xmm2, %xmm3, %xmm3 # xmm3 has {x,x,D,C} @@ -176,8 +176,8 @@ LABEL skip_ %I vpsubd %xmm2, %xmm0, %xmm0 vpsubd %xmm2, %xmm1, %xmm1 - vmovdqa %xmm0, _lens+0*16(state) - vmovdqa %xmm1, _lens+1*16(state) + vmovdqu %xmm0, _lens+0*16(state) + vmovdqu %xmm1, _lens+1*16(state) # "state" and "args" are the same address, arg1 # len is arg2 @@ -234,8 +234,8 @@ ENTRY(sha256_mb_mgr_get_comp_job_avx2) jc .return_null # Find min length - vmovdqa _lens(state), %xmm0 - vmovdqa _lens+1*16(state), %xmm1 + vmovdqu _lens(state), %xmm0 + vmovdqu _lens+1*16(state), %xmm1 vpminud %xmm1, %xmm0, %xmm2 # xmm2 has {D,C,B,A} vpalignr $8, %xmm2, %xmm3, %xmm3 # xmm3 has {x,x,D,C} Patches currently in stable-queue which might be from aryabinin(a)virtuozzo.com are queue-4.13/crypto-x86-sha256-mb-fix-panic-due-to-unaligned-access.patch queue-4.13/crypto-x86-sha1-mb-fix-panic-due-to-unaligned-access.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "crypto: x86/sha1-mb - fix panic due to unaligned access" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled crypto: x86/sha1-mb - fix panic due to unaligned access to the 4.13-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: crypto-x86-sha1-mb-fix-panic-due-to-unaligned-access.patch and it can be found in the queue-4.13 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 d041b557792c85677f17e08eee535eafbd6b9aa2 Mon Sep 17 00:00:00 2001 From: Andrey Ryabinin <aryabinin(a)virtuozzo.com> Date: Mon, 16 Oct 2017 18:51:31 +0300 Subject: crypto: x86/sha1-mb - fix panic due to unaligned access From: Andrey Ryabinin <aryabinin(a)virtuozzo.com> commit d041b557792c85677f17e08eee535eafbd6b9aa2 upstream. struct sha1_ctx_mgr allocated in sha1_mb_mod_init() via kzalloc() and later passed in sha1_mb_flusher_mgr_flush_avx2() function where instructions vmovdqa used to access the struct. vmovdqa requires 16-bytes aligned argument, but nothing guarantees that struct sha1_ctx_mgr will have that alignment. Unaligned vmovdqa will generate GP fault. Fix this by replacing vmovdqa with vmovdqu which doesn't have alignment requirements. Fixes: 2249cbb53ead ("crypto: sha-mb - SHA1 multibuffer submit and flush routines for AVX2") Signed-off-by: Andrey Ryabinin <aryabinin(a)virtuozzo.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/crypto/sha1-mb/sha1_mb_mgr_flush_avx2.S | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) --- a/arch/x86/crypto/sha1-mb/sha1_mb_mgr_flush_avx2.S +++ b/arch/x86/crypto/sha1-mb/sha1_mb_mgr_flush_avx2.S @@ -157,8 +157,8 @@ LABEL skip_ %I .endr # Find min length - vmovdqa _lens+0*16(state), %xmm0 - vmovdqa _lens+1*16(state), %xmm1 + vmovdqu _lens+0*16(state), %xmm0 + vmovdqu _lens+1*16(state), %xmm1 vpminud %xmm1, %xmm0, %xmm2 # xmm2 has {D,C,B,A} vpalignr $8, %xmm2, %xmm3, %xmm3 # xmm3 has {x,x,D,C} @@ -178,8 +178,8 @@ LABEL skip_ %I vpsubd %xmm2, %xmm0, %xmm0 vpsubd %xmm2, %xmm1, %xmm1 - vmovdqa %xmm0, _lens+0*16(state) - vmovdqa %xmm1, _lens+1*16(state) + vmovdqu %xmm0, _lens+0*16(state) + vmovdqu %xmm1, _lens+1*16(state) # "state" and "args" are the same address, arg1 # len is arg2 @@ -235,8 +235,8 @@ ENTRY(sha1_mb_mgr_get_comp_job_avx2) jc .return_null # Find min length - vmovdqa _lens(state), %xmm0 - vmovdqa _lens+1*16(state), %xmm1 + vmovdqu _lens(state), %xmm0 + vmovdqu _lens+1*16(state), %xmm1 vpminud %xmm1, %xmm0, %xmm2 # xmm2 has {D,C,B,A} vpalignr $8, %xmm2, %xmm3, %xmm3 # xmm3 has {x,x,D,C} Patches currently in stable-queue which might be from aryabinin(a)virtuozzo.com are queue-4.13/crypto-x86-sha256-mb-fix-panic-due-to-unaligned-access.patch queue-4.13/crypto-x86-sha1-mb-fix-panic-due-to-unaligned-access.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "ARM: 8720/1: ensure dump_instr() checks addr_limit" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ARM: 8720/1: ensure dump_instr() checks addr_limit to the 4.13-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-8720-1-ensure-dump_instr-checks-addr_limit.patch and it can be found in the queue-4.13 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 b9dd05c7002ee0ca8b676428b2268c26399b5e31 Mon Sep 17 00:00:00 2001 From: Mark Rutland <mark.rutland(a)arm.com> Date: Thu, 2 Nov 2017 18:44:28 +0100 Subject: ARM: 8720/1: ensure dump_instr() checks addr_limit From: Mark Rutland <mark.rutland(a)arm.com> commit b9dd05c7002ee0ca8b676428b2268c26399b5e31 upstream. When CONFIG_DEBUG_USER is enabled, it's possible for a user to deliberately trigger dump_instr() with a chosen kernel address. Let's avoid problems resulting from this by using get_user() rather than __get_user(), ensuring that we don't erroneously access kernel memory. So that we can use the same code to dump user instructions and kernel instructions, the common dumping code is factored out to __dump_instr(), with the fs manipulated appropriately in dump_instr() around calls to this. Signed-off-by: Mark Rutland <mark.rutland(a)arm.com> Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/kernel/traps.c | 28 ++++++++++++++++++---------- 1 file changed, 18 insertions(+), 10 deletions(-) --- a/arch/arm/kernel/traps.c +++ b/arch/arm/kernel/traps.c @@ -154,30 +154,26 @@ static void dump_mem(const char *lvl, co set_fs(fs); } -static void dump_instr(const char *lvl, struct pt_regs *regs) +static void __dump_instr(const char *lvl, struct pt_regs *regs) { unsigned long addr = instruction_pointer(regs); const int thumb = thumb_mode(regs); const int width = thumb ? 4 : 8; - mm_segment_t fs; char str[sizeof("00000000 ") * 5 + 2 + 1], *p = str; int i; /* - * We need to switch to kernel mode so that we can use __get_user - * to safely read from kernel space. Note that we now dump the - * code first, just in case the backtrace kills us. + * Note that we now dump the code first, just in case the backtrace + * kills us. */ - fs = get_fs(); - set_fs(KERNEL_DS); for (i = -4; i < 1 + !!thumb; i++) { unsigned int val, bad; if (thumb) - bad = __get_user(val, &((u16 *)addr)[i]); + bad = get_user(val, &((u16 *)addr)[i]); else - bad = __get_user(val, &((u32 *)addr)[i]); + bad = get_user(val, &((u32 *)addr)[i]); if (!bad) p += sprintf(p, i == 0 ? "(%0*x) " : "%0*x ", @@ -188,8 +184,20 @@ static void dump_instr(const char *lvl, } } printk("%sCode: %s\n", lvl, str); +} - set_fs(fs); +static void dump_instr(const char *lvl, struct pt_regs *regs) +{ + mm_segment_t fs; + + if (!user_mode(regs)) { + fs = get_fs(); + set_fs(KERNEL_DS); + __dump_instr(lvl, regs); + set_fs(fs); + } else { + __dump_instr(lvl, regs); + } } #ifdef CONFIG_ARM_UNWIND Patches currently in stable-queue which might be from mark.rutland(a)arm.com are queue-4.13/arm-8720-1-ensure-dump_instr-checks-addr_limit.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "crypto: ccm - preserve the IV buffer" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled crypto: ccm - preserve the IV buffer to the 4.13-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: crypto-ccm-preserve-the-iv-buffer.patch and it can be found in the queue-4.13 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 441f99c90497e15aa3ad1dbabd56187e29614348 Mon Sep 17 00:00:00 2001 From: Romain Izard <romain.izard.pro(a)gmail.com> Date: Tue, 31 Oct 2017 15:42:35 +0100 Subject: crypto: ccm - preserve the IV buffer From: Romain Izard <romain.izard.pro(a)gmail.com> commit 441f99c90497e15aa3ad1dbabd56187e29614348 upstream. The IV buffer used during CCM operations is used twice, during both the hashing step and the ciphering step. When using a hardware accelerator that updates the contents of the IV buffer at the end of ciphering operations, the value will be modified. In the decryption case, the subsequent setup of the hashing algorithm will interpret the updated IV instead of the original value, which can lead to out-of-bounds writes. Reuse the idata buffer, only used in the hashing step, to preserve the IV's value during the ciphering step in the decryption case. Signed-off-by: Romain Izard <romain.izard.pro(a)gmail.com> Reviewed-by: Tudor Ambarus <tudor.ambarus(a)microchip.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- crypto/ccm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/crypto/ccm.c +++ b/crypto/ccm.c @@ -363,7 +363,7 @@ static int crypto_ccm_decrypt(struct aea unsigned int cryptlen = req->cryptlen; u8 *authtag = pctx->auth_tag; u8 *odata = pctx->odata; - u8 *iv = req->iv; + u8 *iv = pctx->idata; int err; cryptlen -= authsize; @@ -379,6 +379,8 @@ static int crypto_ccm_decrypt(struct aea if (req->src != req->dst) dst = pctx->dst; + memcpy(iv, req->iv, 16); + skcipher_request_set_tfm(skreq, ctx->ctr); skcipher_request_set_callback(skreq, pctx->flags, crypto_ccm_decrypt_done, req); Patches currently in stable-queue which might be from romain.izard.pro(a)gmail.com are queue-4.13/crypto-ccm-preserve-the-iv-buffer.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "ALSA: usb-audio: support new Amanero Combo384 firmware version" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: usb-audio: support new Amanero Combo384 firmware version to the 4.13-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-usb-audio-support-new-amanero-combo384-firmware-version.patch and it can be found in the queue-4.13 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 f5ce817951f38023588b2b8308beca79abe20507 Mon Sep 17 00:00:00 2001 From: Jussi Laako <jussi(a)sonarnerd.net> Date: Wed, 1 Nov 2017 23:32:33 +0200 Subject: ALSA: usb-audio: support new Amanero Combo384 firmware version From: Jussi Laako <jussi(a)sonarnerd.net> commit f5ce817951f38023588b2b8308beca79abe20507 upstream. Support DSD_U32_BE sample format on new Amanero Combo384 firmware version on older VID/PID. Fixes: 3eff682d765b ("ALSA: usb-audio: Support both DSD LE/BE Amanero firmware versions") Signed-off-by: Jussi Laako <jussi(a)sonarnerd.net> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/usb/quirks.c | 1 + 1 file changed, 1 insertion(+) --- a/sound/usb/quirks.c +++ b/sound/usb/quirks.c @@ -1373,6 +1373,7 @@ u64 snd_usb_interface_dsd_format_quirks( case 0x199: return SNDRV_PCM_FMTBIT_DSD_U32_LE; case 0x19b: + case 0x203: return SNDRV_PCM_FMTBIT_DSD_U32_BE; default: break; Patches currently in stable-queue which might be from jussi(a)sonarnerd.net are queue-4.13/alsa-usb-audio-support-new-amanero-combo384-firmware-version.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "ALSA: timer: Limit max instances per timer" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: timer: Limit max instances per timer to the 4.13-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-timer-limit-max-instances-per-timer.patch and it can be found in the queue-4.13 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 9b7d869ee5a77ed4a462372bb89af622e705bfb8 Mon Sep 17 00:00:00 2001 From: Takashi Iwai <tiwai(a)suse.de> Date: Sun, 5 Nov 2017 10:07:43 +0100 Subject: ALSA: timer: Limit max instances per timer MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Takashi Iwai <tiwai(a)suse.de> commit 9b7d869ee5a77ed4a462372bb89af622e705bfb8 upstream. Currently we allow unlimited number of timer instances, and it may bring the system hogging way too much CPU when too many timer instances are opened and processed concurrently. This may end up with a soft-lockup report as triggered by syzkaller, especially when hrtimer backend is deployed. Since such insane number of instances aren't demanded by the normal use case of ALSA sequencer and it merely opens a risk only for abuse, this patch introduces the upper limit for the number of instances per timer backend. As default, it's set to 1000, but for the fine-grained timer like hrtimer, it's set to 100. Reported-by: syzbot Tested-by: Jérôme Glisse <jglisse(a)redhat.com> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/sound/timer.h | 2 + sound/core/hrtimer.c | 1 sound/core/timer.c | 67 ++++++++++++++++++++++++++++++++++++++++---------- 3 files changed, 57 insertions(+), 13 deletions(-) --- a/include/sound/timer.h +++ b/include/sound/timer.h @@ -90,6 +90,8 @@ struct snd_timer { struct list_head ack_list_head; struct list_head sack_list_head; /* slow ack list head */ struct tasklet_struct task_queue; + int max_instances; /* upper limit of timer instances */ + int num_instances; /* current number of timer instances */ }; struct snd_timer_instance { --- a/sound/core/hrtimer.c +++ b/sound/core/hrtimer.c @@ -159,6 +159,7 @@ static int __init snd_hrtimer_init(void) timer->hw = hrtimer_hw; timer->hw.resolution = resolution; timer->hw.ticks = NANO_SEC / resolution; + timer->max_instances = 100; /* lower the limit */ err = snd_timer_global_register(timer); if (err < 0) { --- a/sound/core/timer.c +++ b/sound/core/timer.c @@ -180,7 +180,7 @@ static void snd_timer_request(struct snd * * call this with register_mutex down. */ -static void snd_timer_check_slave(struct snd_timer_instance *slave) +static int snd_timer_check_slave(struct snd_timer_instance *slave) { struct snd_timer *timer; struct snd_timer_instance *master; @@ -190,16 +190,21 @@ static void snd_timer_check_slave(struct list_for_each_entry(master, &timer->open_list_head, open_list) { if (slave->slave_class == master->slave_class && slave->slave_id == master->slave_id) { + if (master->timer->num_instances >= + master->timer->max_instances) + return -EBUSY; list_move_tail(&slave->open_list, &master->slave_list_head); + master->timer->num_instances++; spin_lock_irq(&slave_active_lock); slave->master = master; slave->timer = master->timer; spin_unlock_irq(&slave_active_lock); - return; + return 0; } } } + return 0; } /* @@ -208,7 +213,7 @@ static void snd_timer_check_slave(struct * * call this with register_mutex down. */ -static void snd_timer_check_master(struct snd_timer_instance *master) +static int snd_timer_check_master(struct snd_timer_instance *master) { struct snd_timer_instance *slave, *tmp; @@ -216,7 +221,11 @@ static void snd_timer_check_master(struc list_for_each_entry_safe(slave, tmp, &snd_timer_slave_list, open_list) { if (slave->slave_class == master->slave_class && slave->slave_id == master->slave_id) { + if (master->timer->num_instances >= + master->timer->max_instances) + return -EBUSY; list_move_tail(&slave->open_list, &master->slave_list_head); + master->timer->num_instances++; spin_lock_irq(&slave_active_lock); spin_lock(&master->timer->lock); slave->master = master; @@ -228,8 +237,11 @@ static void snd_timer_check_master(struc spin_unlock_irq(&slave_active_lock); } } + return 0; } +static int snd_timer_close_locked(struct snd_timer_instance *timeri); + /* * open a timer instance * when opening a master, the slave id must be here given. @@ -240,6 +252,7 @@ int snd_timer_open(struct snd_timer_inst { struct snd_timer *timer; struct snd_timer_instance *timeri = NULL; + int err; if (tid->dev_class == SNDRV_TIMER_CLASS_SLAVE) { /* open a slave instance */ @@ -259,10 +272,14 @@ int snd_timer_open(struct snd_timer_inst timeri->slave_id = tid->device; timeri->flags |= SNDRV_TIMER_IFLG_SLAVE; list_add_tail(&timeri->open_list, &snd_timer_slave_list); - snd_timer_check_slave(timeri); + err = snd_timer_check_slave(timeri); + if (err < 0) { + snd_timer_close_locked(timeri); + timeri = NULL; + } mutex_unlock(&register_mutex); *ti = timeri; - return 0; + return err; } /* open a master instance */ @@ -288,6 +305,10 @@ int snd_timer_open(struct snd_timer_inst return -EBUSY; } } + if (timer->num_instances >= timer->max_instances) { + mutex_unlock(&register_mutex); + return -EBUSY; + } timeri = snd_timer_instance_new(owner, timer); if (!timeri) { mutex_unlock(&register_mutex); @@ -314,25 +335,27 @@ int snd_timer_open(struct snd_timer_inst } list_add_tail(&timeri->open_list, &timer->open_list_head); - snd_timer_check_master(timeri); + timer->num_instances++; + err = snd_timer_check_master(timeri); + if (err < 0) { + snd_timer_close_locked(timeri); + timeri = NULL; + } mutex_unlock(&register_mutex); *ti = timeri; - return 0; + return err; } EXPORT_SYMBOL(snd_timer_open); /* * close a timer instance + * call this with register_mutex down. */ -int snd_timer_close(struct snd_timer_instance *timeri) +static int snd_timer_close_locked(struct snd_timer_instance *timeri) { struct snd_timer *timer = NULL; struct snd_timer_instance *slave, *tmp; - if (snd_BUG_ON(!timeri)) - return -ENXIO; - - mutex_lock(&register_mutex); list_del(&timeri->open_list); /* force to stop the timer */ @@ -340,6 +363,7 @@ int snd_timer_close(struct snd_timer_ins timer = timeri->timer; if (timer) { + timer->num_instances--; /* wait, until the active callback is finished */ spin_lock_irq(&timer->lock); while (timeri->flags & SNDRV_TIMER_IFLG_CALLBACK) { @@ -355,6 +379,7 @@ int snd_timer_close(struct snd_timer_ins list_for_each_entry_safe(slave, tmp, &timeri->slave_list_head, open_list) { list_move_tail(&slave->open_list, &snd_timer_slave_list); + timer->num_instances--; slave->master = NULL; slave->timer = NULL; list_del_init(&slave->ack_list); @@ -382,9 +407,24 @@ int snd_timer_close(struct snd_timer_ins module_put(timer->module); } - mutex_unlock(&register_mutex); return 0; } + +/* + * close a timer instance + */ +int snd_timer_close(struct snd_timer_instance *timeri) +{ + int err; + + if (snd_BUG_ON(!timeri)) + return -ENXIO; + + mutex_lock(&register_mutex); + err = snd_timer_close_locked(timeri); + mutex_unlock(&register_mutex); + return err; +} EXPORT_SYMBOL(snd_timer_close); unsigned long snd_timer_resolution(struct snd_timer_instance *timeri) @@ -855,6 +895,7 @@ int snd_timer_new(struct snd_card *card, spin_lock_init(&timer->lock); tasklet_init(&timer->task_queue, snd_timer_tasklet, (unsigned long)timer); + timer->max_instances = 1000; /* default limit per timer */ if (card != NULL) { timer->module = card->module; err = snd_device_new(card, SNDRV_DEV_TIMER, timer, &ops); Patches currently in stable-queue which might be from tiwai(a)suse.de are queue-4.13/alsa-seq-avoid-invalid-lockdep-class-warning.patch queue-4.13/alsa-hda-fix-headset-mic-problem-for-dell-machines-with-alc274.patch queue-4.13/alsa-timer-limit-max-instances-per-timer.patch queue-4.13/alsa-seq-fix-oss-sysex-delivery-in-oss-emulation.patch queue-4.13/alsa-usb-audio-support-new-amanero-combo384-firmware-version.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "ALSA: seq: Fix OSS sysex delivery in OSS emulation" has been added to the 4.13-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 OSS sysex delivery in OSS emulation to the 4.13-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-oss-sysex-delivery-in-oss-emulation.patch and it can be found in the queue-4.13 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 132d358b183ac6ad8b3fea32ad5e0663456d18d1 Mon Sep 17 00:00:00 2001 From: Takashi Iwai <tiwai(a)suse.de> Date: Tue, 7 Nov 2017 16:05:24 +0100 Subject: ALSA: seq: Fix OSS sysex delivery in OSS emulation From: Takashi Iwai <tiwai(a)suse.de> commit 132d358b183ac6ad8b3fea32ad5e0663456d18d1 upstream. The SYSEX event delivery in OSS sequencer emulation assumed that the event is encoded in the variable-length data with the straight buffering. This was the normal behavior in the past, but during the development, the chained buffers were introduced for carrying more data, while the OSS code was left intact. As a result, when a SYSEX event with the chained buffer data is passed to OSS sequencer port, it may end up with the wrong memory access, as if it were having a too large buffer. This patch addresses the bug, by applying the buffer data expansion by the generic snd_seq_dump_var_event() helper function. Reported-by: syzbot <syzkaller(a)googlegroups.com> Reported-by: Mark Salyzyn <salyzyn(a)android.com> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/core/seq/oss/seq_oss_midi.c | 4 +--- sound/core/seq/oss/seq_oss_readq.c | 29 +++++++++++++++++++++++++++++ sound/core/seq/oss/seq_oss_readq.h | 2 ++ 3 files changed, 32 insertions(+), 3 deletions(-) --- a/sound/core/seq/oss/seq_oss_midi.c +++ b/sound/core/seq/oss/seq_oss_midi.c @@ -612,9 +612,7 @@ send_midi_event(struct seq_oss_devinfo * if (!dp->timer->running) len = snd_seq_oss_timer_start(dp->timer); if (ev->type == SNDRV_SEQ_EVENT_SYSEX) { - if ((ev->flags & SNDRV_SEQ_EVENT_LENGTH_MASK) == SNDRV_SEQ_EVENT_LENGTH_VARIABLE) - snd_seq_oss_readq_puts(dp->readq, mdev->seq_device, - ev->data.ext.ptr, ev->data.ext.len); + snd_seq_oss_readq_sysex(dp->readq, mdev->seq_device, ev); } else { len = snd_midi_event_decode(mdev->coder, msg, sizeof(msg), ev); if (len > 0) --- a/sound/core/seq/oss/seq_oss_readq.c +++ b/sound/core/seq/oss/seq_oss_readq.c @@ -118,6 +118,35 @@ snd_seq_oss_readq_puts(struct seq_oss_re } /* + * put MIDI sysex bytes; the event buffer may be chained, thus it has + * to be expanded via snd_seq_dump_var_event(). + */ +struct readq_sysex_ctx { + struct seq_oss_readq *readq; + int dev; +}; + +static int readq_dump_sysex(void *ptr, void *buf, int count) +{ + struct readq_sysex_ctx *ctx = ptr; + + return snd_seq_oss_readq_puts(ctx->readq, ctx->dev, buf, count); +} + +int snd_seq_oss_readq_sysex(struct seq_oss_readq *q, int dev, + struct snd_seq_event *ev) +{ + struct readq_sysex_ctx ctx = { + .readq = q, + .dev = dev + }; + + if ((ev->flags & SNDRV_SEQ_EVENT_LENGTH_MASK) != SNDRV_SEQ_EVENT_LENGTH_VARIABLE) + return 0; + return snd_seq_dump_var_event(ev, readq_dump_sysex, &ctx); +} + +/* * copy an event to input queue: * return zero if enqueued */ --- a/sound/core/seq/oss/seq_oss_readq.h +++ b/sound/core/seq/oss/seq_oss_readq.h @@ -44,6 +44,8 @@ void snd_seq_oss_readq_delete(struct seq void snd_seq_oss_readq_clear(struct seq_oss_readq *readq); unsigned int snd_seq_oss_readq_poll(struct seq_oss_readq *readq, struct file *file, poll_table *wait); int snd_seq_oss_readq_puts(struct seq_oss_readq *readq, int dev, unsigned char *data, int len); +int snd_seq_oss_readq_sysex(struct seq_oss_readq *q, int dev, + struct snd_seq_event *ev); int snd_seq_oss_readq_put_event(struct seq_oss_readq *readq, union evrec *ev); int snd_seq_oss_readq_put_timestamp(struct seq_oss_readq *readq, unsigned long curt, int seq_mode); int snd_seq_oss_readq_pick(struct seq_oss_readq *q, union evrec *rec); Patches currently in stable-queue which might be from tiwai(a)suse.de are queue-4.13/alsa-seq-avoid-invalid-lockdep-class-warning.patch queue-4.13/alsa-hda-fix-headset-mic-problem-for-dell-machines-with-alc274.patch queue-4.13/alsa-timer-limit-max-instances-per-timer.patch queue-4.13/alsa-seq-fix-oss-sysex-delivery-in-oss-emulation.patch queue-4.13/alsa-usb-audio-support-new-amanero-combo384-firmware-version.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "ALSA: seq: Avoid invalid lockdep class warning" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: seq: Avoid invalid lockdep class warning to the 4.13-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-avoid-invalid-lockdep-class-warning.patch and it can be found in the queue-4.13 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 3510c7aa069aa83a2de6dab2b41401a198317bdc Mon Sep 17 00:00:00 2001 From: Takashi Iwai <tiwai(a)suse.de> Date: Mon, 6 Nov 2017 20:16:50 +0100 Subject: ALSA: seq: Avoid invalid lockdep class warning From: Takashi Iwai <tiwai(a)suse.de> commit 3510c7aa069aa83a2de6dab2b41401a198317bdc upstream. The recent fix for adding rwsem nesting annotation was using the given "hop" argument as the lock subclass key. Although the idea itself works, it may trigger a kernel warning like: BUG: looking up invalid subclass: 8 .... since the lockdep has a smaller number of subclasses (8) than we currently allow for the hops there (10). The current definition is merely a sanity check for avoiding the too deep delivery paths, and the 8 hops are already enough. So, as a quick fix, just follow the max hops as same as the max lockdep subclasses. Fixes: 1f20f9ff57ca ("ALSA: seq: Fix nested rwsem annotation for lockdep splat") Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/sound/seq_kernel.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/include/sound/seq_kernel.h +++ b/include/sound/seq_kernel.h @@ -49,7 +49,8 @@ typedef union snd_seq_timestamp snd_seq_ #define SNDRV_SEQ_DEFAULT_CLIENT_EVENTS 200 /* max delivery path length */ -#define SNDRV_SEQ_MAX_HOPS 10 +/* NOTE: this shouldn't be greater than MAX_LOCKDEP_SUBCLASSES */ +#define SNDRV_SEQ_MAX_HOPS 8 /* max size of event size */ #define SNDRV_SEQ_MAX_EVENT_LEN 0x3fffffff Patches currently in stable-queue which might be from tiwai(a)suse.de are queue-4.13/alsa-seq-avoid-invalid-lockdep-class-warning.patch queue-4.13/alsa-hda-fix-headset-mic-problem-for-dell-machines-with-alc274.patch queue-4.13/alsa-timer-limit-max-instances-per-timer.patch queue-4.13/alsa-seq-fix-oss-sysex-delivery-in-oss-emulation.patch queue-4.13/alsa-usb-audio-support-new-amanero-combo384-firmware-version.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "ALSA: hda - fix headset mic problem for Dell machines with alc274" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ALSA: hda - fix headset mic problem for Dell machines with alc274 to the 4.13-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-fix-headset-mic-problem-for-dell-machines-with-alc274.patch and it can be found in the queue-4.13 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 75ee94b20b46459e3d29f5ac2c3af3cebdeef777 Mon Sep 17 00:00:00 2001 From: Hui Wang <hui.wang(a)canonical.com> Date: Thu, 9 Nov 2017 08:48:08 +0800 Subject: ALSA: hda - fix headset mic problem for Dell machines with alc274 From: Hui Wang <hui.wang(a)canonical.com> commit 75ee94b20b46459e3d29f5ac2c3af3cebdeef777 upstream. Confirmed with Kailang of Realtek, the pin 0x19 is for Headset Mic, and the pin 0x1a is for Headphone Mic, he suggested to apply ALC269_FIXUP_DELL1_MIC_NO_PRESENCE to fix this problem. And we verified applying this FIXUP can fix this problem. Cc: Kailang Yang <kailang(a)realtek.com> Signed-off-by: Hui Wang <hui.wang(a)canonical.com> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/pci/hda/patch_realtek.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -6527,6 +6527,11 @@ static const struct snd_hda_pin_quirk al {0x14, 0x90170110}, {0x1b, 0x90a70130}, {0x21, 0x03211020}), + SND_HDA_PIN_QUIRK(0x10ec0274, 0x1028, "Dell", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE, + {0x12, 0xb7a60130}, + {0x13, 0xb8a61140}, + {0x16, 0x90170110}, + {0x21, 0x04211020}), SND_HDA_PIN_QUIRK(0x10ec0280, 0x103c, "HP", ALC280_FIXUP_HP_GPIO4, {0x12, 0x90a60130}, {0x14, 0x90170110}, Patches currently in stable-queue which might be from hui.wang(a)canonical.com are queue-4.13/alsa-hda-fix-headset-mic-problem-for-dell-machines-with-alc274.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "ACPICA: Make it possible to enable runtime GPEs earlier" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ACPICA: Make it possible to enable runtime GPEs earlier to the 4.13-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: acpica-make-it-possible-to-enable-runtime-gpes-earlier.patch and it can be found in the queue-4.13 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 1312b7e0caca44e7ff312bc2eaa888943384e3e1 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" <rafael.j.wysocki(a)intel.com> Date: Thu, 10 Aug 2017 00:31:58 +0200 Subject: ACPICA: Make it possible to enable runtime GPEs earlier From: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> commit 1312b7e0caca44e7ff312bc2eaa888943384e3e1 upstream. Runtime GPEs have corresponding _Lxx/_Exx methods and are enabled automatically during the initialization of the ACPI subsystem through acpi_update_all_gpes() with the assumption that acpi_setup_gpe_for_wake() will be called in advance for all of the GPEs pointed to by _PRW objects in the namespace that may be affected by acpi_update_all_gpes(). That is, acpi_ev_initialize_gpe_block() can only be called for a GPE block after acpi_setup_gpe_for_wake() has been called for all of the _PRW (wakeup) GPEs in it. The platform firmware on some systems, however, expects GPEs to be enabled before the enumeration of devices which is when acpi_setup_gpe_for_wake() is called and that goes against the above assumption. For this reason, introduce a new flag to be set by acpi_ev_initialize_gpe_block() when automatically enabling a GPE to indicate to acpi_setup_gpe_for_wake() that it needs to drop the reference to the GPE coming from acpi_ev_initialize_gpe_block() and modify acpi_setup_gpe_for_wake() accordingly. These changes allow acpi_setup_gpe_for_wake() and acpi_ev_initialize_gpe_block() to be invoked in any order. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Tested-by: Mika Westerberg <mika.westerberg(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/acpi/acpica/evgpeblk.c | 2 ++ drivers/acpi/acpica/evxfgpe.c | 8 ++++++++ include/acpi/actypes.h | 3 ++- 3 files changed, 12 insertions(+), 1 deletion(-) --- a/drivers/acpi/acpica/evgpeblk.c +++ b/drivers/acpi/acpica/evgpeblk.c @@ -496,6 +496,8 @@ acpi_ev_initialize_gpe_block(struct acpi continue; } + gpe_event_info->flags |= ACPI_GPE_AUTO_ENABLED; + if (event_status & ACPI_EVENT_FLAG_STATUS_SET) { ACPI_INFO(("GPE 0x%02X active on init", gpe_number)); --- a/drivers/acpi/acpica/evxfgpe.c +++ b/drivers/acpi/acpica/evxfgpe.c @@ -435,6 +435,14 @@ acpi_setup_gpe_for_wake(acpi_handle wake */ gpe_event_info->flags = (ACPI_GPE_DISPATCH_NOTIFY | ACPI_GPE_LEVEL_TRIGGERED); + } else if (gpe_event_info->flags & ACPI_GPE_AUTO_ENABLED) { + /* + * A reference to this GPE has been added during the GPE block + * initialization, so drop it now to prevent the GPE from being + * permanently enabled and clear its ACPI_GPE_AUTO_ENABLED flag. + */ + (void)acpi_ev_remove_gpe_reference(gpe_event_info); + gpe_event_info->flags &= ~ACPI_GPE_AUTO_ENABLED; } /* --- a/include/acpi/actypes.h +++ b/include/acpi/actypes.h @@ -775,7 +775,7 @@ typedef u32 acpi_event_status; * | | | | +-- Type of dispatch:to method, handler, notify, or none * | | | +----- Interrupt type: edge or level triggered * | | +------- Is a Wake GPE - * | +--------- Is GPE masked by the software GPE masking mechanism + * | +--------- Has been enabled automatically at init time * +------------ <Reserved> */ #define ACPI_GPE_DISPATCH_NONE (u8) 0x00 @@ -791,6 +791,7 @@ typedef u32 acpi_event_status; #define ACPI_GPE_XRUPT_TYPE_MASK (u8) 0x08 #define ACPI_GPE_CAN_WAKE (u8) 0x10 +#define ACPI_GPE_AUTO_ENABLED (u8) 0x20 /* * Flags for GPE and Lock interfaces Patches currently in stable-queue which might be from rafael.j.wysocki(a)intel.com are queue-4.13/acpi-pm-blacklist-low-power-s0-idle-_dsm-for-dell-xps13-9360.patch queue-4.13/acpica-make-it-possible-to-enable-runtime-gpes-earlier.patch queue-4.13/acpica-dispatch-active-gpes-at-init-time.patch queue-4.13/acpi-scan-enable-gpes-before-scanning-the-namespace.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "ACPICA: Dispatch active GPEs at init time" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ACPICA: Dispatch active GPEs at init time to the 4.13-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: acpica-dispatch-active-gpes-at-init-time.patch and it can be found in the queue-4.13 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 ecc1165b8b743fd1503b9c799ae3a9933b89877b Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" <rafael.j.wysocki(a)intel.com> Date: Thu, 10 Aug 2017 00:30:09 +0200 Subject: ACPICA: Dispatch active GPEs at init time From: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> commit ecc1165b8b743fd1503b9c799ae3a9933b89877b upstream. In some cases GPEs are already active when they are enabled by acpi_ev_initialize_gpe_block() and whatever happens next may depend on the result of handling the events signaled by them, so the events should not be discarded (which is what happens currently) and they should be handled as soon as reasonably possible. For this reason, modify acpi_ev_initialize_gpe_block() to dispatch GPEs with the status flag set in-band right after enabling them. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Tested-by: Mika Westerberg <mika.westerberg(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/acpi/acpica/evgpeblk.c | 28 +++++++++++++++++++--------- 1 file changed, 19 insertions(+), 9 deletions(-) --- a/drivers/acpi/acpica/evgpeblk.c +++ b/drivers/acpi/acpica/evgpeblk.c @@ -440,9 +440,11 @@ acpi_ev_initialize_gpe_block(struct acpi void *ignored) { acpi_status status; + acpi_event_status event_status; struct acpi_gpe_event_info *gpe_event_info; u32 gpe_enabled_count; u32 gpe_index; + u32 gpe_number; u32 i; u32 j; @@ -470,30 +472,38 @@ acpi_ev_initialize_gpe_block(struct acpi gpe_index = (i * ACPI_GPE_REGISTER_WIDTH) + j; gpe_event_info = &gpe_block->event_info[gpe_index]; + gpe_number = gpe_block->block_base_number + gpe_index; /* * Ignore GPEs that have no corresponding _Lxx/_Exx method - * and GPEs that are used to wake the system + * and GPEs that are used for wakeup */ - if ((ACPI_GPE_DISPATCH_TYPE(gpe_event_info->flags) == - ACPI_GPE_DISPATCH_NONE) - || (ACPI_GPE_DISPATCH_TYPE(gpe_event_info->flags) == - ACPI_GPE_DISPATCH_HANDLER) - || (ACPI_GPE_DISPATCH_TYPE(gpe_event_info->flags) == - ACPI_GPE_DISPATCH_RAW_HANDLER) + if ((ACPI_GPE_DISPATCH_TYPE(gpe_event_info->flags) != + ACPI_GPE_DISPATCH_METHOD) || (gpe_event_info->flags & ACPI_GPE_CAN_WAKE)) { continue; } + event_status = 0; + (void)acpi_hw_get_gpe_status(gpe_event_info, + &event_status); + status = acpi_ev_add_gpe_reference(gpe_event_info); if (ACPI_FAILURE(status)) { ACPI_EXCEPTION((AE_INFO, status, "Could not enable GPE 0x%02X", - gpe_index + - gpe_block->block_base_number)); + gpe_number)); continue; } + if (event_status & ACPI_EVENT_FLAG_STATUS_SET) { + ACPI_INFO(("GPE 0x%02X active on init", + gpe_number)); + (void)acpi_ev_gpe_dispatch(gpe_block->node, + gpe_event_info, + gpe_number); + } + gpe_enabled_count++; } } Patches currently in stable-queue which might be from rafael.j.wysocki(a)intel.com are queue-4.13/acpi-pm-blacklist-low-power-s0-idle-_dsm-for-dell-xps13-9360.patch queue-4.13/acpica-make-it-possible-to-enable-runtime-gpes-earlier.patch queue-4.13/acpica-dispatch-active-gpes-at-init-time.patch queue-4.13/acpi-scan-enable-gpes-before-scanning-the-namespace.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "ACPI / PM: Blacklist Low Power S0 Idle _DSM for Dell XPS13 9360" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ACPI / PM: Blacklist Low Power S0 Idle _DSM for Dell XPS13 9360 to the 4.13-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: acpi-pm-blacklist-low-power-s0-idle-_dsm-for-dell-xps13-9360.patch and it can be found in the queue-4.13 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 71630b7a832f699d6a6764ae75797e4e743ae348 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" <rafael.j.wysocki(a)intel.com> Date: Mon, 6 Nov 2017 23:56:57 +0100 Subject: ACPI / PM: Blacklist Low Power S0 Idle _DSM for Dell XPS13 9360 From: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> commit 71630b7a832f699d6a6764ae75797e4e743ae348 upstream. At least one Dell XPS13 9360 is reported to have serious issues with the Low Power S0 Idle _DSM interface and since this machine model generally can do ACPI S3 just fine, add a blacklist entry to disable that interface for Dell XPS13 9360. Fixes: 8110dd281e15 (ACPI / sleep: EC-based wakeup from suspend-to-idle on recent systems) Link: https://bugzilla.kernel.org/show_bug.cgi?id=196907 Reported-by: Paul Menzel <pmenzel(a)molgen.mpg.de> Tested-by: Paul Menzel <pmenzel(a)molgen.mpg.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/acpi/sleep.c | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) --- a/drivers/acpi/sleep.c +++ b/drivers/acpi/sleep.c @@ -160,6 +160,14 @@ static int __init init_nvs_nosave(const return 0; } +static bool acpi_sleep_no_lps0; + +static int __init init_no_lps0(const struct dmi_system_id *d) +{ + acpi_sleep_no_lps0 = true; + return 0; +} + static struct dmi_system_id acpisleep_dmi_table[] __initdata = { { .callback = init_old_suspend_ordering, @@ -343,6 +351,19 @@ static struct dmi_system_id acpisleep_dm DMI_MATCH(DMI_PRODUCT_NAME, "80E3"), }, }, + /* + * https://bugzilla.kernel.org/show_bug.cgi?id=196907 + * Some Dell XPS13 9360 cannot do suspend-to-idle using the Low Power + * S0 Idle firmware interface. + */ + { + .callback = init_no_lps0, + .ident = "Dell XPS13 9360", + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."), + DMI_MATCH(DMI_PRODUCT_NAME, "XPS 13 9360"), + }, + }, {}, }; @@ -485,6 +506,7 @@ static void acpi_pm_end(void) } #else /* !CONFIG_ACPI_SLEEP */ #define acpi_target_sleep_state ACPI_STATE_S0 +#define acpi_sleep_no_lps0 (false) static inline void acpi_sleep_dmi_check(void) {} #endif /* CONFIG_ACPI_SLEEP */ @@ -702,6 +724,12 @@ static int lps0_device_attach(struct acp if (lps0_device_handle) return 0; + if (acpi_sleep_no_lps0) { + acpi_handle_info(adev->handle, + "Low Power S0 Idle interface disabled\n"); + return 0; + } + if (!(acpi_gbl_FADT.flags & ACPI_FADT_LOW_POWER_S0)) return 0; Patches currently in stable-queue which might be from rafael.j.wysocki(a)intel.com are queue-4.13/acpi-pm-blacklist-low-power-s0-idle-_dsm-for-dell-xps13-9360.patch queue-4.13/acpica-make-it-possible-to-enable-runtime-gpes-earlier.patch queue-4.13/acpica-dispatch-active-gpes-at-init-time.patch queue-4.13/acpi-scan-enable-gpes-before-scanning-the-namespace.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "ACPI / scan: Enable GPEs before scanning the namespace" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ACPI / scan: Enable GPEs before scanning the namespace to the 4.13-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: acpi-scan-enable-gpes-before-scanning-the-namespace.patch and it can be found in the queue-4.13 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 eb7f43c4adb4a789f99f53916182c3401b4e33c7 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" <rafael.j.wysocki(a)intel.com> Date: Thu, 10 Aug 2017 00:34:23 +0200 Subject: ACPI / scan: Enable GPEs before scanning the namespace From: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> commit eb7f43c4adb4a789f99f53916182c3401b4e33c7 upstream. On some systems the platform firmware expects GPEs to be enabled before the enumeration of devices and if that expectation is not met, the systems in question may not boot in some situations. For this reason, change the initialization ordering of the ACPI subsystem to make it enable GPEs before scanning the namespace for the first time in order to enumerate devices. Reported-by: Mika Westerberg <mika.westerberg(a)linux.intel.com> Suggested-by: Mika Westerberg <mika.westerberg(a)linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Acked-by: Lv Zheng <lv.zheng(a)intel.com> Tested-by: Mika Westerberg <mika.westerberg(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/acpi/scan.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/drivers/acpi/scan.c +++ b/drivers/acpi/scan.c @@ -2058,6 +2058,9 @@ int __init acpi_scan_init(void) acpi_get_spcr_uart_addr(); } + acpi_gpe_apply_masked_gpes(); + acpi_update_all_gpes(); + mutex_lock(&acpi_scan_lock); /* * Enumerate devices in the ACPI namespace. @@ -2082,9 +2085,6 @@ int __init acpi_scan_init(void) } } - acpi_gpe_apply_masked_gpes(); - acpi_update_all_gpes(); - acpi_scan_initialized = true; out: Patches currently in stable-queue which might be from rafael.j.wysocki(a)intel.com are queue-4.13/acpi-pm-blacklist-low-power-s0-idle-_dsm-for-dell-xps13-9360.patch queue-4.13/acpica-make-it-possible-to-enable-runtime-gpes-earlier.patch queue-4.13/acpica-dispatch-active-gpes-at-init-time.patch queue-4.13/acpi-scan-enable-gpes-before-scanning-the-namespace.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "workqueue: Fix NULL pointer dereference" 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 workqueue: Fix NULL pointer dereference 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: workqueue-fix-null-pointer-dereference.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 cef572ad9bd7f85035ba8272e5352040e8be0152 Mon Sep 17 00:00:00 2001 From: Li Bin <huawei.libin(a)huawei.com> Date: Sat, 28 Oct 2017 11:07:28 +0800 Subject: workqueue: Fix NULL pointer dereference From: Li Bin <huawei.libin(a)huawei.com> commit cef572ad9bd7f85035ba8272e5352040e8be0152 upstream. When queue_work() is used in irq (not in task context), there is a potential case that trigger NULL pointer dereference. ---------------------------------------------------------------- worker_thread() |-spin_lock_irq() |-process_one_work() |-worker->current_pwq = pwq |-spin_unlock_irq() |-worker->current_func(work) |-spin_lock_irq() |-worker->current_pwq = NULL |-spin_unlock_irq() //interrupt here |-irq_handler |-__queue_work() //assuming that the wq is draining |-is_chained_work(wq) |-current_wq_worker() //Here, 'current' is the interrupted worker! |-current->current_pwq is NULL here! |-schedule() ---------------------------------------------------------------- Avoid it by checking for task context in current_wq_worker(), and if not in task context, we shouldn't use the 'current' to check the condition. Reported-by: Xiaofei Tan <tanxiaofei(a)huawei.com> Signed-off-by: Li Bin <huawei.libin(a)huawei.com> Reviewed-by: Lai Jiangshan <jiangshanlai(a)gmail.com> Signed-off-by: Tejun Heo <tj(a)kernel.org> Fixes: 8d03ecfe4718 ("workqueue: reimplement is_chained_work() using current_wq_worker()") Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- kernel/workqueue_internal.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/kernel/workqueue_internal.h +++ b/kernel/workqueue_internal.h @@ -9,6 +9,7 @@ #include <linux/workqueue.h> #include <linux/kthread.h> +#include <linux/preempt.h> struct worker_pool; @@ -59,7 +60,7 @@ struct worker { */ static inline struct worker *current_wq_worker(void) { - if (current->flags & PF_WQ_WORKER) + if (in_task() && (current->flags & PF_WQ_WORKER)) return kthread_data(current); return NULL; } Patches currently in stable-queue which might be from huawei.libin(a)huawei.com are queue-3.18/workqueue-fix-null-pointer-dereference.patch

7 years, 7 months

2
1
0 0

[Linux-stable-mirror] Patch "MIPS: Fix CM region target definitions" 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 MIPS: Fix CM region target definitions 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: mips-fix-cm-region-target-definitions.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 6a6cba1d945a7511cdfaf338526871195e420762 Mon Sep 17 00:00:00 2001 From: Paul Burton <paul.burton(a)mips.com> Date: Tue, 31 Oct 2017 15:09:22 -0700 Subject: MIPS: Fix CM region target definitions From: Paul Burton <paul.burton(a)mips.com> commit 6a6cba1d945a7511cdfaf338526871195e420762 upstream. The default CM target field in the GCR_BASE register is encoded with 0 meaning memory & 1 being reserved. However the definitions we use for those bits effectively get these two values backwards - likely because they were copied from the definitions for the CM regions where the target is encoded differently. This results in use setting up GCR_BASE with the reserved target value by default, rather than targeting memory as intended. Although we currently seem to get away with this it's not a great idea to rely upon. Fix this by changing our macros to match the documentated target values. The incorrect encoding became used as of commit 9f98f3dd0c51 ("MIPS: Add generic CM probe & access code") in the Linux v3.15 cycle, and was likely carried forwards from older but unused code introduced by commit 39b8d5254246 ("[MIPS] Add support for MIPS CMP platform.") in the v2.6.26 cycle. Fixes: 9f98f3dd0c51 ("MIPS: Add generic CM probe & access code") Signed-off-by: Paul Burton <paul.burton(a)mips.com> Reported-by: Matt Redfearn <matt.redfearn(a)mips.com> Reviewed-by: James Hogan <jhogan(a)kernel.org> Cc: Matt Redfearn <matt.redfearn(a)mips.com> Cc: Ralf Baechle <ralf(a)linux-mips.org> Cc: linux-mips(a)linux-mips.org Cc: <stable(a)vger.kernel.org> # v3.15+ Patchwork: https://patchwork.linux-mips.org/patch/17562/ Signed-off-by: James Hogan <jhogan(a)kernel.org> [jhogan(a)kernel.org: Backported 3.15..4.13] Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/include/asm/mips-cm.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/arch/mips/include/asm/mips-cm.h +++ b/arch/mips/include/asm/mips-cm.h @@ -173,8 +173,8 @@ BUILD_CM_Cx_R_(tcid_8_priority, 0x80) #define CM_GCR_BASE_GCRBASE_MSK (_ULCAST_(0x1ffff) << 15) #define CM_GCR_BASE_CMDEFTGT_SHF 0 #define CM_GCR_BASE_CMDEFTGT_MSK (_ULCAST_(0x3) << 0) -#define CM_GCR_BASE_CMDEFTGT_DISABLED 0 -#define CM_GCR_BASE_CMDEFTGT_MEM 1 +#define CM_GCR_BASE_CMDEFTGT_MEM 0 +#define CM_GCR_BASE_CMDEFTGT_RESERVED 1 #define CM_GCR_BASE_CMDEFTGT_IOCU0 2 #define CM_GCR_BASE_CMDEFTGT_IOCU1 3 Patches currently in stable-queue which might be from paul.burton(a)mips.com are queue-3.18/mips-fix-cm-region-target-definitions.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "MIPS: microMIPS: Fix incorrect mask in insn_table_MM" 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 MIPS: microMIPS: Fix incorrect mask in insn_table_MM 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: mips-micromips-fix-incorrect-mask-in-insn_table_mm.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 77238e76b9156d28d86c1e31c00ed2960df0e4de Mon Sep 17 00:00:00 2001 From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com> Date: Tue, 31 Oct 2017 00:35:03 -0500 Subject: MIPS: microMIPS: Fix incorrect mask in insn_table_MM From: Gustavo A. R. Silva <garsilva(a)embeddedor.com> commit 77238e76b9156d28d86c1e31c00ed2960df0e4de upstream. It seems that this is a typo error and the proper bit masking is "RT | RS" instead of "RS | RS". This issue was detected with the help of Coccinelle. Fixes: d6b3314b49e1 ("MIPS: uasm: Add lh uam instruction") Reported-by: Julia Lawall <julia.lawall(a)lip6.fr> Signed-off-by: Gustavo A. R. Silva <garsilva(a)embeddedor.com> Reviewed-by: James Hogan <jhogan(a)kernel.org> Patchwork: https://patchwork.linux-mips.org/patch/17551/ Signed-off-by: James Hogan <jhogan(a)kernel.org> [jhogan(a)kernel.org: Backported 3.16..4.12] Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/mips/mm/uasm-micromips.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/arch/mips/mm/uasm-micromips.c +++ b/arch/mips/mm/uasm-micromips.c @@ -83,7 +83,7 @@ static struct insn insn_table_MM[] = { { insn_jr, M(mm_pool32a_op, 0, 0, 0, mm_jalr_op, mm_pool32axf_op), RS }, { insn_lb, M(mm_lb32_op, 0, 0, 0, 0, 0), RT | RS | SIMM }, { insn_ld, 0, 0 }, - { insn_lh, M(mm_lh32_op, 0, 0, 0, 0, 0), RS | RS | SIMM }, + { insn_lh, M(mm_lh32_op, 0, 0, 0, 0, 0), RT | RS | SIMM }, { insn_ll, M(mm_pool32c_op, 0, 0, (mm_ll_func << 1), 0, 0), RS | RT | SIMM }, { insn_lld, 0, 0 }, { insn_lui, M(mm_pool32i_op, mm_lui_op, 0, 0, 0, 0), RS | SIMM }, Patches currently in stable-queue which might be from garsilva(a)embeddedor.com are queue-3.18/mips-micromips-fix-incorrect-mask-in-insn_table_mm.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "KEYS: fix NULL pointer dereference during ASN.1 parsing [ver #2]" 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 KEYS: fix NULL pointer dereference during ASN.1 parsing [ver #2] 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: keys-fix-null-pointer-dereference-during-asn.1-parsing.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 624f5ab8720b3371367327a822c267699c1823b8 Mon Sep 17 00:00:00 2001 From: Eric Biggers <ebiggers(a)google.com> Date: Tue, 7 Nov 2017 22:29:02 +0000 Subject: KEYS: fix NULL pointer dereference during ASN.1 parsing [ver #2] From: Eric Biggers <ebiggers(a)google.com> commit 624f5ab8720b3371367327a822c267699c1823b8 upstream. syzkaller reported a NULL pointer dereference in asn1_ber_decoder(). It can be reproduced by the following command, assuming CONFIG_PKCS7_TEST_KEY=y: keyctl add pkcs7_test desc '' @s The bug is that if the data buffer is empty, an integer underflow occurs in the following check: if (unlikely(dp >= datalen - 1)) goto data_overrun_error; This results in the NULL data pointer being dereferenced. Fix it by checking for 'datalen - dp < 2' instead. Also fix the similar check for 'dp >= datalen - n' later in the same function. That one possibly could result in a buffer overread. The NULL pointer dereference was reproducible using the "pkcs7_test" key type but not the "asymmetric" key type because the "asymmetric" key type checks for a 0-length payload before calling into the ASN.1 decoder but the "pkcs7_test" key type does not. The bug report was: BUG: unable to handle kernel NULL pointer dereference at (null) IP: asn1_ber_decoder+0x17f/0xe60 lib/asn1_decoder.c:233 PGD 7b708067 P4D 7b708067 PUD 7b6ee067 PMD 0 Oops: 0000 [#1] SMP Modules linked in: CPU: 0 PID: 522 Comm: syz-executor1 Not tainted 4.14.0-rc8 #7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.3-20171021_125229-anatol 04/01/2014 task: ffff9b6b3798c040 task.stack: ffff9b6b37970000 RIP: 0010:asn1_ber_decoder+0x17f/0xe60 lib/asn1_decoder.c:233 RSP: 0018:ffff9b6b37973c78 EFLAGS: 00010216 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000021c RDX: ffffffff814a04ed RSI: ffffb1524066e000 RDI: ffffffff910759e0 RBP: ffff9b6b37973d60 R08: 0000000000000001 R09: ffff9b6b3caa4180 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f10ed1f2700(0000) GS:ffff9b6b3ea00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000007b6f3000 CR4: 00000000000006f0 Call Trace: pkcs7_parse_message+0xee/0x240 crypto/asymmetric_keys/pkcs7_parser.c:139 verify_pkcs7_signature+0x33/0x180 certs/system_keyring.c:216 pkcs7_preparse+0x41/0x70 crypto/asymmetric_keys/pkcs7_key_type.c:63 key_create_or_update+0x180/0x530 security/keys/key.c:855 SYSC_add_key security/keys/keyctl.c:122 [inline] SyS_add_key+0xbf/0x250 security/keys/keyctl.c:62 entry_SYSCALL_64_fastpath+0x1f/0xbe RIP: 0033:0x4585c9 RSP: 002b:00007f10ed1f1bd8 EFLAGS: 00000216 ORIG_RAX: 00000000000000f8 RAX: ffffffffffffffda RBX: 00007f10ed1f2700 RCX: 00000000004585c9 RDX: 0000000020000000 RSI: 0000000020008ffb RDI: 0000000020008000 RBP: 0000000000000000 R08: ffffffffffffffff R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000216 R12: 00007fff1b2260ae R13: 00007fff1b2260af R14: 00007f10ed1f2700 R15: 0000000000000000 Code: dd ca ff 48 8b 45 88 48 83 e8 01 4c 39 f0 0f 86 a8 07 00 00 e8 53 dd ca ff 49 8d 46 01 48 89 85 58 ff ff ff 48 8b 85 60 ff ff ff <42> 0f b6 0c 30 89 c8 88 8d 75 ff ff ff 83 e0 1f 89 8d 28 ff ff RIP: asn1_ber_decoder+0x17f/0xe60 lib/asn1_decoder.c:233 RSP: ffff9b6b37973c78 CR2: 0000000000000000 Fixes: 42d5ec27f873 ("X.509: Add an ASN.1 decoder") Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: James Morris <james.l.morris(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- lib/asn1_decoder.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/lib/asn1_decoder.c +++ b/lib/asn1_decoder.c @@ -220,7 +220,7 @@ next_op: hdr = 2; /* Extract a tag from the data */ - if (unlikely(dp >= datalen - 1)) + if (unlikely(datalen - dp < 2)) goto data_overrun_error; tag = data[dp++]; if (unlikely((tag & 0x1f) == ASN1_LONG_TAG)) @@ -266,7 +266,7 @@ next_op: int n = len - 0x80; if (unlikely(n > 2)) goto length_too_long; - if (unlikely(dp >= datalen - n)) + if (unlikely(n > datalen - dp)) goto data_overrun_error; hdr += n; for (len = 0; n > 0; n--) { Patches currently in stable-queue which might be from ebiggers(a)google.com are queue-3.18/keys-trusted-sanitize-all-key-material.patch queue-3.18/keys-fix-null-pointer-dereference-during-asn.1-parsing.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "crypto: x86/sha1-mb - fix panic due to unaligned access" 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 crypto: x86/sha1-mb - fix panic due to unaligned access 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: crypto-x86-sha1-mb-fix-panic-due-to-unaligned-access.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 d041b557792c85677f17e08eee535eafbd6b9aa2 Mon Sep 17 00:00:00 2001 From: Andrey Ryabinin <aryabinin(a)virtuozzo.com> Date: Mon, 16 Oct 2017 18:51:31 +0300 Subject: crypto: x86/sha1-mb - fix panic due to unaligned access From: Andrey Ryabinin <aryabinin(a)virtuozzo.com> commit d041b557792c85677f17e08eee535eafbd6b9aa2 upstream. struct sha1_ctx_mgr allocated in sha1_mb_mod_init() via kzalloc() and later passed in sha1_mb_flusher_mgr_flush_avx2() function where instructions vmovdqa used to access the struct. vmovdqa requires 16-bytes aligned argument, but nothing guarantees that struct sha1_ctx_mgr will have that alignment. Unaligned vmovdqa will generate GP fault. Fix this by replacing vmovdqa with vmovdqu which doesn't have alignment requirements. Fixes: 2249cbb53ead ("crypto: sha-mb - SHA1 multibuffer submit and flush routines for AVX2") Signed-off-by: Andrey Ryabinin <aryabinin(a)virtuozzo.com> Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/x86/crypto/sha-mb/sha1_mb_mgr_flush_avx2.S | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) --- a/arch/x86/crypto/sha-mb/sha1_mb_mgr_flush_avx2.S +++ b/arch/x86/crypto/sha-mb/sha1_mb_mgr_flush_avx2.S @@ -174,8 +174,8 @@ LABEL skip_ %I .endr # Find min length - vmovdqa _lens+0*16(state), %xmm0 - vmovdqa _lens+1*16(state), %xmm1 + vmovdqu _lens+0*16(state), %xmm0 + vmovdqu _lens+1*16(state), %xmm1 vpminud %xmm1, %xmm0, %xmm2 # xmm2 has {D,C,B,A} vpalignr $8, %xmm2, %xmm3, %xmm3 # xmm3 has {x,x,D,C} @@ -195,8 +195,8 @@ LABEL skip_ %I vpsubd %xmm2, %xmm0, %xmm0 vpsubd %xmm2, %xmm1, %xmm1 - vmovdqa %xmm0, _lens+0*16(state) - vmovdqa %xmm1, _lens+1*16(state) + vmovdqu %xmm0, _lens+0*16(state) + vmovdqu %xmm1, _lens+1*16(state) # "state" and "args" are the same address, arg1 # len is arg2 @@ -260,8 +260,8 @@ ENTRY(sha1_mb_mgr_get_comp_job_avx2) jc .return_null # Find min length - vmovdqa _lens(state), %xmm0 - vmovdqa _lens+1*16(state), %xmm1 + vmovdqu _lens(state), %xmm0 + vmovdqu _lens+1*16(state), %xmm1 vpminud %xmm1, %xmm0, %xmm2 # xmm2 has {D,C,B,A} vpalignr $8, %xmm2, %xmm3, %xmm3 # xmm3 has {x,x,D,C} Patches currently in stable-queue which might be from aryabinin(a)virtuozzo.com are queue-3.18/crypto-x86-sha1-mb-fix-panic-due-to-unaligned-access.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "ARM: 8720/1: ensure dump_instr() checks addr_limit" 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 ARM: 8720/1: ensure dump_instr() checks addr_limit 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: arm-8720-1-ensure-dump_instr-checks-addr_limit.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 b9dd05c7002ee0ca8b676428b2268c26399b5e31 Mon Sep 17 00:00:00 2001 From: Mark Rutland <mark.rutland(a)arm.com> Date: Thu, 2 Nov 2017 18:44:28 +0100 Subject: ARM: 8720/1: ensure dump_instr() checks addr_limit From: Mark Rutland <mark.rutland(a)arm.com> commit b9dd05c7002ee0ca8b676428b2268c26399b5e31 upstream. When CONFIG_DEBUG_USER is enabled, it's possible for a user to deliberately trigger dump_instr() with a chosen kernel address. Let's avoid problems resulting from this by using get_user() rather than __get_user(), ensuring that we don't erroneously access kernel memory. So that we can use the same code to dump user instructions and kernel instructions, the common dumping code is factored out to __dump_instr(), with the fs manipulated appropriately in dump_instr() around calls to this. Signed-off-by: Mark Rutland <mark.rutland(a)arm.com> Signed-off-by: Russell King <rmk+kernel(a)armlinux.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/arm/kernel/traps.c | 28 ++++++++++++++++++---------- 1 file changed, 18 insertions(+), 10 deletions(-) --- a/arch/arm/kernel/traps.c +++ b/arch/arm/kernel/traps.c @@ -132,30 +132,26 @@ static void dump_mem(const char *lvl, co set_fs(fs); } -static void dump_instr(const char *lvl, struct pt_regs *regs) +static void __dump_instr(const char *lvl, struct pt_regs *regs) { unsigned long addr = instruction_pointer(regs); const int thumb = thumb_mode(regs); const int width = thumb ? 4 : 8; - mm_segment_t fs; char str[sizeof("00000000 ") * 5 + 2 + 1], *p = str; int i; /* - * We need to switch to kernel mode so that we can use __get_user - * to safely read from kernel space. Note that we now dump the - * code first, just in case the backtrace kills us. + * Note that we now dump the code first, just in case the backtrace + * kills us. */ - fs = get_fs(); - set_fs(KERNEL_DS); for (i = -4; i < 1 + !!thumb; i++) { unsigned int val, bad; if (thumb) - bad = __get_user(val, &((u16 *)addr)[i]); + bad = get_user(val, &((u16 *)addr)[i]); else - bad = __get_user(val, &((u32 *)addr)[i]); + bad = get_user(val, &((u32 *)addr)[i]); if (!bad) p += sprintf(p, i == 0 ? "(%0*x) " : "%0*x ", @@ -166,8 +162,20 @@ static void dump_instr(const char *lvl, } } printk("%sCode: %s\n", lvl, str); +} - set_fs(fs); +static void dump_instr(const char *lvl, struct pt_regs *regs) +{ + mm_segment_t fs; + + if (!user_mode(regs)) { + fs = get_fs(); + set_fs(KERNEL_DS); + __dump_instr(lvl, regs); + set_fs(fs); + } else { + __dump_instr(lvl, regs); + } } #ifdef CONFIG_ARM_UNWIND Patches currently in stable-queue which might be from mark.rutland(a)arm.com are queue-3.18/arm-8720-1-ensure-dump_instr-checks-addr_limit.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "ALSA: seq: Fix OSS sysex delivery in OSS emulation" 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 ALSA: seq: Fix OSS sysex delivery in OSS emulation 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: alsa-seq-fix-oss-sysex-delivery-in-oss-emulation.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 132d358b183ac6ad8b3fea32ad5e0663456d18d1 Mon Sep 17 00:00:00 2001 From: Takashi Iwai <tiwai(a)suse.de> Date: Tue, 7 Nov 2017 16:05:24 +0100 Subject: ALSA: seq: Fix OSS sysex delivery in OSS emulation From: Takashi Iwai <tiwai(a)suse.de> commit 132d358b183ac6ad8b3fea32ad5e0663456d18d1 upstream. The SYSEX event delivery in OSS sequencer emulation assumed that the event is encoded in the variable-length data with the straight buffering. This was the normal behavior in the past, but during the development, the chained buffers were introduced for carrying more data, while the OSS code was left intact. As a result, when a SYSEX event with the chained buffer data is passed to OSS sequencer port, it may end up with the wrong memory access, as if it were having a too large buffer. This patch addresses the bug, by applying the buffer data expansion by the generic snd_seq_dump_var_event() helper function. Reported-by: syzbot <syzkaller(a)googlegroups.com> Reported-by: Mark Salyzyn <salyzyn(a)android.com> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- sound/core/seq/oss/seq_oss_midi.c | 4 +--- sound/core/seq/oss/seq_oss_readq.c | 29 +++++++++++++++++++++++++++++ sound/core/seq/oss/seq_oss_readq.h | 2 ++ 3 files changed, 32 insertions(+), 3 deletions(-) --- a/sound/core/seq/oss/seq_oss_midi.c +++ b/sound/core/seq/oss/seq_oss_midi.c @@ -615,9 +615,7 @@ send_midi_event(struct seq_oss_devinfo * if (!dp->timer->running) len = snd_seq_oss_timer_start(dp->timer); if (ev->type == SNDRV_SEQ_EVENT_SYSEX) { - if ((ev->flags & SNDRV_SEQ_EVENT_LENGTH_MASK) == SNDRV_SEQ_EVENT_LENGTH_VARIABLE) - snd_seq_oss_readq_puts(dp->readq, mdev->seq_device, - ev->data.ext.ptr, ev->data.ext.len); + snd_seq_oss_readq_sysex(dp->readq, mdev->seq_device, ev); } else { len = snd_midi_event_decode(mdev->coder, msg, sizeof(msg), ev); if (len > 0) --- a/sound/core/seq/oss/seq_oss_readq.c +++ b/sound/core/seq/oss/seq_oss_readq.c @@ -120,6 +120,35 @@ snd_seq_oss_readq_puts(struct seq_oss_re } /* + * put MIDI sysex bytes; the event buffer may be chained, thus it has + * to be expanded via snd_seq_dump_var_event(). + */ +struct readq_sysex_ctx { + struct seq_oss_readq *readq; + int dev; +}; + +static int readq_dump_sysex(void *ptr, void *buf, int count) +{ + struct readq_sysex_ctx *ctx = ptr; + + return snd_seq_oss_readq_puts(ctx->readq, ctx->dev, buf, count); +} + +int snd_seq_oss_readq_sysex(struct seq_oss_readq *q, int dev, + struct snd_seq_event *ev) +{ + struct readq_sysex_ctx ctx = { + .readq = q, + .dev = dev + }; + + if ((ev->flags & SNDRV_SEQ_EVENT_LENGTH_MASK) != SNDRV_SEQ_EVENT_LENGTH_VARIABLE) + return 0; + return snd_seq_dump_var_event(ev, readq_dump_sysex, &ctx); +} + +/* * copy an event to input queue: * return zero if enqueued */ --- a/sound/core/seq/oss/seq_oss_readq.h +++ b/sound/core/seq/oss/seq_oss_readq.h @@ -44,6 +44,8 @@ void snd_seq_oss_readq_delete(struct seq void snd_seq_oss_readq_clear(struct seq_oss_readq *readq); unsigned int snd_seq_oss_readq_poll(struct seq_oss_readq *readq, struct file *file, poll_table *wait); int snd_seq_oss_readq_puts(struct seq_oss_readq *readq, int dev, unsigned char *data, int len); +int snd_seq_oss_readq_sysex(struct seq_oss_readq *q, int dev, + struct snd_seq_event *ev); int snd_seq_oss_readq_put_event(struct seq_oss_readq *readq, union evrec *ev); int snd_seq_oss_readq_put_timestamp(struct seq_oss_readq *readq, unsigned long curt, int seq_mode); int snd_seq_oss_readq_pick(struct seq_oss_readq *q, union evrec *rec); Patches currently in stable-queue which might be from tiwai(a)suse.de are queue-3.18/alsa-seq-avoid-invalid-lockdep-class-warning.patch queue-3.18/alsa-seq-fix-oss-sysex-delivery-in-oss-emulation.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "ALSA: seq: Avoid invalid lockdep class warning" 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 ALSA: seq: Avoid invalid lockdep class warning 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: alsa-seq-avoid-invalid-lockdep-class-warning.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 3510c7aa069aa83a2de6dab2b41401a198317bdc Mon Sep 17 00:00:00 2001 From: Takashi Iwai <tiwai(a)suse.de> Date: Mon, 6 Nov 2017 20:16:50 +0100 Subject: ALSA: seq: Avoid invalid lockdep class warning From: Takashi Iwai <tiwai(a)suse.de> commit 3510c7aa069aa83a2de6dab2b41401a198317bdc upstream. The recent fix for adding rwsem nesting annotation was using the given "hop" argument as the lock subclass key. Although the idea itself works, it may trigger a kernel warning like: BUG: looking up invalid subclass: 8 .... since the lockdep has a smaller number of subclasses (8) than we currently allow for the hops there (10). The current definition is merely a sanity check for avoiding the too deep delivery paths, and the 8 hops are already enough. So, as a quick fix, just follow the max hops as same as the max lockdep subclasses. Fixes: 1f20f9ff57ca ("ALSA: seq: Fix nested rwsem annotation for lockdep splat") Reported-by: syzbot <syzkaller(a)googlegroups.com> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/sound/seq_kernel.h | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/include/sound/seq_kernel.h +++ b/include/sound/seq_kernel.h @@ -55,7 +55,8 @@ typedef union snd_seq_timestamp snd_seq_ #define SNDRV_SEQ_DEFAULT_CLIENT_EVENTS 200 /* max delivery path length */ -#define SNDRV_SEQ_MAX_HOPS 10 +/* NOTE: this shouldn't be greater than MAX_LOCKDEP_SUBCLASSES */ +#define SNDRV_SEQ_MAX_HOPS 8 /* max size of event size */ #define SNDRV_SEQ_MAX_EVENT_LEN 0x3fffffff Patches currently in stable-queue which might be from tiwai(a)suse.de are queue-3.18/alsa-seq-avoid-invalid-lockdep-class-warning.patch queue-3.18/alsa-seq-fix-oss-sysex-delivery-in-oss-emulation.patch

7 years, 7 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH BACKPORT 4.1..4.9] MIPS: SMP: Fix deadlock & online race

by Greg KH

On Mon, Nov 06, 2017 at 09:15:14PM +0000, James Hogan wrote: > From: Matt Redfearn <matt.redfearn(a)imgtec.com> > > commit 9e8c399a88f0b87e41a894911475ed2a8f8dff9e upstream. > > Commit 6f542ebeaee0 ("MIPS: Fix race on setting and getting > cpu_online_mask") effectively reverted commit 8f46cca1e6c06 ("MIPS: SMP: > Fix possibility of deadlock when bringing CPUs online") and thus has > reinstated the possibility of deadlock. > > The commit was based on testing of kernel v4.4, where the CPU hotplug > core code issued a BUG() if the starting CPU is not marked online when > the boot CPU returns from __cpu_up. The commit fixes this race (in > v4.4), but re-introduces the deadlock situation. > > As noted in the commit message, upstream differs in this area. Commit > 8df3e07e7f21f ("cpu/hotplug: Let upcoming cpu bring itself fully up") > adds a completion event in the CPU hotplug core code, making this race > impossible. However, people were unhappy with relying on the core code > to do the right thing. > > To address the issues both commits were trying to fix, add a second > completion event in the MIPS smp hotplug path. It removes the > possibility of a race, since the MIPS smp hotplug code now synchronises > both the boot and secondary CPUs before they return to the hotplug core > code. It also addresses the deadlock by ensuring that the secondary CPU > is not marked online before it's counters are synchronised. > > This fix should also be backported to fix the race condition introduced > by the backport of commit 8f46cca1e6c06 ("MIPS: SMP: Fix possibility of > deadlock when bringing CPUs online"), through really that race only > existed before commit 8df3e07e7f21f ("cpu/hotplug: Let upcoming cpu > bring itself fully up"). > > Signed-off-by: Matt Redfearn <matt.redfearn(a)imgtec.com> > Fixes: 6f542ebeaee0 ("MIPS: Fix race on setting and getting cpu_online_mask") > CC: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext(a)nokia.com> > Cc: <stable(a)vger.kernel.org> # v4.1+: 8f46cca1e6c0: "MIPS: SMP: Fix possibility of deadlock when bringing CPUs online" > Cc: <stable(a)vger.kernel.org> # v4.1+: a00eeede507c: "MIPS: SMP: Use a completion event to signal CPU up" > Cc: <stable(a)vger.kernel.org> # v4.1+: 6f542ebeaee0: "MIPS: Fix race on setting and getting cpu_online_mask" These did not apply to 3.18, so this patch overall did not apply there either. I don't know if you care about 3.18, but if so, can you provide backports of these for that tree, and then resend this patch so I can queue it up? thanks, greg k-h

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH] USB: fix buffer overflows with parsing CDC headers

by Oliver Neukum

In newer kernels this issue has been fixed at a central location with commit 2e1c42391ff2556387b3cb6308b24f6f65619feb Author: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Date: Thu Sep 21 16:58:48 2017 +0200 USB: core: harden cdc_parse_cdc_header on anything older the parsing had not been centralised, so a separate fix for each driver is necessary. Signed-off-by: Oliver Neukum <oneukum(a)suse.com> --- drivers/net/usb/cdc_ether.c | 9 ++++++++- drivers/usb/class/cdc-acm.c | 8 +++++++- drivers/usb/class/cdc-wdm.c | 2 ++ 3 files changed, 17 insertions(+), 2 deletions(-) diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c index 3651f3cd474e..0f2fde0820dd 100644 --- a/drivers/net/usb/cdc_ether.c +++ b/drivers/net/usb/cdc_ether.c @@ -144,6 +144,8 @@ int usbnet_generic_cdc_bind(struct usbnet *dev, struct usb_interface *intf) dev_dbg(&intf->dev, "extra CDC header\n"); goto bad_desc; } + if (len < sizeof(struct usb_cdc_header_desc)) + break; info->header = (void *) buf; if (info->header->bLength != sizeof(*info->header)) { dev_dbg(&intf->dev, "CDC header len %u\n", @@ -157,6 +159,8 @@ int usbnet_generic_cdc_bind(struct usbnet *dev, struct usb_interface *intf) */ if (rndis) { struct usb_cdc_acm_descriptor *acm; + if (len < sizeof(struct usb_cdc_acm_descriptor)) + break; acm = (void *) buf; if (acm->bmCapabilities) { @@ -173,6 +177,8 @@ int usbnet_generic_cdc_bind(struct usbnet *dev, struct usb_interface *intf) dev_dbg(&intf->dev, "extra CDC union\n"); goto bad_desc; } + if (len < sizeof(struct usb_cdc_union_desc)) + break; info->u = (void *) buf; if (info->u->bLength != sizeof(*info->u)) { dev_dbg(&intf->dev, "CDC union len %u\n", @@ -231,6 +237,8 @@ int usbnet_generic_cdc_bind(struct usbnet *dev, struct usb_interface *intf) dev_dbg(&intf->dev, "extra CDC ether\n"); goto bad_desc; } + if (len < sizeof(struct usb_cdc_ether_desc)) + break; info->ether = (void *) buf; if (info->ether->bLength != sizeof(*info->ether)) { dev_dbg(&intf->dev, "CDC ether len %u\n", @@ -248,7 +256,6 @@ int usbnet_generic_cdc_bind(struct usbnet *dev, struct usb_interface *intf) dev_dbg(&intf->dev, "extra MDLM descriptor\n"); goto bad_desc; } - desc = (void *)buf; if (desc->bLength != sizeof(*desc)) diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c index ea93b35b1c6d..8957ee57f62d 100644 --- a/drivers/usb/class/cdc-acm.c +++ b/drivers/usb/class/cdc-acm.c @@ -1019,7 +1019,7 @@ static int acm_probe(struct usb_interface *intf, } } - while (buflen > 0) { + while (buflen >= 3) { /* minimum length making sense */ if (buffer[1] != USB_DT_CS_INTERFACE) { dev_err(&intf->dev, "skipping garbage\n"); goto next_desc; @@ -1027,6 +1027,8 @@ static int acm_probe(struct usb_interface *intf, switch (buffer[2]) { case USB_CDC_UNION_TYPE: /* we've found it */ + if (buflen < sizeof(struct usb_cdc_union_desc)) + break; if (union_header) { dev_err(&intf->dev, "More than one " "union descriptor, skipping ...\n"); @@ -1035,6 +1037,8 @@ static int acm_probe(struct usb_interface *intf, union_header = (struct usb_cdc_union_desc *)buffer; break; case USB_CDC_COUNTRY_TYPE: /* export through sysfs*/ + if (buflen < sizeof(struct usb_cdc_country_functional_desc)) + break; cfd = (struct usb_cdc_country_functional_desc *)buffer; break; case USB_CDC_HEADER_TYPE: /* maybe check version */ @@ -1043,6 +1047,8 @@ static int acm_probe(struct usb_interface *intf, ac_management_function = buffer[3]; break; case USB_CDC_CALL_MANAGEMENT_TYPE: + if (buflen < 4) + break; call_management_function = buffer[3]; call_interface_num = buffer[4]; if ((quirks & NOT_A_MODEM) == 0 && (call_management_function & 3) != 3) diff --git a/drivers/usb/class/cdc-wdm.c b/drivers/usb/class/cdc-wdm.c index 07133d0c971b..f61b5e138bc7 100644 --- a/drivers/usb/class/cdc-wdm.c +++ b/drivers/usb/class/cdc-wdm.c @@ -851,6 +851,8 @@ static int wdm_probe(struct usb_interface *intf, const struct usb_device_id *id) case USB_CDC_HEADER_TYPE: break; case USB_CDC_DMM_TYPE: + if (buflen < sizeof(struct usb_cdc_dmm_desc)) + break; dmhd = (struct usb_cdc_dmm_desc *)buffer; maxcom = le16_to_cpu(dmhd->wMaxCommand); dev_dbg(&intf->dev, -- 2.13.6

7 years, 7 months

2
1
0 0

[Linux-stable-mirror] FAILED: patch "[PATCH] ALSA: timer: Limit max instances per timer" failed to apply to 3.18-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 3.18-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 9b7d869ee5a77ed4a462372bb89af622e705bfb8 Mon Sep 17 00:00:00 2001 From: Takashi Iwai <tiwai(a)suse.de> Date: Sun, 5 Nov 2017 10:07:43 +0100 Subject: [PATCH] ALSA: timer: Limit max instances per timer MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Currently we allow unlimited number of timer instances, and it may bring the system hogging way too much CPU when too many timer instances are opened and processed concurrently. This may end up with a soft-lockup report as triggered by syzkaller, especially when hrtimer backend is deployed. Since such insane number of instances aren't demanded by the normal use case of ALSA sequencer and it merely opens a risk only for abuse, this patch introduces the upper limit for the number of instances per timer backend. As default, it's set to 1000, but for the fine-grained timer like hrtimer, it's set to 100. Reported-by: syzbot Tested-by: Jérôme Glisse <jglisse(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> diff --git a/include/sound/timer.h b/include/sound/timer.h index c4d76ff056c6..7ae226ab6990 100644 --- a/include/sound/timer.h +++ b/include/sound/timer.h @@ -90,6 +90,8 @@ struct snd_timer { struct list_head ack_list_head; struct list_head sack_list_head; /* slow ack list head */ struct tasklet_struct task_queue; + int max_instances; /* upper limit of timer instances */ + int num_instances; /* current number of timer instances */ }; struct snd_timer_instance { diff --git a/sound/core/hrtimer.c b/sound/core/hrtimer.c index 1ac0c423903e..6e47b823bcaa 100644 --- a/sound/core/hrtimer.c +++ b/sound/core/hrtimer.c @@ -159,6 +159,7 @@ static int __init snd_hrtimer_init(void) timer->hw = hrtimer_hw; timer->hw.resolution = resolution; timer->hw.ticks = NANO_SEC / resolution; + timer->max_instances = 100; /* lower the limit */ err = snd_timer_global_register(timer); if (err < 0) { diff --git a/sound/core/timer.c b/sound/core/timer.c index 6cdd04a45962..15e82a656d96 100644 --- a/sound/core/timer.c +++ b/sound/core/timer.c @@ -180,7 +180,7 @@ static void snd_timer_request(struct snd_timer_id *tid) * * call this with register_mutex down. */ -static void snd_timer_check_slave(struct snd_timer_instance *slave) +static int snd_timer_check_slave(struct snd_timer_instance *slave) { struct snd_timer *timer; struct snd_timer_instance *master; @@ -190,16 +190,21 @@ static void snd_timer_check_slave(struct snd_timer_instance *slave) list_for_each_entry(master, &timer->open_list_head, open_list) { if (slave->slave_class == master->slave_class && slave->slave_id == master->slave_id) { + if (master->timer->num_instances >= + master->timer->max_instances) + return -EBUSY; list_move_tail(&slave->open_list, &master->slave_list_head); + master->timer->num_instances++; spin_lock_irq(&slave_active_lock); slave->master = master; slave->timer = master->timer; spin_unlock_irq(&slave_active_lock); - return; + return 0; } } } + return 0; } /* @@ -208,7 +213,7 @@ static void snd_timer_check_slave(struct snd_timer_instance *slave) * * call this with register_mutex down. */ -static void snd_timer_check_master(struct snd_timer_instance *master) +static int snd_timer_check_master(struct snd_timer_instance *master) { struct snd_timer_instance *slave, *tmp; @@ -216,7 +221,11 @@ static void snd_timer_check_master(struct snd_timer_instance *master) list_for_each_entry_safe(slave, tmp, &snd_timer_slave_list, open_list) { if (slave->slave_class == master->slave_class && slave->slave_id == master->slave_id) { + if (master->timer->num_instances >= + master->timer->max_instances) + return -EBUSY; list_move_tail(&slave->open_list, &master->slave_list_head); + master->timer->num_instances++; spin_lock_irq(&slave_active_lock); spin_lock(&master->timer->lock); slave->master = master; @@ -228,8 +237,11 @@ static void snd_timer_check_master(struct snd_timer_instance *master) spin_unlock_irq(&slave_active_lock); } } + return 0; } +static int snd_timer_close_locked(struct snd_timer_instance *timeri); + /* * open a timer instance * when opening a master, the slave id must be here given. @@ -240,6 +252,7 @@ int snd_timer_open(struct snd_timer_instance **ti, { struct snd_timer *timer; struct snd_timer_instance *timeri = NULL; + int err; if (tid->dev_class == SNDRV_TIMER_CLASS_SLAVE) { /* open a slave instance */ @@ -259,10 +272,14 @@ int snd_timer_open(struct snd_timer_instance **ti, timeri->slave_id = tid->device; timeri->flags |= SNDRV_TIMER_IFLG_SLAVE; list_add_tail(&timeri->open_list, &snd_timer_slave_list); - snd_timer_check_slave(timeri); + err = snd_timer_check_slave(timeri); + if (err < 0) { + snd_timer_close_locked(timeri); + timeri = NULL; + } mutex_unlock(&register_mutex); *ti = timeri; - return 0; + return err; } /* open a master instance */ @@ -288,6 +305,10 @@ int snd_timer_open(struct snd_timer_instance **ti, return -EBUSY; } } + if (timer->num_instances >= timer->max_instances) { + mutex_unlock(&register_mutex); + return -EBUSY; + } timeri = snd_timer_instance_new(owner, timer); if (!timeri) { mutex_unlock(&register_mutex); @@ -314,25 +335,27 @@ int snd_timer_open(struct snd_timer_instance **ti, } list_add_tail(&timeri->open_list, &timer->open_list_head); - snd_timer_check_master(timeri); + timer->num_instances++; + err = snd_timer_check_master(timeri); + if (err < 0) { + snd_timer_close_locked(timeri); + timeri = NULL; + } mutex_unlock(&register_mutex); *ti = timeri; - return 0; + return err; } EXPORT_SYMBOL(snd_timer_open); /* * close a timer instance + * call this with register_mutex down. */ -int snd_timer_close(struct snd_timer_instance *timeri) +static int snd_timer_close_locked(struct snd_timer_instance *timeri) { struct snd_timer *timer = NULL; struct snd_timer_instance *slave, *tmp; - if (snd_BUG_ON(!timeri)) - return -ENXIO; - - mutex_lock(&register_mutex); list_del(&timeri->open_list); /* force to stop the timer */ @@ -340,6 +363,7 @@ int snd_timer_close(struct snd_timer_instance *timeri) timer = timeri->timer; if (timer) { + timer->num_instances--; /* wait, until the active callback is finished */ spin_lock_irq(&timer->lock); while (timeri->flags & SNDRV_TIMER_IFLG_CALLBACK) { @@ -355,6 +379,7 @@ int snd_timer_close(struct snd_timer_instance *timeri) list_for_each_entry_safe(slave, tmp, &timeri->slave_list_head, open_list) { list_move_tail(&slave->open_list, &snd_timer_slave_list); + timer->num_instances--; slave->master = NULL; slave->timer = NULL; list_del_init(&slave->ack_list); @@ -382,9 +407,24 @@ int snd_timer_close(struct snd_timer_instance *timeri) module_put(timer->module); } - mutex_unlock(&register_mutex); return 0; } + +/* + * close a timer instance + */ +int snd_timer_close(struct snd_timer_instance *timeri) +{ + int err; + + if (snd_BUG_ON(!timeri)) + return -ENXIO; + + mutex_lock(&register_mutex); + err = snd_timer_close_locked(timeri); + mutex_unlock(&register_mutex); + return err; +} EXPORT_SYMBOL(snd_timer_close); unsigned long snd_timer_resolution(struct snd_timer_instance *timeri) @@ -856,6 +896,7 @@ int snd_timer_new(struct snd_card *card, char *id, struct snd_timer_id *tid, spin_lock_init(&timer->lock); tasklet_init(&timer->task_queue, snd_timer_tasklet, (unsigned long)timer); + timer->max_instances = 1000; /* default limit per timer */ if (card != NULL) { timer->module = card->module; err = snd_device_new(card, SNDRV_DEV_TIMER, timer, &ops);

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] FAILED: patch "[PATCH] ALSA: timer: Limit max instances per timer" 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 9b7d869ee5a77ed4a462372bb89af622e705bfb8 Mon Sep 17 00:00:00 2001 From: Takashi Iwai <tiwai(a)suse.de> Date: Sun, 5 Nov 2017 10:07:43 +0100 Subject: [PATCH] ALSA: timer: Limit max instances per timer MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Currently we allow unlimited number of timer instances, and it may bring the system hogging way too much CPU when too many timer instances are opened and processed concurrently. This may end up with a soft-lockup report as triggered by syzkaller, especially when hrtimer backend is deployed. Since such insane number of instances aren't demanded by the normal use case of ALSA sequencer and it merely opens a risk only for abuse, this patch introduces the upper limit for the number of instances per timer backend. As default, it's set to 1000, but for the fine-grained timer like hrtimer, it's set to 100. Reported-by: syzbot Tested-by: Jérôme Glisse <jglisse(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> diff --git a/include/sound/timer.h b/include/sound/timer.h index c4d76ff056c6..7ae226ab6990 100644 --- a/include/sound/timer.h +++ b/include/sound/timer.h @@ -90,6 +90,8 @@ struct snd_timer { struct list_head ack_list_head; struct list_head sack_list_head; /* slow ack list head */ struct tasklet_struct task_queue; + int max_instances; /* upper limit of timer instances */ + int num_instances; /* current number of timer instances */ }; struct snd_timer_instance { diff --git a/sound/core/hrtimer.c b/sound/core/hrtimer.c index 1ac0c423903e..6e47b823bcaa 100644 --- a/sound/core/hrtimer.c +++ b/sound/core/hrtimer.c @@ -159,6 +159,7 @@ static int __init snd_hrtimer_init(void) timer->hw = hrtimer_hw; timer->hw.resolution = resolution; timer->hw.ticks = NANO_SEC / resolution; + timer->max_instances = 100; /* lower the limit */ err = snd_timer_global_register(timer); if (err < 0) { diff --git a/sound/core/timer.c b/sound/core/timer.c index 6cdd04a45962..15e82a656d96 100644 --- a/sound/core/timer.c +++ b/sound/core/timer.c @@ -180,7 +180,7 @@ static void snd_timer_request(struct snd_timer_id *tid) * * call this with register_mutex down. */ -static void snd_timer_check_slave(struct snd_timer_instance *slave) +static int snd_timer_check_slave(struct snd_timer_instance *slave) { struct snd_timer *timer; struct snd_timer_instance *master; @@ -190,16 +190,21 @@ static void snd_timer_check_slave(struct snd_timer_instance *slave) list_for_each_entry(master, &timer->open_list_head, open_list) { if (slave->slave_class == master->slave_class && slave->slave_id == master->slave_id) { + if (master->timer->num_instances >= + master->timer->max_instances) + return -EBUSY; list_move_tail(&slave->open_list, &master->slave_list_head); + master->timer->num_instances++; spin_lock_irq(&slave_active_lock); slave->master = master; slave->timer = master->timer; spin_unlock_irq(&slave_active_lock); - return; + return 0; } } } + return 0; } /* @@ -208,7 +213,7 @@ static void snd_timer_check_slave(struct snd_timer_instance *slave) * * call this with register_mutex down. */ -static void snd_timer_check_master(struct snd_timer_instance *master) +static int snd_timer_check_master(struct snd_timer_instance *master) { struct snd_timer_instance *slave, *tmp; @@ -216,7 +221,11 @@ static void snd_timer_check_master(struct snd_timer_instance *master) list_for_each_entry_safe(slave, tmp, &snd_timer_slave_list, open_list) { if (slave->slave_class == master->slave_class && slave->slave_id == master->slave_id) { + if (master->timer->num_instances >= + master->timer->max_instances) + return -EBUSY; list_move_tail(&slave->open_list, &master->slave_list_head); + master->timer->num_instances++; spin_lock_irq(&slave_active_lock); spin_lock(&master->timer->lock); slave->master = master; @@ -228,8 +237,11 @@ static void snd_timer_check_master(struct snd_timer_instance *master) spin_unlock_irq(&slave_active_lock); } } + return 0; } +static int snd_timer_close_locked(struct snd_timer_instance *timeri); + /* * open a timer instance * when opening a master, the slave id must be here given. @@ -240,6 +252,7 @@ int snd_timer_open(struct snd_timer_instance **ti, { struct snd_timer *timer; struct snd_timer_instance *timeri = NULL; + int err; if (tid->dev_class == SNDRV_TIMER_CLASS_SLAVE) { /* open a slave instance */ @@ -259,10 +272,14 @@ int snd_timer_open(struct snd_timer_instance **ti, timeri->slave_id = tid->device; timeri->flags |= SNDRV_TIMER_IFLG_SLAVE; list_add_tail(&timeri->open_list, &snd_timer_slave_list); - snd_timer_check_slave(timeri); + err = snd_timer_check_slave(timeri); + if (err < 0) { + snd_timer_close_locked(timeri); + timeri = NULL; + } mutex_unlock(&register_mutex); *ti = timeri; - return 0; + return err; } /* open a master instance */ @@ -288,6 +305,10 @@ int snd_timer_open(struct snd_timer_instance **ti, return -EBUSY; } } + if (timer->num_instances >= timer->max_instances) { + mutex_unlock(&register_mutex); + return -EBUSY; + } timeri = snd_timer_instance_new(owner, timer); if (!timeri) { mutex_unlock(&register_mutex); @@ -314,25 +335,27 @@ int snd_timer_open(struct snd_timer_instance **ti, } list_add_tail(&timeri->open_list, &timer->open_list_head); - snd_timer_check_master(timeri); + timer->num_instances++; + err = snd_timer_check_master(timeri); + if (err < 0) { + snd_timer_close_locked(timeri); + timeri = NULL; + } mutex_unlock(&register_mutex); *ti = timeri; - return 0; + return err; } EXPORT_SYMBOL(snd_timer_open); /* * close a timer instance + * call this with register_mutex down. */ -int snd_timer_close(struct snd_timer_instance *timeri) +static int snd_timer_close_locked(struct snd_timer_instance *timeri) { struct snd_timer *timer = NULL; struct snd_timer_instance *slave, *tmp; - if (snd_BUG_ON(!timeri)) - return -ENXIO; - - mutex_lock(&register_mutex); list_del(&timeri->open_list); /* force to stop the timer */ @@ -340,6 +363,7 @@ int snd_timer_close(struct snd_timer_instance *timeri) timer = timeri->timer; if (timer) { + timer->num_instances--; /* wait, until the active callback is finished */ spin_lock_irq(&timer->lock); while (timeri->flags & SNDRV_TIMER_IFLG_CALLBACK) { @@ -355,6 +379,7 @@ int snd_timer_close(struct snd_timer_instance *timeri) list_for_each_entry_safe(slave, tmp, &timeri->slave_list_head, open_list) { list_move_tail(&slave->open_list, &snd_timer_slave_list); + timer->num_instances--; slave->master = NULL; slave->timer = NULL; list_del_init(&slave->ack_list); @@ -382,9 +407,24 @@ int snd_timer_close(struct snd_timer_instance *timeri) module_put(timer->module); } - mutex_unlock(&register_mutex); return 0; } + +/* + * close a timer instance + */ +int snd_timer_close(struct snd_timer_instance *timeri) +{ + int err; + + if (snd_BUG_ON(!timeri)) + return -ENXIO; + + mutex_lock(&register_mutex); + err = snd_timer_close_locked(timeri); + mutex_unlock(&register_mutex); + return err; +} EXPORT_SYMBOL(snd_timer_close); unsigned long snd_timer_resolution(struct snd_timer_instance *timeri) @@ -856,6 +896,7 @@ int snd_timer_new(struct snd_card *card, char *id, struct snd_timer_id *tid, spin_lock_init(&timer->lock); tasklet_init(&timer->task_queue, snd_timer_tasklet, (unsigned long)timer); + timer->max_instances = 1000; /* default limit per timer */ if (card != NULL) { timer->module = card->module; err = snd_device_new(card, SNDRV_DEV_TIMER, timer, &ops);

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] FAILED: patch "[PATCH] ALSA: timer: Limit max instances per timer" 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 9b7d869ee5a77ed4a462372bb89af622e705bfb8 Mon Sep 17 00:00:00 2001 From: Takashi Iwai <tiwai(a)suse.de> Date: Sun, 5 Nov 2017 10:07:43 +0100 Subject: [PATCH] ALSA: timer: Limit max instances per timer MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Currently we allow unlimited number of timer instances, and it may bring the system hogging way too much CPU when too many timer instances are opened and processed concurrently. This may end up with a soft-lockup report as triggered by syzkaller, especially when hrtimer backend is deployed. Since such insane number of instances aren't demanded by the normal use case of ALSA sequencer and it merely opens a risk only for abuse, this patch introduces the upper limit for the number of instances per timer backend. As default, it's set to 1000, but for the fine-grained timer like hrtimer, it's set to 100. Reported-by: syzbot Tested-by: Jérôme Glisse <jglisse(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai(a)suse.de> diff --git a/include/sound/timer.h b/include/sound/timer.h index c4d76ff056c6..7ae226ab6990 100644 --- a/include/sound/timer.h +++ b/include/sound/timer.h @@ -90,6 +90,8 @@ struct snd_timer { struct list_head ack_list_head; struct list_head sack_list_head; /* slow ack list head */ struct tasklet_struct task_queue; + int max_instances; /* upper limit of timer instances */ + int num_instances; /* current number of timer instances */ }; struct snd_timer_instance { diff --git a/sound/core/hrtimer.c b/sound/core/hrtimer.c index 1ac0c423903e..6e47b823bcaa 100644 --- a/sound/core/hrtimer.c +++ b/sound/core/hrtimer.c @@ -159,6 +159,7 @@ static int __init snd_hrtimer_init(void) timer->hw = hrtimer_hw; timer->hw.resolution = resolution; timer->hw.ticks = NANO_SEC / resolution; + timer->max_instances = 100; /* lower the limit */ err = snd_timer_global_register(timer); if (err < 0) { diff --git a/sound/core/timer.c b/sound/core/timer.c index 6cdd04a45962..15e82a656d96 100644 --- a/sound/core/timer.c +++ b/sound/core/timer.c @@ -180,7 +180,7 @@ static void snd_timer_request(struct snd_timer_id *tid) * * call this with register_mutex down. */ -static void snd_timer_check_slave(struct snd_timer_instance *slave) +static int snd_timer_check_slave(struct snd_timer_instance *slave) { struct snd_timer *timer; struct snd_timer_instance *master; @@ -190,16 +190,21 @@ static void snd_timer_check_slave(struct snd_timer_instance *slave) list_for_each_entry(master, &timer->open_list_head, open_list) { if (slave->slave_class == master->slave_class && slave->slave_id == master->slave_id) { + if (master->timer->num_instances >= + master->timer->max_instances) + return -EBUSY; list_move_tail(&slave->open_list, &master->slave_list_head); + master->timer->num_instances++; spin_lock_irq(&slave_active_lock); slave->master = master; slave->timer = master->timer; spin_unlock_irq(&slave_active_lock); - return; + return 0; } } } + return 0; } /* @@ -208,7 +213,7 @@ static void snd_timer_check_slave(struct snd_timer_instance *slave) * * call this with register_mutex down. */ -static void snd_timer_check_master(struct snd_timer_instance *master) +static int snd_timer_check_master(struct snd_timer_instance *master) { struct snd_timer_instance *slave, *tmp; @@ -216,7 +221,11 @@ static void snd_timer_check_master(struct snd_timer_instance *master) list_for_each_entry_safe(slave, tmp, &snd_timer_slave_list, open_list) { if (slave->slave_class == master->slave_class && slave->slave_id == master->slave_id) { + if (master->timer->num_instances >= + master->timer->max_instances) + return -EBUSY; list_move_tail(&slave->open_list, &master->slave_list_head); + master->timer->num_instances++; spin_lock_irq(&slave_active_lock); spin_lock(&master->timer->lock); slave->master = master; @@ -228,8 +237,11 @@ static void snd_timer_check_master(struct snd_timer_instance *master) spin_unlock_irq(&slave_active_lock); } } + return 0; } +static int snd_timer_close_locked(struct snd_timer_instance *timeri); + /* * open a timer instance * when opening a master, the slave id must be here given. @@ -240,6 +252,7 @@ int snd_timer_open(struct snd_timer_instance **ti, { struct snd_timer *timer; struct snd_timer_instance *timeri = NULL; + int err; if (tid->dev_class == SNDRV_TIMER_CLASS_SLAVE) { /* open a slave instance */ @@ -259,10 +272,14 @@ int snd_timer_open(struct snd_timer_instance **ti, timeri->slave_id = tid->device; timeri->flags |= SNDRV_TIMER_IFLG_SLAVE; list_add_tail(&timeri->open_list, &snd_timer_slave_list); - snd_timer_check_slave(timeri); + err = snd_timer_check_slave(timeri); + if (err < 0) { + snd_timer_close_locked(timeri); + timeri = NULL; + } mutex_unlock(&register_mutex); *ti = timeri; - return 0; + return err; } /* open a master instance */ @@ -288,6 +305,10 @@ int snd_timer_open(struct snd_timer_instance **ti, return -EBUSY; } } + if (timer->num_instances >= timer->max_instances) { + mutex_unlock(&register_mutex); + return -EBUSY; + } timeri = snd_timer_instance_new(owner, timer); if (!timeri) { mutex_unlock(&register_mutex); @@ -314,25 +335,27 @@ int snd_timer_open(struct snd_timer_instance **ti, } list_add_tail(&timeri->open_list, &timer->open_list_head); - snd_timer_check_master(timeri); + timer->num_instances++; + err = snd_timer_check_master(timeri); + if (err < 0) { + snd_timer_close_locked(timeri); + timeri = NULL; + } mutex_unlock(&register_mutex); *ti = timeri; - return 0; + return err; } EXPORT_SYMBOL(snd_timer_open); /* * close a timer instance + * call this with register_mutex down. */ -int snd_timer_close(struct snd_timer_instance *timeri) +static int snd_timer_close_locked(struct snd_timer_instance *timeri) { struct snd_timer *timer = NULL; struct snd_timer_instance *slave, *tmp; - if (snd_BUG_ON(!timeri)) - return -ENXIO; - - mutex_lock(&register_mutex); list_del(&timeri->open_list); /* force to stop the timer */ @@ -340,6 +363,7 @@ int snd_timer_close(struct snd_timer_instance *timeri) timer = timeri->timer; if (timer) { + timer->num_instances--; /* wait, until the active callback is finished */ spin_lock_irq(&timer->lock); while (timeri->flags & SNDRV_TIMER_IFLG_CALLBACK) { @@ -355,6 +379,7 @@ int snd_timer_close(struct snd_timer_instance *timeri) list_for_each_entry_safe(slave, tmp, &timeri->slave_list_head, open_list) { list_move_tail(&slave->open_list, &snd_timer_slave_list); + timer->num_instances--; slave->master = NULL; slave->timer = NULL; list_del_init(&slave->ack_list); @@ -382,9 +407,24 @@ int snd_timer_close(struct snd_timer_instance *timeri) module_put(timer->module); } - mutex_unlock(&register_mutex); return 0; } + +/* + * close a timer instance + */ +int snd_timer_close(struct snd_timer_instance *timeri) +{ + int err; + + if (snd_BUG_ON(!timeri)) + return -ENXIO; + + mutex_lock(&register_mutex); + err = snd_timer_close_locked(timeri); + mutex_unlock(&register_mutex); + return err; +} EXPORT_SYMBOL(snd_timer_close); unsigned long snd_timer_resolution(struct snd_timer_instance *timeri) @@ -856,6 +896,7 @@ int snd_timer_new(struct snd_card *card, char *id, struct snd_timer_id *tid, spin_lock_init(&timer->lock); tasklet_init(&timer->task_queue, snd_timer_tasklet, (unsigned long)timer); + timer->max_instances = 1000; /* default limit per timer */ if (card != NULL) { timer->module = card->module; err = snd_device_new(card, SNDRV_DEV_TIMER, timer, &ops);

7 years, 7 months

1
0
0 0

Re: [Linux-stable-mirror] Backport of ACPI GPE fixes for v4.13

by Greg KH

On Mon, Nov 06, 2017 at 12:11:36PM +0200, Mika Westerberg wrote: > Hi, > > Currently there is an issue in v4.13 where booting system with > Thunderbolt device connected causes problems. Typically the device will > not be tunneled properly and will not function as expected. > > The issue has been root caused to the way Linux initializes and handles > ACPI GPEs (General Purpose Events). In summary we enable them too late > and that results the PCI core finds upstream PCIe port of the > Thunderbolt host controller too early (it is not fully configured by the > BIOS SMI handler yet). > > This has been fixed in mainline starting from v4.14-rc1 by the following > commits: > > ecc1165b8b74 ("ACPICA: Dispatch active GPEs at init time") > 1312b7e0caca ("ACPICA: Make it possible to enable runtime GPEs earlier") > eb7f43c4adb4 ("ACPI / scan: Enable GPEs before scanning the namespace") > > In order to get Thunderbolt working even when there is a device > connected during boot, can the above 3 commits be included in stable for > v4.13? Now all queued up, thanks. greg k-h

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH 4/4] can: ifi: Fix transmitter delay calculation

by Marc Kleine-Budde

From: Marek Vasut <marex(a)denx.de> The CANFD transmitter delay calculation formula was updated in the latest software drop from IFI and improves the behavior of the IFI CANFD core during bitrate switching. Use the new formula to improve stability of the CANFD operation. Signed-off-by: Marek Vasut <marex(a)denx.de> Cc: Markus Marb <markus(a)marb.org> Cc: linux-stable <stable(a)vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> --- drivers/net/can/ifi_canfd/ifi_canfd.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/can/ifi_canfd/ifi_canfd.c b/drivers/net/can/ifi_canfd/ifi_canfd.c index 4d1fe8d95042..2772d05ff11c 100644 --- a/drivers/net/can/ifi_canfd/ifi_canfd.c +++ b/drivers/net/can/ifi_canfd/ifi_canfd.c @@ -670,9 +670,9 @@ static void ifi_canfd_set_bittiming(struct net_device *ndev) priv->base + IFI_CANFD_FTIME); /* Configure transmitter delay */ - tdc = (dbt->brp * (dbt->phase_seg1 + 1)) & IFI_CANFD_TDELAY_MASK; - writel(IFI_CANFD_TDELAY_EN | IFI_CANFD_TDELAY_ABS | tdc, - priv->base + IFI_CANFD_TDELAY); + tdc = dbt->brp * (dbt->prop_seg + dbt->phase_seg1); + tdc &= IFI_CANFD_TDELAY_MASK; + writel(IFI_CANFD_TDELAY_EN | tdc, priv->base + IFI_CANFD_TDELAY); } static void ifi_canfd_set_filter(struct net_device *ndev, const u32 id, -- 2.15.0

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH 3/4] can: peak: Add support for new PCIe/M2 CAN FD interfaces

by Marc Kleine-Budde

From: Stephane Grosjean <s.grosjean(a)peak-system.com> This adds support for the following PEAK-System CAN FD interfaces: PCAN-cPCIe FD CAN FD Interface for cPCI Serial (2 or 4 channels) PCAN-PCIe/104-Express CAN FD Interface for PCIe/104-Express (1, 2 or 4 ch.) PCAN-miniPCIe FD CAN FD Interface for PCIe Mini (1, 2 or 4 channels) PCAN-PCIe FD OEM CAN FD Interface for PCIe OEM version (1, 2 or 4 ch.) PCAN-M.2 CAN FD Interface for M.2 (1 or 2 channels) Like the PCAN-PCIe FD interface, all of these boards run the same IP Core that is able to handle CAN FD (see also http://www.peak-system.com). Signed-off-by: Stephane Grosjean <s.grosjean(a)peak-system.com> Cc: linux-stable <stable(a)vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> --- drivers/net/can/peak_canfd/peak_pciefd_main.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/drivers/net/can/peak_canfd/peak_pciefd_main.c b/drivers/net/can/peak_canfd/peak_pciefd_main.c index 51c2d182a33a..b4efd711f824 100644 --- a/drivers/net/can/peak_canfd/peak_pciefd_main.c +++ b/drivers/net/can/peak_canfd/peak_pciefd_main.c @@ -29,14 +29,19 @@ #include "peak_canfd_user.h" MODULE_AUTHOR("Stephane Grosjean <s.grosjean(a)peak-system.com>"); -MODULE_DESCRIPTION("Socket-CAN driver for PEAK PCAN PCIe FD family cards"); -MODULE_SUPPORTED_DEVICE("PEAK PCAN PCIe FD CAN cards"); +MODULE_DESCRIPTION("Socket-CAN driver for PEAK PCAN PCIe/M.2 FD family cards"); +MODULE_SUPPORTED_DEVICE("PEAK PCAN PCIe/M.2 FD CAN cards"); MODULE_LICENSE("GPL v2"); #define PCIEFD_DRV_NAME "peak_pciefd" #define PEAK_PCI_VENDOR_ID 0x001c /* The PCI device and vendor IDs */ #define PEAK_PCIEFD_ID 0x0013 /* for PCIe slot cards */ +#define PCAN_CPCIEFD_ID 0x0014 /* for Compact-PCI Serial slot cards */ +#define PCAN_PCIE104FD_ID 0x0017 /* for PCIe-104 Express slot cards */ +#define PCAN_MINIPCIEFD_ID 0x0018 /* for mini-PCIe slot cards */ +#define PCAN_PCIEFD_OEM_ID 0x0019 /* for PCIe slot OEM cards */ +#define PCAN_M2_ID 0x001a /* for M2 slot cards */ /* PEAK PCIe board access description */ #define PCIEFD_BAR0_SIZE (64 * 1024) @@ -203,6 +208,11 @@ struct pciefd_board { /* supported device ids. */ static const struct pci_device_id peak_pciefd_tbl[] = { {PEAK_PCI_VENDOR_ID, PEAK_PCIEFD_ID, PCI_ANY_ID, PCI_ANY_ID,}, + {PEAK_PCI_VENDOR_ID, PCAN_CPCIEFD_ID, PCI_ANY_ID, PCI_ANY_ID,}, + {PEAK_PCI_VENDOR_ID, PCAN_PCIE104FD_ID, PCI_ANY_ID, PCI_ANY_ID,}, + {PEAK_PCI_VENDOR_ID, PCAN_MINIPCIEFD_ID, PCI_ANY_ID, PCI_ANY_ID,}, + {PEAK_PCI_VENDOR_ID, PCAN_PCIEFD_OEM_ID, PCI_ANY_ID, PCI_ANY_ID,}, + {PEAK_PCI_VENDOR_ID, PCAN_M2_ID, PCI_ANY_ID, PCI_ANY_ID,}, {0,} }; -- 2.15.0

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH 2/4] can: sun4i: handle overrun in RX FIFO

by Marc Kleine-Budde

From: Gerhard Bertelsmann <info(a)gerhard-bertelsmann.de> SUN4Is CAN IP has a 64 byte deep FIFO buffer. If the buffer is not drained fast enough (overrun) it's getting mangled. Already received frames are dropped - the data can't be restored. Signed-off-by: Gerhard Bertelsmann <info(a)gerhard-bertelsmann.de> Cc: linux-stable <stable(a)vger.kernel.org> Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> --- drivers/net/can/sun4i_can.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/drivers/net/can/sun4i_can.c b/drivers/net/can/sun4i_can.c index b0c80859f746..1ac2090a1721 100644 --- a/drivers/net/can/sun4i_can.c +++ b/drivers/net/can/sun4i_can.c @@ -539,6 +539,13 @@ static int sun4i_can_err(struct net_device *dev, u8 isrc, u8 status) } stats->rx_over_errors++; stats->rx_errors++; + + /* reset the CAN IP by entering reset mode + * ignoring timeout error + */ + set_reset_mode(dev); + set_normal_mode(dev); + /* clear bit */ sun4i_can_write_cmdreg(priv, SUN4I_CMD_CLEAR_OR_FLAG); } @@ -653,8 +660,9 @@ static irqreturn_t sun4i_can_interrupt(int irq, void *dev_id) netif_wake_queue(dev); can_led_event(dev, CAN_LED_EVENT_TX); } - if (isrc & SUN4I_INT_RBUF_VLD) { - /* receive interrupt */ + if ((isrc & SUN4I_INT_RBUF_VLD) && + !(isrc & SUN4I_INT_DATA_OR)) { + /* receive interrupt - don't read if overrun occurred */ while (status & SUN4I_STA_RBUF_RDY) { /* RX buffer is not empty */ sun4i_can_rx(dev); -- 2.15.0

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH 1/4] can: c_can: don't indicate triple sampling support for D_CAN

by Marc Kleine-Budde

From: Richard Schütz <rschuetz(a)uni-koblenz.de> The D_CAN controller doesn't provide a triple sampling mode, so don't set the CAN_CTRLMODE_3_SAMPLES flag in ctrlmode_supported. Currently enabling triple sampling is a no-op. Signed-off-by: Richard Schütz <rschuetz(a)uni-koblenz.de> Cc: linux-stable <stable(a)vger.kernel.org> # >= v3.6 Signed-off-by: Marc Kleine-Budde <mkl(a)pengutronix.de> --- drivers/net/can/c_can/c_can_pci.c | 1 - drivers/net/can/c_can/c_can_platform.c | 1 - 2 files changed, 2 deletions(-) diff --git a/drivers/net/can/c_can/c_can_pci.c b/drivers/net/can/c_can/c_can_pci.c index cf7c18947189..d065c0e2d18e 100644 --- a/drivers/net/can/c_can/c_can_pci.c +++ b/drivers/net/can/c_can/c_can_pci.c @@ -178,7 +178,6 @@ static int c_can_pci_probe(struct pci_dev *pdev, break; case BOSCH_D_CAN: priv->regs = reg_map_d_can; - priv->can.ctrlmode_supported |= CAN_CTRLMODE_3_SAMPLES; break; default: ret = -EINVAL; diff --git a/drivers/net/can/c_can/c_can_platform.c b/drivers/net/can/c_can/c_can_platform.c index 46a746ee80bb..b5145a7f874c 100644 --- a/drivers/net/can/c_can/c_can_platform.c +++ b/drivers/net/can/c_can/c_can_platform.c @@ -320,7 +320,6 @@ static int c_can_plat_probe(struct platform_device *pdev) break; case BOSCH_D_CAN: priv->regs = reg_map_d_can; - priv->can.ctrlmode_supported |= CAN_CTRLMODE_3_SAMPLES; priv->read_reg = c_can_plat_read_reg_aligned_to_16bit; priv->write_reg = c_can_plat_write_reg_aligned_to_16bit; priv->read_reg32 = d_can_plat_read_reg32; -- 2.15.0

7 years, 7 months

1
0
0 0

Re: [Linux-stable-mirror] Request for stable 4.13.x inclusion: netfilter: nft_set_hash: disable fast_ops for 2-len keys

by Greg KH

On Fri, Nov 10, 2017 at 12:56:46PM +0100, Thomas Deutschmann wrote: > Hi, > > please consider to add > > > From 0414c78f14861cb704d6e6888efd53dd36e3bdde Mon Sep 17 00:00:00 2001 Just added it 5 minutes ago :) thanks, greg k-h

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "platform/x86: hp-wmi: Fix detection for dock and tablet mode" 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 platform/x86: hp-wmi: Fix detection for dock and tablet mode 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: platform-x86-hp-wmi-fix-detection-for-dock-and-tablet-mode.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 298747b7579f5bbbced793d997b333fd10a24921 Mon Sep 17 00:00:00 2001 From: Carlo Caione <carlo(a)endlessm.com> Date: Sun, 9 Apr 2017 15:56:08 +0200 Subject: platform/x86: hp-wmi: Fix detection for dock and tablet mode From: Carlo Caione <carlo(a)endlessm.com> commit 298747b7579f5bbbced793d997b333fd10a24921 upstream. The current driver code is not checking for the error values returned by 'hp_wmi_dock_state()' and 'hp_wmi_tablet_state()' before passing the returned values down to 'input_report_switch()'. This error code is being translated to '1' in the input subsystem, reporting the wrong status. The biggest problem caused by this issue is that several laptops are wrongly reported by the driver as docked, preventing them to be put to sleep using the LID (and in most cases they are not even dockable). With this patch we create the report switches only if we are able to read the dock and tablet mode status correctly from ACPI. Signed-off-by: Carlo Caione <carlo(a)endlessm.com> Signed-off-by: Darren Hart (VMware) <dvhart(a)infradead.org> Cc: Philip Müller <philm(a)manjaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/platform/x86/hp-wmi.c | 40 +++++++++++++++++++++++++++------------- 1 file changed, 27 insertions(+), 13 deletions(-) --- a/drivers/platform/x86/hp-wmi.c +++ b/drivers/platform/x86/hp-wmi.c @@ -572,10 +572,12 @@ static void hp_wmi_notify(u32 value, voi switch (event_id) { case HPWMI_DOCK_EVENT: - input_report_switch(hp_wmi_input_dev, SW_DOCK, - hp_wmi_dock_state()); - input_report_switch(hp_wmi_input_dev, SW_TABLET_MODE, - hp_wmi_tablet_state()); + if (test_bit(SW_DOCK, hp_wmi_input_dev->swbit)) + input_report_switch(hp_wmi_input_dev, SW_DOCK, + hp_wmi_dock_state()); + if (test_bit(SW_TABLET_MODE, hp_wmi_input_dev->swbit)) + input_report_switch(hp_wmi_input_dev, SW_TABLET_MODE, + hp_wmi_tablet_state()); input_sync(hp_wmi_input_dev); break; case HPWMI_PARK_HDD: @@ -644,6 +646,7 @@ static int __init hp_wmi_input_setup(voi { acpi_status status; int err; + int val; hp_wmi_input_dev = input_allocate_device(); if (!hp_wmi_input_dev) @@ -654,17 +657,26 @@ static int __init hp_wmi_input_setup(voi hp_wmi_input_dev->id.bustype = BUS_HOST; __set_bit(EV_SW, hp_wmi_input_dev->evbit); - __set_bit(SW_DOCK, hp_wmi_input_dev->swbit); - __set_bit(SW_TABLET_MODE, hp_wmi_input_dev->swbit); + + /* Dock */ + val = hp_wmi_dock_state(); + if (!(val < 0)) { + __set_bit(SW_DOCK, hp_wmi_input_dev->swbit); + input_report_switch(hp_wmi_input_dev, SW_DOCK, val); + } + + /* Tablet mode */ + val = hp_wmi_tablet_state(); + if (!(val < 0)) { + __set_bit(SW_TABLET_MODE, hp_wmi_input_dev->swbit); + input_report_switch(hp_wmi_input_dev, SW_TABLET_MODE, val); + } err = sparse_keymap_setup(hp_wmi_input_dev, hp_wmi_keymap, NULL); if (err) goto err_free_dev; /* Set initial hardware state */ - input_report_switch(hp_wmi_input_dev, SW_DOCK, hp_wmi_dock_state()); - input_report_switch(hp_wmi_input_dev, SW_TABLET_MODE, - hp_wmi_tablet_state()); input_sync(hp_wmi_input_dev); if (!hp_wmi_bios_2009_later() && hp_wmi_bios_2008_later()) @@ -950,10 +962,12 @@ static int hp_wmi_resume_handler(struct * changed. */ if (hp_wmi_input_dev) { - input_report_switch(hp_wmi_input_dev, SW_DOCK, - hp_wmi_dock_state()); - input_report_switch(hp_wmi_input_dev, SW_TABLET_MODE, - hp_wmi_tablet_state()); + if (test_bit(SW_DOCK, hp_wmi_input_dev->swbit)) + input_report_switch(hp_wmi_input_dev, SW_DOCK, + hp_wmi_dock_state()); + if (test_bit(SW_TABLET_MODE, hp_wmi_input_dev->swbit)) + input_report_switch(hp_wmi_input_dev, SW_TABLET_MODE, + hp_wmi_tablet_state()); input_sync(hp_wmi_input_dev); } Patches currently in stable-queue which might be from carlo(a)endlessm.com are queue-4.9/platform-x86-hp-wmi-fix-detection-for-dock-and-tablet-mode.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "KEYS: trusted: fix writing past end of buffer in trusted_read()" 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 KEYS: trusted: fix writing past end of buffer in trusted_read() 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: keys-trusted-fix-writing-past-end-of-buffer-in-trusted_read.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 a3c812f7cfd80cf51e8f5b7034f7418f6beb56c1 Mon Sep 17 00:00:00 2001 From: Eric Biggers <ebiggers(a)google.com> Date: Thu, 2 Nov 2017 00:47:12 +0000 Subject: KEYS: trusted: fix writing past end of buffer in trusted_read() From: Eric Biggers <ebiggers(a)google.com> commit a3c812f7cfd80cf51e8f5b7034f7418f6beb56c1 upstream. When calling keyctl_read() on a key of type "trusted", if the user-supplied buffer was too small, the kernel ignored the buffer length and just wrote past the end of the buffer, potentially corrupting userspace memory. Fix it by instead returning the size required, as per the documentation for keyctl_read(). We also don't even fill the buffer at all in this case, as this is slightly easier to implement than doing a short read, and either behavior appears to be permitted. It also makes it match the behavior of the "encrypted" key type. Fixes: d00a1c72f7f4 ("keys: add new trusted key-type") Reported-by: Ben Hutchings <ben(a)decadent.org.uk> Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Reviewed-by: Mimi Zohar <zohar(a)linux.vnet.ibm.com> Reviewed-by: James Morris <james.l.morris(a)oracle.com> Signed-off-by: James Morris <james.l.morris(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- security/keys/trusted.c | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) --- a/security/keys/trusted.c +++ b/security/keys/trusted.c @@ -1147,20 +1147,21 @@ static long trusted_read(const struct ke p = rcu_dereference_key(key); if (!p) return -EINVAL; - if (!buffer || buflen <= 0) - return 2 * p->blob_len; - ascii_buf = kmalloc(2 * p->blob_len, GFP_KERNEL); - if (!ascii_buf) - return -ENOMEM; - bufp = ascii_buf; - for (i = 0; i < p->blob_len; i++) - bufp = hex_byte_pack(bufp, p->blob[i]); - if ((copy_to_user(buffer, ascii_buf, 2 * p->blob_len)) != 0) { + if (buffer && buflen >= 2 * p->blob_len) { + ascii_buf = kmalloc(2 * p->blob_len, GFP_KERNEL); + if (!ascii_buf) + return -ENOMEM; + + bufp = ascii_buf; + for (i = 0; i < p->blob_len; i++) + bufp = hex_byte_pack(bufp, p->blob[i]); + if (copy_to_user(buffer, ascii_buf, 2 * p->blob_len) != 0) { + kzfree(ascii_buf); + return -EFAULT; + } kzfree(ascii_buf); - return -EFAULT; } - kzfree(ascii_buf); return 2 * p->blob_len; } Patches currently in stable-queue which might be from ebiggers(a)google.com are queue-4.9/keys-trusted-sanitize-all-key-material.patch queue-4.9/keys-trusted-fix-writing-past-end-of-buffer-in-trusted_read.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "KEYS: trusted: sanitize all key material" 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 KEYS: trusted: sanitize all key material 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: keys-trusted-sanitize-all-key-material.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 ee618b4619b72527aaed765f0f0b74072b281159 Mon Sep 17 00:00:00 2001 From: Eric Biggers <ebiggers(a)google.com> Date: Thu, 8 Jun 2017 14:49:18 +0100 Subject: KEYS: trusted: sanitize all key material From: Eric Biggers <ebiggers(a)google.com> commit ee618b4619b72527aaed765f0f0b74072b281159 upstream. As the previous patch did for encrypted-keys, zero sensitive any potentially sensitive data related to the "trusted" key type before it is freed. Notably, we were not zeroing the tpm_buf structures in which the actual key is stored for TPM seal and unseal, nor were we zeroing the trusted_key_payload in certain error paths. Cc: Mimi Zohar <zohar(a)linux.vnet.ibm.com> Cc: David Safford <safford(a)us.ibm.com> Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: James Morris <james.l.morris(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- security/keys/trusted.c | 50 +++++++++++++++++++++--------------------------- 1 file changed, 22 insertions(+), 28 deletions(-) --- a/security/keys/trusted.c +++ b/security/keys/trusted.c @@ -70,7 +70,7 @@ static int TSS_sha1(const unsigned char } ret = crypto_shash_digest(&sdesc->shash, data, datalen, digest); - kfree(sdesc); + kzfree(sdesc); return ret; } @@ -114,7 +114,7 @@ static int TSS_rawhmac(unsigned char *di if (!ret) ret = crypto_shash_final(&sdesc->shash, digest); out: - kfree(sdesc); + kzfree(sdesc); return ret; } @@ -165,7 +165,7 @@ static int TSS_authhmac(unsigned char *d paramdigest, TPM_NONCE_SIZE, h1, TPM_NONCE_SIZE, h2, 1, &c, 0, 0); out: - kfree(sdesc); + kzfree(sdesc); return ret; } @@ -246,7 +246,7 @@ static int TSS_checkhmac1(unsigned char if (memcmp(testhmac, authdata, SHA1_DIGEST_SIZE)) ret = -EINVAL; out: - kfree(sdesc); + kzfree(sdesc); return ret; } @@ -347,7 +347,7 @@ static int TSS_checkhmac2(unsigned char if (memcmp(testhmac2, authdata2, SHA1_DIGEST_SIZE)) ret = -EINVAL; out: - kfree(sdesc); + kzfree(sdesc); return ret; } @@ -564,7 +564,7 @@ static int tpm_seal(struct tpm_buf *tb, *bloblen = storedsize; } out: - kfree(td); + kzfree(td); return ret; } @@ -678,7 +678,7 @@ static int key_seal(struct trusted_key_p if (ret < 0) pr_info("trusted_key: srkseal failed (%d)\n", ret); - kfree(tb); + kzfree(tb); return ret; } @@ -703,7 +703,7 @@ static int key_unseal(struct trusted_key /* pull migratable flag out of sealed key */ p->migratable = p->key[--p->key_len]; - kfree(tb); + kzfree(tb); return ret; } @@ -1037,12 +1037,12 @@ static int trusted_instantiate(struct ke if (!ret && options->pcrlock) ret = pcrlock(options->pcrlock); out: - kfree(datablob); - kfree(options); + kzfree(datablob); + kzfree(options); if (!ret) rcu_assign_keypointer(key, payload); else - kfree(payload); + kzfree(payload); return ret; } @@ -1051,8 +1051,7 @@ static void trusted_rcu_free(struct rcu_ struct trusted_key_payload *p; p = container_of(rcu, struct trusted_key_payload, rcu); - memset(p->key, 0, p->key_len); - kfree(p); + kzfree(p); } /* @@ -1094,13 +1093,13 @@ static int trusted_update(struct key *ke ret = datablob_parse(datablob, new_p, new_o); if (ret != Opt_update) { ret = -EINVAL; - kfree(new_p); + kzfree(new_p); goto out; } if (!new_o->keyhandle) { ret = -EINVAL; - kfree(new_p); + kzfree(new_p); goto out; } @@ -1114,22 +1113,22 @@ static int trusted_update(struct key *ke ret = key_seal(new_p, new_o); if (ret < 0) { pr_info("trusted_key: key_seal failed (%d)\n", ret); - kfree(new_p); + kzfree(new_p); goto out; } if (new_o->pcrlock) { ret = pcrlock(new_o->pcrlock); if (ret < 0) { pr_info("trusted_key: pcrlock failed (%d)\n", ret); - kfree(new_p); + kzfree(new_p); goto out; } } rcu_assign_keypointer(key, new_p); call_rcu(&p->rcu, trusted_rcu_free); out: - kfree(datablob); - kfree(new_o); + kzfree(datablob); + kzfree(new_o); return ret; } @@ -1158,24 +1157,19 @@ static long trusted_read(const struct ke for (i = 0; i < p->blob_len; i++) bufp = hex_byte_pack(bufp, p->blob[i]); if ((copy_to_user(buffer, ascii_buf, 2 * p->blob_len)) != 0) { - kfree(ascii_buf); + kzfree(ascii_buf); return -EFAULT; } - kfree(ascii_buf); + kzfree(ascii_buf); return 2 * p->blob_len; } /* - * trusted_destroy - before freeing the key, clear the decrypted data + * trusted_destroy - clear and free the key's payload */ static void trusted_destroy(struct key *key) { - struct trusted_key_payload *p = key->payload.data[0]; - - if (!p) - return; - memset(p->key, 0, p->key_len); - kfree(key->payload.data[0]); + kzfree(key->payload.data[0]); } struct key_type key_type_trusted = { Patches currently in stable-queue which might be from ebiggers(a)google.com are queue-4.9/keys-trusted-sanitize-all-key-material.patch queue-4.9/keys-trusted-fix-writing-past-end-of-buffer-in-trusted_read.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "cdc_ncm: Set NTB format again after altsetting switch for Huawei devices" 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 cdc_ncm: Set NTB format again after altsetting switch for Huawei devices 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: cdc_ncm-set-ntb-format-again-after-altsetting-switch-for-huawei-devices.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 2b02c20ce0c28974b44e69a2e2f5ddc6a470ad6f Mon Sep 17 00:00:00 2001 From: Enrico Mioso <mrkiko.rs(a)gmail.com> Date: Tue, 11 Jul 2017 17:21:52 +0200 Subject: cdc_ncm: Set NTB format again after altsetting switch for Huawei devices MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Enrico Mioso <mrkiko.rs(a)gmail.com> commit 2b02c20ce0c28974b44e69a2e2f5ddc6a470ad6f upstream. Some firmwares in Huawei E3372H devices have been observed to switch back to NTB 32-bit format after altsetting switch. This patch implements a driver flag to check for the device settings and set NTB format to 16-bit again if needed. The flag has been activated for devices controlled by the huawei_cdc_ncm.c driver. V1->V2: - fixed broken error checks - some corrections to the commit message V2->V3: - variable name changes, to clarify what's happening - check (and possibly set) the NTB format later in the common bind code path Signed-off-by: Enrico Mioso <mrkiko.rs(a)gmail.com> Reported-and-tested-by: Christian Panton <christian(a)panton.org> Reviewed-by: Bjørn Mork <bjorn(a)mork.no> CC: Bjørn Mork <bjorn(a)mork.no> CC: Christian Panton <christian(a)panton.org> CC: linux-usb(a)vger.kernel.org CC: netdev(a)vger.kernel.org CC: Oliver Neukum <oliver(a)neukum.org> Signed-off-by: David S. Miller <davem(a)davemloft.net> Cc: Porto Rio <porto.rio(a)gmx.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/usb/cdc_ncm.c | 28 ++++++++++++++++++++++++++++ drivers/net/usb/huawei_cdc_ncm.c | 6 ++++++ include/linux/usb/cdc_ncm.h | 1 + 3 files changed, 35 insertions(+) --- a/drivers/net/usb/cdc_ncm.c +++ b/drivers/net/usb/cdc_ncm.c @@ -769,8 +769,10 @@ int cdc_ncm_bind_common(struct usbnet *d u8 *buf; int len; int temp; + int err; u8 iface_no; struct usb_cdc_parsed_header hdr; + u16 curr_ntb_format; ctx = kzalloc(sizeof(*ctx), GFP_KERNEL); if (!ctx) @@ -875,6 +877,32 @@ int cdc_ncm_bind_common(struct usbnet *d goto error2; } + /* + * Some Huawei devices have been observed to come out of reset in NDP32 mode. + * Let's check if this is the case, and set the device to NDP16 mode again if + * needed. + */ + if (ctx->drvflags & CDC_NCM_FLAG_RESET_NTB16) { + err = usbnet_read_cmd(dev, USB_CDC_GET_NTB_FORMAT, + USB_TYPE_CLASS | USB_DIR_IN | USB_RECIP_INTERFACE, + 0, iface_no, &curr_ntb_format, 2); + if (err < 0) { + goto error2; + } + + if (curr_ntb_format == USB_CDC_NCM_NTB32_FORMAT) { + dev_info(&intf->dev, "resetting NTB format to 16-bit"); + err = usbnet_write_cmd(dev, USB_CDC_SET_NTB_FORMAT, + USB_TYPE_CLASS | USB_DIR_OUT + | USB_RECIP_INTERFACE, + USB_CDC_NCM_NTB16_FORMAT, + iface_no, NULL, 0); + + if (err < 0) + goto error2; + } + } + cdc_ncm_find_endpoints(dev, ctx->data); cdc_ncm_find_endpoints(dev, ctx->control); if (!dev->in || !dev->out || !dev->status) { --- a/drivers/net/usb/huawei_cdc_ncm.c +++ b/drivers/net/usb/huawei_cdc_ncm.c @@ -80,6 +80,12 @@ static int huawei_cdc_ncm_bind(struct us * be at the end of the frame. */ drvflags |= CDC_NCM_FLAG_NDP_TO_END; + + /* Additionally, it has been reported that some Huawei E3372H devices, with + * firmware version 21.318.01.00.541, come out of reset in NTB32 format mode, hence + * needing to be set to the NTB16 one again. + */ + drvflags |= CDC_NCM_FLAG_RESET_NTB16; ret = cdc_ncm_bind_common(usbnet_dev, intf, 1, drvflags); if (ret) goto err; --- a/include/linux/usb/cdc_ncm.h +++ b/include/linux/usb/cdc_ncm.h @@ -83,6 +83,7 @@ /* Driver flags */ #define CDC_NCM_FLAG_NDP_TO_END 0x02 /* NDP is placed at end of frame */ #define CDC_MBIM_FLAG_AVOID_ALTSETTING_TOGGLE 0x04 /* Avoid altsetting toggle during init */ +#define CDC_NCM_FLAG_RESET_NTB16 0x08 /* set NDP16 one more time after altsetting switch */ #define cdc_ncm_comm_intf_is_mbim(x) ((x)->desc.bInterfaceSubClass == USB_CDC_SUBCLASS_MBIM && \ (x)->desc.bInterfaceProtocol == USB_CDC_PROTO_NONE) Patches currently in stable-queue which might be from mrkiko.rs(a)gmail.com are queue-4.9/cdc_ncm-set-ntb-format-again-after-altsetting-switch-for-huawei-devices.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "KEYS: trusted: sanitize all key material" 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 KEYS: trusted: sanitize all key material 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: keys-trusted-sanitize-all-key-material.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 ee618b4619b72527aaed765f0f0b74072b281159 Mon Sep 17 00:00:00 2001 From: Eric Biggers <ebiggers(a)google.com> Date: Thu, 8 Jun 2017 14:49:18 +0100 Subject: KEYS: trusted: sanitize all key material From: Eric Biggers <ebiggers(a)google.com> commit ee618b4619b72527aaed765f0f0b74072b281159 upstream. As the previous patch did for encrypted-keys, zero sensitive any potentially sensitive data related to the "trusted" key type before it is freed. Notably, we were not zeroing the tpm_buf structures in which the actual key is stored for TPM seal and unseal, nor were we zeroing the trusted_key_payload in certain error paths. Cc: Mimi Zohar <zohar(a)linux.vnet.ibm.com> Cc: David Safford <safford(a)us.ibm.com> Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: James Morris <james.l.morris(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- security/keys/trusted.c | 50 +++++++++++++++++++++--------------------------- 1 file changed, 22 insertions(+), 28 deletions(-) --- a/security/keys/trusted.c +++ b/security/keys/trusted.c @@ -69,7 +69,7 @@ static int TSS_sha1(const unsigned char } ret = crypto_shash_digest(&sdesc->shash, data, datalen, digest); - kfree(sdesc); + kzfree(sdesc); return ret; } @@ -113,7 +113,7 @@ static int TSS_rawhmac(unsigned char *di if (!ret) ret = crypto_shash_final(&sdesc->shash, digest); out: - kfree(sdesc); + kzfree(sdesc); return ret; } @@ -164,7 +164,7 @@ static int TSS_authhmac(unsigned char *d paramdigest, TPM_NONCE_SIZE, h1, TPM_NONCE_SIZE, h2, 1, &c, 0, 0); out: - kfree(sdesc); + kzfree(sdesc); return ret; } @@ -245,7 +245,7 @@ static int TSS_checkhmac1(unsigned char if (memcmp(testhmac, authdata, SHA1_DIGEST_SIZE)) ret = -EINVAL; out: - kfree(sdesc); + kzfree(sdesc); return ret; } @@ -346,7 +346,7 @@ static int TSS_checkhmac2(unsigned char if (memcmp(testhmac2, authdata2, SHA1_DIGEST_SIZE)) ret = -EINVAL; out: - kfree(sdesc); + kzfree(sdesc); return ret; } @@ -563,7 +563,7 @@ static int tpm_seal(struct tpm_buf *tb, *bloblen = storedsize; } out: - kfree(td); + kzfree(td); return ret; } @@ -677,7 +677,7 @@ static int key_seal(struct trusted_key_p if (ret < 0) pr_info("trusted_key: srkseal failed (%d)\n", ret); - kfree(tb); + kzfree(tb); return ret; } @@ -702,7 +702,7 @@ static int key_unseal(struct trusted_key /* pull migratable flag out of sealed key */ p->migratable = p->key[--p->key_len]; - kfree(tb); + kzfree(tb); return ret; } @@ -984,12 +984,12 @@ static int trusted_instantiate(struct ke if (!ret && options->pcrlock) ret = pcrlock(options->pcrlock); out: - kfree(datablob); - kfree(options); + kzfree(datablob); + kzfree(options); if (!ret) rcu_assign_keypointer(key, payload); else - kfree(payload); + kzfree(payload); return ret; } @@ -998,8 +998,7 @@ static void trusted_rcu_free(struct rcu_ struct trusted_key_payload *p; p = container_of(rcu, struct trusted_key_payload, rcu); - memset(p->key, 0, p->key_len); - kfree(p); + kzfree(p); } /* @@ -1041,13 +1040,13 @@ static int trusted_update(struct key *ke ret = datablob_parse(datablob, new_p, new_o); if (ret != Opt_update) { ret = -EINVAL; - kfree(new_p); + kzfree(new_p); goto out; } if (!new_o->keyhandle) { ret = -EINVAL; - kfree(new_p); + kzfree(new_p); goto out; } @@ -1061,22 +1060,22 @@ static int trusted_update(struct key *ke ret = key_seal(new_p, new_o); if (ret < 0) { pr_info("trusted_key: key_seal failed (%d)\n", ret); - kfree(new_p); + kzfree(new_p); goto out; } if (new_o->pcrlock) { ret = pcrlock(new_o->pcrlock); if (ret < 0) { pr_info("trusted_key: pcrlock failed (%d)\n", ret); - kfree(new_p); + kzfree(new_p); goto out; } } rcu_assign_keypointer(key, new_p); call_rcu(&p->rcu, trusted_rcu_free); out: - kfree(datablob); - kfree(new_o); + kzfree(datablob); + kzfree(new_o); return ret; } @@ -1105,24 +1104,19 @@ static long trusted_read(const struct ke for (i = 0; i < p->blob_len; i++) bufp = hex_byte_pack(bufp, p->blob[i]); if ((copy_to_user(buffer, ascii_buf, 2 * p->blob_len)) != 0) { - kfree(ascii_buf); + kzfree(ascii_buf); return -EFAULT; } - kfree(ascii_buf); + kzfree(ascii_buf); return 2 * p->blob_len; } /* - * trusted_destroy - before freeing the key, clear the decrypted data + * trusted_destroy - clear and free the key's payload */ static void trusted_destroy(struct key *key) { - struct trusted_key_payload *p = key->payload.data[0]; - - if (!p) - return; - memset(p->key, 0, p->key_len); - kfree(key->payload.data[0]); + kzfree(key->payload.data[0]); } struct key_type key_type_trusted = { Patches currently in stable-queue which might be from ebiggers(a)google.com are queue-4.4/keys-trusted-sanitize-all-key-material.patch queue-4.4/keys-trusted-fix-writing-past-end-of-buffer-in-trusted_read.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "platform/x86: hp-wmi: Fix detection for dock and tablet mode" 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 platform/x86: hp-wmi: Fix detection for dock and tablet mode 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: platform-x86-hp-wmi-fix-detection-for-dock-and-tablet-mode.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 298747b7579f5bbbced793d997b333fd10a24921 Mon Sep 17 00:00:00 2001 From: Carlo Caione <carlo(a)endlessm.com> Date: Sun, 9 Apr 2017 15:56:08 +0200 Subject: platform/x86: hp-wmi: Fix detection for dock and tablet mode From: Carlo Caione <carlo(a)endlessm.com> commit 298747b7579f5bbbced793d997b333fd10a24921 upstream. The current driver code is not checking for the error values returned by 'hp_wmi_dock_state()' and 'hp_wmi_tablet_state()' before passing the returned values down to 'input_report_switch()'. This error code is being translated to '1' in the input subsystem, reporting the wrong status. The biggest problem caused by this issue is that several laptops are wrongly reported by the driver as docked, preventing them to be put to sleep using the LID (and in most cases they are not even dockable). With this patch we create the report switches only if we are able to read the dock and tablet mode status correctly from ACPI. Signed-off-by: Carlo Caione <carlo(a)endlessm.com> Signed-off-by: Darren Hart (VMware) <dvhart(a)infradead.org> Cc: Philip Müller <philm(a)manjaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/platform/x86/hp-wmi.c | 40 +++++++++++++++++++++++++++------------- 1 file changed, 27 insertions(+), 13 deletions(-) --- a/drivers/platform/x86/hp-wmi.c +++ b/drivers/platform/x86/hp-wmi.c @@ -573,10 +573,12 @@ static void hp_wmi_notify(u32 value, voi switch (event_id) { case HPWMI_DOCK_EVENT: - input_report_switch(hp_wmi_input_dev, SW_DOCK, - hp_wmi_dock_state()); - input_report_switch(hp_wmi_input_dev, SW_TABLET_MODE, - hp_wmi_tablet_state()); + if (test_bit(SW_DOCK, hp_wmi_input_dev->swbit)) + input_report_switch(hp_wmi_input_dev, SW_DOCK, + hp_wmi_dock_state()); + if (test_bit(SW_TABLET_MODE, hp_wmi_input_dev->swbit)) + input_report_switch(hp_wmi_input_dev, SW_TABLET_MODE, + hp_wmi_tablet_state()); input_sync(hp_wmi_input_dev); break; case HPWMI_PARK_HDD: @@ -649,6 +651,7 @@ static int __init hp_wmi_input_setup(voi { acpi_status status; int err; + int val; hp_wmi_input_dev = input_allocate_device(); if (!hp_wmi_input_dev) @@ -659,17 +662,26 @@ static int __init hp_wmi_input_setup(voi hp_wmi_input_dev->id.bustype = BUS_HOST; __set_bit(EV_SW, hp_wmi_input_dev->evbit); - __set_bit(SW_DOCK, hp_wmi_input_dev->swbit); - __set_bit(SW_TABLET_MODE, hp_wmi_input_dev->swbit); + + /* Dock */ + val = hp_wmi_dock_state(); + if (!(val < 0)) { + __set_bit(SW_DOCK, hp_wmi_input_dev->swbit); + input_report_switch(hp_wmi_input_dev, SW_DOCK, val); + } + + /* Tablet mode */ + val = hp_wmi_tablet_state(); + if (!(val < 0)) { + __set_bit(SW_TABLET_MODE, hp_wmi_input_dev->swbit); + input_report_switch(hp_wmi_input_dev, SW_TABLET_MODE, val); + } err = sparse_keymap_setup(hp_wmi_input_dev, hp_wmi_keymap, NULL); if (err) goto err_free_dev; /* Set initial hardware state */ - input_report_switch(hp_wmi_input_dev, SW_DOCK, hp_wmi_dock_state()); - input_report_switch(hp_wmi_input_dev, SW_TABLET_MODE, - hp_wmi_tablet_state()); input_sync(hp_wmi_input_dev); if (!hp_wmi_bios_2009_later() && hp_wmi_bios_2008_later()) @@ -982,10 +994,12 @@ static int hp_wmi_resume_handler(struct * changed. */ if (hp_wmi_input_dev) { - input_report_switch(hp_wmi_input_dev, SW_DOCK, - hp_wmi_dock_state()); - input_report_switch(hp_wmi_input_dev, SW_TABLET_MODE, - hp_wmi_tablet_state()); + if (test_bit(SW_DOCK, hp_wmi_input_dev->swbit)) + input_report_switch(hp_wmi_input_dev, SW_DOCK, + hp_wmi_dock_state()); + if (test_bit(SW_TABLET_MODE, hp_wmi_input_dev->swbit)) + input_report_switch(hp_wmi_input_dev, SW_TABLET_MODE, + hp_wmi_tablet_state()); input_sync(hp_wmi_input_dev); } Patches currently in stable-queue which might be from carlo(a)endlessm.com are queue-4.4/platform-x86-hp-wmi-fix-detection-for-dock-and-tablet-mode.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "cdc_ncm: Set NTB format again after altsetting switch for Huawei devices" 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 cdc_ncm: Set NTB format again after altsetting switch for Huawei devices 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: cdc_ncm-set-ntb-format-again-after-altsetting-switch-for-huawei-devices.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 2b02c20ce0c28974b44e69a2e2f5ddc6a470ad6f Mon Sep 17 00:00:00 2001 From: Enrico Mioso <mrkiko.rs(a)gmail.com> Date: Tue, 11 Jul 2017 17:21:52 +0200 Subject: cdc_ncm: Set NTB format again after altsetting switch for Huawei devices MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Enrico Mioso <mrkiko.rs(a)gmail.com> commit 2b02c20ce0c28974b44e69a2e2f5ddc6a470ad6f upstream. Some firmwares in Huawei E3372H devices have been observed to switch back to NTB 32-bit format after altsetting switch. This patch implements a driver flag to check for the device settings and set NTB format to 16-bit again if needed. The flag has been activated for devices controlled by the huawei_cdc_ncm.c driver. V1->V2: - fixed broken error checks - some corrections to the commit message V2->V3: - variable name changes, to clarify what's happening - check (and possibly set) the NTB format later in the common bind code path Signed-off-by: Enrico Mioso <mrkiko.rs(a)gmail.com> Reported-and-tested-by: Christian Panton <christian(a)panton.org> Reviewed-by: Bjørn Mork <bjorn(a)mork.no> CC: Bjørn Mork <bjorn(a)mork.no> CC: Christian Panton <christian(a)panton.org> CC: linux-usb(a)vger.kernel.org CC: netdev(a)vger.kernel.org CC: Oliver Neukum <oliver(a)neukum.org> Signed-off-by: David S. Miller <davem(a)davemloft.net> Cc: Porto Rio <porto.rio(a)gmx.net> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/usb/cdc_ncm.c | 28 ++++++++++++++++++++++++++++ drivers/net/usb/huawei_cdc_ncm.c | 6 ++++++ include/linux/usb/cdc_ncm.h | 1 + 3 files changed, 35 insertions(+) --- a/drivers/net/usb/cdc_ncm.c +++ b/drivers/net/usb/cdc_ncm.c @@ -724,8 +724,10 @@ int cdc_ncm_bind_common(struct usbnet *d u8 *buf; int len; int temp; + int err; u8 iface_no; struct usb_cdc_parsed_header hdr; + u16 curr_ntb_format; ctx = kzalloc(sizeof(*ctx), GFP_KERNEL); if (!ctx) @@ -823,6 +825,32 @@ int cdc_ncm_bind_common(struct usbnet *d goto error2; } + /* + * Some Huawei devices have been observed to come out of reset in NDP32 mode. + * Let's check if this is the case, and set the device to NDP16 mode again if + * needed. + */ + if (ctx->drvflags & CDC_NCM_FLAG_RESET_NTB16) { + err = usbnet_read_cmd(dev, USB_CDC_GET_NTB_FORMAT, + USB_TYPE_CLASS | USB_DIR_IN | USB_RECIP_INTERFACE, + 0, iface_no, &curr_ntb_format, 2); + if (err < 0) { + goto error2; + } + + if (curr_ntb_format == USB_CDC_NCM_NTB32_FORMAT) { + dev_info(&intf->dev, "resetting NTB format to 16-bit"); + err = usbnet_write_cmd(dev, USB_CDC_SET_NTB_FORMAT, + USB_TYPE_CLASS | USB_DIR_OUT + | USB_RECIP_INTERFACE, + USB_CDC_NCM_NTB16_FORMAT, + iface_no, NULL, 0); + + if (err < 0) + goto error2; + } + } + cdc_ncm_find_endpoints(dev, ctx->data); cdc_ncm_find_endpoints(dev, ctx->control); if (!dev->in || !dev->out || !dev->status) { --- a/drivers/net/usb/huawei_cdc_ncm.c +++ b/drivers/net/usb/huawei_cdc_ncm.c @@ -80,6 +80,12 @@ static int huawei_cdc_ncm_bind(struct us * be at the end of the frame. */ drvflags |= CDC_NCM_FLAG_NDP_TO_END; + + /* Additionally, it has been reported that some Huawei E3372H devices, with + * firmware version 21.318.01.00.541, come out of reset in NTB32 format mode, hence + * needing to be set to the NTB16 one again. + */ + drvflags |= CDC_NCM_FLAG_RESET_NTB16; ret = cdc_ncm_bind_common(usbnet_dev, intf, 1, drvflags); if (ret) goto err; --- a/include/linux/usb/cdc_ncm.h +++ b/include/linux/usb/cdc_ncm.h @@ -82,6 +82,7 @@ /* Driver flags */ #define CDC_NCM_FLAG_NDP_TO_END 0x02 /* NDP is placed at end of frame */ +#define CDC_NCM_FLAG_RESET_NTB16 0x08 /* set NDP16 one more time after altsetting switch */ #define cdc_ncm_comm_intf_is_mbim(x) ((x)->desc.bInterfaceSubClass == USB_CDC_SUBCLASS_MBIM && \ (x)->desc.bInterfaceProtocol == USB_CDC_PROTO_NONE) Patches currently in stable-queue which might be from mrkiko.rs(a)gmail.com are queue-4.4/cdc_ncm-set-ntb-format-again-after-altsetting-switch-for-huawei-devices.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "KEYS: trusted: fix writing past end of buffer in trusted_read()" 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 KEYS: trusted: fix writing past end of buffer in trusted_read() 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: keys-trusted-fix-writing-past-end-of-buffer-in-trusted_read.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 a3c812f7cfd80cf51e8f5b7034f7418f6beb56c1 Mon Sep 17 00:00:00 2001 From: Eric Biggers <ebiggers(a)google.com> Date: Thu, 2 Nov 2017 00:47:12 +0000 Subject: KEYS: trusted: fix writing past end of buffer in trusted_read() From: Eric Biggers <ebiggers(a)google.com> commit a3c812f7cfd80cf51e8f5b7034f7418f6beb56c1 upstream. When calling keyctl_read() on a key of type "trusted", if the user-supplied buffer was too small, the kernel ignored the buffer length and just wrote past the end of the buffer, potentially corrupting userspace memory. Fix it by instead returning the size required, as per the documentation for keyctl_read(). We also don't even fill the buffer at all in this case, as this is slightly easier to implement than doing a short read, and either behavior appears to be permitted. It also makes it match the behavior of the "encrypted" key type. Fixes: d00a1c72f7f4 ("keys: add new trusted key-type") Reported-by: Ben Hutchings <ben(a)decadent.org.uk> Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Reviewed-by: Mimi Zohar <zohar(a)linux.vnet.ibm.com> Reviewed-by: James Morris <james.l.morris(a)oracle.com> Signed-off-by: James Morris <james.l.morris(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- security/keys/trusted.c | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) --- a/security/keys/trusted.c +++ b/security/keys/trusted.c @@ -1094,20 +1094,21 @@ static long trusted_read(const struct ke p = rcu_dereference_key(key); if (!p) return -EINVAL; - if (!buffer || buflen <= 0) - return 2 * p->blob_len; - ascii_buf = kmalloc(2 * p->blob_len, GFP_KERNEL); - if (!ascii_buf) - return -ENOMEM; - bufp = ascii_buf; - for (i = 0; i < p->blob_len; i++) - bufp = hex_byte_pack(bufp, p->blob[i]); - if ((copy_to_user(buffer, ascii_buf, 2 * p->blob_len)) != 0) { + if (buffer && buflen >= 2 * p->blob_len) { + ascii_buf = kmalloc(2 * p->blob_len, GFP_KERNEL); + if (!ascii_buf) + return -ENOMEM; + + bufp = ascii_buf; + for (i = 0; i < p->blob_len; i++) + bufp = hex_byte_pack(bufp, p->blob[i]); + if (copy_to_user(buffer, ascii_buf, 2 * p->blob_len) != 0) { + kzfree(ascii_buf); + return -EFAULT; + } kzfree(ascii_buf); - return -EFAULT; } - kzfree(ascii_buf); return 2 * p->blob_len; } Patches currently in stable-queue which might be from ebiggers(a)google.com are queue-4.4/keys-trusted-sanitize-all-key-material.patch queue-4.4/keys-trusted-fix-writing-past-end-of-buffer-in-trusted_read.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "netfilter: nft_set_hash: disable fast_ops for 2-len keys" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled netfilter: nft_set_hash: disable fast_ops for 2-len keys to the 4.13-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: netfilter-nft_set_hash-disable-fast_ops-for-2-len-keys.patch and it can be found in the queue-4.13 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 0414c78f14861cb704d6e6888efd53dd36e3bdde Mon Sep 17 00:00:00 2001 From: Anatole Denis <anatole(a)rezel.net> Date: Wed, 4 Oct 2017 01:17:14 +0100 Subject: netfilter: nft_set_hash: disable fast_ops for 2-len keys From: Anatole Denis <anatole(a)rezel.net> commit 0414c78f14861cb704d6e6888efd53dd36e3bdde upstream. jhash_1word of a u16 is a different value from jhash of the same u16 with length 2. Since elements are always inserted in sets using jhash over the actual klen, this would lead to incorrect lookups on fixed-size sets with a key length of 2, as they would be inserted with hash value jhash(key, 2) and looked up with hash value jhash_1word(key), which is different. Example reproducer(v4.13+), using anonymous sets which always have a fixed size: table inet t { chain c { type filter hook output priority 0; policy accept; tcp dport { 10001, 10003, 10005, 10007, 10009 } counter packets 4 bytes 240 reject tcp dport 10001 counter packets 4 bytes 240 reject tcp dport 10003 counter packets 4 bytes 240 reject tcp dport 10005 counter packets 4 bytes 240 reject tcp dport 10007 counter packets 0 bytes 0 reject tcp dport 10009 counter packets 4 bytes 240 reject } } then use nc -z localhost <port> to probe; incorrectly hashed ports will pass through the set lookup and increment the counter of an individual rule. jhash being seeded with a random value, it is not deterministic which ports will incorrectly hash, but in testing with 5 ports in the set I always had 4 or 5 with an incorrect hash value. Signed-off-by: Anatole Denis <anatole(a)rezel.net> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/netfilter/nft_set_hash.c | 1 - 1 file changed, 1 deletion(-) --- a/net/netfilter/nft_set_hash.c +++ b/net/netfilter/nft_set_hash.c @@ -643,7 +643,6 @@ nft_hash_select_ops(const struct nft_ctx { if (desc->size) { switch (desc->klen) { - case 2: case 4: return &nft_hash_fast_ops; default: Patches currently in stable-queue which might be from anatole(a)rezel.net are queue-4.13/netfilter-nft_set_hash-disable-fast_ops-for-2-len-keys.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "netfilter: nat: Revert "netfilter: nat: convert nat bysrc hash to rhashtable"" has been added to the 4.13-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled netfilter: nat: Revert "netfilter: nat: convert nat bysrc hash to rhashtable" to the 4.13-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: netfilter-nat-revert-netfilter-nat-convert-nat-bysrc-hash-to-rhashtable.patch and it can be found in the queue-4.13 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 e1bf1687740ce1a3598a1c5e452b852ff2190682 Mon Sep 17 00:00:00 2001 From: Florian Westphal <fw(a)strlen.de> Date: Wed, 6 Sep 2017 14:39:51 +0200 Subject: netfilter: nat: Revert "netfilter: nat: convert nat bysrc hash to rhashtable" From: Florian Westphal <fw(a)strlen.de> commit e1bf1687740ce1a3598a1c5e452b852ff2190682 upstream. This reverts commit 870190a9ec9075205c0fa795a09fa931694a3ff1. It was not a good idea. The custom hash table was a much better fit for this purpose. A fast lookup is not essential, in fact for most cases there is no lookup at all because original tuple is not taken and can be used as-is. What needs to be fast is insertion and deletion. rhlist removal however requires a rhlist walk. We can have thousands of entries in such a list if source port/addresses are reused for multiple flows, if this happens removal requests are so expensive that deletions of a few thousand flows can take several seconds(!). The advantages that we got from rhashtable are: 1) table auto-sizing 2) multiple locks 1) would be nice to have, but it is not essential as we have at most one lookup per new flow, so even a million flows in the bysource table are not a problem compared to current deletion cost. 2) is easy to add to custom hash table. I tried to add hlist_node to rhlist to speed up rhltable_remove but this isn't doable without changing semantics. rhltable_remove_fast will check that the to-be-deleted object is part of the table and that requires a list walk that we want to avoid. Furthermore, using hlist_node increases size of struct rhlist_head, which in turn increases nf_conn size. Link: https://bugzilla.kernel.org/show_bug.cgi?id=196821 Reported-by: Ivan Babrou <ibobrik(a)gmail.com> Signed-off-by: Florian Westphal <fw(a)strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo(a)netfilter.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/net/netfilter/nf_conntrack.h | 3 include/net/netfilter/nf_nat.h | 1 net/netfilter/nf_nat_core.c | 128 ++++++++++++++--------------------- 3 files changed, 53 insertions(+), 79 deletions(-) --- a/include/net/netfilter/nf_conntrack.h +++ b/include/net/netfilter/nf_conntrack.h @@ -17,7 +17,6 @@ #include <linux/bitops.h> #include <linux/compiler.h> #include <linux/atomic.h> -#include <linux/rhashtable.h> #include <linux/netfilter/nf_conntrack_tcp.h> #include <linux/netfilter/nf_conntrack_dccp.h> @@ -83,7 +82,7 @@ struct nf_conn { possible_net_t ct_net; #if IS_ENABLED(CONFIG_NF_NAT) - struct rhlist_head nat_bysource; + struct hlist_node nat_bysource; #endif /* all members below initialized via memset */ u8 __nfct_init_offset[0]; --- a/include/net/netfilter/nf_nat.h +++ b/include/net/netfilter/nf_nat.h @@ -1,6 +1,5 @@ #ifndef _NF_NAT_H #define _NF_NAT_H -#include <linux/rhashtable.h> #include <linux/netfilter_ipv4.h> #include <linux/netfilter/nf_nat.h> #include <net/netfilter/nf_conntrack_tuple.h> --- a/net/netfilter/nf_nat_core.c +++ b/net/netfilter/nf_nat_core.c @@ -30,19 +30,17 @@ #include <net/netfilter/nf_conntrack_zones.h> #include <linux/netfilter/nf_nat.h> +static DEFINE_SPINLOCK(nf_nat_lock); + static DEFINE_MUTEX(nf_nat_proto_mutex); static const struct nf_nat_l3proto __rcu *nf_nat_l3protos[NFPROTO_NUMPROTO] __read_mostly; static const struct nf_nat_l4proto __rcu **nf_nat_l4protos[NFPROTO_NUMPROTO] __read_mostly; -struct nf_nat_conn_key { - const struct net *net; - const struct nf_conntrack_tuple *tuple; - const struct nf_conntrack_zone *zone; -}; - -static struct rhltable nf_nat_bysource_table; +static struct hlist_head *nf_nat_bysource __read_mostly; +static unsigned int nf_nat_htable_size __read_mostly; +static unsigned int nf_nat_hash_rnd __read_mostly; inline const struct nf_nat_l3proto * __nf_nat_l3proto_find(u8 family) @@ -118,17 +116,19 @@ int nf_xfrm_me_harder(struct net *net, s EXPORT_SYMBOL(nf_xfrm_me_harder); #endif /* CONFIG_XFRM */ -static u32 nf_nat_bysource_hash(const void *data, u32 len, u32 seed) +/* We keep an extra hash for each conntrack, for fast searching. */ +static unsigned int +hash_by_src(const struct net *n, const struct nf_conntrack_tuple *tuple) { - const struct nf_conntrack_tuple *t; - const struct nf_conn *ct = data; + unsigned int hash; + + get_random_once(&nf_nat_hash_rnd, sizeof(nf_nat_hash_rnd)); - t = &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple; /* Original src, to ensure we map it consistently if poss. */ + hash = jhash2((u32 *)&tuple->src, sizeof(tuple->src) / sizeof(u32), + tuple->dst.protonum ^ nf_nat_hash_rnd ^ net_hash_mix(n)); - seed ^= net_hash_mix(nf_ct_net(ct)); - return jhash2((const u32 *)&t->src, sizeof(t->src) / sizeof(u32), - t->dst.protonum ^ seed); + return reciprocal_scale(hash, nf_nat_htable_size); } /* Is this tuple already taken? (not by us) */ @@ -184,28 +184,6 @@ same_src(const struct nf_conn *ct, t->src.u.all == tuple->src.u.all); } -static int nf_nat_bysource_cmp(struct rhashtable_compare_arg *arg, - const void *obj) -{ - const struct nf_nat_conn_key *key = arg->key; - const struct nf_conn *ct = obj; - - if (!same_src(ct, key->tuple) || - !net_eq(nf_ct_net(ct), key->net) || - !nf_ct_zone_equal(ct, key->zone, IP_CT_DIR_ORIGINAL)) - return 1; - - return 0; -} - -static struct rhashtable_params nf_nat_bysource_params = { - .head_offset = offsetof(struct nf_conn, nat_bysource), - .obj_hashfn = nf_nat_bysource_hash, - .obj_cmpfn = nf_nat_bysource_cmp, - .nelem_hint = 256, - .min_size = 1024, -}; - /* Only called for SRC manip */ static int find_appropriate_src(struct net *net, @@ -216,26 +194,22 @@ find_appropriate_src(struct net *net, struct nf_conntrack_tuple *result, const struct nf_nat_range *range) { + unsigned int h = hash_by_src(net, tuple); const struct nf_conn *ct; - struct nf_nat_conn_key key = { - .net = net, - .tuple = tuple, - .zone = zone - }; - struct rhlist_head *hl, *h; - - hl = rhltable_lookup(&nf_nat_bysource_table, &key, - nf_nat_bysource_params); - rhl_for_each_entry_rcu(ct, h, hl, nat_bysource) { - nf_ct_invert_tuplepr(result, - &ct->tuplehash[IP_CT_DIR_REPLY].tuple); - result->dst = tuple->dst; + hlist_for_each_entry_rcu(ct, &nf_nat_bysource[h], nat_bysource) { + if (same_src(ct, tuple) && + net_eq(net, nf_ct_net(ct)) && + nf_ct_zone_equal(ct, zone, IP_CT_DIR_ORIGINAL)) { + /* Copy source part from reply tuple. */ + nf_ct_invert_tuplepr(result, + &ct->tuplehash[IP_CT_DIR_REPLY].tuple); + result->dst = tuple->dst; - if (in_range(l3proto, l4proto, result, range)) - return 1; + if (in_range(l3proto, l4proto, result, range)) + return 1; + } } - return 0; } @@ -408,6 +382,7 @@ nf_nat_setup_info(struct nf_conn *ct, const struct nf_nat_range *range, enum nf_nat_manip_type maniptype) { + struct net *net = nf_ct_net(ct); struct nf_conntrack_tuple curr_tuple, new_tuple; /* Can't setup nat info for confirmed ct. */ @@ -447,19 +422,14 @@ nf_nat_setup_info(struct nf_conn *ct, } if (maniptype == NF_NAT_MANIP_SRC) { - struct nf_nat_conn_key key = { - .net = nf_ct_net(ct), - .tuple = &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple, - .zone = nf_ct_zone(ct), - }; - int err; - - err = rhltable_insert_key(&nf_nat_bysource_table, - &key, - &ct->nat_bysource, - nf_nat_bysource_params); - if (err) - return NF_DROP; + unsigned int srchash; + + srchash = hash_by_src(net, + &ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple); + spin_lock_bh(&nf_nat_lock); + hlist_add_head_rcu(&ct->nat_bysource, + &nf_nat_bysource[srchash]); + spin_unlock_bh(&nf_nat_lock); } /* It's done. */ @@ -568,8 +538,9 @@ static int nf_nat_proto_clean(struct nf_ * will delete entry from already-freed table. */ clear_bit(IPS_SRC_NAT_DONE_BIT, &ct->status); - rhltable_remove(&nf_nat_bysource_table, &ct->nat_bysource, - nf_nat_bysource_params); + spin_lock_bh(&nf_nat_lock); + hlist_del_rcu(&ct->nat_bysource); + spin_unlock_bh(&nf_nat_lock); /* don't delete conntrack. Although that would make things a lot * simpler, we'd end up flushing all conntracks on nat rmmod. @@ -697,9 +668,11 @@ EXPORT_SYMBOL_GPL(nf_nat_l3proto_unregis /* No one using conntrack by the time this called. */ static void nf_nat_cleanup_conntrack(struct nf_conn *ct) { - if (ct->status & IPS_SRC_NAT_DONE) - rhltable_remove(&nf_nat_bysource_table, &ct->nat_bysource, - nf_nat_bysource_params); + if (ct->status & IPS_SRC_NAT_DONE) { + spin_lock_bh(&nf_nat_lock); + hlist_del_rcu(&ct->nat_bysource); + spin_unlock_bh(&nf_nat_lock); + } } static struct nf_ct_ext_type nat_extend __read_mostly = { @@ -823,13 +796,16 @@ static int __init nf_nat_init(void) { int ret; - ret = rhltable_init(&nf_nat_bysource_table, &nf_nat_bysource_params); - if (ret) - return ret; + /* Leave them the same for the moment. */ + nf_nat_htable_size = nf_conntrack_htable_size; + + nf_nat_bysource = nf_ct_alloc_hashtable(&nf_nat_htable_size, 0); + if (!nf_nat_bysource) + return -ENOMEM; ret = nf_ct_extend_register(&nat_extend); if (ret < 0) { - rhltable_destroy(&nf_nat_bysource_table); + nf_ct_free_hashtable(nf_nat_bysource, nf_nat_htable_size); printk(KERN_ERR "nf_nat_core: Unable to register extension\n"); return ret; } @@ -863,8 +839,8 @@ static void __exit nf_nat_cleanup(void) for (i = 0; i < NFPROTO_NUMPROTO; i++) kfree(nf_nat_l4protos[i]); - - rhltable_destroy(&nf_nat_bysource_table); + synchronize_net(); + nf_ct_free_hashtable(nf_nat_bysource, nf_nat_htable_size); } MODULE_LICENSE("GPL"); Patches currently in stable-queue which might be from fw(a)strlen.de are queue-4.13/netfilter-nat-revert-netfilter-nat-convert-nat-bysrc-hash-to-rhashtable.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "KEYS: trusted: sanitize all key material" 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 KEYS: trusted: sanitize all key material 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: keys-trusted-sanitize-all-key-material.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 ee618b4619b72527aaed765f0f0b74072b281159 Mon Sep 17 00:00:00 2001 From: Eric Biggers <ebiggers(a)google.com> Date: Thu, 8 Jun 2017 14:49:18 +0100 Subject: KEYS: trusted: sanitize all key material From: Eric Biggers <ebiggers(a)google.com> commit ee618b4619b72527aaed765f0f0b74072b281159 upstream. As the previous patch did for encrypted-keys, zero sensitive any potentially sensitive data related to the "trusted" key type before it is freed. Notably, we were not zeroing the tpm_buf structures in which the actual key is stored for TPM seal and unseal, nor were we zeroing the trusted_key_payload in certain error paths. Cc: Mimi Zohar <zohar(a)linux.vnet.ibm.com> Cc: David Safford <safford(a)us.ibm.com> Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Signed-off-by: James Morris <james.l.morris(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- security/keys/trusted.c | 35 +++++++++++++++++------------------ 1 file changed, 17 insertions(+), 18 deletions(-) --- a/security/keys/trusted.c +++ b/security/keys/trusted.c @@ -69,7 +69,7 @@ static int TSS_sha1(const unsigned char } ret = crypto_shash_digest(&sdesc->shash, data, datalen, digest); - kfree(sdesc); + kzfree(sdesc); return ret; } @@ -113,7 +113,7 @@ static int TSS_rawhmac(unsigned char *di if (!ret) ret = crypto_shash_final(&sdesc->shash, digest); out: - kfree(sdesc); + kzfree(sdesc); return ret; } @@ -164,7 +164,7 @@ static int TSS_authhmac(unsigned char *d paramdigest, TPM_NONCE_SIZE, h1, TPM_NONCE_SIZE, h2, 1, &c, 0, 0); out: - kfree(sdesc); + kzfree(sdesc); return ret; } @@ -245,7 +245,7 @@ static int TSS_checkhmac1(unsigned char if (memcmp(testhmac, authdata, SHA1_DIGEST_SIZE)) ret = -EINVAL; out: - kfree(sdesc); + kzfree(sdesc); return ret; } @@ -346,7 +346,7 @@ static int TSS_checkhmac2(unsigned char if (memcmp(testhmac2, authdata2, SHA1_DIGEST_SIZE)) ret = -EINVAL; out: - kfree(sdesc); + kzfree(sdesc); return ret; } @@ -563,7 +563,7 @@ static int tpm_seal(struct tpm_buf *tb, *bloblen = storedsize; } out: - kfree(td); + kzfree(td); return ret; } @@ -677,7 +677,7 @@ static int key_seal(struct trusted_key_p if (ret < 0) pr_info("trusted_key: srkseal failed (%d)\n", ret); - kfree(tb); + kzfree(tb); return ret; } @@ -702,7 +702,7 @@ static int key_unseal(struct trusted_key /* pull migratable flag out of sealed key */ p->migratable = p->key[--p->key_len]; - kfree(tb); + kzfree(tb); return ret; } @@ -961,12 +961,12 @@ static int trusted_instantiate(struct ke if (!ret && options->pcrlock) ret = pcrlock(options->pcrlock); out: - kfree(datablob); - kfree(options); + kzfree(datablob); + kzfree(options); if (!ret) rcu_assign_keypointer(key, payload); else - kfree(payload); + kzfree(payload); return ret; } @@ -975,8 +975,7 @@ static void trusted_rcu_free(struct rcu_ struct trusted_key_payload *p; p = container_of(rcu, struct trusted_key_payload, rcu); - memset(p->key, 0, p->key_len); - kfree(p); + kzfree(p); } /* @@ -1018,7 +1017,7 @@ static int trusted_update(struct key *ke ret = datablob_parse(datablob, new_p, new_o); if (ret != Opt_update) { ret = -EINVAL; - kfree(new_p); + kzfree(new_p); goto out; } /* copy old key values, and reseal with new pcrs */ @@ -1031,22 +1030,22 @@ static int trusted_update(struct key *ke ret = key_seal(new_p, new_o); if (ret < 0) { pr_info("trusted_key: key_seal failed (%d)\n", ret); - kfree(new_p); + kzfree(new_p); goto out; } if (new_o->pcrlock) { ret = pcrlock(new_o->pcrlock); if (ret < 0) { pr_info("trusted_key: pcrlock failed (%d)\n", ret); - kfree(new_p); + kzfree(new_p); goto out; } } rcu_assign_keypointer(key, new_p); call_rcu(&p->rcu, trusted_rcu_free); out: - kfree(datablob); - kfree(new_o); + kzfree(datablob); + kzfree(new_o); return ret; } Patches currently in stable-queue which might be from ebiggers(a)google.com are queue-3.18/keys-trusted-sanitize-all-key-material.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] FAILED: patch "[PATCH] KEYS: trusted: fix writing past end of buffer in" failed to apply to 3.18-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 3.18-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 a3c812f7cfd80cf51e8f5b7034f7418f6beb56c1 Mon Sep 17 00:00:00 2001 From: Eric Biggers <ebiggers(a)google.com> Date: Thu, 2 Nov 2017 00:47:12 +0000 Subject: [PATCH] KEYS: trusted: fix writing past end of buffer in trusted_read() When calling keyctl_read() on a key of type "trusted", if the user-supplied buffer was too small, the kernel ignored the buffer length and just wrote past the end of the buffer, potentially corrupting userspace memory. Fix it by instead returning the size required, as per the documentation for keyctl_read(). We also don't even fill the buffer at all in this case, as this is slightly easier to implement than doing a short read, and either behavior appears to be permitted. It also makes it match the behavior of the "encrypted" key type. Fixes: d00a1c72f7f4 ("keys: add new trusted key-type") Reported-by: Ben Hutchings <ben(a)decadent.org.uk> Cc: <stable(a)vger.kernel.org> # v2.6.38+ Signed-off-by: Eric Biggers <ebiggers(a)google.com> Signed-off-by: David Howells <dhowells(a)redhat.com> Reviewed-by: Mimi Zohar <zohar(a)linux.vnet.ibm.com> Reviewed-by: James Morris <james.l.morris(a)oracle.com> Signed-off-by: James Morris <james.l.morris(a)oracle.com> diff --git a/security/keys/trusted.c b/security/keys/trusted.c index bd85315cbfeb..98aa89ff7bfd 100644 --- a/security/keys/trusted.c +++ b/security/keys/trusted.c @@ -1147,20 +1147,21 @@ static long trusted_read(const struct key *key, char __user *buffer, p = dereference_key_locked(key); if (!p) return -EINVAL; - if (!buffer || buflen <= 0) - return 2 * p->blob_len; - ascii_buf = kmalloc(2 * p->blob_len, GFP_KERNEL); - if (!ascii_buf) - return -ENOMEM; - bufp = ascii_buf; - for (i = 0; i < p->blob_len; i++) - bufp = hex_byte_pack(bufp, p->blob[i]); - if ((copy_to_user(buffer, ascii_buf, 2 * p->blob_len)) != 0) { + if (buffer && buflen >= 2 * p->blob_len) { + ascii_buf = kmalloc(2 * p->blob_len, GFP_KERNEL); + if (!ascii_buf) + return -ENOMEM; + + bufp = ascii_buf; + for (i = 0; i < p->blob_len; i++) + bufp = hex_byte_pack(bufp, p->blob[i]); + if (copy_to_user(buffer, ascii_buf, 2 * p->blob_len) != 0) { + kzfree(ascii_buf); + return -EFAULT; + } kzfree(ascii_buf); - return -EFAULT; } - kzfree(ascii_buf); return 2 * p->blob_len; }

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Please integrate commit 2b02c20 (cdc_ncm) into 4.4

by Porto Rio

Hello, please integrate/backport the following commit into stable kernel release 4.4: Commit-ID: 2b02c20ce0c28974b44e69a2e2f5ddc6a470ad6f (see https://github.com/torvalds/linux/commit/2b02c20ce0c28974b44e69a2e2f5ddc6a4…) Subject: "cdc_ncm: Set NTB format again after altsetting switch for Huawei devices" (The patch has been submitted and merged into the mainline.) We regard this commit as a fix/workaround for a change in firmware behavior observed in some recent huawei devices (e.g.: Huawei MS2131 LTE stick). As these devices are unusable with the 4.4.x LTS kernel we suggest to include this workarround as there will be more and more LTE sticks to expect until EOS in 2022... See also the mail below of the originator of the commit. (It may also make sense to integrate it into the other stable kernel release) Thank you very much! Kind regards, Matthias ---- Sender: Enrico Mioso <mrkiko.rs(a)gmail.com> Date: 08.11.2017 23:21 Subject: Re: Question regarding commit: cdc_ncm: Set NTB format again after altsetting switch for Huawei devices Hello Mathias. First of all, thank you for your interest in huawei_cdc_ncm driver and contacting me. This commit could be backported to 4.4 kernel, I didn't send that to stable(a)vger.kernel.org . Let me know if there are any difficulties doing so. Or I might do the submission in some days. I think that commit could be related to a bug: even if it's arguable. That bug infact, is not related to the Linux kernel itself, but to the huawei firmware. So I don't think there will be a bug tracker entry. Thanks for all, Enrico

7 years, 7 months

2
1
0 0

Re: [Linux-stable-mirror] [PATCH 2/3] IB/core: disable memory registration of fileystem-dax vmas

by Christoph Hellwig

On Mon, Nov 06, 2017 at 04:57:21PM -0800, Dan Williams wrote: > Until there is a solution to the dma-to-dax vs truncate problem it is > not safe to allow RDMA to create long standing memory registrations > against filesytem-dax vmas. Looks good: Reviewed-by: Christoph Hellwig <hch(a)lst.de>

7 years, 7 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH 1/3] mm: introduce get_user_pages_longterm

by Christoph Hellwig

> +long get_user_pages_longterm(unsigned long start, unsigned long nr_pages, > + unsigned int gup_flags, struct page **pages, > + struct vm_area_struct **vmas) > +{ > + struct vm_area_struct **__vmas = vmas; How about calling the vma argument vma_arg, and the one used vma to make thigns a little more readable? > + struct vm_area_struct *vma_prev = NULL; > + long rc, i; > + > + if (!pages) > + return -EINVAL; > + > + if (!vmas && IS_ENABLED(CONFIG_FS_DAX)) { > + __vmas = kzalloc(sizeof(struct vm_area_struct *) * nr_pages, > + GFP_KERNEL); > + if (!__vmas) > + return -ENOMEM; > + } > + > + rc = get_user_pages(start, nr_pages, gup_flags, pages, __vmas); > + > + /* skip scan for fs-dax vmas if they are compile time disabled */ > + if (!IS_ENABLED(CONFIG_FS_DAX)) > + goto out; Instead of all this IS_ENABLED magic I'd recomment to just conditionally compile this function and define it to get_user_pages in the header if FS_DAX is disabled. Else this looks fine to me.

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [RFC PATCH] mm: fix device-dax pud write-faults triggered by get_user_pages()

by Dan Williams

Currently only get_user_pages_fast() can safely handle the writable gup case due to its use of pud_access_permitted() to check whether the pud entry is writable. In the gup slow path pud_write() is used instead of pud_access_permitted() and to date it has been unimplemented, just calls BUG_ON(). kernel BUG at ./include/linux/hugetlb.h:244! [..] RIP: 0010:follow_devmap_pud+0x482/0x490 [..] Call Trace: follow_page_mask+0x28c/0x6e0 __get_user_pages+0xe4/0x6c0 get_user_pages_unlocked+0x130/0x1b0 get_user_pages_fast+0x89/0xb0 iov_iter_get_pages_alloc+0x114/0x4a0 nfs_direct_read_schedule_iovec+0xd2/0x350 ? nfs_start_io_direct+0x63/0x70 nfs_file_direct_read+0x1e0/0x250 nfs_file_read+0x90/0xc0 Use pud_access_permitted() to implement pud_write(), a later cleanup can remove {pte,pmd,pud}_write and replace them with {pte,pmd,pud}_access_permitted() drectly so that we only have one set of helpers these kinds of checks. For now, implementing pud_write() simplifies -stable backports. Cc: <stable(a)vger.kernel.org> Cc: Dave Hansen <dave.hansen(a)intel.com> Fixes: a00cc7d9dd93 ("mm, x86: add support for PUD-sized transparent hugepages") Signed-off-by: Dan Williams <dan.j.williams(a)intel.com> --- Sending this as RFC for opinion on whether this should just be a pud_flags() & _PAGE_RW check, like pmd_write, or pud_access_permitted() that also takes protection keys into account. include/linux/hugetlb.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h index fbf5b31d47ee..6a142b240ef7 100644 --- a/include/linux/hugetlb.h +++ b/include/linux/hugetlb.h @@ -242,8 +242,7 @@ static inline int pgd_write(pgd_t pgd) #ifndef pud_write static inline int pud_write(pud_t pud) { - BUG(); - return 0; + return pud_access_permitted(pud, WRITE); } #endif

7 years, 7 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH] blk-mq: respect queue dead via blk_mq_quiesce_queue

by Ming Lei

On Sun, Nov 05, 2017 at 08:10:08PM +0800, Ming Lei wrote: > blk-mq never respects queue dead, and this may cause use-after-free on > any kind of queue resources. This patch respects the rule by calling > blk_mq_quiesce_queue() when queue is marked as DEAD. > > This patch fixes the following kernel crash: > > [ 42.170824] BUG: unable to handle kernel NULL pointer dereference at (null) > [ 42.172011] IP: blk_mq_flush_busy_ctxs+0x5a/0xe0 > [ 42.172011] PGD 25d8d1067 P4D 25d8d1067 PUD 25d458067 PMD 0 > [ 42.172011] Oops: 0000 [#1] PREEMPT SMP > [ 42.172011] Dumping ftrace buffer: > [ 42.172011] (ftrace buffer empty) > [ 42.172011] Modules linked in: scsi_debug ebtable_filter ebtables ip6table_filter ip6_tables xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack libcrc32c bridge stp llc fuse iptable_filter ip_tables sd_mod sg mptsas mptscsih mptbase crc32c_intel scsi_transport_sas nvme lpc_ich serio_raw ahci virtio_scsi libahci libata nvme_core binfmt_misc dm_mod iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi null_blk configs > [ 42.172011] CPU: 0 PID: 2750 Comm: fio Not tainted 4.14.0-rc7.blk_mq_io_hang+ #507 > [ 42.172011] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.9.3-1.fc25 04/01/2014 > [ 42.172011] task: ffff88025dc18000 task.stack: ffffc900028c4000 > [ 42.172011] RIP: 0010:blk_mq_flush_busy_ctxs+0x5a/0xe0 > [ 42.172011] RSP: 0018:ffffc900028c7be0 EFLAGS: 00010246 > [ 42.172011] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff8802775907c8 > [ 42.172011] RDX: 0000000000000000 RSI: ffffc900028c7c50 RDI: ffff88025de25c00 > [ 42.172011] RBP: ffffc900028c7c28 R08: 0000000000000000 R09: ffff8802595692c0 > [ 42.172011] R10: ffffc900028c7e50 R11: 0000000000000008 R12: ffffc900028c7c50 > [ 42.172011] R13: ffff88025de25cd8 R14: ffffc900028c7d78 R15: ffff88025de25c00 > [ 42.172011] FS: 00007faa8653f7c0(0000) GS:ffff88027fc00000(0000) knlGS:0000000000000000 > [ 42.172011] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 42.172011] CR2: 0000000000000000 CR3: 00000002593df006 CR4: 00000000003606f0 > [ 42.172011] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 42.172011] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 > [ 42.172011] Call Trace: > [ 42.172011] blk_mq_sched_dispatch_requests+0x1b4/0x1f0 > [ 42.172011] ? preempt_schedule+0x27/0x30 > [ 42.172011] __blk_mq_run_hw_queue+0x8b/0xa0 > [ 42.172011] __blk_mq_delay_run_hw_queue+0xb7/0x100 > [ 42.172011] blk_mq_run_hw_queue+0x14/0x20 > [ 42.172011] blk_mq_sched_insert_requests+0xda/0x120 > [ 42.172011] blk_mq_flush_plug_list+0x179/0x280 > [ 42.172011] blk_flush_plug_list+0x102/0x290 > [ 42.172011] blk_finish_plug+0x2c/0x40 > [ 42.172011] do_io_submit+0x3fa/0x780 > [ 42.172011] SyS_io_submit+0x10/0x20 > [ 42.172011] ? SyS_io_submit+0x10/0x20 > [ 42.172011] entry_SYSCALL_64_fastpath+0x1a/0xa5 > [ 42.172011] RIP: 0033:0x7faa80ff8697 > [ 42.172011] RSP: 002b:00007ffe08236de8 EFLAGS: 00000206 ORIG_RAX: 00000000000000d1 > [ 42.172011] RAX: ffffffffffffffda RBX: 0000000001f1e600 RCX: 00007faa80ff8697 > [ 42.172011] RDX: 000000000208e638 RSI: 0000000000000001 RDI: 00007faa6ecae000 > [ 42.172011] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000001f1e0e0 > [ 42.172011] R10: 0000000000000001 R11: 0000000000000206 R12: 00007faa614f19e0 > [ 42.172011] R13: 00007faa614ff0b0 R14: 00007faa614fef50 R15: 0000000100000000 > [ 42.172011] Code: e0 00 00 00 c7 45 bc 00 00 00 00 85 c0 74 76 4c 8d af d8 00 00 00 49 89 ff 44 8b 45 bc 4c 89 c0 49 c1 e0 06 4d 03 87 e8 00 00 00 <49> 83 38 00 4d 89 c6 74 41 41 8b 8f dc 00 00 00 41 89 c4 31 db > [ 42.172011] RIP: blk_mq_flush_busy_ctxs+0x5a/0xe0 RSP: ffffc900028c7be0 > [ 42.172011] CR2: 0000000000000000 > [ 42.172011] ---[ end trace 2432dfddf9b84061 ]--- > [ 42.172011] Kernel panic - not syncing: Fatal exception > [ 42.172011] Dumping ftrace buffer: > [ 42.172011] (ftrace buffer empty) > [ 42.172011] Kernel Offset: disabled > [ 42.172011] ---[ end Kernel panic - not syncing: Fatal exception > > Cc: stable(a)vger.kernel.org > Signed-off-by: Ming Lei <ming.lei(a)redhat.com> > --- > block/blk-core.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/block/blk-core.c b/block/blk-core.c > index 048be4aa6024..0b121f29e3b1 100644 > --- a/block/blk-core.c > +++ b/block/blk-core.c > @@ -658,6 +658,10 @@ void blk_cleanup_queue(struct request_queue *q) > queue_flag_set(QUEUE_FLAG_DEAD, q); > spin_unlock_irq(lock); > > + /* respect queue DEAD via quiesce for blk-mq */ > + if (q->mq_ops) > + blk_mq_quiesce_queue(q); > + > /* for synchronous bio-based driver finish in-flight integrity i/o */ > blk_flush_integrity(); Hi Jens, Could you consider this patch? This issue can be reproduced easily in heavy IO and device remove test on SCSI. -- Ming

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] [PATCH v2 04/17] lpfc: Fix crash after bad bar setup on driver attachment

by James Smart

In test cases where an instance of the driver is detached and reattached, the driver will crash on reattachment. There is a compound if statement that will skip over the bar setup if the pci_resource_start call is not successful. The driver erroneously returns success to its bar setup in this scenario even though the bars aren't properly configured. Rework the offending code segment for proper initialization steps. If the pci_resource_start call fails, -ENOMEM is now returned. Sample stack: rport-5:0-10: blocked FC remote port time out: removing rport BUG: unable to handle kernel NULL pointer dereference at (null) ... lpfc_sli4_wait_bmbx_ready+0x32/0x70 [lpfc] ... ... RIP: 0010:... ... lpfc_sli4_wait_bmbx_ready+0x32/0x70 [lpfc] Call Trace: ... lpfc_sli4_post_sync_mbox+0x106/0x4d0 [lpfc] ... ? __alloc_pages_nodemask+0x176/0x420 ... ? __kmalloc+0x2e/0x230 ... lpfc_sli_issue_mbox_s4+0x533/0x720 [lpfc] ... ? mempool_alloc+0x69/0x170 ... ? dma_generic_alloc_coherent+0x8f/0x140 ... lpfc_sli_issue_mbox+0xf/0x20 [lpfc] ... lpfc_sli4_driver_resource_setup+0xa6f/0x1130 [lpfc] ... ? lpfc_pci_probe_one+0x23e/0x16f0 [lpfc] ... lpfc_pci_probe_one+0x445/0x16f0 [lpfc] ... local_pci_probe+0x45/0xa0 ... work_for_cpu_fn+0x14/0x20 ... process_one_work+0x17a/0x440 Cc: <stable(a)vger.kernel.org> # 4.12+ Signed-off-by: Dick Kennedy <dick.kennedy(a)broadcom.com> Signed-off-by: James Smart <james.smart(a)broadcom.com> Reviewed-by: Hannes Reinecke <hare(a)suse.com> --- drivers/scsi/lpfc/lpfc_init.c | 84 ++++++++++++++++++++++++++----------------- 1 file changed, 51 insertions(+), 33 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_init.c b/drivers/scsi/lpfc/lpfc_init.c index 745aff753396..fc9f91327724 100644 --- a/drivers/scsi/lpfc/lpfc_init.c +++ b/drivers/scsi/lpfc/lpfc_init.c @@ -9437,44 +9437,62 @@ lpfc_sli4_pci_mem_setup(struct lpfc_hba *phba) lpfc_sli4_bar0_register_memmap(phba, if_type); } - if ((if_type == LPFC_SLI_INTF_IF_TYPE_0) && - (pci_resource_start(pdev, PCI_64BIT_BAR2))) { - /* - * Map SLI4 if type 0 HBA Control Register base to a kernel - * virtual address and setup the registers. - */ - phba->pci_bar1_map = pci_resource_start(pdev, PCI_64BIT_BAR2); - bar1map_len = pci_resource_len(pdev, PCI_64BIT_BAR2); - phba->sli4_hba.ctrl_regs_memmap_p = - ioremap(phba->pci_bar1_map, bar1map_len); - if (!phba->sli4_hba.ctrl_regs_memmap_p) { - dev_printk(KERN_ERR, &pdev->dev, - "ioremap failed for SLI4 HBA control registers.\n"); + if (if_type == LPFC_SLI_INTF_IF_TYPE_0) { + if (pci_resource_start(pdev, PCI_64BIT_BAR2)) { + /* + * Map SLI4 if type 0 HBA Control Register base to a + * kernel virtual address and setup the registers. + */ + phba->pci_bar1_map = pci_resource_start(pdev, + PCI_64BIT_BAR2); + bar1map_len = pci_resource_len(pdev, PCI_64BIT_BAR2); + phba->sli4_hba.ctrl_regs_memmap_p = + ioremap(phba->pci_bar1_map, + bar1map_len); + if (!phba->sli4_hba.ctrl_regs_memmap_p) { + dev_err(&pdev->dev, + "ioremap failed for SLI4 HBA " + "control registers.\n"); + error = -ENOMEM; + goto out_iounmap_conf; + } + phba->pci_bar2_memmap_p = + phba->sli4_hba.ctrl_regs_memmap_p; + lpfc_sli4_bar1_register_memmap(phba); + } else { + error = -ENOMEM; goto out_iounmap_conf; } - phba->pci_bar2_memmap_p = phba->sli4_hba.ctrl_regs_memmap_p; - lpfc_sli4_bar1_register_memmap(phba); } - if ((if_type == LPFC_SLI_INTF_IF_TYPE_0) && - (pci_resource_start(pdev, PCI_64BIT_BAR4))) { - /* - * Map SLI4 if type 0 HBA Doorbell Register base to a kernel - * virtual address and setup the registers. - */ - phba->pci_bar2_map = pci_resource_start(pdev, PCI_64BIT_BAR4); - bar2map_len = pci_resource_len(pdev, PCI_64BIT_BAR4); - phba->sli4_hba.drbl_regs_memmap_p = - ioremap(phba->pci_bar2_map, bar2map_len); - if (!phba->sli4_hba.drbl_regs_memmap_p) { - dev_printk(KERN_ERR, &pdev->dev, - "ioremap failed for SLI4 HBA doorbell registers.\n"); - goto out_iounmap_ctrl; - } - phba->pci_bar4_memmap_p = phba->sli4_hba.drbl_regs_memmap_p; - error = lpfc_sli4_bar2_register_memmap(phba, LPFC_VF0); - if (error) + if (if_type == LPFC_SLI_INTF_IF_TYPE_0) { + if (pci_resource_start(pdev, PCI_64BIT_BAR4)) { + /* + * Map SLI4 if type 0 HBA Doorbell Register base to + * a kernel virtual address and setup the registers. + */ + phba->pci_bar2_map = pci_resource_start(pdev, + PCI_64BIT_BAR4); + bar2map_len = pci_resource_len(pdev, PCI_64BIT_BAR4); + phba->sli4_hba.drbl_regs_memmap_p = + ioremap(phba->pci_bar2_map, + bar2map_len); + if (!phba->sli4_hba.drbl_regs_memmap_p) { + dev_err(&pdev->dev, + "ioremap failed for SLI4 HBA" + " doorbell registers.\n"); + error = -ENOMEM; + goto out_iounmap_ctrl; + } + phba->pci_bar4_memmap_p = + phba->sli4_hba.drbl_regs_memmap_p; + error = lpfc_sli4_bar2_register_memmap(phba, LPFC_VF0); + if (error) + goto out_iounmap_all; + } else { + error = -ENOMEM; goto out_iounmap_all; + } } return 0; -- 2.13.1

7 years, 7 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH v3] scsi: require CAP_SYS_ADMIN to write to procfs interface

by ebiederm＠xmission.com

Aleksa Sarai <asarai(a)suse.de> writes: > On 11/05/2017 01:56 PM, Aleksa Sarai wrote: >> Previously, the only capability effectively required to operate on the >> /proc/scsi interface was CAP_DAC_OVERRIDE (or for some other files, >> having an fsuid of GLOBAL_ROOT_UID was enough). This means that >> semi-privileged processes could interfere with core components of a >> system (such as causing a DoS by removing the underlying SCSI device of >> the host's / mount). > > An alternative to this patch would be to make the open(2) call fail, if you try > to open it write-only or read-write. Not sure which would be preferred (should > it be possible to pass /proc/scsi/scsi to a semi-privileged process to write > to?). Making open fail is very much the preferred solution. Testing for permission on write can be avoided by finding a suid root application whose error output acts like a suid cat. The best current practice for adding this kind of permission check is to add the check in open. For some older use cases where we made this mistake we had to maintian a check during write to avoid breaking userspace. But as this check is new there is no reason to add a check anywhere except in open. Eric

7 years, 7 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH 3.16 000/294] 3.16.50-rc1 review

by Guenter Roeck

On Thu, Nov 09, 2017 at 04:59:58PM +0000, Ben Hutchings wrote: > On Thu, 2017-11-09 at 08:03 -0800, Guenter Roeck wrote: > > On Thu, Nov 09, 2017 at 12:40:36PM +0000, Ben Hutchings wrote: > > > On Thu, 2017-11-09 at 13:21 +0100, Arnd Bergmann wrote: > > > > On Thu, Nov 9, 2017 at 1:08 PM, Greg KH <greg(a)kroah.com> wrote: > > > > > On Thu, Nov 09, 2017 at 12:55:30PM +0100, Arnd Bergmann wrote: > > > > > > [...] > > > > > > I think if you upload the branch to the stable-rc git, that should produce > > > > > > the automated build and boot results via email or via the > > > > > > https://kernelci.org/job/ interface. Once there are some results > > > > > > there, I'll go through the list once more to see what warnings > > > > > > and failures remain. > > > > > > > > > > I don't know of a way to have others push to that tree/branch at the > > > > > moment :( > > > > > > > > > > I'll go update that branch now... > > > > > > > > Thanks! > > > > > > > > With the arm-soc tree, we simply have a shared group-id on > > > > gitolite.kernel.org and everyone in that group can push to it. > > > > > > > > If that is the only thing you need, it should be trivial to let Ben > > > > and Sasha push to /pub/scm/linux/kernel/git/stable/*.git as well, > > > > I'm sure helpdesk(a)kernel.org can arrange that. Of course if you are > > > > worried about having multiple accounts with write access to all the > > > > branches, then that wouldn't be enough. > > > > > > I think I'd rather send a pull request to Greg at the start of the > > > review period. > > > > > > > If you change the trees I am supposed to pull from for my builders, > > please let me know. > > If you're happy to keep supporting quilt-in-git then there's no change. > I check your builders page and try to fix up build failures before even > making a release candidate. > Ah yes, kernelci won't pick that up. No problem to keep kerneltests going as long as it adds value. Guenter

7 years, 7 months

1
0
0 0

Re: [Linux-stable-mirror] [PATCH] net: mvneta: fix handling of the Tx descriptor counter

by Andreas Tobler

Hi Simon, On 08.11.17 18:17, Simon Guinot wrote: > Hi Sven and Andreas, > > Please, can you try with this patch ? Today we, my son and I, repeated the failing scenario and we were able to show that our scenario behaves stable after you patch being applied. Thanks for taking care of this issue. If you need further testing let me know. Regards, Andreas > On Wed, Nov 08, 2017 at 05:58:35PM +0100, Simon Guinot wrote: >> The mvneta controller provides a 8-bit register to update the pending >> Tx descriptor counter. Then, a maximum of 255 Tx descriptors can be >> added at once. In the current code the mvneta_txq_pend_desc_add function >> assumes the caller takes care of this limit. But it is not the case. In >> some situations (xmit_more flag), more than 255 descriptors are added. >> When this happens, the Tx descriptor counter register is updated with a >> wrong value, which breaks the whole Tx queue management. >> >> This patch fixes the issue by allowing the mvneta_txq_pend_desc_add >> function to process more than 255 Tx descriptors. >> >> Fixes: 2a90f7e1d5d0 ("net: mvneta: add xmit_more support") >> Cc: stable(a)vger.kernel.org # 4.11+ >> Signed-off-by: Simon Guinot <simon.guinot(a)sequanux.org> >> --- >> drivers/net/ethernet/marvell/mvneta.c | 16 +++++++++------- >> 1 file changed, 9 insertions(+), 7 deletions(-) >> >> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c >> index 64a04975bcf8..027c08ce4e5d 100644 >> --- a/drivers/net/ethernet/marvell/mvneta.c >> +++ b/drivers/net/ethernet/marvell/mvneta.c >> @@ -816,11 +816,14 @@ static void mvneta_txq_pend_desc_add(struct mvneta_port *pp, >> { >> u32 val; >> >> - /* Only 255 descriptors can be added at once ; Assume caller >> - * process TX desriptors in quanta less than 256 >> - */ >> - val = pend_desc + txq->pending; >> - mvreg_write(pp, MVNETA_TXQ_UPDATE_REG(txq->id), val); >> + pend_desc += txq->pending; >> + >> + /* Only 255 Tx descriptors can be added at once */ >> + while (pend_desc > 0) { >> + val = min(pend_desc, 255); >> + mvreg_write(pp, MVNETA_TXQ_UPDATE_REG(txq->id), val); >> + pend_desc -= val; >> + } >> txq->pending = 0; >> } >> >> @@ -2413,8 +2416,7 @@ static int mvneta_tx(struct sk_buff *skb, struct net_device *dev) >> if (txq->count >= txq->tx_stop_threshold) >> netif_tx_stop_queue(nq); >> >> - if (!skb->xmit_more || netif_xmit_stopped(nq) || >> - txq->pending + frags > MVNETA_TXQ_DEC_SENT_MASK) >> + if (!skb->xmit_more || netif_xmit_stopped(nq)) >> mvneta_txq_pend_desc_add(pp, txq, frags); >> else >> txq->pending += frags; >> -- >> 2.9.3

7 years, 7 months

1
0
0 0

Re: [Linux-stable-mirror] [4.4, 06/28] rcu: Allow for page faults in NMI handlers

by Ben Hutchings

On Mon, 2017-10-16 at 18:11 +0200, gregkh(a)linuxfoundation.org wrote: > 4.4-stable review patch. If anyone has any objections, please let me know. > > ------------------ > > From: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com> > > commit 28585a832602747cbfa88ad8934013177a3aae38 upstream. > > A number of architecture invoke rcu_irq_enter() on exception entry in > order to allow RCU read-side critical sections in the exception handler > when the exception is from an idle or nohz_full CPU. This works, at > least unless the exception happens in an NMI handler. In that case, > rcu_nmi_enter() would already have exited the extended quiescent state, > which would mean that rcu_irq_enter() would (incorrectly) cause RCU > to think that it is again in an extended quiescent state. This will > in turn result in lockdep splats in response to later RCU read-side > critical sections. > > This commit therefore causes rcu_irq_enter() and rcu_irq_exit() to > take no action if there is an rcu_nmi_enter() in effect, thus avoiding > the unscheduled return to RCU quiescent state. This in turn should > make the kernel safe for on-demand RCU voyeurism. > > Link: http://lkml.kernel.org/r/20170922211022.GA18084@linux.vnet.ibm.com > > Cc: stable(a)vger.kernel.org > Fixes: 0be964be0 ("module: Sanitize RCU usage and locking") > > Reported-by: Steven Rostedt <rostedt(a)goodmis.org> > > Signed-off-by: Paul E. McKenney <paulmck(a)linux.vnet.ibm.com> > > Signed-off-by: Steven Rostedt (VMware) <rostedt(a)goodmis.org> > > Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> > --- > kernel/rcu/tree.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > --- a/kernel/rcu/tree.c > +++ b/kernel/rcu/tree.c > @@ -759,6 +759,12 @@ void rcu_irq_exit(void) > > local_irq_save(flags); > rdtp = this_cpu_ptr(&rcu_dynticks); > + > + /* Page faults can happen in NMI handlers, so check... */ > + if (READ_ONCE(rdtp->dynticks_nmi_nesting)) > + return; Shouldn't there be a local_irq_restore() on this return path? Or does this condition imply that IRQs were already disabled? > + RCU_LOCKDEP_WARN(!irqs_disabled(), "rcu_irq_exit() invoked with irqs enabled!!!"); I don't see why you added RCU_LOCKDEP_WARN() here. Prior to 4.5 it's not an error to call this function with IRQs disabled. And after calling local_irq_save(), it's redundant to assert that IRQs are disabled. > oldval = rdtp->dynticks_nesting; > rdtp->dynticks_nesting--; > WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) && > @@ -887,6 +893,12 @@ void rcu_irq_enter(void) > > local_irq_save(flags); > rdtp = this_cpu_ptr(&rcu_dynticks); > + > + /* Page faults can happen in NMI handlers, so check... */ > + if (READ_ONCE(rdtp->dynticks_nmi_nesting)) > + return; > + > + RCU_LOCKDEP_WARN(!irqs_disabled(), "rcu_irq_enter() invoked with irqs enabled!!!"); Same problems here. Ben. > oldval = rdtp->dynticks_nesting; > rdtp->dynticks_nesting++; > WARN_ON_ONCE(IS_ENABLED(CONFIG_RCU_EQS_DEBUG) && -- Ben Hutchings Software Developer, Codethink Ltd.

7 years, 7 months

3
2
0 0

[Linux-stable-mirror] [PATCH v2] ASoC: sun8i-codec: Set the BCLK divider

by Maxime Ripard

While the current code was reporting to be able to work in master mode, it failed to do so because the BCLK divider wasn't programmed, meaning that the BCLK would run at the PLL's frequency no matter the sample rate. It was obviously a bit too fast. Add support to retrieve the divider to use, and set it. Since our PLL is not always able to generate a perfect multiple of the sample rate, we'll have to choose the closest divider that matches our setup. Fixes: 36c684936fae ("ASoC: Add sun8i digital audio codec") Cc: <stable(a)vger.kernel.org> Reviewed-by: Chen-Yu Tsai <wens(a)csie.org> Signed-off-by: Maxime Ripard <maxime.ripard(a)free-electrons.com> --- Changes from v1: - Hardcoded the bit width to remain consistent with the rest of the driver --- sound/soc/sunxi/sun8i-codec.c | 51 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) diff --git a/sound/soc/sunxi/sun8i-codec.c b/sound/soc/sunxi/sun8i-codec.c index c2ceca485d6a..7a312168f864 100644 --- a/sound/soc/sunxi/sun8i-codec.c +++ b/sound/soc/sunxi/sun8i-codec.c @@ -73,6 +73,7 @@ #define SUN8I_SYS_SR_CTRL_AIF2_FS_MASK GENMASK(11, 8) #define SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ_MASK GENMASK(5, 4) #define SUN8I_AIF1CLK_CTRL_AIF1_LRCK_DIV_MASK GENMASK(8, 6) +#define SUN8I_AIF1CLK_CTRL_AIF1_BCLK_DIV_MASK GENMASK(12, 9) struct sun8i_codec { struct device *dev; @@ -226,12 +227,57 @@ static int sun8i_set_fmt(struct snd_soc_dai *dai, unsigned int fmt) return 0; } +struct sun8i_codec_clk_div { + u8 div; + u8 val; +}; + +static const struct sun8i_codec_clk_div sun8i_codec_bclk_div[] = { + { .div = 1, .val = 0 }, + { .div = 2, .val = 1 }, + { .div = 4, .val = 2 }, + { .div = 6, .val = 3 }, + { .div = 8, .val = 4 }, + { .div = 12, .val = 5 }, + { .div = 16, .val = 6 }, + { .div = 24, .val = 7 }, + { .div = 32, .val = 8 }, + { .div = 48, .val = 9 }, + { .div = 64, .val = 10 }, + { .div = 96, .val = 11 }, + { .div = 128, .val = 12 }, + { .div = 192, .val = 13 }, +}; + +static u8 sun8i_codec_get_bclk_div(struct sun8i_codec *scodec, + unsigned int rate, + unsigned int word_size) +{ + unsigned long clk_rate = clk_get_rate(scodec->clk_module); + unsigned int div = clk_rate / rate / word_size / 2; + unsigned int best_val = 0, best_diff = ~0; + int i; + + for (i = 0; i < ARRAY_SIZE(sun8i_codec_bclk_div); i++) { + const struct sun8i_codec_clk_div *bdiv = &sun8i_codec_bclk_div[i]; + unsigned int diff = abs(bdiv->div - div); + + if (diff < best_diff) { + best_diff = diff; + best_val = bdiv->val; + } + } + + return best_val; +} + static int sun8i_codec_hw_params(struct snd_pcm_substream *substream, struct snd_pcm_hw_params *params, struct snd_soc_dai *dai) { struct sun8i_codec *scodec = snd_soc_codec_get_drvdata(dai->codec); int sample_rate; + u8 bclk_div; /* * The CPU DAI handles only a sample of 16 bits. Configure the @@ -241,6 +287,11 @@ static int sun8i_codec_hw_params(struct snd_pcm_substream *substream, SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ_MASK, SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ_16); + bclk_div = sun8i_codec_get_bclk_div(scodec, params_rate(params), 16); + regmap_update_bits(scodec->regmap, SUN8I_AIF1CLK_CTRL, + SUN8I_AIF1CLK_CTRL_AIF1_BCLK_DIV_MASK, + bclk_div << SUN8I_AIF1CLK_CTRL_AIF1_BCLK_DIV); + regmap_update_bits(scodec->regmap, SUN8I_AIF1CLK_CTRL, SUN8I_AIF1CLK_CTRL_AIF1_LRCK_DIV_MASK, SUN8I_AIF1CLK_CTRL_AIF1_LRCK_DIV_16); -- 2.14.3

7 years, 7 months

2
1
0 0

[Linux-stable-mirror] [GIT PULL] commits for Linux 4.4

by Levin, Alexander (Sasha Levin)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Greg, Pleae pull commits for Linux 4.4 . 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 c54d0707aa09a824413ebb4195c98bfb9b9e1fc0: Linux 4.4.97 (2017-11-08 10:06:31 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-stable.git for-greg-4.4-2 for you to fetch changes up to 2f948758f8adbf4e5f78506568f32ae6269a822d: net: dsa: select NET_SWITCHDEV (2017-11-08 15:35:51 -0500) - ---------------------------------------------------------------- Akinobu Mita (2): Input: mpr121 - handle multiple bits change of status register Input: mpr121 - set missing event capability Alison Schofield (1): iio: trigger: free trigger resource correctly David Lechner (2): dt-bindings: Add LEGO MINDSTORMS EV3 compatible specification dt-bindings: Add vendor prefix for LEGO Feras Daoud (1): IB/ipoib: Change list_del to list_del_init in the tx object Gilad Ben-Yossef (1): IPsec: do not ignore crypto err in ah4 input Harninder Rai (1): dt-bindings: clockgen: Add compatible string for LS1012A Jason Gunthorpe (1): PCI: mvebu: Handle changes to the bridge windows while enabled Juergen Gross (1): xen/netback: set default upper limit of tx/rx queues to 8 Julian Wiedmann (1): s390/qeth: issue STARTLAN as first IPA command Lars-Peter Clausen (1): [media] adv7604: Initialize drive strength to default when using DT Laurent Pinchart (1): serial: sh-sci: Fix register offsets for the IRDA serial port Li Zhong (2): KVM: PPC: Book 3S: XICS: correct the real mode ICP rejecting counter crypto: vmx - disable preemption to enable vsx in aes_ctr.c Liping Zhang (1): netfilter: nft_meta: deal with PACKET_LOOPBACK in netdev family Maciej W. Rozycki (1): video: fbdev: pmag-ba-fb: Remove bad `__init' annotation Nate Watterson (1): iommu/arm-smmu-v3: Clear prior settings when updating STEs Noralf TrÃ¸nnes (1): drm: drm_minor_register(): Clean up debugfs on failure Patrick Bruenn (1): ARM: dts: imx53-qsb-common: fix FEC pinmux config Tony Lindgren (1): ARM: omap2plus_defconfig: Fix probe errors on UARTs 5 and 6 Valentin Longchamp (1): powerpc/corenet: explicitly disable the SDHC controller on kmcoge4 Vivien Didelot (1): net: dsa: select NET_SWITCHDEV Volodymyr Bendiuga (1): phy: increase size of MII_BUS_ID_SIZE and bus_id William wu (1): usb: hcd: initialize hcd->flags to 0 when rm hcd Documentation/devicetree/bindings/arm/davinci.txt | 4 + .../devicetree/bindings/clock/qoriq-clock.txt | 1 + .../devicetree/bindings/vendor-prefixes.txt | 1 + arch/arm/boot/dts/imx53-qsb-common.dtsi | 20 ++-- arch/arm/configs/omap2plus_defconfig | 1 + arch/powerpc/boot/dts/fsl/kmcoge4.dts | 4 + arch/powerpc/kvm/book3s_hv_rm_xics.c | 5 +- arch/sh/kernel/cpu/sh3/setup-sh770x.c | 1 - drivers/crypto/vmx/aes_ctr.c | 6 ++ drivers/gpu/drm/drm_drv.c | 2 +- drivers/iio/trigger/iio-trig-interrupt.c | 8 +- drivers/iio/trigger/iio-trig-sysfs.c | 2 +- drivers/infiniband/ulp/ipoib/ipoib_cm.c | 2 +- drivers/input/keyboard/mpr121_touchkey.c | 24 +++-- drivers/iommu/arm-smmu-v3.c | 10 +- drivers/media/i2c/adv7604.c | 3 + drivers/net/xen-netback/netback.c | 6 +- drivers/pci/host/pci-mvebu.c | 101 ++++++++++++--------- drivers/s390/net/qeth_core.h | 1 - drivers/s390/net/qeth_core_main.c | 21 ++++- drivers/s390/net/qeth_l2_main.c | 15 --- drivers/s390/net/qeth_l3_main.c | 15 --- drivers/staging/iio/trigger/iio-trig-bfin-timer.c | 4 +- drivers/tty/serial/sh-sci.c | 17 ++-- drivers/usb/core/hcd.c | 1 + drivers/video/fbdev/pmag-ba-fb.c | 2 +- include/linux/phy.h | 8 +- net/dsa/Kconfig | 5 +- net/ipv4/ah4.c | 3 + net/netfilter/nft_meta.c | 28 +++++- 30 files changed, 184 insertions(+), 137 deletions(-) -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaA2zzAAoJEN6mb/eXdyzcFM0P/iZBjbrfPNDJYW73WHmz1fq0 s4WaAN0yOtt/rnLwBmzy6SohzIcwX8r/P5aJFh4Yyvw0U1X67KtQTZuzL/NM/gs8 iUpCJ5yFmK5+UUlA2aE8qwpBIobuzUvcS3Iy5ZT5j24hLOSPUQ0B7SvLycmZri78 RmvJzEn/f2fozaPDJkvf1YMJOMpf178gOk/XuIiIbaaLLKyfSjPdxm/OgTcmUrfy qYbJxfsI+VznY8bQF2UtBfcqtsS9aXoHQP//OmHXd3q6vvcQFDU/TpCLNP7XxIhM YIR1TGGGzX0uKYN7B93JpSuIBY+AZ4hECo3CTQ1FCszltcWyfaCQy8NrhWZbhwEr gO+v0s4pDCkuVP6sxHUUuQQ/O53cbmSCIZFwFSpB32zsskY6c1Y2ATvFV52Lpb2a M/ALRNJzNj5x/I/esxjgNX4DZ7F7Wql0iVTyAMjRy5SFrLE+/zAI7c/Ma1MVnQeZ PPXj2bdzdJE2UmGE5SwtewHSzVU0u/2UJ+a9FRpR+m36GiVUlmXckaCwCM0s1ein MAA/qWSvOgnWz6Eo8PGdG83nHSRmtiglflsv4/DO4uFKMB8ltcWzsFa8dknkEOag L4pwQZXxhDE62EnYW3gMJowjd6BNEj/ZrBXv9InObCEHsguhPJg5UK+sSL3gosMq +0jIGPSqGfnR7cWycde2 =PAvO -----END PGP SIGNATURE-----

7 years, 7 months

2
1
0 0

[Linux-stable-mirror] Patch "xen/netback: set default upper limit of tx/rx queues to 8" 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 xen/netback: set default upper limit of tx/rx queues to 8 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: xen-netback-set-default-upper-limit-of-tx-rx-queues-to-8.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 foo@baz Thu Nov 9 18:22:51 CET 2017 From: Juergen Gross <jgross(a)suse.com> Date: Tue, 10 Jan 2017 14:32:52 +0100 Subject: xen/netback: set default upper limit of tx/rx queues to 8 From: Juergen Gross <jgross(a)suse.com> [ Upstream commit 56dd5af9bc23d0d5d23bb207c477715b4c2216c5 ] The default for the maximum number of tx/rx queues of one interface is the number of cpus of the system today. As each queue pair reserves 512 grant pages this default consumes a ridiculous number of grants for large guests. Limit the queue number to 8 as default. This value can be modified via a module parameter if required. Signed-off-by: Juergen Gross <jgross(a)suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com> Signed-off-by: Boris Ostrovsky <boris.ostrovsky(a)oracle.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/xen-netback/netback.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/drivers/net/xen-netback/netback.c +++ b/drivers/net/xen-netback/netback.c @@ -67,6 +67,7 @@ module_param(rx_drain_timeout_msecs, uin unsigned int rx_stall_timeout_msecs = 60000; module_param(rx_stall_timeout_msecs, uint, 0444); +#define MAX_QUEUES_DEFAULT 8 unsigned int xenvif_max_queues; module_param_named(max_queues, xenvif_max_queues, uint, 0644); MODULE_PARM_DESC(max_queues, @@ -2157,11 +2158,12 @@ static int __init netback_init(void) if (!xen_domain()) return -ENODEV; - /* Allow as many queues as there are CPUs if user has not + /* Allow as many queues as there are CPUs but max. 8 if user has not * specified a value. */ if (xenvif_max_queues == 0) - xenvif_max_queues = num_online_cpus(); + xenvif_max_queues = min_t(unsigned int, MAX_QUEUES_DEFAULT, + num_online_cpus()); if (fatal_skb_slots < XEN_NETBK_LEGACY_SLOTS_MAX) { pr_info("fatal_skb_slots too small (%d), bump it to XEN_NETBK_LEGACY_SLOTS_MAX (%d)\n", Patches currently in stable-queue which might be from jgross(a)suse.com are queue-4.4/xen-netback-set-default-upper-limit-of-tx-rx-queues-to-8.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "video: fbdev: pmag-ba-fb: Remove bad `__init' annotation" 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 video: fbdev: pmag-ba-fb: Remove bad `__init' annotation 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: video-fbdev-pmag-ba-fb-remove-bad-__init-annotation.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 foo@baz Thu Nov 9 18:22:51 CET 2017 From: "Maciej W. Rozycki" <macro(a)linux-mips.org> Date: Mon, 30 Jan 2017 17:39:48 +0100 Subject: video: fbdev: pmag-ba-fb: Remove bad `__init' annotation From: "Maciej W. Rozycki" <macro(a)linux-mips.org> [ Upstream commit 879e5a0df626f39cbb3c61bb90373e56d67012c4 ] Fix: WARNING: drivers/video/fbdev/pmag-ba-fb.o(.text+0x308): Section mismatch in reference from the function pmagbafb_probe() to the function .init.text:pmagbafb_erase_cursor() The function pmagbafb_probe() references the function __init pmagbafb_erase_cursor(). This is often because pmagbafb_probe lacks a __init annotation or the annotation of pmagbafb_erase_cursor is wrong. -- a fallout from a missed update from commit 9625b51350cc ("VIDEO: PMAG-BA: Fix section mismatch") and then commit 48c68c4f1b54 ("Drivers: video: remove __dev* attributes.") Signed-off-by: Maciej W. Rozycki <macro(a)linux-mips.org> Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie(a)samsung.com> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/video/fbdev/pmag-ba-fb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/video/fbdev/pmag-ba-fb.c +++ b/drivers/video/fbdev/pmag-ba-fb.c @@ -129,7 +129,7 @@ static struct fb_ops pmagbafb_ops = { /* * Turn the hardware cursor off. */ -static void __init pmagbafb_erase_cursor(struct fb_info *info) +static void pmagbafb_erase_cursor(struct fb_info *info) { struct pmagbafb_par *par = info->par; Patches currently in stable-queue which might be from macro(a)linux-mips.org are queue-4.4/video-fbdev-pmag-ba-fb-remove-bad-__init-annotation.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "usb: hcd: initialize hcd->flags to 0 when rm hcd" 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: hcd: initialize hcd->flags to 0 when rm hcd 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-hcd-initialize-hcd-flags-to-0-when-rm-hcd.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 foo@baz Thu Nov 9 18:22:51 CET 2017 From: William wu <wulf(a)rock-chips.com> Date: Fri, 13 Jan 2017 11:04:22 +0800 Subject: usb: hcd: initialize hcd->flags to 0 when rm hcd From: William wu <wulf(a)rock-chips.com> [ Upstream commit 76b8db0d480e8045e1a1902fc9ab143b3b9ef115 ] On some platforms(e.g. rk3399 board), we can call hcd_add/remove consecutively without calling usb_put_hcd/usb_create_hcd in between, so hcd->flags can be stale. If the HC dies due to whatever reason then without this patch we get the below error on next hcd_add. [173.296154] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up [173.296209] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller [173.296762] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 6 [173.296931] usb usb6: We don't know the algorithms for LPM for this host, disabling LPM. [173.297179] usb usb6: New USB device found, idVendor=1d6b, idProduct=0003 [173.297203] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [173.297222] usb usb6: Product: xHCI Host Controller [173.297240] usb usb6: Manufacturer: Linux 4.4.21 xhci-hcd [173.297257] usb usb6: SerialNumber: xhci-hcd.2.auto [173.298680] hub 6-0:1.0: USB hub found [173.298749] hub 6-0:1.0: 1 port detected [173.299382] rockchip-dwc3 usb@fe800000: USB HOST connected [173.395418] hub 5-0:1.0: activate --> -19 [173.603447] irq 228: nobody cared (try booting with the "irqpoll" option) [173.603493] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.21 #9 [173.603513] Hardware name: Google Kevin (DT) [173.603531] Call trace: [173.603568] [<ffffffc0002087dc>] dump_backtrace+0x0/0x160 [173.603596] [<ffffffc00020895c>] show_stack+0x20/0x28 [173.603623] [<ffffffc0004b28a8>] dump_stack+0x90/0xb0 [173.603650] [<ffffffc00027347c>] __report_bad_irq+0x48/0xe8 [173.603674] [<ffffffc0002737cc>] note_interrupt+0x1e8/0x28c [173.603698] [<ffffffc000270a38>] handle_irq_event_percpu+0x1d4/0x25c [173.603722] [<ffffffc000270b0c>] handle_irq_event+0x4c/0x7c [173.603748] [<ffffffc00027456c>] handle_fasteoi_irq+0xb4/0x124 [173.603777] [<ffffffc00026fe3c>] generic_handle_irq+0x30/0x44 [173.603804] [<ffffffc0002701a8>] __handle_domain_irq+0x90/0xbc [173.603827] [<ffffffc0002006f4>] gic_handle_irq+0xcc/0x188 ... [173.604500] [<ffffffc000203700>] el1_irq+0x80/0xf8 [173.604530] [<ffffffc000261388>] cpu_startup_entry+0x38/0x3cc [173.604558] [<ffffffc00090f7d8>] rest_init+0x8c/0x94 [173.604585] [<ffffffc000e009ac>] start_kernel+0x3d0/0x3fc [173.604607] [<0000000000b16000>] 0xb16000 [173.604622] handlers: [173.604648] [<ffffffc000642084>] usb_hcd_irq [173.604673] Disabling IRQ #228 Signed-off-by: William wu <wulf(a)rock-chips.com> Acked-by: Roger Quadros <rogerq(a)ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/usb/core/hcd.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/usb/core/hcd.c +++ b/drivers/usb/core/hcd.c @@ -2997,6 +2997,7 @@ void usb_remove_hcd(struct usb_hcd *hcd) } usb_put_invalidate_rhdev(hcd); + hcd->flags = 0; } EXPORT_SYMBOL_GPL(usb_remove_hcd); Patches currently in stable-queue which might be from wulf(a)rock-chips.com are queue-4.4/usb-hcd-initialize-hcd-flags-to-0-when-rm-hcd.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "serial: sh-sci: Fix register offsets for the IRDA serial port" 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 serial: sh-sci: Fix register offsets for the IRDA serial port 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: serial-sh-sci-fix-register-offsets-for-the-irda-serial-port.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 foo@baz Thu Nov 9 18:22:51 CET 2017 From: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com> Date: Wed, 11 Jan 2017 16:43:32 +0200 Subject: serial: sh-sci: Fix register offsets for the IRDA serial port From: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com> [ Upstream commit a752ba18af8285e3eeda572f40dddaebff0c3621 ] Even though most of its registers are 8-bit wide, the IRDA has two 16-bit registers that make it a 16-bit peripheral and not a 8-bit peripheral with addresses shifted by one. Fix the registers offset in the driver and the platform data regshift value. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas(a)ideasonboard.com> Reviewed-by: Geert Uytterhoeven <geert+renesas(a)glider.be> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/sh/kernel/cpu/sh3/setup-sh770x.c | 1 - drivers/tty/serial/sh-sci.c | 17 ++++++++--------- 2 files changed, 8 insertions(+), 10 deletions(-) --- a/arch/sh/kernel/cpu/sh3/setup-sh770x.c +++ b/arch/sh/kernel/cpu/sh3/setup-sh770x.c @@ -165,7 +165,6 @@ static struct plat_sci_port scif2_platfo .scscr = SCSCR_TE | SCSCR_RE, .type = PORT_IRDA, .ops = &sh770x_sci_port_ops, - .regshift = 1, }; static struct resource scif2_resources[] = { --- a/drivers/tty/serial/sh-sci.c +++ b/drivers/tty/serial/sh-sci.c @@ -163,18 +163,17 @@ static const struct plat_sci_reg sci_reg }, /* - * Common definitions for legacy IrDA ports, dependent on - * regshift value. + * Common definitions for legacy IrDA ports. */ [SCIx_IRDA_REGTYPE] = { [SCSMR] = { 0x00, 8 }, - [SCBRR] = { 0x01, 8 }, - [SCSCR] = { 0x02, 8 }, - [SCxTDR] = { 0x03, 8 }, - [SCxSR] = { 0x04, 8 }, - [SCxRDR] = { 0x05, 8 }, - [SCFCR] = { 0x06, 8 }, - [SCFDR] = { 0x07, 16 }, + [SCBRR] = { 0x02, 8 }, + [SCSCR] = { 0x04, 8 }, + [SCxTDR] = { 0x06, 8 }, + [SCxSR] = { 0x08, 16 }, + [SCxRDR] = { 0x0a, 8 }, + [SCFCR] = { 0x0c, 8 }, + [SCFDR] = { 0x0e, 16 }, [SCTFDR] = sci_reg_invalid, [SCRFDR] = sci_reg_invalid, [SCSPTR] = sci_reg_invalid, Patches currently in stable-queue which might be from laurent.pinchart+renesas(a)ideasonboard.com are queue-4.4/serial-sh-sci-fix-register-offsets-for-the-irda-serial-port.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "powerpc/corenet: explicitly disable the SDHC controller on kmcoge4" 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 powerpc/corenet: explicitly disable the SDHC controller on kmcoge4 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: powerpc-corenet-explicitly-disable-the-sdhc-controller-on-kmcoge4.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 foo@baz Thu Nov 9 18:22:51 CET 2017 From: Valentin Longchamp <valentin.longchamp(a)keymile.com> Date: Thu, 15 Dec 2016 14:22:26 +0100 Subject: powerpc/corenet: explicitly disable the SDHC controller on kmcoge4 From: Valentin Longchamp <valentin.longchamp(a)keymile.com> [ Upstream commit a674c7d470bb47e82f4eb1fa944eadeac2f6bbaf ] It is not implemented on the kmcoge4 hardware and if not disabled it leads to error messages with the corenet32_smp_defconfig. Signed-off-by: Valentin Longchamp <valentin.longchamp(a)keymile.com> Signed-off-by: Scott Wood <oss(a)buserror.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/boot/dts/fsl/kmcoge4.dts | 4 ++++ 1 file changed, 4 insertions(+) --- a/arch/powerpc/boot/dts/fsl/kmcoge4.dts +++ b/arch/powerpc/boot/dts/fsl/kmcoge4.dts @@ -83,6 +83,10 @@ }; }; + sdhc@114000 { + status = "disabled"; + }; + i2c@119000 { status = "disabled"; }; Patches currently in stable-queue which might be from valentin.longchamp(a)keymile.com are queue-4.4/powerpc-corenet-explicitly-disable-the-sdhc-controller-on-kmcoge4.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "s390/qeth: issue STARTLAN as first IPA command" 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 s390/qeth: issue STARTLAN as first IPA command 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: s390-qeth-issue-startlan-as-first-ipa-command.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 foo@baz Thu Nov 9 18:22:51 CET 2017 From: Julian Wiedmann <jwi(a)linux.vnet.ibm.com> Date: Thu, 12 Jan 2017 15:48:42 +0100 Subject: s390/qeth: issue STARTLAN as first IPA command From: Julian Wiedmann <jwi(a)linux.vnet.ibm.com> [ Upstream commit 1034051045d125579ab1e8fcd5a724eeb0e70149 ] STARTLAN needs to be the first IPA command after MPC initialization completes. So move the qeth_send_startlan() call from the layer disciplines into the core path, right after the MPC handshake. While at it, replace the magic LAN OFFLINE return code with the existing enum. Signed-off-by: Julian Wiedmann <jwi(a)linux.vnet.ibm.com> Reviewed-by: Thomas Richter <tmricht(a)linux.vnet.ibm.com> Reviewed-by: Ursula Braun <ubraun(a)linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/s390/net/qeth_core.h | 1 - drivers/s390/net/qeth_core_main.c | 21 +++++++++++++++++---- drivers/s390/net/qeth_l2_main.c | 15 --------------- drivers/s390/net/qeth_l3_main.c | 15 --------------- 4 files changed, 17 insertions(+), 35 deletions(-) --- a/drivers/s390/net/qeth_core.h +++ b/drivers/s390/net/qeth_core.h @@ -909,7 +909,6 @@ void qeth_clear_thread_running_bit(struc int qeth_core_hardsetup_card(struct qeth_card *); void qeth_print_status_message(struct qeth_card *); int qeth_init_qdio_queues(struct qeth_card *); -int qeth_send_startlan(struct qeth_card *); int qeth_send_ipa_cmd(struct qeth_card *, struct qeth_cmd_buffer *, int (*reply_cb) (struct qeth_card *, struct qeth_reply *, unsigned long), --- a/drivers/s390/net/qeth_core_main.c +++ b/drivers/s390/net/qeth_core_main.c @@ -2955,7 +2955,7 @@ int qeth_send_ipa_cmd(struct qeth_card * } EXPORT_SYMBOL_GPL(qeth_send_ipa_cmd); -int qeth_send_startlan(struct qeth_card *card) +static int qeth_send_startlan(struct qeth_card *card) { int rc; struct qeth_cmd_buffer *iob; @@ -2968,7 +2968,6 @@ int qeth_send_startlan(struct qeth_card rc = qeth_send_ipa_cmd(card, iob, NULL, NULL); return rc; } -EXPORT_SYMBOL_GPL(qeth_send_startlan); static int qeth_default_setadapterparms_cb(struct qeth_card *card, struct qeth_reply *reply, unsigned long data) @@ -5080,6 +5079,20 @@ retriable: goto out; } + rc = qeth_send_startlan(card); + if (rc) { + QETH_DBF_TEXT_(SETUP, 2, "6err%d", rc); + if (rc == IPA_RC_LAN_OFFLINE) { + dev_warn(&card->gdev->dev, + "The LAN is offline\n"); + card->lan_online = 0; + } else { + rc = -ENODEV; + goto out; + } + } else + card->lan_online = 1; + card->options.ipa4.supported_funcs = 0; card->options.ipa6.supported_funcs = 0; card->options.adp.supported_funcs = 0; @@ -5091,14 +5104,14 @@ retriable: if (qeth_is_supported(card, IPA_SETADAPTERPARMS)) { rc = qeth_query_setadapterparms(card); if (rc < 0) { - QETH_DBF_TEXT_(SETUP, 2, "6err%d", rc); + QETH_DBF_TEXT_(SETUP, 2, "7err%d", rc); goto out; } } if (qeth_adp_supported(card, IPA_SETADP_SET_DIAG_ASSIST)) { rc = qeth_query_setdiagass(card); if (rc < 0) { - QETH_DBF_TEXT_(SETUP, 2, "7err%d", rc); + QETH_DBF_TEXT_(SETUP, 2, "8err%d", rc); goto out; } } --- a/drivers/s390/net/qeth_l2_main.c +++ b/drivers/s390/net/qeth_l2_main.c @@ -1203,21 +1203,6 @@ static int __qeth_l2_set_online(struct c /* softsetup */ QETH_DBF_TEXT(SETUP, 2, "softsetp"); - rc = qeth_send_startlan(card); - if (rc) { - QETH_DBF_TEXT_(SETUP, 2, "1err%d", rc); - if (rc == 0xe080) { - dev_warn(&card->gdev->dev, - "The LAN is offline\n"); - card->lan_online = 0; - goto contin; - } - rc = -ENODEV; - goto out_remove; - } else - card->lan_online = 1; - -contin: if ((card->info.type == QETH_CARD_TYPE_OSD) || (card->info.type == QETH_CARD_TYPE_OSX)) { if (qeth_l2_start_ipassists(card)) --- a/drivers/s390/net/qeth_l3_main.c +++ b/drivers/s390/net/qeth_l3_main.c @@ -3298,21 +3298,6 @@ static int __qeth_l3_set_online(struct c /* softsetup */ QETH_DBF_TEXT(SETUP, 2, "softsetp"); - rc = qeth_send_startlan(card); - if (rc) { - QETH_DBF_TEXT_(SETUP, 2, "1err%d", rc); - if (rc == 0xe080) { - dev_warn(&card->gdev->dev, - "The LAN is offline\n"); - card->lan_online = 0; - goto contin; - } - rc = -ENODEV; - goto out_remove; - } else - card->lan_online = 1; - -contin: rc = qeth_l3_setadapter_parms(card); if (rc) QETH_DBF_TEXT_(SETUP, 2, "2err%04x", rc); Patches currently in stable-queue which might be from jwi(a)linux.vnet.ibm.com are queue-4.4/s390-qeth-issue-startlan-as-first-ipa-command.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "phy: increase size of MII_BUS_ID_SIZE and bus_id" 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 phy: increase size of MII_BUS_ID_SIZE and bus_id 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: phy-increase-size-of-mii_bus_id_size-and-bus_id.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 foo@baz Thu Nov 9 18:22:51 CET 2017 From: Volodymyr Bendiuga <volodymyr.bendiuga(a)gmail.com> Date: Thu, 19 Jan 2017 17:05:04 +0100 Subject: phy: increase size of MII_BUS_ID_SIZE and bus_id From: Volodymyr Bendiuga <volodymyr.bendiuga(a)gmail.com> [ Upstream commit 4567d686f5c6d955e57a3afa1741944c1e7f4033 ] Some bus names are pretty long and do not fit into 17 chars. Increase therefore MII_BUS_ID_SIZE and phy_fixup.bus_id to larger number. Now mii_bus.id can host larger name. Signed-off-by: Volodymyr Bendiuga <volodymyr.bendiuga(a)gmail.com> Signed-off-by: Magnus Öberg <magnus.oberg(a)westermo.se> Reviewed-by: Andrew Lunn <andrew(a)lunn.ch> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- include/linux/phy.h | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) --- a/include/linux/phy.h +++ b/include/linux/phy.h @@ -136,11 +136,7 @@ static inline const char *phy_modes(phy_ /* Used when trying to connect to a specific phy (mii bus id:phy device id) */ #define PHY_ID_FMT "%s:%02x" -/* - * Need to be a little smaller than phydev->dev.bus_id to leave room - * for the ":%02x" - */ -#define MII_BUS_ID_SIZE (20 - 3) +#define MII_BUS_ID_SIZE 61 /* Or MII_ADDR_C45 into regnum for read/write on mii_bus to enable the 21 bit IEEE 802.3ae clause 45 addressing mode used by 10GIGE phy chips. */ @@ -599,7 +595,7 @@ struct phy_driver { /* A Structure for boards to register fixups with the PHY Lib */ struct phy_fixup { struct list_head list; - char bus_id[20]; + char bus_id[MII_BUS_ID_SIZE + 3]; u32 phy_uid; u32 phy_uid_mask; int (*run)(struct phy_device *phydev); Patches currently in stable-queue which might be from volodymyr.bendiuga(a)gmail.com are queue-4.4/phy-increase-size-of-mii_bus_id_size-and-bus_id.patch

7 years, 7 months

1
0
0 0

[Linux-stable-mirror] Patch "PCI: mvebu: Handle changes to the bridge windows while enabled" 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 PCI: mvebu: Handle changes to the bridge windows while enabled 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: pci-mvebu-handle-changes-to-the-bridge-windows-while-enabled.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 foo@baz Thu Nov 9 18:22:51 CET 2017 From: Jason Gunthorpe <jgunthorpe(a)obsidianresearch.com> Date: Mon, 12 Dec 2016 11:30:20 -0700 Subject: PCI: mvebu: Handle changes to the bridge windows while enabled From: Jason Gunthorpe <jgunthorpe(a)obsidianresearch.com> [ Upstream commit d9bf28e2650fe3eeefed7e34841aea07d10c6543 ] The PCI core will write to the bridge window config multiple times while they are enabled. This can lead to mbus failures like this: mvebu_mbus: cannot add window '4:e8', conflicts with another window mvebu-pcie mbus:pex@e0000000: Could not create MBus window at [mem 0xe0000000-0xe00fffff]: -22 For me this is happening during a hotplug cycle. The PCI core is not changing the values, just writing them twice while active. The patch addresses the general case of any change to an active window, but not atomically. The code is slightly refactored so io and mem can share more of the window logic. Signed-off-by: Jason Gunthorpe <jgunthorpe(a)obsidianresearch.com> Signed-off-by: Bjorn Helgaas <bhelgaas(a)google.com> Acked-by: Jason Cooper <jason(a)lakedaemon.net> Signed-off-by: Sasha Levin <alexander.levin(a)verizon.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/pci/host/pci-mvebu.c | 101 +++++++++++++++++++++++++------------------ 1 file changed, 60 insertions(+), 41 deletions(-) --- a/drivers/pci/host/pci-mvebu.c +++ b/drivers/pci/host/pci-mvebu.c @@ -131,6 +131,12 @@ struct mvebu_pcie { int nports; }; +struct mvebu_pcie_window { + phys_addr_t base; + phys_addr_t remap; + size_t size; +}; + /* Structure representing one PCIe interface */ struct mvebu_pcie_port { char *name; @@ -148,10 +154,8 @@ struct mvebu_pcie_port { struct mvebu_sw_pci_bridge bridge; struct device_node *dn; struct mvebu_pcie *pcie; - phys_addr_t memwin_base; - size_t memwin_size; - phys_addr_t iowin_base; - size_t iowin_size; + struct mvebu_pcie_window memwin; + struct mvebu_pcie_window iowin; u32 saved_pcie_stat; }; @@ -377,23 +381,45 @@ static void mvebu_pcie_add_windows(struc } } +static void mvebu_pcie_set_window(struct mvebu_pcie_port *port, + unsigned int target, unsigned int attribute, + const struct mvebu_pcie_window *desired, + struct mvebu_pcie_window *cur) +{ + if (desired->base == cur->base && desired->remap == cur->remap && + desired->size == cur->size) + return; + + if (cur->size != 0) { + mvebu_pcie_del_windows(port, cur->base, cur->size); + cur->size = 0; + cur->base = 0; + + /* + * If something tries to change the window while it is enabled + * the change will not be done atomically. That would be + * difficult to do in the general case. + */ + } + + if (desired->size == 0) + return; + + mvebu_pcie_add_windows(port, target, attribute, desired->base, + desired->size, desired->remap); + *cur = *desired; +} + static void mvebu_pcie_handle_iobase_change(struct mvebu_pcie_port *port) { - phys_addr_t iobase; + struct mvebu_pcie_window desired = {}; /* Are the new iobase/iolimit values invalid? */ if (port->bridge.iolimit < port->bridge.iobase || port->bridge.iolimitupper < port->bridge.iobaseupper || !(port->bridge.command & PCI_COMMAND_IO)) { - - /* If a window was configured, remove it */ - if (port->iowin_base) { - mvebu_pcie_del_windows(port, port->iowin_base, - port->iowin_size); - port->iowin_base = 0; - port->iowin_size = 0; - } - + mvebu_pcie_set_window(port, port->io_target, port->io_attr, + &desired, &port->iowin); return; } @@ -410,32 +436,27 @@ static void mvebu_pcie_handle_iobase_cha * specifications. iobase is the bus address, port->iowin_base * is the CPU address. */ - iobase = ((port->bridge.iobase & 0xF0) << 8) | - (port->bridge.iobaseupper << 16); - port->iowin_base = port->pcie->io.start + iobase; - port->iowin_size = ((0xFFF | ((port->bridge.iolimit & 0xF0) << 8) | - (port->bridge.iolimitupper << 16)) - - iobase) + 1; - - mvebu_pcie_add_windows(port, port->io_target, port->io_attr, - port->iowin_base, port->iowin_size, - iobase); + desired.remap = ((port->bridge.iobase & 0xF0) << 8) | + (port->bridge.iobaseupper << 16); + desired.base = port->pcie->io.start + desired.remap; + desired.size = ((0xFFF | ((port->bridge.iolimit & 0xF0) << 8) | + (port->bridge.iolimitupper << 16)) - + desired.remap) + + 1; + + mvebu_pcie_set_window(port, port->io_target, port->io_attr, &desired, + &port->iowin); } static void mvebu_pcie_handle_membase_change(struct mvebu_pcie_port *port) { + struct mvebu_pcie_window desired = {.remap = MVEBU_MBUS_NO_REMAP}; + /* Are the new membase/memlimit values invalid? */ if (port->bridge.memlimit < port->bridge.membase || !(port->bridge.command & PCI_COMMAND_MEMORY)) { - - /* If a window was configured, remove it */ - if (port->memwin_base) { - mvebu_pcie_del_windows(port, port->memwin_base, - port->memwin_size); - port->memwin_base = 0; - port->memwin_size = 0; - } - + mvebu_pcie_set_window(port, port->mem_target, port->mem_attr, + &desired, &port->memwin); return; } @@ -445,14 +466,12 @@ static void mvebu_pcie_handle_membase_ch * window to setup, according to the PCI-to-PCI bridge * specifications. */ - port->memwin_base = ((port->bridge.membase & 0xFFF0) << 16); - port->memwin_size = - (((port->bridge.memlimit & 0xFFF0) << 16) | 0xFFFFF) - - port->memwin_base + 1; - - mvebu_pcie_add_windows(port, port->mem_target, port->mem_attr, - port->memwin_base, port->memwin_size, - MVEBU_MBUS_NO_REMAP); + desired.base = ((port->bridge.membase & 0xFFF0) << 16); + desired.size = (((port->bridge.memlimit & 0xFFF0) << 16) | 0xFFFFF) - + desired.base + 1; + + mvebu_pcie_set_window(port, port->mem_target, port->mem_attr, &desired, + &port->memwin); } /* Patches currently in stable-queue which might be from jgunthorpe(a)obsidianresearch.com are queue-4.4/pci-mvebu-handle-changes-to-the-bridge-windows-while-enabled.patch

7 years, 7 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror