Sparc32: BTFIXUPSET_CALL(pmd_clear, . . .)-related issue in older versions of the kernel

Sparc32: BTFIXUPSET_CALL(pmd_clear, . . .)-related issue in older versions of the kernel

[Ilya Malakhov]

 Hi.

 While analyzing a rather nasty problem with an application running at
sun4m sparc32 hosts with "Fujitsu TurboSparc" and "TI Viking/MXCC"
MMUs, I realized, that as a 4Kb "Page Table" was freed, only the first
element in the corresponding `pmdv[]' array in

typedef struct { unsigned long pmdv[16]; } pmd_t;

was actually cleared, rather than all the 16 ones.

 The reason for that was the use of `BTFIXUPCALL_SWAPO0G0' instead of
`BTFIXUPCALL_NORM' for `pmd_clear' in case of "default" SRMMU (except
for some specific types of SRMMU) during initialization:
 . .
BTFIXUPSET_CALL(pmd_clear, srmmu_pmd_clear, BTFIXUPCALL_SWAPO0G0);
 . .

 That would probably be OK if pmd_t were `struct { unsigned long pmd;
}' as it used to be ten years ago, but seems to be erroneous nowadays,
doesn't it?

 From a user's point of view this leads to poorly diagnosable
problems. E.g., after a series of mmaps and munmaps one may find
himself in a situation, where different virtual addresses are mapped to
the same physical one.

 A recent commit by David Miller, where pmd_clear() is un-btfixupped,
is likely to solve this problem in future versions of the kernel. I
wonder, if any patches for older ones should be expected.

 Thanks,
 Ilya.

Re: Sparc32: BTFIXUPSET_CALL(pmd_clear, . . .)-related issue in older versions of the kernel

[Sam Ravnborg]

Hi Ilya.

Cc: sparclinux + David S. Miller.

On Sun, May 27, 2012 at 04:03:50PM +0400, Ilya Malakhov wrote:
>  Hi.
> 
>  While analyzing a rather nasty problem with an application running at
> sun4m sparc32 hosts with "Fujitsu TurboSparc" and "TI Viking/MXCC"
> MMUs, I realized, that as a 4Kb "Page Table" was freed, only the first
> element in the corresponding `pmdv[]' array in
> 
> typedef struct { unsigned long pmdv[16]; } pmd_t;
> 
> was actually cleared, rather than all the 16 ones.
> 
>  The reason for that was the use of `BTFIXUPCALL_SWAPO0G0' instead of
> `BTFIXUPCALL_NORM' for `pmd_clear' in case of "default" SRMMU (except
> for some specific types of SRMMU) during initialization:
>  . .
> BTFIXUPSET_CALL(pmd_clear, srmmu_pmd_clear, BTFIXUPCALL_SWAPO0G0);
>  . .
> 
>  That would probably be OK if pmd_t were `struct { unsigned long pmd;
> }' as it used to be ten years ago, but seems to be erroneous nowadays,
> doesn't it?
> 
>  From a user's point of view this leads to poorly diagnosable
> problems. E.g., after a series of mmaps and munmaps one may find
> himself in a situation, where different virtual addresses are mapped to
> the same physical one.
> 
Sounds like a problem that have taken long time to track down!

>  A recent commit by David Miller, where pmd_clear() is un-btfixupped,
> is likely to solve this problem in future versions of the kernel.
We were very glad to kill off this btfixup thing.


> I wonder, if any patches for older ones should be expected.

If someone submits a patch for this it is likely to happen - hint!
That patch should explicit reference the commit in upstrem
that fixes the same bug.

Otherwise - no.

	Sam