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

[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

8 years

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

8 years

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

8 years

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

8 years

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

8 years

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

8 years

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

8 years

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

8 years

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

8 years

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…

8 years

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror