Trivial fixes to spelling mistakes in ftrace.rst
Signed-off-by: Amir Livneh
---
Documentation/trace/ftrace.rst | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/trace/ftrace.rst b/Documentation/trace/ftrace.rst
index 7ea16a0ceffc..80fde12e6564 10064
On Wed, Oct 31, 2018 at 09:37:17PM +0800, Peng Hao wrote:
> move pvpanic.c from drivers/platform/x86 to drivers/misc.
> following patches will use pvpanic device in arm64.
FWIW, the series as a whole looks fine to me, so for all patches:
Acked-by: Mark Rutland
Thanks,
Mark.
>
> Signed-off-by:
With MFD devices the clk properties may be contained in MFD (parent) DT
node. Current devm_of_clk_add_hw_provider assumes the clk is bound to MFD
subdevice not to MFD device (parent). Add
devm_of_clk_add_hw_provider_parent to tackle this issue.
Also clkdev registration lacks of managed registratio
Patch series adding managed clkdev and of_provider registrations
Few clk drivers appear to be leaking clkdev lookup registrations at
driver remove. The patch series adds devm versions of lookup
registrations and cleans up few drivers. There is no intended functional
changes besides adding clean-up
clk-max77686 never clean clkdev lookup at remove. This can cause
oops if clk-max77686 is removed and inserted again. Fix leak by
using new devm clkdev lookup registration. Simplify also error
path by using new devm_of_clk_add_parent_hw_provider.
Signed-off-by: Matti Vaittinen
---
drivers/clk/clk
Use devm variant of clkdev lookup registration in order to avoid
clkdev lookup leak at device remove.
Signed-off-by: Matti Vaittinen
---
drivers/clk/samsung/clk-s3c2410-dclk.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/clk/samsung/clk-s3c2410-dclk
Use devm based clkdev lookup registration to avoid leaking lookup
structures.
Signed-off-by: Matti Vaittinen
---
drivers/clk/x86/clk-st.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/x86/clk-st.c b/drivers/clk/x86/clk-st.c
index fb62f3938008..32d8df9bd853 100
use devm variant for of_provider registration so provider is freed
at exit.
Signed-off-by: Matti Vaittinen
---
drivers/clk/clk-hi655x.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk-hi655x.c b/drivers/clk/clk-hi655x.c
index 403a0188634a..394d0109104d 100
Simplify clean-up for rk808 by using managed version of of_provider
registration.
Signed-off-by: Matti Vaittinen
---
drivers/clk/clk-rk808.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/clk/clk-rk808.c b/drivers/clk/clk-rk808.c
index 6461f2820a5b..
use devm variant for of_provider registration so provider is freed
at exit.
Signed-off-by: Matti Vaittinen
---
drivers/clk/clk-twl6040.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/clk-twl6040.c b/drivers/clk/clk-twl6040.c
index 25dfe050ae9f..e9da09453eb2
use devm variant for of_provider registration.
Signed-off-by: Matti Vaittinen
---
drivers/clk/qcom/apcs-msm8916.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/qcom/apcs-msm8916.c b/drivers/clk/qcom/apcs-msm8916.c
index b1cc8dbcd327..f4e0c136ab1a 100644
---
Adding SELinux folks and the SELinux ml
I think it's better if they participate in this discussion.
On 31/10/2018 06:41, Andy Lutomirski wrote:
On Tue, Oct 30, 2018 at 2:36 PM Matthew Wilcox wrote:
On Tue, Oct 30, 2018 at 10:43:14PM +0200, Igor Stoppa wrote:
On 30/10/2018 21:20, Matthew Wil
On Tue, Oct 30, 2018 at 04:18:39PM -0700, Nadav Amit wrote:
> > Nadav, want to resubmit your series? IIRC the only thing wrong with it was
> > that it was a big change and we wanted a simpler fix to backport. But
> > that’s all done now, and I, at least, rather liked your code. :)
>
> I guess sinc
On Tue, Oct 30, 2018 at 11:03:51AM -0700, Dave Hansen wrote:
> On 10/30/18 10:58 AM, Matthew Wilcox wrote:
> > Does this satisfy Igor's requirements? We wouldn't be able to
> > copy_to/from_user() while rare_mm was active. I think that's a feature
> > though! It certainly satisfies my interests
On 30/10/2018 18:37, Kees Cook wrote:
On Tue, Oct 30, 2018 at 8:26 AM, Peter Zijlstra wrote:
I suppose the 'normal' attack goes like:
1) find buffer-overrun / bound check failure
2) use that to write to 'interesting' location
3) that write results arbitrary code execution
4) win
Of
On Tue, Oct 30, 2018 at 02:25:51PM -0700, Matthew Wilcox wrote:
> On Tue, Oct 30, 2018 at 11:51:17AM -0700, Andy Lutomirski wrote:
> > Finally, one issue: rare_alloc() is going to utterly suck
> > performance-wise due to the global IPI when the region gets zapped out
> > of the direct map or otherw
On Tue, Oct 30, 2018 at 10:58:14AM -0700, Matthew Wilcox wrote:
> On Tue, Oct 30, 2018 at 10:06:51AM -0700, Andy Lutomirski wrote:
> > > On Oct 30, 2018, at 9:37 AM, Kees Cook wrote:
> > I support the addition of a rare-write mechanism to the upstream kernel.
> > And I think that there is only one
On Tue, Oct 30, 2018 at 02:02:12PM -0700, Andy Lutomirski wrote:
> But I dislike allowing regular writes in the protected region. We
> really only need four write primitives:
>
> 1. Just write one value. Call at any time (except NMI).
>
> 2. Just copy some bytes. Same as (1) but any number of by
On Tue, Oct 30, 2018 at 09:41:13PM -0700, Andy Lutomirski wrote:
> To clarify some of this thread, I think that the fact that rare_write
> uses an mm_struct and alias mappings under the hood should be
> completely invisible to users of the API. No one should ever be
> handed a writable pointer to
On Wed, Oct 31, 2018 at 12:15:46AM +0200, Igor Stoppa wrote:
> On 30/10/2018 23:02, Andy Lutomirski wrote:
> > But I dislike allowing regular writes in the protected region. We
> > really only need four write primitives:
> >
> > 1. Just write one value. Call at any time (except NMI).
> >
> > 2.
On Wed, Oct 31, 2018 at 10:36:59AM +0100, Peter Zijlstra wrote:
> On Tue, Oct 30, 2018 at 10:58:14AM -0700, Matthew Wilcox wrote:
> > On Tue, Oct 30, 2018 at 10:06:51AM -0700, Andy Lutomirski wrote:
> > > > On Oct 30, 2018, at 9:37 AM, Kees Cook wrote:
> > > I support the addition of a rare-write
On Wed, Oct 31, 2018 at 7:27 AM Peng Hao wrote:
>
> move pvpanic.c from drivers/platform/x86 to drivers/misc.
> following patches will use pvpanic device in arm64.
> --- a/drivers/platform/Kconfig
> +++ b/drivers/platform/Kconfig
> @@ -1,3 +1,6 @@
> +if ARM64
> +source "drivers/platform/arm/Kconf
On Wed, Oct 31, 2018 at 7:27 AM Peng Hao wrote:
>
> This patch updates license to use SPDX-License-Identifier
> instead of verbose license text.
>
Reviewed-by: Andy Shevchenko
> Signed-off-by: Peng Hao
> ---
> drivers/misc/pvpanic.c | 17 ++---
> 1 file changed, 2 insertions(+), 1
On Wed, Oct 31, 2018 at 7:27 AM Peng Hao wrote:
>
> On some architectures (e.g. arm64), it's preferable to use MMIO, since
> this can be used standalone. Add MMIO support to the pvpanic driver.
> case ACPI_RESOURCE_TYPE_IO:
> - port = res->data.io.minimum;
> +
On Wed, Oct 31, 2018 at 7:27 AM Peng Hao wrote:
>
> By default, when ACPI tables and FDT coexist for ARM64,
> current kernel takes precedence over FDT to get device information.
> Virt machine in qemu provides both FDT and ACPI table. This patch
> increases the way to get information through FDT.
On Wed, Oct 31, 2018 at 7:27 AM Peng Hao wrote:
>
> By default, when ACPI tables and FDT coexist for ARM64,
> current kernel takes precedence over FDT to get device information.
> Virt machine in qemu provides both FDT and ACPI table. This patch
> increases the way to get information through FDT.
Hi Matti,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on clk/clk-next]
[also build test ERROR on v4.19 next-20181031]
[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
On Wed, Oct 31, 2018 at 10:30:34AM +0200, Matti Vaittinen wrote:
> With MFD devices the clk properties may be contained in MFD (parent) DT
> node. Current devm_of_clk_add_hw_provider assumes the clk is bound to MFD
> subdevice not to MFD device (parent). Add
> devm_of_clk_add_hw_provider_parent to
Hi Matti,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on clk/clk-next]
[also build test ERROR on v4.19 next-20181031]
[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
Historically, kretprobe has always produced unusable stack traces
(kretprobe_trampoline is the only entry in most cases, because of the
funky stack pointer overwriting). This has caused quite a few annoyances
when using tracing to debug problems[1] -- since return values are only
available with kre
Historically, kretprobe has always produced unusable stack traces
(kretprobe_trampoline is the only entry in most cases, because of the
funky stack pointer overwriting). This has caused quite a few annoyances
when using tracing to debug problems[1] -- since return values are only
available with kre
This is effectively a reversion of commit 76094a2cf46e ("ftrace:
distinguish kretprobe'd functions in trace logs"), as the checking of
kretprobe_trampoline *for tracing* is no longer necessary with the new
kretprobe stack trace changes.
Signed-off-by: Aleksa Sarai
---
kernel/trace/trace_output.c
On Mon, 29 Oct 2018 at 18:42, Sean Christopherson
wrote:
>
> On Fri, Oct 26, 2018 at 05:12:19PM +0200, Ahmed Abd El Mawgood wrote:
> > Following up with my previous threads on KVM assisted Anti rootkit
> > protections.
>
> All of the changelogs in this series need to be rewritten to adhere to
> Do
On 09/21/2018 06:13 PM, Andrey Konovalov wrote:
> Tag-based KASAN changes the value of the top byte of pointers returned
> from the kernel allocation functions (such as kmalloc). This patch updates
> KASAN hooks signatures and their usage in SLAB and SLUB code to reflect
> that.
>
> Signed-off-
On 31/10/2018 11:08, Igor Stoppa wrote:
Adding SELinux folks and the SELinux ml
I think it's better if they participate in this discussion.
On 31/10/2018 06:41, Andy Lutomirski wrote:
On Tue, Oct 30, 2018 at 2:36 PM Matthew Wilcox
wrote:
On Tue, Oct 30, 2018 at 10:43:14PM +0200, Igor Sto
Hi Aleksa,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on tip/perf/core]
[also build test ERROR on v4.19 next-20181031]
[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
> On Oct 31, 2018, at 3:02 AM, Peter Zijlstra wrote:
>
>> On Tue, Oct 30, 2018 at 09:41:13PM -0700, Andy Lutomirski wrote:
>> To clarify some of this thread, I think that the fact that rare_write
>> uses an mm_struct and alias mappings under the hood should be
>> completely invisible to users o
> On Oct 31, 2018, at 3:11 AM, Peter Zijlstra wrote:
>
>> On Wed, Oct 31, 2018 at 12:15:46AM +0200, Igor Stoppa wrote:
>> On 30/10/2018 23:02, Andy Lutomirski wrote:
>
>>> But I dislike allowing regular writes in the protected region. We
>>> really only need four write primitives:
>>>
>>> 1.
> On Oct 31, 2018, at 1:38 PM, Andy Lutomirski wrote:
>
>
>
>>> On Oct 31, 2018, at 3:11 AM, Peter Zijlstra wrote:
>>>
>>> On Wed, Oct 31, 2018 at 12:15:46AM +0200, Igor Stoppa wrote:
>>> On 30/10/2018 23:02, Andy Lutomirski wrote:
>>
But I dislike allowing regular writes in the prot
On Wed, Oct 31, 2018 at 01:36:48PM -0700, Andy Lutomirski wrote:
>
> > On Oct 31, 2018, at 3:02 AM, Peter Zijlstra wrote:
> >
> >> On Tue, Oct 30, 2018 at 09:41:13PM -0700, Andy Lutomirski wrote:
> >> To clarify some of this thread, I think that the fact that rare_write
> >> uses an mm_struct an
On Thu, Oct 18, 2018 at 10:52:00PM +, Moger, Babu wrote:
> Changes from v4 -> v5:
> b. The functions update_mba_bw and set_mba_sc is not required for AMD.
> Removed all the changes related to these functions.
Hi, Babu,
In v4, you says AMD won't support MBA software controller.
In v5, do
> On Oct 31, 2018, at 2:00 PM, Peter Zijlstra wrote:
>
>> On Wed, Oct 31, 2018 at 01:36:48PM -0700, Andy Lutomirski wrote:
>>
On Oct 31, 2018, at 3:02 AM, Peter Zijlstra wrote:
On Tue, Oct 30, 2018 at 09:41:13PM -0700, Andy Lutomirski wrote:
To clarify some of this threa
On Wed, Oct 31, 2018 at 4:10 PM Igor Stoppa wrote:
>
>
>
> On 01/11/2018 00:57, Andy Lutomirski wrote:
> >
> >
> >> On Oct 31, 2018, at 2:00 PM, Peter Zijlstra wrote:
>
>
>
> >> I _think_ the use-case for atomics is updating the reference counts of
> >> objects that are in this write-rare domain.
Hello Igor,
> This is very interesting, because it seems a very good match to the work
> I'm doing, for supporting the creation of more targets for protection:
>
> https://www.openwall.com/lists/kernel-hardening/2018/10/23/3
>
> In my case the protection would extend also to write-rate type of data
On 01/11/2018 00:57, Andy Lutomirski wrote:
On Oct 31, 2018, at 2:00 PM, Peter Zijlstra wrote:
I _think_ the use-case for atomics is updating the reference counts of
objects that are in this write-rare domain. But I'm not entirely clear
on that myself either. I just really want to avo
On 01/11/2018 01:19, Andy Lutomirski wrote:
ISTM you don't need that atomic operation -- you could take a spinlock
and then just add one directly to the variable.
It was my intention to provide a 1:1 conversion of existing code, as it
should be easier to verify the correctness of the conve
Fix a typo in the admin-guide documentation for cpufreq.
Signed-off-by: Zhao Wei Liew
---
Documentation/admin-guide/pm/cpufreq.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/pm/cpufreq.rst
b/Documentation/admin-guide/pm/cpufreq.rst
index 47153e
On Tue, Oct 23, 2018 at 6:31 PM Derek Basehore wrote:
>
> clk_calc_subtree was called at every step up the clk tree in
> clk_calc_new_rates. Since it recursively calls itself for its
> children, this means it would be called once on each clk for each
> step above the top clk is.
>
> This fixes thi
48 matches
Mail list logo
