Re: [PATCH 2/2] x86/mtrr: Refactor PAT initialization code

On Tue, Mar 29, 2016 at 5:16 PM, Toshi Kani wrote: > On Tue, 2016-03-29 at 15:12 -0700, Luis R. Rodriguez wrote: >> On Tue, Mar 29, 2016 at 2:46 PM, Toshi Kani wrote: >> > On Tue, 2016-03-29 at 10:14 -0700, Luis R. Rodriguez wrote: >> > > On Fri, Mar 18, 2016 at 2:35 PM, Toshi Kani >> > >

[PATCH 03/11] perf tools: Make -f/--force option documentation consistent across tools

From: Jiri Olsa Signed-off-by: Jiri Olsa Cc: Andi Kleen Cc: David Ahern Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Stephane Eranian Link: http://lkml.kernel.org/r/1458823940-24583-6-git-send-email-jo...@kernel.org Signed-off-by: Arnaldo Carvalho de Melo ---

[PATCH 05/11] perf config: Remove duplicated set_buildid_dir calls

From: Taeung Song Signed-off-by: Taeung Song Acked-by: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Link:

[PATCH 06/11] perf config: Rework buildid_dir_command_config to perf_buildid_config

From: Taeung Song To avoid repeated calling perf_config() remove buildid_dir_command_config() and add new perf_buildid_config into perf_default_config. Because perf_config() is already called with perf_default_config at main(). Signed-off-by: Taeung Song

[PATCH 05/11] perf config: Remove duplicated set_buildid_dir calls

From: Taeung Song Signed-off-by: Taeung Song Acked-by: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1459099340-16911-1-git-send-email-treeze.tae...@gmail.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/perf.c | 3 +-- 1 file changed, 1

[PATCH 06/11] perf config: Rework buildid_dir_command_config to perf_buildid_config

From: Taeung Song To avoid repeated calling perf_config() remove buildid_dir_command_config() and add new perf_buildid_config into perf_default_config. Because perf_config() is already called with perf_default_config at main(). Signed-off-by: Taeung Song Acked-by: Jiri Olsa Cc: Namhyung Kim

[PATCH 04/11] perf tests: Add test to check for event times

From: Jiri Olsa This test creates software event 'cpu-clock' attaches it in several ways and checks that enabled and running times match. Committer notes: Testing it: [acme@jouet linux]$ perf test -v times 44: Test events times:

[PATCH 04/11] perf tests: Add test to check for event times

From: Jiri Olsa This test creates software event 'cpu-clock' attaches it in several ways and checks that enabled and running times match. Committer notes: Testing it: [acme@jouet linux]$ perf test -v times 44: Test events times: --- start ---

[PATCH 07/11] perf config: Rename 'v' to 'home' in set_buildid_dir()

From: Taeung Song Change the variable name 'v' to 'home' to make it more readable. Signed-off-by: Taeung Song Acked-by: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Link:

[PATCH 08/11] perf script perl: Perl scripts now get a backtrace, like the python ones

From: Dima Kogan We have some infrastructure to use perl or python to analyze logs generated by perf. Prior to this patch, only the python tools had access to backtrace information. This patch makes this information available to perl scripts as well. Example: Let's

[PATCH 07/11] perf config: Rename 'v' to 'home' in set_buildid_dir()

From: Taeung Song Change the variable name 'v' to 'home' to make it more readable. Signed-off-by: Taeung Song Acked-by: Jiri Olsa Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1459099340-16911-3-git-send-email-treeze.tae...@gmail.com Signed-off-by: Arnaldo Carvalho de

[PATCH 08/11] perf script perl: Perl scripts now get a backtrace, like the python ones

From: Dima Kogan We have some infrastructure to use perl or python to analyze logs generated by perf. Prior to this patch, only the python tools had access to backtrace information. This patch makes this information available to perl scripts as well. Example: Let's look at malloc() calls

[PATCH 11/11] perf script: Add support for printing assembler

From: Andi Kleen When dumping PT traces with perf script it is very useful to see the assembler for each sample, so that it is easily possible to follow the control flow. As using objdump is difficult and inefficient from perf script this patch uses the udis86 library to

Re: [RFC][PATCH] mm/slub: Skip CPU slab activation when debugging

On 03/28/2016 06:52 PM, Laura Abbott wrote: On 03/28/2016 03:53 PM, Laura Abbott wrote: The per-cpu slab is designed to be the primary path for allocation in SLUB since it assumed allocations will go through the fast path if possible. When debugging is enabled, the fast path is disabled and

[PATCH 11/11] perf script: Add support for printing assembler

From: Andi Kleen When dumping PT traces with perf script it is very useful to see the assembler for each sample, so that it is easily possible to follow the control flow. As using objdump is difficult and inefficient from perf script this patch uses the udis86 library to implement assembler

Re: [RFC][PATCH] mm/slub: Skip CPU slab activation when debugging

On 03/28/2016 06:52 PM, Laura Abbott wrote: On 03/28/2016 03:53 PM, Laura Abbott wrote: The per-cpu slab is designed to be the primary path for allocation in SLUB since it assumed allocations will go through the fast path if possible. When debugging is enabled, the fast path is disabled and

[PATCH 10/11] perf tools: Add probing for udev86 library

From: Andi Kleen Add autoprobing for the udev86 disassembler library. Signed-off-by: Andi Kleen Acked-by: Jiri Olsa Cc: Stephane Eranian Link:

[PATCH 09/11] perf tools: Add support for skipping itrace instructions

From: Andi Kleen When using 'perf script' to look at PT traces it is often useful to ignore the initialization code at the beginning. On larger traces which may have many millions of instructions in initialization code doing that in a pipeline can be very slow, with perf

[PATCH 09/11] perf tools: Add support for skipping itrace instructions

From: Andi Kleen When using 'perf script' to look at PT traces it is often useful to ignore the initialization code at the beginning. On larger traces which may have many millions of instructions in initialization code doing that in a pipeline can be very slow, with perf script spending a lot

[PATCH 10/11] perf tools: Add probing for udev86 library

From: Andi Kleen Add autoprobing for the udev86 disassembler library. Signed-off-by: Andi Kleen Acked-by: Jiri Olsa Cc: Stephane Eranian Link: http://lkml.kernel.org/r/1459187142-20035-2-git-send-email-a...@firstfloor.org Signed-off-by: Arnaldo Carvalho de Melo ---

Re: [PATCH v3] sparc64: Reduce TLB flushes during hugepte changes

From: Nitin Gupta Date: Tue, 29 Mar 2016 14:11:14 -0700 > During hugepage map/unmap, TSB and TLB flushes are currently > issued at every PAGE_SIZE'd boundary which is unnecessary. > We now issue the flush at REAL_HPAGE_SIZE boundaries only. > > Without this patch

Applied "regulator: core: Log when we bring constraints into range" to the regulator tree

The patch regulator: core: Log when we bring constraints into range has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next

Re: [PATCH v3] sparc64: Reduce TLB flushes during hugepte changes

From: Nitin Gupta Date: Tue, 29 Mar 2016 14:11:14 -0700 > During hugepage map/unmap, TSB and TLB flushes are currently > issued at every PAGE_SIZE'd boundary which is unnecessary. > We now issue the flush at REAL_HPAGE_SIZE boundaries only. > > Without this patch workloads which unmap a large

Applied "regulator: core: Log when we bring constraints into range" to the regulator tree

The patch regulator: core: Log when we bring constraints into range has been applied to the regulator tree at git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next

Re: [GIT PULL] bcm2835 clk changes for 4.6 maybe

On 03/17, Eric Anholt wrote: > This is late, so feel free to drop it, but I figured I'd send it to > you in case you were still open to merges. I've pounded on it a bit > today (modesets to all sorts of resolutions on HDMI, used it for > testing the DPI panel support that I'm hoping to have for

Re: [GIT PULL] bcm2835 clk changes for 4.6 maybe

On 03/17, Eric Anholt wrote: > This is late, so feel free to drop it, but I figured I'd send it to > you in case you were still open to merges. I've pounded on it a bit > today (modesets to all sorts of resolutions on HDMI, used it for > testing the DPI panel support that I'm hoping to have for

[PATCH] regulator: core: Log when we bring constraints into range

This aids in debugging problems triggered by the regulator core applying its constraints, we could potentially crash immediately after updating the voltage if the constraints are buggy. Signed-off-by: Mark Brown --- drivers/regulator/core.c | 2 ++ 1 file changed, 2

[PATCH] regulator: core: Log when we bring constraints into range

This aids in debugging problems triggered by the regulator core applying its constraints, we could potentially crash immediately after updating the voltage if the constraints are buggy. Signed-off-by: Mark Brown --- drivers/regulator/core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

Re: 3.14.65: Memory leak when slub_debug is enabled

On Tue, 29 Mar 2016, Ajay Patel wrote: > We have custom board with Marvell Armada dual core ARMV7. > The driver uses buffers from kmalloc-8192 slab heavily. > When slub_debug is enabled, the kmalloc-8192 active slabs are > increasing. The slub stats shows cmpxchg_double_fail and objects_partial

Re: 3.14.65: Memory leak when slub_debug is enabled

On Tue, 29 Mar 2016, Ajay Patel wrote: > We have custom board with Marvell Armada dual core ARMV7. > The driver uses buffers from kmalloc-8192 slab heavily. > When slub_debug is enabled, the kmalloc-8192 active slabs are > increasing. The slub stats shows cmpxchg_double_fail and objects_partial

Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies

On 03/29/2016 05:25 PM, Linus Torvalds wrote: > On Tue, Mar 29, 2016 at 6:11 PM, Scotty Bauer wrote: >> >> Yeah I had toyed with using hashes, I used hash_64 not md5 which is like 14 >> extra instructions or something. > > That sounds fine. Anything that requires enough

Re: [PATCH v4 3/4] perf config: Prepare all default configs

On 03/30/2016 01:12 AM, Arnaldo Carvalho de Melo wrote: Em Tue, Mar 29, 2016 at 09:43:56AM +0900, Taeung Song escreveu: To precisely manage configs, prepare all default perf's configs that contain default section name, variable name, value and correct type, not string type. In the near

Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies

On 03/29/2016 05:25 PM, Linus Torvalds wrote: > On Tue, Mar 29, 2016 at 6:11 PM, Scotty Bauer wrote: >> >> Yeah I had toyed with using hashes, I used hash_64 not md5 which is like 14 >> extra instructions or something. > > That sounds fine. Anything that requires enough code to undo that it >

Re: [PATCH v4 3/4] perf config: Prepare all default configs

On 03/30/2016 01:12 AM, Arnaldo Carvalho de Melo wrote: Em Tue, Mar 29, 2016 at 09:43:56AM +0900, Taeung Song escreveu: To precisely manage configs, prepare all default perf's configs that contain default section name, variable name, value and correct type, not string type. In the near

Re: [PATCH 04/17] clk: qcom: ipq4019: switch remaining defines to enums

On 03/23, Matthew McClintock wrote: > When this was added not all the remaining defines were switched over to > use enums, so let's complete that process here > > Reported-by: Stephen Boyd > Signed-off-by: Matthew McClintock > --- Applied to

Re: [PATCH 04/17] clk: qcom: ipq4019: switch remaining defines to enums

On 03/23, Matthew McClintock wrote: > When this was added not all the remaining defines were switched over to > use enums, so let's complete that process here > > Reported-by: Stephen Boyd > Signed-off-by: Matthew McClintock > --- Applied to clk-fixes -- Qualcomm Innovation Center, Inc. is a

Re: [PATCH 05/17] clk: qcom: ipq4019: add some fixed clocks for ddrppl and fepll

On 03/23, Matthew McClintock wrote: > Drivers for these don't exist yet so we will add them as fixed clocks > so we don't BUG() if we change clocks that reference these clocks. > > Signed-off-by: Matthew McClintock > --- Applied to clk-fixes -- Qualcomm Innovation

Re: [PATCH 05/17] clk: qcom: ipq4019: add some fixed clocks for ddrppl and fepll

On 03/23, Matthew McClintock wrote: > Drivers for these don't exist yet so we will add them as fixed clocks > so we don't BUG() if we change clocks that reference these clocks. > > Signed-off-by: Matthew McClintock > --- Applied to clk-fixes -- Qualcomm Innovation Center, Inc. is a member of

Re: [PATCH v2] module: fix noreturn attribute for __module_put_and_exit()

On Mon, 21 Mar 2016, Jiri Kosina wrote: > __module_put_and_exit() is makred noreturn in module.h declaration, but is > lacking the attribute in the definition, which makes some tools (such as > sparse) unhappy. Amend the definition with the attribute as well (and > reformat the declaration so

Re: [PATCH v2] module: fix noreturn attribute for __module_put_and_exit()

On Mon, 21 Mar 2016, Jiri Kosina wrote: > __module_put_and_exit() is makred noreturn in module.h declaration, but is > lacking the attribute in the definition, which makes some tools (such as > sparse) unhappy. Amend the definition with the attribute as well (and > reformat the declaration so

Re: [PATCH v4 1/4] perf config: Introduce perf_config_set class

Hi, Arnaldo and Namhyung On 03/30/2016 01:12 AM, Arnaldo Carvalho de Melo wrote: Em Tue, Mar 29, 2016 at 09:43:13AM +0900, Taeung Song escreveu: This infrastructure code was designed for upcoming features of perf-config. That collect config key-value pairs from user and system config files

Re: [PATCH v4 1/4] perf config: Introduce perf_config_set class

Hi, Arnaldo and Namhyung On 03/30/2016 01:12 AM, Arnaldo Carvalho de Melo wrote: Em Tue, Mar 29, 2016 at 09:43:13AM +0900, Taeung Song escreveu: This infrastructure code was designed for upcoming features of perf-config. That collect config key-value pairs from user and system config files

Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies

On Tue, Mar 29, 2016 at 6:11 PM, Scotty Bauer wrote: > > Yeah I had toyed with using hashes, I used hash_64 not md5 which is like 14 > extra instructions or something. That sounds fine. Anything that requires enough code to undo that it kind of defeats the purpose of a SROP

Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies

On Tue, Mar 29, 2016 at 6:11 PM, Scotty Bauer wrote: > > Yeah I had toyed with using hashes, I used hash_64 not md5 which is like 14 > extra instructions or something. That sounds fine. Anything that requires enough code to undo that it kind of defeats the purpose of a SROP should be enough.

Re: [PATCH 2/2] x86/mtrr: Refactor PAT initialization code

On Tue, 2016-03-29 at 15:12 -0700, Luis R. Rodriguez wrote: > On Tue, Mar 29, 2016 at 2:46 PM, Toshi Kani wrote: > > On Tue, 2016-03-29 at 10:14 -0700, Luis R. Rodriguez wrote: > > > On Fri, Mar 18, 2016 at 2:35 PM, Toshi Kani > > > wrote:  : > > > > > >

Re: [PATCH 2/2] x86/mtrr: Refactor PAT initialization code

On Tue, 2016-03-29 at 15:12 -0700, Luis R. Rodriguez wrote: > On Tue, Mar 29, 2016 at 2:46 PM, Toshi Kani wrote: > > On Tue, 2016-03-29 at 10:14 -0700, Luis R. Rodriguez wrote: > > > On Fri, Mar 18, 2016 at 2:35 PM, Toshi Kani > > > wrote:  : > > > > > > Do we really need UC for the fan? > > >

Re: (mostly) Arch-independent livepatch

On Tue, 29 Mar 2016, Jessica Yu wrote: > > v6: > > - Since we hard-code the field widths for the objname and symbol name > > for the sscanf() calls, which are supposed to correspond to the values > > of MODULE_NAME_LEN and KSYM_NAME_LEN, use BUILD_BUG_ON() to detect when > > the values of

Re: (mostly) Arch-independent livepatch

On Tue, 29 Mar 2016, Jessica Yu wrote: > > v6: > > - Since we hard-code the field widths for the objname and symbol name > > for the sscanf() calls, which are supposed to correspond to the values > > of MODULE_NAME_LEN and KSYM_NAME_LEN, use BUILD_BUG_ON() to detect when > > the values of

Re: [PATCH v2 03/15] MIPS: PCI: Compatibility with ARM-like PCI host drivers

Le 03/02/2016 03:30, Paul Burton a écrit : > Introduce support for struct hw_pci & the associated pci_common_init_dev > function as used by the PCI drivers written for ARM platforms under > drivers/pci. This is in preparation for reusing the xilinx-pcie driver > on the MIPS Boston board. > >

Re: [PATCH v2 03/15] MIPS: PCI: Compatibility with ARM-like PCI host drivers

Le 03/02/2016 03:30, Paul Burton a écrit : > Introduce support for struct hw_pci & the associated pci_common_init_dev > function as used by the PCI drivers written for ARM platforms under > drivers/pci. This is in preparation for reusing the xilinx-pcie driver > on the MIPS Boston board. > >

Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies

On 03/29/2016 04:34 PM, Linus Torvalds wrote: > On Tue, Mar 29, 2016 at 4:38 PM, Andy Lutomirski wrote: >> >> Then there's an unanswered question: is this patch acceptable given >> that it's an ABI break? Security fixes are sometimes an exception to >> the "no ABI breaks"

Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies

On 03/29/2016 04:34 PM, Linus Torvalds wrote: > On Tue, Mar 29, 2016 at 4:38 PM, Andy Lutomirski wrote: >> >> Then there's an unanswered question: is this patch acceptable given >> that it's an ABI break? Security fixes are sometimes an exception to >> the "no ABI breaks" rule, but it's by no

[ANNOUNCE] 3.10.101-rt111

Dear RT Folks, I'm pleased to announce the 3.10.101-rt111 stable release. This release is just an update to the new stable 3.10.101 version and no RT specific changes have been made. You can get this release via the git tree at:

[ANNOUNCE] 3.12.57-rt77

Dear RT Folks, I'm pleased to announce the 3.12.57-rt77 stable release. This release is just an update to the new stable 3.12.57 version and no RT specific changes have been made. You can get this release via the git tree at:

[ANNOUNCE] 3.4.111-rt141

Dear RT Folks, I'm pleased to announce the 3.4.111-rt141 stable release. This release is just an update to the new stable 3.4.111 version and no RT specific changes have been made. You can get this release via the git tree at:

[ANNOUNCE] 3.12.57-rt77

Dear RT Folks, I'm pleased to announce the 3.12.57-rt77 stable release. This release is just an update to the new stable 3.12.57 version and no RT specific changes have been made. You can get this release via the git tree at:

[ANNOUNCE] 3.4.111-rt141

Dear RT Folks, I'm pleased to announce the 3.4.111-rt141 stable release. This release is just an update to the new stable 3.4.111 version and no RT specific changes have been made. You can get this release via the git tree at:

[ANNOUNCE] 3.10.101-rt111

Dear RT Folks, I'm pleased to announce the 3.10.101-rt111 stable release. This release is just an update to the new stable 3.10.101 version and no RT specific changes have been made. You can get this release via the git tree at:

[ANNOUNCE] 3.14.65-rt68

Dear RT Folks, I'm pleased to announce the 3.14.65-rt68 stable release. This release is just an update to the new stable 3.14.65 version and no RT specific changes have been made. You can get this release via the git tree at:

[ANNOUNCE] 3.14.65-rt68

Dear RT Folks, I'm pleased to announce the 3.14.65-rt68 stable release. This release is just an update to the new stable 3.14.65 version and no RT specific changes have been made. You can get this release via the git tree at:

Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies

On 03/29/2016 04:54 PM, Linus Torvalds wrote: > On Tue, Mar 29, 2016 at 2:53 PM, Scott Bauer wrote: >> >> These patches implement the necessary changes to generate a cookie >> which will be placed above signal frame upon signal delivery to userland. >> The cookie is

[ANNOUNCE] 3.18.29-rt30

Dear RT Folks, I'm pleased to announce the 3.18.29-rt30 stable release. Note, 3.18.29-rt29 was also released that only included the stable update. But -rt30 is released because the last pull of changes to 3.18-rt included a change that was also reverted in upstream. This release includes both

Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies

On 03/29/2016 04:54 PM, Linus Torvalds wrote: > On Tue, Mar 29, 2016 at 2:53 PM, Scott Bauer wrote: >> >> These patches implement the necessary changes to generate a cookie >> which will be placed above signal frame upon signal delivery to userland. >> The cookie is generated using a

[ANNOUNCE] 3.18.29-rt30

Dear RT Folks, I'm pleased to announce the 3.18.29-rt30 stable release. Note, 3.18.29-rt29 was also released that only included the stable update. But -rt30 is released because the last pull of changes to 3.18-rt included a change that was also reverted in upstream. This release includes both

[PATCH 1/1] perf tools: Add missing initialization of perf_sample.cpumode in synthesized samples

From: Arnaldo Carvalho de Melo In 473398a21d28 ("perf tools: Add cpumode to struct perf_sample"), I missed some places where perf_sample fields are directly initialized in addition to what is done in perf_evsel__parse_sample(), namely when synthesizing

[PATCH 1/1] perf tools: Add missing initialization of perf_sample.cpumode in synthesized samples

From: Arnaldo Carvalho de Melo In 473398a21d28 ("perf tools: Add cpumode to struct perf_sample"), I missed some places where perf_sample fields are directly initialized in addition to what is done in perf_evsel__parse_sample(), namely when synthesizing PERF_RECORD_{MMAP*,COMM,FORK,EXIT} for

Re: [PATCH] regulator: qcom_spmi: Add slewing delays for all SMPS types

On Tue, Mar 29, 2016 at 03:58:40PM -0700, Stephen Boyd wrote: > - if (vreg->logical_type == SPMI_REGULATOR_LOGICAL_TYPE_FTSMPS) { > - ret = spmi_regulator_ftsmps_init_slew_rate(vreg); > + if (vreg->logical_type == SPMI_REGULATOR_LOGICAL_TYPE_FTSMPS || > +

[GIT PULL 0/1] perf/urgent fix

/urgent (2016-03-29 10:39:12 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-urgent-for-mingo-20160329 for you to fetch changes up to 3ea223adcb0c5893a6dc8ed3a84dce264cbb61d6: perf tools: Add missing initialization

Re: [PATCH] regulator: qcom_spmi: Add slewing delays for all SMPS types

On Tue, Mar 29, 2016 at 03:58:40PM -0700, Stephen Boyd wrote: > - if (vreg->logical_type == SPMI_REGULATOR_LOGICAL_TYPE_FTSMPS) { > - ret = spmi_regulator_ftsmps_init_slew_rate(vreg); > + if (vreg->logical_type == SPMI_REGULATOR_LOGICAL_TYPE_FTSMPS || > +

[GIT PULL 0/1] perf/urgent fix

/urgent (2016-03-29 10:39:12 +0200) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-urgent-for-mingo-20160329 for you to fetch changes up to 3ea223adcb0c5893a6dc8ed3a84dce264cbb61d6: perf tools: Add missing initialization

[ANNOUNCE] 4.1.20-rt23

Dear RT Folks, I'm pleased to announce the 4.1.20-rt23 stable release. This release is just an update to the new stable 4.1.20 version and no RT specific changes have been made. You can get this release via the git tree at:

[ANNOUNCE] 4.1.20-rt23

Dear RT Folks, I'm pleased to announce the 4.1.20-rt23 stable release. This release is just an update to the new stable 4.1.20 version and no RT specific changes have been made. You can get this release via the git tree at:

Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies

On Tue, Mar 29, 2016 at 3:54 PM, Linus Torvalds wrote: > On Tue, Mar 29, 2016 at 2:53 PM, Scott Bauer wrote: >> >> These patches implement the necessary changes to generate a cookie >> which will be placed above signal frame upon signal

Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies

On Tue, Mar 29, 2016 at 3:54 PM, Linus Torvalds wrote: > On Tue, Mar 29, 2016 at 2:53 PM, Scott Bauer wrote: >> >> These patches implement the necessary changes to generate a cookie >> which will be placed above signal frame upon signal delivery to userland. >> The cookie is generated using a

Re: [PATCH v4 1/4] SROP Mitigation: Architecture independent code for signal cookies

On Tue, Mar 29, 2016 at 2:53 PM, Scott Bauer wrote: > @@ -1231,6 +1232,8 @@ void setup_new_exec(struct linux_binprm * bprm) > /* This is the point of no return */ > current->sas_ss_sp = current->sas_ss_size = 0; > > + get_random_bytes(>sig_cookie,

Re: [PATCH v4 1/4] SROP Mitigation: Architecture independent code for signal cookies

On Tue, Mar 29, 2016 at 2:53 PM, Scott Bauer wrote: > @@ -1231,6 +1232,8 @@ void setup_new_exec(struct linux_binprm * bprm) > /* This is the point of no return */ > current->sas_ss_sp = current->sas_ss_size = 0; > > + get_random_bytes(>sig_cookie,

Re: [PATCH v12 07/29] HMM: add per mirror page table v4.

On Tue, 8 Mar 2016, Jérôme Glisse wrote: > This patch add the per mirror page table. It also propagate CPU page > table update to this per mirror page table using mmu_notifier callback. > All update are contextualized with an HMM event structure that convey > all information needed by device

Re: [PATCH v12 07/29] HMM: add per mirror page table v4.

On Tue, 8 Mar 2016, Jérôme Glisse wrote: > This patch add the per mirror page table. It also propagate CPU page > table update to this per mirror page table using mmu_notifier callback. > All update are contextualized with an HMM event structure that convey > all information needed by device

[PATCH] regulator: qcom_spmi: Add slewing delays for all SMPS types

Only the FT SMPS type regulators have slewing supported in the driver, but all types of SMPS regulators need the same support. The only difference is that some SMPS regulators don't have a step size and the step delay is typically 20, not 8. Luckily, the step size reads as 0 for the non-FT types,

[PATCH] regulator: qcom_spmi: Add slewing delays for all SMPS types

Only the FT SMPS type regulators have slewing supported in the driver, but all types of SMPS regulators need the same support. The only difference is that some SMPS regulators don't have a step size and the step delay is typically 20, not 8. Luckily, the step size reads as 0 for the non-FT types,

Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies

On Tue, Mar 29, 2016 at 5:54 PM, Linus Torvalds wrote: > > So you could do 4 32 > > - the random value > - the low 32 bits of the address of the cookie > - the low 32 bits of the return point stack and instruction pointer Oops, editing mishap. That was supposed

Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies

On Tue, Mar 29, 2016 at 5:54 PM, Linus Torvalds wrote: > > So you could do 4 32 > > - the random value > - the low 32 bits of the address of the cookie > - the low 32 bits of the return point stack and instruction pointer Oops, editing mishap. That was supposed to be about the 128-bit md5

mmotm 2016-03-29-15-54 uploaded

The mm-of-the-moment snapshot 2016-03-29-15-54 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

Re: [kernel-hardening] Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies

> Then there's an unanswered question: is this patch acceptable given > that it's an ABI break?  Security fixes are sometimes an exception to > the "no ABI breaks" rule, but it's by no means an automatic exception. > > --Andy It seems this could be worked around in general. Processes can have a

mmotm 2016-03-29-15-54 uploaded

The mm-of-the-moment snapshot 2016-03-29-15-54 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

Re: [kernel-hardening] Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies

> Then there's an unanswered question: is this patch acceptable given > that it's an ABI break?  Security fixes are sometimes an exception to > the "no ABI breaks" rule, but it's by no means an automatic exception. > > --Andy It seems this could be worked around in general. Processes can have a

Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies

On Tue, Mar 29, 2016 at 2:53 PM, Scott Bauer wrote: > > These patches implement the necessary changes to generate a cookie > which will be placed above signal frame upon signal delivery to userland. > The cookie is generated using a per-process random value xor'd with > the

Re: [PATCH v4 0/4] SROP Mitigation: Sigreturn Cookies

On Tue, Mar 29, 2016 at 2:53 PM, Scott Bauer wrote: > > These patches implement the necessary changes to generate a cookie > which will be placed above signal frame upon signal delivery to userland. > The cookie is generated using a per-process random value xor'd with > the address where the

Re: arm64: kernel v4.6-rc1 hangs on QEMU

On Wed, Mar 30, 2016 at 12:32:42AM +0200, Arnd Bergmann wrote: > On Wednesday 30 March 2016 01:22:17 Yury Norov wrote: > > > > > > Undefined instruction in cpuinfo_store_boot_cpu() could be related > > > to the SYS_ID_AA64MMFR2_EL1 access that was recently added. > > > > > > What does the

Re: arm64: kernel v4.6-rc1 hangs on QEMU

On Wed, Mar 30, 2016 at 12:32:42AM +0200, Arnd Bergmann wrote: > On Wednesday 30 March 2016 01:22:17 Yury Norov wrote: > > > > > > Undefined instruction in cpuinfo_store_boot_cpu() could be related > > > to the SYS_ID_AA64MMFR2_EL1 access that was recently added. > > > > > > What does the

Re: [PATCH v3] sched/deadline: do not try to push tasks if pinned task switches to dl

On Wed, 22 Oct 2014 10:33:05 +0100 Juri Lelli wrote: > On 22/10/14 01:36, Wanpeng Li wrote: > > As Kirill mentioned(https://lkml.org/lkml/2013/1/29/118): > > | If rq has already had 2 or more pushable tasks and we try to add a > > | pinned task then call of push_rt_task will

Re: [PATCH v3] sched/deadline: do not try to push tasks if pinned task switches to dl

On Wed, 22 Oct 2014 10:33:05 +0100 Juri Lelli wrote: > On 22/10/14 01:36, Wanpeng Li wrote: > > As Kirill mentioned(https://lkml.org/lkml/2013/1/29/118): > > | If rq has already had 2 or more pushable tasks and we try to add a > > | pinned task then call of push_rt_task will just waste a time.

[PATCH] acpi/acpica: fix Thunderbolt hotplug

The following hung task trace is seen when hotplugging an ethernet dongle in a Thunderbolt port on Linux. INFO: task kworker/0:4:1468 blocked for more than 120 seconds. Tainted: GW 4.6.0-rc1+ #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

[PATCH] acpi/acpica: fix Thunderbolt hotplug

The following hung task trace is seen when hotplugging an ethernet dongle in a Thunderbolt port on Linux. INFO: task kworker/0:4:1468 blocked for more than 120 seconds. Tainted: GW 4.6.0-rc1+ #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

Re: [PATCH v3] sparc64: Reduce TLB flushes during hugepte changes

Hi Nitin, [auto build test ERROR on sparc/master] [also build test ERROR on v4.6-rc1 next-20160329] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Nitin-Gupta/sparc64-Reduce-TLB-flushes

Re: [PATCH v3] sparc64: Reduce TLB flushes during hugepte changes

Hi Nitin, [auto build test ERROR on sparc/master] [also build test ERROR on v4.6-rc1 next-20160329] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Nitin-Gupta/sparc64-Reduce-TLB-flushes

Re: fallocate INSERT_RANGE/COLLAPSE_RANGE is completely broken [PATCH]

On Mon, Mar 28, 2016 at 10:04:10PM -0800, Kent Overstreet wrote: > On Tue, Mar 29, 2016 at 04:15:58PM +1100, Dave Chinner wrote: > > On Mon, Mar 28, 2016 at 08:25:46PM -0800, Kent Overstreet wrote: > > > Bit of previous discussion: > > > http://thread.gmane.org/gmane.linux.file-systems/101201/ > >

Re: fallocate INSERT_RANGE/COLLAPSE_RANGE is completely broken [PATCH]

On Mon, Mar 28, 2016 at 10:04:10PM -0800, Kent Overstreet wrote: > On Tue, Mar 29, 2016 at 04:15:58PM +1100, Dave Chinner wrote: > > On Mon, Mar 28, 2016 at 08:25:46PM -0800, Kent Overstreet wrote: > > > Bit of previous discussion: > > > http://thread.gmane.org/gmane.linux.file-systems/101201/ > >

Re: [REGRESSION 4.6-rc1] NFS mounts (using autofs) failing

On 03/30/16 04:17, Arend van Spriel wrote: > On 29-03-16 16:02, Al Viro wrote: >> On Tue, Mar 29, 2016 at 01:11:55PM +0200, Arend Van Spriel wrote: >>> Moved to 4.6-rc1 and found NFS mounts were failing moving to the new >>> kernel. The NFS mounts are done using autofs. Below is the bisect log >>>

Re: [REGRESSION 4.6-rc1] NFS mounts (using autofs) failing

On 03/30/16 04:17, Arend van Spriel wrote: > On 29-03-16 16:02, Al Viro wrote: >> On Tue, Mar 29, 2016 at 01:11:55PM +0200, Arend Van Spriel wrote: >>> Moved to 4.6-rc1 and found NFS mounts were failing moving to the new >>> kernel. The NFS mounts are done using autofs. Below is the bisect log >>>

<    1   2   3   4   5   6   7   8   9   10   >