From: a.ryabinin@samsung.com (Andrey Ryabinin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 5/5] arm64: add KASan support
Date: Wed, 15 Jul 2015 11:55:20 +0300 [thread overview]
Message-ID: <55A61FF8.9000603@samsung.com> (raw)
In-Reply-To: <20150714150445.GH13555@e104818-lin.cambridge.arm.com>
On 07/14/2015 06:04 PM, Catalin Marinas wrote:
> On Fri, Jul 10, 2015 at 08:11:03PM +0300, Andrey Ryabinin wrote:
>>>> +#if CONFIG_PGTABLE_LEVELS > 3
>>>> +pud_t kasan_zero_pud[PTRS_PER_PUD] __page_aligned_bss;
>>>> +#endif
>>>> +#if CONFIG_PGTABLE_LEVELS > 2
>>>> +pmd_t kasan_zero_pmd[PTRS_PER_PMD] __page_aligned_bss;
>>>> +#endif
>>>> +pte_t kasan_zero_pte[PTRS_PER_PTE] __page_aligned_bss;
>>>> +
>>>> +static void __init kasan_early_pmd_populate(unsigned long start,
>>>> + unsigned long end, pud_t *pud)
>>>> +{
>>>> + unsigned long addr;
>>>> + unsigned long next;
>>>> + pmd_t *pmd;
>>>> +
>>>> + pmd = pmd_offset(pud, start);
>>>> + for (addr = start; addr < end; addr = next, pmd++) {
>>>> + pmd_populate_kernel(&init_mm, pmd, kasan_zero_pte);
>>>> + next = pmd_addr_end(addr, end);
>>>> + }
>>>> +}
>>>> +
>>>> +static void __init kasan_early_pud_populate(unsigned long start,
>>>> + unsigned long end, pgd_t *pgd)
>>>> +{
>>>> + unsigned long addr;
>>>> + unsigned long next;
>>>> + pud_t *pud;
>>>> +
>>>> + pud = pud_offset(pgd, start);
>>>> + for (addr = start; addr < end; addr = next, pud++) {
>>>> + pud_populate(&init_mm, pud, kasan_zero_pmd);
>>>> + next = pud_addr_end(addr, end);
>>>> + kasan_early_pmd_populate(addr, next, pud);
>>>> + }
>>>> +}
>>>> +
>>>> +static void __init kasan_map_early_shadow(pgd_t *pgdp)
>>>> +{
>>>> + int i;
>>>> + unsigned long start = KASAN_SHADOW_START;
>>>> + unsigned long end = KASAN_SHADOW_END;
>>>> + unsigned long addr;
>>>> + unsigned long next;
>>>> + pgd_t *pgd;
>>>> +
>>>> + for (i = 0; i < PTRS_PER_PTE; i++)
>>>> + set_pte(&kasan_zero_pte[i], pfn_pte(
>>>> + virt_to_pfn(kasan_zero_page), PAGE_KERNEL));
>>>> +
>>>> + pgd = pgd_offset_k(start);
>>>> + for (addr = start; addr < end; addr = next, pgd++) {
>>>> + pgd_populate(&init_mm, pgd, kasan_zero_pud);
>>>> + next = pgd_addr_end(addr, end);
>>>> + kasan_early_pud_populate(addr, next, pgd);
>>>> + }
>>>
>>> I prefer to use "do ... while" constructs similar to __create_mapping()
>>> (or zero_{pgd,pud,pmd}_populate as you are more familiar with them).
>>>
>>> But what I don't get here is that you repopulate the pud page for every
>>> pgd (and so on for pmd). You don't need this recursive call all the way
>>> to kasan_early_pmd_populate() but just sequential:
>>
>> This repopulation needed for 3,2 level page tables configurations.
>>
>> E.g. for 3-level page tables we need to call pud_populate(&init_mm,
>> pud, kasan_zero_pmd) for each pud in [KASAN_SHADOW_START,
>> KASAN_SHADOW_END] range, this causes repopopulation for 4-level page
>> tables, since we need to pud_populate() only [KASAN_SHADOW_START,
>> KASAN_SHADOW_START + PGDIR_SIZE] range.
>
> I'm referring to writing the same information multiple times over the
> same entry. kasan_map_early_shadow() goes over each pgd entry and writes
> the address of kasan_zero_pud. That's fine so far. However, in the same
> loop you call kasan_early_pud_populate(). The latter retrieves the pud
> page via pud_offset(pgd, start) which would always be kasan_zero_pud
Not always. E.g. if we have 3-level page tables pud = pgd, pgd_populate() is nop, and
pud_populate in fact populates pgd.
pud_offset(pgd, start) will return (swapper_pg_dir + pgd_index(start)) and pud_populate()
will fill that entry with the address of kasan_zero_pmd. So we need to pud_populate() for
each pgd.
> because that's what you wrote via pgd_populate() in each pgd entry. So
> for each pgd entry, you keep populating the same kasan_zero_pud page
> with pointers to kasan_zero_pmd. And so on for the pmd.
>
Yes, I'm perfectly understand that. And this was done intentionally since I don't
see the way to make this work for all possible CONFIG_PGTABLE_LEVELS without rewrites
or without #ifdefs (and you didn't like them in v1).
>>> kasan_early_pte_populate();
>>> kasan_early_pmd_populate(..., pte);
>>> kasan_early_pud_populate(..., pmd);
>>> kasan_early_pgd_populate(..., pud);
>>>
>>> (or in reverse order)
>>
>> Unless, I'm missing something, this will either work only with 4-level
>> page tables. We could do this without repopulation by using
>> CONFIG_PGTABLE_LEVELS ifdefs.
>
> Or you could move kasan_early_*_populate outside the loop. You already
> do this for the pte at the beginning of the kasan_map_early_shadow()
> function (and it probably makes more sense to create a separate
> kasan_early_pte_populate).
>
Ok, let's try to implement that.
And for example, let's consider CONFIG_PGTABLE_LEVELS=3 case:
* pgd_populate() is nop, so kasan_early_pgd_populate() won't do anything.
* pud_populate() in kasan_early_pud_populate() actually will setup pgd entries in swapper_pg_dir,
so pud_populate() should be called for the whole shadow range: [KASAN_SHADOW_START, KASAN_SHADOW_END]
IOW: kasan_early_pud_populate(KASAN_SHADOW_START, KASAN_SHADOW_END, kasan_zero_pmd);
We will need to slightly change kasan_early_pud_populate() implementation for that
(Current implementation implies that [start, end) addresses belong to one pgd)
void kasan_early_pud_populate(unsigned long start, unsigned long end, pmd_t *pmd)
{
unsigned long addr;
long next;
for (addr = start; addr < end; addr = next) {
pud_t *pud = pud_offset(pgd_offset_k(addr), addr);
pud_populate(&init_mm, pud, pmd);
next = pud_addr_end(addr, pgd_addr_end(addr, end));
}
}
But, wait! In 4-level page tables case this will be the same repopulation as we had before!
See? The problem here is that pud_populate() but not pgd_populate() populates pgds (3-level page tables case).
So I still don't see the way to avoid repopulation without ifdefs.
Did I miss anything?
WARNING: multiple messages have this Message-ID (diff)
From: Andrey Ryabinin <a.ryabinin@samsung.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
David Keitel <dkeitel@codeaurora.org>,
Will Deacon <will.deacon@arm.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Alexander Potapenko <glider@google.com>,
Dmitry Vyukov <dvyukov@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 5/5] arm64: add KASan support
Date: Wed, 15 Jul 2015 11:55:20 +0300 [thread overview]
Message-ID: <55A61FF8.9000603@samsung.com> (raw)
In-Reply-To: <20150714150445.GH13555@e104818-lin.cambridge.arm.com>
On 07/14/2015 06:04 PM, Catalin Marinas wrote:
> On Fri, Jul 10, 2015 at 08:11:03PM +0300, Andrey Ryabinin wrote:
>>>> +#if CONFIG_PGTABLE_LEVELS > 3
>>>> +pud_t kasan_zero_pud[PTRS_PER_PUD] __page_aligned_bss;
>>>> +#endif
>>>> +#if CONFIG_PGTABLE_LEVELS > 2
>>>> +pmd_t kasan_zero_pmd[PTRS_PER_PMD] __page_aligned_bss;
>>>> +#endif
>>>> +pte_t kasan_zero_pte[PTRS_PER_PTE] __page_aligned_bss;
>>>> +
>>>> +static void __init kasan_early_pmd_populate(unsigned long start,
>>>> + unsigned long end, pud_t *pud)
>>>> +{
>>>> + unsigned long addr;
>>>> + unsigned long next;
>>>> + pmd_t *pmd;
>>>> +
>>>> + pmd = pmd_offset(pud, start);
>>>> + for (addr = start; addr < end; addr = next, pmd++) {
>>>> + pmd_populate_kernel(&init_mm, pmd, kasan_zero_pte);
>>>> + next = pmd_addr_end(addr, end);
>>>> + }
>>>> +}
>>>> +
>>>> +static void __init kasan_early_pud_populate(unsigned long start,
>>>> + unsigned long end, pgd_t *pgd)
>>>> +{
>>>> + unsigned long addr;
>>>> + unsigned long next;
>>>> + pud_t *pud;
>>>> +
>>>> + pud = pud_offset(pgd, start);
>>>> + for (addr = start; addr < end; addr = next, pud++) {
>>>> + pud_populate(&init_mm, pud, kasan_zero_pmd);
>>>> + next = pud_addr_end(addr, end);
>>>> + kasan_early_pmd_populate(addr, next, pud);
>>>> + }
>>>> +}
>>>> +
>>>> +static void __init kasan_map_early_shadow(pgd_t *pgdp)
>>>> +{
>>>> + int i;
>>>> + unsigned long start = KASAN_SHADOW_START;
>>>> + unsigned long end = KASAN_SHADOW_END;
>>>> + unsigned long addr;
>>>> + unsigned long next;
>>>> + pgd_t *pgd;
>>>> +
>>>> + for (i = 0; i < PTRS_PER_PTE; i++)
>>>> + set_pte(&kasan_zero_pte[i], pfn_pte(
>>>> + virt_to_pfn(kasan_zero_page), PAGE_KERNEL));
>>>> +
>>>> + pgd = pgd_offset_k(start);
>>>> + for (addr = start; addr < end; addr = next, pgd++) {
>>>> + pgd_populate(&init_mm, pgd, kasan_zero_pud);
>>>> + next = pgd_addr_end(addr, end);
>>>> + kasan_early_pud_populate(addr, next, pgd);
>>>> + }
>>>
>>> I prefer to use "do ... while" constructs similar to __create_mapping()
>>> (or zero_{pgd,pud,pmd}_populate as you are more familiar with them).
>>>
>>> But what I don't get here is that you repopulate the pud page for every
>>> pgd (and so on for pmd). You don't need this recursive call all the way
>>> to kasan_early_pmd_populate() but just sequential:
>>
>> This repopulation needed for 3,2 level page tables configurations.
>>
>> E.g. for 3-level page tables we need to call pud_populate(&init_mm,
>> pud, kasan_zero_pmd) for each pud in [KASAN_SHADOW_START,
>> KASAN_SHADOW_END] range, this causes repopopulation for 4-level page
>> tables, since we need to pud_populate() only [KASAN_SHADOW_START,
>> KASAN_SHADOW_START + PGDIR_SIZE] range.
>
> I'm referring to writing the same information multiple times over the
> same entry. kasan_map_early_shadow() goes over each pgd entry and writes
> the address of kasan_zero_pud. That's fine so far. However, in the same
> loop you call kasan_early_pud_populate(). The latter retrieves the pud
> page via pud_offset(pgd, start) which would always be kasan_zero_pud
Not always. E.g. if we have 3-level page tables pud = pgd, pgd_populate() is nop, and
pud_populate in fact populates pgd.
pud_offset(pgd, start) will return (swapper_pg_dir + pgd_index(start)) and pud_populate()
will fill that entry with the address of kasan_zero_pmd. So we need to pud_populate() for
each pgd.
> because that's what you wrote via pgd_populate() in each pgd entry. So
> for each pgd entry, you keep populating the same kasan_zero_pud page
> with pointers to kasan_zero_pmd. And so on for the pmd.
>
Yes, I'm perfectly understand that. And this was done intentionally since I don't
see the way to make this work for all possible CONFIG_PGTABLE_LEVELS without rewrites
or without #ifdefs (and you didn't like them in v1).
>>> kasan_early_pte_populate();
>>> kasan_early_pmd_populate(..., pte);
>>> kasan_early_pud_populate(..., pmd);
>>> kasan_early_pgd_populate(..., pud);
>>>
>>> (or in reverse order)
>>
>> Unless, I'm missing something, this will either work only with 4-level
>> page tables. We could do this without repopulation by using
>> CONFIG_PGTABLE_LEVELS ifdefs.
>
> Or you could move kasan_early_*_populate outside the loop. You already
> do this for the pte at the beginning of the kasan_map_early_shadow()
> function (and it probably makes more sense to create a separate
> kasan_early_pte_populate).
>
Ok, let's try to implement that.
And for example, let's consider CONFIG_PGTABLE_LEVELS=3 case:
* pgd_populate() is nop, so kasan_early_pgd_populate() won't do anything.
* pud_populate() in kasan_early_pud_populate() actually will setup pgd entries in swapper_pg_dir,
so pud_populate() should be called for the whole shadow range: [KASAN_SHADOW_START, KASAN_SHADOW_END]
IOW: kasan_early_pud_populate(KASAN_SHADOW_START, KASAN_SHADOW_END, kasan_zero_pmd);
We will need to slightly change kasan_early_pud_populate() implementation for that
(Current implementation implies that [start, end) addresses belong to one pgd)
void kasan_early_pud_populate(unsigned long start, unsigned long end, pmd_t *pmd)
{
unsigned long addr;
long next;
for (addr = start; addr < end; addr = next) {
pud_t *pud = pud_offset(pgd_offset_k(addr), addr);
pud_populate(&init_mm, pud, pmd);
next = pud_addr_end(addr, pgd_addr_end(addr, end));
}
}
But, wait! In 4-level page tables case this will be the same repopulation as we had before!
See? The problem here is that pud_populate() but not pgd_populate() populates pgds (3-level page tables case).
So I still don't see the way to avoid repopulation without ifdefs.
Did I miss anything?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Andrey Ryabinin <a.ryabinin@samsung.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
David Keitel <dkeitel@codeaurora.org>,
Will Deacon <will.deacon@arm.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Alexander Potapenko <glider@google.com>,
Dmitry Vyukov <dvyukov@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 5/5] arm64: add KASan support
Date: Wed, 15 Jul 2015 11:55:20 +0300 [thread overview]
Message-ID: <55A61FF8.9000603@samsung.com> (raw)
In-Reply-To: <20150714150445.GH13555@e104818-lin.cambridge.arm.com>
On 07/14/2015 06:04 PM, Catalin Marinas wrote:
> On Fri, Jul 10, 2015 at 08:11:03PM +0300, Andrey Ryabinin wrote:
>>>> +#if CONFIG_PGTABLE_LEVELS > 3
>>>> +pud_t kasan_zero_pud[PTRS_PER_PUD] __page_aligned_bss;
>>>> +#endif
>>>> +#if CONFIG_PGTABLE_LEVELS > 2
>>>> +pmd_t kasan_zero_pmd[PTRS_PER_PMD] __page_aligned_bss;
>>>> +#endif
>>>> +pte_t kasan_zero_pte[PTRS_PER_PTE] __page_aligned_bss;
>>>> +
>>>> +static void __init kasan_early_pmd_populate(unsigned long start,
>>>> + unsigned long end, pud_t *pud)
>>>> +{
>>>> + unsigned long addr;
>>>> + unsigned long next;
>>>> + pmd_t *pmd;
>>>> +
>>>> + pmd = pmd_offset(pud, start);
>>>> + for (addr = start; addr < end; addr = next, pmd++) {
>>>> + pmd_populate_kernel(&init_mm, pmd, kasan_zero_pte);
>>>> + next = pmd_addr_end(addr, end);
>>>> + }
>>>> +}
>>>> +
>>>> +static void __init kasan_early_pud_populate(unsigned long start,
>>>> + unsigned long end, pgd_t *pgd)
>>>> +{
>>>> + unsigned long addr;
>>>> + unsigned long next;
>>>> + pud_t *pud;
>>>> +
>>>> + pud = pud_offset(pgd, start);
>>>> + for (addr = start; addr < end; addr = next, pud++) {
>>>> + pud_populate(&init_mm, pud, kasan_zero_pmd);
>>>> + next = pud_addr_end(addr, end);
>>>> + kasan_early_pmd_populate(addr, next, pud);
>>>> + }
>>>> +}
>>>> +
>>>> +static void __init kasan_map_early_shadow(pgd_t *pgdp)
>>>> +{
>>>> + int i;
>>>> + unsigned long start = KASAN_SHADOW_START;
>>>> + unsigned long end = KASAN_SHADOW_END;
>>>> + unsigned long addr;
>>>> + unsigned long next;
>>>> + pgd_t *pgd;
>>>> +
>>>> + for (i = 0; i < PTRS_PER_PTE; i++)
>>>> + set_pte(&kasan_zero_pte[i], pfn_pte(
>>>> + virt_to_pfn(kasan_zero_page), PAGE_KERNEL));
>>>> +
>>>> + pgd = pgd_offset_k(start);
>>>> + for (addr = start; addr < end; addr = next, pgd++) {
>>>> + pgd_populate(&init_mm, pgd, kasan_zero_pud);
>>>> + next = pgd_addr_end(addr, end);
>>>> + kasan_early_pud_populate(addr, next, pgd);
>>>> + }
>>>
>>> I prefer to use "do ... while" constructs similar to __create_mapping()
>>> (or zero_{pgd,pud,pmd}_populate as you are more familiar with them).
>>>
>>> But what I don't get here is that you repopulate the pud page for every
>>> pgd (and so on for pmd). You don't need this recursive call all the way
>>> to kasan_early_pmd_populate() but just sequential:
>>
>> This repopulation needed for 3,2 level page tables configurations.
>>
>> E.g. for 3-level page tables we need to call pud_populate(&init_mm,
>> pud, kasan_zero_pmd) for each pud in [KASAN_SHADOW_START,
>> KASAN_SHADOW_END] range, this causes repopopulation for 4-level page
>> tables, since we need to pud_populate() only [KASAN_SHADOW_START,
>> KASAN_SHADOW_START + PGDIR_SIZE] range.
>
> I'm referring to writing the same information multiple times over the
> same entry. kasan_map_early_shadow() goes over each pgd entry and writes
> the address of kasan_zero_pud. That's fine so far. However, in the same
> loop you call kasan_early_pud_populate(). The latter retrieves the pud
> page via pud_offset(pgd, start) which would always be kasan_zero_pud
Not always. E.g. if we have 3-level page tables pud = pgd, pgd_populate() is nop, and
pud_populate in fact populates pgd.
pud_offset(pgd, start) will return (swapper_pg_dir + pgd_index(start)) and pud_populate()
will fill that entry with the address of kasan_zero_pmd. So we need to pud_populate() for
each pgd.
> because that's what you wrote via pgd_populate() in each pgd entry. So
> for each pgd entry, you keep populating the same kasan_zero_pud page
> with pointers to kasan_zero_pmd. And so on for the pmd.
>
Yes, I'm perfectly understand that. And this was done intentionally since I don't
see the way to make this work for all possible CONFIG_PGTABLE_LEVELS without rewrites
or without #ifdefs (and you didn't like them in v1).
>>> kasan_early_pte_populate();
>>> kasan_early_pmd_populate(..., pte);
>>> kasan_early_pud_populate(..., pmd);
>>> kasan_early_pgd_populate(..., pud);
>>>
>>> (or in reverse order)
>>
>> Unless, I'm missing something, this will either work only with 4-level
>> page tables. We could do this without repopulation by using
>> CONFIG_PGTABLE_LEVELS ifdefs.
>
> Or you could move kasan_early_*_populate outside the loop. You already
> do this for the pte at the beginning of the kasan_map_early_shadow()
> function (and it probably makes more sense to create a separate
> kasan_early_pte_populate).
>
Ok, let's try to implement that.
And for example, let's consider CONFIG_PGTABLE_LEVELS=3 case:
* pgd_populate() is nop, so kasan_early_pgd_populate() won't do anything.
* pud_populate() in kasan_early_pud_populate() actually will setup pgd entries in swapper_pg_dir,
so pud_populate() should be called for the whole shadow range: [KASAN_SHADOW_START, KASAN_SHADOW_END]
IOW: kasan_early_pud_populate(KASAN_SHADOW_START, KASAN_SHADOW_END, kasan_zero_pmd);
We will need to slightly change kasan_early_pud_populate() implementation for that
(Current implementation implies that [start, end) addresses belong to one pgd)
void kasan_early_pud_populate(unsigned long start, unsigned long end, pmd_t *pmd)
{
unsigned long addr;
long next;
for (addr = start; addr < end; addr = next) {
pud_t *pud = pud_offset(pgd_offset_k(addr), addr);
pud_populate(&init_mm, pud, pmd);
next = pud_addr_end(addr, pgd_addr_end(addr, end));
}
}
But, wait! In 4-level page tables case this will be the same repopulation as we had before!
See? The problem here is that pud_populate() but not pgd_populate() populates pgds (3-level page tables case).
So I still don't see the way to avoid repopulation without ifdefs.
Did I miss anything?
next prev parent reply other threads:[~2015-07-15 8:55 UTC|newest]
Thread overview: 127+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-15 13:58 [PATCH v2 0/5] KASan for arm64 Andrey Ryabinin
2015-05-15 13:58 ` Andrey Ryabinin
2015-05-15 13:58 ` Andrey Ryabinin
2015-05-15 13:59 ` [PATCH v2 1/5] kasan, x86: move KASAN_SHADOW_OFFSET to the arch Kconfig Andrey Ryabinin
2015-05-15 13:59 ` Andrey Ryabinin
2015-05-15 13:59 ` Andrey Ryabinin
2015-05-16 11:27 ` Paul Bolle
2015-05-16 11:27 ` Paul Bolle
2015-05-16 11:27 ` Paul Bolle
2015-05-18 7:43 ` Andrey Ryabinin
2015-05-18 7:43 ` Andrey Ryabinin
2015-05-18 7:43 ` Andrey Ryabinin
2015-05-18 8:34 ` Paul Bolle
2015-05-18 8:34 ` Paul Bolle
2015-05-18 8:34 ` Paul Bolle
2015-05-15 13:59 ` [PATCH v2 2/5] x86: kasan: fix types in kasan page tables declarations Andrey Ryabinin
2015-05-15 13:59 ` Andrey Ryabinin
2015-05-15 13:59 ` Andrey Ryabinin
2015-05-15 13:59 ` [PATCH v2 3/5] x86: kasan: generalize populate_zero_shadow() code Andrey Ryabinin
2015-05-15 13:59 ` Andrey Ryabinin
2015-05-15 13:59 ` Andrey Ryabinin
2015-05-15 13:59 ` [PATCH v2 4/5] kasan, x86: move populate_zero_shadow() out of arch directory Andrey Ryabinin
2015-05-15 13:59 ` Andrey Ryabinin
2015-05-15 13:59 ` Andrey Ryabinin
2015-05-15 13:59 ` [PATCH v2 5/5] arm64: add KASan support Andrey Ryabinin
2015-05-15 13:59 ` Andrey Ryabinin
2015-05-15 13:59 ` Andrey Ryabinin
2015-05-26 13:35 ` Linus Walleij
2015-05-26 13:35 ` Linus Walleij
2015-05-26 13:35 ` Linus Walleij
2015-05-26 14:12 ` Andrey Ryabinin
2015-05-26 14:12 ` Andrey Ryabinin
2015-05-26 14:12 ` Andrey Ryabinin
2015-05-26 14:22 ` Andrey Ryabinin
2015-05-26 14:22 ` Andrey Ryabinin
2015-05-26 14:22 ` Andrey Ryabinin
2015-05-26 20:28 ` Linus Walleij
2015-05-26 20:28 ` Linus Walleij
2015-05-26 20:28 ` Linus Walleij
2015-05-27 12:40 ` Linus Walleij
2015-05-27 12:40 ` Linus Walleij
2015-05-27 12:40 ` Linus Walleij
2015-06-11 13:39 ` Linus Walleij
2015-06-11 13:39 ` Linus Walleij
2015-06-11 13:39 ` Linus Walleij
2015-06-12 18:14 ` Andrey Ryabinin
2015-06-12 18:14 ` Andrey Ryabinin
2015-06-12 18:14 ` Andrey Ryabinin
2015-06-13 15:25 ` Linus Walleij
2015-06-13 15:25 ` Linus Walleij
2015-06-13 15:25 ` Linus Walleij
2015-06-17 21:32 ` Andrey Ryabinin
2015-06-17 21:32 ` Andrey Ryabinin
2015-06-17 21:32 ` Andrey Ryabinin
2015-07-21 10:36 ` Linus Walleij
2015-07-21 10:36 ` Linus Walleij
2015-07-21 10:36 ` Linus Walleij
2015-07-21 14:27 ` Andrey Ryabinin
2015-07-21 14:27 ` Andrey Ryabinin
2015-07-21 14:27 ` Andrey Ryabinin
2015-07-21 21:27 ` Linus Walleij
2015-07-21 21:27 ` Linus Walleij
2015-07-21 21:27 ` Linus Walleij
2015-07-22 17:54 ` Andrey Ryabinin
2015-07-22 17:54 ` Andrey Ryabinin
2015-07-22 17:54 ` Andrey Ryabinin
2015-08-19 12:14 ` Linus Walleij
2015-08-19 12:14 ` Linus Walleij
2015-08-19 12:14 ` Linus Walleij
2015-08-19 14:51 ` Andrey Ryabinin
2015-08-19 14:51 ` Andrey Ryabinin
2015-08-19 14:51 ` Andrey Ryabinin
2015-08-24 13:02 ` Linus Walleij
2015-08-24 13:02 ` Linus Walleij
2015-08-24 13:02 ` Linus Walleij
2015-08-24 13:15 ` Russell King - ARM Linux
2015-08-24 13:15 ` Russell King - ARM Linux
2015-08-24 13:15 ` Russell King - ARM Linux
2015-08-24 13:45 ` Linus Walleij
2015-08-24 13:45 ` Linus Walleij
2015-08-24 13:45 ` Linus Walleij
2015-08-24 14:15 ` Andrey Ryabinin
2015-08-24 14:15 ` Andrey Ryabinin
2015-08-24 14:15 ` Andrey Ryabinin
2015-08-24 15:44 ` Vladimir Murzin
2015-08-24 15:44 ` Vladimir Murzin
2015-08-24 15:44 ` Vladimir Murzin
2015-08-24 16:00 ` Andrey Ryabinin
2015-08-24 16:00 ` Andrey Ryabinin
2015-08-24 16:00 ` Andrey Ryabinin
2015-08-24 16:16 ` Vladimir Murzin
2015-08-24 16:16 ` Vladimir Murzin
2015-08-24 16:16 ` Vladimir Murzin
2015-08-24 16:18 ` Andrey Ryabinin
2015-08-24 16:18 ` Andrey Ryabinin
2015-08-24 16:18 ` Andrey Ryabinin
2015-08-24 17:47 ` Russell King - ARM Linux
2015-08-24 17:47 ` Russell King - ARM Linux
2015-08-24 17:47 ` Russell King - ARM Linux
2015-08-25 9:15 ` Will Deacon
2015-08-25 9:15 ` Will Deacon
2015-08-25 9:15 ` Will Deacon
2015-07-08 15:48 ` Catalin Marinas
2015-07-08 15:48 ` Catalin Marinas
2015-07-08 15:48 ` Catalin Marinas
2015-07-10 17:11 ` Andrey Ryabinin
2015-07-10 17:11 ` Andrey Ryabinin
2015-07-10 17:11 ` Andrey Ryabinin
2015-07-14 15:04 ` Catalin Marinas
2015-07-14 15:04 ` Catalin Marinas
2015-07-14 15:04 ` Catalin Marinas
2015-07-15 8:55 ` Andrey Ryabinin [this message]
2015-07-15 8:55 ` Andrey Ryabinin
2015-07-15 8:55 ` Andrey Ryabinin
2015-07-15 16:37 ` Catalin Marinas
2015-07-15 16:37 ` Catalin Marinas
2015-07-15 16:37 ` Catalin Marinas
2015-07-16 15:30 ` Andrey Ryabinin
2015-07-16 15:30 ` Andrey Ryabinin
2015-07-16 15:30 ` Andrey Ryabinin
2015-07-16 16:03 ` Catalin Marinas
2015-07-16 16:03 ` Catalin Marinas
2015-07-16 16:03 ` Catalin Marinas
2015-07-17 13:13 ` Andrey Ryabinin
2015-07-17 13:13 ` Andrey Ryabinin
2015-07-17 13:13 ` Andrey Ryabinin
2015-07-18 2:44 ` Patrick Daly
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55A61FF8.9000603@samsung.com \
--to=a.ryabinin@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.