Re: [tip:efi/core] x86/efi: Unmap EFI boot services code/data regions from efi_pgd

On Mon, 17 Dec 2018 at 20:48, Prakhya, Sai Praneeth wrote: > > > > > > Hi Thomas and Ingo, > > > > > > > > > > I recently noticed that the below commits [1] and [2] are broken > > > > > when kernel command line argument "efi=old_map" is passed. Sorry! > > > > > I missed to test this condition

Re: [PATCH] blkcg: add rcu lock to bio_clone_blkg_association()

On 12/21/18 10:02 AM, Dennis Zhou wrote: > On Fri, Dec 21, 2018 at 08:26:02AM -0700, Jens Axboe wrote: >> On 12/21/18 7:54 AM, Dennis Zhou wrote: >>> I cleaned up blkg_tryget_closest() to require rcu_read_lock() earlier. >>> However, this was a subtle case too which clearly was too subtle for me.

Re: [PATCH] blkcg: add rcu lock to bio_clone_blkg_association()

On Fri, Dec 21, 2018 at 08:26:02AM -0700, Jens Axboe wrote: > On 12/21/18 7:54 AM, Dennis Zhou wrote: > > I cleaned up blkg_tryget_closest() to require rcu_read_lock() earlier. > > However, this was a subtle case too which clearly was too subtle for me. > > The idea was the src bio should be

Re: [PATCH net-next 0/4] bridge: implement Multicast Router Discovery (RFC4286)

From: Linus Lüssing Date: Fri, 21 Dec 2018 16:15:07 +0100 > This patchset adds initial Multicast Router Discovery support to > the Linux bridge (RFC4286). With MRD it is possible to detect multicast > routers and mark bridge ports and forward multicast packets to such routers > accordingly. ...

Re: [PATCH v3 2/9] ASoC: sun4i-i2s: Add regmap field to sign extend sample

On Fri, Dec 21, 2018 at 11:21 PM wrote: > > From: Marcus Cooper > > On the newer SoCs this is set by default to transfer a 0 after > each sample in each slot. Add the regmap field to configure this > and set it so that it pads the sample with 0s. > > Signed-off-by: Marcus Cooper The code

Re: [PATCH v2] mfd: tqmx86: IO controller with i2c, wachdog and gpio

> > +config MFD_TQMX86 > > + tristate "TQ-Systems IO controller TQMX86" > > + select MFD_CORE > > + help > > + Say yes here to enable support for various functions of the > > + TQ-Systems IO controller and watchdog device, found on their > > + ComExpress CPU modules

Re: linux-next: Tree for Dec 21 (nvdimm/security.o)

On 12/21/18 12:32 AM, Stephen Rothwell wrote: > Hi all, > > News: there will be no linux-next release until Jan 2. Have a good break. > > Changes since 20181220: > on x86_64: ld: drivers/nvdimm/security.o: in function `nvdimm_request_key': security.c:(.text+0xbe): undefined reference to

Re: [PATCH v2 1/4] vmalloc: New flags for safe vfree on special perms

> On Dec 21, 2018, at 9:39 AM, Ard Biesheuvel wrote: > >> On Wed, 12 Dec 2018 at 03:20, Andy Lutomirski wrote: >> >> On Tue, Dec 11, 2018 at 4:12 PM Rick Edgecombe >> wrote: >>> >>> This adds two new flags VM_IMMEDIATE_UNMAP and VM_HAS_SPECIAL_PERMS, for >>> enabling vfree operations to

Re: [tip:efi/core] x86/efi: Unmap EFI boot services code/data regions from efi_pgd

On Fri, Dec 21, 2018 at 06:02:29PM +0100, Ard Biesheuvel wrote: > As far as I can tell, the SGI x86 UV platforms still rely on this, so > we're stuck with it for the foreseeable future. What happened with the old apple laptops which couldn't handle high virtual mappings and needed 1:1? We don't

Re: x86/sgx: uapi change proposal

> On Dec 21, 2018, at 9:28 AM, Sean Christopherson > wrote: > > On Wed, Dec 19, 2018 at 06:58:48PM -0800, Andy Lutomirski wrote: >>> On Dec 19, 2018, at 6:45 AM, Sean Christopherson >>> wrote: >>> > On Wed, Dec 19, 2018 at 09:36:16AM +, Jethro Beekman wrote: >>> >>> I agree with

Re: [PATCH 3/3] sched/fair: fix unnecessary increase of balance interval

On 21/12/2018 14:49, Vincent Guittot wrote: [...] > After looking at shed.c at this sha1, (sd->nr_balance_failed > > sd->cache_nice_tries+2) was the only condition for doing active > migration and as a result it was the only reason for doubling > sd->balance_interval. > My patch keeps exactly the

Re: [PATCH v3 3/9] ASoc: sun4i-i2s: Add 20, 24 and 32 bit support

On Sat, Dec 22, 2018 at 12:48 AM Chen-Yu Tsai wrote: > > On Fri, Dec 21, 2018 at 11:21 PM wrote: > > > > From: Marcus Cooper > > > > Extend the functionality of the driver to include support of 20 and > > 24 bits per sample for the earlier SoCs. > > > > Newer SoCs can also handle 32bit samples.

Re: [PATCH 0/7] ARM: hacks for link-time optimization

> In particular turning an address-dependency into a control-dependency, > which is something allowed by the C language, since it doesn't recognise > these concepts as such. > > The 'optimization' is allowed currently, but LTO will make it much more > likely since it will have a much wider view

[PATCH] drm/i915/psr: simplify enable_psr handling

The following commit: commit 2bdd045e3a30 ("drm/i915/psr: Check if VBT says PSR can be enabled.") added some code with no usable functionality. Regardless of how the psr default is set up in the BDB_DRIVER_FEATURES section, if the enable_psr module parameter isn't specified it defaults to 0.

Re: [PATCH 04/12] __wr_after_init: x86_64: __wr_op

On Thu, Dec 20, 2018 at 11:19 AM Igor Stoppa wrote: > > > > On 20/12/2018 20:49, Matthew Wilcox wrote: > > > I think you're causing yourself more headaches by implementing this "op" > > function. > > I probably misinterpreted the initial criticism on my first patchset, > about duplication.

Re: [PATCH v2 1/4] vmalloc: New flags for safe vfree on special perms

On Fri, 21 Dec 2018 at 18:12, Andy Lutomirski wrote: > > > On Dec 21, 2018, at 9:39 AM, Ard Biesheuvel > > wrote: > > > >> On Wed, 12 Dec 2018 at 03:20, Andy Lutomirski wrote: > >> > >> On Tue, Dec 11, 2018 at 4:12 PM Rick Edgecombe > >> wrote: > >>> > >>> This adds two new flags

Re: [tip:efi/core] x86/efi: Unmap EFI boot services code/data regions from efi_pgd

On Fri, 21 Dec 2018 at 18:13, Borislav Petkov wrote: > > On Fri, Dec 21, 2018 at 06:02:29PM +0100, Ard Biesheuvel wrote: > > As far as I can tell, the SGI x86 UV platforms still rely on this, so > > we're stuck with it for the foreseeable future. > > What happened with the old apple laptops which

Re: linux-next: Tree for Dec 21 (acpi without CONFIG_PCI)

On 12/21/18 9:23 AM, Sinan Kaya wrote: > > > On Friday, December 21, 2018, Randy Dunlap > wrote: > > On 12/21/18 12:32 AM, Stephen Rothwell wrote: > > Hi all, > > > > News: there will be no linux-next release until Jan 2.  Have a good > break. >

I NEED A TRUSTWORTHY PARTNER.

-- Hello, Compliment of the season. I have a lucrative and profitable business to discuse with you. Reply urgently if you are intersted for more details. Regards, Prisca Lamberth

[PATCH 3/3] pinctrl: dt-bindings: Fix the armada-37xx documentation

While it was possible to configure the PCIe1 Wakeup pin, it was missing in the bidding, let's document it. Signed-off-by: Gregory CLEMENT --- .../bindings/pinctrl/marvell,armada-37xx-pinctrl.txt| 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git

[PATCH 1/3] pinctrl: armada-37xx: Correct mpp definitions

From: Marek Behún This is a cleanup and fix of the patch by Ken Ma . Fix the mpp definitions according to newest revision of the specification: - northbridge: fix pmic1 gpio number to 7 fix pmic0 gpio number to 6 - southbridge split pcie1 group bit mask to BIT(5) and BIT(9)

[PATCH 2/3] pinctrl: armada-37xx: add missing pin: PCIe1 Wakeup

Declare the PCIe1 Wakeup which was initially missing. Signed-off-by: Gregory CLEMENT --- drivers/pinctrl/mvebu/pinctrl-armada-37xx.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c b/drivers/pinctrl/mvebu/pinctrl-armada-37xx.c index

[PATCH 0/3] Few fix for pins configuration on Armada 37xx

Hello, this small series fixes wrong pins configuration we currently have on Armada 37xx. For now it is especially annoying it we want to enable suspend to RAM for PCie. Gregory Gregory CLEMENT (2): pinctrl: armada-37xx: add missing pin: PCIe1 Wakeup pinctrl: dt-bindings: Fix the

Re: linux-next: Tree for Dec 21 (mmc/host/sdhci-omap.c)

On 12/21/18 12:32 AM, Stephen Rothwell wrote: > Hi all, > > News: there will be no linux-next release until Jan 2. Have a good break. > > Changes since 20181220: > on x86_64: This change to drivers/mmc/host/Kconfig: config MMC_SDHCI_OMAP tristate "TI SDHCI Controller Support"

Re: [PATCH] smack: Fix a memory leak in smack_add_opt()

On 12/21/2018 8:42 AM, Al Viro wrote: > On Fri, Dec 21, 2018 at 04:36:54PM +, Al Viro wrote: >> On Fri, Dec 21, 2018 at 12:09:58PM +0300, Dan Carpenter wrote: >>> The function is leaking "opts" on the error paths. >>> >>> Fixes: 90e3b564ab93 ("smack: take the guts of smack_parse_opts_str()

Re: [PATCH 3/3] sched/fair: fix unnecessary increase of balance interval

On Fri, 21 Dec 2018 at 18:15, Valentin Schneider wrote: > > On 21/12/2018 14:49, Vincent Guittot wrote: > [...] > > After looking at shed.c at this sha1, (sd->nr_balance_failed > > > sd->cache_nice_tries+2) was the only condition for doing active > > migration and as a result it was the only

[ANNOUNCE] v4.19.10-rt8

Dear RT folks! I'm pleased to announce the v4.19.10-rt8 patch set. Changes since v4.19.10-rt7: - Additional trace points in i915 could fail to compile due to the NOTRACE in statement since last release. - Make a rwlock in kmemleak raw to avoid scheduling in wrong context. Report

Re: [PATCH 04/12] __wr_after_init: x86_64: __wr_op

On 21/12/2018 19:23, Andy Lutomirski wrote: On Thu, Dec 20, 2018 at 11:19 AM Igor Stoppa wrote: On 20/12/2018 20:49, Matthew Wilcox wrote: I think you're causing yourself more headaches by implementing this "op" function. I probably misinterpreted the initial criticism on my first

Re: linux-next: Tree for Dec 21 (acpi without CONFIG_PCI)

On 12/21/18 9:23 AM, Sinan Kaya wrote: > > > On Friday, December 21, 2018, Randy Dunlap > wrote: > > On 12/21/18 12:32 AM, Stephen Rothwell wrote: > > Hi all, > > > > News: there will be no linux-next release until Jan 2.  Have a good > break. >

Re: [PATCH v4 02/18] iommu/mediatek: Use a struct as the platform data

On 08/12/2018 09:39, Yong Wu wrote: > Use a struct as the platform special data instead of the enumeration. > This is a prepare patch for adding mt8183 iommu support. > > Signed-off-by: Yong Wu > --- Reviewed-by: Matthias Brugger > drivers/iommu/mtk_iommu.c | 24 >

Re: [PATCH v4 03/18] memory: mtk-smi: Use a general config_port interface

On 08/12/2018 09:39, Yong Wu wrote: > The config_port of mt2712 and mt8183 are the same. Use a general > config_port interface instead. > > In addition, in mt2712, larb8 and larb9 are the bdpsys larbs which > are not the normal larb, their register space are different from the > normal one.

Re: [PATCH v4 04/18] memory: mtk-smi: Use a struct for the platform data for smi-common

On 08/12/2018 09:39, Yong Wu wrote: > Use a struct as the platform special data instead of the enumeration. > > Also there is a minor change that moving the position of > "enum mtk_smi_gen" definition, this is because we expect define > "struct mtk_smi_common_plat" before it is referred. > >

Assalamualaikum My Dear Friend,

Assalamualaikum My Dear Friend, Before I introduce myself, I wish to inform you that this letter is not a hoax mail and I urge you to treat it serious. This letter must come to you as a big surprise, but I believe it is only a day that people meet and become great friends and business

Re: [PATCH] i2c: bcm2835: Clear current message and count after a transaction

On 12/21/18 4:11 AM, Paul Kocialkowski wrote: > The driver's interrupt handler checks whether a message is currently > being handled with the curr_msg pointer. When it is NULL, the interrupt > is considered to be unexpected. Similarly, the i2c_start_transfer > routine checks for the remaining

RE: [tip:efi/core] x86/efi: Unmap EFI boot services code/data regions from efi_pgd

> > > For the short term, could we simply make your changes dependent on > > > efi != old_map? That gives us some time to fix the old_map case properly. > > > > Yes, I think we could and it should work but I hesitated to propose it > > because (as you already noted) it's a short term fix and not

Re: [PATCH] ACPI / tables: Add an ifdef around amlcode and dsdt_amlcode

On Thu, Dec 20, 2018 at 1:57 PM Nathan Chancellor wrote: > > On Thu, Dec 20, 2018 at 12:38:56PM -0700, Nathan Chancellor wrote: > > Clang warns: > > > > drivers/acpi/tables.c:715:14: warning: unused variable 'amlcode' > > [-Wunused-variable] > > static void *amlcode __attribute__

Re: [PATCH 2/2] ARC: show_regs: fix lockdep splat for good

On 12/21/18 5:04 AM, Michal Hocko wrote: >> I presume you are referring to original commit, not my anti-change in ARC >> code, >> which is actually re-enabling it. > > Yes, but you are building on a broken concept I believe. Not sure where this is heading. Broken concept was introduced by

[for-next][PATCH 06/24] sparc64: Use ftrace_graph_get_ret_stack() instead of curr_ret_stack

From: "Steven Rostedt (VMware)" The structure of the ret_stack array on the task struct is going to change, and accessing it directly via the curr_ret_stack index will no longer give the ret_stack entry that holds the return address. To access that, architectures must now use

[for-next][PATCH 05/24] powerpc/frace: Use ftrace_graph_get_ret_stack() instead of curr_ret_stack

From: "Steven Rostedt (VMware)" The structure of the ret_stack array on the task struct is going to change, and accessing it directly via the curr_ret_stack index will no longer give the ret_stack entry that holds the return address. To access that, architectures must now use

[for-next][PATCH 16/24] tracing: Use hist triggers var_ref array to destroy var_refs

From: Tom Zanussi Since every var ref for a trigger has an entry in the var_ref[] array, use that to destroy the var_refs, instead of piecemeal via the field expressions. This allows us to avoid having to keep and treat differently separate lists for the action-related references, which future

[for-next][PATCH 01/24] ftrace: Allow ftrace_replace_code() to be schedulable

From: "Steven Rostedt (VMware)" The function ftrace_replace_code() is the ftrace engine that does the work to modify all the nops into the calls to the function callback in all the functions being traced. The generic version which is normally called from stop machine, but an architecture can

[for-next][PATCH 24/24] tracing: Use strncmp_prefix() helper for histogram code

From: "Steven Rostedt (VMware)" The tracing histogram code contains a lot of instances of the construct: strncmp(str, "const", sizeof("const") - 1) This can be prone to bugs due to typos or bad cut and paste. Use the strncmp_prefix() helper macro instead that removes the need for having two

[for-next][PATCH 19/24] tracing: Merge seq_print_sym_short() and seq_print_sym_offset()

From: Rasmus Villemoes These two functions are nearly identical, so we can avoid some code duplication by moving the conditional into a common implementation. Link: http://lkml.kernel.org/r/20181029223542.26175-2-li...@rasmusvillemoes.dk Signed-off-by: Rasmus Villemoes Signed-off-by: Steven

[for-next][PATCH 21/24] tracing: Simplify printfing in seq_print_sym

From: Rasmus Villemoes trace_seq_printf(..., "%s", ...) can be done with trace_seq_puts() instead, avoiding printf overhead. In the second instance, the string we're copying was just created from an snprintf() to a stack buffer, so we might as well do that printf directly. This naturally leads

[for-next][PATCH 23/24] string.h: Add strncmp_prefix() helper macro

From: Steven Rostedt A discussion came up in the trace triggers thread about converting a bunch of: strncmp(str, "const", sizeof("const") - 1) use cases into a helper macro. It started with: strncmp(str, const, sizeof(const) - 1) But then Joe Perches mentioned that if a const is not

Re: [PATCH v1 1/2] soc: qcom: rmtfs-mem: Add class to enable uevents

On Thu, Dec 20, 2018 at 5:19 PM Brian Norris wrote: > > Hi Evan, > > On Mon, Dec 17, 2018 at 04:08:33PM -0800, Evan Green wrote: > > Currently the qcom_rmtfs_memN devices are entirely invisible to the udev > > world. > > Add a class to the rmtfs device so that uevents fire when the device is >

[for-next][PATCH 15/24] tracing: Remove open-coding of hist trigger var_ref management

From: Tom Zanussi Have create_var_ref() manage the hist trigger's var_ref list, rather than having similar code doing it in multiple places. This cleans up the code and makes sure var_refs are always accounted properly. Also, document the var_ref-related functions to make what their purpose

[for-next][PATCH 13/24] tracing: Change strlen to sizeof for hist trigger static strings

From: Tom Zanussi There's no need to use strlen() for static strings when the length is already known, so update trace_events_hist.c with sizeof() for those cases. Link: http://lkml.kernel.org/r/e3e754f2bd18e56eaa8baf79bee619316ebf4cfc.1545161087.git.tom.zanu...@linux.intel.com Acked-by:

[for-next][PATCH 14/24] tracing: Use var_refs[] for hist trigger reference checking

From: Tom Zanussi Since all the variable reference hist_fields are collected into hist_data->var_refs[] array, there's no need to go through all the fields looking for them, or in separate arrays like synth_var_refs[], which will be going away soon anyway. This also allows us to get rid of some

[for-next][PATCH 17/24] tracing: Remove hist trigger synth_var_refs

From: Tom Zanussi All var_refs are now handled uniformly and there's no reason to treat the synth_refs in a special way now, so remove them and associated functions. Link: http://lkml.kernel.org/r/b4d3470526b8f0426dcec125399dad9ad9b8589d.1545161087.git.tom.zanu...@linux.intel.com Acked-by:

[for-next][PATCH 18/24] tracing: Add hist trigger comments for variable-related fields

From: Tom Zanussi Add a few comments to help clarify how variable and variable reference fields are used in the code. Link: http://lkml.kernel.org/r/ea857ce948531d7bec712bbb0f38360aa1d378ec.1545161087.git.tom.zanu...@linux.intel.com Acked-by: Namhyung Kim Reviewed-by: Masami Hiramatsu

[for-next][PATCH 10/24] seq_buf: Use size_t for len in seq_buf_puts()

From: Michael Ellerman Jann Horn points out that we're using unsigned int for len in seq_buf_puts(), which could potentially overflow if we're passed a UINT_MAX sized string. The rest of the code already uses size_t, so we should also use that in seq_buf_puts() to avoid any issues. Link:

[for-next][PATCH 12/24] tracing: Remove unnecessary hist trigger struct field

From: Tom Zanussi hist_field.var_idx is completely unused, so remove it. Link: http://lkml.kernel.org/r/d4e066c0f509f5f13ad3babc8c33ca6e7ddc439a.1545161087.git.tom.zanu...@linux.intel.com Acked-by: Namhyung Kim Reviewed-by: Masami Hiramatsu Signed-off-by: Tom Zanussi Signed-off-by: Steven

[for-next][PATCH 04/24] x86/ftrace: Do not call function graph from dynamic trampolines

From: "Steven Rostedt (VMware)" Since commit 79922b8009c07 ("ftrace: Optimize function graph to be called directly"), dynamic trampolines should not be calling the function graph tracer at the end. If they do, it could cause the function graph tracer to trace functions that it filtered out.

[for-next][PATCH 11/24] tracing: Fix ftrace_graph_get_ret_stack() to use task and not current

From: "Steven Rostedt (VMware)" The function ftrace_graph_get_ret_stack() takes a task struct descriptor but uses current as the task to perform the operations on. In pretty much all cases the task decriptor is the same as current, so this wasn't an issue. But there is a case in the ARM

[for-next][PATCH 08/24] arm64: Use ftrace_graph_get_ret_stack() instead of curr_ret_stack

From: "Steven Rostedt (VMware)" The structure of the ret_stack array on the task struct is going to change, and accessing it directly via the curr_ret_stack index will no longer give the ret_stack entry that holds the return address. To access that, architectures must now use

[for-next][PATCH 07/24] sh: ftrace: Use ftrace_graph_get_ret_stack() instead of curr_ret_stack

From: "Steven Rostedt (VMware)" The structure of the ret_stack array on the task struct is going to change, and accessing it directly via the curr_ret_stack index will no longer give the ret_stack entry that holds the return address. To access that, architectures must now use

[for-next][PATCH 03/24] fgraph: Add comment to describe ftrace_graph_get_ret_stack

From: "Steven Rostedt (VMware)" The ret_stack should not be accessed directly via the curr_ret_stack variable on the task_struct. This is because the ret_stack is going to be converted into a series of longs and not an array of ret_stack structures. The way that a ret_stack should be retrieved

[for-next][PATCH 02/24] arm64: ftrace: Set FTRACE_MAY_SLEEP before ftrace_modify_all_code()

From: "Steven Rostedt (VMware)" It has been reported that ftrace_replace_code() which is called by ftrace_modify_all_code() can cause a soft lockup warning for an allmodconfig kernel. This is because all the debug options enabled causes the loop in ftrace_replace_code() (which loops over all the

[for-next][PATCH 00/24] tracing: Updates for the next (coming soon) merge window

git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git for-next Head SHA1: 05cd667ce570cb82a967af7166c54c610324861c Mathieu Malaterre (1): tracing: Make function ‘ftrace_exports’ static Michael Ellerman (2): seq_buf: Make seq_buf_puts() null-terminate the

Re: [PATCH 01/13] clk: qcom: gcc: limit GPLL0_AO_OUT operating frequency

Hello, On 12/21/2018 6:06 PM, Jorge Ramirez wrote: On 12/21/18 12:19, Taniya Das wrote: On 12/17/2018 3:16 PM, Jorge Ramirez-Ortiz wrote: Limit the GPLL0_AO_OUT_MAIN operating frequency as per its hardware specifications. Co-developed-by: Niklas Cassel Signed-off-by: Niklas Cassel

Re: [PATCH 0/7] ARM: hacks for link-time optimization

On Fri, Dec 21, 2018 at 09:20:44AM -0800, Andi Kleen wrote: > > In particular turning an address-dependency into a control-dependency, > > which is something allowed by the C language, since it doesn't recognise > > these concepts as such. > > > > The 'optimization' is allowed currently, but LTO

Re: [for-next][PATCH 09/24] seq_buf: Make seq_buf_puts() null-terminate the buffer

On Fri, 21 Dec 2018 12:56:27 -0500 Steven Rostedt wrote: > From: Michael Ellerman > > Currently seq_buf_puts() will happily create a non null-terminated > string for you in the buffer. This is particularly dangerous if the > buffer is on the stack. > > For example: > > char buf[8]; >

Re: linux-next: Tree for Dec 21 (SND_HDA_INTEL_DSP_DETECTION)

On 12/21/18 12:32 AM, Stephen Rothwell wrote: > Hi all, > > News: there will be no linux-next release until Jan 2. Have a good break. > > Changes since 20181220: > on x86_64: A new group of Kconfig "select"s is causing kconfig warnings: WARNING: unmet direct dependencies detected for

Re: [PATCH 00/14] Add support for FM radio in hcill and kill TI_ST

* Sebastian Reichel [181221 01:18]: > The new code has been tested on the Motorola Droid 4. For testing the audio > should be configured to route Ext to Speaker or Headphone. Then you need to > plug headphone, since its cable is used as antenna. For testing there is a > 'radio' utility packages

Re: [for-next][PATCH 09/24] seq_buf: Make seq_buf_puts() null-terminate the buffer

On Fri, 21 Dec 2018 13:00:21 -0500 Steven Rostedt wrote: > > Can result in: > > > > Message is fooªªªªªsecret > > Sending this via quilt, and that we have non UTF8 characters causes > LKML to blow up. > > There's a couple more patches with this issue. I'm going to fix up the >

[PATCH v1] cpufreq: qcom: Read voltage LUT and populate OPP

Add support to read the voltage look up table and populate OPP for all corresponding CPUS. Signed-off-by: Taniya Das --- drivers/cpufreq/qcom-cpufreq-hw.c | 32 ++-- 1 file changed, 30 insertions(+), 2 deletions(-) diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c

Re: > [PATCH] Security: Handle hidepid option correctly

On Mon, Dec 17, 2018 at 12:21:40PM +0800, 程洋 wrote: > Actually I'm pretty sure kernel calls proc_mount() > Here is the call stack OK, hidepid= is still misdesigned. :-(

Re: [PATCH] ARM: Ensure that NEON code always compiles with Clang

On Sat, Dec 15, 2018 at 1:23 PM Nathan Chancellor wrote: > > While building arm32 allyesconfig, I ran into the following errors: > > arch/arm/lib/xor-neon.c:17:2: error: You should compile this file with > '-mfloat-abi=softfp -mfpu=neon' > > In file included from lib/raid6/neon1.c:27: >

[PATCH 05/12] __wr_after_init: x86_64: __wr_op

Architecture-specific implementation of the core write rare operation. The implementation is based on code from Andy Lutomirski and Nadav Amit for patching the text on x86 [here goes reference to commits, once merged] The modification of write protected data is done through an alternate mapping

[PATCH 01/12] x86_64: memset_user()

Create x86_64 specific version of memset for user space, based on clear_user(). This will be used for implementing wr_memset() in the __wr_after_init scenario, where write-rare variables have an alternate mapping for writing. Signed-off-by: Igor Stoppa CC: Andy Lutomirski CC: Nadav Amit CC:

[PATCH 03/12] __wr_after_init: generic functionality

The patch provides: - the generic part of the write rare functionality for static data, based on code from Matthew Wilcox - the dummy functionality, in case an arch doesn't support write rare or the functionality is disabled The basic functions are: - wr_memset(): write rare counterpart of

[PATCH 08/12] rodata_test: refactor tests

Refactor the test cases, in preparation for using them also for testing __wr_after_init memory, when available. Signed-off-by: Igor Stoppa CC: Andy Lutomirski CC: Nadav Amit CC: Matthew Wilcox CC: Peter Zijlstra CC: Kees Cook CC: Dave Hansen CC: Mimi Zohar CC: Thiago Jung Bauermann CC:

[PATCH v2] arm64: dts: sdm845: Add cpufreq device node

This change adds the cpufreq node as per the bindings example for SDM845. Signed-off-by: Taniya Das Tested-by: Matthias Kaehlcke --- arch/arm64/boot/dts/qcom/sdm845.dtsi | 19 +++ 1 file changed, 19 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi

[PATCH 06/12] __wr_after_init: Documentation: self-protection

Update the self-protection documentation, to mention also the use of the __wr_after_init attribute. Signed-off-by: Igor Stoppa CC: Andy Lutomirski CC: Nadav Amit CC: Matthew Wilcox CC: Peter Zijlstra CC: Kees Cook CC: Dave Hansen CC: Mimi Zohar CC: Thiago Jung Bauermann CC: Ahmed

Applied "ASoC: rockchip: support ACODEC for rk3328" to the asoc tree

The patch ASoC: rockchip: support ACODEC for rk3328 has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to

[PATCH 02/12] __wr_after_init: linker section and label

Introduce a section and a label for statically allocated write rare data. The label is named "__wr_after_init". As the name implies, after the init phase is completed, this section will be modifiable only by invoking write rare functions. The section must take up a set of full pages. To activate

[PATCH 12/12] x86_64: __clear_user as case of __memset_user

To avoid code duplication, re-use __memset_user(), when clearing user-space memory. The overhead should be minimal (2 extra register assignments) and outside of the writing loop. Signed-off-by: Igor Stoppa CC: Andy Lutomirski CC: Nadav Amit CC: Matthew Wilcox CC: Peter Zijlstra CC: Kees

[PATCH 09/12] rodata_test: add verification for __wr_after_init

The write protection of the __wr_after_init data can be verified with the same methodology used for const data. Signed-off-by: Igor Stoppa CC: Andy Lutomirski CC: Nadav Amit CC: Matthew Wilcox CC: Peter Zijlstra CC: Kees Cook CC: Dave Hansen CC: Mimi Zohar CC: Thiago Jung Bauermann CC:

Applied "ASoC: rockchip: add workaround for silence of rk3288 ACODEC" to the asoc tree

The patch ASoC: rockchip: add workaround for silence of rk3288 ACODEC has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

[PATCH 07/12] __wr_after_init: lkdtm test

Verify that trying to modify a variable with the __wr_after_init attribute will cause a crash. Signed-off-by: Igor Stoppa CC: Andy Lutomirski CC: Nadav Amit CC: Matthew Wilcox CC: Peter Zijlstra CC: Kees Cook CC: Dave Hansen CC: Mimi Zohar CC: Thiago Jung Bauermann CC: Ahmed Soliman

[PATCH 10/12] __wr_after_init: test write rare functionality

Set of test cases meant to confirm that the write rare functionality works as expected. It can be optionally compiled as module. Signed-off-by: Igor Stoppa CC: Andy Lutomirski CC: Nadav Amit CC: Matthew Wilcox CC: Peter Zijlstra CC: Kees Cook CC: Dave Hansen CC: Mimi Zohar CC: Thiago

Applied "ASoC: xlnx: add pcm formatter platform driver" to the asoc tree

The patch ASoC: xlnx: add pcm formatter platform driver has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent

[PATCH 11/12] IMA: turn ima_policy_flags into __wr_after_init

The policy flags could be targeted by an attacker aiming at disabling IMA, so that there would be no trace of a file system modification in the measurement list. Since the flags can be altered at runtime, it is not possible to make them become fully read-only, for example with __ro_after_init.

[PATCH 04/12] __wr_after_init: debug writes

After each write operation, confirm that it was successful, otherwise generate a warning. Signed-off-by: Igor Stoppa CC: Andy Lutomirski CC: Nadav Amit CC: Matthew Wilcox CC: Peter Zijlstra CC: Kees Cook CC: Dave Hansen CC: Mimi Zohar CC: Thiago Jung Bauermann CC: Ahmed Soliman CC:

Re: [PATCH] arm64: dts: sdm845: Add cpufreq device node

Hello Matthias, On 12/21/2018 1:20 AM, Matthias Kaehlcke wrote: Hi Taniya, On Fri, Dec 21, 2018 at 12:48:50AM +0530, Taniya Das wrote: This change adds the cpufreq node as per the bindings example for SDM845. Signed-off-by: Taniya Das --- arch/arm64/boot/dts/qcom/sdm845.dtsi | 19

Re: [RFC RESEND PATCH] kvm: arm64: export memory error recovery capability to user space

Hi Peter, On 19/12/2018 19:02, Peter Maydell wrote: > On Mon, 17 Dec 2018 at 15:56, James Morse wrote: >> I don't think this really matters. Its only the NMIlike notifications that >> the >> guest doesn't have to register or poll. The ones we support today extend the >> architectures existing

Re: [PATCH 1/5] dt-bindings: gpu: mali-utgard: add Amlogic Meson8 and Meson8b compatible

On Sat, 8 Dec 2018 18:12:43 +0100, Martin Blumenstingl wrote: > Add a compatible string for the Mali-450 GPU on Amlogic Meson8 and > Meson8b SoCs. Meson8 uses an "MP6" variant with six pixel processors > while Meson8b (as cost-reduced SoC) uses an "MP2" variant with two pixel > processors. Both

Re: [PATCH v2 1/2] hugetlbfs: use i_mmap_rwsem for more pmd sharing synchronization

On 12/21/18 2:05 AM, Kirill A. Shutemov wrote: > On Tue, Dec 18, 2018 at 02:35:56PM -0800, Mike Kravetz wrote: >> While looking at BUGs associated with invalid huge page map counts, >> it was discovered and observed that a huge pte pointer could become >> 'invalid' and point to another task's page

[PATCH] x86/speculation: Add document to describe Spectre and its mitigations

Thomas, Andi and I have made an update to our draft of the Spectre admin guide. We may be out on Christmas vacation for a while. But we want to send it out for everyone to take a look. Thanks. Tim From: Andi Kleen There are no document in admin guides describing Spectre v1 and v2 side

Re: [PATCH v5 1/8] dt-bindings: stmpe: reformatting parameter list and use tabs only

On Fri, 21 Dec 2018 14:46:30 +0100, Philippe Schenker wrote: > From: Philippe Schenker > > This patch reformats the parameter list for stmpe device in a > table-style so it is more clear to read. > > Signed-off-by: Philippe Schenker > Acked-for-MFD-by: Lee Jones > > --- > > Changes in v5: >

Re: [for-next][PATCH 06/24] sparc64: Use ftrace_graph_get_ret_stack() instead of curr_ret_stack

From: Steven Rostedt Date: Fri, 21 Dec 2018 12:56:24 -0500 > From: "Steven Rostedt (VMware)" > > The structure of the ret_stack array on the task struct is going to > change, and accessing it directly via the curr_ret_stack index will no > longer give the ret_stack entry that holds the return

Re: x86/sgx: uapi change proposal

On Fri, Dec 21, 2018 at 09:12:46AM -0800, Andy Lutomirski wrote: > > On Dec 21, 2018, at 9:28 AM, Sean Christopherson > > wrote: > > > > On Wed, Dec 19, 2018 at 06:58:48PM -0800, Andy Lutomirski wrote: > >>> On Dec 19, 2018, at 6:45 AM, Sean Christopherson > >>> wrote: > >>> > > On Wed,

Re: [PATCH v5 6/8] iio: adc: add STMPE ADC devicetree bindings

On Fri, 21 Dec 2018 14:46:35 +0100, Philippe Schenker wrote: > From: Stefan Agner > > This adds the devicetree bindings for the STMPE ADC. This also corrects > a typo in st,sample-time it is rather "6 -> 124 clocks" according > to the datasheet and not 144. > We need to use the naming stmpe_adc

Re: [PATCH 01/12] x86_64: memset_user()

On Fri, Dec 21, 2018 at 08:14:12PM +0200, Igor Stoppa wrote: > +unsigned long __memset_user(void __user *addr, int c, unsigned long size) > +{ > + long __d0; > + unsigned long pattern = 0; > + int i; > + > + for (i = 0; i < 8; i++) > + pattern = (pattern << 8) | (0xFF

Re: [PATCH 2/2] drm: Revert syncobj timeline changes.

Am 19.12.18 um 18:53 schrieb Dmitry Osipenko: [SNIP] @@ -931,9 +718,6 @@ static signed long drm_syncobj_array_wait_timeout(struct drm_syncobj **syncobjs, if (flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT) { for (i = 0; i < count; ++i) { - if

Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

On Wed, Dec 19, 2018 at 07:00:47AM +0200, Jarkko Sakkinen wrote: > On Tue, Dec 18, 2018 at 10:53:49AM -0800, Sean Christopherson wrote: > > What if we re-organize the ioctls in such a way that we leave open the > > possibility of allocating raw EPC for KVM via /dev/sgx? I'm not 100% > > positive

Re: [PATCH v3 2/3] dt-bindings: drm/msm/a6xx: Document interconnect properties for GPU

On Thu, 20 Dec 2018 10:30:25 -0700, Jordan Crouse wrote: > Add documentation for the interconnect and interconnect-names bindings > for the GPU node as detailed by bindings/interconnect/interconnect.txt. > > Signed-off-by: Jordan Crouse > --- > >

Re: linux-next: Tree for Dec 21 (acpi without CONFIG_PCI)

On 12/21/18 9:23 AM, Sinan Kaya wrote: > > > On Friday, December 21, 2018, Randy Dunlap > wrote: > > On 12/21/18 12:32 AM, Stephen Rothwell wrote: > > Hi all, > > > > News: there will be no linux-next release until Jan 2.  Have a good > break. >

Re: [PATCH v2 2/2] hugetlbfs: Use i_mmap_rwsem to fix page fault/truncate race

On 12/21/18 2:28 AM, Kirill A. Shutemov wrote: > On Tue, Dec 18, 2018 at 02:35:57PM -0800, Mike Kravetz wrote: >> Instead of writing the required complicated code for this rare >> occurrence, just eliminate the race. i_mmap_rwsem is now held in read >> mode for the duration of page fault

<    1   2   3   4   5   6   7   8   >