Hi ajd,
Thanks for taking care of this.
I was going to merge this as-is, but given it's fixing a long standing
issue there's not really a big rush. So a few comments below.
Andrew Donnellan writes:
> A number of userspace utilities depend on making calls to RTAS to retrieve
> information and up
Hi Christoph,
On Mon, 10 Aug 2020 08:11:06 +0200 Christoph Hellwig wrote:
>
> please drop my set_fs tree from linux-next. It is not going to be
> merged for 5.9 in this form.
OK, done from tomorrow.
--
Cheers,
Stephen Rothwell
pgpWqA2LVLZSU.pgp
Description: OpenPGP digital signature
Hi Stephen,
please drop my set_fs tree from linux-next. It is not going to be
merged for 5.9 in this form.
Thanks!
Hi Nicholas,
I love your patch! Yet something to improve:
[auto build test ERROR on hnaz-linux-mm/master]
[also build test ERROR on arm64/for-next/core powerpc/next tip/x86/mm
linus/master v5.8 next-20200807]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submit
On platforms that define HAVE_ARCH_HUGE_VMAP and support PMD vmaps,
vmalloc will attempt to allocate PMD-sized pages first, before falling
back to small pages.
Allocations which use something other than PAGE_KERNEL protections are
not permitted to use huge pages yet, not all callers expect this (e
As a side-effect, the order of flush_cache_vmap() and
arch_sync_kernel_mappings() calls are switched, but that now matches
the other callers in this file.
Signed-off-by: Nicholas Piggin
---
mm/vmalloc.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/mm/vma
This is a generic kernel virtual memory mapper, not specific to ioremap.
Signed-off-by: Nicholas Piggin
---
include/linux/vmalloc.h | 2 +
mm/ioremap.c| 192
mm/vmalloc.c| 191 +++
3 files chan
This changes the awkward approach where architectures provide init
functions to determine which levels they can provide large mappings for,
to one where the arch is queried for each call.
This removes code and indirection, and allows constant-folding of dead
code for unsupported levels.
This also
This will be moved to mm/ and used as a generic kernel virtual mapping
function, so re-name it in preparation.
Signed-off-by: Nicholas Piggin
---
mm/ioremap.c | 55 ++--
1 file changed, 23 insertions(+), 32 deletions(-)
diff --git a/mm/ioremap.c b
The vmalloc mapper operates on a struct page * array rather than a
linear physical address, re-name it to make this distinction clear.
Signed-off-by: Nicholas Piggin
---
mm/vmalloc.c | 28
1 file changed, 12 insertions(+), 16 deletions(-)
diff --git a/mm/vmalloc.c b
Signed-off-by: Nicholas Piggin
---
mm/memory.c | 60 +++--
1 file changed, 44 insertions(+), 16 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index c39a13b09602..1d5f3093c249 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2260,13 +2260,20 @@
vmalloc_to_page returns NULL for addresses mapped by larger pages[*].
Whether or not a vmap is huge depends on the architecture details,
alignments, boot options, etc., which the caller can not be expected
to know. Therefore HUGE_VMAP is a regression for vmalloc_to_page.
This change teaches vmallo
Not tested on x86 or arm64, would appreciate a quick test there so I can
ask Andrew to put it in -mm. Other option is I can disable huge vmallocs
for them for the time being.
Since v2:
- Rebased on vmalloc cleanups, split series into simpler pieces.
- Fixed several compile errors and warnings
- Ke
On 24/03/20 10:54 am, Chris Packham wrote:
> Hi Christophe,
>
> On Wed, 2020-02-05 at 12:03 +, Christophe Leroy wrote:
>> [0.00] ioremap() called early from
>> find_legacy_serial_ports+0x3cc/0x474. Use early_ioremap() instead
>>
> I was just about to dig into this error message and fou
Hi,
On 8/9/20 3:58 PM, Finn Thain wrote:
> On Sun, 9 Aug 2020, Guenter Roeck wrote:
>
>> Hi,
>>
>> On Sun, Jun 28, 2020 at 02:23:12PM +1000, Finn Thain wrote:
>>> Poll the most recently polled device by default, rather than the lowest
>>> device address that happens to be enabled in autopoll_devs
On Sun, 9 Aug 2020, Guenter Roeck wrote:
> Hi,
>
> On Sun, Jun 28, 2020 at 02:23:12PM +1000, Finn Thain wrote:
> > The interrupt handler should be excluded when accessing the
> > autopoll_devs variable.
> >
>
> I am quite baffled by this patch. Other than adding an unnecessary lock
> / unlock
On Sun, 9 Aug 2020, Guenter Roeck wrote:
> Hi,
>
> On Sun, Jun 28, 2020 at 02:23:12PM +1000, Finn Thain wrote:
> > Poll the most recently polled device by default, rather than the lowest
> > device address that happens to be enabled in autopoll_devs. This improves
> > input latency. Re-use macii_
Hi,
On Sun, Jun 28, 2020 at 02:23:12PM +1000, Finn Thain wrote:
> The interrupt handler should be excluded when accessing the autopoll_devs
> variable.
>
I am quite baffled by this patch. Other than adding an unnecessary lock /
unlock sequence, accessing a variable (which is derived from another
Hi,
On Sun, Jun 28, 2020 at 02:23:12PM +1000, Finn Thain wrote:
> Poll the most recently polled device by default, rather than the lowest
> device address that happens to be enabled in autopoll_devs. This improves
> input latency. Re-use macii_queue_poll() rather than duplicate that logic.
> This
"Aneesh Kumar K.V" writes:
> On 8/8/20 2:15 AM, Nathan Lynch wrote:
>> "Aneesh Kumar K.V" writes:
>>> On 8/7/20 9:54 AM, Nathan Lynch wrote:
"Aneesh Kumar K.V" writes:
> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
> index e437a9ac4956..6c659aada55b 100644
> ---
On 8/9/20 8:04 PM, Aneesh Kumar K.V wrote:
On 8/9/20 7:42 PM, Christian Zigotzky wrote:
Hello,
The Nemo board (A-EON AmigaOne X1000) [1] doesn't start with the
latest Git kernel anymore after the commit "powerpc/book3s64/pkeys:
Simplify pkey disable branch" [2].
I bisected today [3].
Resul
On 8/9/20 7:42 PM, Christian Zigotzky wrote:
Hello,
The Nemo board (A-EON AmigaOne X1000) [1] doesn't start with the latest
Git kernel anymore after the commit "powerpc/book3s64/pkeys: Simplify
pkey disable branch" [2].
I bisected today [3].
Result: powerpc/book3s64/pkeys: Simplify pkey dis
On 8/8/20 2:15 AM, Nathan Lynch wrote:
"Aneesh Kumar K.V" writes:
On 8/7/20 9:54 AM, Nathan Lynch wrote:
"Aneesh Kumar K.V" writes:
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index e437a9ac4956..6c659aada55b 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@
Hello,
The Nemo board (A-EON AmigaOne X1000) [1] doesn't start with the latest
Git kernel anymore after the commit "powerpc/book3s64/pkeys: Simplify
pkey disable branch" [2].
I bisected today [3].
Result: powerpc/book3s64/pkeys: Simplify pkey disable branch
(a4678d4b477c3d2901f101986ca01406
Hi all,
On Fri, 17 Jul 2020 19:09:31 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the set_fs tree got a conflict in:
>
> arch/powerpc/mm/numa.c
>
> between commit:
>
> c30f931e891e ("powerpc/numa: remove ability to enable topology updates")
>
> from the powerpc tree and
25 matches
Mail list logo
