On Sat, 2016-06-18 at 23:57 +0530, Aneesh Kumar K.V wrote:
> We use feature fixup in segment and page fault path and hence we should
> not call any function that can cause either of these before we finish
> feature fixup.
>
> Calling into early debug routine can result in segment fault as updated
We use feature fixup in segment and page fault path and hence we should
not call any function that can cause either of these before we finish
feature fixup.
Calling into early debug routine can result in segment fault as updated
in
https://lkml.kernel.org/r/CAOJe8K2L8D1M_yZPmyiZ11JvJ+HAS0aFHOnsqa
Michael Ellerman writes:
> On Fri, 2016-06-17 at 08:33 +1000, Benjamin Herrenschmidt wrote:
>> On Thu, 2016-06-16 at 22:49 +0300, Denis Kirjanov wrote:
>> > -
>> > +BEGIN_MMU_FTR_SECTION
>> > + b 2f
>> > +END_MMU_FTR_SECTION_IFSET(MMU_FTR_RADIX)
>> > andi. r10,r12,MSR_RI /*
The use feature fixup in segment and page fault path and we should
not call any function that can cause either of these before we finish
feature fixup.
Calling into early debug routine can result in segment fault as updated
in
https://lkml.kernel.org/r/CAOJe8K2L8D1M_yZPmyiZ11JvJ+HAS0aFHOnsqaY=xlo
On Fri, Jun 17, 2016 at 07:24:46PM -0700, Yinghai Lu wrote:
> In 8c05cd08a7 ("PCI: fix offset check for sysfs mmapped files"), try
> to check exposed value with resource start/end in proc mmap path.
>
> |start = vma->vm_pgoff;
> |size = ((pci_resource_len(pdev, resno) - 1) >> PAGE_
On 06/18/16 00:59, Doug Ledford wrote:
> On 6/13/2016 3:44 PM, Topi Miettinen wrote:
>> Track maximum size of locked memory, presented in /proc/self/limits.
>
> You should have probably Cc:ed everyone on the cover letter and probably
> patch 1 of this series. This patch is hard to decipher withou
