On 04/03/15 11:27, Borislav Petkov wrote:
On Wed, Mar 04, 2015 at 11:15:49AM +, Sudeep Holla wrote:
I can do that, but wouldn't that add confusion as this commit is not
changing that behaviour. It's already changed in v4.0-rc1
Nah, this would add a reference to the fact that the cpumask
On Wed, Mar 04, 2015 at 11:15:49AM +, Sudeep Holla wrote:
> I can do that, but wouldn't that add confusion as this commit is not
> changing that behaviour. It's already changed in v4.0-rc1
Nah, this would add a reference to the fact that the cpumask format is
not really a stable thing and
Hi Boris,
On 03/03/15 18:57, Borislav Petkov wrote:
On Tue, Mar 03, 2015 at 01:53:02PM -0500, Tejun Heo wrote:
We were alternating between the two forms depending on
CONFIG_CPUMASK_OFFSTACK before. Now we're always sticking to the
shorter format. Please see 513e3d2d11c9 ("cpumask: always use
On 03/03/15 18:45, Borislav Petkov wrote:
[...]
Now, previously the code did
- if (!per_cpu(ici_cpuid4_info, i))
- continue;
and __cache_cpumap_setup() already does:
if (i == cpu || !sib_cpu_ci->info_list)
On 03/03/15 18:45, Borislav Petkov wrote:
[...]
Now, previously the code did
- if (!per_cpu(ici_cpuid4_info, i))
- continue;
and __cache_cpumap_setup() already does:
if (i == cpu || !sib_cpu_ci-info_list)
On 04/03/15 11:27, Borislav Petkov wrote:
On Wed, Mar 04, 2015 at 11:15:49AM +, Sudeep Holla wrote:
I can do that, but wouldn't that add confusion as this commit is not
changing that behaviour. It's already changed in v4.0-rc1
Nah, this would add a reference to the fact that the cpumask
On Wed, Mar 04, 2015 at 11:15:49AM +, Sudeep Holla wrote:
I can do that, but wouldn't that add confusion as this commit is not
changing that behaviour. It's already changed in v4.0-rc1
Nah, this would add a reference to the fact that the cpumask format is
not really a stable thing and thus
Hi Boris,
On 03/03/15 18:57, Borislav Petkov wrote:
On Tue, Mar 03, 2015 at 01:53:02PM -0500, Tejun Heo wrote:
We were alternating between the two forms depending on
CONFIG_CPUMASK_OFFSTACK before. Now we're always sticking to the
shorter format. Please see 513e3d2d11c9 (cpumask: always use
On Tue, Mar 03, 2015 at 01:53:02PM -0500, Tejun Heo wrote:
> We were alternating between the two forms depending on
> CONFIG_CPUMASK_OFFSTACK before. Now we're always sticking to the
> shorter format. Please see 513e3d2d11c9 ("cpumask: always use
> nr_cpu_ids in formatting and parsing
Hello, Borislav.
On Tue, Mar 03, 2015 at 07:45:27PM +0100, Borislav Petkov wrote:
> Tejun, we have this change in user-visible masks formatting in sysfs
> after your bitmaps printing changes:
>
> -cpu5/cache/index3/shared_cpu_map:,003f
> +cpu5/cache/index3/shared_cpu_map:3f
>
>
@Tejun: scroll to the end :)
On Sun, Mar 01, 2015 at 10:39:24PM +, Andre Przywara wrote:
> So I gave that a spin on my old PhenomII X6 box, and indeed there is a
> NULL pointer dereference. I tracked it down to
> __cache_amd_cpumap_setup(), where the sibling map for the L3 is
> populated.
@Tejun: scroll to the end :)
On Sun, Mar 01, 2015 at 10:39:24PM +, Andre Przywara wrote:
So I gave that a spin on my old PhenomII X6 box, and indeed there is a
NULL pointer dereference. I tracked it down to
__cache_amd_cpumap_setup(), where the sibling map for the L3 is
populated. When
Hello, Borislav.
On Tue, Mar 03, 2015 at 07:45:27PM +0100, Borislav Petkov wrote:
Tejun, we have this change in user-visible masks formatting in sysfs
after your bitmaps printing changes:
-cpu5/cache/index3/shared_cpu_map:,003f
+cpu5/cache/index3/shared_cpu_map:3f
What's the
On Tue, Mar 03, 2015 at 01:53:02PM -0500, Tejun Heo wrote:
We were alternating between the two forms depending on
CONFIG_CPUMASK_OFFSTACK before. Now we're always sticking to the
shorter format. Please see 513e3d2d11c9 (cpumask: always use
nr_cpu_ids in formatting and parsing functions).
Hi Andre,
On 01/03/15 22:39, Andre Przywara wrote:
On Tue, 24 Feb 2015 18:57:49 +0100, Borislav Petkov wrote:
On Mon, Feb 23, 2015 at 06:14:25PM +, Sudeep Holla wrote:
- Rebased on v4.0-rc1
- Fixed lockdep warning reported by Borislav
You probably have fixed the lockdep splat but not
Hi Andre,
On 01/03/15 22:39, Andre Przywara wrote:
On Tue, 24 Feb 2015 18:57:49 +0100, Borislav Petkov wrote:
On Mon, Feb 23, 2015 at 06:14:25PM +, Sudeep Holla wrote:
- Rebased on v4.0-rc1
- Fixed lockdep warning reported by Borislav
You probably have fixed the lockdep splat but not
On Tue, 24 Feb 2015 18:57:49 +0100, Borislav Petkov wrote:
> On Mon, Feb 23, 2015 at 06:14:25PM +, Sudeep Holla wrote:
>> - Rebased on v4.0-rc1
>> - Fixed lockdep warning reported by Borislav
> You probably have fixed the lockdep splat but not the NULL pointer
> dereference which was there
On Tue, 24 Feb 2015 18:57:49 +0100, Borislav Petkov wrote:
On Mon, Feb 23, 2015 at 06:14:25PM +, Sudeep Holla wrote:
- Rebased on v4.0-rc1
- Fixed lockdep warning reported by Borislav
You probably have fixed the lockdep splat but not the NULL pointer
dereference which was there in the
On Tue, Feb 24, 2015 at 06:09:17PM +, Sudeep Holla wrote:
> Sorry for the trouble and thanks for giving it a try. OK I will try to
> find one, but it may be difficult to grab one.
Well, either that or I can take a look as I have the box here but it
won't happen immediately as I'm swamped.
--
Hi Boris,
On 24/02/15 17:57, Borislav Petkov wrote:
On Mon, Feb 23, 2015 at 06:14:25PM +, Sudeep Holla wrote:
- Rebased on v4.0-rc1
- Fixed lockdep warning reported by Borislav
You probably have fixed the lockdep splat but not the NULL pointer
dereference which was there in the first
On Mon, Feb 23, 2015 at 06:14:25PM +, Sudeep Holla wrote:
> - Rebased on v4.0-rc1
> - Fixed lockdep warning reported by Borislav
You probably have fixed the lockdep splat but not the NULL pointer
dereference which was there in the first mail I sent you. I'd suggest
you find an AMD box with
On 24/02/15 07:58, Ingo Molnar wrote:
* Sudeep Holla wrote:
This patch removes the redundant sysfs cacheinfo code by
reusing the newly introduced generic cacheinfo
infrastructure through the commit 246246cbde5e ("drivers:
base: support cpu cache information interface to
userspace via
On 24/02/15 07:58, Ingo Molnar wrote:
* Sudeep Holla sudeep.ho...@arm.com wrote:
This patch removes the redundant sysfs cacheinfo code by
reusing the newly introduced generic cacheinfo
infrastructure through the commit 246246cbde5e (drivers:
base: support cpu cache information interface to
On Tue, Feb 24, 2015 at 06:09:17PM +, Sudeep Holla wrote:
Sorry for the trouble and thanks for giving it a try. OK I will try to
find one, but it may be difficult to grab one.
Well, either that or I can take a look as I have the box here but it
won't happen immediately as I'm swamped.
--
On Mon, Feb 23, 2015 at 06:14:25PM +, Sudeep Holla wrote:
- Rebased on v4.0-rc1
- Fixed lockdep warning reported by Borislav
You probably have fixed the lockdep splat but not the NULL pointer
dereference which was there in the first mail I sent you. I'd suggest
you find an AMD box with an
Hi Boris,
On 24/02/15 17:57, Borislav Petkov wrote:
On Mon, Feb 23, 2015 at 06:14:25PM +, Sudeep Holla wrote:
- Rebased on v4.0-rc1
- Fixed lockdep warning reported by Borislav
You probably have fixed the lockdep splat but not the NULL pointer
dereference which was there in the first
* Sudeep Holla wrote:
> This patch removes the redundant sysfs cacheinfo code by
> reusing the newly introduced generic cacheinfo
> infrastructure through the commit 246246cbde5e ("drivers:
> base: support cpu cache information interface to
> userspace via sysfs")
>
> The private pointer
This patch removes the redundant sysfs cacheinfo code by reusing
the newly introduced generic cacheinfo infrastructure through the
commit 246246cbde5e ("drivers: base: support cpu cache information
interface to userspace via sysfs")
The private pointer provided by the cacheinfo is used to
This patch removes the redundant sysfs cacheinfo code by reusing
the newly introduced generic cacheinfo infrastructure through the
commit 246246cbde5e (drivers: base: support cpu cache information
interface to userspace via sysfs)
The private pointer provided by the cacheinfo is used to implement
* Sudeep Holla sudeep.ho...@arm.com wrote:
This patch removes the redundant sysfs cacheinfo code by
reusing the newly introduced generic cacheinfo
infrastructure through the commit 246246cbde5e (drivers:
base: support cpu cache information interface to
userspace via sysfs)
The
30 matches
Mail list logo
