Subject: Re: [PATCH 00/14] Fix wrong %pF and %pS printk format specifier
 usages
To: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
Cc: "Luck, Tony" <tony.luck@intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
        Petr Mladek <pmladek@suse.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        "Yu, Fenghua" <fenghua.yu@intel.com>,
        Benjamin Herrenschmidt <benh@kernel.crashing.org>,
        Paul Mackerras <paulus@samba.org>,
        Michael Ellerman <mpe@ellerman.id.au>
References: <20170907083207.GC533@jagdpanzerIV.localdomain>
 <667b8849-fb60-a312-2483-505252ff737e@gmx.de>
 <20170907093631.GD533@jagdpanzerIV.localdomain>
 <20170907095119.GE533@jagdpanzerIV.localdomain>
 <0604f27e-24ab-625b-9013-c6c0f4f6acc1@gmx.de>
 <3908561D78D1C84285E8C5FCA982C28F6136C2ED@ORSMSX114.amr.corp.intel.com>
 <20170908061830.GA496@jagdpanzerIV.localdomain>
 <20170908172528.qc2vdtxzqh777k6o@intel.com>
 <67a0aad8-5412-60f8-6481-562d37995eb2@gmx.de>
 <20170914074044.GE599@jagdpanzerIV.localdomain>
 <20170914080302.GF599@jagdpanzerIV.localdomain>
From: Helge Deller <deller@gmx.de>
Message-ID: <404e94ca-36b3-8ea2-8ccc-e4a261b38416@gmx.de>
Date: Thu, 14 Sep 2017 10:39:03 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170914080302.GF599@jagdpanzerIV.localdomain>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2837
Lines: 83

On 14.09.2017 10:03, Sergey Senozhatsky wrote:
> On (09/14/17 16:40), Sergey Senozhatsky wrote:
> [..]
>> powerpc and parisc handle kernel .opd section as well:
>>
>> arch/powerpc/kernel/vmlinux.lds.S:      .opd
>> arch/parisc/kernel/vmlinux.lds.S:       .opd
> 
> for modules, arch-s define mod_arch_specific struct.
> 
> parisc has .opd
> 
> (fdesc offset should be the start of .opd,
>   fdesc_offset + sizeof(fdesc) * fdesc_count should be the .opd address range)
> 
> struct mod_arch_specific
> {
>          unsigned long got_offset, got_count, got_max;
>          unsigned long fdesc_offset, fdesc_count, fdesc_max;
>          struct {
>                  unsigned long stub_offset;
>                  unsigned int stub_entries;
>                  } *section;
>          int unwind_section;
>          struct unwind_table *unwind;
> };
> 
> 
> ia64 has .opd
> 
> struct mod_arch_specific {
>          struct elf64_shdr *core_plt;    /* core PLT section */
>          struct elf64_shdr *init_plt;    /* init PLT section */
>          struct elf64_shdr *got;         /* global offset table */
>          struct elf64_shdr *opd;         /* official procedure descriptors */
>          struct elf64_shdr *unwind;      /* unwind-table section */
>          unsigned long gp;               /* global-pointer for module */
> 
>          void *core_unw_table;           /* core unwind-table cookie returned by unwinder */
>          void *init_unw_table;           /* init unwind-table cookie returned by unwinder */
>          unsigned int next_got_entry;    /* index of next available got entry */
> };
> 
> 
> powerpc does not keep track of .opd, need to add
> 
> struct mod_arch_specific {
> #ifdef __powerpc64__
>          unsigned int stubs_section;     /* Index of stubs section in module */
>          unsigned int toc_section;       /* What section is the TOC? */
>          bool toc_fixed;                 /* Have we fixed up .TOC.? */
> #ifdef CONFIG_DYNAMIC_FTRACE
>          unsigned long toc;
>          unsigned long tramp;
> #endif
> 
> #else /* powerpc64 */
>          /* Indices of PLT sections within module. */
>          unsigned int core_plt_section;
>          unsigned int init_plt_section;
> #ifdef CONFIG_DYNAMIC_FTRACE
>          unsigned long tramp;
> #endif
> #endif /* powerpc64 */
> 
>          /* List of BUG addresses, source line numbers and filenames */
>          struct list_head bug_list;
>          struct bug_entry *bug_table;
>          unsigned int num_bugs;
> };
> 
> 
> seems like we are looking at a solution here.
> 
> thoughts?

The basic concept of your proposal may work, and since it will avoid such
coding issues in the future I think it's probably the best solution.

Will you come up with a patch ? (I won't have time the next few days).
If yes,I'd be happy to test it on parisc.

Helge