[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200228180518.GA21491@sasha-vm>
Date: Fri, 28 Feb 2020 13:05:18 -0500
From: Sasha Levin <sashal@...nel.org>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Pavel Machek <pavel@...x.de>, linux-kernel@...r.kernel.org,
stable@...r.kernel.org, Miles Chen <miles.chen@...iatek.com>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 4.19 60/97] lib/stackdepot: Fix outdated comments
On Fri, Feb 28, 2020 at 02:30:36PM +0100, Greg Kroah-Hartman wrote:
>On Fri, Feb 28, 2020 at 02:24:55PM +0100, Greg Kroah-Hartman wrote:
>> On Fri, Feb 28, 2020 at 02:05:33PM +0100, Pavel Machek wrote:
>> > Hi!
>> >
>> > > [ Upstream commit ee050dc83bc326ad5ef8ee93bca344819371e7a5 ]
>> > >
>> > > Replace "depot_save_stack" with "stack_depot_save" in code comments because
>> > > depot_save_stack() was replaced in commit c0cfc337264c ("lib/stackdepot:
>> > > Provide functions which operate on plain storage arrays") and removed in
>> > > commit 56d8f079c51a ("lib/stackdepot: Remove obsolete functions")
>> >
>> > This is wrong.
>> >
>> > > +++ b/lib/stackdepot.c
>> > > @@ -96,7 +96,7 @@ static bool init_stack_slab(void **prealloc)
>> > > stack_slabs[depot_index + 1] = *prealloc;
>> > > /*
>> > > * This smp_store_release pairs with smp_load_acquire() from
>> > > - * |next_slab_inited| above and in depot_save_stack().
>> > > + * |next_slab_inited| above and in stack_depot_save().
>> > > */
>> > > smp_store_release(&next_slab_inited, 1);
>> > > }
>> >
>> > May have been outdated for mainline, but they are actually okay for
>> > 4.19.
>>
>> Good catch, I'll go drop this from the stable queues (4.14, 4.9, and 4.19).
>
>Ah, nope, this patch is needed for the "real" patch here, 305e519ce48e
>("lib/stackdepot.c: fix global out-of-bounds in stack_slabs")
>
>Hm, it's not that big of a deal, I'll go fix that up by hand...
>
>But that explains why it is included here.
I replied on the "FAILED:" email explaining why I took it even though
it's wrong:
Technically the comment change is wrong as the commit it addresses is
older, but no one should be coding against the stable tree, and doing it
by changing 305e519ce48e would cause merge conflicts in the future.
--
Thanks,
Sasha
Powered by blists - more mailing lists