Re: [bisected] DEBUG_PAGEALLOC hangs on sparc64

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 29 May 2019, at 22:00, James Clarke <jrtc27@xxxxxxxxxx> wrote:
> On 29 May 2019, at 21:23, David Miller <davem@xxxxxxxxxxxxx> wrote:
>> 
>> From: Meelis Roos <mroos@xxxxxxxx>
>> Date: Wed, 29 May 2019 22:08:26 +0300
>> 
>>> Bisecting led me to 4.9 merge window and this patch that broke it:
>>> 
>>> a74ad5e660a9ee1d071665e7e8ad822784a2dc7f is the first bad commit
>>> commit a74ad5e660a9ee1d071665e7e8ad822784a2dc7f
>>> Author: David S. Miller <davem@xxxxxxxxxxxxx>
>>> Date:   Thu Oct 27 09:04:54 2016 -0700
>>> 
>>>   sparc64: Handle extremely large kernel TLB range flushes more
>>>   gracefully.
>> 
>> Thank you, I will take a close look at this ASAP.
> 
> Perhaps I'm being stupid, but the first hunk in xcall_flush_tlb_kernel_range
> looks wrong to me. %g2 previously contained PAGE_SIZE-1, but is now clobbered
> by the new srlx, setting %g2 to (aligned_end-aligned_start)>>18. If the
> brnz %g2 is taken, %g2 gets overwritten, so it's not a problem, but if the
> branch *isn't* taken, then %g2 is zero, so the add %g2, 1, %g2 in the delay
> slot of the branch sets %g2 to 1. However, prior to this commit, %g2 would then
> have had the value PAGE_SIZE, and the following code to do a page-by-page flush
> assumes this, using it as the amount to step through. Rather than stepping
> through page-by-page (with offset 0x20 to indicate nucleus), we will step
> through the loop byte-by-byte, so some iterations will have low bit
> combinations for things other than a nucleus page demap operation. This same
> bug is replicated in the new __cheetah_xcall_flush_tlb_kernel_range.

Meelis, could you please try the attached patch to see if it fixes the issue?

David, I don't actually see why we need this alignment code in the first place.
The only call to the xcall is in smp_flush_tlb_kernel_range which already
rounds the start and end to multiples of the page size, so I believe we should
be able to delete the first four instructions of the 3 different
implementations? The non-xcall variants already skip doing this.

Regards,
James

Attachment: 0001-sparc64-Fix-regression-in-non-hypervisor-TLB-flush-x.patch
Description: Binary data


[Index of Archives]     [Kernel Development]     [DCCP]     [Linux ARM Development]     [Linux]     [Photo]     [Yosemite Help]     [Linux ARM Kernel]     [Linux SCSI]     [Linux x86_64]     [Linux Hams]

  Powered by Linux