> On Apr 12, 2020, at 3:48 PM, Mike Rapoport wrote:
>
> From: Baoquan He
>
> When called during boot the memmap_init_zone() function checks if each PFN
> is valid and actually belongs to the node being initialized using
> early_pfn_valid() and early_pfn_in_nid().
>
> Each such check may cos
> On Mar 6, 2020, at 7:56 PM, Anshuman Khandual
> wrote:
>
>
>
> On 03/07/2020 06:04 AM, Qian Cai wrote:
>>
>>
>>> On Mar 6, 2020, at 7:03 PM, Anshuman Khandual
>>> wrote:
>>>
>>> Hmm, set_pte_at() function is not p
> On Mar 6, 2020, at 7:03 PM, Anshuman Khandual
> wrote:
>
> Hmm, set_pte_at() function is not preferred here for these tests. The idea
> is to avoid or atleast minimize TLB/cache flushes triggered from these sort
> of 'static' tests. set_pte_at() is platform provided and could/might trigger
On Fri, 2020-03-06 at 05:27 +0530, Anshuman Khandual wrote:
> This adds tests which will validate architecture page table helpers and
> other accessors in their compliance with expected generic MM semantics.
> This will help various architectures in validating changes to existing
> page table helpe
> On Mar 4, 2020, at 1:49 AM, Christophe Leroy wrote:
>
> AFAIU, you are not taking an interrupt here. You are stuck in the
> pte_update(), most likely due to nested locks. Try with LOCKDEP ?
Not exactly sure what did you mean here, but the kernel has all lockdep enabled
and did not flag an
> Below is slightly modified version of your change above and should still
> prevent the bug on powerpc. Will it be possible for you to re-test this
> ? Once confirmed, will send a patch enabling this test on powerpc64
> keeping your authorship. Thank you.
This works fine on radix MMU but I decid
On Wed, 2020-02-26 at 10:51 -0500, Qian Cai wrote:
> On Wed, 2020-02-26 at 15:45 +0100, Christophe Leroy wrote:
> >
> > Le 26/02/2020 à 15:09, Qian Cai a écrit :
> > > On Mon, 2020-02-17 at 08:47 +0530, Anshuman Khandual wrote:
> > > > This adds tests which w
On Wed, 2020-02-26 at 15:45 +0100, Christophe Leroy wrote:
>
> Le 26/02/2020 à 15:09, Qian Cai a écrit :
> > On Mon, 2020-02-17 at 08:47 +0530, Anshuman Khandual wrote:
> > > This adds tests which will validate architecture page table helpers and
> > > other acce
On Wed, 2020-02-26 at 09:09 -0500, Qian Cai wrote:
> On Mon, 2020-02-17 at 08:47 +0530, Anshuman Khandual wrote:
> > This adds tests which will validate architecture page table helpers and
> > other accessors in their compliance with expected generic MM semantics.
> > T
ormation message in debug_vm_pgtable() per Christophe
> - Dropped random_vaddr boundary condition checks per Christophe and Qian
> - Replaced virt_addr_valid() check with pfn_valid() check in
> debug_vm_pgtable()
> - Slightly changed pr_fmt(fmt) information
>
> Changes
On Mon, 2020-02-03 at 16:14 +0100, Christophe Leroy wrote:
>
> Le 02/02/2020 à 12:26, Qian Cai a écrit :
> >
> >
> > > On Jan 30, 2020, at 9:13 AM, Christophe Leroy
> > > wrote:
> > >
> > > config DEBUG_VM_PGTABLE
> > &g
> On Jan 30, 2020, at 9:13 AM, Christophe Leroy wrote:
>
> config DEBUG_VM_PGTABLE
>bool "Debug arch page table for semantics compliance" if
> ARCH_HAS_DEBUG_VM_PGTABLE || EXPERT
>depends on MMU
>default 'n' if !ARCH_HAS_DEBUG_VM_PGTABLE
>default 'y' if DEBUG_VM
Does it reall
> On Jan 29, 2020, at 5:36 AM, Catalin Marinas wrote:
>
> On Tue, Jan 28, 2020 at 02:07:10PM -0500, Qian Cai wrote:
>> On Jan 28, 2020, at 12:47 PM, Catalin Marinas
>> wrote:
>>> The primary goal here is not finding regressions but having clearly
>>&
> On Jan 28, 2020, at 12:47 PM, Catalin Marinas wrote:
>
> The primary goal here is not finding regressions but having clearly
> defined semantics of the page table accessors across architectures. x86
> and arm64 are a good starting point and other architectures will be
> enabled as they are a
> On Jan 28, 2020, at 1:13 AM, Christophe Leroy wrote:
>
> ppc32 an indecent / legacy platform ? Are you kidying ?
>
> Powerquicc II PRO for instance is fully supported by the manufacturer and
> widely used in many small networking devices.
Of course I forgot about embedded devices. The pro
> On Jan 28, 2020, at 2:03 AM, Anshuman Khandual
> wrote:
>
> 'allyesconfig' makes 'DEBUG_VM = y' which in turn will enable
> 'DEBUG_VM_PGTABLE = y'
> on platforms that subscribe ARCH_HAS_DEBUG_VM_PGTABLE.
Isn’t that only for compiling testing? Who is booting such a beast and make
sure ever
> On Jan 28, 2020, at 1:17 AM, Christophe Leroy wrote:
>
> It is 'default y' so there is no much risk that it is forgotten, at least all
> test suites run with 'allyes_defconfig' will trigger the test, so I think it
> is really a good feature.
This thing depends on DEBUG_VM which I don’t see
> On Jan 27, 2020, at 11:58 PM, Anshuman Khandual
> wrote:
>
> As I had mentioned before, the test attempts to formalize page table helper
> semantics
> as expected from generic MM code paths and intend to catch deviations when
> enabled on
> a given platform. How else should we test semanti
> On Jan 27, 2020, at 10:06 PM, Anshuman Khandual
> wrote:
>
>
>
> On 01/28/2020 07:41 AM, Qian Cai wrote:
>>
>>
>>> On Jan 27, 2020, at 8:28 PM, Anshuman Khandual
>>> wrote:
>>>
>>> This adds tests which will validat
> On Jan 27, 2020, at 8:28 PM, Anshuman Khandual
> wrote:
>
> This adds tests which will validate architecture page table helpers and
> other accessors in their compliance with expected generic MM semantics.
> This will help various architectures in validating changes to existing
> page table
> On Oct 28, 2019, at 1:29 AM, Anshuman Khandual
> wrote:
>
> This adds tests which will validate architecture page table helpers and
> other accessors in their compliance with expected generic MM semantics.
> This will help various architectures in validating changes to existing
> page table
> On Oct 24, 2019, at 11:45 PM, Anshuman Khandual
> wrote:
>
> Nothing specific. But just tested this with x86 defconfig with relevant
> configs
> which are required for this test. Not sure if it involved W=1.
No, it will not. It needs to run like,
make W=1 -j 64 2>/tmp/warns
_
ge_alloc_init_late() per Michal and Qian
> - Updated the commit message per Michal
> - Updated W=1 GCC warning problem on x86 per Qian Cai
It would be interesting to know if you actually tested out to see if the
warning went away. As far I can tell, the GCC is quite stubborn there
On Tue, 2019-10-15 at 20:51 +0530, Anshuman Khandual wrote:
>
> On 10/15/2019 08:11 PM, Qian Cai wrote:
> > The x86 will crash with linux-next during boot due to this series (v5) with
> > the
> > config below plus CONFIG_DEBUG_VM_PGTABLE=y. I am not sure if v6 w
On Tue, 2019-10-15 at 14:51 +0530, Anshuman Khandual wrote:
> +static unsigned long __init get_random_vaddr(void)
> +{
> + unsigned long random_vaddr, random_pages, total_user_pages;
> +
> + total_user_pages = (TASK_SIZE - FIRST_USER_ADDRESS) / PAGE_SIZE;
> +
> + random_pages = get_rand
The x86 will crash with linux-next during boot due to this series (v5) with the
config below plus CONFIG_DEBUG_VM_PGTABLE=y. I am not sure if v6 would address
it.
https://raw.githubusercontent.com/cailca/linux-mm/master/x86.config
[ 33.862600][T1] page:ea000900 is uninitialized and
26 matches
Mail list logo
