[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2236FBA76BA1254E88B949DDB74E612B41C3C41D@IRSMSX102.ger.corp.intel.com>
Date: Thu, 12 Jan 2017 07:54:37 +0000
From: "Reshetova, Elena" <elena.reshetova@...el.com>
To: Kees Cook <keescook@...omium.org>
CC: AKASHI Takahiro <takahiro.akashi@...aro.org>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
"arnd@...db.de" <arnd@...db.de>, "tglx@...utronix.de" <tglx@...utronix.de>,
"mingo@...hat.com" <mingo@...hat.com>, "Anvin, H Peter"
<h.peter.anvin@...el.com>, "peterz@...radead.org" <peterz@...radead.org>,
"will.deacon@....com" <will.deacon@....com>, "dwindsor@...il.com"
<dwindsor@...il.com>, "gregkh@...uxfoundation.org"
<gregkh@...uxfoundation.org>, "ishkamiel@...il.com" <ishkamiel@...il.com>
Subject: RE: [RFC PATCH 08/19] kernel, mm: convert from
atomic_t to refcount_t
On Wed, Jan 11, 2017 at 1:30 AM, Reshetova, Elena
<elena.reshetova@...el.com> wrote:
> On Tue, Jan 10, 2017 at 3:57 AM, Reshetova, Elena
> <elena.reshetova@...el.com> wrote:
>> On Thu, Jan 5, 2017 at 1:56 AM, Reshetova, Elena
>> <elena.reshetova@...el.com> wrote:
>>>> On Thu, Dec 29, 2016 at 08:56:00AM +0200, Elena Reshetova wrote:
>>>> > refcount_t type and corresponding API should be
>>>> > used instead of atomic_t when the variable is used as
>>>> > a reference counter. Convert the cases found.
>>>> > diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
>>>> > index 7dd14e8..1d59aca 100644
>>>> > --- a/arch/arm/kernel/smp.c
>>>> > +++ b/arch/arm/kernel/smp.c
>>>> > @@ -371,7 +371,7 @@ asmlinkage void secondary_start_kernel(void)
>>>> > * reference and switch to it.
>>>> > */
>>>> > cpu = smp_processor_id();
>>>> > - atomic_inc(&mm->mm_count);
>>>> > + refcount_inc(&mm->mm_count);
>>>> > current->active_mm = mm;
>>>> > cpumask_set_cpu(cpu, mm_cpumask(mm));
>>>> >
>>>>
>>>> If this is the case, arm64 has almost the same code.
>>>
>>> Thank you! I haven't tried to build on arm64 this yet (as well as on other arches). I am pretty sure there are more cases on other arches that are missed.
>>> That's why I was hoping that we can run this series to the automatic build infra.
>>>
>>> @Kees, how did you do it before for previous patches? Who should be contacted to get a build-test on all arches?
>>
>>>Normally the 0day builder should pick it up from the mailing list, but
>>>if it doesn't (and it may not due to the missing prerequisite
>>>patches), I can create a branch on kernel.org and it will pick it up
>>>there.
>>
>> I don't think it picked up this one, don't know why. All prerequisites should be in place.
>> Is there a way to point it to the repo? We have everything in refcount_t branch here:
>> https://github.com/ereshetova/linux-stable/tree/refcount_t
>
>>We could ask Fengguang to explicitly add it, but how about I just put
>>it in my repo on kernel.org.
>
> Sure, whatever works.
>
>> Just note: the last lustre commit is there just for future work, I won't include it in testing since we gave up on trying to get it in shape. It is *way* too messy...
>>
>>>Are you able to build a series that includes refcount_t implementation
>>>(so there is a single series that contains all the prerequisites), and
>>>base it on v4.10-rc2? That should give 0day no problems in doing a
>>>merge and test (since -next mutates every day...)
>>
>> It was fully buildable at last on x86 and arm (not arm64 as was noted) and was based on linux-next/stable branch.
>> I can also rebase it to 4.10-rc2 if needed. Should be trivial.
>> Should we in general keep it on stable and not on linux-next? Certainly easier to test...
>
>>Yeah, from what I've been able to tell, with large changes, it's
>>easier to carry things as deltas against the -rc2 while Linus's tree
>>is finalizing for a release, and then once it's out, wait for -rc2
>>again, and rebase. That way, if things stabilize in your tree, we can
>>get it added to -next and things should merge "well".
>
> Maybe stupid question: but why explicitly -rc2 vs. any other rcX?
> Now it seems the latest is rc3 and it applies nicely there. I guess I
> don't understand the release flow yet...
>My understanding (which may be flawed) is that -rc1 takes the bulk of
>major changes, and -rc2 takes the bulk of early/large fixes. After
>-rc2, almost everything is going to be bug fixes. Also, it seems to be
>traditional to use -rc2 bases for trees that are automatically merged
>in -next.
>Therefore, in the interests of both 0-day and -next merge ease, using
>-rc2 tends to be the best.
Thank you for explaining this! This is clearly the knowledge I was missing.
I was merely seeing different rc2 as intermediate tags with no specific values.
Will be basing on rc2 from now on.
Best Regards,
Elena.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
