pages get destroyed
> while they are isolated -- and instead delaying that to the
> putback/migration call. Add a TODO for that.
>
> Reviewed-by: Harry Yoo
> Reviewed-by: Lorenzo Stoakes
> Signed-off-by: David Hildenbrand
Reviewed-by: Sergey Senozhatsky
On (25/07/03 09:45), David Hildenbrand wrote:
> Not sure if there is real value for that; given the review status, I assume
> this series won't take too long to be ready for upstream. Of course, if that
> is not the case we could try pulling them out.
Sounds good to me.
On (25/07/03 11:28), Sergey Senozhatsky wrote:
> > > > > >static int zs_page_migrate(struct page *newpage, struct page
> > > > > > *page,
> > > > > > @@ -1736,6 +1736,13 @@ static int zs_page_migrate(struct page
> > > > >
On (25/07/02 12:55), David Hildenbrand wrote:
> On 02.07.25 12:10, Sergey Senozhatsky wrote:
> > On (25/07/02 10:25), David Hildenbrand wrote:
> > > On 02.07.25 10:11, Sergey Senozhatsky wrote:
> > > > On (25/06/30 14:59), David Hildenbrand wrote:
> &
On (25/07/02 10:25), David Hildenbrand wrote:
> On 02.07.25 10:11, Sergey Senozhatsky wrote:
> > On (25/06/30 14:59), David Hildenbrand wrote:
> > [..]
> > > static int zs_page_migrate(struct page *newpage, struct page *page,
> > > @@ -1736,6 +1736,13 @@ stati
On (25/06/30 14:59), David Hildenbrand wrote:
[..]
> static int zs_page_migrate(struct page *newpage, struct page *page,
> @@ -1736,6 +1736,13 @@ static int zs_page_migrate(struct page *newpage,
> struct page *page,
> unsigned long old_obj, new_obj;
> unsigned int obj_idx;
>
> +
On (25/06/18 19:39), David Hildenbrand wrote:
> Let the buddy handle clearing the type.
>
> Signed-off-by: David Hildenbrand
FWIW,
Reviewed-by: Sergey Senozhatsky
On (25/06/18 19:39), David Hildenbrand wrote:
> Let's drop these checks; these are conditions the core migration code
> must make sure will hold either way, no need to double check.
>
> Signed-off-by: David Hildenbrand
Reviewed-by: Sergey Senozhatsky
Hi,
On (25/05/06 11:09), Misbah Anjum N wrote:
> I am facing this issue even with the latest kernel: 6.15.0-rc4-g5721cf0b9352
> The suspecting commit is: 44f76413496ec343da0d8292ceecdcabe3e6ec16. The
> commit introduces zs_obj_write() function.
> Link:
> https://github.com/torvalds/linux/commit/4
)")
> Cc: "James E.J. Bottomley"
> Cc: Christophe Leroy
> Cc: Helge Deller
> Cc: Madhavan Srinivasan
> Cc: Michael Ellerman
> Cc: Naveen N Rao
> Cc: Nicholas Piggin
> Cc: Sergey Senozhatsky
> Cc: linux-par...@vger.kernel.org
> Cc: linuxppc-dev@lis
On (24/10/09 21:08), Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> Enable execmem's cache of PMD_SIZE'ed pages mapped as ROX for module
> text allocations.
>
With this modprobe disappoints kmemleak
[ 12.700128] kmemleak: Found object by alias at 0xa000a000
[ 12.70217
Hi,
On (24/09/23 11:06), Venkat Rao Bagalkote wrote:
> Hello,
>
> Below is the TC, I was running.
>
> https://github.com/avocado-framework-tests/avocado-misc-tests/blob/master/generic/ltp.py
Out of curiosity, does this [1] patch fix the issue for you?
[1]
https://lore.kernel.org/all/202409230
Hi,
On (24/09/22 22:23), Venkat Rao Bagalkote wrote:
> Greetings!!!
>
> I am observing Kernel OOPs on PowerPC system, while running LTP Test case.
>
> [11472.962838] BUG: Unable to handle kernel data access on read at
> 0xc00c02013d88
> [11472.962846] Faulting instruction address: 0xc000
On (24/06/07 10:40), Nhat Pham wrote:
> Personally, I'm not super convinced about class locks. We're
> essentially relying on the post-compression size of the data to
> load-balance the queries - I can imagine a scenario where a workload
> has a concentrated distribution of post-compression data (i
On (24/06/06 12:46), Chengming Zhou wrote:
> >> Agree, I think we should try to improve locking scalability of zsmalloc.
> >> I have some thoughts to share, no code or test data yet:
> >>
> >> 1. First, we can change the pool global lock to per-class lock, which
> >>is more fine-grained.
> >
>
On (24/06/06 10:49), Chengming Zhou wrote:
> > Thanks for trying this out. This is interesting, so even two zpools is
> > too much fragmentation for your use case.
> >
> > I think there are multiple ways to go forward here:
> > (a) Make the number of zpools a config option, leave the default as
>
On (24/01/15 08:47), Yosry Ahmed wrote:
> > At this point I NACK this patch. We're about to submit an allocator
> > which is clearly better that z3fold and is faster that zsmalloc in
> > most cases and that submission will mark z3fold as deprecated. But for
> > now this move is premature.
>
> I thi
case.
>
> Signed-off-by: Peter Zijlstra (Intel)
> Reviewed-by: Sergey Senozhatsky
> Acked-by: Petr Mladek
Acked-by: Sergey Senozhatsky
un 9, 2022 at 10:02 PM Petr Mladek wrote:
>
> On Thu 2022-06-09 20:30:58, Sergey Senozhatsky wrote:
> > My emails are getting rejected... Let me try web-interface
>
> Bad day for mail sending. I have problems as well ;-)
For me the problem is still there and apparently it'
un 9, 2022 at 10:06 PM Petr Mladek wrote:
>
> Makes sense. Feel free to use for this patch:
>
> Acked-by: Petr Mladek
Reviewed-by: Sergey Senozhatsky
e>, ulli.kr...@googlemail.com, vgu...@kernel.org, linux-...@vger.kernel.org,
j...@joshtriplett.org, rost...@goodmis.org, r...@vger.kernel.org,
b...@alien8.de, bc...@quicinc.com, tsbog...@alpha.franken.de,
linux-par...@vger.kernel.org, sudeep.ho...@arm.com, shawn...@kernel.org,
da...@davemloft.n
On (21/08/05 17:47), Petr Mladek wrote:
[..]
> 3. After introducing console kthread(s):
>
> int printk(...)
> {
> vprintk_store();
> wake_consoles_via_irqwork();
> }
>
> + in panic:
>
> + with atomic console like after this patchset?
On (21/04/01 16:17), Petr Mladek wrote:
> > For the long term, we should introduce a printk-context API that allows
> > callers to perfectly pack their multi-line output into a single
> > entry. We discussed [0][1] this back in August 2020.
>
> We need a "short" term solution. There are currently
On (21/03/17 00:33), John Ogness wrote:
[..]
> void printk_nmi_direct_enter(void)
> {
> @@ -324,27 +44,8 @@ void printk_nmi_direct_exit(void)
> this_cpu_and(printk_context, ~PRINTK_NMI_DIRECT_CONTEXT_MASK);
> }
>
> -#else
> -
> -static __printf(1, 0) int vprintk_nmi(const char *fmt, va_l
Use the 'common' foo_console_setup() naming scheme. There are 71
foo_console_setup() callbacks and only one foo_setup_console().
Signed-off-by: Sergey Senozhatsky
Cc: Andy Shevchenko
Cc: Steven Rostedt
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
---
drivers/tty/hvc/hvc_xen.c | 4 ++
On (20/04/09 10:08), Minchan Kim wrote:
> > > Even though I don't know how many usecase we have using zsmalloc as
> > > module(I heard only once by dumb reason), it could affect existing
> > > users. Thus, please include concrete explanation in the patch to
> > > justify when the complain occurs.
>
On (19/11/13 10:39), Steven Rostedt wrote:
[..]
> > void show_stack(struct task_struct *task, unsigned long *sp, int log_level)
> > {
> > printk_emergency_enter(log_level);
> > __show_stack(task, sp);
> > printk_emergency_exit();
> > }
> > // - - - - - - - - - - - - - - - - - - - - - -
On (19/11/13 16:40), Dmitry Safonov wrote:
> It's also not very fun for me to create those patches.
> But they fix console_loglevel issues (I hope we could un-export it in
> the end) and also I need it for my other patches those will produce
> warnings with debug loglevel when configured through sy
On (19/11/13 02:25), Dmitry Safonov wrote:
> I guess I've pointed that in my point of view price for one-time testing
> code is cheaper than adding a new printk feature to swap log levels on
> the fly.
[..]
> I've gone through functions used by sysrq driver and the same changes
> introducing log le
On (19/11/13 02:41), Dmitry Safonov wrote:
[..]
>
> I don't strongly disagree, but if you look at those results:
> git grep 'printk("%s.*", \(lvl\|level\)'
>
> it seems to be used in quite a few places.
Yes, you are right, it is used in some places. That's why I said
that I'd prefer to keep that
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 and clear.
>
> If
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 and clear.
If loglevel is DEFAULT or NOTICE or INFO then we can overwrite it
(either downgrade or upgrade)
On (19/11/12 13:44), Sergey Senozhatsky wrote:
[..]
> > But yes, this per-code-section loglevel is problematic. The feedback
> > against the patchset shows that people want it also the other way.
> > I mean to keep pr_debug() as pr_debug().
>
> Hmm. Right.
>
> &g
On (19/11/11 10:12), Petr Mladek wrote:
[..]
> > I do recall that we talked about per-CPU printk state bit which would
> > start/end "just print it" section. We probably can extend it to "just
> > log_store" type of functionality. Doesn't look like a very bad idea.
>
> The problem with per-CPU pri
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.
Well, there may be the need to pass loglevel deeper due to "hey __show_stack()
on that ar
On (19/11/11 19:47), Dmitry Safonov wrote:
[..]
> I don't see how bits on task_struct or in per-cpu are easier than
> supplying a log level parameter down the stack.
> How would it work if sysrq_handle_crash() called by key-press?
> How would that interact with deferred printing?
> How would it mak
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_struct for the normal context and in per-CPU
> variables for interrupt contex
On (19/11/06 09:35), Petr Mladek wrote:
> I agree with all the other justification.
>
> I would add. The backtrace is really useful for debugging. It should
> be possible to print it even in less critical situations.
Hmm, I don't know.
Do we really need debug/info level backtraces? May be all bac
On (05/14/19 21:13), Geert Uytterhoeven wrote:
> I would immediately understand there's a missing IS_ERR() check in a
> function that can return -EINVAL, without having to add a new printk()
> to find out what kind of bogus value has been received, and without
> having to reboot, and trying to rep
On (05/14/19 11:07), Sergey Senozhatsky wrote:
> How about this:
>
> if ptr < PAGE_SIZE -> "(null)"
No, this is totally stupid. Forget about it. Sorry.
> if IS_ERR_VALUE(ptr)-> "(fault)"
But Steven's "(fault)" is nice.
-ss
On (05/13/19 14:42), Petr Mladek wrote:
> > The "(null)" is good enough by itself and already an established
> > practice..
>
> (efault) made more sense with the probe_kernel_read() that
> checked wide range of addresses. Well, I still think that
> it makes sense to distinguish a pure NULL. And it
On (05/10/19 10:42), Petr Mladek wrote:
[..]
> Fixes: 3e5903eb9cff70730 ("vsprintf: Prevent crash when dereferencing invalid
> pointers")
> Signed-off-by: Petr Mladek
FWIW
Reviewed-by: Sergey Senozhatsky
-ss
On (05/10/19 10:06), Petr Mladek wrote:
[..]
> I am going to send a patch replacing probe_kernel_address() with
> a simple check:
>
> if ((unsigned long)ptr < PAGE_SIZE || IS_ERR_VALUE(ptr))
> return "(efault)";
I'm OK with this.
Probing ptrs was a good idea, it just didn't wo
On (05/09/19 21:47), Linus Torvalds wrote:
>[ Sorry about html and mobile crud, I'm not at the computer right now ]
>How about we just undo the whole misguided probe_kernel_address() thing?
But the problem will remain - %pS/%pF on PPC (and some other arch-s)
do dereference_function_descrip
On (05/09/19 14:19), Petr Mladek wrote:
> 1. Report on Power:
>
> Kernel crashes very early during boot with with CONFIG_PPC_KUAP and
> CONFIG_JUMP_LABEL_FEATURE_CHECK_DEBUG
>
> The problem is the combination of some new code called via printk(),
> check_pointer() which calls probe_kernel_read().
On (02/08/19 13:55), Steven Rostedt wrote:
[..]
> > + if (len) {
> > + /*
> > +* Order the stores above in vsnprintf() vs the store of the
> > +* space below which joins the two strings. Note this doesn't
> > +* make the code truly race free because t
real objections; dump_stack_add_arch_desc() can do.
FWIW,
Reviewed-by: Sergey Senozhatsky
-ss
Use a CONSOLE_LOGLEVEL_DEBUG macro for console_loglevel rather
than a naked number.
Signed-off-by: Sergey Senozhatsky
---
arch/powerpc/kernel/udbg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/udbg.c b/arch/powerpc/kernel/udbg.c
index 7cc38b5b58bc
trace_initcall_start(call);
> + ret = call();
> + trace_initcall_finish(call, ret);
> + ce++;
> }
> }
printk bits look OK to me.
The patch set works fine on my x86_64 and does reduce the size of vmlinux.
Acked-by: Sergey Senozhatsky
-ss
On (12/06/17 11:32), Petr Mladek wrote:
[..]
> > diff --git a/Documentation/printk-formats.txt
> > b/Documentation/printk-formats.txt
> > index aa0a776c817a..02745028e909 100644
> > --- a/Documentation/printk-formats.txt
> > +++ b/Documentation/printk-formats.txt
> > @@ -61,41 +61,31 @@ Symbols/Fu
Hello,
so we got a number of build-error reports [somehow I
thought 0day has compile tested the patches already; well, I
was wrong] basically on congifs that have no KALLSYMS.
Petr, can we replace 0006 with the following patch?
8<--- --- ---
From: Sergey Senozhatsky
Subject: [PA
On (11/28/17 16:47), Petr Mladek wrote:
> On Fri 2017-11-10 08:48:24, Sergey Senozhatsky wrote:
> > Hello,
> >
> > A reworked version. There is a new dereference_symbol_descriptor()
> > function now, where "the magic happens", so I
On (11/13/17 18:17), Helge Deller wrote:
> On 10.11.2017 00:48, Sergey Senozhatsky wrote:
> > All Ack-s/Tested-by-s were dropped, since the patch set has been
> > reworked. I'm kindly asking arch-s maintainers and developers to test it
> > once again. Sorry for any
On (11/13/17 12:41), Santosh Sivaraj wrote:
> * Sergey Senozhatsky wrote (on 2017-11-10
> 08:48:27 +0900):
>
> > We are moving towards separate kernel and module function descriptor
> > dereference callbacks. This patch enables it for powerpc64.
> >
> > For p
On (11/10/17 10:09), Luck, Tony wrote:
> On Fri, Nov 10, 2017 at 08:48:29AM +0900, Sergey Senozhatsky wrote:
> > -Examples::
> > -
> > - printk("Going to call: %pF\n", gettimeofday);
> > - printk("Going to call: %pF\n", p->func);
>
On (11/10/17 10:11), Luck, Tony wrote:
> On Fri, Nov 10, 2017 at 08:48:24AM +0900, Sergey Senozhatsky wrote:
> > All Ack-s/Tested-by-s were dropped, since the patch set has been
> > reworked. I'm kindly asking arch-s maintainers and developers to test it
> >
We deprecated '%pF/%pf' printk specifiers, since '%pS/%ps' is now smart
enough to handle function pointer dereference on platforms where such
dereference is required.
Signed-off-by: Sergey Senozhatsky
Signed-off-by: Joe Perches
Cc: Andy Whitcroft
Reviewed-by: Petr
t the pointer: if it belongs to .opd
section then we need to dereference it.
The kernel and modules have their own .opd sections, obviously,
that's why we need to split dereference_function_descriptor()
and use separate kernel and module dereference arch callbacks.
Signed-o
are within [module->opd.start, module->opd.end).
Signed-off-by: Sergey Senozhatsky
Signed-off-by: Helge Deller
---
arch/parisc/boot/compressed/vmlinux.lds.S | 2 ++
arch/parisc/include/asm/sections.h| 6 ++
arch/parisc/kernel/module.c | 16
are within [module->opd.start, module->opd.end).
Signed-off-by: Sergey Senozhatsky
---
arch/powerpc/include/asm/module.h | 3 +++
arch/powerpc/include/asm/sections.h | 12
arch/powerpc/kernel/module_64.c | 14 ++
arch/powerpc/kernel/vmlinux.lds.S | 2
within [module->opd.start, module->opd.end).
Signed-off-by: Sergey Senozhatsky
---
arch/ia64/include/asm/sections.h | 10 +-
arch/ia64/kernel/module.c| 12
arch/ia64/kernel/vmlinux.lds.S | 2 ++
3 files changed, 23 insertions(+), 1 deletion(-)
diff --git
test.
3) dereference_module_function_descriptor()
A function to call on modules' symbols that does modules' .opd
section address range test.
[1] https://marc.info/?l=linux-kernel&m=150472969730573
Signed-off-by: Sergey Senozhatsky
---
include/asm-generic/sections.h | 8 +
v2:
-- convert dereference_function_descriptor() to unsigned long
-- fix kernel descriptor range checks (Helge)
-- fix parisc module descriptor range check (Helge)
-- fix ppc64 module range check
-- add checkpatch patch
Sergey Senozhatsky (6):
sections: split dereference_function_descrip
On (11/02/17 15:11), Laurent Dufour wrote:
> On 26/10/2017 10:14, kemi wrote:
> > Some regression is found by LKP-tools(linux kernel performance) on this
> > patch series
> > tested on Intel 2s/4s Skylake platform.
> > The regression result is sorted by the metric will-it-scale.per_process_ops.
>
On (10/20/17 15:08), Petr Mladek wrote:
> On Thu 2017-10-19 15:42:35, Sergey Senozhatsky wrote:
> > Sorry for the delay and thanks for taking a look.
> >
> > I'll try to re-spin the patch set by the end of this week/early next
> > week.
> >
> >
Michael,
On (09/27/17 15:01), Michael Ellerman wrote:
> Sergey Senozhatsky writes:
>
> > On (09/22/17 16:48), Luck, Tony wrote:
> > [..]
> >> Tested patch series on ia64 successfully.
> >>
> >> Tested-by: Tony Luck
> >
> > thanks!
>
Hello,
Michael, sorry for the delay. I'm catching up with the emails
after... absence.
On (10/04/17 22:06), Michael Ellerman wrote:
> Petr Mladek writes:
> > On Sat 2017-09-30 11:53:16, Sergey Senozhatsky wrote:
> >> diff --git a/arch/powerpc/kernel/module_64.c
>
On (10/04/17 10:24), Petr Mladek wrote:
[..]
> To make it clear. All these comments are not a big deal and I do
> not want to invalidate all the acked-by and tested-by just because
> of them.
>
> But please, consider removing this change if we need to do
> another iteration of this patchset. IMHO,
On (10/04/17 11:00), Petr Mladek wrote:
[..]
> > /* random extra sections (if any). Override
> > diff --git a/include/linux/moduleloader.h b/include/linux/moduleloader.h
> > index 4d0cb9bba93e..172904e9cded 100644
> > --- a/include/linux/moduleloader.h
> > +++ b/include/linux/moduleloader.h
> > @
On (10/04/17 11:21), Petr Mladek wrote:
[..]
> > +#ifdef PPC64_ELF_ABI_v1
> > +unsigned long dereference_module_function_descriptor(struct module *mod,
> > +unsigned long addr)
> > +{
> > + if (addr < mod->arch.start_opd || addr >= mod->arch.end_opd
On (10/04/17 12:40), Petr Mladek wrote:
> > +unsigned long dereference_module_function_descriptor(struct module *mod,
> > +unsigned long addr)
> > +{
> > + unsigned long start_opd = (Elf64_Addr)mod->core_layout.base +
> > +
Sorry for the delay and thanks for taking a look.
I'll try to re-spin the patch set by the end of this week/early next
week.
On (10/04/17 13:53), Petr Mladek wrote:
[..]
> Note that kallsyms_lookup() and module_address_lookup() is used
> in many other situations.
we dereference only things that
We deprecated '%pF/%pf' printk specifiers, since '%pS/%ps' is now smart
enough to handle function pointer dereference on platforms where such
dereference is required.
checkpatch warning example:
WARNING: Deprecated vsprintf pointer extension '%pF' - use %pS
F/%pf' vsprintf handler, because it has the same behavior with
'%pS/%ps' now.
Signed-off-by: Sergey Senozhatsky
Tested-by: Helge Deller # parisc64
Tested-by: Santosh Sivaraj # powerpc64
Acked-by: Michael Ellerman # powerpc64
Tested-by: Tony Luck # ia64
---
Documentation/pri
are within [module->opd.start, module->opd.end].
Signed-off-by: Sergey Senozhatsky
Signed-off-by: Helge Deller
Tested-by: Helge Deller # parisc64
Tested-by: Santosh Sivaraj # powerpc64
Acked-by: Michael Ellerman # powerpc64
Tested-by: Tony Luck # ia64
---
arch/parisc/boot/comp
are within [module->opd.start, module->opd.end].
Signed-off-by: Sergey Senozhatsky
Tested-by: Helge Deller # parisc64
Tested-by: Santosh Sivaraj # powerpc64
Acked-by: Michael Ellerman # powerpc64
Tested-by: Tony Luck # ia64
---
arch/powerpc/include/asm/module.h | 3 +++
arch/p
within [module->opd.start, module->opd.end].
Signed-off-by: Sergey Senozhatsky
Tested-by: Helge Deller # parisc64
Tested-by: Santosh Sivaraj # powerpc64
Acked-by: Michael Ellerman # powerpc64
Tested-by: Tony Luck # ia64
---
arch/ia64/include/asm/sections.h | 10 +-
arch/ia64/
test.
3) dereference_module_function_descriptor()
A function to call on modules' symbols that does modules' .opd
section address range test.
[1] https://marc.info/?l=linux-kernel&m=150472969730573
Signed-off-by: Sergey Senozhatsky
Tested-by: Helge Deller # parisc64
Tested-by
unsigned long a = (unsigned long)dereference_function_descriptor(addr);
Convert dereference_function_descriptor() users tree-wide.
Signed-off-by: Sergey Senozhatsky
Tested-by: Helge Deller # parisc64
Tested-by: Santosh Sivaraj # powerpc64
Acked-by: Michael Ellerman # powerpc64
Tested-by: To
or range checks (Helge)
-- fix parisc module descriptor range check (Helge)
-- fix ppc64 module range check
-- add checkpatch patch
Sergey Senozhatsky (7):
switch dereference_function_descriptor() to `unsigned long'
sections: split dereference_function_descriptor()
ia64: Add .o
On (09/27/17 16:26), Michael Ellerman wrote:
[..]
> > Tested-by: Santosh Sivaraj
>
> Thanks Santosh.
>
> I also gave it a quick spin. I'll give you an ack for the powerpc changes.
>
> Acked-by: Michael Ellerman (powerpc)
>
>
> Thanks for cleaning this up Sergey.
thanks!
-ss
On (09/22/17 16:48), Luck, Tony wrote:
[..]
> Tested patch series on ia64 successfully.
>
> Tested-by: Tony Luck
thanks!
> After this goes upstream, you should submit a patch to get rid of
> all uses of %pF (70 instances in 35 files) and %pf (63 in 34)
>
> Perhaps break the patch by top-level
On (09/22/17 11:04), Santosh Sivaraj wrote:
[..]
> > *** A BIG NOTE ***
> > I don't own ia64/ppc64/parisc64 hardware, so the patches are not
> > tested. Sorry about that!
>
> Tested patch series on ppc64 sucessfully.
>
> You may add tested by to the series.
>
> Tested-by: Santosh
On (09/21/17 01:29), Sergey Senozhatsky wrote:
[..]
> + %pS versatile_init+0x0/0x110
> + %ps versatile_init
> %pF versatile_init+0x0/0x110
> %pf versatile_init
> - %pS versatile_init+0x0/0x110
> %pSRversat
On (09/20/17 11:24), Joe Perches wrote:
> On Wed, 2017-09-20 at 19:53 +0200, Helge Deller wrote:
[..]
> > Is it worth to mention, that it's still needed in older kernels?
> > Just in case some patch get's backported.
good question.
> I think probably not.
>
> There are relatively few references
On (09/20/17 22:14), Helge Deller wrote:
> On 20.09.2017 18:29, Sergey Senozhatsky wrote:
> > This patch set attempts to move ia64/ppc64/parisc64 C function
> > pointer ABI details out of printk() to arch code. Function dereference
> > code now checks if a pointer
On (09/20/17 10:38), Joe Perches wrote:
> On Thu, 2017-09-21 at 01:29 +0900, Sergey Senozhatsky wrote:
> > We deprecated '%pF/%pf' printk specifiers, since '%pS/%ps' is now smart
> > enough to handle function pointer dereference on platforms whe
On (09/21/17 01:29), Sergey Senozhatsky wrote:
> We deprecated '%pF/%pf' printk specifiers, since '%pS/%ps' is now smart
> enough to handle function pointer dereference on platforms where such
> dereference is required.
>
> checkpatch warning example:
>
On (09/20/17 12:20), Helge Deller wrote:
[..]
> > I've not looked at the specifics case...
> >
> > Another option is using a struct with a single member and
> > passing it by value.
>
> Actually, we do already have correct structs which could be referenced:
> parisc: struct Elf64_Fdesc
> ia64: st
We deprecated '%pF/%pf' printk specifiers, since '%pS/%ps' is now smart
enough to handle function pointer dereference on platforms where such
dereference is required.
checkpatch warning example:
WARNING: Use '%pS/%ps' instead. This pointer extension was deprecated
We deprecated '%pF/%pf' printk specifiers, since '%pS/%ps' is now smart
enough to handle function pointer dereference on platforms where such
dereference is required.
checkpatch warning example:
WARNING: Use '%pS/%ps' instead. This pointer extension was deprecated
F/%pf' vsprintf handler, because it has the same behavior with
'%pS/%ps' now.
Signed-off-by: Sergey Senozhatsky
---
Documentation/printk-formats.txt | 15 +--
kernel/kallsyms.c| 1 +
kernel/module.c | 1 +
lib/vsprintf.c
are within [module->opd.start, module->opd.end].
Signed-off-by: Sergey Senozhatsky
Signed-off-by: Helge Deller
---
arch/parisc/boot/compressed/vmlinux.lds.S | 2 ++
arch/parisc/include/asm/sections.h| 2 ++
arch/parisc/kernel/module.c | 17 +
arch/
are within [module->opd.start, module->opd.end].
Signed-off-by: Sergey Senozhatsky
---
arch/powerpc/include/asm/module.h | 3 +++
arch/powerpc/include/asm/sections.h | 11 +++
arch/powerpc/kernel/module_64.c | 16
arch/powerpc/kernel/vmlinux.lds.S | 2
within [module->opd.start, module->opd.end].
Signed-off-by: Sergey Senozhatsky
---
arch/ia64/include/asm/sections.h | 10 +-
arch/ia64/kernel/module.c| 13 +
arch/ia64/kernel/vmlinux.lds.S | 2 ++
3 files changed, 24 insertions(+), 1 deletion(-)
diff --git
test.
3) dereference_module_function_descriptor()
A function to call on modules' symbols that does modules' .opd
section address range test.
[1] https://marc.info/?l=linux-kernel&m=150472969730573
Signed-off-by: Sergey Senozhatsky
---
include/asm-generic/sections.h | 8 ++
unsigned long a = (unsigned long)dereference_function_descriptor(addr);
Convert dereference_function_descriptor() users tree-wide.
Signed-off-by: Sergey Senozhatsky
---
arch/ia64/include/asm/sections.h| 6 +++---
arch/parisc/include/asm/sections.h | 2 +-
arch/parisc/kernel/proce
to unsigned long
-- fix kernel descriptor range checks (Helge)
-- fix parisc module descriptor range check (Helge)
-- fix ppc64 module range check
-- add checkpatch patch
Sergey Senozhatsky (7):
switch dereference_function_descriptor() to `unsigned long'
sections: split dereference_function
On (09/20/17 11:51), Michael Ellerman wrote:
[..]
> > unlike ppc_function_entry(), printk() can get called on any symbol,
> > not just function pointers.
> >
> > for example,
> >
> > cat /proc/kallsyms | grep shrinker_rwsem
> > 81a4b1e0 d shrinker_rwsem
>
> Yep, good point. So your patch i
On (09/19/17 22:03), Helge Deller wrote:
[..]
> Your implementation of dereference_module_function_descriptor() in
> arch/parisc/kernel/module.c is faulty.
> mod->arch.fdesc_offset is relative to the base address of the module,
> so you need to add to mod->core_layout.base.
aha, got it. I should h
1 - 100 of 136 matches
Mail list logo
