On Thu, Jul 21, 2016 at 2:21 PM, Josh Poimboeuf wrote:
> Now that we can find pt_regs registers in the middle of the stack due to
> an interrupt or exception, we can print them. Here's what it looks
> like:
>
>...
>[] do_async_page_fault+0x2c/0xa0
>[] async_page_fault+0x28/0x30
> RI
On Wed, 2016-07-20 at 14:37 -0400, Waiman Long wrote:
> On 07/20/2016 12:39 AM, Jason Low wrote:
> > On Tue, 2016-07-19 at 16:04 -0700, Jason Low wrote:
> >> Hi Imre,
> >>
> >> Here is a patch which prevents a thread from spending too much "time"
> >> waiting for a mutex in the !CONFIG_MUTEX_SPIN_O
On 7/20/2016 9:50 PM, Vishal Verma wrote:
> When a latent (unknown to 'badblocks') error is encountered, it will
> trigger a machine check exception. On a system with machine check
> recovery, this will only SIGBUS the process(es) which had the bad page
> mapped (as opposed to a kernel panic on p
On Thu, Jul 21, 2016 at 2:21 PM, Josh Poimboeuf wrote:
> With frame pointers, when a task is interrupted, its stack is no longer
> completely reliable because the function could have been interrupted
> before it had a chance to save the previous frame pointer on the stack.
> So the caller of the i
On 07/21/2016 02:48 PM, H. Peter Anvin wrote:
>> >I like it, except that reading just a single byte is a bit silly.
>> >OTOH, that's what the current code needs and I see no fundamental
>> >reason to change it until there's a real user.
>>>
> The thing is that we can't actually test this, since th
On 07/20/2016 09:43 PM, a...@linux-foundation.org wrote:
>
> The patch titled
> Subject:
> mm-kasan-switch-slub-to-stackdepot-enable-memory-quarantine-for-slub-fix
> has been added to the -mm tree. Its filename is
>
> mm-kasan-switch-slub-to-stackdepot-enable-memory-quarantine-for-s
Hi Guenter,
On Thu, Jul 21, 2016 at 3:09 PM, Guenter Roeck wrote:
> On Thu, Jul 21, 2016 at 01:55:56PM -0700, Hoan Tran wrote:
>> This patch adds hardware temperature and power reading support for
>> APM X-Gene SoC using the mailbox communication interface.
>>
>> Signed-off-by: Hoan Tran
>> ---
On Thu, Jul 21, 2016 at 11:33:11PM +0300, Aleksei Mamlin wrote:
> This patch add support for Domintech DMARD06 accelerometer.
>
> Domintech DMARD06 is a low-g tri-axial digital accelerometer for
> cost-sensitive consumer application.
>
> Signed-off-by: Aleksei Mamlin
> ---
> .../devicetree/bind
On Thu, Jul 21, 2016 at 11:32:58PM +0300, Aleksei Mamlin wrote:
> Add vendor-prefix for Domintech Co., Ltd.
>
> Signed-off-by: Aleksei Mamlin
> ---
> Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
> 1 file changed, 1 insertion(+)
Please add acks when posting new versions.
Rob
On Thu, Jul 21, 2016 at 02:44:11PM +0200, Grzegorz Jaszczyk wrote:
> Beside interfaces described in the armada-39x.dtsi, the Armada 395 SoC
> family supports: 2 x SATA3 (2 ports in one unit) and the USB3.0
>
> Signed-off-by: Grzegorz Jaszczyk
> ---
> .../devicetree/bindings/arm/marvell/armada-39
> > > > comments below; nice addition
> > > >
> > > > it seems this patch clashes with the recent changes to this driver in
> > > > iio-testing; can you rebase on top please?
> > >
> > > Where is iio-testing? I couldn't found it in linux.
> >
> > https://git.kernel.org/cgit/linux/kernel/git/jic23/
Paul's changes to remove MODULE_LICENSE() out of the x86 glue_helper
causes a kernel with CONFIG_CRYPTO_GLUE_HELPER_X86=m to taint since
it now detects the license is missing if you try to build the driver
as a module, log below.
Fix this by removing the module option for it via Kconfig as it
cann
The mm-of-the-moment snapshot 2016-07-21-15-11 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You wi
Hi,
[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.7-rc7 next-20160721]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Zhiyong-Tao/AUXADC-Mediatek-auxadc-driver/20160722
On Thu, Jul 21, 2016 at 01:55:57PM -0700, Hoan Tran wrote:
> This patch adds DT node to enable hwmon driver for APM X-Gene SoC.
>
> Signed-off-by: Hoan Tran
Acked-by: Guenter Roeck
> ---
> arch/arm64/boot/dts/apm/apm-shadowcat.dtsi | 5 +
> arch/arm64/boot/dts/apm/apm-storm.dtsi | 5 +
> Triggered buffer support uses the HDC100X's dual acquisition mode
> to read both humidity and temperature in one shot.
comments below
> Signed-off-by: Alison Schofield
> Cc: Daniel Baluta
> ---
> drivers/iio/humidity/Kconfig | 2 +
> drivers/iio/humidity/hdc100x.c | 144
>
On Thu, Jul 21, 2016 at 01:55:56PM -0700, Hoan Tran wrote:
> This patch adds hardware temperature and power reading support for
> APM X-Gene SoC using the mailbox communication interface.
>
> Signed-off-by: Hoan Tran
> ---
[ ... ]
> +
> + dev_info(&pdev->dev, "APM X-Gene SoC HW monitor driv
On Thu, Jul 21, 2016 at 12:48:10PM +0200, Grzegorz Jaszczyk wrote:
> Both SATA and second USB3.0 interface are supported in Armada-39x SoC
> family. Add necessary clk description, so both xhci and sata drivers
> can be correctly initialized.
>
> The binding documentation has also been updated acco
On Thu, Jul 21, 2016 at 11:19:26AM +0200, gabriel.fernan...@st.com wrote:
> From: Maxime Coquelin
>
> This adds documentation of device tree bindings for the
> STM32 reset controller.
>
> Signed-off-by: Maxime Coquelin
> Signed-off-by: Gabriel Fernandez
> ---
> .../devicetree/bindings/clock/s
On Thu, Jul 21, 2016 at 2:21 PM, Josh Poimboeuf wrote:
> in_exception_stack() does some bad, bad things just so the unwinder can
> print different values for different areas of the debug exception stack.
>
> There's no need to clarify where exactly on the stack it is. Just print
> "#DB" and be do
On Thu, Jul 21, 2016 at 04:14:58PM +0800, Songjun Wu wrote:
> DT binding documentation for ISC driver.
>
> Signed-off-by: Songjun Wu
> ---
>
> Changes in v6:
> - Add "iscck" and "gck" to clock-names.
>
> Changes in v5:
> - Add clock-output-names.
>
> Changes in v4:
> - Remove the isc clock nod
On Thu, Jul 21, 2016 at 01:55:55PM -0700, Hoan Tran wrote:
> This patch adds the APM X-Gene hwmon device tree node documentation.
>
> Signed-off-by: Hoan Tran
> Acked-by: Rob Herring
Applied to hwmon-next.
Thanks,
Guenter
On Thu, Jul 21, 2016 at 2:21 PM, Josh Poimboeuf wrote:
> For reasons unknown, the x86_64 irq stack starts at an offset 64 bytes
> from the end of the page. At least make that explicit.
This is a change in behavior -- see below. Please mention this in the
changelog.
>
> FIXME: Can we just remov
If no user specified chip->select_chip() function is provided, code in
nand_base.c will automatically set this hook to nand_select_chip(),
which in turn depends on chip->cmd_ctrl() hook being valid. Not
providing both of those functions in NAND controller driver (for example
by mistake) will result
On Thu, Jul 21, 2016 at 2:21 PM, Josh Poimboeuf wrote:
> The various functions involved in dumping the stack all do similar
> things with regard to getting the stack pointer and the frame pointer
> based on the regs and task arguments. Create helper functions to
> do that instead.
>
Reviewed-by:
Using "goto" and "switch" statement only makes it harder to follow
control flow and doesn't bring any advantages. Rewrite the code to avoid
using "goto".
Signed-off-by: Brian Norris
Signed-off-by: Andrey Smirnov
---
No changes since v2.
drivers/mtd/nand/nand_base.c | 18 ++
1
Config MTD_NAND_FSL_IFC is already located inside 'if MTD_NAND'
statment, so there's no need to explicitly specify it as a dependency.
Signed-off-by: Andrey Smirnov
---
drivers/mtd/nand/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/Kconfig b/drivers
MTD_NAND_FSL_ELBC selects FSL_LBC that in turn depends on FSL_SOC, so
depending on PPC instead of FSL_SOC leads to this message:
warning: (MPC836x_RDK && MTD_NAND_FSL_ELBC &&
MTD_NAND_FSL_UPM) selects FSL_LBC which has unmet direct
dependencies (FSL_SOC)
when doing
On 7/21/2016 5:10 PM, Vishal Verma wrote:
> On 07/21, Linda Knippers wrote:
>>
>>
>> On 7/20/2016 9:50 PM, Vishal Verma wrote:
>>> When a latent (unknown to 'badblocks') error is encountered, it will
>>> trigger a machine check exception. On a system with machine check
>>> recovery, this will onl
On Thu, Jul 21, 2016 at 2:21 PM, Josh Poimboeuf wrote:
> There are a bewildering array of options for dumping the stack.
> Simplify things a little by removing show_trace(), which is unused.
Reviewed-by: Andy Lutomirski
On Thu, Jul 21, 2016 at 2:21 PM, Josh Poimboeuf wrote:
> When calling show_stack_log_lvl() or dump_trace() with a regs argument,
> providing a stack pointer or frame pointer is redundant.
>
> diff --git a/arch/x86/kernel/dumpstack_32.c b/arch/x86/kernel/dumpstack_32.c
> index 358fe1c..c533b8b 100
On July 21, 2016 2:45:49 PM PDT, Andy Lutomirski wrote:
>On Thu, Jul 21, 2016 at 2:35 PM, Dave Hansen
> wrote:
>> On 07/12/2016 03:59 PM, Andy Lutomirski wrote:
>>> On Tue, Jul 12, 2016 at 3:55 PM, H. Peter Anvin
>wrote:
On 07/12/16 08:32, Dave Hansen wrote:
> On 07/09/2016 02:27 PM, And
On Thu, Jul 21, 2016 at 04:21:52PM -0500, Josh Poimboeuf wrote:
> Convert show_trace_log_lvl() to the new unwinder. dump_trace() has been
> deprecated.
>
> show_trace_log_lvl() is special compared to other users of the unwinder.
> It's the only place where both reliable *and* unreliable addresses
As I've mentioned in the comment/message, there is no ATA command
needed to be sent to the device, since it only toggles a bit in
dev->flags. See that there is no ata_taskfile constructed in
ata_mselect_control().
On 22 July 2016 at 05:26, Tejun Heo wrote:
> On Fri, Jul 22, 2016 at 02:41:54AM +08
Dear Esteemed Friend,
My name is Mr. Amit Jain, I double as the Group Chief Operations Officer Emaar
Properties and Chief Executive Officer Emaar Dubai. Let me know the
possibilities of setting up a private investment in your country as I am
interested in your region. I have interest in Real Es
On Thu, Jul 21, 2016 at 2:28 PM, H. Peter Anvin wrote:
> On July 21, 2016 2:08:12 PM PDT, Andy Lutomirski wrote:
>>On Thu, Jul 21, 2016 at 9:18 AM, Ingo Molnar wrote:
>>>
>>> * Andy Lutomirski wrote:
>>>
It would be very easy to implement this if we could handle
>>overlapping memblocks
>>>
This patch has two fixes for the patch
"rapidio/switches: add driver for IDT gen3 switches" currently in -mm tree.
First address Andrew's comment about blocking delay.
The second fix was missed during the original patch preparation.
Signed-off-by: Alexandre Bounine
Cc: Matt Porter
Cc: Andre van
On Thu, Jul 21, 2016 at 2:35 PM, Dave Hansen
wrote:
> On 07/12/2016 03:59 PM, Andy Lutomirski wrote:
>> On Tue, Jul 12, 2016 at 3:55 PM, H. Peter Anvin wrote:
>>> On 07/12/16 08:32, Dave Hansen wrote:
On 07/09/2016 02:27 PM, Andy Lutomirski wrote:
> is_prefetch in arch/x86/mm/fault.c can
On Fri, Jul 22, 2016 at 05:39:27AM +0800, Tom Yan wrote:
> Let me know how I should polish the description for this.
The above is because the signed ones are getting sign-extended making
them different from the unsigned ones which don't get padded in the
high bits. Converting to u8 is the right t
Well, I mean this is happening when ata_mselect_*() calls ata_msense_*():
[tom@localhost ~]$ cat test.c
#include
#include
typedef unsigned char u8;
int main() {
u8 a[2] = { 0xff, 0xff };
char b[2];
memcpy(b, a, 2);
for (int i=0; i<2; i++) {
printf("%d\n", a[i]);
}
for (int i=
The handlers provided by cpufreq core are sufficient for resolving the
frequency for drivers providing ->target_index(), as the core already
has the frequency table and so ->resolve_freq() isn't required for such
platforms.
This patch disallows drivers with ->target_index() callback to use the
->r
On Thu, Jul 21, 2016 at 11:23 PM, Viresh Kumar wrote:
> The handlers provided by cpufreq core are sufficient for resolving the
> frequency for drivers providing ->target_index(), as the core already
> has the frequency table and so ->resolve_freq() isn't required for such
> platforms.
>
> This pat
On 07/12/2016 03:59 PM, Andy Lutomirski wrote:
> On Tue, Jul 12, 2016 at 3:55 PM, H. Peter Anvin wrote:
>> On 07/12/16 08:32, Dave Hansen wrote:
>>> On 07/09/2016 02:27 PM, Andy Lutomirski wrote:
is_prefetch in arch/x86/mm/fault.c can be called on a user address
that's not readable due t
On Wed, Jul 20, 2016 at 11:13 PM, Stephen Rothwell
wrote:
> Hi Dan,
>
> After merging the nvdimm tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> arch/powerpc/sysdev/axonram.c: In function 'axon_ram_direct_access':
> arch/powerpc/sysdev/axonram.c:151:9: error: assi
The x86 stack dump code is a bit of a mess. dump_trace() uses
callbacks, and each user of it seems to have slightly different
requirements, so there are several slightly different callbacks floating
around.
Also there are some upcoming features which will require more changes to
the stack dump co
When function graph tracing is enabled for a function, its return
address on the stack is replaced with the address of an ftrace handler
(return_to_handler). When dumping the stack of a task with graph
tracing enabled, there are some subtle bugs:
- The fake return_to_handler() address can be repo
On July 21, 2016 2:08:12 PM PDT, Andy Lutomirski wrote:
>On Thu, Jul 21, 2016 at 9:18 AM, Ingo Molnar wrote:
>>
>> * Andy Lutomirski wrote:
>>
>>> It would be very easy to implement this if we could handle
>overlapping memblocks
>>> precisely or set a lower limit on the memblock allocator. Then
There are a bewildering array of options for dumping the stack.
Simplify things a little by removing show_trace(), which is unused.
Signed-off-by: Josh Poimboeuf
---
arch/x86/include/asm/kdebug.h | 2 --
arch/x86/kernel/dumpstack.c | 6 --
2 files changed, 8 deletions(-)
diff --git a/arch
>> Can you follow expectations around the proposed refactoring of any
>> function implementations?
>
> I don't understand both questions. Maybe you need to give examples?
I suggest to try the following script (semantic patch for working with
the Coccinelle software) out on the discussed source fi
in_exception_stack() does some bad, bad things just so the unwinder can
print different values for different areas of the debug exception stack.
There's no need to clarify where exactly on the stack it is. Just print
"#DB" and be done with it.
Signed-off-by: Josh Poimboeuf
---
arch/x86/kernel/
On Fri, Jul 22, 2016 at 02:41:54AM +0800, tom.t...@gmail.com wrote:
> @@ -3854,6 +3852,8 @@ static unsigned int ata_scsi_mode_select_xlat(struct
> ata_queued_cmd *qc)
> if (ata_mselect_control(qc, p, pg_len, &fp) < 0) {
> fp += hdr_len + bd_len;
>
For reasons unknown, the x86_64 irq stack starts at an offset 64 bytes
from the end of the page. At least make that explicit.
FIXME: Can we just remove the 64 byte gap? If not, at least document
why.
Signed-off-by: Josh Poimboeuf
---
arch/x86/include/asm/page_64_types.h | 19 +++--
valid_stack_ptr() is buggy: it assumes that all stacks are of size
THREAD_SIZE, which is not true for exception stacks. So the
walk_stack() callbacks will need to know the location of the beginning
of the stack as well as the end.
Another issue is that in general the various features of a stack (
When calling show_stack_log_lvl() or dump_trace() with a regs argument,
providing a stack pointer or frame pointer is redundant.
Signed-off-by: Josh Poimboeuf d
---
arch/x86/kernel/dumpstack.c| 2 +-
arch/x86/kernel/dumpstack_32.c | 2 +-
arch/x86/kernel/dumpstack_64.c | 5 +
arch/x86/opr
The x86 stack dump code is a bit of a mess. dump_trace() uses
callbacks, and each user of it seems to have slightly different
requirements, so there are several slightly different callbacks floating
around.
Also there are some upcoming features which will require more changes to
the stack dump co
When starting the dump of an exception stack, it shows "<>" instead
of "". print_trace_stack() already adds brackets, no need to add
them again.
Signed-off-by: Josh Poimboeuf
---
arch/x86/kernel/dumpstack_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/d
Convert show_trace_log_lvl() to the new unwinder. dump_trace() has been
deprecated.
show_trace_log_lvl() is special compared to other users of the unwinder.
It's the only place where both reliable *and* unreliable addresses are
needed. With frame pointers enabled, most stack walking code doesn't
show_trace_log_lvl() prints the stack id (e.g. "") without a
newline so that any stack address printed after it will appear on the
same line. That causes the first stack address to be vertically
misaligned with the rest, making it visually cluttered and slightly
confusing:
Call Trace:
[] du
The handlers provided by cpufreq core are sufficient for resolving the
frequency for drivers providing ->target_index(), as the core already
has the frequency table and so ->resolve_freq() isn't required for such
platforms.
This patch disallows drivers with ->target_index() callback to use the
->r
show_stack_log_lvl() and dump_trace() are already preemption safe:
- If they're running in irq or exception context, preemption is already
disabled, and the percpu irq stack pointers can be trusted.
- If they're running with preemption enabled, they must be running on
the task stack anyway, s
Convert perf_callchain_kernel() to the new unwinder. dump_trace() has
been deprecated.
Signed-off-by: Josh Poimboeuf
---
arch/x86/events/core.c | 32 +---
1 file changed, 9 insertions(+), 23 deletions(-)
diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
i
Change printk_stack_address() to be useful when called by an unwinder
outside the context of dump_trace().
Specifically:
- printk_stack_address()'s 'data' argument is always used as the log
level string. Make that explicit.
- Call touch_nmi_watchdog().
Signed-off-by: Josh Poimboeuf
---
arc
Convert oprofile's x86_backtrace() to the new unwinder. dump_trace()
has been deprecated.
Cc: Robert Richter
Cc: oprofile-l...@lists.sf.net
Signed-off-by: Josh Poimboeuf
---
arch/x86/oprofile/backtrace.c | 42 +++---
1 file changed, 19 insertions(+), 23 dele
Convert save_stack_trace_*() to the new unwinder. dump_trace() has been
deprecated.
Signed-off-by: Josh Poimboeuf
---
arch/x86/kernel/stacktrace.c | 74 +---
1 file changed, 29 insertions(+), 45 deletions(-)
diff --git a/arch/x86/kernel/stacktrace.c b/ar
Now that we can find pt_regs registers in the middle of the stack due to
an interrupt or exception, we can print them. Here's what it looks
like:
...
[] do_async_page_fault+0x2c/0xa0
[] async_page_fault+0x28/0x30
RIP: 0010:[] [] __clear_user+0x42/0x70
RSP: 0018:88007876fd38 EFL
All previous users of dump_trace() have been converted to use the new
unwind interfaces, so we can remove it.
Signed-off-by: Josh Poimboeuf
---
arch/x86/include/asm/stacktrace.h | 38 +
arch/x86/kernel/dumpstack_32.c| 35
arch/x86/kernel/dumpstack_64.
With frame pointers, when a task is interrupted, its stack is no longer
completely reliable because the function could have been interrupted
before it had a chance to save the previous frame pointer on the stack.
So the caller of the interrupted function could get skipped by a stack
trace.
This is
WDOG_HW_RUNNING indicates that the hardware watchdog is running while the
watchdog device is closed. The flag may be set by the driver when it is
instantiated to indicate that the watchdog is running, and that the
watchdog core needs to send heartbeat requests to the driver until the
watchdog devic
The various functions involved in dumping the stack all do similar
things with regard to getting the stack pointer and the frame pointer
based on the regs and task arguments. Create helper functions to
do that instead.
Signed-off-by: Josh Poimboeuf
---
arch/x86/include/asm/stacktrace.h | 39 +++
On Thursday, July 21, 2016 01:52:45 PM Viresh Kumar wrote:
> On 21-07-16, 22:52, Rafael J. Wysocki wrote:
> > That'd be fine by me.
> >
> > Please send a patch on top of the Steve's series and I can apply it too
> > (unless Steve sees some major problems in it, which seems unlikely to me).
>
> Su
On Thu, Jul 21, 2016 at 11:52:36AM +0530, Sekhar Nori wrote:
> Nishanth,
>
> On Wednesday 20 July 2016 09:03 PM, Nishanth Menon wrote:
> > On 07/20/2016 09:56 AM, Mugunthan V N wrote:
> >> Add documention of ti,impedance-control which can be used to
> >> correct MAC impedance mismatch using phy ex
This follows up on Ingo's cleanup. The first patch fixes the docs
and the second makes the code even more comprehensible.
Andy Lutomirski (2):
x86/boot: Clarify what x86_legacy_features.reserve_bios_regions does
x86/boot: Simplify EBDA-vs-BIOS reservation logic
arch/x86/include/asm/x86_init
Hello,
On Fri, Jul 22, 2016 at 02:41:52AM +0800, tom.t...@gmail.com wrote:
> From: Tom Yan
>
> ata_mselect_*() would initialize a char array for storing a copy of
> the current mode page. However, if char was actually signed char,
> overflow could occur.
Do you mean sign extension?
> For examp
On 21-07-16, 23:19, Rafael J. Wysocki wrote:
> On Thursday, July 21, 2016 01:52:45 PM Viresh Kumar wrote:
> > On 21-07-16, 22:52, Rafael J. Wysocki wrote:
> > > That'd be fine by me.
> > >
> > > Please send a patch on top of the Steve's series and I can apply it too
> > > (unless Steve sees some m
Both the intent and the effect of reserve_bios_regions() is simple:
reserve the range from the apparent BIOS start (suitably filtered)
through 1MB and, if the EBDA start address is sensible, extend that
reservation downward to cover the EBDA as well.
The code is overcomplicated, though, and contai
It doesn't just control probing for the EBDA -- it controls whether we
detect and reserve the <1MB BIOS regions in general.
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/x86_init.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/x86_init.h
On Wed, Jul 13, 2016 at 10:44 AM, Vivek Goyal wrote:
> Hi All,
>
> Please find attached the V3 of patches. Changes since V2 are as follows.
>
> - Fixed the build issue with CONFIG_SECURITY=n.
>
> - Dan Walsh was writing more tests for selinux-testsuite and noted couple
> of issues. I have fixed
Call the rseq_handle_notify_resume() function on return to
userspace if TIF_NOTIFY_RESUME thread flag is set.
Increment the event counter and perform fixup on the pre-signal frame
when a signal is delivered on top of a restartable sequence critical
section.
Signed-off-by: Mathieu Desnoyers
CC: R
Hi,
This is mostly a re-write of Paul Turner and Andrew Hunter's restartable
critical sections (percpu atomics), which brings the following main
benefits over Paul Turner's prior version (v2):
- The ABI is now architecture-agnostic, and it requires fewer
instruction on the user-space fast path,
Implements two basic tests of RSEQ functionality, and one more
exhaustive parameterizable test.
The first, "basic_test" only asserts that RSEQ works moderately
correctly.
E.g. that:
- The CPUID pointer works
- Code infinitely looping within a critical section will eventually be
interrupted.
- Cr
Wire up the rseq system call on 32-bit ARM.
This provides an ABI improving the speed of a user-space getcpu
operation on ARM by skipping the getcpu system call on the fast path, as
well as improving the speed of user-space operations on per-cpu data
compared to using load-linked/store-conditional.
Signed-off-by: Mathieu Desnoyers
CC: Thomas Gleixner
CC: Paul Turner
CC: Andrew Hunter
CC: Peter Zijlstra
CC: Andy Lutomirski
CC: Andi Kleen
CC: Dave Watson
CC: Chris Lameter
CC: Ingo Molnar
CC: "H. Peter Anvin"
CC: Ben Maurer
CC: Steven Rostedt
CC: "Paul E. McKenney"
CC: Josh Triplet
Wire up the rseq system call on x86 32/64.
This provides an ABI improving the speed of a user-space getcpu
operation on x86 by removing the need to perform a function call, "lsl"
instruction, or system call on the fast path, as well as improving the
speed of user-space operations on per-cpu data.
Call the rseq_handle_notify_resume() function on return to userspace if
TIF_NOTIFY_RESUME thread flag is set.
Increment the event counter and perform fixup on the pre-signal frame
when a signal is delivered on top of a restartable sequence critical
section.
Signed-off-by: Mathieu Desnoyers
CC: R
Expose a new system call allowing each thread to register one userspace
memory area to be used as an ABI between kernel and user-space for two
purposes: user-space restartable sequences and quick access to read the
current CPU number value from user-space.
* Restartable sequences (per-cpu atomics)
On 13-07-16, 13:25, Steve Muckle wrote:
> +unsigned int cpufreq_driver_resolve_freq(struct cpufreq_policy *policy,
> + unsigned int target_freq)
> +{
> + target_freq = clamp_val(target_freq, policy->min, policy->max);
> + policy->cached_target_freq = tar
On 07/21, Linda Knippers wrote:
>
>
> On 7/20/2016 9:50 PM, Vishal Verma wrote:
> > When a latent (unknown to 'badblocks') error is encountered, it will
> > trigger a machine check exception. On a system with machine check
> > recovery, this will only SIGBUS the process(es) which had the bad page
Thanks for applying it, I'll skip the reせend then.
On Thu, Jul 21, 2016 at 9:18 AM, Ingo Molnar wrote:
>
> * Andy Lutomirski wrote:
>
>> It would be very easy to implement this if we could handle overlapping
>> memblocks
>> precisely or set a lower limit on the memblock allocator. Then we could block
>> off everything below 1MB or 2MB very early
On Thu, Jul 21, 2016 at 04:02:23PM -0500, Bjorn Helgaas wrote:
> Hi Christoph,
>
> This thread looks like it might be a typo. It doesn't use any of the
> new PCI MSI stuff. Looks like the cover letter from the PCI MSI
> patches, but the actual patches are from a different series?
Ah, sorry. Th
For PCC mailbox with interrupt flag, CPPC should call mbox_chan_txdone()
function to notify the mailbox framework about TX completion.
Signed-off-by: Hoan Tran
---
This patch is tested on top and depends on patch[1]:
[1] http://www.spinics.net/lists/linux-acpi/msg66041.html
- [PATCH v3] mailbox:
Hello,
On Thu, Jul 21, 2016 at 11:16:42AM -0700, James Bottomley wrote:
> OK so a theoretical (not saying it's implementable, we'll have to
> explore that) way of fixing all of this is to have separate views of
> the tree. If the admin always saw everything in A, even if the
> cgroupns had create
On Tue, Jul 12, 2016 at 06:20:13PM +0900, Christoph Hellwig wrote:
> This series adds a new set of functions that transparently use the right
> type of interrupt (MSI-X, MSI, legacy interrupt line) for a PCI device,
> and if multiple vectors are supported automatically spreads the irq
> routing to
Hey Matt,
On 7/21/2016 7:12 AM, Matt Fleming wrote:
On Fri, 15 Jul, at 10:41:31AM, Christ, Austin wrote:
According to UEFI 2.6 section 7.5.3, the capsule should be in contiguous
virtual memory and firmware may consume the capsule immediately. To
correctly implement this functionality, the kern
On Wed, Jul 20, 2016 at 12:49:12PM -0700, Andrey Pronin wrote:
> On Wed, Jul 20, 2016 at 02:03:03PM -0500, Rob Herring wrote:
> > On Tue, Jul 19, 2016 at 08:41:24PM -0700, Andrey Pronin wrote:
>
> Hi Rob,
>
> > As I mentioned, there may be common properties. It doesn't seem you
> > looked, so I
Hi Christoph,
This thread looks like it might be a typo. It doesn't use any of the
new PCI MSI stuff. Looks like the cover letter from the PCI MSI
patches, but the actual patches are from a different series?
On Thu, Jul 21, 2016 at 04:30:20PM +0200, Christoph Hellwig wrote:
> This series adds a
On 21-07-16, 22:52, Rafael J. Wysocki wrote:
> That'd be fine by me.
>
> Please send a patch on top of the Steve's series and I can apply it too
> (unless Steve sees some major problems in it, which seems unlikely to me).
Sure, thanks :)
--
viresh
On Thu, Jul 21, 2016 at 11:10:47AM -0700, Andrey Pronin wrote:
> On Wed, Jul 20, 2016 at 11:03:36AM -0600, Jason Gunthorpe wrote:
> > On Tue, Jul 19, 2016 at 05:24:11PM -0700, Andrey Pronin wrote:
> >
> > > The only two things that bother me with such approach are
> > > (1) whatever names I pick f
On Wed, 2016-07-20 at 16:29 +0300, Imre Deak wrote:
> On ti, 2016-07-19 at 21:39 -0700, Jason Low wrote:
> > On Tue, 2016-07-19 at 16:04 -0700, Jason Low wrote:
> > > Hi Imre,
> > >
> > > Here is a patch which prevents a thread from spending too much "time"
> > > waiting for a mutex in the !CONFIG
On Thu, Jul 21, 2016 at 03:23:40PM -0400, Lyude wrote:
> Thanks to Ville for suggesting this as a potential solution to pipe
> underruns on Skylake.
>
> On Skylake all of the registers for configuring planes, including the
> registers for configuring their watermarks, are double buffered. New
> va
201 - 300 of 792 matches
Mail list logo
