at 11:58 AM, Andy Lutomirski wrote:
> On Mon, Aug 27, 2018 at 11:54 AM, Nadav Amit wrote:
>>> On Mon, Aug 27, 2018 at 10:34 AM, Nadav Amit wrote:
>>> What do you all think?
>>
>> I agree in general. But I think that current->mm would need to be loaded, as
>> otherwise I am afraid it would
On Sun, Aug 26, 2018 at 3:51 PM Linus Torvalds
wrote:
>
> So two weeks have passed, and the merge window for 4.19 is over.
>
> Anyway, go forth and test,
>
I am seeing the errors use-after-free errors in mei_cl_write. dmesg as follows.
Adding Tomas Winkler to the thread.
[ 12.602912] PM:
On Fri 24-08-18 11:08:24, Mike Kravetz wrote:
[...]
> From: Mike Kravetz
> Date: Fri, 24 Aug 2018 10:58:20 -0700
> Subject: [PATCH v7 1/2] mm: migration: fix migration of huge PMD shared pages
>
> The page migration code employs try_to_unmap() to try and unmap the
> source page. This is
On Fri 24-08-18 11:08:24, Mike Kravetz wrote:
[...]
> From: Mike Kravetz
> Date: Fri, 24 Aug 2018 10:58:20 -0700
> Subject: [PATCH v7 1/2] mm: migration: fix migration of huge PMD shared pages
>
> The page migration code employs try_to_unmap() to try and unmap the
> source page. This is
Quoting yixin zhu (2018-08-08 01:52:20)
> On 8/8/2018 1:50 PM, Stephen Boyd wrote:
> > Quoting Songjun Wu (2018-08-02 20:02:21)
> >> + struct clk *clk;
> >> + int idx;
> >> +
> >> + for (idx = 0; idx < nr_clks; idx++, osc++) {
> >> + if (!osc->dt_freq ||
> >> +
Quoting yixin zhu (2018-08-08 01:52:20)
> On 8/8/2018 1:50 PM, Stephen Boyd wrote:
> > Quoting Songjun Wu (2018-08-02 20:02:21)
> >> + struct clk *clk;
> >> + int idx;
> >> +
> >> + for (idx = 0; idx < nr_clks; idx++, osc++) {
> >> + if (!osc->dt_freq ||
> >> +
On Mon 27-08-18 09:46:33, Jerome Glisse wrote:
> On Mon, Aug 27, 2018 at 09:46:45AM +0200, Michal Hocko wrote:
> > On Fri 24-08-18 11:08:24, Mike Kravetz wrote:
> > > On 08/24/2018 01:41 AM, Michal Hocko wrote:
> > > > On Thu 23-08-18 13:59:16, Mike Kravetz wrote:
> > > >
> > > > Acked-by: Michal
On Mon 27-08-18 09:46:33, Jerome Glisse wrote:
> On Mon, Aug 27, 2018 at 09:46:45AM +0200, Michal Hocko wrote:
> > On Fri 24-08-18 11:08:24, Mike Kravetz wrote:
> > > On 08/24/2018 01:41 AM, Michal Hocko wrote:
> > > > On Thu 23-08-18 13:59:16, Mike Kravetz wrote:
> > > >
> > > > Acked-by: Michal
On Mon, Aug 27, 2018 at 11:56 AM, Jann Horn wrote:
> This is preparation for looking at trap number and fault address in the
> handlers for uaccess errors.
> This patch should not change any behavior.
Confused. $SUBJECT says you're plumbing the error code through, and
you are sort of doing it:
On Mon, Aug 27, 2018 at 11:56 AM, Jann Horn wrote:
> This is preparation for looking at trap number and fault address in the
> handlers for uaccess errors.
> This patch should not change any behavior.
Confused. $SUBJECT says you're plumbing the error code through, and
you are sort of doing it:
Hi,
On 27-08-18 20:47, Suman Tripathi wrote:
Due to hardware errata, Ampere Computing eMAG SATA can't support
AHCI ALPM feature. This patch disables the AHCI ALPM feature for
eMAG SATA.
Signed-off-by: Suman Tripathi
Signed-off-by: Rameshwar Prasad Sahu
Thank you for the patch. 2 remarks:
Hi,
On 27-08-18 20:47, Suman Tripathi wrote:
Due to hardware errata, Ampere Computing eMAG SATA can't support
AHCI ALPM feature. This patch disables the AHCI ALPM feature for
eMAG SATA.
Signed-off-by: Suman Tripathi
Signed-off-by: Rameshwar Prasad Sahu
Thank you for the patch. 2 remarks:
On Mon, Aug 27, 2018 at 11:56 AM, Jann Horn wrote:
> This removes the call into exception fixup that was added in
> commit c28f896634f2 ("[PATCH] kprobes: fix broken fault handling for
> x86_64").
>
> On X86, kprobe_fault_handler() is called from two places:
> do_general_protection() (for #GP)
On Mon, Aug 27, 2018 at 11:56 AM, Jann Horn wrote:
> This removes the call into exception fixup that was added in
> commit c28f896634f2 ("[PATCH] kprobes: fix broken fault handling for
> x86_64").
>
> On X86, kprobe_fault_handler() is called from two places:
> do_general_protection() (for #GP)
Add VMA callbacks for ptrace() that can be used with debug enclaves.
With debug enclaves data can be read and write the memory word at a time
by using ENCLS(EDBGRD) and ENCLS(EDBGWR) leaf instructions.
Signed-off-by: Jarkko Sakkinen
---
drivers/platform/x86/intel_sgx/sgx_vma.c | 109
Add VMA callbacks for ptrace() that can be used with debug enclaves.
With debug enclaves data can be read and write the memory word at a time
by using ENCLS(EDBGRD) and ENCLS(EDBGWR) leaf instructions.
Signed-off-by: Jarkko Sakkinen
---
drivers/platform/x86/intel_sgx/sgx_vma.c | 109
Documentation of the features of the Software Guard eXtensions used
by the Linux kernel and basic design choices for the core and driver
and functionality.
Signed-off-by: Jarkko Sakkinen
---
Documentation/index.rst | 1 +
Documentation/x86/intel_sgx.rst | 185
Documentation of the features of the Software Guard eXtensions used
by the Linux kernel and basic design choices for the core and driver
and functionality.
Signed-off-by: Jarkko Sakkinen
---
Documentation/index.rst | 1 +
Documentation/x86/intel_sgx.rst | 185
On Mon, Aug 27, 2018 at 11:54 AM, Nadav Amit wrote:
>> On Mon, Aug 27, 2018 at 10:34 AM, Nadav Amit wrote:
>> What do you all think?
>
> I agree in general. But I think that current->mm would need to be loaded, as
> otherwise I am afraid it would break switch_mm_irqs_off().
>
What breaks?
On Mon, Aug 27, 2018 at 11:54 AM, Nadav Amit wrote:
>> On Mon, Aug 27, 2018 at 10:34 AM, Nadav Amit wrote:
>> What do you all think?
>
> I agree in general. But I think that current->mm would need to be loaded, as
> otherwise I am afraid it would break switch_mm_irqs_off().
>
What breaks?
We shouldn't be directly passing device tree values to userspace, both
because there could be mistakes in device trees and because the kernel
doesn't support arbitrary ISAs.
Signed-off-by: Palmer Dabbelt
---
arch/riscv/kernel/cpu.c | 62 +++--
1 file
f1f1007644ff ("mm: add new mmgrab() helper") added a helper that we
missed out on.
Signed-off-by: Palmer Dabbelt
---
arch/riscv/kernel/smpboot.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/riscv/kernel/smpboot.c b/arch/riscv/kernel/smpboot.c
index
This isn't readily apparent from reading the code.
Signed-off-by: Palmer Dabbelt
---
arch/riscv/kernel/smpboot.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/riscv/kernel/smpboot.c b/arch/riscv/kernel/smpboot.c
index 5437a04babcd..953bc540207d 100644
---
We shouldn't be directly passing device tree values to userspace, both
because there could be mistakes in device trees and because the kernel
doesn't support arbitrary ISAs.
Signed-off-by: Palmer Dabbelt
---
arch/riscv/kernel/cpu.c | 62 +++--
1 file
f1f1007644ff ("mm: add new mmgrab() helper") added a helper that we
missed out on.
Signed-off-by: Palmer Dabbelt
---
arch/riscv/kernel/smpboot.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/riscv/kernel/smpboot.c b/arch/riscv/kernel/smpboot.c
index
This isn't readily apparent from reading the code.
Signed-off-by: Palmer Dabbelt
---
arch/riscv/kernel/smpboot.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/riscv/kernel/smpboot.c b/arch/riscv/kernel/smpboot.c
index 5437a04babcd..953bc540207d 100644
---
The old name was a bit odd.
Signed-off-by: Palmer Dabbelt
---
arch/riscv/kernel/smpboot.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/riscv/kernel/smpboot.c b/arch/riscv/kernel/smpboot.c
index 5f29f8562cf6..e1f6a5ad0416 100644
---
These are just hard coded in the RISC-V port, which doesn't make any
sense. We should probably be setting these from device tree entries
when they exist, but for now I think it's saner to just leave them all
as their default values.
Signed-off-by: Palmer Dabbelt
---
It's a bit confusing exactly what this function does: it actually
returns the hartid of an OF processor node, failing with -1 on invalid
nodes. I've changed the name to _hartid() in order to make that a bit
more clear, as well as adding a comment.
Signed-off-by: Palmer Dabbelt
---
It's a bit confusing exactly what this function does: it actually
returns the hartid of an OF processor node, failing with -1 on invalid
nodes. I've changed the name to _hartid() in order to make that a bit
more clear, as well as adding a comment.
Signed-off-by: Palmer Dabbelt
---
The old name was a bit odd.
Signed-off-by: Palmer Dabbelt
---
arch/riscv/kernel/smpboot.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/riscv/kernel/smpboot.c b/arch/riscv/kernel/smpboot.c
index 5f29f8562cf6..e1f6a5ad0416 100644
---
These are just hard coded in the RISC-V port, which doesn't make any
sense. We should probably be setting these from device tree entries
when they exist, but for now I think it's saner to just leave them all
as their default values.
Signed-off-by: Palmer Dabbelt
---
I'm not sure, but I think this was a bug: if the scheduler fired right
here then I believe it would blow up.
Signed-off-by: Palmer Dabbelt
---
arch/riscv/kernel/smpboot.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/kernel/smpboot.c
I'm not sure, but I think this was a bug: if the scheduler fired right
here then I believe it would blow up.
Signed-off-by: Palmer Dabbelt
---
arch/riscv/kernel/smpboot.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/kernel/smpboot.c
Add data structures to track Enclave Page Cache (EPC) pages. EPC is
divided into multiple banks (1-N) of which addresses and sizes can be
enumerated with CPUID by the OS.
On NUMA systems a node can have at most bank. A bank can be at most part of
two nodes. SGX supports both nodes with a single
I'm not sure how I managed to miss this the first time, but this is much
better.
Signed-off-by: Palmer Dabbelt
---
arch/riscv/include/asm/smp.h | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/arch/riscv/include/asm/smp.h b/arch/riscv/include/asm/smp.h
Add data structures to track Enclave Page Cache (EPC) pages. EPC is
divided into multiple banks (1-N) of which addresses and sizes can be
enumerated with CPUID by the OS.
On NUMA systems a node can have at most bank. A bank can be at most part of
two nodes. SGX supports both nodes with a single
I'm not sure how I managed to miss this the first time, but this is much
better.
Signed-off-by: Palmer Dabbelt
---
arch/riscv/include/asm/smp.h | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/arch/riscv/include/asm/smp.h b/arch/riscv/include/asm/smp.h
I finally got around to answering a very old email in my inbox that was
a response to our original patch set. These are meant to cause little
to no functional changes to the port, but I've given them very little
testing so I wouldn't be surprised if I've managed to screw something
up here.
I'll
I finally got around to answering a very old email in my inbox that was
a response to our original patch set. These are meant to cause little
to no functional changes to the port, but I've given them very little
testing so I wouldn't be surprised if I've managed to screw something
up here.
I'll
Intel Software Guard eXtensions (SGX) is a set of CPU instructions that
can be used by applications to set aside private regions of code and
data. The code outside the enclave is disallowed to access the memory
inside the enclave by the CPU access control.
SGX driver provides a ioctl API for
Intel Software Guard eXtensions (SGX) is a set of CPU instructions that
can be used by applications to set aside private regions of code and
data. The code outside the enclave is disallowed to access the memory
inside the enclave by the CPU access control.
SGX driver provides a ioctl API for
Test whether the kernel WARN()s when, under KERNEL_DS, a bad kernel pointer
is used as "userspace" pointer. Should normally be used in "DIRECT" mode.
Signed-off-by: Jann Horn
---
drivers/misc/lkdtm/core.c | 1 +
drivers/misc/lkdtm/lkdtm.h| 1 +
drivers/misc/lkdtm/usercopy.c | 13
Currently, most fixups for attempting to access userspace memory are
handled using _ASM_EXTABLE, which is also used for various other types of
fixups (e.g. safe MSR access, IRET failures, and a bunch of other things).
In order to make it possible to add special safety checks to uaccess fixups
(in
Test whether the kernel WARN()s when, under KERNEL_DS, a bad kernel pointer
is used as "userspace" pointer. Should normally be used in "DIRECT" mode.
Signed-off-by: Jann Horn
---
drivers/misc/lkdtm/core.c | 1 +
drivers/misc/lkdtm/lkdtm.h| 1 +
drivers/misc/lkdtm/usercopy.c | 13
Currently, most fixups for attempting to access userspace memory are
handled using _ASM_EXTABLE, which is also used for various other types of
fixups (e.g. safe MSR access, IRET failures, and a bunch of other things).
In order to make it possible to add special safety checks to uaccess fixups
(in
There have been multiple kernel vulnerabilities that permitted userspace to
pass completely unchecked pointers through to userspace accessors:
- the waitid() bug - commit 96ca579a1ecc ("waitid(): Add missing
access_ok() checks")
- the sg/bsg read/write APIs
- the infiniband read/write APIs
There have been multiple kernel vulnerabilities that permitted userspace to
pass completely unchecked pointers through to userspace accessors:
- the waitid() bug - commit 96ca579a1ecc ("waitid(): Add missing
access_ok() checks")
- the sg/bsg read/write APIs
- the infiniband read/write APIs
This removes the call into exception fixup that was added in
commit c28f896634f2 ("[PATCH] kprobes: fix broken fault handling for
x86_64").
On X86, kprobe_fault_handler() is called from two places:
do_general_protection() (for #GP) and kprobes_fault() (for #PF).
In both paths, the
This is preparation for looking at trap number and fault address in the
handlers for uaccess errors.
This patch should not change any behavior.
Signed-off-by: Jann Horn
---
arch/x86/include/asm/extable.h | 3 ++-
arch/x86/include/asm/ptrace.h| 2 ++
arch/x86/kernel/cpu/mcheck/mce.c | 2
This removes the call into exception fixup that was added in
commit c28f896634f2 ("[PATCH] kprobes: fix broken fault handling for
x86_64").
On X86, kprobe_fault_handler() is called from two places:
do_general_protection() (for #GP) and kprobes_fault() (for #PF).
In both paths, the
This is preparation for looking at trap number and fault address in the
handlers for uaccess errors.
This patch should not change any behavior.
Signed-off-by: Jann Horn
---
arch/x86/include/asm/extable.h | 3 ++-
arch/x86/include/asm/ptrace.h| 2 ++
arch/x86/kernel/cpu/mcheck/mce.c | 2
The opaque plumbing of #GP from do_general_protection() through
notify_die() into kprobe_exceptions_notify() makes it hard to understand
what's going on.
Suggested-by: Andy Lutomirski
Signed-off-by: Jann Horn
---
arch/x86/kernel/kprobes/core.c | 31 +--
The opaque plumbing of #GP from do_general_protection() through
notify_die() into kprobe_exceptions_notify() makes it hard to understand
what's going on.
Suggested-by: Andy Lutomirski
Signed-off-by: Jann Horn
---
arch/x86/kernel/kprobes/core.c | 31 +--
This is the second version of "[RFC PATCH 1/2] x86: WARN() when uaccess
helpers fault on kernel addresses".
See patch 6/7 ("x86: BUG() when uaccess helpers fault on kernel
addresses") for a description of the motivation for this series.
Patches 1 and 2 are cleanups that I did while working on
From: Sean Christopherson
Add a function to perform ENCLS(EINIT), which initializes an enclave,
which can be used by a driver for running enclaves and VMMs.
Writing the LE hash MSRs is extraordinarily expensive, e.g. 3-4x slower
than normal MSRs, so we use a per-cpu cache to track the last
This is an extension of commit b506a9d08bae ("x86: code clarification patch
to Kprobes arch code"). As that commit explains, even though
kprobe_running() can't be called with preemption enabled, you don't have to
disable preemption - if preemption is on, you can't be in a kprobe.
Also, use
This is an extension of commit b506a9d08bae ("x86: code clarification patch
to Kprobes arch code"). As that commit explains, even though
kprobe_running() can't be called with preemption enabled, you don't have to
disable preemption - if preemption is on, you can't be in a kprobe.
Also, use
This is the second version of "[RFC PATCH 1/2] x86: WARN() when uaccess
helpers fault on kernel addresses".
See patch 6/7 ("x86: BUG() when uaccess helpers fault on kernel
addresses") for a description of the motivation for this series.
Patches 1 and 2 are cleanups that I did while working on
From: Sean Christopherson
Add a function to perform ENCLS(EINIT), which initializes an enclave,
which can be used by a driver for running enclaves and VMMs.
Writing the LE hash MSRs is extraordinarily expensive, e.g. 3-4x slower
than normal MSRs, so we use a per-cpu cache to track the last
Add a Enclave Page Cache (EPC) memory manager that can be used to
allocate and free EPC pages. The swapper thread ksgxswapd reclaims pages
on the event when the number of free EPC pages goes below
%SGX_NR_LOW_PAGES up until it reaches %SGX_NR_HIGH_PAGES.
Pages are reclaimed in LRU fashion from a
Add a Enclave Page Cache (EPC) memory manager that can be used to
allocate and free EPC pages. The swapper thread ksgxswapd reclaims pages
on the event when the number of free EPC pages goes below
%SGX_NR_LOW_PAGES up until it reaches %SGX_NR_HIGH_PAGES.
Pages are reclaimed in LRU fashion from a
Add wrappers for Intel(R) SGX ENCLS opcode leaf functions except
ENCLS(EINIT). ENCLS invokes privileged functions for managing (creation,
initialization and swapping) and debugging enclaves.
Signed-off-by: Jarkko Sakkinen
Co-developed-by: Sean Christopherson
Signed-off-by: Sean Christopherson
Add wrappers for Intel(R) SGX ENCLS opcode leaf functions except
ENCLS(EINIT). ENCLS invokes privileged functions for managing (creation,
initialization and swapping) and debugging enclaves.
Signed-off-by: Jarkko Sakkinen
Co-developed-by: Sean Christopherson
Signed-off-by: Sean Christopherson
From: Sean Christopherson
Intel(R) SGX is a set of CPU instructions that can be used by applications
to set aside private regions of code and data. The code outside the enclave
is disallowed to access the memory inside the enclave by the CPU access
control.
Add a check for SGX to arch/x86 and a
From: Sean Christopherson
Intel(R) SGX is a set of CPU instructions that can be used by applications
to set aside private regions of code and data. The code outside the enclave
is disallowed to access the memory inside the enclave by the CPU access
control.
Add a check for SGX to arch/x86 and a
From: Sean Christopherson
ENCLS and ENCLU are usable if and only if SGX_ENABLE is set and After
SGX is activated the IA32_SGXLEPUBKEYHASHn MSRs are writable if
SGX_LC_WR is set and the feature control is locked.
SGX related bits in IA32_FEATURE_CONTROL cannot be set before SGX is
activated by
From: Sean Christopherson
ENCLS and ENCLU are usable if and only if SGX_ENABLE is set and After
SGX is activated the IA32_SGXLEPUBKEYHASHn MSRs are writable if
SGX_LC_WR is set and the feature control is locked.
SGX related bits in IA32_FEATURE_CONTROL cannot be set before SGX is
activated by
From: Sean Christopherson
CPUID_12_EAX is an Intel-defined feature bits leaf dedicated for SGX.
There are currently four documented feature bits, with more expected in
the not-too-distant future.
Signed-off-by: Sean Christopherson
Signed-off-by: Jarkko Sakkinen
---
From: Sean Christopherson
CPUID_12_EAX is an Intel-defined feature bits leaf dedicated for SGX.
There are currently four documented feature bits, with more expected in
the not-too-distant future.
Signed-off-by: Sean Christopherson
Signed-off-by: Jarkko Sakkinen
---
Add arch/x86/include/asm/sgx_arch.h, which contains definitions for the
architectural data structures used by the CPU to implement the SGX.
Signed-off-by: Jarkko Sakkinen
---
arch/x86/include/asm/sgx_arch.h | 379 ++
arch/x86/include/uapi/asm/sgx_errno.h | 91
Add arch/x86/include/asm/sgx_arch.h, which contains definitions for the
architectural data structures used by the CPU to implement the SGX.
Signed-off-by: Jarkko Sakkinen
---
arch/x86/include/asm/sgx_arch.h | 379 ++
arch/x86/include/uapi/asm/sgx_errno.h | 91
From: Kai Huang
Add X86_FEATURE_SGX and X86_FEATURE_SGX_LC that define the bits
determining whether the CPU supports SGX and user launch configuration
i.e. using a custom root key rather the Intel proprietary key for
enclave signing.
Signed-off-by: Kai Huang
Signed-off-by: Jarkko Sakkinen
---
From: Kai Huang
Add X86_FEATURE_SGX and X86_FEATURE_SGX_LC that define the bits
determining whether the CPU supports SGX and user launch configuration
i.e. using a custom root key rather the Intel proprietary key for
enclave signing.
Signed-off-by: Kai Huang
Signed-off-by: Jarkko Sakkinen
---
Add the maintainer information for the SGX subsystem.
Signed-off-by: Jarkko Sakkinen
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 24b200d91b30..877fbc6ef7a7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7562,6 +7562,13 @@ L:
Add the maintainer information for the SGX subsystem.
Signed-off-by: Jarkko Sakkinen
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 24b200d91b30..877fbc6ef7a7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7562,6 +7562,13 @@ L:
at 11:45 AM, Andy Lutomirski wrote:
> On Mon, Aug 27, 2018 at 10:34 AM, Nadav Amit wrote:
>> at 1:05 AM, Masami Hiramatsu wrote:
>>
>>> On Sun, 26 Aug 2018 20:26:09 -0700
>>> Nadav Amit wrote:
>>>
at 8:03 PM, Masami Hiramatsu wrote:
> On Sun, 26 Aug 2018 11:09:58 +0200
>
at 11:45 AM, Andy Lutomirski wrote:
> On Mon, Aug 27, 2018 at 10:34 AM, Nadav Amit wrote:
>> at 1:05 AM, Masami Hiramatsu wrote:
>>
>>> On Sun, 26 Aug 2018 20:26:09 -0700
>>> Nadav Amit wrote:
>>>
at 8:03 PM, Masami Hiramatsu wrote:
> On Sun, 26 Aug 2018 11:09:58 +0200
>
Due to hardware errata, Ampere Computing eMAG SATA can't support
AHCI ALPM feature. This patch disables the AHCI ALPM feature for
eMAG SATA.
Signed-off-by: Suman Tripathi
Signed-off-by: Rameshwar Prasad Sahu
---
drivers/ata/ahci_platform.c | 13 -
1 file changed, 12 insertions(+),
Due to hardware errata, Ampere Computing eMAG SATA can't support
AHCI ALPM feature. This patch disables the AHCI ALPM feature for
eMAG SATA.
Signed-off-by: Suman Tripathi
Signed-off-by: Rameshwar Prasad Sahu
---
drivers/ata/ahci_platform.c | 13 -
1 file changed, 12 insertions(+),
On Mon, Aug 27, 2018 at 10:34 AM, Nadav Amit wrote:
> at 1:05 AM, Masami Hiramatsu wrote:
>
>> On Sun, 26 Aug 2018 20:26:09 -0700
>> Nadav Amit wrote:
>>
>>> at 8:03 PM, Masami Hiramatsu wrote:
>>>
On Sun, 26 Aug 2018 11:09:58 +0200
Peter Zijlstra wrote:
> On Sat, Aug 25,
On Mon, Aug 27, 2018 at 10:34 AM, Nadav Amit wrote:
> at 1:05 AM, Masami Hiramatsu wrote:
>
>> On Sun, 26 Aug 2018 20:26:09 -0700
>> Nadav Amit wrote:
>>
>>> at 8:03 PM, Masami Hiramatsu wrote:
>>>
On Sun, 26 Aug 2018 11:09:58 +0200
Peter Zijlstra wrote:
> On Sat, Aug 25,
On Mon, 27 Aug 2018 16:01:41 +0900
Masahiro Yamada wrote:
> Commit 49aa76b16676 ("mtd: rawnand: do not execute nand_scan_ident()
> if maxchips is zero") gave a new meaning for calling nand_scan_ident()
> with maxchips=0.
>
> It is a special usage for some drivers such as docg4, but actually
>
On Mon, 27 Aug 2018 16:01:41 +0900
Masahiro Yamada wrote:
> Commit 49aa76b16676 ("mtd: rawnand: do not execute nand_scan_ident()
> if maxchips is zero") gave a new meaning for calling nand_scan_ident()
> with maxchips=0.
>
> It is a special usage for some drivers such as docg4, but actually
>
On Thu, 23 Aug 2018 23:43:45 +0200
Geert Uytterhoeven wrote:
> If gcc (e.g. 4.1.2) decides not to inline init_mtd_structs() and
> read_id_reg(), this will cause section mismatches, and crashes:
>
> WARNING: drivers/mtd/nand/raw/docg4.o(.text+0xc10): Section mismatch in
> reference from the
On Thu, 23 Aug 2018 23:43:45 +0200
Geert Uytterhoeven wrote:
> If gcc (e.g. 4.1.2) decides not to inline init_mtd_structs() and
> read_id_reg(), this will cause section mismatches, and crashes:
>
> WARNING: drivers/mtd/nand/raw/docg4.o(.text+0xc10): Section mismatch in
> reference from the
Currently in record mode the tool implements trace writing serially.
The algorithm loops over mapped per-cpu data buffers and stores ready
data chunks into a trace file using write() system call.
At some circumstances the kernel may lack free space in a buffer
because the other buffer's half
Currently in record mode the tool implements trace writing serially.
The algorithm loops over mapped per-cpu data buffers and stores ready
data chunks into a trace file using write() system call.
At some circumstances the kernel may lack free space in a buffer
because the other buffer's half
Great, thanks so much for the quick reply!
Ray
On Mon, Aug 27, 2018 at 2:34 PM Greg Kroah-Hartman wrote:
>
> On Mon, Aug 27, 2018 at 02:26:48PM -0400, Ray Clinton wrote:
> > Hi,
> >
> > I'm brand new to kernel dev and after going through Kernel Newbies
> > am trying to find a good first patch
Great, thanks so much for the quick reply!
Ray
On Mon, Aug 27, 2018 at 2:34 PM Greg Kroah-Hartman wrote:
>
> On Mon, Aug 27, 2018 at 02:26:48PM -0400, Ray Clinton wrote:
> > Hi,
> >
> > I'm brand new to kernel dev and after going through Kernel Newbies
> > am trying to find a good first patch
On Mon, Aug 27, 2018 at 02:26:48PM -0400, Ray Clinton wrote:
> Hi,
>
> I'm brand new to kernel dev and after going through Kernel Newbies
> am trying to find a good first patch to work.
>
> I just wanted to know if the TODO files, mentioned in the subject, are
> up-to-date. If not, would you
On Mon, Aug 27, 2018 at 02:26:48PM -0400, Ray Clinton wrote:
> Hi,
>
> I'm brand new to kernel dev and after going through Kernel Newbies
> am trying to find a good first patch to work.
>
> I just wanted to know if the TODO files, mentioned in the subject, are
> up-to-date. If not, would you
Hi,
I'm brand new to kernel dev and after going through Kernel Newbies
am trying to find a good first patch to work.
I just wanted to know if the TODO files, mentioned in the subject, are
up-to-date. If not, would you have any suggestions on where to find
a good first patch to work on?
Thanks
Hi,
I'm brand new to kernel dev and after going through Kernel Newbies
am trying to find a good first patch to work.
I just wanted to know if the TODO files, mentioned in the subject, are
up-to-date. If not, would you have any suggestions on where to find
a good first patch to work on?
Thanks
From: Roman Kiryanov
There is no reason to have an array of 1.
Signed-off-by: Roman Kiryanov
---
drivers/platform/goldfish/goldfish_pipe.c | 28 +++
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/platform/goldfish/goldfish_pipe.c
From: Roman Kiryanov
Since the driver provides no workaround prevent in cases if structs do
no fit into a memory page, it is better to fail complation to find about
the issue earlt instead of returning errors at runtime.
Signed-off-by: Roman Kiryanov
---
From: Roman Kiryanov
Provide an explanation why GFP_ATOMIC is needed to prevent changing it to
other values.
Signed-off-by: Roman Kiryanov
---
drivers/platform/goldfish/goldfish_pipe.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git
From: Roman Kiryanov
To improve readability and to be consistent with other
struct members.
Signed-off-by: Roman Kiryanov
---
drivers/platform/goldfish/goldfish_pipe.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/platform/goldfish/goldfish_pipe.c
From: Roman Kiryanov
There is no reason to have an array of 1.
Signed-off-by: Roman Kiryanov
---
drivers/platform/goldfish/goldfish_pipe.c | 28 +++
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/platform/goldfish/goldfish_pipe.c
From: Roman Kiryanov
Since the driver provides no workaround prevent in cases if structs do
no fit into a memory page, it is better to fail complation to find about
the issue earlt instead of returning errors at runtime.
Signed-off-by: Roman Kiryanov
---
501 - 600 of 1294 matches
Mail list logo