* Re: [RFC v2 8/8] arm64, kexec: enable MMU during kexec relocation
From: Pavel Tatashin @ 2019-07-31 16:01 UTC (permalink / raw)
To: Mark Rutland
Cc: James Morris, Sasha Levin, Eric W. Biederman, kexec mailing list,
LKML, Jonathan Corbet, Catalin Marinas, will,
Linux Doc Mailing List, Linux ARM, Marc Zyngier, James Morse,
Vladimir Murzin, Matthias Brugger, Bhupesh Sharma
In-Reply-To: <20190731155042.GF39768@lakrids.cambridge.arm.com>
> For various reasons, one cannot safely use Set/Way operations in
> portable code. They only make sense for low-level platform-specific
> firmware performing power management operations.
>
> If you need to perform D-cache maintenance, you must use the VA
> operations to do so.
Hi Mark,
I see, thank you for letting me know. I will do d-cache flushing by VA
in the next iteration. First I need to root cause/fix the bug
described in the cover letter.
Thank you,
Pasha
^ permalink raw reply
* Re: [RFC v2 0/8] arm64: MMU enabled kexec relocation
From: Mark Rutland @ 2019-07-31 16:32 UTC (permalink / raw)
To: Pavel Tatashin
Cc: jmorris, sashal, ebiederm, kexec, linux-kernel, corbet,
catalin.marinas, will, linux-doc, linux-arm-kernel, marc.zyngier,
james.morse, vladimir.murzin, matthias.bgg, bhsharma
In-Reply-To: <20190731153857.4045-1-pasha.tatashin@soleen.com>
Hi Pavel,
Generally, the cover letter should state up-front what the goal is (or
what problem you're trying to solve). It would be really helpful to have
that so that we understand what you're trying to achieve, and why.
Messing with the MMU is often fraught with danger (and very painful to
debug, as you are now aware), and so far we've tried to minimize the
number of places where we have to do so.
On Wed, Jul 31, 2019 at 11:38:49AM -0400, Pavel Tatashin wrote:
> Changelog from previous RFC:
> - Added trans_table support for both hibernate and kexec.
> - Fixed performance issue, where enabling MMU did not yield the
> actual performance improvement.
>
> Bug:
> With the current state, this patch series works on kernels booted with EL1
> mode, but for some reason, when elevated to EL2 mode reboot freezes in
> both QEMU and on real hardware.
>
> The freeze happens in:
>
> arch/arm64/kernel/relocate_kernel.S
> turn_on_mmu()
>
> Right after sctlr_el2 is written (MMU on EL2 is enabled)
>
> msr sctlr_el2, \tmp1
>
> I've been studying all the relevant control registers for EL2, but do not
> see what might be causing this hang:
>
> MAIR_EL2 is set to be exactly the same as MAIR_EL1 0xbbff440c0400
>
> TCR_EL2 0x80843510
> Enabled bits:
> PS Physical Address Size. (0b100 44 bits, 16TB.)
> SH0 Shareability 11 Inner Shareable
> ORGN0 Normal memory, Outer Write-Back Read-Allocate Write-Allocate Cach.
> IRGN0 Normal memory, Inner Write-Back Read-Allocate Write-Allocate Cach.
> T0SZ 01 0000
>
> SCTLR_EL2 0x30e5183f
> RES1 : Reserve ones
> M : MMU enabled
> A : Align check
> C : Cacheability control
> SA : SP Alignment check enable
> IESB : Implicit Error Synchronization event
> I : Instruction access Cacheability
>
> TTBR0_EL2 0x1b3069000 (address of trans_table)
>
> Any suggestion of what else might be missing that causes this freeze when
> MMU is enabled in EL2?
>
> =====
> Here is the current data from the real hardware:
> (because of bug, I forced EL1 mode by setting el2_switch always to zero in
> cpu_soft_restart()):
>
> For this experiment, the size of kernel plus initramfs is 25M. If initramfs
> was larger, than the improvements would be even greater, as time spent in
> relocation is proportional to the size of relocation.
>
> Previously:
> kernel shutdown 0.022131328s
> relocation 0.440510736s
> kernel startup 0.294706768s
In total this takes ~0.76s...
>
> Relocation was taking: 58.2% of reboot time
>
> Now:
> kernel shutdown 0.032066576s
> relocation 0.022158152s
> kernel startup 0.296055880s
... and this takes ~0.35s
So do we really need this complexity for a few blinks of an eye?
Thanks,
Mark.
^ permalink raw reply
* Re: [RFC v2 0/8] arm64: MMU enabled kexec relocation
From: Pavel Tatashin @ 2019-07-31 16:40 UTC (permalink / raw)
To: Mark Rutland
Cc: James Morris, Sasha Levin, Eric W. Biederman, kexec mailing list,
LKML, Jonathan Corbet, Catalin Marinas, will,
Linux Doc Mailing List, Linux ARM, Marc Zyngier, James Morse,
Vladimir Murzin, Matthias Brugger, Bhupesh Sharma
In-Reply-To: <20190731163258.GH39768@lakrids.cambridge.arm.com>
On Wed, Jul 31, 2019 at 12:33 PM Mark Rutland <mark.rutland@arm.com> wrote:
>
> Hi Pavel,
>
> Generally, the cover letter should state up-front what the goal is (or
> what problem you're trying to solve). It would be really helpful to have
> that so that we understand what you're trying to achieve, and why.
>
> Messing with the MMU is often fraught with danger (and very painful to
> debug, as you are now aware), and so far we've tried to minimize the
> number of places where we have to do so.
Hi Mark,
I understand, this is why I first went another route of solving this
problem: pre-reserving contiguous memory, and avoid relocation
entirely (the same as what happens during crash reboot). But, that
solution was not accepted because it introduces a change to the common
code to solve ARM specific problem. So, James Morse, and other
suggested that I take a look at the root of the problem, and enable
MMU during relocation by doing what is already done during hibernate
restore.
>
> On Wed, Jul 31, 2019 at 11:38:49AM -0400, Pavel Tatashin wrote:
> > Changelog from previous RFC:
> > - Added trans_table support for both hibernate and kexec.
> > - Fixed performance issue, where enabling MMU did not yield the
> > actual performance improvement.
> >
> > Bug:
> > With the current state, this patch series works on kernels booted with EL1
> > mode, but for some reason, when elevated to EL2 mode reboot freezes in
> > both QEMU and on real hardware.
> >
> > The freeze happens in:
> >
> > arch/arm64/kernel/relocate_kernel.S
> > turn_on_mmu()
> >
> > Right after sctlr_el2 is written (MMU on EL2 is enabled)
> >
> > msr sctlr_el2, \tmp1
> >
> > I've been studying all the relevant control registers for EL2, but do not
> > see what might be causing this hang:
> >
> > MAIR_EL2 is set to be exactly the same as MAIR_EL1 0xbbff440c0400
> >
> > TCR_EL2 0x80843510
> > Enabled bits:
> > PS Physical Address Size. (0b100 44 bits, 16TB.)
> > SH0 Shareability 11 Inner Shareable
> > ORGN0 Normal memory, Outer Write-Back Read-Allocate Write-Allocate Cach.
> > IRGN0 Normal memory, Inner Write-Back Read-Allocate Write-Allocate Cach.
> > T0SZ 01 0000
> >
> > SCTLR_EL2 0x30e5183f
> > RES1 : Reserve ones
> > M : MMU enabled
> > A : Align check
> > C : Cacheability control
> > SA : SP Alignment check enable
> > IESB : Implicit Error Synchronization event
> > I : Instruction access Cacheability
> >
> > TTBR0_EL2 0x1b3069000 (address of trans_table)
> >
> > Any suggestion of what else might be missing that causes this freeze when
> > MMU is enabled in EL2?
> >
> > =====
>
> > Here is the current data from the real hardware:
> > (because of bug, I forced EL1 mode by setting el2_switch always to zero in
> > cpu_soft_restart()):
> >
> > For this experiment, the size of kernel plus initramfs is 25M. If initramfs
> > was larger, than the improvements would be even greater, as time spent in
> > relocation is proportional to the size of relocation.
> >
> > Previously:
> > kernel shutdown 0.022131328s
> > relocation 0.440510736s
> > kernel startup 0.294706768s
>
> In total this takes ~0.76s...
>
> >
> > Relocation was taking: 58.2% of reboot time
> >
> > Now:
> > kernel shutdown 0.032066576s
> > relocation 0.022158152s
> > kernel startup 0.296055880s
>
> ... and this takes ~0.35s
>
> So do we really need this complexity for a few blinks of an eye?
Yes, we have an extremely tight reboot budget, 0.35s is not an acceptable waste.
>
> Thanks,
> Mark.
^ permalink raw reply
* Re: [PATCH v6 1/2] arm64: Define Documentation/arm64/tagged-address-abi.rst
From: Dave Hansen @ 2019-07-31 16:43 UTC (permalink / raw)
To: Vincenzo Frascino, linux-arm-kernel, linux-doc, linux-mm,
linux-arch, linux-kselftest, linux-kernel
Cc: Catalin Marinas, Will Deacon, Andrey Konovalov, Szabolcs Nagy
In-Reply-To: <20190725135044.24381-2-vincenzo.frascino@arm.com>
On 7/25/19 6:50 AM, Vincenzo Frascino wrote:
> With the relaxed ABI proposed through this document, it is now possible
> to pass tagged pointers to the syscalls, when these pointers are in
> memory ranges obtained by an anonymous (MAP_ANONYMOUS) mmap().
I don't see a lot of description of why this restriction is necessary.
What's the problem with supporting MAP_SHARED?
^ permalink raw reply
* Re: [RFC v2 0/8] arm64: MMU enabled kexec relocation
From: Mark Rutland @ 2019-07-31 16:50 UTC (permalink / raw)
To: Pavel Tatashin
Cc: James Morris, Sasha Levin, Eric W. Biederman, kexec mailing list,
LKML, Jonathan Corbet, Catalin Marinas, will,
Linux Doc Mailing List, Linux ARM, Marc Zyngier, James Morse,
Vladimir Murzin, Matthias Brugger, Bhupesh Sharma
In-Reply-To: <CA+CK2bAYUFBBGo-LHBK4UWRK1tpx3AZ4Z9NkDxiDK0UYEDozaQ@mail.gmail.com>
On Wed, Jul 31, 2019 at 12:40:51PM -0400, Pavel Tatashin wrote:
> On Wed, Jul 31, 2019 at 12:33 PM Mark Rutland <mark.rutland@arm.com> wrote:
> >
> > Hi Pavel,
> >
> > Generally, the cover letter should state up-front what the goal is (or
> > what problem you're trying to solve). It would be really helpful to have
> > that so that we understand what you're trying to achieve, and why.
[...]
> > > Here is the current data from the real hardware:
> > > (because of bug, I forced EL1 mode by setting el2_switch always to zero in
> > > cpu_soft_restart()):
> > >
> > > For this experiment, the size of kernel plus initramfs is 25M. If initramfs
> > > was larger, than the improvements would be even greater, as time spent in
> > > relocation is proportional to the size of relocation.
> > >
> > > Previously:
> > > kernel shutdown 0.022131328s
> > > relocation 0.440510736s
> > > kernel startup 0.294706768s
> >
> > In total this takes ~0.76s...
> >
> > >
> > > Relocation was taking: 58.2% of reboot time
> > >
> > > Now:
> > > kernel shutdown 0.032066576s
> > > relocation 0.022158152s
> > > kernel startup 0.296055880s
> >
> > ... and this takes ~0.35s
> >
> > So do we really need this complexity for a few blinks of an eye?
>
> Yes, we have an extremely tight reboot budget, 0.35s is not an acceptable waste.
Could you please elaborate on your use-case?
Understanfin what you're trying to achieve would help us to understand
which solutions make sense.
Thanks,
Mark.
^ permalink raw reply
* Re: [RFC v2 0/8] arm64: MMU enabled kexec relocation
From: Pavel Tatashin @ 2019-07-31 17:04 UTC (permalink / raw)
To: Mark Rutland
Cc: James Morris, Sasha Levin, Eric W. Biederman, kexec mailing list,
LKML, Jonathan Corbet, Catalin Marinas, will,
Linux Doc Mailing List, Linux ARM, Marc Zyngier, James Morse,
Vladimir Murzin, Matthias Brugger, Bhupesh Sharma
In-Reply-To: <20190731165007.GJ39768@lakrids.cambridge.arm.com>
On Wed, Jul 31, 2019 at 12:50 PM Mark Rutland <mark.rutland@arm.com> wrote:
>
> On Wed, Jul 31, 2019 at 12:40:51PM -0400, Pavel Tatashin wrote:
> > On Wed, Jul 31, 2019 at 12:33 PM Mark Rutland <mark.rutland@arm.com> wrote:
> > >
> > > Hi Pavel,
> > >
> > > Generally, the cover letter should state up-front what the goal is (or
> > > what problem you're trying to solve). It would be really helpful to have
> > > that so that we understand what you're trying to achieve, and why.
>
> [...]
>
> > > > Here is the current data from the real hardware:
> > > > (because of bug, I forced EL1 mode by setting el2_switch always to zero in
> > > > cpu_soft_restart()):
> > > >
> > > > For this experiment, the size of kernel plus initramfs is 25M. If initramfs
> > > > was larger, than the improvements would be even greater, as time spent in
> > > > relocation is proportional to the size of relocation.
> > > >
> > > > Previously:
> > > > kernel shutdown 0.022131328s
> > > > relocation 0.440510736s
> > > > kernel startup 0.294706768s
> > >
> > > In total this takes ~0.76s...
> > >
> > > >
> > > > Relocation was taking: 58.2% of reboot time
> > > >
> > > > Now:
> > > > kernel shutdown 0.032066576s
> > > > relocation 0.022158152s
> > > > kernel startup 0.296055880s
> > >
> > > ... and this takes ~0.35s
> > >
> > > So do we really need this complexity for a few blinks of an eye?
> >
> > Yes, we have an extremely tight reboot budget, 0.35s is not an acceptable waste.
>
> Could you please elaborate on your use-case?
>
> Understanfin what you're trying to achieve would help us to understand
> which solutions make sense.
An extremely high availability device with an update story utilizing
kexec functionality for a faster kernel update and also for being able
to preserve some state in memory without wasting the time of copying
it to and from a backing storage. We at Microsoft will be using a
fleet of these devices. The total reboot budget is less than half a
second, out of which 0.44s is currently spent in kexec relocation.
Pasha
>
> Thanks,
> Mark.
^ permalink raw reply
* Re: [PATCH v3 1/2] mm/page_idle: Add per-pid idle page tracking using virtual indexing
From: Joel Fernandes @ 2019-07-31 17:19 UTC (permalink / raw)
To: Minchan Kim
Cc: linux-kernel, Alexey Dobriyan, Andrew Morton, Brendan Gregg,
Christian Hansen, dancol, fmayer, joaodias, Jonathan Corbet,
Kees Cook, kernel-team, linux-api, linux-doc, linux-fsdevel,
linux-mm, Michal Hocko, Mike Rapoport, namhyung, Roman Gushchin,
Stephen Rothwell, surenb, tkjos, Vladimir Davydov,
Vlastimil Babka, wvw
In-Reply-To: <20190731085335.GD155569@google.com>
On Wed, Jul 31, 2019 at 05:53:35PM +0900, Minchan Kim wrote:
> Hi Joel,
>
> On Fri, Jul 26, 2019 at 11:23:18AM -0400, Joel Fernandes (Google) wrote:
> > The page_idle tracking feature currently requires looking up the pagemap
> > for a process followed by interacting with /sys/kernel/mm/page_idle.
> > Looking up PFN from pagemap in Android devices is not supported by
> > unprivileged process and requires SYS_ADMIN and gives 0 for the PFN.
> >
[snip]
> > index 77eb628ecc7f..a58dd74606e9 100644
> > --- a/fs/proc/base.c
> > +++ b/fs/proc/base.c
> > @@ -3021,6 +3021,9 @@ static const struct pid_entry tgid_base_stuff[] = {
> > REG("smaps", S_IRUGO, proc_pid_smaps_operations),
> > REG("smaps_rollup", S_IRUGO, proc_pid_smaps_rollup_operations),
> > REG("pagemap", S_IRUSR, proc_pagemap_operations),
> > +#ifdef CONFIG_IDLE_PAGE_TRACKING
> > + REG("page_idle", S_IRUSR|S_IWUSR, proc_page_idle_operations),
> > +#endif
> > #endif
> > #ifdef CONFIG_SECURITY
> > DIR("attr", S_IRUGO|S_IXUGO, proc_attr_dir_inode_operations, proc_attr_dir_operations),
> > diff --git a/fs/proc/internal.h b/fs/proc/internal.h
> > index cd0c8d5ce9a1..bc9371880c63 100644
> > --- a/fs/proc/internal.h
> > +++ b/fs/proc/internal.h
> > @@ -293,6 +293,7 @@ extern const struct file_operations proc_pid_smaps_operations;
> > extern const struct file_operations proc_pid_smaps_rollup_operations;
> > extern const struct file_operations proc_clear_refs_operations;
> > extern const struct file_operations proc_pagemap_operations;
> > +extern const struct file_operations proc_page_idle_operations;
> >
> > extern unsigned long task_vsize(struct mm_struct *);
> > extern unsigned long task_statm(struct mm_struct *,
> > diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> > index 4d2b860dbc3f..11ccc53da38e 100644
> > --- a/fs/proc/task_mmu.c
> > +++ b/fs/proc/task_mmu.c
> > @@ -1642,6 +1642,63 @@ const struct file_operations proc_pagemap_operations = {
> > .open = pagemap_open,
> > .release = pagemap_release,
> > };
> > +
> > +#ifdef CONFIG_IDLE_PAGE_TRACKING
> > +static ssize_t proc_page_idle_read(struct file *file, char __user *buf,
> > + size_t count, loff_t *ppos)
> > +{
> > + int ret;
> > + struct task_struct *tsk = get_proc_task(file_inode(file));
> > +
> > + if (!tsk)
> > + return -EINVAL;
> > + ret = page_idle_proc_read(file, buf, count, ppos, tsk);
> > + put_task_struct(tsk);
>
> Why do you need task_struct here? You already got the task in open
> and got mm there so you could pass the MM here instead of task.
Good point, will just use mm.
[snip]
> > diff --git a/include/linux/page_idle.h b/include/linux/page_idle.h
> > index 1e894d34bdce..f1bc2640d85e 100644
> > --- a/include/linux/page_idle.h
> > +++ b/include/linux/page_idle.h
> > @@ -106,6 +106,10 @@ static inline void clear_page_idle(struct page *page)
> > }
> > #endif /* CONFIG_64BIT */
> >
> > +ssize_t page_idle_proc_write(struct file *file,
> > + char __user *buf, size_t count, loff_t *ppos, struct task_struct *tsk);
> > +ssize_t page_idle_proc_read(struct file *file,
> > + char __user *buf, size_t count, loff_t *ppos, struct task_struct *tsk);
> > #else /* !CONFIG_IDLE_PAGE_TRACKING */
> >
> > static inline bool page_is_young(struct page *page)
> > diff --git a/mm/page_idle.c b/mm/page_idle.c
> > index 295512465065..86244f7f1faa 100644
> > --- a/mm/page_idle.c
> > +++ b/mm/page_idle.c
> > @@ -5,12 +5,15 @@
> > #include <linux/sysfs.h>
> > #include <linux/kobject.h>
> > #include <linux/mm.h>
> > -#include <linux/mmzone.h>
> > -#include <linux/pagemap.h>
> > -#include <linux/rmap.h>
> > #include <linux/mmu_notifier.h>
> > +#include <linux/mmzone.h>
> > #include <linux/page_ext.h>
> > #include <linux/page_idle.h>
> > +#include <linux/pagemap.h>
> > +#include <linux/rmap.h>
> > +#include <linux/sched/mm.h>
> > +#include <linux/swap.h>
> > +#include <linux/swapops.h>
> >
> > #define BITMAP_CHUNK_SIZE sizeof(u64)
> > #define BITMAP_CHUNK_BITS (BITMAP_CHUNK_SIZE * BITS_PER_BYTE)
> > @@ -25,18 +28,13 @@
> > * page tracking. With such an indicator of user pages we can skip isolated
> > * pages, but since there are not usually many of them, it will hardly affect
> > * the overall result.
> > - *
> > - * This function tries to get a user memory page by pfn as described above.
> > */
> > -static struct page *page_idle_get_page(unsigned long pfn)
> > +static struct page *page_idle_get_page(struct page *page_in)
>
> Looks weird function name after you changed the argument.
> Maybe "bool check_valid_page(struct page *page)"?
I don't think so, this function does a get_page_unless_zero() on the page as well.
> > {
> > struct page *page;
> > pg_data_t *pgdat;
> >
> > - if (!pfn_valid(pfn))
> > - return NULL;
> > -
> > - page = pfn_to_page(pfn);
> > + page = page_in;
> > if (!page || !PageLRU(page) ||
> > !get_page_unless_zero(page))
> > return NULL;
> > @@ -51,6 +49,18 @@ static struct page *page_idle_get_page(unsigned long pfn)
> > return page;
> > }
> >
> > +/*
> > + * This function tries to get a user memory page by pfn as described above.
> > + */
> > +static struct page *page_idle_get_page_pfn(unsigned long pfn)
>
> So we could use page_idle_get_page name here.
Based on above comment, I prefer to keep same name. Do you agree?
> > + return page_idle_get_page(pfn_to_page(pfn));
> > +}
> > +
> > static bool page_idle_clear_pte_refs_one(struct page *page,
> > struct vm_area_struct *vma,
> > unsigned long addr, void *arg)
> > @@ -118,6 +128,47 @@ static void page_idle_clear_pte_refs(struct page *page)
> > unlock_page(page);
> > }
> >
> > +/* Helper to get the start and end frame given a pos and count */
> > +static int page_idle_get_frames(loff_t pos, size_t count, struct mm_struct *mm,
> > + unsigned long *start, unsigned long *end)
> > +{
> > + unsigned long max_frame;
> > +
> > + /* If an mm is not given, assume we want physical frames */
> > + max_frame = mm ? (mm->task_size >> PAGE_SHIFT) : max_pfn;
> > +
> > + if (pos % BITMAP_CHUNK_SIZE || count % BITMAP_CHUNK_SIZE)
> > + return -EINVAL;
> > +
> > + *start = pos * BITS_PER_BYTE;
> > + if (*start >= max_frame)
> > + return -ENXIO;
> > +
> > + *end = *start + count * BITS_PER_BYTE;
> > + if (*end > max_frame)
> > + *end = max_frame;
> > + return 0;
> > +}
> > +
> > +static bool page_really_idle(struct page *page)
>
> Just minor:
> Instead of creating new API, could we combine page_is_idle with
> introducing furthere argument pte_check?
I cannot see in the code where pte_check will be false when this is called? I
could rename the function to page_idle_check_ptes() if that's Ok with you.
[snip]
> +
> > +static int pte_page_idle_proc_range(pmd_t *pmd, unsigned long addr,
> > + unsigned long end,
> > + struct mm_walk *walk)
> > +{
> > + struct vm_area_struct *vma = walk->vma;
> > + pte_t *pte;
> > + spinlock_t *ptl;
> > + struct page *page;
> > +
> > + ptl = pmd_trans_huge_lock(pmd, vma);
> > + if (ptl) {
> > + if (pmd_present(*pmd)) {
> > + page = follow_trans_huge_pmd(vma, addr, pmd,
> > + FOLL_DUMP|FOLL_WRITE);
> > + if (!IS_ERR_OR_NULL(page))
> > + add_page_idle_list(page, addr, walk);
> > + }
> > + spin_unlock(ptl);
> > + return 0;
> > + }
> > +
> > + if (pmd_trans_unstable(pmd))
> > + return 0;
> > +
> > + pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, &ptl);
> > + for (; addr != end; pte++, addr += PAGE_SIZE) {
> > + /*
> > + * We add swapped pages to the idle_page_list so that we can
> > + * reported to userspace that they are idle.
> > + */
> > + if (is_swap_pte(*pte)) {
>
> I suggested "let's consider every swapped out pages as IDLE" but
> let's think about this case:
>
> 1. mark heap of the process as IDLE
> 2. process touch working set
> 3. process's heap pages are swap out by meory spike or madvise
> 4. heap profiler investigates the process's IDLE page and surprised all of
> heap are idle.
>
> It's the good scenario for other purpose because non-idle pages(IOW,
> workingset) could be readahead when the app will restart.
>
> Maybe, squeeze the idle bit in the swap pte to check it.
Ok, I will look more into this. Konstantin had similar ideas here too.
> > +ssize_t page_idle_proc_generic(struct file *file, char __user *ubuff,
> > + size_t count, loff_t *pos,
> > + struct task_struct *tsk, int write)
> > +{
> > + int ret;
> > + char *buffer;
> > + u64 *out;
> > + unsigned long start_addr, end_addr, start_frame, end_frame;
> > + struct mm_struct *mm = file->private_data;
> > + struct mm_walk walk = { .pmd_entry = pte_page_idle_proc_range, };
> > + struct page_node *cur;
> > + struct page_idle_proc_priv priv;
> > + bool walk_error = false;
> > + LIST_HEAD(idle_page_list);
> > +
> > + if (!mm || !mmget_not_zero(mm))
> > + return -EINVAL;
> > +
> > + if (count > PAGE_SIZE)
> > + count = PAGE_SIZE;
> > +
> > + buffer = kzalloc(PAGE_SIZE, GFP_KERNEL);
> > + if (!buffer) {
> > + ret = -ENOMEM;
> > + goto out_mmput;
> > + }
> > + out = (u64 *)buffer;
> > +
> > + if (write && copy_from_user(buffer, ubuff, count)) {
> > + ret = -EFAULT;
> > + goto out;
> > + }
> > +
> > + ret = page_idle_get_frames(*pos, count, mm, &start_frame, &end_frame);
> > + if (ret)
> > + goto out;
> > +
> > + start_addr = (start_frame << PAGE_SHIFT);
> > + end_addr = (end_frame << PAGE_SHIFT);
> > + priv.buffer = buffer;
> > + priv.start_addr = start_addr;
> > + priv.write = write;
> > +
> > + priv.idle_page_list = &idle_page_list;
> > + priv.cur_page_node = 0;
> > + priv.page_nodes = kzalloc(sizeof(struct page_node) *
> > + (end_frame - start_frame), GFP_KERNEL);
> > + if (!priv.page_nodes) {
> > + ret = -ENOMEM;
> > + goto out;
> > + }
> > +
> > + walk.private = &priv;
> > + walk.mm = mm;
> > +
> > + down_read(&mm->mmap_sem);
> > +
> > + /*
> > + * idle_page_list is needed because walk_page_vma() holds ptlock which
> > + * deadlocks with page_idle_clear_pte_refs(). So we have to collect all
> > + * pages first, and then call page_idle_clear_pte_refs().
> > + */
>
> Thanks for the comment, I was curious why you want to have
> idle_page_list and the reason is here.
>
> How about making this /proc/<pid>/page_idle per-process granuariy,
> unlike system level /sys/xxx/page_idle? What I meant is not to check
> rmap to see any reference from random process but just check only
> access from the target process. It would be more proper as /proc/
> <pid>/ interface and good for per-process tracking as well as
> fast.
I prefer not to do this for the following reasons:
(1) It makes a feature lost, now accesses to shared pages will not be
accounted properly.
(2) It makes it inconsistent with other idle page tracking mechanism. I
prefer if post per-process. At the heart of it, the tracking is always at the
physical page level -- I feel that is how it should be. Other drawback, is
also we have to document this subtlety.
Another reason is the performance is pretty good already with this mechanism
with rmap. I did idle tracking on 512MB range in about 15ms for read and 15ms
for write.
In the future if it is an issue, we can consider it.
thanks,
- Joel
^ permalink raw reply
* Re: [PATCH v4 3/3] f2fs: Support case-insensitive file name lookups
From: Nathan Chancellor @ 2019-07-31 17:57 UTC (permalink / raw)
To: Daniel Rosenberg
Cc: Jaegeuk Kim, Chao Yu, Jonathan Corbet, linux-f2fs-devel,
linux-kernel, linux-doc, linux-fsdevel, linux-api, kernel-team
In-Reply-To: <20190723230529.251659-4-drosen@google.com>
Hi all,
<snip>
> diff --git a/fs/f2fs/hash.c b/fs/f2fs/hash.c
> index cc82f142f811f..99e79934f5088 100644
> --- a/fs/f2fs/hash.c
> +++ b/fs/f2fs/hash.c
> @@ -14,6 +14,7 @@
> #include <linux/f2fs_fs.h>
> #include <linux/cryptohash.h>
> #include <linux/pagemap.h>
> +#include <linux/unicode.h>
>
> #include "f2fs.h"
>
> @@ -67,7 +68,7 @@ static void str2hashbuf(const unsigned char *msg, size_t len,
> *buf++ = pad;
> }
>
> -f2fs_hash_t f2fs_dentry_hash(const struct qstr *name_info,
> +static f2fs_hash_t __f2fs_dentry_hash(const struct qstr *name_info,
> struct fscrypt_name *fname)
> {
> __u32 hash;
> @@ -103,3 +104,35 @@ f2fs_hash_t f2fs_dentry_hash(const struct qstr *name_info,
> f2fs_hash = cpu_to_le32(hash & ~F2FS_HASH_COL_BIT);
> return f2fs_hash;
> }
> +
> +f2fs_hash_t f2fs_dentry_hash(const struct inode *dir,
> + const struct qstr *name_info, struct fscrypt_name *fname)
> +{
> +#ifdef CONFIG_UNICODE
> + struct f2fs_sb_info *sbi = F2FS_SB(dir->i_sb);
> + const struct unicode_map *um = sbi->s_encoding;
> + int r, dlen;
> + unsigned char *buff;
> + struct qstr *folded;
> +
> + if (name_info->len && IS_CASEFOLDED(dir)) {
> + buff = f2fs_kzalloc(sbi, sizeof(char) * PATH_MAX, GFP_KERNEL);
> + if (!buff)
> + return -ENOMEM;
> +
> + dlen = utf8_casefold(um, name_info, buff, PATH_MAX);
> + if (dlen < 0) {
> + kvfree(buff);
> + goto opaque_seq;
> + }
> + folded->name = buff;
> + folded->len = dlen;
> + r = __f2fs_dentry_hash(folded, fname);
> +
> + kvfree(buff);
> + return r;
> + }
> +opaque_seq:
> +#endif
> + return __f2fs_dentry_hash(name_info, fname);
> +}
Clang now warns:
fs/f2fs/hash.c:128:3: warning: variable 'folded' is uninitialized when used here [-Wuninitialized]
folded->name = buff;
^~~~~~
fs/f2fs/hash.c:116:21: note: initialize the variable 'folded' to silence this warning
struct qstr *folded;
^
= NULL
1 warning generated.
I assume that it wants to be initialized with f2fs_kzalloc as well but
I am not familiar with this code and what it expects to do.
Please look into this when you get a chance!
Nathan
^ permalink raw reply
* [PATCH] of/platform: Add missing const qualifier in of_link_property
From: Nathan Chancellor @ 2019-07-31 18:17 UTC (permalink / raw)
To: saravanak
Cc: collinsd, corbet, devicetree, frowand.list, gregkh, kernel-team,
linux-doc, linux-kernel, mark.rutland, rafael, robh+dt,
Nathan Chancellor, kbuild test robot
In-Reply-To: <20190729221101.228240-4-saravanak@google.com>
Clang errors:
drivers/of/platform.c:632:28: error: initializing 'struct
supplier_bindings *' with an expression of type 'const struct
supplier_bindings [4]' discards qualifiers
[-Werror,-Wincompatible-pointer-types-discards-qualifiers]
struct supplier_bindings *s = bindings;
^ ~~~~~~~~
1 error generated.
Fixes: 05f812549f53 ("of/platform: Add functional dependency link from DT bindings")
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---
Given this is still in the driver-core-testing branch, I am fine with
this being squashed in if desired.
drivers/of/platform.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index e2da90e53edb..21838226d68a 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -629,7 +629,7 @@ static bool of_link_property(struct device *dev, struct device_node *con_np,
const char *prop)
{
struct device_node *phandle;
- struct supplier_bindings *s = bindings;
+ const struct supplier_bindings *s = bindings;
unsigned int i = 0;
bool done = true, matched = false;
--
2.22.0
^ permalink raw reply related
* Re: [PATCH] docs: arm: Remove orphan sh-mobile directory
From: Jonathan Corbet @ 2019-07-31 18:42 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Mauro Carvalho Chehab, Simon Horman, Magnus Damm, linux-doc,
linux-renesas-soc, linux-kernel
In-Reply-To: <20190731090211.19408-1-geert+renesas@glider.be>
On Wed, 31 Jul 2019 11:02:11 +0200
Geert Uytterhoeven <geert+renesas@glider.be> wrote:
> This directory is empty, except for a .gitignore file, listing an
> executable file that can no longer be built since commit
> c6535e1e0361157e ("Documentation: Remove ZBOOT MMC/SDHI utility and
> docs").
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH] mailmap: add entry to connect my email addresses
From: Jonathan Corbet @ 2019-07-31 18:45 UTC (permalink / raw)
To: Chao Yu; +Cc: linux-doc, chao, linux-kernel
In-Reply-To: <20190731114510.42003-1-yuchao0@huawei.com>
On Wed, 31 Jul 2019 19:45:10 +0800
Chao Yu <yuchao0@huawei.com> wrote:
> I've used several email accounts to contribute codes, samsung's one
> is obsolete, so let me add entry to map them, in order to let people
> find me easily when they blame my codes.
>
> Signed-off-by: Chao Yu <yuchao0@huawei.com>
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH] doc:it_IT: align translation to mainline
From: Jonathan Corbet @ 2019-07-31 18:46 UTC (permalink / raw)
To: Federico Vaga; +Cc: linux-doc, linux-kernel, Alessia Mantegazza
In-Reply-To: <20190729215856.11128-1-federico.vaga@vaga.pv.it>
On Mon, 29 Jul 2019 23:58:56 +0200
Federico Vaga <federico.vaga@vaga.pv.it> wrote:
> The patch translates the following patches in Italian:
>
> 1fb12b35e5ff kbuild: Raise the minimum required binutils version to 2.21
> 9c3c0c204814 isdn: remove isdn4linux
>
> Signed-off-by: Federico Vaga <federico.vaga@vaga.pv.it>
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH] doc:it_IT: translations for documents in process/
From: Jonathan Corbet @ 2019-07-31 18:51 UTC (permalink / raw)
To: Federico Vaga; +Cc: linux-doc, linux-kernel, Alessia Mantegazza
In-Reply-To: <20190728092054.1183-1-federico.vaga@vaga.pv.it>
On Sun, 28 Jul 2019 11:20:54 +0200
Federico Vaga <federico.vaga@vaga.pv.it> wrote:
> From: Alessia Mantegazza <amantegazza@vaga.pv.it>
>
> Translations for the following documents in process/:
> - email-clients
> - management-style
>
> Signed-off-by: Alessia Mantegazza <amantegazza@vaga.pv.it>
> Signed-off-by: Federico Vaga <federico.vaga@vaga.pv.it>
This looks generally good, but I have to ask...
> +Se la patch che avete inserito dev'essere modificata usato la finestra di
> +scrittura di Claws, allora assicuratevi che l'"auto-interruzione" sia
> +disabilitata :menuselection:`Configurazione-->Preferenze-->Composizione-->Interruzione riga`.
Have you actually verified that the translations used in these mail
clients matches what you have here?
Thanks,
jon
^ permalink raw reply
* Re: [PATCH 1/5] MAINTAINERS: fix broken ref for ABI sysfs-bus-counter-ftm-quaddec
From: Jonathan Corbet @ 2019-07-31 18:55 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
David S. Miller, Greg Kroah-Hartman, Jonathan Cameron,
Nicolas Ferre
In-Reply-To: <5c44856436bbaeb4f2d4b750365b82de973ad054.1564169297.git.mchehab+samsung@kernel.org>
On Fri, 26 Jul 2019 16:29:10 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> There's a typo here:
>
> sysfs-bus-counter-ftm-quadddec -> sysfs-bus-counter-ftm-quaddec
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
These are easy...I've applied this set, thanks.
jon
^ permalink raw reply
* Re: [PATCH] docs: riscv: convert boot-image-header.txt to ReST
From: Jonathan Corbet @ 2019-07-31 19:02 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Doc Mailing List, Mauro Carvalho Chehab, linux-kernel,
Atish Patra, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Karsten Merker, Linus Walleij, linux-riscv
In-Reply-To: <1eaeb3fbb74de55af0b3f6d93ab40776dcbbb5c8.1564174903.git.mchehab+samsung@kernel.org>
On Fri, 26 Jul 2019 18:01:55 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> Convert this small file to ReST format by:
> - Using a proper markup for the document title;
> - marking a code block as such;
> - use tags for Author and date;
> - use tables for bit map fields.
>
> While here, fix a broken reference for a document with is
> planned but is not here yet.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v2 01/26] docs: power: add it to to the main documentation index
From: Jonathan Corbet @ 2019-07-31 19:03 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Rafael J. Wysocki, Len Brown, Pavel Machek, linux-doc, linux-pm
In-Reply-To: <5417112ea7a391e6622c46bf833b7d6a5725c158.1564145354.git.mchehab+samsung@kernel.org>
On Fri, 26 Jul 2019 09:51:11 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> The power docs are orphaned at the documentation body.
>
> While it could likely be moved to be inside some guide, I'm opting to just
> adding it to the main index.rst, removing the :orphan: and adding the SPDX
> header.
>
> The reason is similar to what it was done for other driver-specific
> subsystems: the docs there contain a mix of Kernelspace, uAPI and
> admin-guide. So, better to keep them on its own directory,
> while the docs there are not properly classified.
>
> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
So this one went upstream with the PDF fixes pull, right? I'm a little
surprised to see it here now.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH] doc: email-clients miscellaneous fixes
From: Jonathan Corbet @ 2019-07-31 19:06 UTC (permalink / raw)
To: Federico Vaga; +Cc: linux-doc, linux-kernel
In-Reply-To: <20190706210100.26698-1-federico.vaga@vaga.pv.it>
On Sat, 6 Jul 2019 23:01:00 +0200
Federico Vaga <federico.vaga@vaga.pv.it> wrote:
> Fixed some style inconsistencies and remove old statement referring to
> kmail missing feature (saving email from the view window is possible).
>
> Signed-off-by: Federico Vaga <federico.vaga@vaga.pv.it>
So this one fell through the cracks, it seems, sorry. Applied now.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v3] Documentation: filesystems: Convert jfs.txt to
From: Jonathan Corbet @ 2019-07-31 19:09 UTC (permalink / raw)
To: Shobhit Kukreti
Cc: skhan, Mauro Carvalho Chehab, linux-kernel-mentees, linux-doc,
linux-kernel, willy
In-Reply-To: <1562772541-32144-1-git-send-email-shobhitkukreti@gmail.com>
On Wed, 10 Jul 2019 08:29:01 -0700
Shobhit Kukreti <shobhitkukreti@gmail.com> wrote:
> This converts the plain text documentation of jfs.txt to reStructuredText
> format. Added to documentation build process and verified with
> make htmldocs
>
> Signed-off-by: Shobhit Kukreti <shobhitkukreti@gmail.com>
So this kind of fell through the cracks, sorry; I've applied it now.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v3] Documentation: filesystems: Convert ufs.txt to reStructuredText format
From: Jonathan Corbet @ 2019-07-31 19:10 UTC (permalink / raw)
To: Shobhit Kukreti
Cc: skhan, Mauro Carvalho Chehab, linux-kernel-mentees, linux-doc,
linux-kernel
In-Reply-To: <1562772683-32422-1-git-send-email-shobhitkukreti@gmail.com>
On Wed, 10 Jul 2019 08:31:23 -0700
Shobhit Kukreti <shobhitkukreti@gmail.com> wrote:
> This converts the plain text documentation of ufs.txt to
> reStructuredText format. Added to documentation build process
> and verified with make htmldocs
>
> Signed-off-by: Shobhit Kukreti <shobhitkukreti@gmail.com>
I've applied this one as well; apologies for the delay.
jon
^ permalink raw reply
* Re: [PATCH] Documentation: coresight: convert txt to rst
From: Jonathan Corbet @ 2019-07-31 19:14 UTC (permalink / raw)
To: Phong Tran
Cc: mathieu.poirier, mchehab, leo.yan, marc.w.gonzalez,
linux-arm-kernel, linux-doc, linux-kernel-mentees, linux-kernel,
skhan, suzuki.poulose
In-Reply-To: <20190711165201.31798-1-tranmanphong@gmail.com>
On Thu, 11 Jul 2019 23:52:01 +0700
Phong Tran <tranmanphong@gmail.com> wrote:
> This changes from plain text to reStructuredText as suggestion
> in doc-guide [1]
>
> [1] https://www.kernel.org/doc/html/latest/doc-guide/sphinx.html
>
> Some adaptations such as: literal block, ``inline literal`` and
> alignment text,...
>
> Signed-off-by: Phong Tran <tranmanphong@gmail.com>
> Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Applied at long last, sorry for the delay.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v2 01/26] docs: power: add it to to the main documentation index
From: Mauro Carvalho Chehab @ 2019-07-31 19:16 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Rafael J. Wysocki, Len Brown, Pavel Machek, linux-doc, linux-pm
In-Reply-To: <20190731130338.6de6c5d7@lwn.net>
Em Wed, 31 Jul 2019 13:03:38 -0600
Jonathan Corbet <corbet@lwn.net> escreveu:
> On Fri, 26 Jul 2019 09:51:11 -0300
> Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
>
> > The power docs are orphaned at the documentation body.
> >
> > While it could likely be moved to be inside some guide, I'm opting to just
> > adding it to the main index.rst, removing the :orphan: and adding the SPDX
> > header.
> >
> > The reason is similar to what it was done for other driver-specific
> > subsystems: the docs there contain a mix of Kernelspace, uAPI and
> > admin-guide. So, better to keep them on its own directory,
> > while the docs there are not properly classified.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
>
> So this one went upstream with the PDF fixes pull, right? I'm a little
> surprised to see it here now.
Yeah, this specific patch went together with the PDF fixes.
The remaining ones in this series aren't there yet.
From this series, besides this patch, you can also exclude patch
25/26, as it seems that Paul will merge via RCU tree.
The remaining ones apply cleanly on the top of docs-next
(I tested applying them on the top of your tree yesterday).
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH v2 01/26] docs: power: add it to to the main documentation index
From: Jonathan Corbet @ 2019-07-31 19:34 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Rafael J. Wysocki, Len Brown, Pavel Machek, linux-doc, linux-pm
In-Reply-To: <20190731161606.2572a567@coco.lan>
On Wed, 31 Jul 2019 16:16:06 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> The remaining ones in this series aren't there yet.
>
> From this series, besides this patch, you can also exclude patch
> 25/26, as it seems that Paul will merge via RCU tree.
>
> The remaining ones apply cleanly on the top of docs-next
> (I tested applying them on the top of your tree yesterday).
Hmm...really?
- [PATCH v2 03/26] docs: powerpc: convert docs to ReST and rename to *.rst
Seems to already be applied.
- [PATCH v2 07/26] docs: w1: convert to ReST and add to the kAPI group of
docs
Gives me the dreaded "could not build fake ancestor" error, I
don't really understand why.
- [PATCH v2 08/26] spi: docs: convert to ReST and add it to the kABI
bookset
- [PATCH v2 16/26] docs: fs: cifs: convert to ReST and add to admin-guide
book
Likewise
I've applied the others, so we're getting closer...
jon
^ permalink raw reply
* Re: [PATCH v4] tpm: Document UEFI event log quirks
From: Jonathan Corbet @ 2019-07-31 19:39 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: linux-kernel, linux-integrity, linux-doc, tweek, matthewgarrett,
jorhand, rdunlap, Sasha Levin
In-Reply-To: <20190712154439.10642-1-jarkko.sakkinen@linux.intel.com>
On Fri, 12 Jul 2019 18:44:32 +0300
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> wrote:
> There are some weird quirks when it comes to UEFI event log. Provide a
> brief introduction to TPM event log mechanism and describe the quirks
> and how they can be sorted out.
>
> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> ---
> v4: - Unfortanely -> Unfortunately
> v3: - Add a section for refs and use a bullet list to enumerate them.
> - Remove an invalid author info.
> v2: - Fix one typo.
> - Refine the last paragraph to better explain how the two halves
> of the event log are concatenated.
> Documentation/security/tpm/index.rst | 1 +
> Documentation/security/tpm/tpm_event_log.rst | 55 ++++++++++++++++++++
> 2 files changed, 56 insertions(+)
> create mode 100644 Documentation/security/tpm/tpm_event_log.rst
I've applied this, thanks. Before I could do so, though, I had to edit
the headers, which read:
> Content-Type: text/plain; charset=y
"git am" *really* doesn't like "charset=y". I think this is something
that git send-email likes to do occasionally, don't know why...
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v2 01/26] docs: power: add it to to the main documentation index
From: Mauro Carvalho Chehab @ 2019-07-31 19:58 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Rafael J. Wysocki, Len Brown, Pavel Machek, linux-doc, linux-pm
In-Reply-To: <20190731133443.49368cbb@lwn.net>
Em Wed, 31 Jul 2019 13:34:43 -0600
Jonathan Corbet <corbet@lwn.net> escreveu:
> On Wed, 31 Jul 2019 16:16:06 -0300
> Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
>
> > The remaining ones in this series aren't there yet.
> >
> > From this series, besides this patch, you can also exclude patch
> > 25/26, as it seems that Paul will merge via RCU tree.
> >
> > The remaining ones apply cleanly on the top of docs-next
> > (I tested applying them on the top of your tree yesterday).
>
> Hmm...really?
>
> - [PATCH v2 03/26] docs: powerpc: convert docs to ReST and rename to *.rst
>
> Seems to already be applied.
>
> - [PATCH v2 07/26] docs: w1: convert to ReST and add to the kAPI group of
> docs
>
> Gives me the dreaded "could not build fake ancestor" error, I
> don't really understand why.
That's new! What Sphinx version are you using?
Btw, on my build here (Sphinx 2.0.1 on Python3), I can't see this error.
>
> - [PATCH v2 08/26] spi: docs: convert to ReST and add it to the kABI
> bookset
> - [PATCH v2 16/26] docs: fs: cifs: convert to ReST and add to admin-guide
> book
>
> Likewise
>
> I've applied the others, so we're getting closer...
Weird...
I did a rebase here on the top of your current docs/docs-next... they
apply fine. Had to do just a small trivial fix on one of the patches.
Anyway, thanks for merging those... I have now just 5 patches.
Btw, it seems that there are now 5 new broken links:
MAINTAINERS: Documentation/filesystems/jfs.txt
MAINTAINERS: Documentation/filesystems/ufs.txt
drivers/hwtracing/coresight/Kconfig: Documentation/trace/coresight-cpu-debug.txt
fs/jfs/Kconfig: file:Documentation/filesystems/jfs.txt
fs/ufs/Kconfig: file:Documentation/filesystems/ufs.txt
4 of them related to the two fs patches applied today.
I'll send you a fix together with the remaining patches in a few.
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH v2 01/26] docs: power: add it to to the main documentation index
From: Jonathan Corbet @ 2019-07-31 20:02 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Rafael J. Wysocki, Len Brown, Pavel Machek, linux-doc, linux-pm
In-Reply-To: <20190731165859.10b439c8@coco.lan>
On Wed, 31 Jul 2019 16:58:59 -0300
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> > - [PATCH v2 07/26] docs: w1: convert to ReST and add to the kAPI group of
> > docs
> >
> > Gives me the dreaded "could not build fake ancestor" error, I
> > don't really understand why.
>
> That's new! What Sphinx version are you using?
That's a "git am" error, sphinx doesn't enter into the picture...
jon
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox