From: Peng Ma
This patch enables ACPI support in RCPM driver.
Signed-off-by: Peng Ma
Signed-off-by: Ran Wang
---
Change in v5:
- Fix panic when dev->of_node is null
Change in v4:
- Make commit subject more accurate
- Remove unrelated new blank line
Change in v3:
- Add #ifdef CONFIG_ACPI
On Wed, Sep 02, 2020 at 11:02:22AM -0700, Linus Torvalds wrote:
> I don't see why this change would make any difference.
Me neither, but while looking at a different project I did spot places
that actually do an access_ok with len 0, that's why I wanted him to
try.
That being said: Christophe are
Le 02/09/2020 à 20:02, Linus Torvalds a écrit :
On Wed, Sep 2, 2020 at 8:17 AM Christophe Leroy
wrote:
With this fix, I get
root@vgoippro:~# time dd if=/dev/zero of=/dev/null count=1M
536870912 bytes (512.0MB) copied, 6.776327 seconds, 75.6MB/s
That's still far from the 91.7MB/s I get wi
Le 03/09/2020 à 09:11, Christoph Hellwig a écrit :
On Wed, Sep 02, 2020 at 11:02:22AM -0700, Linus Torvalds wrote:
I don't see why this change would make any difference.
Me neither, but while looking at a different project I did spot places
that actually do an access_ok with len 0, that's w
Le 03/09/2020 à 09:11, Christoph Hellwig a écrit :
Except that we do not actually have such a patch. For normal user
writes we only use ->write_iter if ->write is not present. But what
shows up in the profile is that /dev/zero only has a read_iter op and
not a normal read. I've added a pat
From: "Gautham R. Shenoy"
commit d947fb4c965c ("cpuidle: pseries: Fixup exit latency for
CEDE(0)") sets the exit latency of CEDE(0) based on the latency values
of the Extended CEDE states advertised by the platform. The values
advertised by the platform are in timebase ticks. However the cpuidle
On Wed, Sep 2, 2020 at 1:20 AM Nicolin Chen wrote:
>
> We found that callers of dma_get_seg_boundary mostly do an ALIGN
> with page mask and then do a page shift to get number of pages:
> ALIGN(boundary + 1, 1 << shift) >> shift
>
> However, the boundary might be as large as ULONG_MAX, which m
On Fri, 28 Aug 2020 15:38:52 +0530, Aneesh Kumar K.V wrote:
> If the hypervisor doesn't support hugepages, the kernel ends up allocating a
> large
> number of page table pages. The early page table allocation was wrongly
> setting the max memblock limit to ppc64_rma_size with radix translation
> w
On Wed, 2 Sep 2020 09:31:22 +0530, Aneesh Kumar K.V wrote:
> The test is broken w.r.t page table update rules and results in kernel
> crash as below. Disable the support until we get the tests updated.
>
> [ 21.083519] kernel BUG at arch/powerpc/mm/pgtable.c:304!
> cpu 0x0: Vector: 700 (Program
On Tue, 1 Sep 2020 22:46:53 +1000, Michael Ellerman wrote:
> In commit 9b725a90a8f1 ("powerpc/64s: Disallow PROT_SAO in LPARs by
> default") PROT_SAO was disabled in guests/LPARs by default. So skip
> the test if we are running in a guest to avoid a spurious failure.
Applied to powerpc/fixes.
[1/
Instead of providing a special no-compat version provide a special
compat version for operations with ->compat_ioctl.
Signed-off-by: Christoph Hellwig
---
fs/proc/inode.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/fs/proc/inode.c b/fs/proc/inode.c
index 016b13
Just return early on inode allocation failure.
Signed-off-by: Christoph Hellwig
---
fs/proc/inode.c | 72 +
1 file changed, 37 insertions(+), 35 deletions(-)
diff --git a/fs/proc/inode.c b/fs/proc/inode.c
index 28d6105e908e4c..016b1302cbabc0 10064
From: "Matthew Wilcox (Oracle)"
Using the read_iter/write_iter interfaces allows for in-kernel users
to set sysctls without using set_fs(). Also, the buffer is a string,
so give it the real type of 'char *', not void *.
Signed-off-by: Matthew Wilcox (Oracle)
Signed-off-by: Christoph Hellwig
-
Hi all,
this series removes the last set_fs() used to force a kernel address
space for the uaccess code in the kernel read/write/splice code, and then
stops implementing the address space overrides entirely for x86 and
powerpc.
[Note to Linus: I'd like to get this into linux-next rather earlier
t
This will allow proc files to implement iter read semantics.
Signed-off-by: Christoph Hellwig
---
fs/proc/inode.c | 53 ++---
include/linux/proc_fs.h | 1 +
2 files changed, 51 insertions(+), 3 deletions(-)
diff --git a/fs/proc/inode.c b/fs/proc/inod
Don't allow calling ->read or ->write with set_fs as a preparation for
killing off set_fs. All the instances that we use kernel_read/write on
are using the iter ops already.
If a file has both the regular ->read/->write methods and the iter
variants those could have different semantics for messed
default_file_splice_write is the last piece of generic code that uses
set_fs to make the uaccess routines operate on kernel pointers. It
implements a "fallback loop" for splicing from files that do not actually
provide a proper splice_read method. The usual file systems and other
high bandwidth i
We can't run the tests for userspace bitmap parsing if set_fs() doesn't
exist, and it is about to go away for x86, powerpc with other major
architectures to follow.
Signed-off-by: Christoph Hellwig
---
lib/test_bitmap.c | 91 +++
1 file changed, 21 ins
Once we can't manipulate the address limit, we also can't test what
happens when the manipulation is abused.
Signed-off-by: Christoph Hellwig
---
drivers/misc/lkdtm/bugs.c | 10 --
drivers/misc/lkdtm/core.c | 2 --
drivers/misc/lkdtm/lkdtm.h | 2
At least for 64-bit this moves them closer to some of the defines
they are based on, and it prepares for using the TASK_SIZE_MAX
definition from assembly.
Signed-off-by: Christoph Hellwig
Reviewed-by: Kees Cook
---
arch/x86/include/asm/page_32_types.h | 11 +++
arch/x86/include/asm/page_64_
For 64-bit the only thing missing was a strategic _AC, and for 32-bit we
need to use __PAGE_OFFSET instead of PAGE_OFFSET in the TASK_SIZE
definition to escape the explicit unsigned long cast. This just works
because __PAGE_OFFSET is defined using _AC itself and thus never needs
the cast anyway.
Stop providing the possibility to override the address space using
set_fs() now that there is no need for that any more. To properly
handle the TASK_SIZE_MAX checking for 4 vs 5-level page tables on
x86 a new alternative is introduced, which just like the one in
entry_64.S has to use the hardcoded
Add a CONFIG_SET_FS option that is selected by architecturess that
implement set_fs, which is all of them initially. If the option is not
set stubs for routines related to overriding the address space are
provided so that architectures can start to opt out of providing set_fs.
Signed-off-by: Chri
Provide __get_kernel_nofault and __put_kernel_nofault routines to
implement the maccess routines without messing with set_fs and without
opening up access to user space.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/include/asm/uaccess.h | 16
1 file changed, 16 insertions(+
Stop providing the possibility to override the address space using
set_fs() now that there is no need for that any more.
Signed-off-by: Christoph Hellwig
---
arch/powerpc/Kconfig | 1 -
arch/powerpc/include/asm/processor.h | 7
arch/powerpc/include/asm/thread_info.h |
On Thu, Sep 03, 2020 at 04:22:28PM +0200, Christoph Hellwig wrote:
> Besides x86 and powerpc I plan to eventually convert all other
> architectures, although this will be a slow process, starting with the
> easier ones once the infrastructure is merged. The process to convert
> architectures is r
On Thu, Sep 03, 2020 at 03:28:03PM +0100, Al Viro wrote:
> On Thu, Sep 03, 2020 at 04:22:28PM +0200, Christoph Hellwig wrote:
>
> > Besides x86 and powerpc I plan to eventually convert all other
> > architectures, although this will be a slow process, starting with the
> > easier ones once the inf
On Thu, Sep 03, 2020 at 04:30:03PM +0200, Christoph Hellwig wrote:
> On Thu, Sep 03, 2020 at 03:28:03PM +0100, Al Viro wrote:
> > On Thu, Sep 03, 2020 at 04:22:28PM +0200, Christoph Hellwig wrote:
> >
> > > Besides x86 and powerpc I plan to eventually convert all other
> > > architectures, althoug
On Thu, Sep 03, 2020 at 03:36:29PM +0100, Al Viro wrote:
> FWIW, vfs.git#for-next is always a merge of independent branches; I don't
> put stuff directly into #for-next - too easy to lose that way.
>
> IOW, that would be something like #base.set_fs, included into #for-next
> merge set. And I've n
Le 03/09/2020 à 16:22, Christoph Hellwig a écrit :
Stop providing the possibility to override the address space using
set_fs() now that there is no need for that any more.
Signed-off-by: Christoph Hellwig
---
-static inline int __access_ok(unsigned long addr, unsigned long size,
-
On Thu, Sep 03, 2020 at 05:43:25PM +0200, Christophe Leroy wrote:
>
>
> Le 03/09/2020 à 16:22, Christoph Hellwig a écrit :
>> Stop providing the possibility to override the address space using
>> set_fs() now that there is no need for that any more.
>>
>> Signed-off-by: Christoph Hellwig
>> ---
>
On Thu, Sep 3, 2020 at 7:22 AM Christoph Hellwig wrote:
>
> [Note to Linus: I'd like to get this into linux-next rather earlier
> than later. Do you think it is ok to add this tree to linux-next?]
This whole series looks really good to me now, with each patch looking
like a clear cleanup on its
* Gautham R Shenoy [2020-09-03 14:57:27]:
> From: "Gautham R. Shenoy"
>
> commit d947fb4c965c ("cpuidle: pseries: Fixup exit latency for
> CEDE(0)") sets the exit latency of CEDE(0) based on the latency values
> of the Extended CEDE states advertised by the platform. The values
> advertised by
On Thu, Sep 03, 2020 at 05:49:09PM +0200, Christoph Hellwig wrote:
> On Thu, Sep 03, 2020 at 05:43:25PM +0200, Christophe Leroy wrote:
> >
> >
> > Le 03/09/2020 à 16:22, Christoph Hellwig a écrit :
> >> Stop providing the possibility to override the address space using
> >> set_fs() now that there
Le 03/09/2020 à 17:56, Christoph Hellwig a écrit :
On Thu, Sep 03, 2020 at 05:49:09PM +0200, Christoph Hellwig wrote:
On Thu, Sep 03, 2020 at 05:43:25PM +0200, Christophe Leroy wrote:
Le 03/09/2020 à 16:22, Christoph Hellwig a écrit :
Stop providing the possibility to override the address
On Thu, Sep 03, 2020 at 01:57:39PM +0300, Andy Shevchenko wrote:
> > +{
> > + if (!dev)
> > + return (U32_MAX >> page_shift) + 1;
> > + return (dma_get_seg_boundary(dev) >> page_shift) + 1;
>
> Can it be better to do something like
> unsigned long boundary = dev ? dma_g
Applied with the recommendation from Michael folded in.
Le 03/09/2020 à 18:12, Christoph Hellwig a écrit :
On Thu, Sep 03, 2020 at 01:57:39PM +0300, Andy Shevchenko wrote:
+{
+ if (!dev)
+ return (U32_MAX >> page_shift) + 1;
+ return (dma_get_seg_boundary(dev) >> page_shift) + 1;
Can it be better to do something like
allnoconfig
x86_64 randconfig-a004-20200903
x86_64 randconfig-a006-20200903
x86_64 randconfig-a003-20200903
x86_64 randconfig-a005-20200903
x86_64 randconfig-a001-20200903
x86_64 randconfig
ig
powerpc allmodconfig
powerpc allnoconfig
x86_64 randconfig-a004-20200903
x86_64 randconfig-a006-20200903
x86_64 randconfig-a003-20200903
x86_64 randconfig-a005-20200903
x86_64 randc
On 2020-06-23 15:03, Michael Ellerman wrote:
With CONFIG_OF_ALL_DTBS=y, as set by eg. allmodconfig, we see lots of
warnings about our dts files, such as:
arch/powerpc/boot/dts/glacier.dts:492.26-532.5:
Warning (pci_bridge): /plb/pciex@d: node name is not "pci"
or "pcie"
The nod
From: Christoph Hellwig
> Sent: 03 September 2020 15:23
>
> Stop providing the possibility to override the address space using
> set_fs() now that there is no need for that any more. To properly
> handle the TASK_SIZE_MAX checking for 4 vs 5-level page tables on
> x86 a new alternative is introdu
On Wed, 2 Sep 2020 11:09:11 +0200 Laurent Dufour wrote:
> register_mem_sect_under_nodem() is checking the memory block's node id only
> if the system state is "SYSTEM_BOOTING". On PowerPC, the memory blocks are
> registered while the system state is "SYSTEM_SCHEDULING", the one before
> SYSTEM_R
On Thu, Sep 3, 2020 at 2:30 PM David Laight wrote:
>
> A non-canonical (is that the right term) address between the highest
> valid user address and the lowest valid kernel address (7ffe to fffe?)
> will fault anyway.
Yes.
But we actually warn against that fault, because it's been a good way
to
On 1/09/20 6:14 pm, Nicholas Piggin wrote:
> Excerpts from Chris Packham's message of September 1, 2020 11:25 am:
>> On 1/09/20 12:33 am, Heiner Kallweit wrote:
>>> On 30.08.2020 23:59, Chris Packham wrote:
On 31/08/20 9:41 am, Heiner Kallweit wrote:
> On 30.08.2020 23:00, Chris Packham w
The SPIE register contains counts for the TX FIFO so any time the irq
handler was invoked we would attempt to process the RX/TX fifos. Use the
SPIM value to mask the events so that we only process interrupts that
were expected.
This was a latent issue exposed by commit 3282a3da25bd ("powerpc/64:
I
On 02/09/2020 16:11, Leonardo Bras wrote:
On Mon, 2020-08-31 at 14:35 +1000, Alexey Kardashevskiy wrote:
On 29/08/2020 04:36, Leonardo Bras wrote:
On Mon, 2020-08-24 at 15:17 +1000, Alexey Kardashevskiy wrote:
On 18/08/2020 09:40, Leonardo Bras wrote:
As of today, if the biggest DDW that
On Thu, Sep 03, 2020 at 04:22:40PM +0200, Christoph Hellwig wrote:
> diff --git a/arch/x86/lib/getuser.S b/arch/x86/lib/getuser.S
> index c8a85b512796e1..94f7be4971ed04 100644
> --- a/arch/x86/lib/getuser.S
> +++ b/arch/x86/lib/getuser.S
> @@ -35,10 +35,19 @@
> #include
> #include
>
> +#ifde
On 09/02/2020 05:12 PM, Aneesh Kumar K.V wrote:
> This will help in adding proper locks in a later patch
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> mm/debug_vm_pgtable.c | 51 ---
> 1 file changed, 28 insertions(+), 23 deletions(-)
>
> diff --git a/mm
On 09/02/2020 05:12 PM, Aneesh Kumar K.V wrote:
> ppc64 use bit 62 to indicate a pte entry (_PAGE_PTE). Avoid setting
> that bit in random value.
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> mm/debug_vm_pgtable.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff
On 09/02/2020 05:12 PM, Aneesh Kumar K.V wrote:
> ppc64 supports huge vmap only with radix translation. Hence use arch helper
> to determine the huge vmap support.
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> mm/debug_vm_pgtable.c | 14 --
> 1 file changed, 12 insertions(+), 2 dele
On 09/02/2020 05:12 PM, Aneesh Kumar K.V wrote:
> Saved write support was added to track the write bit of a pte after
> marking the pte protnone. This was done so that AUTONUMA can convert
> a write pte to protnone and still track the old write bit. When converting
> it back we set the pte write
On 09/02/2020 05:16 PM, Aneesh Kumar K.V wrote:
> pte_clear_tests operate on an existing pte entry. Make sure that
> is not a none pte entry.
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> mm/debug_vm_pgtable.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/mm/d
On 09/02/2020 05:12 PM, Aneesh Kumar K.V wrote:
> Architectures like ppc64 use deposited page table while updating the
> huge pte entries.
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> mm/debug_vm_pgtable.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/mm/
On Fri, Sep 04, 2020 at 03:55:10AM +0100, Al Viro wrote:
> On Thu, Sep 03, 2020 at 04:22:40PM +0200, Christoph Hellwig wrote:
>
> > diff --git a/arch/x86/lib/getuser.S b/arch/x86/lib/getuser.S
> > index c8a85b512796e1..94f7be4971ed04 100644
> > --- a/arch/x86/lib/getuser.S
> > +++ b/arch/x86/lib/g
On 09/02/2020 05:12 PM, Aneesh Kumar K.V wrote:
> kernel expects entries to be marked huge before we use
> set_pmd_at()/set_pud_at().
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> mm/debug_vm_pgtable.c | 20 +++-
> 1 file changed, 11 insertions(+), 9 deletions(-)
>
> diff --git
On 09/02/2020 05:12 PM, Aneesh Kumar K.V wrote:
> set_pte_at() should not be used to set a pte entry at locations that
> already holds a valid pte entry. Architectures like ppc64 don't do TLB
> invalidate in set_pte_at() and hence expect it to be used to set locations
> that are not a valid PTE.
On 09/02/2020 05:12 PM, Aneesh Kumar K.V wrote:
> Make sure we call pte accessors with correct lock held.
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> mm/debug_vm_pgtable.c | 35 ++-
> 1 file changed, 22 insertions(+), 13 deletions(-)
>
> diff --git a/mm/debug_
* Christoph Hellwig wrote:
> Hi all,
>
> this series removes the last set_fs() used to force a kernel address
> space for the uaccess code in the kernel read/write/splice code, and then
> stops implementing the address space overrides entirely for x86 and
> powerpc.
Cool! For the x86 bits:
On 09/02/2020 05:12 PM, Aneesh Kumar K.V wrote:
> pmd_clear() should not be used to clear pmd level pte entries.
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> mm/debug_vm_pgtable.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/mm/debug_vm_pgtable.c b/mm/debug_
On Thu, 2020-09-03 at 14:41 +1000, Alexey Kardashevskiy wrote:
> I am new to this, so I am trying to understand how a memory page mapped
> > as DMA, and used for something else could be a problem.
>
> From the device prospective, there is PCI space and everything from 0
> till 1<<64 is accessibl
On 09/02/2020 05:12 PM, Aneesh Kumar K.V wrote:
> The seems to be missing quite a lot of details w.r.t allocating
> the correct pgtable_t page (huge_pte_alloc()), holding the right
> lock (huge_pte_lock()) etc. The vma used is also not a hugetlb VMA.
>
> ppc64 do have runtime checks within CONF
On Fri, Sep 04, 2020 at 03:55:10AM +0100, Al Viro wrote:
> On Thu, Sep 03, 2020 at 04:22:40PM +0200, Christoph Hellwig wrote:
>
> > diff --git a/arch/x86/lib/getuser.S b/arch/x86/lib/getuser.S
> > index c8a85b512796e1..94f7be4971ed04 100644
> > --- a/arch/x86/lib/getuser.S
> > +++ b/arch/x86/lib/g
On 09/02/2020 05:12 PM, Aneesh Kumar K.V wrote:
> This patch series includes fixes for debug_vm_pgtable test code so that
> they follow page table updates rules correctly. The first two patches
> introduce
> changes w.r.t ppc64. The patches are included in this series for
> completeness. We ca
64 matches
Mail list logo
