logical: if one can switch between modes,
why can't he change vdso mapping to mode he got to?
(note: if the work about removing thread compatible flags
will be done (on x86), there will not even be such a thing,
as application mode - just difference on which syscalls it
uses: compatible
ected.
Tested on qemu with buildroot rootfs.
Dmitry Safonov (7):
powerpc/vdso: unify return paths in setup_additional_pages
powerpc/vdso: remove unused params in vdso_do_func_patch{32,64}
powerpc/vdso: separate common code in vdso_common
powerpc/vdso: introduce init_vdso{32,64}_pagelist
po
Impact: cleanup
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Andy Lutomirski
Cc: Oleg Nesterov
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux...@kvack.org
Signed-off-by: Dmitry Safonov
---
arch/powerpc/kernel/vdso.c | 19 +++
1 file changed, 7
Impact: cleanup
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Andy Lutomirski
Cc: Oleg Nesterov
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux...@kvack.org
Signed-off-by: Dmitry Safonov
---
arch/powerpc/kernel/vdso.c | 11 +++
1 file changed, 3 insertions
k.org
Signed-off-by: Dmitry Safonov
---
arch/powerpc/kernel/vdso.c | 67 +-
1 file changed, 31 insertions(+), 36 deletions(-)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 25d03d773c49..e68601ffc9ad 100644
--- a/arch/powerpc/k
This will allow to introduce mremap hook (the next patch).
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Andy Lutomirski
Cc: Oleg Nesterov
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux...@kvack.org
Signed-off-by: Dmitry Safonov
---
arch/powerpc/kernel/vdso.c
renschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: "Kirill A. Shutemov"
Cc: Andy Lutomirski
Cc: Oleg Nesterov
Cc: Andrew Morton
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux...@kvack.org
Signed-off-by: Dmitry Safonov
---
arch/alpha/include/asm/Kbuild| 1
@kvack.org
Signed-off-by: Dmitry Safonov
---
arch/powerpc/kernel/vdso.c| 352 ++
arch/powerpc/kernel/vdso_common.c | 221
2 files changed, 234 insertions(+), 339 deletions(-)
create mode 100644 arch/powerpc/kernel/vdso_common.c
di
Common code with allocation/initialization of vDSO's pagelist.
Impact: cleanup
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Andy Lutomirski
Cc: Oleg Nesterov
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux...@kvack.org
Signed-off-by: Dmitry Safonov
---
arch/po
renschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: "Kirill A. Shutemov"
Cc: Andy Lutomirski
Cc: Oleg Nesterov
Cc: Andrew Morton
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux...@kvack.org
Signed-off-by: Dmitry Safonov
---
v2: use vdso64_pages only under CONFIG_PPC64
qemu with buildroot rootfs.
Dmitry Safonov (8):
powerpc/vdso: unify return paths in setup_additional_pages
powerpc/vdso: remove unused params in vdso_do_func_patch{32,64}
powerpc/vdso: separate common code in vdso_common
powerpc/vdso: introduce init_vdso{32,64}_pagelist
powerpc/vdso:
ov
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux...@kvack.org
Signed-off-by: Dmitry Safonov
---
arch/powerpc/kernel/vdso.c | 19 +++
1 file changed, 7 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 4111d30badfa..4ffb82a2d9
linux...@kvack.org
Signed-off-by: Dmitry Safonov
---
arch/powerpc/kernel/vdso.c| 27 ++-
arch/powerpc/kernel/vdso_common.c | 22 ++
2 files changed, 24 insertions(+), 25 deletions(-)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/v
c: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Andy Lutomirski
Cc: Oleg Nesterov
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux...@kvack.org
Signed-off-by: Dmitry Safonov
---
arch/powerpc/kernel/vdso.c| 352 ++
arch/powerpc/k
nuxppc-dev@lists.ozlabs.org
Cc: linux...@kvack.org
Signed-off-by: Dmitry Safonov
---
arch/powerpc/kernel/vdso.c | 67 +-
1 file changed, 31 insertions(+), 36 deletions(-)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 25
v
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux...@kvack.org
Signed-off-by: Dmitry Safonov
---
arch/powerpc/kernel/vdso.c| 19 +++
arch/powerpc/kernel/vdso_common.c | 8 ++--
2 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/kernel/vdso.c b
: Dmitry Safonov
---
arch/powerpc/kernel/vdso.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 4ffb82a2d9e9..278b9aa25a1c 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -309,7
ing").
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: Andy Lutomirski
Cc: Oleg Nesterov
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux...@kvack.org
Signed-off-by: Dmitry Safonov
---
arch/powerpc/kernel/vdso.c | 20 +++-
1 file changed, 3 insertions(+), 17
x86.
Cc: Laurent Dufour
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: "Kirill A. Shutemov"
Cc: Andy Lutomirski
Cc: Oleg Nesterov
Cc: Andrew Morton
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux...@kvack.org
Signed-off-by: Dmitry Safonov
---
arch/alpha
2016-10-25 18:50 GMT+03:00 Dmitry Safonov :
> Cleanup patches for vDSO on powerpc.
> Originally, I wanted to add vDSO remapping on arm/aarch64 and
> I decided to cleanup that part on powerpc.
> I've add a hook for vm_ops for vDSO just like I did for x86.
> Other changes - re
2016-10-27 20:09 GMT+03:00 Dmitry Safonov :
> Changes since v1, v2:
> - use vdso64_pages only under CONFIG_PPC64 (32-bit build fix)
> - remove arch_vma_name helper as not needed anymore,
> simplify vdso_base pointer initializing in map_vdso()
>
> Cleanup patches for vDSO on pow
On 11/08/2016 03:10 AM, Michael Ellerman wrote:
Hi Dmitry,
Thanks for the patches.
Dmitry Safonov writes:
Impact: cleanup
I'm not a fan of these "Impact" lines, especially when they're not
correct, ie. this is not a cleanup, a cleanup doesn't change logic.
R
On 11/08/2016 02:57 AM, Michael Ellerman wrote:
Dmitry Safonov <0x7f454...@gmail.com> writes:
2016-10-27 20:09 GMT+03:00 Dmitry Safonov :
ping?
There's another series doing some similar changes:
http://www.spinics.net/lists/linux-mm/msg115860.html
Well, that version makes
only for CRIU, hide it under CHECKPOINT_RESTORE
config.
Hope those patches will help to clean task_size-related code
at least a bit (and helps me to restore vaddr limits).
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Andy Lutomirski
Cc: Kirill A. Shutemov
Cc: x...@kernel.org
D
radead.org
Cc: linux-m...@linux-mips.org
Cc: linux-par...@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-s...@vger.kernel.org
Cc: sparcli...@vger.kernel.org
Signed-off-by: Dmitry Safonov
---
arch/arm64/include/asm/memory.h | 2 --
arch/mips/include/asm/processor.h | 3 ---
: linuxppc-dev@lists.ozlabs.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-d...@arista.com/T/#u
Acked-by: Michael Ellerman (powerpc)
Signed-off-by: Dmitry Safonov
---
arch/powerpc/kernel/process.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a
com/T/#u
[2]:
https://lkml.kernel.org/r/41fd7652-df1f-26f6-aba0-b87ebae07...@i-love.sakura.ne.jp
Dmitry Safonov (50):
kallsyms/printk: Add loglvl to print_ip_sym()
alpha: Add show_stack_loglvl()
arc: Add show_stack_loglvl()
arm/asm: Add loglvl to c_backtrace()
arm: Add loglvl to unwind_backtra
02412.1625-1-d...@arista.com/T/#u
[2]:
https://lkml.kernel.org/r/41fd7652-df1f-26f6-aba0-b87ebae07...@i-love.sakura.ne.jp
Dmitry Safonov (50):
kallsyms/printk: Add loglvl to print_ip_sym()
alpha: Add show_stack_loglvl()
arc: Add show_stack_loglvl()
arm/asm: Add loglvl to c_backtrace()
: linuxppc-dev@lists.ozlabs.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-d...@arista.com/T/#u
Signed-off-by: Dmitry Safonov
---
arch/powerpc/kernel/process.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b/arch
On 11/6/19 9:52 AM, Michael Ellerman wrote:
> Dmitry Safonov writes:
>> Currently, the log-level of show_stack() depends on a platform
>> realization. It creates situations where the headers are printed with
>> lower log level or higher than the stacktrace (depending on
On 11/6/19 8:35 AM, Petr Mladek wrote:
> On Wed 2019-11-06 03:04:51, Dmitry Safonov wrote:
>> Add log level argument to show_stack().
>> Done in three stages:
>> 1. Introducing show_stack_loglvl() for every architecture
>> 2. Migrating old users with an explic
Hi Peter,
On 11/6/19 9:20 AM, Peter Zijlstra wrote:
> On Wed, Nov 06, 2019 at 03:04:51AM +0000, Dmitry Safonov wrote:
>> Add log level argument to show_stack().
>> Done in three stages:
>> 1. Introducing show_stack_loglvl() for every architecture
>> 2. Migrating old
On 11/6/19 8:34 PM, Peter Zijlstra wrote:
> On Wed, Nov 06, 2019 at 04:27:33PM +0000, Dmitry Safonov wrote:
[..]
>> Sorry, I should have tried to describe better.
>>
>> I'm trying to remove external users of console_loglevel by following
>> reasons:
>
> I sup
On 11/8/19 5:30 PM, Russell King - ARM Linux admin wrote:
> On Fri, Nov 08, 2019 at 04:28:30PM +0000, Dmitry Safonov wrote:
[..]
>>
>> Well, the use-case for lower log-level is that everything goes into logs
>> (/var/log/dmesg or /var/log/messages whatever rsyslog has sett
Hi Sergey, Petr,
On 11/11/19 1:23 AM, Sergey Senozhatsky wrote:
> On (19/11/08 14:04), Petr Mladek wrote:
> [..]
>> I agree that it is complicated to pass the loglevel as
>> a parameter. It would be better define the default
>> log level for a given code section. It might be stored
>> in task_stru
Hi Sergey,
On 11/12/19 2:17 AM, Sergey Senozhatsky wrote:
> On (19/11/11 19:47), Dmitry Safonov wrote:
[..]
>> What I'm going to do - is to fix all build and reported issues, I'll
>> send v2 this week and feel free to NAK it, I will forget about those
>> patches and
On 11/13/19 1:23 AM, Sergey Senozhatsky wrote:
> On (19/11/12 19:12), Sergey Senozhatsky wrote:
>> On (19/11/12 09:35), Petr Mladek wrote:
>> [..]
>>> This is getting too complicated. It would introduce too many
>>> hidden rules. While the explicitly passed loglevel parameter
>>> is straightforward
On 11/12/19 4:25 AM, Sergey Senozhatsky wrote:
> On (19/11/12 02:40), Dmitry Safonov wrote:
> [..]
>> In my point of view the cost of one-time [mostly build] testing every
>> architecture is cheaper than introducing some new smart code that will
>> live forever.
>
>
Hi Sergey,
On 11/13/19 6:33 AM, Sergey Senozhatsky wrote:
[..]
> Well, here we go. There is a number of generally useful functions that
> print nice data and where people might want to have better loglevel control
> (for debugging purposes). show_stack() is just one of them. Patching all
> those f
: linuxppc-dev@lists.ozlabs.org
[1]: https://lore.kernel.org/lkml/20190528002412.1625-1-d...@arista.com/T/#u
Acked-by: Michael Ellerman (powerpc)
Signed-off-by: Dmitry Safonov
---
arch/powerpc/kernel/process.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a
r/41fd7652-df1f-26f6-aba0-b87ebae07...@i-love.sakura.ne.jp
Dmitry Safonov (50):
kallsyms/printk: Add loglvl to print_ip_sym()
alpha: Add show_stack_loglvl()
arc: Add show_stack_loglvl()
arm/asm: Add loglvl to c_backtrace()
arm: Add loglvl to unwind_backtrace()
arm: Add loglvl to dump_ba
Cc: Jiri Slaby
Cc: Vasiliy Khoruzhick
Cc: linux-ser...@vger.kernel.org
Dmitry Safonov (58):
sysrq: Remove sysrq_handler_registered
serial: Move sysrq members above
serial_core: Un-ifdef sysrq SUPPORT_SYSRQ
tty/serial: Migrate aspeed_vuart to use has_sysrq
tty/serial: Migrate 8250_fsl t
has_sysrq variable has been added.
Initialise it in driver's probe and remove ifdeffery.
Cc: Benjamin Herrenschmidt
Cc: Paul Mackerras
Cc: Michael Ellerman
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Dmitry Safonov
---
arch/powerpc/kernel/legacy_serial.c | 4 +++-
drivers/tty/serial/8250/
has_sysrq variable has been added.
Initialise it in driver's probe and remove ifdeffery.
Cc: Benjamin Herrenschmidt
Cc: Michael Ellerman
Cc: Paul Mackerras
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Dmitry Safonov
---
drivers/tty/serial/pmac_zilog.c | 5 +
1 file changed, 1 insertion(
ucc_uart doesn't seem to support console over itself, so maybe it can
be deleted with uart_handle_sysrq_char() from the file.
Cc: Timur Tabi
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Dmitry Safonov
---
drivers/tty/serial/ucc_uart.c | 2 --
1 file changed, 2 deletions(-)
diff --
Hi Christophe,
On 12/13/19 5:47 AM, Christophe Leroy wrote:
> Le 13/12/2019 à 01:05, Dmitry Safonov a écrit :
[..]
>
> powerpc patchwork didn't get the full series, see
> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=148198
Yes, I was under impression that
y: kbuild test robot
Signed-off-by: Dmitry Safonov
---
It's probably better to squash this into the 8250_fsl patch.
I've added Fixes tag in case the branch won't be rebased.
Tested powerpc build manually with ppc64 cross-compiler.
drivers/tty/serial/8250/8250_core.c | 1 +
incl
Hello,
On 3/26/21 10:50 AM, Christophe Leroy wrote:
>
>
> Le 26/03/2021 à 11:46, Michael Ellerman a écrit :
>> Laurent Dufour writes:
>>> Le 25/03/2021 à 17:56, Laurent Dufour a écrit :
Le 25/03/2021 à 17:46, Christophe Leroy a écrit :
> Le 25/03/2021 à 17:11, Laurent Dufour a écrit :
On 3/26/21 4:11 PM, Christophe Leroy wrote:
[..]
>>>
>>> Dmitry proposed the same, see
>>> https://github.com/0x7f454c46/linux/commit/783c7a2532d2219edbcf555cc540eab05f698d2a
>>>
>>>
>>>
>>> Discussion at https://github.com/checkpoint-restore/criu/issues/1417
>>
>> Yeah, I didn't submit it official
On 3/26/21 5:07 PM, Christophe Leroy wrote:
> No, the problem is that user access has to be allowed for the flush()
>
> A hacky solution would be to call user_access_begin() , will test that
> later
Yeah, cool.
Will it be fine if I send the vvar patch with your Tested-by?
Thanks,
Dm
On 3/26/21 6:40 PM, Christophe Leroy wrote:
>
>
> Le 26/03/2021 à 18:11, Dmitry Safonov a écrit :
>> On 3/26/21 5:07 PM, Christophe Leroy wrote:
>>> No, the problem is that user access has to be allowed for the flush()
>>>
>>> A hacky solution would
ode. Thanks!
>>
>> Cc: Andrei Vagin
>> Cc: Andy Lutomirski
>> Cc: Benjamin Herrenschmidt
>> Cc: Christophe Leroy
>> Cc: Laurent Dufour
>> Cc: Michael Ellerman
>> Cc: Paul Mackerras
>> Cc: linuxppc-dev@lists.ozlabs.org
>> Cc: sta...@v
On 3/29/21 4:14 PM, Laurent Dufour wrote:
> Le 26/03/2021 à 20:17, Dmitry Safonov a écrit :
>> Since commit 511157ab641e ("powerpc/vdso: Move vdso datapage up front")
>> VVAR page is in front of the VDSO area. In result it breaks CRIU
>> (Checkpoint Restore In Use
On 3/30/21 11:17 AM, Christophe Leroy wrote:
>
>
> Le 26/03/2021 à 20:17, Dmitry Safonov a écrit :
[..]
>> --- a/arch/powerpc/kernel/vdso.c
>> +++ b/arch/powerpc/kernel/vdso.c
>> @@ -55,10 +55,10 @@ static int vdso_mremap(const struct
>> vm_special_
On 3/31/21 10:59 AM, Michael Ellerman wrote:
> Christophe Leroy writes:
[..]
>>
>>> @@ -133,7 +135,13 @@ static int __arch_setup_additional_pages(struct
>>> linux_binprm *bprm, int uses_int
>>> * install_special_mapping or the perf counter mmap tracking code
>>> * will fail to recognise
Hello,
On Wed, 26 Aug 2020 at 15:39, Michael Ellerman wrote:
> Christophe Leroy writes:
[..]
> > arch_remap() gets replaced by vdso_remap()
> >
> > For arch_unmap(), I'm wondering how/what other architectures do, because
> > powerpc seems to be the only one to erase the vdso context pointer when
On 9/27/20 8:43 AM, Christophe Leroy wrote:
>
>
> Le 21/09/2020 à 13:26, Will Deacon a écrit :
>> On Fri, Aug 28, 2020 at 12:14:28PM +1000, Michael Ellerman wrote:
>>> Dmitry Safonov <0x7f454...@gmail.com> writes:
[..]
>>>> I'll cook a
Hi Christophe, Will,
On 10/23/20 12:57 PM, Christophe Leroy wrote:
>
>
> Le 23/10/2020 à 13:25, Will Deacon a écrit :
>> On Fri, Oct 23, 2020 at 01:22:04PM +0200, Christophe Leroy wrote:
>>> Hi Dmitry,
[..]
>>> I haven't seen the patches, did you sent them out finally ?
I was working on .close(
Hi Laurent, Christophe, Michael, all,
On 11/3/20 5:11 PM, Laurent Dufour wrote:
> Le 23/10/2020 à 14:28, Christophe Leroy a écrit :
[..]
That seems like it would work for CRIU and make sense in general?
>>>
>>> Sorry for the late answer, yes this would make more sense.
>>>
>>> Here is a patch
Hi Liam,
On Wed, Jul 10, 2024 at 5:09 PM Liam R. Howlett wrote:
>
> * LEROY Christophe [240710 08:59]:
> >
> ...
> >
> > Assuming the removal of the vdso does not cause the application to seg
> > fault, then the user visible change is that any vdso call after a
> > failed
>
60 matches
Mail list logo
