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
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
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
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…
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
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.
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.
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