Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1226585 > unrolled thread

Re: [linux41] regression with 'x86/cacheinfo: Move cacheinfo sysfs code to generic infrastructure' on AMD i686

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [linux41] regression with 'x86/cacheinfo: Move cacheinfo sysfs  code to generic infrastructure' on AMD i686 Josh Boyer <jwboyer@fedoraproject.org> - 2015-09-17 02:00 +0200
    Re: [linux41] regression with 'x86/cacheinfo: Move cacheinfo sysfs  code to generic infrastructure' on AMD i686 Philip Müller <philm@manjaro.org> - 2015-09-17 07:40 +0200
    Re: [linux41] regression with 'x86/cacheinfo: Move cacheinfo sysfs  code to generic infrastructure' on AMD i686 Borislav Petkov <bp@alien8.de> - 2015-09-17 09:20 +0200
      Re: [linux41] regression with 'x86/cacheinfo: Move cacheinfo sysfs  code to generic infrastructure' on AMD i686 Greg KH <gregkh@linuxfoundation.org> - 2015-09-17 15:00 +0200

#1226585 — Re: [linux41] regression with 'x86/cacheinfo: Move cacheinfo sysfs code to generic infrastructure' on AMD i686

On Sun, Jul 26, 2015 at 10:42 AM, Borislav Petkov <bp@alien8.de> wrote:
> On Sun, Jul 26, 2015 at 12:54:55PM +0200, Philip Müller wrote:
>> I can confirm your patch working. However, it might be good to use yours
>> and Thomas' in combination to solve this properly.
>
> Please do not top-post.
>
> We could use Thomas' too although from looking at it,
> detect_cache_attributes() allocates a per-CPU per_cpu_cacheinfo thing
> for each CPU. By the time we hit cache_shared_cpu_map_remove() in
> free_cache_attributes(), those per_cpu_cacheinfo(cpu) things are still
> allocated. We kfree them in the next step only.
>
> But I like the moving of the check from the CPU hotplug callback to
> free_cache_attributes().
>
> So I'll merge the two patches and write up a proper commit message,
> unless someone objects.
>
> I'll add your Tested-by too.

Did this actually happen?  I don't see either fix in Linus' tree yet,
the merge window is closed, and the bug happens on 4.1 and 4.2 stable
kernels..

josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1226677

Am 17.09.2015 um 01:52 schrieb Josh Boyer:
> 
> Did this actually happen?  I don't see either fix in Linus' tree yet,
> the merge window is closed, and the bug happens on 4.1 and 4.2 stable
> kernels..
> 
> josh
> 

Seems not yet. I don't see it neither in 4.3-rc1. Seems 4.3 will have
the same issues then ...

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1226710

On Wed, Sep 16, 2015 at 07:52:47PM -0400, Josh Boyer wrote:
> On Sun, Jul 26, 2015 at 10:42 AM, Borislav Petkov <bp@alien8.de> wrote:
> > On Sun, Jul 26, 2015 at 12:54:55PM +0200, Philip Müller wrote:
> >> I can confirm your patch working. However, it might be good to use yours
> >> and Thomas' in combination to solve this properly.
> >
> > Please do not top-post.
> >
> > We could use Thomas' too although from looking at it,
> > detect_cache_attributes() allocates a per-CPU per_cpu_cacheinfo thing
> > for each CPU. By the time we hit cache_shared_cpu_map_remove() in
> > free_cache_attributes(), those per_cpu_cacheinfo(cpu) things are still
> > allocated. We kfree them in the next step only.
> >
> > But I like the moving of the check from the CPU hotplug callback to
> > free_cache_attributes().
> >
> > So I'll merge the two patches and write up a proper commit message,
> > unless someone objects.
> >
> > I'll add your Tested-by too.
> 
> Did this actually happen?  I don't see either fix in Linus' tree yet,
> the merge window is closed, and the bug happens on 4.1 and 4.2 stable
> kernels..

Greg wanted to pick it up...

Greg, what's up?

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1226994

On Thu, Sep 17, 2015 at 09:15:04AM +0200, Borislav Petkov wrote:
> On Wed, Sep 16, 2015 at 07:52:47PM -0400, Josh Boyer wrote:
> > On Sun, Jul 26, 2015 at 10:42 AM, Borislav Petkov <bp@alien8.de> wrote:
> > > On Sun, Jul 26, 2015 at 12:54:55PM +0200, Philip Müller wrote:
> > >> I can confirm your patch working. However, it might be good to use yours
> > >> and Thomas' in combination to solve this properly.
> > >
> > > Please do not top-post.
> > >
> > > We could use Thomas' too although from looking at it,
> > > detect_cache_attributes() allocates a per-CPU per_cpu_cacheinfo thing
> > > for each CPU. By the time we hit cache_shared_cpu_map_remove() in
> > > free_cache_attributes(), those per_cpu_cacheinfo(cpu) things are still
> > > allocated. We kfree them in the next step only.
> > >
> > > But I like the moving of the check from the CPU hotplug callback to
> > > free_cache_attributes().
> > >
> > > So I'll merge the two patches and write up a proper commit message,
> > > unless someone objects.
> > >
> > > I'll add your Tested-by too.
> > 
> > Did this actually happen?  I don't see either fix in Linus' tree yet,
> > the merge window is closed, and the bug happens on 4.1 and 4.2 stable
> > kernels..
> 
> Greg wanted to pick it up...
> 
> Greg, what's up?

It's in my "to-apply" queue, let me go dig it up now...

thanks for the reminder.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web