On Sat, Oct 31 2020 at 00:26, Thomas Gleixner wrote:
> On Fri, Oct 30 2020 at 15:46, Linus Torvalds wrote:
>> On Fri, Oct 30, 2020 at 3:26 PM Thomas Gleixner wrote:
>> To me, your patch series has two big advantages:
>>
>> - more common code
>>
>> - kmap_local() becomes more of a no-op
>>
>> an
On Fri, Oct 30 2020 at 15:46, Linus Torvalds wrote:
> On Fri, Oct 30, 2020 at 3:26 PM Thomas Gleixner wrote:
> To me, your patch series has two big advantages:
>
> - more common code
>
> - kmap_local() becomes more of a no-op
>
> and the last thing we want is to expand on kmap.
Happy to go with
On Fri, Oct 30, 2020 at 3:26 PM Thomas Gleixner wrote:
>
> While at it I might have a look at that debug request from Willy in the
> other end of this thread. Any comment on that?
>
> https://lore.kernel.org/r/87k0v7mrrd@nanos.tec.linutronix.de
I do think that it would be nice to have a debu
On Fri, Oct 30 2020 at 13:28, Linus Torvalds wrote:
> On Fri, Oct 30, 2020 at 2:39 AM Thomas Gleixner wrote:
>>
>> But then we really should not name it kmap_local. 'local' suggests
>> locality, think local_irq*, local_bh* ... kmap_task would be more
>> accurate then.
>
> So the main reason I'd li
On 10/30/20 2:08 PM, Vineet Gupta wrote:
> On 10/30/20 11:53 AM, Jens Axboe wrote:
>>
>> Ah thanks, I'll make that change. Hard for me to test a lot of these, so
>> I really appreciate someone knowledgable taking a look at it.
>
> Sure, glad to help, thx to you for writing the arch patches in firs
On Fri, Oct 30, 2020 at 2:39 AM Thomas Gleixner wrote:
>
> But then we really should not name it kmap_local. 'local' suggests
> locality, think local_irq*, local_bh* ... kmap_task would be more
> accurate then.
So the main reason I'd like to see it is because I think on a
non-highmem machine, the
On 10/30/20 11:53 AM, Jens Axboe wrote:
>
> Ah thanks, I'll make that change. Hard for me to test a lot of these, so
> I really appreciate someone knowledgable taking a look at it.
Sure, glad to help, thx to you for writing the arch patches in first
place. It takes a bit of daring to venture in u
On Fri, Oct 30 2020 at 13:06, Matthew Wilcox wrote:
> On Thu, Oct 29, 2020 at 11:18:06PM +0100, Thomas Gleixner wrote:
>> This series provides kmap_local.* iomap_local variants which only disable
>> migration to keep the virtual mapping address stable accross preemption,
>> but do neither disable p
On 10/30/20 12:47 PM, Vineet Gupta wrote:
> On 10/29/20 9:09 AM, Jens Axboe wrote:
>> Wire up TIF_NOTIFY_SIGNAL handling for arc.
>>
>> Cc:linux-arm-ker...@lists.infradead.org
>
>
> Just to be clear, ARC and ARM seem to differ in 1 letter, they are in no
> way related :-)
Oops, fat fingered tha
Hi Naresh,
On 10/30/20 3:29 AM, Naresh Kamboju wrote:
> arc defconfig build failed on linux next 20201030 with gcc-8 and gcc-9.
>
> make -sk KBUILD_BUILD_USER=TuxBuild -C/linux -j16 ARCH=arc
> CROSS_COMPILE=arc-elf32- HOSTCC=gcc CC="sccache arc-elf32-gcc" O=build
> uImage
On 10/30/20 12:53 PM, Vineet Gupta wrote:
> Hi Naresh,
>
> On 10/30/20 3:29 AM, Naresh Kamboju wrote:
>> arc defconfig build failed on linux next 20201030 with gcc-8 and gcc-9.
>>
>> make -sk KBUILD_BUILD_USER=TuxBuild -C/linux -j16 ARCH=arc
>> CROSS_COMPILE=arc-
On 10/29/20 9:09 AM, Jens Axboe wrote:
> Wire up TIF_NOTIFY_SIGNAL handling for arc.
>
> Cc:linux-arm-ker...@lists.infradead.org
Just to be clear, ARC and ARM seem to differ in 1 letter, they are in no
way related :-)
> Signed-off-by: Jens Axboe
> ---
>
> 5.11 has support queued up for TIF_NOT
On Thu, Oct 29, 2020 at 11:18:06PM +0100, Thomas Gleixner wrote:
> This series provides kmap_local.* iomap_local variants which only disable
> migration to keep the virtual mapping address stable accross preemption,
> but do neither disable pagefaults nor preemption. The new functions can be
> used
arc defconfig build failed on linux next 20201030 with gcc-8 and gcc-9.
make -sk KBUILD_BUILD_USER=TuxBuild -C/linux -j16 ARCH=arc
CROSS_COMPILE=arc-elf32- HOSTCC=gcc CC="sccache arc-elf32-gcc" O=build
uImage
#
../arch/arc/kernel/entry.S: Assembler messages:
../arch/arc/kernel/entry.S:
On Fri, Oct 30 2020 at 00:41, Thomas Gleixner wrote:
> On Thu, Oct 29 2020 at 16:11, Linus Torvalds wrote:
> No, you're not misreading it, but doing it conditionally would be a
> complete semantical disaster. kmap_atomic*() also disables preemption
> and pagefaults unconditionaly. If that wouldn't
On Fri, Oct 30 2020 at 08:25, Christoph Hellwig wrote:
> On Thu, Oct 29, 2020 at 11:18:06PM +0100, Thomas Gleixner wrote:
>> - Consolidating all kmap atomic implementations in generic code
>
> I think the consolidation is a winner no matter where we go next. Maybe
> split it out in a prep series
On Thu, Oct 29, 2020 at 11:18:06PM +0100, Thomas Gleixner wrote:
> This is achieved by:
...
>
> - Consolidating all kmap atomic implementations in generic code
...
> Though I wanted to share the current state of affairs before investigating
> that further. If there is consensus in going forwa
17 matches
Mail list logo
