On Sat, Nov 10, 2018 at 11:28:06PM +, Colin King wrote:
> From: Colin Ian King
>
> Currently the for_each_node_with_property loop us incrementing variable
> ngroups however it was not initialized and hence will contain garbage.
> Fix this by initializing ngroups to zero.
>
> Detected with
On Sat, Nov 10, 2018 at 11:28:06PM +, Colin King wrote:
> From: Colin Ian King
>
> Currently the for_each_node_with_property loop us incrementing variable
> ngroups however it was not initialized and hence will contain garbage.
> Fix this by initializing ngroups to zero.
>
> Detected with
ftrace_ops_test() passed local varible parameter to hash_contains_ip(),
which could result KASAN stack-out-of-bounds warning.
Signed-off-by: Zhizhou Zhang
---
kernel/trace/ftrace.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index
ftrace_ops_test() passed local varible parameter to hash_contains_ip(),
which could result KASAN stack-out-of-bounds warning.
Signed-off-by: Zhizhou Zhang
---
kernel/trace/ftrace.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index
[adding in glibc folk for comment]
On 11/10/18 7:52 PM, Daniel Colascione wrote:
> Now that glibc is basically not adding any new system call wrappers,
> how about publishing an "official" system call glue library as part of
> the kernel distribution, along with the uapi headers? I don't think
>
[adding in glibc folk for comment]
On 11/10/18 7:52 PM, Daniel Colascione wrote:
> Now that glibc is basically not adding any new system call wrappers,
> how about publishing an "official" system call glue library as part of
> the kernel distribution, along with the uapi headers? I don't think
>
On Sat 10 Nov 17:34 PST 2018, Brian Masney wrote:
> When attempting to setup up a gpio hog, device probing will repeatedly
> fail with -EPROBE_DEFERED errors. It is caused by a circular dependency
> between the gpio and pinctrl frameworks. If the gpio-ranges property is
> present in device tree,
On Sat 10 Nov 17:34 PST 2018, Brian Masney wrote:
> When attempting to setup up a gpio hog, device probing will repeatedly
> fail with -EPROBE_DEFERED errors. It is caused by a circular dependency
> between the gpio and pinctrl frameworks. If the gpio-ranges property is
> present in device tree,
This patch-set addresses some issues that might affect the security and
the correctness of code patching.
The main issue that the patches deal with is the fact that the fixmap
PTEs that are used for patching are available for access from other
cores and might be exploited. They are not even
text_mutex is currently expected to be held before text_poke() is
called, but we kgdb does not take the mutex, and instead *supposedly*
ensures the lock is not taken and will not be acquired by any other core
while text_poke() is running.
The reason for the "supposedly" comment is that it is not
This patch-set addresses some issues that might affect the security and
the correctness of code patching.
The main issue that the patches deal with is the fact that the fixmap
PTEs that are used for patching are available for access from other
cores and might be exploited. They are not even
text_mutex is currently expected to be held before text_poke() is
called, but we kgdb does not take the mutex, and instead *supposedly*
ensures the lock is not taken and will not be acquired by any other core
while text_poke() is running.
The reason for the "supposedly" comment is that it is not
There is no apparent reason not to use text_poke_early() while we are
during early-init and we do not patch code that might be on the stack
(i.e., we'll return to the middle of the patched code). This appears to
be the case of jump-labels, so do so.
This is required for the next patches that
Provide a function for copying init_mm. This function will be later used
for setting a temporary mm.
Cc: Andy Lutomirski
Cc: Kees Cook
Cc: Peter Zijlstra
Cc: Dave Hansen
Reviewed-by: Masami Hiramatsu
Tested-by: Masami Hiramatsu
Signed-off-by: Nadav Amit
---
include/linux/sched/task.h | 1
There is no apparent reason not to use text_poke_early() while we are
during early-init and we do not patch code that might be on the stack
(i.e., we'll return to the middle of the patched code). This appears to
be the case of jump-labels, so do so.
This is required for the next patches that
Provide a function for copying init_mm. This function will be later used
for setting a temporary mm.
Cc: Andy Lutomirski
Cc: Kees Cook
Cc: Peter Zijlstra
Cc: Dave Hansen
Reviewed-by: Masami Hiramatsu
Tested-by: Masami Hiramatsu
Signed-off-by: Nadav Amit
---
include/linux/sched/task.h | 1
To prevent improper use of the PTEs that are used for text patching, we
want to use a temporary mm struct. We initailize it by copying the init
mm.
The address that will be used for patching is taken from the lower area
that is usually used for the task memory. Doing so prevents the need to
text_poke() already ensures that the written value is the correct one
and fails if that is not the case. There is no need for an additional
comparison. Remove it.
Signed-off-by: Nadav Amit
---
arch/x86/kernel/kgdb.c | 10 --
1 file changed, 10 deletions(-)
diff --git
From: Andy Lutomirski
Sometimes we want to set a temporary page-table entries (PTEs) in one of
the cores, without allowing other cores to use - even speculatively -
these mappings. There are two benefits for doing so:
(1) Security: if sensitive PTEs are set, temporary mm prevents their use
in
text_poke() already ensures that the written value is the correct one
and fails if that is not the case. There is no need for an additional
comparison. Remove it.
Signed-off-by: Nadav Amit
---
arch/x86/kernel/kgdb.c | 10 --
1 file changed, 10 deletions(-)
diff --git
From: Andy Lutomirski
Sometimes we want to set a temporary page-table entries (PTEs) in one of
the cores, without allowing other cores to use - even speculatively -
these mappings. There are two benefits for doing so:
(1) Security: if sensitive PTEs are set, temporary mm prevents their use
in
To prevent improper use of the PTEs that are used for text patching, we
want to use a temporary mm struct. We initailize it by copying the init
mm.
The address that will be used for patching is taken from the lower area
that is usually used for the task memory. Doing so prevents the need to
When modules and BPF filters are loaded, there is a time window in
which some memory is both writable and executable. An attacker that has
already found another vulnerability (e.g., a dangling pointer) might be
able to exploit this behavior to overwrite kernel code. This patch
prevents having
text_poke() can potentially compromise the security as it sets temporary
PTEs in the fixmap. These PTEs might be used to rewrite the kernel code
from other cores accidentally or maliciously, if an attacker gains the
ability to write onto kernel memory.
Moreover, since remote TLBs are not flushed
The return value of text_poke_early() and text_poke_bp() is useless.
Remove it.
Cc: Andy Lutomirski
Cc: Kees Cook
Cc: Peter Zijlstra
Cc: Dave Hansen
Cc: Masami Hiramatsu
Signed-off-by: Nadav Amit
---
arch/x86/include/asm/text-patching.h | 4 ++--
arch/x86/kernel/alternative.c| 11
There are only two types of poking: early and breakpoint based. The use
of a function pointer to perform poking complicates the code and is
probably inefficient due to the use of indirect branches.
Cc: Andy Lutomirski
Cc: Kees Cook
Cc: Peter Zijlstra
Cc: Dave Hansen
Cc: Masami Hiramatsu
When modules and BPF filters are loaded, there is a time window in
which some memory is both writable and executable. An attacker that has
already found another vulnerability (e.g., a dangling pointer) might be
able to exploit this behavior to overwrite kernel code. This patch
prevents having
text_poke() can potentially compromise the security as it sets temporary
PTEs in the fixmap. These PTEs might be used to rewrite the kernel code
from other cores accidentally or maliciously, if an attacker gains the
ability to write onto kernel memory.
Moreover, since remote TLBs are not flushed
The return value of text_poke_early() and text_poke_bp() is useless.
Remove it.
Cc: Andy Lutomirski
Cc: Kees Cook
Cc: Peter Zijlstra
Cc: Dave Hansen
Cc: Masami Hiramatsu
Signed-off-by: Nadav Amit
---
arch/x86/include/asm/text-patching.h | 4 ++--
arch/x86/kernel/alternative.c| 11
There are only two types of poking: early and breakpoint based. The use
of a function pointer to perform poking complicates the code and is
probably inefficient due to the use of indirect branches.
Cc: Andy Lutomirski
Cc: Kees Cook
Cc: Peter Zijlstra
Cc: Dave Hansen
Cc: Masami Hiramatsu
On Sun, Nov 11, 2018 at 12:09:03AM +, Ben Hutchings wrote:
> On Sat, 2018-06-16 at 22:18 +0100, Ben Hutchings wrote:
> > On Fri, 2018-06-08 at 07:14 -0700, Guenter Roeck wrote:
> > > On Thu, Jun 07, 2018 at 03:05:20PM +0100, Ben Hutchings wrote:
> > > > This is the start of the stable review
On Sun, Nov 11, 2018 at 12:09:03AM +, Ben Hutchings wrote:
> On Sat, 2018-06-16 at 22:18 +0100, Ben Hutchings wrote:
> > On Fri, 2018-06-08 at 07:14 -0700, Guenter Roeck wrote:
> > > On Thu, Jun 07, 2018 at 03:05:20PM +0100, Ben Hutchings wrote:
> > > > This is the start of the stable review
Use the gpiod interface instead of the deprecated old non-descriptor
interface.
Signed-off-by: Nishad Kamdar
---
drivers/staging/greybus/arche-apb-ctrl.c | 158 ++-
1 file changed, 65 insertions(+), 93 deletions(-)
diff --git a/drivers/staging/greybus/arche-apb-ctrl.c
Use the gpiod interface instead of the deprecated old non-descriptor
interface.
Signed-off-by: Nishad Kamdar
---
drivers/staging/greybus/arche-apb-ctrl.c | 158 ++-
1 file changed, 65 insertions(+), 93 deletions(-)
diff --git a/drivers/staging/greybus/arche-apb-ctrl.c
The perf sample data contains flags to indicate the hardware trace data
is belonging to which type branch instruction, thus this can be used to
print out the human readable string. Arm CoreSight ETM sample data is
missed to set flags and it is always set to zeros, this results in perf
tool skips
This patch seris adds support for sample flags so can facilitate perf
to print sample flags for branch instruction.
The patch 0001 is to set branch instruction flags in packet, this
patch has the core code in this series to set flags according to the
decoding element type, and also based on the
We have prepared the flags in the packet structure, so need to copy
the related value into sample structure thus perf tool can facilitate
sample flags.
The PREV_PACKET contains the branch instruction flags and PACKET
actually contains the flags for next branch instruction. So this patch
is to
The perf sample data contains flags to indicate the hardware trace data
is belonging to which type branch instruction, thus this can be used to
print out the human readable string. Arm CoreSight ETM sample data is
missed to set flags and it is always set to zeros, this results in perf
tool skips
This patch seris adds support for sample flags so can facilitate perf
to print sample flags for branch instruction.
The patch 0001 is to set branch instruction flags in packet, this
patch has the core code in this series to set flags according to the
decoding element type, and also based on the
We have prepared the flags in the packet structure, so need to copy
the related value into sample structure thus perf tool can facilitate
sample flags.
The PREV_PACKET contains the branch instruction flags and PACKET
actually contains the flags for next branch instruction. So this patch
is to
At the end of trace buffer handling, function cs_etm__flush() is invoked
to flush any remaining branch stack entries. As a side effect, it also
generates branch sample, because the 'etmq->packet' doesn't contains any
new coming packet but point to one stale packet after packets swapping,
so it
At the end of trace buffer handling, function cs_etm__flush() is invoked
to flush any remaining branch stack entries. As a side effect, it also
generates branch sample, because the 'etmq->packet' doesn't contains any
new coming packet but point to one stale packet after packets swapping,
so it
When an exception packet comes, it contains the info for exception
number; the exception number indicates the exception types, so from it
we can know if the exception is taken for interrupt, system call or
other traps, etc. But because the exception return packet cannot
delivery exception number
When an exception packet comes, it contains the info for exception
number; the exception number indicates the exception types, so from it
we can know if the exception is taken for interrupt, system call or
other traps, etc. But because the exception return packet cannot
delivery exception number
The exception packet appears as one element with 'elem_type' ==
OCSD_GEN_TRC_ELEM_EXCEPTION or OCSD_GEN_TRC_ELEM_EXCEPTION_RET,
which present for exception entry and exit respectively. The decoder
set packet fields 'packet->exc' and 'packet->exc_ret' to indicate the
exception packets; but
The structure cs_etm_queue uses 'prev_packet' to point to previous
packet, this can be used to combine with new coming packet to generate
samples.
In function cs_etm__flush() it swaps packets only when the flag
'etm->synth_opts.last_branch' is true, this means that it will not
swap packets if
As described in OpenCSD (CoreSight decoder lib), in the decoding stream
it includes one trace element with type OCSD_GEN_TRC_ELEM_NO_SYNC; the
element indicates 'either at start of decode, or after overflow / bad
packet', we should take it as a signal for the tracing off and this will
cause
perf cs-etm module converts decoder elements to packets and then we have
more context crossing packets to generate synthenize samples, finally
perf tool can faciliate samples for statistics and report the results.
This patch series is to address several issues found related with
packets handling
The exception packet appears as one element with 'elem_type' ==
OCSD_GEN_TRC_ELEM_EXCEPTION or OCSD_GEN_TRC_ELEM_EXCEPTION_RET,
which present for exception entry and exit respectively. The decoder
set packet fields 'packet->exc' and 'packet->exc_ret' to indicate the
exception packets; but
The structure cs_etm_queue uses 'prev_packet' to point to previous
packet, this can be used to combine with new coming packet to generate
samples.
In function cs_etm__flush() it swaps packets only when the flag
'etm->synth_opts.last_branch' is true, this means that it will not
swap packets if
As described in OpenCSD (CoreSight decoder lib), in the decoding stream
it includes one trace element with type OCSD_GEN_TRC_ELEM_NO_SYNC; the
element indicates 'either at start of decode, or after overflow / bad
packet', we should take it as a signal for the tracing off and this will
cause
perf cs-etm module converts decoder elements to packets and then we have
more context crossing packets to generate synthenize samples, finally
perf tool can faciliate samples for statistics and report the results.
This patch series is to address several issues found related with
packets handling
On Fri, Nov 9, 2018 at 4:45 AM Anders Roxell wrote:
>
> In today's merge_config.sh the order of the config fragment files dictates
> the output of a config option. With this approach we will get different
> .config files depending on the order of the config fragment files.
>
> So doing something
On Fri, Nov 9, 2018 at 4:45 AM Anders Roxell wrote:
>
> In today's merge_config.sh the order of the config fragment files dictates
> the output of a config option. With this approach we will get different
> .config files depending on the order of the config fragment files.
>
> So doing something
It was broken somewhere between b00d209241ff and 3541833fd1f2.
[0.00] cannot allocate crashkernel (size:0x2000)
Where a good one looks like this,
[0.00] crashkernel reserved: 0x0860 - 0x2860
(512 MB)
Some commits look more suspicious than others.
It was broken somewhere between b00d209241ff and 3541833fd1f2.
[0.00] cannot allocate crashkernel (size:0x2000)
Where a good one looks like this,
[0.00] crashkernel reserved: 0x0860 - 0x2860
(512 MB)
Some commits look more suspicious than others.
save_trace() which is called from walk_stackframe() always try to
read/write caller's stack. This results KASAN stack-out-of-bounds
warning. So mute it.
Signed-off-by: Zhizhou Zhang
---
arch/arm64/kernel/stacktrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
save_trace() which is called from walk_stackframe() always try to
read/write caller's stack. This results KASAN stack-out-of-bounds
warning. So mute it.
Signed-off-by: Zhizhou Zhang
---
arch/arm64/kernel/stacktrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Sat, Nov 10, 2018 at 07:09:25PM -0800, Joel Fernandes wrote:
> On Sat, Nov 10, 2018 at 03:04:36PM -0800, Paul E. McKenney wrote:
> > On Sat, Nov 10, 2018 at 01:46:59PM -0800, Joel Fernandes wrote:
> > > Hi Paul and everyone,
> > >
> > > I was tracing/studying the RCU code today in paul/dev
On Sat, Nov 10, 2018 at 07:09:25PM -0800, Joel Fernandes wrote:
> On Sat, Nov 10, 2018 at 03:04:36PM -0800, Paul E. McKenney wrote:
> > On Sat, Nov 10, 2018 at 01:46:59PM -0800, Joel Fernandes wrote:
> > > Hi Paul and everyone,
> > >
> > > I was tracing/studying the RCU code today in paul/dev
I have a deal for you, in your region.
I have a deal for you, in your region.
> From: gre...@linuxfoundation.org
> Sent: Thursday, November 1, 2018 21:54
> To: Dexuan Cui
> Cc: Michael Kelley ; KY Srinivasan
> ; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> jasow...@redhat.com; Stephen Hemminger ;
> vkuznets ; Sasha
> From: gre...@linuxfoundation.org
> Sent: Thursday, November 1, 2018 21:54
> To: Dexuan Cui
> Cc: Michael Kelley ; KY Srinivasan
> ; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com;
> jasow...@redhat.com; Stephen Hemminger ;
> vkuznets ; Sasha
I have a deal for you, in your region.
I have a deal for you, in your region.
On Sat, Nov 10, 2018 at 07:40:10PM -0800, Andy Lutomirski wrote:
>
>
> > On Nov 10, 2018, at 6:38 PM, Joel Fernandes wrote:
> >
> >> On Sat, Nov 10, 2018 at 02:18:23PM -0800, Andy Lutomirski wrote:
> >>
> On Nov 10, 2018, at 2:09 PM, Joel Fernandes
> wrote:
>
> > On Sat,
On Sat, Nov 10, 2018 at 07:40:10PM -0800, Andy Lutomirski wrote:
>
>
> > On Nov 10, 2018, at 6:38 PM, Joel Fernandes wrote:
> >
> >> On Sat, Nov 10, 2018 at 02:18:23PM -0800, Andy Lutomirski wrote:
> >>
> On Nov 10, 2018, at 2:09 PM, Joel Fernandes
> wrote:
>
> > On Sat,
> On Nov 10, 2018, at 6:38 PM, Joel Fernandes wrote:
>
>> On Sat, Nov 10, 2018 at 02:18:23PM -0800, Andy Lutomirski wrote:
>>
On Nov 10, 2018, at 2:09 PM, Joel Fernandes wrote:
> On Sat, Nov 10, 2018 at 11:11:27AM -0800, Daniel Colascione wrote:
>> On Sat, Nov 10, 2018 at
> On Nov 10, 2018, at 6:38 PM, Joel Fernandes wrote:
>
>> On Sat, Nov 10, 2018 at 02:18:23PM -0800, Andy Lutomirski wrote:
>>
On Nov 10, 2018, at 2:09 PM, Joel Fernandes wrote:
> On Sat, Nov 10, 2018 at 11:11:27AM -0800, Daniel Colascione wrote:
>> On Sat, Nov 10, 2018 at
On Tue, Oct 16, 2018 at 05:00:03PM -0700, Joel Fernandes (Google) wrote:
> From: Pierre Yves MORDRET
>
> commit e57cb3b3f10d005410f09d4598cc6d62b833f2b0 upstream.
>
> When in cyclic mode, the configuration is updated after having started the
> DMA hardware (STM32_DMA_SCR_EN) leading to
On Tue, Oct 16, 2018 at 05:00:03PM -0700, Joel Fernandes (Google) wrote:
> From: Pierre Yves MORDRET
>
> commit e57cb3b3f10d005410f09d4598cc6d62b833f2b0 upstream.
>
> When in cyclic mode, the configuration is updated after having started the
> DMA hardware (STM32_DMA_SCR_EN) leading to
On Sat, Nov 10, 2018 at 03:04:36PM -0800, Paul E. McKenney wrote:
> On Sat, Nov 10, 2018 at 01:46:59PM -0800, Joel Fernandes wrote:
> > Hi Paul and everyone,
> >
> > I was tracing/studying the RCU code today in paul/dev branch and noticed
> > that
> > for dyntick-idle CPUs, the RCU GP thread is
On Sat, Nov 10, 2018 at 03:04:36PM -0800, Paul E. McKenney wrote:
> On Sat, Nov 10, 2018 at 01:46:59PM -0800, Joel Fernandes wrote:
> > Hi Paul and everyone,
> >
> > I was tracing/studying the RCU code today in paul/dev branch and noticed
> > that
> > for dyntick-idle CPUs, the RCU GP thread is
Hi Rakesh,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: e255aee5b66ce4af025e6f77122114c01303b861
commit: 6bae5ea9498926440ffc883f3dbceb0adc65e492 ASoC: hdac_hda: add asoc
extension for legacy HDA codec drivers
Hi Rakesh,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: e255aee5b66ce4af025e6f77122114c01303b861
commit: 6bae5ea9498926440ffc883f3dbceb0adc65e492 ASoC: hdac_hda: add asoc
extension for legacy HDA codec drivers
On Sat, Nov 10, 2018 at 8:07 PM Andi Kleen wrote:
>
> On Sat, Nov 10, 2018 at 04:42:48PM -0500, Travis Downs wrote:
> > I guess this problem doesn't occur for LBR unwinding since the LBR
> > records are captured at the same
> > moment in time as the PEBS record, so reflect the correct branch
> >
On Sat, Nov 10, 2018 at 8:07 PM Andi Kleen wrote:
>
> On Sat, Nov 10, 2018 at 04:42:48PM -0500, Travis Downs wrote:
> > I guess this problem doesn't occur for LBR unwinding since the LBR
> > records are captured at the same
> > moment in time as the PEBS record, so reflect the correct branch
> >
On Sat, Nov 10, 2018, at 4:49 PM, Alexey Dobriyan wrote:
> On Sat, Nov 10, 2018 at 03:56:03PM -0200, Rafael David Tinoco wrote:
> > On Sat, Nov 10, 2018, at 3:47 PM, Alexey Dobriyan wrote:
> > > On Fri, Nov 09, 2018 at 09:30:36AM -0200, Rafael David Tinoco wrote:
> > > > Merge proc-self-map-files
On Sat, Nov 10, 2018, at 4:49 PM, Alexey Dobriyan wrote:
> On Sat, Nov 10, 2018 at 03:56:03PM -0200, Rafael David Tinoco wrote:
> > On Sat, Nov 10, 2018, at 3:47 PM, Alexey Dobriyan wrote:
> > > On Fri, Nov 09, 2018 at 09:30:36AM -0200, Rafael David Tinoco wrote:
> > > > Merge proc-self-map-files
Including Shuah and kselftest list...
On Sat, Nov 10, 2018, at 4:49 PM, Alexey Dobriyan wrote:
> https://bugs.linaro.org/show_bug.cgi?id=3782
>
> Turns out arm doesn't allow to map address 0, so try minimum virtual
> address instead.
>
> Reported-by: Rafael David Tinoco
> Signed-off-by: Alexey
Including Shuah and kselftest list...
On Sat, Nov 10, 2018, at 4:49 PM, Alexey Dobriyan wrote:
> https://bugs.linaro.org/show_bug.cgi?id=3782
>
> Turns out arm doesn't allow to map address 0, so try minimum virtual
> address instead.
>
> Reported-by: Rafael David Tinoco
> Signed-off-by: Alexey
Hi,
On Sun, Nov 11, 2018 at 12:20:34AM +0100, Andreas Kemnade wrote:
> This is a first try to be able to use h4 devices specified in
> the devicetree, so you do not need to call hciattach and
> it can be automatically probed.
>
> Of course, proper devicetree bindings documentation is
> missing.
Hi,
On Sun, Nov 11, 2018 at 12:20:34AM +0100, Andreas Kemnade wrote:
> This is a first try to be able to use h4 devices specified in
> the devicetree, so you do not need to call hciattach and
> it can be automatically probed.
>
> Of course, proper devicetree bindings documentation is
> missing.
On Sat, Nov 10, 2018 at 02:18:23PM -0800, Andy Lutomirski wrote:
>
> > On Nov 10, 2018, at 2:09 PM, Joel Fernandes wrote:
> >
> >> On Sat, Nov 10, 2018 at 11:11:27AM -0800, Daniel Colascione wrote:
> >>> On Sat, Nov 10, 2018 at 10:45 AM, Daniel Colascione
> >>> wrote:
> On Sat, Nov 10,
On Sat, Nov 10, 2018 at 02:18:23PM -0800, Andy Lutomirski wrote:
>
> > On Nov 10, 2018, at 2:09 PM, Joel Fernandes wrote:
> >
> >> On Sat, Nov 10, 2018 at 11:11:27AM -0800, Daniel Colascione wrote:
> >>> On Sat, Nov 10, 2018 at 10:45 AM, Daniel Colascione
> >>> wrote:
> On Sat, Nov 10,
Dear friend,
I am Abel Brent, a NATO soldier serving in Afghanistan. I and my
Comrades, we are seeking your assistance to help us
receive/invest our funds in your country in any lucrative
business. Please if this proposal is acceptable by you, kindly
respond back to me for more details.
Dear friend,
I am Abel Brent, a NATO soldier serving in Afghanistan. I and my
Comrades, we are seeking your assistance to help us
receive/invest our funds in your country in any lucrative
business. Please if this proposal is acceptable by you, kindly
respond back to me for more details.
Hello Vinod,
On 11/9/2018 3:20 PM, Vinod Koul wrote:
Device tree node name are not supposed to have "_" in them so fix the
node name use of xo_board to xo-board
Fixes: 652f1813c113 ("clk: qcom: gcc: Add global clock controller driver for
QCS404")
Signed-off-by: Vinod Koul
---
Steve: RobH
Hello Vinod,
On 11/9/2018 3:20 PM, Vinod Koul wrote:
Device tree node name are not supposed to have "_" in them so fix the
node name use of xo_board to xo-board
Fixes: 652f1813c113 ("clk: qcom: gcc: Add global clock controller driver for
QCS404")
Signed-off-by: Vinod Koul
---
Steve: RobH
Hello,
syzbot found the following crash on:
HEAD commit:442b8cea2477 Add linux-next specific files for 20181109
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=169a6fbd40
kernel config: https://syzkaller.appspot.com/x/.config?x=2f72bdb11df9fbe8
Hello,
syzbot found the following crash on:
HEAD commit:442b8cea2477 Add linux-next specific files for 20181109
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=169a6fbd40
kernel config: https://syzkaller.appspot.com/x/.config?x=2f72bdb11df9fbe8
On Sat, 2018-01-13 at 19:51 +0100, Manfred Spraul wrote:
> Hi Arnd,
>
> On 01/03/2018 12:15 AM, Arnd Bergmann wrote:
> > > 2 ipc/sem.c:377:6: warning: '___p1' may be used uninitialized in this
> > > function [-Wmaybe-uninitialized]
> > This code was last touched in 3.16 by the backport of commit
On Sat, 2018-01-13 at 19:51 +0100, Manfred Spraul wrote:
> Hi Arnd,
>
> On 01/03/2018 12:15 AM, Arnd Bergmann wrote:
> > > 2 ipc/sem.c:377:6: warning: '___p1' may be used uninitialized in this
> > > function [-Wmaybe-uninitialized]
> > This code was last touched in 3.16 by the backport of commit
When attempting to setup up a gpio hog, device probing will repeatedly
fail with -EPROBE_DEFERED errors. It is caused by a circular dependency
between the gpio and pinctrl frameworks. If the gpio-ranges property is
present in device tree, then the gpio framework will handle the gpio pin
When attempting to setup up a gpio hog, device probing will repeatedly
fail with -EPROBE_DEFERED errors. It is caused by a circular dependency
between the gpio and pinctrl frameworks. If the gpio-ranges property is
present in device tree, then the gpio framework will handle the gpio pin
On Sat, Nov 10, 2018 at 07:30:54PM -0500, Waiman Long wrote:
> On 11/10/2018 09:20 AM, Peter Zijlstra wrote:
> > On Thu, Nov 08, 2018 at 03:34:23PM -0500, Waiman Long wrote:
> >> There are use cases where we want to allow 2-level nesting of one
> >> terminal lock underneath another one. So the
On Sat, Nov 10, 2018 at 07:30:54PM -0500, Waiman Long wrote:
> On 11/10/2018 09:20 AM, Peter Zijlstra wrote:
> > On Thu, Nov 08, 2018 at 03:34:23PM -0500, Waiman Long wrote:
> >> There are use cases where we want to allow 2-level nesting of one
> >> terminal lock underneath another one. So the
On Mon, 2018-03-05 at 20:43 +, Tomasz Kramkowski wrote:
> In September last year, Ben Hutchings submitted commit [9547837bdccb]
> for 3.16.48-rc1 and I informed him that it would be useless without
> [3f3752705dbd] (and that maybe [c3883fe06488] would be useful as well).
> Ben dropped the
On Mon, 2018-03-05 at 20:43 +, Tomasz Kramkowski wrote:
> In September last year, Ben Hutchings submitted commit [9547837bdccb]
> for 3.16.48-rc1 and I informed him that it would be useless without
> [3f3752705dbd] (and that maybe [c3883fe06488] would be useful as well).
> Ben dropped the
1 - 100 of 458 matches
Mail list logo
