Commit 28e1745b9fa2 ("printk: rename vprintk_func to vprintk") while
improving readability by removing vprintk indirection, inadvertently
placed the EXPORT_SYMBOL() for the newly renamed function at the end
of the file.
For reader sanity, and as is convention move the EXPORT_SYMBOL()
declaration just after the end of the function.
Fixes: 28e1745b9fa2 ("printk: rename vprintk_func to vprintk")
Signed-off-by: Punit Agrawal <[email protected]>
--
Hi,
The out-of-place EXPORT_SYMBOL() caused an unexpected conflict while
attempting to rebase the RT patches onto newer kernels.
Generally I avoid sending trivial changes on their own but this one is
a little hard to overlook. Also it felt like an obvious oversight in
the original patch.
Please consider merging.
Thanks,
Punit
---
kernel/printk/printk_safe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/printk/printk_safe.c b/kernel/printk/printk_safe.c
index 7a1414622051..94232186fccb 100644
--- a/kernel/printk/printk_safe.c
+++ b/kernel/printk/printk_safe.c
@@ -391,6 +391,7 @@ asmlinkage int vprintk(const char *fmt, va_list args)
/* No obstacles. */
return vprintk_default(fmt, args);
}
+EXPORT_SYMBOL(vprintk);
void __init printk_safe_init(void)
{
@@ -411,4 +412,3 @@ void __init printk_safe_init(void)
/* Flush pending messages that did not have scheduled IRQ works. */
printk_safe_flush();
}
-EXPORT_SYMBOL(vprintk);
--
2.30.2
On 15/06/2021 01.56, Punit Agrawal wrote:
> Commit 28e1745b9fa2 ("printk: rename vprintk_func to vprintk") while
> improving readability by removing vprintk indirection, inadvertently
> placed the EXPORT_SYMBOL() for the newly renamed function at the end
> of the file.
>
> For reader sanity, and as is convention move the EXPORT_SYMBOL()
> declaration just after the end of the function.
>
> Fixes: 28e1745b9fa2 ("printk: rename vprintk_func to vprintk")
> Signed-off-by: Punit Agrawal <[email protected]>
> --
> Hi,
>
> The out-of-place EXPORT_SYMBOL() caused an unexpected conflict while
> attempting to rebase the RT patches onto newer kernels.
>
> Generally I avoid sending trivial changes on their own but this one is
> a little hard to overlook. Also it felt like an obvious oversight in
> the original patch.
Yes, indeed, sorry about that, and thanks for fixing it.
> Please consider merging.
Petr, as this is causing trouble for the -rt patchset, please consider
if this could make it to Linus before v5.13 release.
Acked-by: Rasmus Villemoes <[email protected]>
Rasmus
Hi Rasmus,
Rasmus Villemoes <[email protected]> writes:
> On 15/06/2021 01.56, Punit Agrawal wrote:
>> Commit 28e1745b9fa2 ("printk: rename vprintk_func to vprintk") while
>> improving readability by removing vprintk indirection, inadvertently
>> placed the EXPORT_SYMBOL() for the newly renamed function at the end
>> of the file.
>>
>> For reader sanity, and as is convention move the EXPORT_SYMBOL()
>> declaration just after the end of the function.
>>
>> Fixes: 28e1745b9fa2 ("printk: rename vprintk_func to vprintk")
>> Signed-off-by: Punit Agrawal <[email protected]>
>> --
>> Hi,
>>
>> The out-of-place EXPORT_SYMBOL() caused an unexpected conflict while
>> attempting to rebase the RT patches onto newer kernels.
>>
>> Generally I avoid sending trivial changes on their own but this one is
>> a little hard to overlook. Also it felt like an obvious oversight in
>> the original patch.
>
> Yes, indeed, sorry about that, and thanks for fixing it.
>
>> Please consider merging.
>
> Petr, as this is causing trouble for the -rt patchset, please consider
> if this could make it to Linus before v5.13 release.
>
> Acked-by: Rasmus Villemoes <[email protected]>
Thanks for the quick response.
Punit
On (21/06/15 08:56), Punit Agrawal wrote:
> Commit 28e1745b9fa2 ("printk: rename vprintk_func to vprintk") while
> improving readability by removing vprintk indirection, inadvertently
> placed the EXPORT_SYMBOL() for the newly renamed function at the end
> of the file.
>
> For reader sanity, and as is convention move the EXPORT_SYMBOL()
> declaration just after the end of the function.
>
> Fixes: 28e1745b9fa2 ("printk: rename vprintk_func to vprintk")
> Signed-off-by: Punit Agrawal <[email protected]>
Acked-by: Sergey Senozhatsky <[email protected]>
On Tue 2021-06-15 08:50:45, Rasmus Villemoes wrote:
> On 15/06/2021 01.56, Punit Agrawal wrote:
> > Commit 28e1745b9fa2 ("printk: rename vprintk_func to vprintk") while
> > improving readability by removing vprintk indirection, inadvertently
> > placed the EXPORT_SYMBOL() for the newly renamed function at the end
> > of the file.
> >
> > For reader sanity, and as is convention move the EXPORT_SYMBOL()
> > declaration just after the end of the function.
> >
> > Fixes: 28e1745b9fa2 ("printk: rename vprintk_func to vprintk")
> > Signed-off-by: Punit Agrawal <[email protected]>
> > --
> > Hi,
> >
> > The out-of-place EXPORT_SYMBOL() caused an unexpected conflict while
> > attempting to rebase the RT patches onto newer kernels.
> >
> > Generally I avoid sending trivial changes on their own but this one is
> > a little hard to overlook. Also it felt like an obvious oversight in
> > the original patch.
>
> Yes, indeed, sorry about that, and thanks for fixing it.
Yes, great catch.
> > Please consider merging.
>
> Petr, as this is causing trouble for the -rt patchset, please consider
> if this could make it to Linus before v5.13 release.
Sure, I could do so. But could you please provide some more details
what exact problems it causes?
It looks like a cosmetic issue to me. It would be the only change
in the pull request. I would like to provide some reasonable
justification for it at this stage (for rc7).
Best Regards,
Petr
On Wed 2021-06-16 08:56:01, Petr Mladek wrote:
> On Tue 2021-06-15 08:50:45, Rasmus Villemoes wrote:
> > On 15/06/2021 01.56, Punit Agrawal wrote:
> > > Commit 28e1745b9fa2 ("printk: rename vprintk_func to vprintk") while
> > > improving readability by removing vprintk indirection, inadvertently
> > > placed the EXPORT_SYMBOL() for the newly renamed function at the end
> > > of the file.
> > >
> > > For reader sanity, and as is convention move the EXPORT_SYMBOL()
> > > declaration just after the end of the function.
> > >
> > > Fixes: 28e1745b9fa2 ("printk: rename vprintk_func to vprintk")
> > > Signed-off-by: Punit Agrawal <[email protected]>
> > > --
> > > Hi,
> > >
> > > The out-of-place EXPORT_SYMBOL() caused an unexpected conflict while
> > > attempting to rebase the RT patches onto newer kernels.
Ah, this is the explanation. I am sorry for the noise.
> > > Generally I avoid sending trivial changes on their own but this one is
> > > a little hard to overlook. Also it felt like an obvious oversight in
> > > the original patch.
> >
> > Petr, as this is causing trouble for the -rt patchset, please consider
> > if this could make it to Linus before v5.13 release.
Punit, John, would you mind when I queue this change for-5.14?
It seems that, you, RT-guys already handled this, so it will not help
much if I sent it now. It does not look appropriate to send just a single
cosmetic fix few days before rc7.
Best Regards,
Petr
On 2021-06-16, Petr Mladek <[email protected]> wrote:
>>> Petr, as this is causing trouble for the -rt patchset, please
>>> consider if this could make it to Linus before v5.13 release.
>
> Punit, John, would you mind when I queue this change for-5.14? It
> seems that, you, RT-guys already handled this, so it will not help
> much if I sent it now. It does not look appropriate to send just a
> single cosmetic fix few days before rc7.
Since this cosmetic problem was introduced during the 5.13 merge window,
it would help if it is fixed before the 5.13 release. Obviously this is
not a reason to have an rc7. But if there is going to be an rc7, I think
this fix should be included.
John Ogness
On Wed 2021-06-16 09:57:11, John Ogness wrote:
> On 2021-06-16, Petr Mladek <[email protected]> wrote:
> >>> Petr, as this is causing trouble for the -rt patchset, please
> >>> consider if this could make it to Linus before v5.13 release.
> >
> > Punit, John, would you mind when I queue this change for-5.14? It
> > seems that, you, RT-guys already handled this, so it will not help
> > much if I sent it now. It does not look appropriate to send just a
> > single cosmetic fix few days before rc7.
>
> Since this cosmetic problem was introduced during the 5.13 merge window,
> it would help if it is fixed before the 5.13 release. Obviously this is
> not a reason to have an rc7. But if there is going to be an rc7, I think
> this fix should be included.
OK, I have committed the patch into printk/linux.git, branch
for-5.13-fixup.
I am going to send the pull request later this week, most likely
tomorrow.
Best Regards,
Petr
Hi Petr,
Apologies for the delayed response.
Petr Mladek <[email protected]> writes:
> On Wed 2021-06-16 09:57:11, John Ogness wrote:
>> On 2021-06-16, Petr Mladek <[email protected]> wrote:
>> >>> Petr, as this is causing trouble for the -rt patchset, please
>> >>> consider if this could make it to Linus before v5.13 release.
>> >
>> > Punit, John, would you mind when I queue this change for-5.14? It
>> > seems that, you, RT-guys already handled this, so it will not help
>> > much if I sent it now. It does not look appropriate to send just a
>> > single cosmetic fix few days before rc7.
>>
>> Since this cosmetic problem was introduced during the 5.13 merge window,
>> it would help if it is fixed before the 5.13 release. Obviously this is
>> not a reason to have an rc7. But if there is going to be an rc7, I think
>> this fix should be included.
>
> OK, I have committed the patch into printk/linux.git, branch
> for-5.13-fixup.
>
> I am going to send the pull request later this week, most likely
> tomorrow.
Thanks for picking this up.
It's good to have to the patch go in early, but 5.14 would also be fine.
Punit
[...]