* Re: [PATCH v2 4/4] hugetlbfs: clean up command line processing
From: Peter Xu @ 2020-04-10 20:37 UTC (permalink / raw)
To: Mike Kravetz
Cc: linux-doc, Catalin Marinas, Dave Hansen, Heiko Carstens, linux-mm,
Paul Mackerras, sparclinux, linux-riscv, Will Deacon,
Mina Almasry, linux-s390, Jonathan Corbet, Christian Borntraeger,
Ingo Molnar, Longpeng, Albert Ou, Vasily Gorbik, Paul Walmsley,
Thomas Gleixner, linux-arm-kernel, linux-kernel, Palmer Dabbelt,
Andrew Morton, linuxppc-dev, David S . Miller
In-Reply-To: <20200401183819.20647-5-mike.kravetz@oracle.com>
On Wed, Apr 01, 2020 at 11:38:19AM -0700, Mike Kravetz wrote:
> With all hugetlb page processing done in a single file clean up code.
> - Make code match desired semantics
> - Update documentation with semantics
> - Make all warnings and errors messages start with 'HugeTLB:'.
> - Consistently name command line parsing routines.
> - Check for hugepages_supported() before processing parameters.
> - Add comments to code
> - Describe some of the subtle interactions
> - Describe semantics of command line arguments
>
> Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
> ---
> .../admin-guide/kernel-parameters.txt | 35 ++++---
> Documentation/admin-guide/mm/hugetlbpage.rst | 44 +++++++++
> mm/hugetlb.c | 96 +++++++++++++++----
> 3 files changed, 142 insertions(+), 33 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 1bd5454b5e5f..de653cfe1726 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -832,12 +832,15 @@
> See also Documentation/networking/decnet.txt.
>
> default_hugepagesz=
> - [same as hugepagesz=] The size of the default
> - HugeTLB page size. This is the size represented by
> - the legacy /proc/ hugepages APIs, used for SHM, and
> - default size when mounting hugetlbfs filesystems.
> - Defaults to the default architecture's huge page size
> - if not specified.
> + [HW] The size of the default HugeTLB page size. This
Could I ask what's "HW"? Sorry this is not a comment at all but
really a pure question I wanted to ask... :)
> + is the size represented by the legacy /proc/ hugepages
> + APIs. In addition, this is the default hugetlb size
> + used for shmget(), mmap() and mounting hugetlbfs
> + filesystems. If not specified, defaults to the
> + architecture's default huge page size. Huge page
> + sizes are architecture dependent. See also
> + Documentation/admin-guide/mm/hugetlbpage.rst.
> + Format: size[KMG]
>
> deferred_probe_timeout=
> [KNL] Debugging option to set a timeout in seconds for
> @@ -1480,13 +1483,19 @@
> If enabled, boot-time allocation of gigantic hugepages
> is skipped.
>
> - hugepages= [HW,X86-32,IA-64] HugeTLB pages to allocate at boot.
> - hugepagesz= [HW,IA-64,PPC,X86-64] The size of the HugeTLB pages.
> - On x86-64 and powerpc, this option can be specified
> - multiple times interleaved with hugepages= to reserve
> - huge pages of different sizes. Valid pages sizes on
> - x86-64 are 2M (when the CPU supports "pse") and 1G
> - (when the CPU supports the "pdpe1gb" cpuinfo flag).
> + hugepages= [HW] Number of HugeTLB pages to allocate at boot.
> + If this follows hugepagesz (below), it specifies
> + the number of pages of hugepagesz to be allocated.
"... Otherwise it specifies the number of pages to allocate for the
default huge page size." ?
> + Format: <integer>
How about add a new line here?
> + hugepagesz=
> + [HW] The size of the HugeTLB pages. This is used in
> + conjunction with hugepages (above) to allocate huge
> + pages of a specific size at boot. The pair
> + hugepagesz=X hugepages=Y can be specified once for
> + each supported huge page size. Huge page sizes are
> + architecture dependent. See also
> + Documentation/admin-guide/mm/hugetlbpage.rst.
> + Format: size[KMG]
>
> hung_task_panic=
> [KNL] Should the hung task detector generate panics.
> diff --git a/Documentation/admin-guide/mm/hugetlbpage.rst b/Documentation/admin-guide/mm/hugetlbpage.rst
> index 1cc0bc78d10e..de340c586995 100644
> --- a/Documentation/admin-guide/mm/hugetlbpage.rst
> +++ b/Documentation/admin-guide/mm/hugetlbpage.rst
> @@ -100,6 +100,50 @@ with a huge page size selection parameter "hugepagesz=<size>". <size> must
> be specified in bytes with optional scale suffix [kKmMgG]. The default huge
> page size may be selected with the "default_hugepagesz=<size>" boot parameter.
>
> +Hugetlb boot command line parameter semantics
> +hugepagesz - Specify a huge page size. Used in conjunction with hugepages
> + parameter to preallocate a number of huge pages of the specified
> + size. Hence, hugepagesz and hugepages are typically specified in
> + pairs such as:
> + hugepagesz=2M hugepages=512
> + hugepagesz can only be specified once on the command line for a
> + specific huge page size. Valid huge page sizes are architecture
> + dependent.
> +hugepages - Specify the number of huge pages to preallocate. This typically
> + follows a valid hugepagesz parameter. However, if hugepages is the
> + first or only hugetlb command line parameter it specifies the number
> + of huge pages of default size to allocate. The number of huge pages
> + of default size specified in this manner can be overwritten by a
> + hugepagesz,hugepages parameter pair for the default size.
> + For example, on an architecture with 2M default huge page size:
> + hugepages=256 hugepagesz=2M hugepages=512
> + will result in 512 2M huge pages being allocated. If a hugepages
> + parameter is preceded by an invalid hugepagesz parameter, it will
> + be ignored.
> +default_hugepagesz - Specify the default huge page size. This parameter can
> + only be specified once on the command line. No other hugetlb command
> + line parameter is associated with default_hugepagesz. Therefore, it
> + can appear anywhere on the command line. If hugepages= is the first
> + hugetlb command line parameter, the specified number of huge pages
> + will apply to the default huge page size specified with
> + default_hugepagesz. For example,
> + hugepages=512 default_hugepagesz=2M
No strong opinion, but considering to the special case of gigantic
huge page mentioned below, I'm thinking maybe it's easier to just ask
the user to always use "hugepagesz=X hugepages=Y" pair when people
want to reserve huge pages.
For example, some user might start to use this after this series
legally:
default_hugepagesz=2M hugepages=1024
Then the user thinks, hmm, maybe it's good to use 1G pages, by just
changing some numbers:
default_hugepagesz=1G hugepages=2
Then if it stops working it could really confuse the user.
(Besides, it could be an extra maintainaince burden for linux itself)
> + will result in 512 2M huge pages being allocated. However, specifying
> + the number of default huge pages in this manner will not apply to
> + gigantic huge pages. For example,
> + hugepages=10 default_hugepagesz=1G
> + or
> + default_hugepagesz=1G hugepages=10
> + will NOT result in the allocation of 10 1G huge pages. In order to
> + preallocate gigantic huge pages, there must be hugepagesz, hugepages
> + parameter pair. For example,
> + hugepagesz=1G hugepages=10 default_hugepagesz=1G
> + or
> + default_hugepagesz=1G hugepagesz=1G hugepages=10
> + will result 10 1G huge pages being allocated and the default huge
> + page size will be set to 1G. Valid default huge page size is
> + architecture dependent.
> +
> When multiple huge page sizes are supported, ``/proc/sys/vm/nr_hugepages``
> indicates the current number of pre-allocated huge pages of the default size.
> Thus, one can use the following command to dynamically allocate/deallocate
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 72a4343509d5..74ef53f7c5a7 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -3054,7 +3054,7 @@ static void __init hugetlb_sysfs_init(void)
> err = hugetlb_sysfs_add_hstate(h, hugepages_kobj,
> hstate_kobjs, &hstate_attr_group);
> if (err)
> - pr_err("Hugetlb: Unable to add hstate %s", h->name);
> + pr_err("HugeTLB: Unable to add hstate %s", h->name);
> }
> }
>
> @@ -3158,7 +3158,7 @@ static void hugetlb_register_node(struct node *node)
> nhs->hstate_kobjs,
> &per_node_hstate_attr_group);
> if (err) {
> - pr_err("Hugetlb: Unable to add hstate %s for node %d\n",
> + pr_err("HugeTLB: Unable to add hstate %s for node %d\n",
> h->name, node->dev.id);
> hugetlb_unregister_node(node);
> break;
> @@ -3209,19 +3209,35 @@ static int __init hugetlb_init(void)
> if (!hugepages_supported())
> return 0;
>
> - if (!size_to_hstate(default_hstate_size)) {
> - if (default_hstate_size != 0) {
> - pr_err("HugeTLB: unsupported default_hugepagesz %lu. Reverting to %lu\n",
> - default_hstate_size, HPAGE_SIZE);
> - }
> -
> + /*
> + * Make sure HPAGE_SIZE (HUGETLB_PAGE_ORDER) hstate exists. Some
> + * architectures depend on setup being done here.
> + *
> + * If a valid default huge page size was specified on the command line,
> + * add associated hstate if necessary. If not, set default_hstate_size
> + * to default size. default_hstate_idx is used at runtime to identify
> + * the default huge page size/hstate.
> + */
> + hugetlb_add_hstate(HUGETLB_PAGE_ORDER);
> + if (default_hstate_size)
> + hugetlb_add_hstate(ilog2(default_hstate_size) - PAGE_SHIFT);
> + else
> default_hstate_size = HPAGE_SIZE;
> - hugetlb_add_hstate(HUGETLB_PAGE_ORDER);
> - }
> default_hstate_idx = hstate_index(size_to_hstate(default_hstate_size));
> +
> + /*
> + * default_hstate_max_huge_pages != 0 indicates a count (hugepages=)
> + * specified before a size (hugepagesz=). Use this count for the
> + * default huge page size, unless a specific value was specified for
> + * this size in a hugepagesz/hugepages pair.
> + */
> if (default_hstate_max_huge_pages) {
Since we're refactoring this - Could default_hstate_max_huge_pages be
dropped directly (in hugepages= we can create the default hstate, then
we set max_huge_pages of the default hstate there)? Or did I miss
anything important?
> if (!default_hstate.max_huge_pages)
> - default_hstate.max_huge_pages = default_hstate_max_huge_pages;
> + default_hstate.max_huge_pages =
> + default_hstate_max_huge_pages;
> + else
> + pr_warn("HugeTLB: First hugepages=%lu ignored\n",
> + default_hstate_max_huge_pages);
> }
>
> hugetlb_init_hstates();
> @@ -3274,20 +3290,31 @@ void __init hugetlb_add_hstate(unsigned int order)
> parsed_hstate = h;
> }
>
> -static int __init hugetlb_nrpages_setup(char *s)
> +/*
> + * hugepages command line processing
> + * hugepages normally follows a valid hugepagsz specification. If not, ignore
> + * the hugepages value. hugepages can also be the first huge page command line
> + * option in which case it specifies the number of huge pages for the default
> + * size.
> + */
> +static int __init hugepages_setup(char *s)
> {
> unsigned long *mhp;
> static unsigned long *last_mhp;
>
> + if (!hugepages_supported()) {
> + pr_warn("HugeTLB: huge pages not supported, ignoring hugepages = %s\n", s);
> + return 0;
> + }
> +
> if (!parsed_valid_hugepagesz) {
> - pr_warn("hugepages = %s preceded by "
> - "an unsupported hugepagesz, ignoring\n", s);
> + pr_warn("HugeTLB: hugepages = %s preceded by an unsupported hugepagesz, ignoring\n", s);
s/preceded/is preceded/?
> parsed_valid_hugepagesz = true;
> - return 1;
> + return 0;
> }
> /*
> - * !hugetlb_max_hstate means we haven't parsed a hugepagesz= parameter yet,
> - * so this hugepages= parameter goes to the "default hstate".
> + * !hugetlb_max_hstate means we haven't parsed a hugepagesz= parameter
> + * yet, so this hugepages= parameter goes to the "default hstate".
> */
> else if (!hugetlb_max_hstate)
> mhp = &default_hstate_max_huge_pages;
> @@ -3295,8 +3322,8 @@ static int __init hugetlb_nrpages_setup(char *s)
> mhp = &parsed_hstate->max_huge_pages;
>
> if (mhp == last_mhp) {
> - pr_warn("hugepages= specified twice without interleaving hugepagesz=, ignoring\n");
> - return 1;
> + pr_warn("HugeTLB: hugepages= specified twice without interleaving hugepagesz=, ignoring hugepages=%s\n", s);
> + return 0;
> }
>
> if (sscanf(s, "%lu", mhp) <= 0)
> @@ -3314,12 +3341,24 @@ static int __init hugetlb_nrpages_setup(char *s)
>
> return 1;
> }
> -__setup("hugepages=", hugetlb_nrpages_setup);
> +__setup("hugepages=", hugepages_setup);
>
> +/*
> + * hugepagesz command line processing
> + * A specific huge page size can only be specified once with hugepagesz.
> + * hugepagesz is followed by hugepages on the command line. The global
> + * variable 'parsed_valid_hugepagesz' is used to determine if prior
> + * hugepagesz argument was valid.
> + */
> static int __init hugepagesz_setup(char *s)
> {
> unsigned long size;
>
> + if (!hugepages_supported()) {
> + pr_warn("HugeTLB: huge pages not supported, ignoring hugepagesz = %s\n", s);
> + return 0;
> + }
> +
> size = (unsigned long)memparse(s, NULL);
>
> if (!arch_hugetlb_valid_size(size)) {
> @@ -3329,19 +3368,31 @@ static int __init hugepagesz_setup(char *s)
> }
>
> if (size_to_hstate(size)) {
> + parsed_valid_hugepagesz = false;
> pr_warn("HugeTLB: hugepagesz %s specified twice, ignoring\n", s);
> return 0;
> }
>
> + parsed_valid_hugepagesz = true;
> hugetlb_add_hstate(ilog2(size) - PAGE_SHIFT);
> return 1;
> }
> __setup("hugepagesz=", hugepagesz_setup);
>
> +/*
> + * default_hugepagesz command line input
> + * Only one instance of default_hugepagesz allowed on command line. Do not
> + * add hstate here as that will confuse hugepagesz/hugepages processing.
> + */
> static int __init default_hugepagesz_setup(char *s)
> {
> unsigned long size;
>
> + if (!hugepages_supported()) {
> + pr_warn("HugeTLB: huge pages not supported, ignoring default_hugepagesz = %s\n", s);
> + return 0;
> + }
> +
> size = (unsigned long)memparse(s, NULL);
>
> if (!arch_hugetlb_valid_size(size)) {
> @@ -3349,6 +3400,11 @@ static int __init default_hugepagesz_setup(char *s)
> return 0;
> }
>
> + if (default_hstate_size) {
> + pr_err("HugeTLB: default_hugepagesz previously specified, ignoring %s\n", s);
> + return 0;
> + }
Nitpick: ideally this can be moved before memparse().
Thanks,
> +
> default_hstate_size = size;
> return 1;
> }
> --
> 2.25.1
>
>
--
Peter Xu
^ permalink raw reply
* [PATCH] powerpc/ima: fix secure boot rules in ima arch policy
From: Nayna Jain @ 2020-04-10 20:13 UTC (permalink / raw)
To: linux-integrity, linuxppc-dev; +Cc: Nayna Jain, linux-kernel, Mimi Zohar
To prevent verifying the kernel module appended signature twice
(finit_module), once by the module_sig_check() and again by IMA, powerpc
IMA secure boot rules define an IMA architecture specific policy rule
only if CONFIG_MODULE_SIG_FORCE is not enabled. This, unfortunately, does
not take into account the ability of enabling "sig_enforce" on the boot
command line (module.sig_enforce=1).
This patch fixes secure boot policy rules to be based on CONFIG_MODULE_SIG
instead.
Fixes: 4238fad366a6 ("powerpc/ima: Add support to initialize ima policy rules")
Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
---
arch/powerpc/kernel/ima_arch.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/ima_arch.c b/arch/powerpc/kernel/ima_arch.c
index e34116255ced..957abd592075 100644
--- a/arch/powerpc/kernel/ima_arch.c
+++ b/arch/powerpc/kernel/ima_arch.c
@@ -19,12 +19,12 @@ bool arch_ima_get_secureboot(void)
* to be stored as an xattr or as an appended signature.
*
* To avoid duplicate signature verification as much as possible, the IMA
- * policy rule for module appraisal is added only if CONFIG_MODULE_SIG_FORCE
+ * policy rule for module appraisal is added only if CONFIG_MODULE_SIG
* is not enabled.
*/
static const char *const secure_rules[] = {
"appraise func=KEXEC_KERNEL_CHECK appraise_flag=check_blacklist appraise_type=imasig|modsig",
-#ifndef CONFIG_MODULE_SIG_FORCE
+#ifndef CONFIG_MODULE_SIG
"appraise func=MODULE_CHECK appraise_flag=check_blacklist appraise_type=imasig|modsig",
#endif
NULL
@@ -50,7 +50,7 @@ static const char *const secure_and_trusted_rules[] = {
"measure func=KEXEC_KERNEL_CHECK template=ima-modsig",
"measure func=MODULE_CHECK template=ima-modsig",
"appraise func=KEXEC_KERNEL_CHECK appraise_flag=check_blacklist appraise_type=imasig|modsig",
-#ifndef CONFIG_MODULE_SIG_FORCE
+#ifndef CONFIG_MODULE_SIG
"appraise func=MODULE_CHECK appraise_flag=check_blacklist appraise_type=imasig|modsig",
#endif
NULL
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v2 3/4] hugetlbfs: remove hugetlb_add_hstate() warning for existing hstate
From: Peter Xu @ 2020-04-10 19:34 UTC (permalink / raw)
To: Mike Kravetz
Cc: linux-doc, Catalin Marinas, Dave Hansen, Heiko Carstens, linux-mm,
Paul Mackerras, sparclinux, linux-riscv, Will Deacon,
Mina Almasry, linux-s390, Jonathan Corbet, Christian Borntraeger,
Ingo Molnar, Longpeng, Albert Ou, Vasily Gorbik, Paul Walmsley,
Thomas Gleixner, linux-arm-kernel, linux-kernel, Palmer Dabbelt,
Andrew Morton, linuxppc-dev, David S . Miller
In-Reply-To: <20200401183819.20647-4-mike.kravetz@oracle.com>
On Wed, Apr 01, 2020 at 11:38:18AM -0700, Mike Kravetz wrote:
[...]
> @@ -3255,7 +3254,6 @@ void __init hugetlb_add_hstate(unsigned int order)
> unsigned long i;
>
> if (size_to_hstate(PAGE_SIZE << order)) {
> - pr_warn("hugepagesz= specified twice, ignoring\n");
> return;
> }
Nitpick: I think the brackets need to be removed to follow linux
coding style. With that:
Reviewed-by: Peter Xu <peterx@redhat.com>
--
Peter Xu
^ permalink raw reply
* Re: [PATCH 1/1] powerpc/rtas: Implement reentrant rtas call
From: Nathan Lynch @ 2020-04-10 19:28 UTC (permalink / raw)
To: Leonardo Bras
Cc: Gautham R. Shenoy, Greg Kroah-Hartman, linux-kernel,
Nicholas Piggin, Paul Mackerras, Nadav Amit, Thomas Gleixner,
linuxppc-dev, Allison Randal
In-Reply-To: <20200408223901.760733-1-leonardo@linux.ibm.com>
Leonardo Bras <leonardo@linux.ibm.com> writes:
> Implement rtas_call_reentrant() for reentrant rtas-calls:
> "ibm,int-on", "ibm,int-off",ibm,get-xive" and "ibm,set-xive".
>
> On LoPAPR Version 1.1 (March 24, 2016), from 7.3.10.1 to 7.3.10.4,
> items 2 and 3 say:
>
> 2 - For the PowerPC External Interrupt option: The * call must be
> reentrant to the number of processors on the platform.
> 3 - For the PowerPC External Interrupt option: The * argument call
> buffer for each simultaneous call must be physically unique.
>
> So, these rtas-calls can be called in a lockless way, if using
> a different buffer for each call.
From the language in the spec it's clear that these calls are intended
to be reentrant with respect to themselves, but it's less clear to me
that they are safe to call simultaneously with respect to each other or
arbitrary other RTAS methods.
> This can be useful to avoid deadlocks in crashing, where rtas-calls are
> needed, but some other thread crashed holding the rtas.lock.
Are these calls commonly used in the crash-handling path? Is this
addressing a real issue you've seen?
> +/*
> + * Used for reentrant rtas calls.
> + * According to LoPAR documentation, only "ibm,int-on", "ibm,int-off",
> + * "ibm,get-xive" and "ibm,set-xive" are currently reentrant.
> + * Reentrant calls need their own rtas_args buffer, so not using rtas.args.
> + */
Please use kernel-doc format in new code.
> +int rtas_call_reentrant(int token, int nargs, int nret, int *outputs, ...)
> +{
> + va_list list;
> + struct rtas_args rtas_args;
> +
> + if (!rtas.entry || token == RTAS_UNKNOWN_SERVICE)
> + return -1;
> +
> + va_start(list, outputs);
> + va_rtas_call_unlocked(&rtas_args, token, nargs, nret, list);
> + va_end(list);
No, I don't think you can place the RTAS argument buffer on the stack:
7.2.7, Software Implementation Note:
| The OS must be aware that the effective address range for RTAS is 4
| GB when instantiated in 32-bit mode and the OS should not pass RTAS
| addresses or blocks of data which might fall outside of this range.
^ permalink raw reply
* Re: [PATCH v2 2/4] hugetlbfs: move hugepagesz= parsing to arch independent code
From: Peter Xu @ 2020-04-10 19:26 UTC (permalink / raw)
To: Mike Kravetz
Cc: linux-doc, Catalin Marinas, Dave Hansen, Heiko Carstens, linux-mm,
Paul Mackerras, sparclinux, linux-riscv, Will Deacon,
Mina Almasry, linux-s390, Jonathan Corbet, Christian Borntraeger,
Ingo Molnar, Longpeng, Albert Ou, Vasily Gorbik, Paul Walmsley,
Thomas Gleixner, linux-arm-kernel, linux-kernel, Palmer Dabbelt,
Andrew Morton, linuxppc-dev, David S . Miller
In-Reply-To: <20200401183819.20647-3-mike.kravetz@oracle.com>
On Wed, Apr 01, 2020 at 11:38:17AM -0700, Mike Kravetz wrote:
> Now that architectures provide arch_hugetlb_valid_size(), parsing
> of "hugepagesz=" can be done in architecture independent code.
> Create a single routine to handle hugepagesz= parsing and remove
> all arch specific routines. We can also remove the interface
> hugetlb_bad_size() as this is no longer used outside arch independent
> code.
>
> This also provides consistent behavior of hugetlbfs command line
> options. The hugepagesz= option should only be specified once for
> a specific size, but some architectures allow multiple instances.
> This appears to be more of an oversight when code was added by some
> architectures to set up ALL huge pages sizes.
>
> Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
This could change the error messages for a wrong setup on archs, but I
guess it's not a big deal, assuming even to capture error people will
majorly still look for error lines in general..
Reviewed-by: Peter Xu <peterx@redhat.com>
--
Peter Xu
^ permalink raw reply
* Re: Linux-next POWER9 NULL pointer NIP since 1st Apr.
From: Qian Cai @ 2020-04-10 19:20 UTC (permalink / raw)
To: Steven Rostedt; +Cc: linuxppc-dev, LKML, Nicholas Piggin
In-Reply-To: <20200409101413.35d9c72d@gandalf.local.home>
> On Apr 9, 2020, at 10:14 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Thu, 9 Apr 2020 06:06:35 -0400
> Qian Cai <cai@lca.pw> wrote:
>
>>>> I’ll go to bisect some more but it is going to take a while.
>>>>
>>>> $ git log --oneline 4c205c84e249..8e99cf91b99b
>>>> 8e99cf91b99b tracing: Do not allocate buffer in trace_find_next_entry() in atomic
>>>> 2ab2a0924b99 tracing: Add documentation on set_ftrace_notrace_pid and set_event_notrace_pid
>>>> ebed9628f5c2 selftests/ftrace: Add test to test new set_event_notrace_pid file
>>>> ed8839e072b8 selftests/ftrace: Add test to test new set_ftrace_notrace_pid file
>>>> 276836260301 tracing: Create set_event_notrace_pid to not trace tasks
>>>
>>>> b3b1e6ededa4 ftrace: Create set_ftrace_notrace_pid to not trace tasks
>>>> 717e3f5ebc82 ftrace: Make function trace pid filtering a bit more exact
>>>
>>> If it is affecting function tracing, it is probably one of the above two
>>> commits.
>>
>> OK, it was narrowed down to one of those messed with mcount here,
>
> Thing is, nothing here touches mcount.
Yes, you are right. I went back to test the commit just before the 5.7-trace merge request,
I did reproduce there. The thing is that this bastard could take more 6-hour to happen,
so my previous attempt did not wait long enough. Back to the square one...
>
>>
>> 8e99cf91b99b tracing: Do not allocate buffer in trace_find_next_entry() in atomic
>
> Touches reading the trace buffer.
>
>> 2ab2a0924b99 tracing: Add documentation on set_ftrace_notrace_pid and set_event_notrace_pid
>
> Documentation.
>
>> 6a13a0d7b4d1 ftrace/kprobe: Show the maxactive number on kprobe_events
>
> kprobe output.
>
>> c9b7a4a72ff6 ring-buffer/tracing: Have iterator acknowledge dropped events
>
> Reading the buffer.
>
>> 06e0a548bad0 tracing: Do not disable tracing when reading the trace file
>
> Reading the buffer.
>
>> 1039221cc278 ring-buffer: Do not disable recording when there is an iterator
>
> Reading the buffer.
>
>> 07b8b10ec94f ring-buffer: Make resize disable per cpu buffer instead of total buffer
>
> Resizing the buffer.
>
>> 153368ce1bd0 ring-buffer: Optimize rb_iter_head_event()
>
> Reading the buffer.
>
>> ff84c50cfb4b ring-buffer: Do not die if rb_iter_peek() fails more than thrice
>
> Reading the buffer.
>
>> 785888c544e0 ring-buffer: Have rb_iter_head_event() handle concurrent writer
>
> Reading the buffer.
>
>> 28e3fc56a471 ring-buffer: Add page_stamp to iterator for synchronization
>
> Reading the buffer.
>
>> bc1a72afdc4a ring-buffer: Rename ring_buffer_read() to read_buffer_iter_advance()
>
> Reading the buffer.
>
>> ead6ecfddea5 ring-buffer: Have ring_buffer_empty() not depend on tracing stopped
>
> Reading the buffer.
>
>> ff895103a84a tracing: Save off entry when peeking at next entry
>
> Reading the buffer.
>
>> bf2cbe044da2 tracing: Use address-of operator on section symbols
>
> Affects trace_printk()
>
>> bbd9d05618a6 gpu/trace: add a gpu total memory usage tracepoint
>
> New tracepoint infrastructure (just new trace events for gpu)
>
>> 89b74cac7834 tools/bootconfig: Show line and column in parse error
>
> Extended command line boot config.
>
>> 306b69dce926 bootconfig: Support O=<builddir> option
>
> Extended command line boot config
>
>> 5412e0b763e0 tracing: Remove unused TRACE_BUFFER bits
>
> Removed unused enums.
>
>> b396bfdebffc tracing: Have hwlat ts be first instance and record count of instances
>
> Affects only the hard ware latency detector (most likely not even
> configured in the kernel).
>
> So I don't understand how any of the above commits can cause a problem.
>
> -- Steve
^ permalink raw reply
* Re: [PATCH v2 1/4] hugetlbfs: add arch_hugetlb_valid_size
From: Peter Xu @ 2020-04-10 19:16 UTC (permalink / raw)
To: Mike Kravetz
Cc: linux-doc, Catalin Marinas, Dave Hansen, Heiko Carstens, linux-mm,
Paul Mackerras, sparclinux, linux-riscv, Will Deacon,
Mina Almasry, linux-s390, Jonathan Corbet, Christian Borntraeger,
Ingo Molnar, Longpeng, Albert Ou, Vasily Gorbik, Paul Walmsley,
Thomas Gleixner, linux-arm-kernel, linux-kernel, Palmer Dabbelt,
Andrew Morton, linuxppc-dev, David S . Miller
In-Reply-To: <20200401183819.20647-2-mike.kravetz@oracle.com>
On Wed, Apr 01, 2020 at 11:38:16AM -0700, Mike Kravetz wrote:
> diff --git a/arch/arm64/include/asm/hugetlb.h b/arch/arm64/include/asm/hugetlb.h
> index 2eb6c234d594..81606223494f 100644
> --- a/arch/arm64/include/asm/hugetlb.h
> +++ b/arch/arm64/include/asm/hugetlb.h
> @@ -59,6 +59,8 @@ extern void huge_pte_clear(struct mm_struct *mm, unsigned long addr,
> extern void set_huge_swap_pte_at(struct mm_struct *mm, unsigned long addr,
> pte_t *ptep, pte_t pte, unsigned long sz);
> #define set_huge_swap_pte_at set_huge_swap_pte_at
> +bool __init arch_hugetlb_valid_size(unsigned long size);
> +#define arch_hugetlb_valid_size arch_hugetlb_valid_size
Sorry for chimming in late.
Since we're working on removing arch-dependent codes after all.. I'm
thinking whether we can define arch_hugetlb_valid_size() once in the
common header (e.g. linux/hugetlb.h), then in mm/hugetlb.c:
bool __init __attribute((weak)) arch_hugetlb_valid_size(unsigned long size)
{
return size == HPAGE_SIZE;
}
We can simply redefine arch_hugetlb_valid_size() in arch specific C
files where we want to override the default. Would that be slightly
cleaner?
Thanks,
--
Peter Xu
^ permalink raw reply
* Re: [PATCH v2 2/2] powerpc: Remove Xilinx PPC405/PPC440 support
From: Rob Herring @ 2020-04-10 17:33 UTC (permalink / raw)
To: Michal Simek
Cc: Kate Stewart, Mark Rutland, Desnes A. Nunes do Rosario,
Geert Uytterhoeven, linux-doc, linux-fbdev, dri-devel,
Paul Mackerras, Miquel Raynal, Mauro Carvalho Chehab,
Fabio Estevam, Sasha Levin, sfr, Jonathan Corbet, maz,
Masahiro Yamada, YueHaibing, Krzysztof Kozlowski, Allison Randal,
linux-arm-kernel, devicetree, Andrew Donnellan, Arnd Bergmann,
Bartlomiej Zolnierkiewicz, Alistair Popple, linuxppc-dev,
Nicholas Piggin, Alexios Zavras, git, Jonathan Cameron,
Thomas Gleixner, Andy Shevchenko, Dmitry Vyukov, monstr, Wei Hu,
Greg Kroah-Hartman, Nick Desaulniers, linux-kernel,
Enrico Weigelt, David S. Miller, Thiago Jung Bauermann
In-Reply-To: <9c3e02ffa9812c6f046708b45932d40f33e8817a.1585575111.git.michal.simek@xilinx.com>
On Mon, Mar 30, 2020 at 03:32:17PM +0200, Michal Simek wrote:
> The latest Xilinx design tools called ISE and EDK has been released in
> October 2013. New tool doesn't support any PPC405/PPC440 new designs.
> These platforms are no longer supported and tested.
>
> PowerPC 405/440 port is orphan from 2013 by
> commit cdeb89943bfc ("MAINTAINERS: Fix incorrect status tag") and
> commit 19624236cce1 ("MAINTAINERS: Update Grant's email address and maintainership")
> that's why it is time to remove the support fot these platforms.
>
> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> ---
>
> Changes in v2:
> - Based on my chat with Arnd I removed arch/powerpc/xmon/ changes done in
> v1 to keep them the same as before. (kbuild reported some issues with it
> too)
>
> Documentation/devicetree/bindings/xilinx.txt | 143 ------
Acked-by: Rob Herring <robh@kernel.org>
> Documentation/powerpc/bootwrapper.rst | 28 +-
> MAINTAINERS | 6 -
> arch/powerpc/Kconfig.debug | 2 +-
> arch/powerpc/boot/Makefile | 7 +-
> arch/powerpc/boot/dts/Makefile | 1 -
> arch/powerpc/boot/dts/virtex440-ml507.dts | 406 ----------------
> arch/powerpc/boot/dts/virtex440-ml510.dts | 466 -------------------
> arch/powerpc/boot/ops.h | 1 -
> arch/powerpc/boot/serial.c | 5 -
> arch/powerpc/boot/uartlite.c | 79 ----
> arch/powerpc/boot/virtex.c | 97 ----
> arch/powerpc/boot/virtex405-head.S | 31 --
> arch/powerpc/boot/wrapper | 8 -
> arch/powerpc/configs/40x/virtex_defconfig | 75 ---
> arch/powerpc/configs/44x/virtex5_defconfig | 74 ---
> arch/powerpc/configs/ppc40x_defconfig | 8 -
> arch/powerpc/configs/ppc44x_defconfig | 8 -
> arch/powerpc/include/asm/xilinx_intc.h | 16 -
> arch/powerpc/include/asm/xilinx_pci.h | 21 -
> arch/powerpc/kernel/cputable.c | 39 --
> arch/powerpc/platforms/40x/Kconfig | 31 --
> arch/powerpc/platforms/40x/Makefile | 1 -
> arch/powerpc/platforms/40x/virtex.c | 54 ---
> arch/powerpc/platforms/44x/Kconfig | 37 --
> arch/powerpc/platforms/44x/Makefile | 2 -
> arch/powerpc/platforms/44x/virtex.c | 60 ---
> arch/powerpc/platforms/44x/virtex_ml510.c | 30 --
> arch/powerpc/platforms/Kconfig | 4 -
> arch/powerpc/sysdev/Makefile | 2 -
> arch/powerpc/sysdev/xilinx_intc.c | 88 ----
> arch/powerpc/sysdev/xilinx_pci.c | 132 ------
> drivers/char/Kconfig | 2 +-
> drivers/video/fbdev/Kconfig | 2 +-
> 34 files changed, 7 insertions(+), 1959 deletions(-)
^ permalink raw reply
* Re: [PATCH 1/2] selftests: vm: Do not override definition of ARCH
From: Shuah Khan @ 2020-04-10 15:57 UTC (permalink / raw)
To: Michael Ellerman, Sandipan Das, shuah, linux-kselftest
Cc: aneesh.kumar, kamalesh, linux-mm, mhiramat, Shuah Khan,
linuxppc-dev
In-Reply-To: <87lfp9zvl4.fsf@mpe.ellerman.id.au>
On 2/10/20 7:49 PM, Michael Ellerman wrote:
> Sandipan Das <sandipan@linux.ibm.com> writes:
>> Independent builds of the vm selftests is currently broken
>> because commit 7549b3364201 overrides the value of ARCH with
>> the machine name from uname. This does not always match the
>> architecture names used for tasks like header installation.
>>
In the interest not adding more delays to this patch, I fixed up
the commit log for the following error and applied it. I hope to
send this up for next rc.
ERROR: Please use git commit description style 'commit <12+ chars of
sha1> ("<title line>")' - ie: 'commit 7549b3364201 ("selftests: vm:
Build/Run 64bit tests only on 64bit arch")'
#93:
because commit 7549b3364201 overrides the value of ARCH with
The fixed up now looks as follows:
Independent builds of the vm selftests is currently broken because
commit 7549b3364201 ("selftests: vm: Build/Run 64bit tests only on
64bit arch") overrides the value of ARCH with the machine name from
uname. This does not always match the architecture names used for
tasks like header installation.
Please make sure to run checkpatch with --strict to catch these
kinds of errors in the future.
thanks,
-- Shuah
^ permalink raw reply
* Re: [PATCH] usb: gadget: fsl: Fix a wrong judgment in fsl_udc_probe()
From: Sergei Shtylyov @ 2020-04-10 9:47 UTC (permalink / raw)
To: Tang Bin, leoyang.li, balbi, gregkh
Cc: Markus.Elfring, linux-usb, linuxppc-dev, linux-kernel,
Shengju Zhang
In-Reply-To: <20200410015832.8012-1-tangbin@cmss.chinamobile.com>
On 10.04.2020 4:58, Tang Bin wrote:
> If the function "platform_get_irq()" failed, the negative value
> returned will not be detected here, including "-EPROBE_DEFER", which
> causes the application to fail to get the correct error message.
> Thus it must be fixed.
platform_get_irq() prints an appropriate error message, the problem is that
the current code calls request_irq() with error code instead of IRQ.
> Signed-off-by: Tang Bin <tangbin@cmss.chinamobile.com>
> Signed-off-by: Shengju Zhang <zhangshengju@cmss.chinamobile.com>
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH] usb: gadget: fsl: Fix a wrong judgment in fsl_udc_probe()
From: Sergei Shtylyov @ 2020-04-10 9:36 UTC (permalink / raw)
To: Tang Bin, leoyang.li, balbi, gregkh
Cc: Markus.Elfring, linux-usb, linuxppc-dev, linux-kernel,
Shengju Zhang
In-Reply-To: <20200410015832.8012-1-tangbin@cmss.chinamobile.com>
Hello!
On 10.04.2020 4:58, Tang Bin wrote:
> If the function "platform_get_irq()" failed, the negative value
> returned will not be detected here, including "-EPROBE_DEFER", which
> causes the application to fail to get the correct error message.
> Thus it must be fixed.
>
> Signed-off-by: Tang Bin <tangbin@cmss.chinamobile.com>
> Signed-off-by: Shengju Zhang <zhangshengju@cmss.chinamobile.com>
> ---
> drivers/usb/gadget/udc/fsl_udc_core.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c b/drivers/usb/gadget/udc/fsl_udc_core.c
> index ec6eda426..60853ad10 100644
> --- a/drivers/usb/gadget/udc/fsl_udc_core.c
> +++ b/drivers/usb/gadget/udc/fsl_udc_core.c
> @@ -2441,8 +2441,8 @@ static int fsl_udc_probe(struct platform_device *pdev)
> udc_controller->max_ep = (dccparams & DCCPARAMS_DEN_MASK) * 2;
>
> udc_controller->irq = platform_get_irq(pdev, 0);
> - if (!udc_controller->irq) {
This check has always been wrong, doesn't account for real errors and
probe deferral...
> - ret = -ENODEV;
> + if (udc_controller->irq <= 0) {
Note that platfrom_get_irq() no longer returns 0 on error.
> + ret = udc_controller->irq ? : -ENODEV;
> goto err_iounmap;
> }
MBR, Sergei
^ permalink raw reply
* Re: usb: gadget: fsl: Fix a wrong judgment in fsl_udc_probe()
From: Tang Bin @ 2020-04-10 9:15 UTC (permalink / raw)
To: Markus Elfring, linux-usb, linuxppc-dev
Cc: Felipe Balbi, Greg Kroah-Hartman, kernel-janitors, LKML, Li Yang,
Shengju Zhang
In-Reply-To: <aa7006c9-8b83-5f30-86a6-8d60d290f824@web.de>
Hi Markus:
On 2020/4/10 16:30, Markus Elfring wrote:
>> Hardware experiments show that the negative return value is not just "-EPROBE_DEFER".
> How much will this specific error code influence our understanding
> of the discussed software situation?
>
From my superficial knowledge, I think we should not think about it
too complicated. The return value is just zero or negative, and for
these negative return value, such as
"-ENODEV"、"-ENXIO"、"-ENOENT"、“EPROBE_DEFER”，may be the same
effect。But“-EPROBE_DEFER”has another importment function: Driver
requested deferred probing，which is used in cases where the dependency
resource is not ready during the driver initialization process.
>>>> + ret = udc_controller->irq ? : -ENODEV;
>>> Will it be clearer to specify values for all cases in such a conditional operator
>>> (instead of leaving one case empty)?
>> I don't know what you mean of "instead of leaving one case empty".
> I suggest to reconsider also the proposed specification “… ? : …”.
What you mean is the way I'm written？
I have provided two ways of patching, both functional can be verified on
hardware.
Thanks for your patience.
Tang Bin
^ permalink raw reply
* Re: usb: gadget: fsl: Fix a wrong judgment in fsl_udc_probe()
From: Markus Elfring @ 2020-04-10 8:30 UTC (permalink / raw)
To: Tang Bin, linux-usb, linuxppc-dev
Cc: Felipe Balbi, Greg Kroah-Hartman, kernel-janitors, LKML, Li Yang,
Shengju Zhang
In-Reply-To: <0b718268-d330-dfc1-aca3-3dd3203363d7@cmss.chinamobile.com>
> Hardware experiments show that the negative return value is not just "-EPROBE_DEFER".
How much will this specific error code influence our understanding
of the discussed software situation?
>>> + ret = udc_controller->irq ? : -ENODEV;
>> Will it be clearer to specify values for all cases in such a conditional operator
>> (instead of leaving one case empty)?
>
> I don't know what you mean of "instead of leaving one case empty".
I suggest to reconsider also the proposed specification “… ? : …”.
Regards,
Markus
^ permalink raw reply
* Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc
From: Daniel Vetter @ 2020-04-10 8:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-hyperv, David Airlie, dri-devel, Linux MM, K. Y. Srinivasan,
Sumit Semwal, open list:GENERIC INCLUDE/A..., linux-s390, Wei Liu,
Stephen Hemminger, X86 ML, Christoph Hellwig, Peter Zijlstra,
Laura Abbott, Nitin Gupta, Haiyang Zhang,
moderated list:DMA BUFFER SHARING FRAMEWORK, bpf, Linux ARM,
Robin Murphy, Linux Kernel Mailing List, Minchan Kim,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
Sakari Ailus, Andrew Morton, linuxppc-dev
In-Reply-To: <0f360b9cb72b80bae0d0db8150f65598c2776268.camel@kernel.crashing.org>
On Fri, Apr 10, 2020 at 12:57 AM Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
>
> On Thu, 2020-04-09 at 11:41 +0200, Daniel Vetter wrote:
> > Now if these boxes didn't ever have agp then I think we can get away
> > with deleting this, since we've already deleted the legacy radeon
> > driver. And that one used vmalloc for everything. The new kms one does
> > use the dma-api if the gpu isn't connected through agp
>
> Definitely no AGP there.
Ah in that case I think we can be sure that this code is dead.
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* Re: [PATCH] usb: gadget: fsl: Fix a wrong judgment in fsl_udc_probe()
From: Tang Bin @ 2020-04-10 8:05 UTC (permalink / raw)
To: Markus Elfring
Cc: Felipe Balbi, Greg Kroah-Hartman, linux-usb, kernel-janitors,
linux-kernel, Li Yang, linuxppc-dev
In-Reply-To: <be8cd229-884a-40e6-3363-7c4680a51b30@web.de>
Hi Markus
On 2020/4/10 15:33, Markus Elfring wrote:
>> If the function "platform_get_irq()" failed, the negative value
>> returned will not be detected here, including "-EPROBE_DEFER",
> I suggest to adjust this change description.
>
> Wording alternative:
> The negative return value (which could eventually be “-EPROBE_DEFER”)
> will not be detected here from a failed call of the function “platform_get_irq”.
Hardware experiments show that the negative return value is not just
"-EPROBE_DEFER".
>
>> which causes the application to fail to get the correct error message.
> Will another fine-tuning become relevant also for this wording?
Maybe that's not quite accurate.
>
>
>> Thus it must be fixed.
> Wording alternative:
> Thus adjust the error detection and corresponding exception handling.
Got it.
>
>
>> Signed-off-by: Tang Bin <tangbin@cmss.chinamobile.com>
>> Signed-off-by: Shengju Zhang <zhangshengju@cmss.chinamobile.com>
> How do you think about to add the tags “Fixes”, “Link” and “Reported-by”?
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=c0cc271173b2e1c2d8d0ceaef14e4dfa79eefc0d#n584
>
> usb: gadget: fsl_udc_core: Checking for a failed platform_get_irq() call in fsl_udc_probe()
> https://lore.kernel.org/linux-usb/36341bb1-1e00-5eb1-d032-60dcc614ddaf@web.de/
> https://lkml.org/lkml/2020/4/8/442
>
> …
>> +++ b/drivers/usb/gadget/udc/fsl_udc_core.c
>> @@ -2441,8 +2441,8 @@ static int fsl_udc_probe(struct platform_device *pdev)
>> udc_controller->max_ep = (dccparams & DCCPARAMS_DEN_MASK) * 2;
>>
>> udc_controller->irq = platform_get_irq(pdev, 0);
>> - if (!udc_controller->irq) {
>> - ret = -ENODEV;
>> + if (udc_controller->irq <= 0) {
> Will such a failure predicate need any more clarification?
>
> How does this check fit to the current software documentation?
Maybe my tags are not suitable.
>
>
>> + ret = udc_controller->irq ? : -ENODEV;
> Will it be clearer to specify values for all cases in such a conditional operator
> (instead of leaving one case empty)?
I don't know what you mean of "instead of leaving one case empty". But
by experiment, "ret = udc_controller->irq ? : -ENODEV" or "ret =
udc_controller->irq < 0 ? udc_controller->irq : -ENODEV" should be
suitable here.
Thank you for your guidance.
Tang Bin
^ permalink raw reply
* Re: [PATCH] usb: gadget: fsl: Fix a wrong judgment in fsl_udc_probe()
From: Markus Elfring @ 2020-04-10 7:33 UTC (permalink / raw)
To: Tang Bin, Li Yang, Greg Kroah-Hartman, Felipe Balbi, linux-usb,
linuxppc-dev
Cc: kernel-janitors, linux-kernel, Shengju Zhang
In-Reply-To: <20200410015832.8012-1-tangbin@cmss.chinamobile.com>
> If the function "platform_get_irq()" failed, the negative value
> returned will not be detected here, including "-EPROBE_DEFER",
I suggest to adjust this change description.
Wording alternative:
The negative return value (which could eventually be “-EPROBE_DEFER”)
will not be detected here from a failed call of the function “platform_get_irq”.
> which causes the application to fail to get the correct error message.
Will another fine-tuning become relevant also for this wording?
> Thus it must be fixed.
Wording alternative:
Thus adjust the error detection and corresponding exception handling.
> Signed-off-by: Tang Bin <tangbin@cmss.chinamobile.com>
> Signed-off-by: Shengju Zhang <zhangshengju@cmss.chinamobile.com>
How do you think about to add the tags “Fixes”, “Link” and “Reported-by”?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=c0cc271173b2e1c2d8d0ceaef14e4dfa79eefc0d#n584
usb: gadget: fsl_udc_core: Checking for a failed platform_get_irq() call in fsl_udc_probe()
https://lore.kernel.org/linux-usb/36341bb1-1e00-5eb1-d032-60dcc614ddaf@web.de/
https://lkml.org/lkml/2020/4/8/442
…
> +++ b/drivers/usb/gadget/udc/fsl_udc_core.c
> @@ -2441,8 +2441,8 @@ static int fsl_udc_probe(struct platform_device *pdev)
> udc_controller->max_ep = (dccparams & DCCPARAMS_DEN_MASK) * 2;
>
> udc_controller->irq = platform_get_irq(pdev, 0);
> - if (!udc_controller->irq) {
> - ret = -ENODEV;
> + if (udc_controller->irq <= 0) {
Will such a failure predicate need any more clarification?
How does this check fit to the current software documentation?
> + ret = udc_controller->irq ? : -ENODEV;
Will it be clearer to specify values for all cases in such a conditional operator
(instead of leaving one case empty)?
Regards,
Markus
^ permalink raw reply
* Re: [PATCH v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA
From: Baoquan He @ 2020-04-10 6:50 UTC (permalink / raw)
To: Mike Rapoport
Cc: mmorana, Catalin Marinas, Heiko Carstens, Michal Hocko,
open list:MEMORY MANAGEMENT, Paul Mackerras, H. Peter Anvin,
sparclinux, Alexander Duyck, linux-s390, x86,
Christian Borntraeger, Ingo Molnar, Hoan Tran, Pavel Tatashin,
lho, Vasily Gorbik, Vlastimil Babka, Will Deacon, Borislav Petkov,
Thomas Gleixner, linux-arm-kernel, Oscar Salvador, linux-kernel,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20200409162741.GA9387@linux.ibm.com>
On 04/09/20 at 07:27pm, Mike Rapoport wrote:
> On Tue, Mar 31, 2020 at 04:21:38PM +0200, Michal Hocko wrote:
> > On Tue 31-03-20 22:03:32, Baoquan He wrote:
> > > Hi Michal,
> > >
> > > On 03/31/20 at 10:55am, Michal Hocko wrote:
> > > > On Tue 31-03-20 11:14:23, Mike Rapoport wrote:
> > > > > Maybe I mis-read the code, but I don't see how this could happen. In the
> > > > > HAVE_MEMBLOCK_NODE_MAP=y case, free_area_init_node() calls
> > > > > calculate_node_totalpages() that ensures that node->node_zones are entirely
> > > > > within the node because this is checked in zone_spanned_pages_in_node().
> > > >
> > > > zone_spanned_pages_in_node does chech the zone boundaries are within the
> > > > node boundaries. But that doesn't really tell anything about other
> > > > potential zones interleaving with the physical memory range.
> > > > zone->spanned_pages simply gives the physical range for the zone
> > > > including holes. Interleaving nodes are essentially a hole
> > > > (__absent_pages_in_range is going to skip those).
> > > >
> > > > That means that when free_area_init_core simply goes over the whole
> > > > physical zone range including holes and that is why we need to check
> > > > both for physical and logical holes (aka other nodes).
> > > >
> > > > The life would be so much easier if the whole thing would simply iterate
> > > > over memblocks...
> > >
> > > The memblock iterating sounds a great idea. I tried with putting the
> > > memblock iterating in the upper layer, memmap_init(), which is used for
> > > boot mem only anyway. Do you think it's doable and OK? It yes, I can
> > > work out a formal patch to make this simpler as you said. The draft code
> > > is as below. Like this it uses the existing code and involves little change.
> >
> > Doing this would be a step in the right direction! I haven't checked the
> > code very closely though. The below sounds way too simple to be truth I
> > am afraid. First for_each_mem_pfn_range is available only for
> > CONFIG_HAVE_MEMBLOCK_NODE_MAP (which is one of the reasons why I keep
> > saying that I really hate that being conditional). Also I haven't really
> > checked the deferred initialization path - I have a very vague
> > recollection that it has been converted to the memblock api but I have
> > happilly dropped all that memory.
>
> The Baoquan's patch almost did it, at least for simple case of qemu with 2
> nodes. It's only missing the adjustment to the size passed to
> memmap_init_zone() as it may change because of clamping.
Right, the size need be adjusted after start and end clamping.
>
> I've drafted something that removes HAVE_MEMBLOCK_NODE_MAP and added this
> patch there [1]. For several memory configurations I could emulate with
> qemu it worked.
> I'm going to wait a bit to see of kbuild is happy and then I'll send the
> patches.
>
> Baoquan, I took liberty to add your SoB, hope you don't mind.
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/rppt/linux.git/log/?h=memblock/all-have-node-map
Of course not. Thanks for doing this, and look forward to seeing your
formal patchset posting when it's ready.
>
> > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > > index 138a56c0f48f..558d421f294b 100644
> > > --- a/mm/page_alloc.c
> > > +++ b/mm/page_alloc.c
> > > @@ -6007,14 +6007,6 @@ void __meminit memmap_init_zone(unsigned long size, int nid, unsigned long zone,
> > > * function. They do not exist on hotplugged memory.
> > > */
> > > if (context == MEMMAP_EARLY) {
> > > - if (!early_pfn_valid(pfn)) {
> > > - pfn = next_pfn(pfn);
> > > - continue;
> > > - }
> > > - if (!early_pfn_in_nid(pfn, nid)) {
> > > - pfn++;
> > > - continue;
> > > - }
> > > if (overlap_memmap_init(zone, &pfn))
> > > continue;
> > > if (defer_init(nid, pfn, end_pfn))
> > > @@ -6130,9 +6122,17 @@ static void __meminit zone_init_free_lists(struct zone *zone)
> > > }
> > >
> > > void __meminit __weak memmap_init(unsigned long size, int nid,
> > > - unsigned long zone, unsigned long start_pfn)
> > > + unsigned long zone, unsigned long range_start_pfn)
> > > {
> > > - memmap_init_zone(size, nid, zone, start_pfn, MEMMAP_EARLY, NULL);
> > > + unsigned long start_pfn, end_pfn;
> > > + unsigned long range_end_pfn = range_start_pfn + size;
> > > + int i;
> > > + for_each_mem_pfn_range(i, nid, &start_pfn, &end_pfn, NULL) {
> > > + start_pfn = clamp(start_pfn, range_start_pfn, range_end_pfn);
> > > + end_pfn = clamp(end_pfn, range_start_pfn, range_end_pfn);
> > > + if (end_pfn > start_pfn)
> > > + memmap_init_zone(size, nid, zone, start_pfn, MEMMAP_EARLY, NULL);
> > > + }
> > > }
> > >
> > > static int zone_batchsize(struct zone *zone)
> >
> > --
> > Michal Hocko
> > SUSE Labs
>
> --
> Sincerely yours,
> Mike.
>
>
^ permalink raw reply
* Re: [PATCH RFC] mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP (was: Re: [PATCH v3 0/5] mm: Enable CONFIG_NODES_SPAN_OTHER_NODES by default for NUMA)
From: Baoquan He @ 2020-04-10 6:46 UTC (permalink / raw)
To: Michal Hocko
Cc: mmorana, Catalin Marinas, Heiko Carstens,
open list:MEMORY MANAGEMENT, Paul Mackerras, H. Peter Anvin,
sparclinux, Alexander Duyck, linux-s390, x86, Mike Rapoport,
Christian Borntraeger, Ingo Molnar, Hoan Tran, Pavel Tatashin,
lho, Vasily Gorbik, Vlastimil Babka, Will Deacon, Borislav Petkov,
Thomas Gleixner, linux-arm-kernel, Oscar Salvador, linux-kernel,
Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20200409153321.GQ18386@dhcp22.suse.cz>
On 04/09/20 at 05:33pm, Michal Hocko wrote:
> On Thu 09-04-20 22:41:19, Baoquan He wrote:
> > On 04/02/20 at 10:01am, Michal Hocko wrote:
> > > On Wed 01-04-20 10:51:55, Mike Rapoport wrote:
> > > > Hi,
> > > >
> > > > On Wed, Apr 01, 2020 at 01:42:27PM +0800, Baoquan He wrote:
> > > [...]
> > > > > From above information, we can remove HAVE_MEMBLOCK_NODE_MAP, and
> > > > > replace it with CONFIG_NUMA. That sounds more sensible to store nid into
> > > > > memblock when NUMA support is enabled.
> > > >
> > > > Replacing CONFIG_HAVE_MEMBLOCK_NODE_MAP with CONFIG_NUMA will work, but
> > > > this will not help cleaning up the whole node/zone initialization mess and
> > > > we'll be stuck with two implementations.
> > >
> > > Yeah, this is far from optimal.
> > >
> > > > The overhead of enabling HAVE_MEMBLOCK_NODE_MAP is only for init time as
> > > > most architectures will anyway discard the entire memblock, so having it in
> > > > a UMA arch won't be a problem. The only exception is arm that uses
> > > > memblock for pfn_valid(), here we may also think about a solution to
> > > > compensate the addition of nid to the memblock structures.
> > >
> > > Well, we can make memblock_region->nid defined only for CONFIG_NUMA.
> > > memblock_get_region_node would then unconditionally return 0 on UMA.
> > > Essentially the same way we do NUMA for other MM code. I only see few
> > > direct usage of region->nid.
> >
> > Checked code again, seems HAVE_MEMBLOCK_NODE_MAP is selected directly in
> > all ARCHes which support it. Means HAVE_MEMBLOCK_NODE_MAP is enabled by
> > default on those ARCHes, and has no dependency on CONFIG_NUMA at all.
> > E.g on x86, it just calls free_area_init_nodes() in generic code path,
> > while free_area_init_nodes() is defined in CONFIG_HAVE_MEMBLOCK_NODE_MAP
> > ifdeffery scope. So I tend to agree with Mike to remove
> > HAVE_MEMBLOCK_NODE_MAP firstly on all ARCHes. We can check if it's worth
> > only defining memblock_region->nid for CONFIG_NUMA case after
> > HAVE_MEMBLOCK_NODE_MAP is removed.
>
> This can surely go in separate patches. What I meant to say is the
> region->nid is by definition 0 on !CONFIG_NUMA.
I see, thanks.
^ permalink raw reply
* Re: [PATCH 10/28] mm: only allow page table mappings for built-in zsmalloc
From: Sergey Senozhatsky @ 2020-04-10 2:38 UTC (permalink / raw)
To: Minchan Kim
Cc: linux-hyperv, Peter Zijlstra, dri-devel, linux-mm,
K. Y. Srinivasan, Sumit Semwal, linux-arch, linux-s390, Wei Liu,
Stephen Hemminger, x86, Christoph Hellwig, David Airlie,
Laura Abbott, Nitin Gupta, Daniel Vetter, Haiyang Zhang,
linaro-mm-sig, bpf, linux-arm-kernel, Robin Murphy, linux-kernel,
sergey.senozhatsky, iommu, Sakari Ailus, Andrew Morton,
linuxppc-dev
In-Reply-To: <20200409170813.GD247701@google.com>
On (20/04/09 10:08), Minchan Kim wrote:
> > > Even though I don't know how many usecase we have using zsmalloc as
> > > module(I heard only once by dumb reason), it could affect existing
> > > users. Thus, please include concrete explanation in the patch to
> > > justify when the complain occurs.
> >
> > The justification is 'we can unexport functions that have no sane reason
> > of being exported in the first place'.
> >
> > The Changelog pretty much says that.
>
> Okay, I hope there is no affected user since this patch.
> If there are someone, they need to provide sane reason why they want
> to have zsmalloc as module.
I'm one of those who use zsmalloc as a module - mainly because I use zram
as a compressing general purpose block device, not as a swap device.
I create zram0, mkfs, mount, checkout and compile code, once done -
umount, rmmod. This reduces the number of writes to SSD. Some people use
tmpfs, but zram device(-s) can be much larger in size. That's a niche use
case and I'm not against the patch.
-ss
^ permalink raw reply
* [PATCH] usb: gadget: fsl: Fix a wrong judgment in fsl_udc_probe()
From: Tang Bin @ 2020-04-10 1:58 UTC (permalink / raw)
To: leoyang.li, balbi, gregkh
Cc: Tang Bin, linux-usb, linux-kernel, Markus.Elfring, linuxppc-dev,
Shengju Zhang
If the function "platform_get_irq()" failed, the negative value
returned will not be detected here, including "-EPROBE_DEFER", which
causes the application to fail to get the correct error message.
Thus it must be fixed.
Signed-off-by: Tang Bin <tangbin@cmss.chinamobile.com>
Signed-off-by: Shengju Zhang <zhangshengju@cmss.chinamobile.com>
---
drivers/usb/gadget/udc/fsl_udc_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/udc/fsl_udc_core.c b/drivers/usb/gadget/udc/fsl_udc_core.c
index ec6eda426..60853ad10 100644
--- a/drivers/usb/gadget/udc/fsl_udc_core.c
+++ b/drivers/usb/gadget/udc/fsl_udc_core.c
@@ -2441,8 +2441,8 @@ static int fsl_udc_probe(struct platform_device *pdev)
udc_controller->max_ep = (dccparams & DCCPARAMS_DEN_MASK) * 2;
udc_controller->irq = platform_get_irq(pdev, 0);
- if (!udc_controller->irq) {
- ret = -ENODEV;
+ if (udc_controller->irq <= 0) {
+ ret = udc_controller->irq ? : -ENODEV;
goto err_iounmap;
}
--
2.20.1.windows.1
^ permalink raw reply related
* Re: [PATCH 19/28] gpu/drm: remove the powerpc hack in drm_legacy_sg_alloc
From: Benjamin Herrenschmidt @ 2020-04-09 22:56 UTC (permalink / raw)
To: Daniel Vetter
Cc: linux-hyperv, David Airlie, dri-devel, Linux MM, K. Y. Srinivasan,
Sumit Semwal, open list:GENERIC INCLUDE/A..., linux-s390, Wei Liu,
Stephen Hemminger, X86 ML, Christoph Hellwig, Peter Zijlstra,
Laura Abbott, Nitin Gupta, Haiyang Zhang,
moderated list:DMA BUFFER SHARING FRAMEWORK, bpf, Linux ARM,
Robin Murphy, Linux Kernel Mailing List, Minchan Kim,
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>, ,
Sakari Ailus, Andrew Morton, linuxppc-dev
In-Reply-To: <CAKMK7uHtkLvdsWFGiAtkzVa5mpnDvXkn3CHZQ6bgJ_enbyAc8A@mail.gmail.com>
On Thu, 2020-04-09 at 11:41 +0200, Daniel Vetter wrote:
> Now if these boxes didn't ever have agp then I think we can get away
> with deleting this, since we've already deleted the legacy radeon
> driver. And that one used vmalloc for everything. The new kms one does
> use the dma-api if the gpu isn't connected through agp
Definitely no AGP there.
Cheers
Ben.
^ permalink raw reply
* Re: [PATCH 01/28] x86/hyperv: use vmalloc_exec for the hypercall page
From: Wei Liu @ 2020-04-09 15:52 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-hyperv, David Airlie, dri-devel, linux-mm, K. Y. Srinivasan,
Sumit Semwal, linux-arch, linux-s390, Wei Liu, Stephen Hemminger,
x86, Peter Zijlstra, Laura Abbott, Nitin Gupta, Daniel Vetter,
Haiyang Zhang, linaro-mm-sig, bpf, linux-arm-kernel, Robin Murphy,
linux-kernel, Minchan Kim, iommu, Sakari Ailus, Andrew Morton,
linuxppc-dev
In-Reply-To: <20200408115926.1467567-2-hch@lst.de>
On Wed, Apr 08, 2020 at 01:58:59PM +0200, Christoph Hellwig wrote:
> Use the designated helper for allocating executable kernel memory, and
> remove the now unused PAGE_KERNEL_RX define.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Wei Liu <wei.liu@kernel.org>
^ permalink raw reply
* Re: [PATCH 25/28] mm: remove vmalloc_user_node_flags
From: Andrii Nakryiko @ 2020-04-09 22:25 UTC (permalink / raw)
To: Christoph Hellwig, Johannes Weiner
Cc: linux-hyperv, David Airlie, dri-devel, linux-mm, K. Y. Srinivasan,
Sumit Semwal, linux-arch, linux-s390, Wei Liu, Stephen Hemminger,
x86, Peter Zijlstra, Laura Abbott, Nitin Gupta, Daniel Vetter,
Haiyang Zhang, linaro-mm-sig, bpf, linux-arm-kernel, Robin Murphy,
open list, Minchan Kim, iommu, Sakari Ailus, Andrew Morton,
linuxppc-dev
In-Reply-To: <20200408115926.1467567-26-hch@lst.de>
cc Johannes who suggested this API call originally
On Wed, Apr 8, 2020 at 5:03 AM Christoph Hellwig <hch@lst.de> wrote:
>
> Open code it in __bpf_map_area_alloc, which is the only caller. Also
> clean up __bpf_map_area_alloc to have a single vmalloc call with
> slightly different flags instead of the current two different calls.
>
> For this to compile for the nommu case add a __vmalloc_node_range stub
> to nommu.c.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> include/linux/vmalloc.h | 1 -
> kernel/bpf/syscall.c | 23 +++++++++++++----------
> mm/nommu.c | 14 ++++++++------
> mm/vmalloc.c | 20 --------------------
> 4 files changed, 21 insertions(+), 37 deletions(-)
>
> diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
> index 108f49b47756..f90f2946aac2 100644
> --- a/include/linux/vmalloc.h
> +++ b/include/linux/vmalloc.h
> @@ -106,7 +106,6 @@ extern void *vzalloc(unsigned long size);
> extern void *vmalloc_user(unsigned long size);
> extern void *vmalloc_node(unsigned long size, int node);
> extern void *vzalloc_node(unsigned long size, int node);
> -extern void *vmalloc_user_node_flags(unsigned long size, int node, gfp_t flags);
> extern void *vmalloc_exec(unsigned long size);
> extern void *vmalloc_32(unsigned long size);
> extern void *vmalloc_32_user(unsigned long size);
> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 48d98ea8fad6..249d9bd43321 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -281,26 +281,29 @@ static void *__bpf_map_area_alloc(u64 size, int numa_node, bool mmapable)
> * __GFP_RETRY_MAYFAIL to avoid such situations.
> */
>
> - const gfp_t flags = __GFP_NOWARN | __GFP_ZERO;
> + const gfp_t gfp = __GFP_NOWARN | __GFP_ZERO;
> + unsigned int flags = 0;
> + unsigned long align = 1;
> void *area;
>
> if (size >= SIZE_MAX)
> return NULL;
>
> /* kmalloc()'ed memory can't be mmap()'ed */
> - if (!mmapable && size <= (PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER)) {
> - area = kmalloc_node(size, GFP_USER | __GFP_NORETRY | flags,
> + if (mmapable) {
> + BUG_ON(!PAGE_ALIGNED(size));
> + align = SHMLBA;
> + flags = VM_USERMAP;
> + } else if (size <= (PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER)) {
> + area = kmalloc_node(size, gfp | GFP_USER | __GFP_NORETRY,
> numa_node);
> if (area != NULL)
> return area;
> }
> - if (mmapable) {
> - BUG_ON(!PAGE_ALIGNED(size));
> - return vmalloc_user_node_flags(size, numa_node, GFP_KERNEL |
> - __GFP_RETRY_MAYFAIL | flags);
> - }
> - return __vmalloc_node(size, 1, GFP_KERNEL | __GFP_RETRY_MAYFAIL | flags,
> - numa_node, __builtin_return_address(0));
> +
> + return __vmalloc_node_range(size, align, VMALLOC_START, VMALLOC_END,
> + gfp | GFP_KERNEL | __GFP_RETRY_MAYFAIL, PAGE_KERNEL,
> + flags, numa_node, __builtin_return_address(0));
> }
>
> void *bpf_map_area_alloc(u64 size, int numa_node)
> diff --git a/mm/nommu.c b/mm/nommu.c
> index 81a86cd85893..b42cd6003d7d 100644
> --- a/mm/nommu.c
> +++ b/mm/nommu.c
> @@ -150,6 +150,14 @@ void *__vmalloc(unsigned long size, gfp_t gfp_mask)
> }
> EXPORT_SYMBOL(__vmalloc);
>
> +void *__vmalloc_node_range(unsigned long size, unsigned long align,
> + unsigned long start, unsigned long end, gfp_t gfp_mask,
> + pgprot_t prot, unsigned long vm_flags, int node,
> + const void *caller)
> +{
> + return __vmalloc(size, flags);
> +}
> +
> void *__vmalloc_node(unsigned long size, unsigned long align, gfp_t gfp_mask,
> int node, const void *caller)
> {
> @@ -180,12 +188,6 @@ void *vmalloc_user(unsigned long size)
> }
> EXPORT_SYMBOL(vmalloc_user);
>
> -void *vmalloc_user_node_flags(unsigned long size, int node, gfp_t flags)
> -{
> - return __vmalloc_user_flags(size, flags | __GFP_ZERO);
> -}
> -EXPORT_SYMBOL(vmalloc_user_node_flags);
> -
> struct page *vmalloc_to_page(const void *addr)
> {
> return virt_to_page(addr);
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 333fbe77255a..f6f2acdaf70c 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -2658,26 +2658,6 @@ void *vzalloc_node(unsigned long size, int node)
> }
> EXPORT_SYMBOL(vzalloc_node);
>
> -/**
> - * vmalloc_user_node_flags - allocate memory for userspace on a specific node
> - * @size: allocation size
> - * @node: numa node
> - * @flags: flags for the page level allocator
> - *
> - * The resulting memory area is zeroed so it can be mapped to userspace
> - * without leaking data.
> - *
> - * Return: pointer to the allocated memory or %NULL on error
> - */
> -void *vmalloc_user_node_flags(unsigned long size, int node, gfp_t flags)
> -{
> - return __vmalloc_node_range(size, SHMLBA, VMALLOC_START, VMALLOC_END,
> - flags | __GFP_ZERO, PAGE_KERNEL,
> - VM_USERMAP, node,
> - __builtin_return_address(0));
> -}
> -EXPORT_SYMBOL(vmalloc_user_node_flags);
> -
> /**
> * vmalloc_exec - allocate virtually contiguous, executable memory
> * @size: allocation size
> --
> 2.25.1
>
^ permalink raw reply
* [powerpc:merge] BUILD SUCCESS a9aa21d05c33c556e48c5062b6632a9b94906570
From: kbuild test robot @ 2020-04-09 20:04 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge
branch HEAD: a9aa21d05c33c556e48c5062b6632a9b94906570 Automatic merge of branches 'master', 'next' and 'fixes' into merge
elapsed time: 578m
configs tested: 166
configs skipped: 0
The following configs have been built successfully.
More configs may be tested in the coming days.
arm allmodconfig
arm allnoconfig
arm allyesconfig
arm64 allmodconfig
arm64 allnoconfig
arm64 allyesconfig
arm at91_dt_defconfig
arm efm32_defconfig
arm exynos_defconfig
arm multi_v5_defconfig
arm multi_v7_defconfig
arm shmobile_defconfig
arm sunxi_defconfig
arm64 defconfig
sparc allyesconfig
i386 allnoconfig
riscv allnoconfig
sh titan_defconfig
h8300 h8s-sim_defconfig
m68k allmodconfig
s390 debug_defconfig
ia64 defconfig
powerpc defconfig
microblaze mmu_defconfig
sh allmodconfig
i386 alldefconfig
i386 allyesconfig
i386 debian-10.3
i386 defconfig
ia64 alldefconfig
ia64 allmodconfig
ia64 allnoconfig
ia64 allyesconfig
c6x allyesconfig
c6x evmc6678_defconfig
nios2 10m50_defconfig
nios2 3c120_defconfig
openrisc or1ksim_defconfig
openrisc simple_smp_defconfig
xtensa common_defconfig
xtensa iss_defconfig
alpha defconfig
csky defconfig
nds32 allnoconfig
nds32 defconfig
h8300 edosk2674_defconfig
h8300 h8300h-sim_defconfig
m68k m5475evb_defconfig
m68k multi_defconfig
m68k sun3_defconfig
arc defconfig
arc allyesconfig
powerpc ppc64_defconfig
powerpc rhel-kconfig
microblaze nommu_defconfig
powerpc allnoconfig
mips 32r2_defconfig
mips 64r6el_defconfig
mips allmodconfig
mips allnoconfig
mips allyesconfig
mips fuloong2e_defconfig
mips malta_kvm_defconfig
parisc allnoconfig
parisc allyesconfig
parisc generic-32bit_defconfig
parisc generic-64bit_defconfig
x86_64 randconfig-a001-20200409
x86_64 randconfig-a002-20200409
x86_64 randconfig-a003-20200409
i386 randconfig-a001-20200409
i386 randconfig-a002-20200409
i386 randconfig-a003-20200409
alpha randconfig-a001-20200409
m68k randconfig-a001-20200409
mips randconfig-a001-20200409
nds32 randconfig-a001-20200409
parisc randconfig-a001-20200409
riscv randconfig-a001-20200409
c6x randconfig-a001-20200409
h8300 randconfig-a001-20200409
microblaze randconfig-a001-20200409
nios2 randconfig-a001-20200409
sparc64 randconfig-a001-20200409
s390 randconfig-a001-20200409
xtensa randconfig-a001-20200409
csky randconfig-a001-20200409
openrisc randconfig-a001-20200409
sh randconfig-a001-20200409
x86_64 randconfig-b001-20200409
x86_64 randconfig-b002-20200409
x86_64 randconfig-b003-20200409
i386 randconfig-b001-20200409
i386 randconfig-b002-20200409
i386 randconfig-b003-20200409
x86_64 randconfig-c001-20200409
x86_64 randconfig-c002-20200409
x86_64 randconfig-c003-20200409
i386 randconfig-c001-20200409
i386 randconfig-c002-20200409
i386 randconfig-c003-20200409
x86_64 randconfig-d001-20200409
x86_64 randconfig-d002-20200409
x86_64 randconfig-d003-20200409
i386 randconfig-d001-20200409
i386 randconfig-d002-20200409
i386 randconfig-d003-20200409
x86_64 randconfig-e001-20200409
x86_64 randconfig-e002-20200409
x86_64 randconfig-e003-20200409
i386 randconfig-e001-20200409
i386 randconfig-e002-20200409
i386 randconfig-e003-20200409
x86_64 randconfig-f001-20200409
x86_64 randconfig-f002-20200409
x86_64 randconfig-f003-20200409
i386 randconfig-f001-20200409
i386 randconfig-f002-20200409
i386 randconfig-f003-20200409
x86_64 randconfig-g001-20200409
x86_64 randconfig-g002-20200409
x86_64 randconfig-g003-20200409
i386 randconfig-g001-20200409
i386 randconfig-g002-20200409
i386 randconfig-g003-20200409
x86_64 randconfig-h001-20200409
x86_64 randconfig-h002-20200409
x86_64 randconfig-h003-20200409
i386 randconfig-h001-20200409
i386 randconfig-h002-20200409
i386 randconfig-h003-20200409
sparc randconfig-a001-20200409
arm64 randconfig-a001-20200409
ia64 randconfig-a001-20200409
arc randconfig-a001-20200409
arm randconfig-a001-20200409
powerpc randconfig-a001-20200409
riscv allmodconfig
riscv allyesconfig
riscv defconfig
riscv nommu_virt_defconfig
riscv rv32_defconfig
s390 alldefconfig
s390 allmodconfig
s390 allnoconfig
s390 allyesconfig
s390 defconfig
s390 zfcpdump_defconfig
sh allnoconfig
sh rsk7269_defconfig
sh sh7785lcr_32bit_defconfig
sparc defconfig
sparc64 allmodconfig
sparc64 allnoconfig
sparc64 allyesconfig
sparc64 defconfig
um x86_64_defconfig
um i386_defconfig
um defconfig
x86_64 rhel
x86_64 rhel-7.6
x86_64 rhel-7.6-kselftests
x86_64 rhel-7.2-clear
x86_64 lkp
x86_64 fedora-25
x86_64 kexec
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.7-2 tag
From: pr-tracker-bot @ 2020-04-09 18:10 UTC (permalink / raw)
To: Michael Ellerman
Cc: geert+renesas, aik, linuxppc-dev, linux-kernel, npiggin, geoff,
anju, ganeshgr, msuchanek, Linus Torvalds, elfring, dan.carpenter
In-Reply-To: <87pncgkjdf.fsf@mpe.ellerman.id.au>
The pull request you sent on Thu, 09 Apr 2020 21:07:24 +1000:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.7-2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e4da01d8333e500e15a674d75885a9dfcfd31e77
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ 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