* Linus Torvalds wrote:
> On Wed, Nov 2, 2016 at 4:50 AM, Tetsuo Handa
> wrote:
> >>
> >> So I _think_ the fix is to just remove this. Perhaps something like
> >> the attached? Adding scheduler people since this is in their code..
> >
> > That is not sufficient, for another Oops occurs inside s
On Wed, Nov 2, 2016 at 4:50 AM, Tetsuo Handa
wrote:
>>
>> So I _think_ the fix is to just remove this. Perhaps something like
>> the attached? Adding scheduler people since this is in their code..
>
> That is not sufficient, for another Oops occurs inside stack_not_used().
> Since I don't want to
On Wed, Nov 2, 2016 at 3:50 AM, Tetsuo Handa
wrote:
> Linus Torvalds wrote:
>> On Tue, Nov 1, 2016 at 8:36 AM, Tetsuo Handa
>> wrote:
>> >
>> > I got an Oops with khungtaskd. This kernel was built with
>> > CONFIG_THREAD_INFO_IN_TASK=y .
>> > Is this same reason?
>>
>> CONFIG_THREAD_INFO_IN_TASK
Linus Torvalds wrote:
> On Tue, Nov 1, 2016 at 8:36 AM, Tetsuo Handa
> wrote:
> >
> > I got an Oops with khungtaskd. This kernel was built with
> > CONFIG_THREAD_INFO_IN_TASK=y .
> > Is this same reason?
>
> CONFIG_THREAD_INFO_IN_TASK is always set on x86, but I assume you also
> did VMAP_STACK
On Tue, Nov 1, 2016 at 8:36 AM, Tetsuo Handa
wrote:
>
> I got an Oops with khungtaskd. This kernel was built with
> CONFIG_THREAD_INFO_IN_TASK=y .
> Is this same reason?
CONFIG_THREAD_INFO_IN_TASK is always set on x86, but I assume you also
did VMAP_STACK
And yes, it looks like it's the same "t
Hello.
Andy Lutomirski wrote:
> Reporting these fields on a non-current task is dangerous. If the
> task is in any state other than normal kernel code, they may contain
> garbage or even kernel addresses on some architectures. (x86_64
> used to do this. I bet lots of architectures still do.) W
6 matches
Mail list logo