Re: [PATCH v3 0/3] update infiniband uverbs documentation
Jonathan Corbet wrote on 02/02/2019 01:15:33 AM: > Subject: Re: [PATCH v3 0/3] update infiniband uverbs documentation > > On Fri, 1 Feb 2019 09:52:52 -0700 > Jason Gunthorpe wrote: > > > Doc folks, what is the feedback on these patches? Should I take > > them through the rdma tree? > > If you think they are ready (it seemed that there were still comments on > one of the patches?) I'll take them, just let me know. >From Jason's latest review, it looks like 90% of what I wrote is no longer relevant: > This array was deleted recently > IB_VERBS_DELCARE_CMD is also deleted > DECLARE_UVERBS_OBJECT_TREE as well So I'm abandoning this patch. > Thanks, > > jon (aka "doc folks" :) >
[PATCH 3.16 004/305] x86/mm: Simplify p[g4um]d_page() macros
3.16.63-rc1 review patch. If anyone has any objections, please let me know.
--
From: Tom Lendacky
commit fd7e315988b784509ba3f1b42f539bd0b1fca9bb upstream.
Create a pgd_pfn() macro similar to the p[4um]d_pfn() macros and then
use the p[g4um]d_pfn() macros in the p[g4um]d_page() macros instead of
duplicating the code.
Signed-off-by: Tom Lendacky
Reviewed-by: Thomas Gleixner
Reviewed-by: Borislav Petkov
Cc: Alexander Potapenko
Cc: Andrey Ryabinin
Cc: Andy Lutomirski
Cc: Arnd Bergmann
Cc: Borislav Petkov
Cc: Brijesh Singh
Cc: Dave Young
Cc: Dmitry Vyukov
Cc: Jonathan Corbet
Cc: Konrad Rzeszutek Wilk
Cc: Larry Woodman
Cc: Linus Torvalds
Cc: Matt Fleming
Cc: Michael S. Tsirkin
Cc: Paolo Bonzini
Cc: Peter Zijlstra
Cc: Radim Krčmář
Cc: Rik van Riel
Cc: Toshimitsu Kani
Cc: kasan-...@googlegroups.com
Cc: k...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux...@kvack.org
Link:
http://lkml.kernel.org/r/e61eb533a6d0aac941db2723d8aa63ef6b882dee.1500319216.git.thomas.lenda...@amd.com
Signed-off-by: Ingo Molnar
[Backported to 4.9 stable by AK, suggested by Michael Hocko]
Signed-off-by: Andi Kleen
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Wenkuan Wang
Signed-off-by: Ben Hutchings
---
arch/x86/include/asm/pgtable.h | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -166,6 +166,11 @@ static inline unsigned long pud_pfn(pud_
return (pfn & pud_pfn_mask(pud)) >> PAGE_SHIFT;
}
+static inline unsigned long pgd_pfn(pgd_t pgd)
+{
+ return (pgd_val(pgd) & PTE_PFN_MASK) >> PAGE_SHIFT;
+}
+
#define pte_page(pte) pfn_to_page(pte_pfn(pte))
static inline int pmd_large(pmd_t pte)
@@ -591,8 +596,7 @@ static inline unsigned long pmd_page_vad
* Currently stuck as a macro due to indirect forward reference to
* linux/mmzone.h's __section_mem_map_addr() definition:
*/
-#define pmd_page(pmd) \
- pfn_to_page((pmd_val(pmd) & pmd_pfn_mask(pmd)) >> PAGE_SHIFT)
+#define pmd_page(pmd) pfn_to_page(pmd_pfn(pmd))
/*
* the pmd page can be thought of an array like this: pmd_t[PTRS_PER_PMD]
@@ -665,8 +669,7 @@ static inline unsigned long pud_page_vad
* Currently stuck as a macro due to indirect forward reference to
* linux/mmzone.h's __section_mem_map_addr() definition:
*/
-#define pud_page(pud) \
- pfn_to_page((pud_val(pud) & pud_pfn_mask(pud)) >> PAGE_SHIFT)
+#define pud_page(pud) pfn_to_page(pud_pfn(pud))
/* Find an entry in the second-level page table.. */
static inline pmd_t *pmd_offset(pud_t *pud, unsigned long address)
@@ -706,7 +709,7 @@ static inline unsigned long pgd_page_vad
* Currently stuck as a macro due to indirect forward reference to
* linux/mmzone.h's __section_mem_map_addr() definition:
*/
-#define pgd_page(pgd) pfn_to_page(pgd_val(pgd) >> PAGE_SHIFT)
+#define pgd_page(pgd) pfn_to_page(pgd_pfn(pgd))
/* to find an entry in a page-table-directory. */
static inline unsigned long pud_index(unsigned long address)
[PATCH 1/1] doc: kernel-parameters.txt: fix documentation of elevator parameter
Legacy IO schedulers (cfq, deadline and noop) were removed in
f382fb0bcef4.
The documentation for deadline was retained because it carries over to
mq-deadline as well, but location of the doc file was changed over time.
The old iosched algorithms were removed from elevator= kernel parameter
and mq-deadline, kyber and bfq were added with a reference to their
documentation.
Fixes: f382fb0bcef4 ("block: remove legacy IO schedulers")
Signed-off-by: Otto Sabart
---
Documentation/admin-guide/kernel-parameters.txt | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index b799bcf67d7b..2238fb3c7dcf 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1182,9 +1182,10 @@
arch/x86/kernel/cpu/cpufreq/elanfreq.c.
elevator= [IOSCHED]
- Format: {"cfq" | "deadline" | "noop"}
- See Documentation/block/cfq-iosched.txt and
- Documentation/block/deadline-iosched.txt for details.
+ Format: { "mq-deadline" | "kyber" | "bfq" }
+ See Documentation/block/deadline-iosched.txt,
+ Documentation/block/kyber-iosched.txt and
+ Documentation/block/bfq-iosched.txt for details.
elfcorehdr=[size[KMG]@]offset[KMG] [IA64,PPC,SH,X86,S390]
Specifies physical address of start of kernel core
--
2.17.2
signature.asc
Description: PGP signature
Re: [PATCH 3/3] docs: Use underscore not hyphen in label
On Sat, Feb 02, 2019 at 04:32:10PM +0200, Mike Rapoport wrote: > On Fri, Feb 01, 2019 at 04:03:10PM -0700, Jonathan Corbet wrote: > > On Fri, 1 Feb 2019 07:56:08 +1100 > > "Tobin C. Harding" wrote: > > > > > > > From: "Tobin C. Harding" > > > > > > > > > > sphinx emits warning > > > > > > > > > >WARNING: undefined label: memory-allocation ... > > > > > > > > Weird, for me it works fine. The generated html at kernel.org [1] also > > > > seems to be Ok... > > > > > > > > What version of sphinx do you use? > > > > > > Thanks for looking at this Mike. I was running 1.4, I see there is a v2 > > > out so I'll upgrade but if the warning doesn't show for you then I'd say > > > we just drop this patch. > > > > > > Jon, > > > > > > Is it within your usual workflow to take just the first two patches from > > > this series or would you like me to spin another version without the > > > final patch in it? > > > > We currently document that 1.4 is supposed to work, so we should stick to > > that; I think I'll go ahead and apply all three patches. > > > > We should maybe consider dragging our minimum version forward a bit, or > > else we might want to document this particular gotcha. > > I have 1.4.6 (the one listed in sphinx.rst) and everything worked just > fine... FWIW I'm running 1.4.9 thanks, Tobin.
