* Re: [Patch v4 16/22] CIFS: SMBD: Fix the definition for SMB2_CHANNEL_RDMA_V1_INVALIDATE
From: Steve French @ 2017-10-04 22:07 UTC (permalink / raw)
To: Long Li
Cc: Steve French, linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
samba-technical, LKML, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
Christoph Hellwig, Tom Talpey, Matthew Wilcox, Long Li
In-Reply-To: <20171002023030.3582-17-longli-Lp/cVzEoVyZiJJESP9tAQJZ3qXmFLfmx@public.gmane.org>
Good catch - merged into cifs-2.6.git for-next
On Sun, Oct 1, 2017 at 9:30 PM, Long Li <longli-Lp/cVzEoVyZiJJESP9tAQJZ3qXmFLfmx@public.gmane.org> wrote:
> From: Long Li <longli-0li6OtcxBFHby3iVrkZq2A@public.gmane.org>
>
> The channel value for requesting server remote invalidating local memory
> registration should be 0x00000002
>
> Signed-off-by: Long Li <longli-0li6OtcxBFHby3iVrkZq2A@public.gmane.org>
> ---
> fs/cifs/smb2pdu.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/cifs/smb2pdu.h b/fs/cifs/smb2pdu.h
> index 393ed5f..f783a08 100644
> --- a/fs/cifs/smb2pdu.h
> +++ b/fs/cifs/smb2pdu.h
> @@ -832,7 +832,7 @@ struct smb2_flush_rsp {
> /* Channel field for read and write: exactly one of following flags can be set*/
> #define SMB2_CHANNEL_NONE 0x00000000
> #define SMB2_CHANNEL_RDMA_V1 0x00000001 /* SMB3 or later */
> -#define SMB2_CHANNEL_RDMA_V1_INVALIDATE 0x00000001 /* SMB3.02 or later */
> +#define SMB2_CHANNEL_RDMA_V1_INVALIDATE 0x00000002 /* SMB3.02 or later */
>
> /* SMB2 read request without RFC1001 length at the beginning */
> struct smb2_read_plain_req {
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Thanks,
Steve
^ permalink raw reply
* + scripts-kallsyms-ignore-symbol-type-n.patch added to -mm tree
From: akpm @ 2017-10-04 22:08 UTC (permalink / raw)
To: linux, ard.biesheuvel, jpoimboe, mm-commits
The patch titled
Subject: scripts/kallsyms.c: ignore symbol type 'n'
has been added to the -mm tree. Its filename is
scripts-kallsyms-ignore-symbol-type-n.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/scripts-kallsyms-ignore-symbol-type-n.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/scripts-kallsyms-ignore-symbol-type-n.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Guenter Roeck <linux@roeck-us.net>
Subject: scripts/kallsyms.c: ignore symbol type 'n'
gcc on aarch64 may emit synbols of type 'n' if the kernel is built with
'-frecord-gcc-switches'. In most cases, those symbols are reported with
nm as
000000000000000e n $d
and with objdump as
0000000000000000 l d .GCC.command.line 0000000000000000 .GCC.command.line
000000000000000e l .GCC.command.line 0000000000000000 $d
Those symbols are detected in is_arm_mapping_symbol() and ignored.
However, if "--prefix-symbols=<prefix>" is configured as well, the
situation is different. For example, in efi/libstub, arm64 images are
built with
'--prefix-alloc-sections=.init --prefix-symbols=__efistub_'.
In combination with '-frecord-gcc-switches', the symbols are now reported
by nm as:
000000000000000e n __efistub_$d
and by objdump as:
0000000000000000 l d .GCC.command.line 0000000000000000 .GCC.command.line
000000000000000e l .GCC.command.line 0000000000000000 __efistub_$d
Those symbols are no longer ignored and included in the base address
calculation. This results in a base address of 000000000000000e, which in
turn causes kallsyms to abort with
kallsyms failure:
relative symbol value 0xffffff900800a000 out of range in relative mode
The problem is seen in little endian arm64 builds with CONFIG_EFI enabled
and with '-frecord-gcc-switches' set in KCFLAGS.
Explicitly ignore symbols of type 'n' since those are clearly debug
symbols.
Link: http://lkml.kernel.org/r/1507136063-3139-1-git-send-email-linux@roeck-us.net
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
scripts/kallsyms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN scripts/kallsyms.c~scripts-kallsyms-ignore-symbol-type-n scripts/kallsyms.c
--- a/scripts/kallsyms.c~scripts-kallsyms-ignore-symbol-type-n
+++ a/scripts/kallsyms.c
@@ -158,7 +158,7 @@ static int read_symbol(FILE *in, struct
else if (str[0] == '$')
return -1;
/* exclude debugging symbols */
- else if (stype == 'N')
+ else if (stype == 'N' || stype == 'n')
return -1;
/* include the type field in the symbol name, so that it gets
_
Patches currently in -mm which might be from linux@roeck-us.net are
scripts-kallsyms-ignore-symbol-type-n.patch
^ permalink raw reply
* Re: [Patch v4 16/22] CIFS: SMBD: Fix the definition for SMB2_CHANNEL_RDMA_V1_INVALIDATE
From: Steve French @ 2017-10-04 22:07 UTC (permalink / raw)
To: Long Li
Cc: Steve French, linux-cifs@vger.kernel.org, samba-technical, LKML,
linux-rdma, Christoph Hellwig, Tom Talpey, Matthew Wilcox,
Long Li
In-Reply-To: <20171002023030.3582-17-longli@exchange.microsoft.com>
Good catch - merged into cifs-2.6.git for-next
On Sun, Oct 1, 2017 at 9:30 PM, Long Li <longli@exchange.microsoft.com> wrote:
> From: Long Li <longli@microsoft.com>
>
> The channel value for requesting server remote invalidating local memory
> registration should be 0x00000002
>
> Signed-off-by: Long Li <longli@microsoft.com>
> ---
> fs/cifs/smb2pdu.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/cifs/smb2pdu.h b/fs/cifs/smb2pdu.h
> index 393ed5f..f783a08 100644
> --- a/fs/cifs/smb2pdu.h
> +++ b/fs/cifs/smb2pdu.h
> @@ -832,7 +832,7 @@ struct smb2_flush_rsp {
> /* Channel field for read and write: exactly one of following flags can be set*/
> #define SMB2_CHANNEL_NONE 0x00000000
> #define SMB2_CHANNEL_RDMA_V1 0x00000001 /* SMB3 or later */
> -#define SMB2_CHANNEL_RDMA_V1_INVALIDATE 0x00000001 /* SMB3.02 or later */
> +#define SMB2_CHANNEL_RDMA_V1_INVALIDATE 0x00000002 /* SMB3.02 or later */
>
> /* SMB2 read request without RFC1001 length at the beginning */
> struct smb2_read_plain_req {
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Thanks,
Steve
^ permalink raw reply
* ✗ Fi.CI.IGT: warning for lib/igt_kms: Convert properties to be more atomic-like. (rev11)
From: Patchwork @ 2017-10-04 22:08 UTC (permalink / raw)
To: Maarten Lankhorst; +Cc: intel-gfx
In-Reply-To: <20170929095937.15702-1-maarten.lankhorst@linux.intel.com>
== Series Details ==
Series: lib/igt_kms: Convert properties to be more atomic-like. (rev11)
URL : https://patchwork.freedesktop.org/series/30903/
State : warning
== Summary ==
Test kms_flip:
Subgroup plain-flip-fb-recreate-interruptible:
pass -> FAIL (shard-hsw) fdo#100368
Test gem_flink_race:
Subgroup flink_close:
fail -> PASS (shard-hsw) fdo#102655
Test perf:
Subgroup blocking:
fail -> PASS (shard-hsw) fdo#102252
Test gem_eio:
Subgroup in-flight-contexts:
dmesg-warn -> PASS (shard-hsw) fdo#102886
Test kms_addfb_basic:
Subgroup bo-too-small-due-to-tiling:
pass -> DMESG-WARN (shard-hsw)
Test kms_busy:
Subgroup extended-modeset-hang-newfb-render-C:
pass -> SKIP (shard-hsw)
fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368
fdo#102655 https://bugs.freedesktop.org/show_bug.cgi?id=102655
fdo#102252 https://bugs.freedesktop.org/show_bug.cgi?id=102252
fdo#102886 https://bugs.freedesktop.org/show_bug.cgi?id=102886
shard-hsw total:2430 pass:1330 dwarn:7 dfail:0 fail:8 skip:1085 time:10067s
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_297/shards.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH 2/2] arm64: dts: qcom: Rename SBC to DragonBoard 410c
From: Stephen Boyd @ 2017-10-04 22:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAF6AEGvtfAYx5mgg9mMVeXdO5mStD9gJvi5+Pp46jYj-e8WnOQ@mail.gmail.com>
On 10/04, Rob Clark wrote:
> On Tue, Oct 3, 2017 at 2:54 PM, Rob Clark <robdclark@gmail.com> wrote:
> > On Tue, Oct 3, 2017 at 1:49 PM, Nicolas Dechesne
> > <nicolas.dechesne@linaro.org> wrote:
> >> On Tue, Oct 3, 2017 at 6:37 PM, Rob Clark <robdclark@gmail.com> wrote:
> >>> On Tue, Oct 3, 2017 at 8:25 AM, Srinivas Kandagatla
> >>> <srinivas.kandagatla@linaro.org> wrote:
> >>>>
> >>>>
> >>>> On 03/10/17 10:11, Linus Walleij wrote:
> >>>>>
> >>>>> Naming the DragonBoard 410c "SBC" (I guess "single board computer")
> >>>>> is not very helpful for users looking for their device tree in
> >>>>> the kernel. Also the db820c is named properly.
> >>>>>
> >>>>> Rectify this, simply, do not change the compatible strings but name
> >>>>> the DTS files in a consistent manner.
> >>>>>
> >>>>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> >>>>
> >>>> I did not like the sbc naming convention too, This was primarily done due to
> >>>> some legacy build tools + bootloaders which have used sbc compatible to
> >>>> identify boards from multiple dtb blobs. Now that we can append dtb to
> >>>> kernel with new LK, this should not be a issue anymore.
> >>>
> >>> maybe it would be an idea to update skales/dbttool first to look for
> >>> the new name, and then give people some time to upgrade, before
> >>> changing this in the kernel. Otherwise I expect you'll cause some
> >>> confusion..
> >>
> >> iirc, skale is using the compatible name, not the filename.
> >>
> >
> > ahh, yes, I think you are right.. u-boot is using a different filename.
> >
> > So in this case, no issue to pick a saner name :-)
> >
>
> So, actually u-boot encodes the board's fdtname.. so as much as I'd
> like to rename it to something more sane, unless the kernel can manage
> to install a symlink for backwards compat, NAK
>
> I was trying to think of hacks for u-boot to check for multiple fdt
> names, but if we want to get to the point of being able to install
> multiple distro's on a single disk, we actually need to pass fdtname
> to grub (where distro specific grub.cfg is encoding the UUID of the
> distro's /boot partition, so it knows where to load the dtb from)..
> this gets nearly impossible when one name becomes multiple names. So
> hurray for the fdt name becoming accidental ABI!
>
> If we managed to get this in before the 4.14 LTS I might feel
> differently. But afterwards, totally not. :-(
>
How do you install dtbs onto your device? Should be simple enough
to run 'mv' on the new filename to the old one?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: Rename SBC to DragonBoard 410c
From: Stephen Boyd @ 2017-10-04 22:09 UTC (permalink / raw)
To: Rob Clark
Cc: Nicolas Dechesne, Srinivas Kandagatla, Linus Walleij,
linux-arm-kernel@lists.infradead.org, linux-arm-msm, Andy Gross,
David Brown, Bjorn Andersson, linux-soc, Alexander Graf
In-Reply-To: <CAF6AEGvtfAYx5mgg9mMVeXdO5mStD9gJvi5+Pp46jYj-e8WnOQ@mail.gmail.com>
On 10/04, Rob Clark wrote:
> On Tue, Oct 3, 2017 at 2:54 PM, Rob Clark <robdclark@gmail.com> wrote:
> > On Tue, Oct 3, 2017 at 1:49 PM, Nicolas Dechesne
> > <nicolas.dechesne@linaro.org> wrote:
> >> On Tue, Oct 3, 2017 at 6:37 PM, Rob Clark <robdclark@gmail.com> wrote:
> >>> On Tue, Oct 3, 2017 at 8:25 AM, Srinivas Kandagatla
> >>> <srinivas.kandagatla@linaro.org> wrote:
> >>>>
> >>>>
> >>>> On 03/10/17 10:11, Linus Walleij wrote:
> >>>>>
> >>>>> Naming the DragonBoard 410c "SBC" (I guess "single board computer")
> >>>>> is not very helpful for users looking for their device tree in
> >>>>> the kernel. Also the db820c is named properly.
> >>>>>
> >>>>> Rectify this, simply, do not change the compatible strings but name
> >>>>> the DTS files in a consistent manner.
> >>>>>
> >>>>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> >>>>
> >>>> I did not like the sbc naming convention too, This was primarily done due to
> >>>> some legacy build tools + bootloaders which have used sbc compatible to
> >>>> identify boards from multiple dtb blobs. Now that we can append dtb to
> >>>> kernel with new LK, this should not be a issue anymore.
> >>>
> >>> maybe it would be an idea to update skales/dbttool first to look for
> >>> the new name, and then give people some time to upgrade, before
> >>> changing this in the kernel. Otherwise I expect you'll cause some
> >>> confusion..
> >>
> >> iirc, skale is using the compatible name, not the filename.
> >>
> >
> > ahh, yes, I think you are right.. u-boot is using a different filename.
> >
> > So in this case, no issue to pick a saner name :-)
> >
>
> So, actually u-boot encodes the board's fdtname.. so as much as I'd
> like to rename it to something more sane, unless the kernel can manage
> to install a symlink for backwards compat, NAK
>
> I was trying to think of hacks for u-boot to check for multiple fdt
> names, but if we want to get to the point of being able to install
> multiple distro's on a single disk, we actually need to pass fdtname
> to grub (where distro specific grub.cfg is encoding the UUID of the
> distro's /boot partition, so it knows where to load the dtb from)..
> this gets nearly impossible when one name becomes multiple names. So
> hurray for the fdt name becoming accidental ABI!
>
> If we managed to get this in before the 4.14 LTS I might feel
> differently. But afterwards, totally not. :-(
>
How do you install dtbs onto your device? Should be simple enough
to run 'mv' on the new filename to the old one?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH 7/7] xen: Convert __page_to_mfn and __mfn_to_page to use typesafe MFN
From: Tamas K Lengyel @ 2017-10-04 22:10 UTC (permalink / raw)
To: Julien Grall
Cc: Jun Nakajima, Tim Deegan, Kevin Tian, Stefano Stabellini, Wei Liu,
Suravee Suthikulpanit, Razvan Cojocaru, Konrad Rzeszutek Wilk,
George Dunlap, Andrew Cooper, Ian Jackson, Xen-devel,
Julien Grall, Paul Durrant, Jan Beulich, Shane Wang,
Boris Ostrovsky, Gang Wei
In-Reply-To: <20171004181526.9405-8-julien.grall@linaro.org>
On Wed, Oct 4, 2017 at 12:15 PM, Julien Grall <julien.grall@linaro.org> wrote:
> Most of the users of page_to_mfn and mfn_to_page are either overriding
> the macros to make them work with mfn_t or use mfn_x/_mfn because the
> rest of the function use mfn_t.
>
> So make __page_to_mfn and __mfn_to_page return mfn_t by default.
>
> Only reasonable clean-ups are done in this patch because it is
> already quite big. So some of the files now override page_to_mfn and
> mfn_to_page to avoid using mfn_t.
>
> Signed-off-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* [PATCH] fix security_release_secctx seems broken
From: James Morris @ 2017-10-04 22:10 UTC (permalink / raw)
To: linux-security-module
In-Reply-To: <ff77bdc9-e642-113d-dbde-f4d0770fff00@yandex-team.ru>
On Wed, 4 Oct 2017, Konstantin Khlebnikov wrote:
> Just "getcap /bin/ping" is enough to tigger leak if file has capabilities.
> Selinux shouldn't be loaded because its release_secctx hook call kfree.
Ahh, makes sense.
>
> But sometimes it takes some time for kmemleak to find leak. Presumably
> because stale poiner stays on stack which could be reused nowdays.
Thanks for finding this!
--
James Morris
<jmorris@namei.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* + mm-arch-remove-empty_bad_page.patch added to -mm tree
From: akpm @ 2017-10-04 22:11 UTC (permalink / raw)
To: mhocko, dalias, dhowells, jdike, mingo, ralf, richard, ysato,
mm-commits
The patch titled
Subject: mm, arch: remove empty_bad_page*
has been added to the -mm tree. Its filename is
mm-arch-remove-empty_bad_page.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-arch-remove-empty_bad_page.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-arch-remove-empty_bad_page.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Michal Hocko <mhocko@suse.com>
Subject: mm, arch: remove empty_bad_page*
empty_bad_page() and empty_bad_pte_table() seem to be relics from old days
which is not used by any code for a long time. I have tried to find when
exactly but this is not really all that straightforward due to many code
movements - traces disappear around 2.4 times.
Anyway no code really references neither empty_bad_page nor
empty_bad_pte_table. We only allocate the storage which is not used by
anybody so remove them.
Link: http://lkml.kernel.org/r/20171004150045.30755-1-mhocko@kernel.org
Signed-off-by: Michal Hocko <mhocko@suse.com>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: David Howells <dhowells@redhat.com>
Cc: Rich Felker <dalias@libc.org>
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/frv/mm/init.c | 14 --------------
arch/h8300/mm/init.c | 13 -------------
arch/mips/include/asm/pgtable-64.h | 8 +-------
arch/mn10300/kernel/head.S | 8 --------
arch/sh/kernel/head_64.S | 8 --------
arch/um/kernel/mem.c | 3 ---
include/linux/page-flags.h | 2 +-
7 files changed, 2 insertions(+), 54 deletions(-)
diff -puN arch/frv/mm/init.c~mm-arch-remove-empty_bad_page arch/frv/mm/init.c
--- a/arch/frv/mm/init.c~mm-arch-remove-empty_bad_page
+++ a/arch/frv/mm/init.c
@@ -42,21 +42,9 @@
#undef DEBUG
/*
- * BAD_PAGE is the page that is used for page faults when linux
- * is out-of-memory. Older versions of linux just did a
- * do_exit(), but using this instead means there is less risk
- * for a process dying in kernel mode, possibly leaving a inode
- * unused etc..
- *
- * BAD_PAGETABLE is the accompanying page-table: it is initialized
- * to point to BAD_PAGE entries.
- *
* ZERO_PAGE is a special page that is used for zero-initialized
* data and COW.
*/
-static unsigned long empty_bad_page_table;
-static unsigned long empty_bad_page;
-
unsigned long empty_zero_page;
EXPORT_SYMBOL(empty_zero_page);
@@ -72,8 +60,6 @@ void __init paging_init(void)
unsigned long zones_size[MAX_NR_ZONES] = {0, };
/* allocate some pages for kernel housekeeping tasks */
- empty_bad_page_table = (unsigned long) alloc_bootmem_pages(PAGE_SIZE);
- empty_bad_page = (unsigned long) alloc_bootmem_pages(PAGE_SIZE);
empty_zero_page = (unsigned long) alloc_bootmem_pages(PAGE_SIZE);
memset((void *) empty_zero_page, 0, PAGE_SIZE);
diff -puN arch/h8300/mm/init.c~mm-arch-remove-empty_bad_page arch/h8300/mm/init.c
--- a/arch/h8300/mm/init.c~mm-arch-remove-empty_bad_page
+++ a/arch/h8300/mm/init.c
@@ -39,20 +39,9 @@
#include <asm/sections.h>
/*
- * BAD_PAGE is the page that is used for page faults when linux
- * is out-of-memory. Older versions of linux just did a
- * do_exit(), but using this instead means there is less risk
- * for a process dying in kernel mode, possibly leaving a inode
- * unused etc..
- *
- * BAD_PAGETABLE is the accompanying page-table: it is initialized
- * to point to BAD_PAGE entries.
- *
* ZERO_PAGE is a special page that is used for zero-initialized
* data and COW.
*/
-static unsigned long empty_bad_page_table;
-static unsigned long empty_bad_page;
unsigned long empty_zero_page;
/*
@@ -77,8 +66,6 @@ void __init paging_init(void)
* Initialize the bad page table and bad page to point
* to a couple of allocated pages.
*/
- empty_bad_page_table = (unsigned long)alloc_bootmem_pages(PAGE_SIZE);
- empty_bad_page = (unsigned long)alloc_bootmem_pages(PAGE_SIZE);
empty_zero_page = (unsigned long)alloc_bootmem_pages(PAGE_SIZE);
memset((void *)empty_zero_page, 0, PAGE_SIZE);
diff -puN arch/mips/include/asm/pgtable-64.h~mm-arch-remove-empty_bad_page arch/mips/include/asm/pgtable-64.h
--- a/arch/mips/include/asm/pgtable-64.h~mm-arch-remove-empty_bad_page
+++ a/arch/mips/include/asm/pgtable-64.h
@@ -31,12 +31,7 @@
* tables. Each page table is also a single 4K page, giving 512 (==
* PTRS_PER_PTE) 8 byte ptes. Each pud entry is initialized to point to
* invalid_pmd_table, each pmd entry is initialized to point to
- * invalid_pte_table, each pte is initialized to 0. When memory is low,
- * and a pmd table or a page table allocation fails, empty_bad_pmd_table
- * and empty_bad_page_table is returned back to higher layer code, so
- * that the failure is recognized later on. Linux does not seem to
- * handle these failures very well though. The empty_bad_page_table has
- * invalid pte entries in it, to force page faults.
+ * invalid_pte_table, each pte is initialized to 0.
*
* Kernel mappings: kernel mappings are held in the swapper_pg_table.
* The layout is identical to userspace except it's indexed with the
@@ -175,7 +170,6 @@
printk("%s:%d: bad pgd %016lx.\n", __FILE__, __LINE__, pgd_val(e))
extern pte_t invalid_pte_table[PTRS_PER_PTE];
-extern pte_t empty_bad_page_table[PTRS_PER_PTE];
#ifndef __PAGETABLE_PUD_FOLDED
/*
diff -puN arch/mn10300/kernel/head.S~mm-arch-remove-empty_bad_page arch/mn10300/kernel/head.S
--- a/arch/mn10300/kernel/head.S~mm-arch-remove-empty_bad_page
+++ a/arch/mn10300/kernel/head.S
@@ -434,14 +434,6 @@ ENTRY(empty_zero_page)
.space PAGE_SIZE
.balign PAGE_SIZE
-ENTRY(empty_bad_page)
- .space PAGE_SIZE
-
- .balign PAGE_SIZE
-ENTRY(empty_bad_pte_table)
- .space PAGE_SIZE
-
- .balign PAGE_SIZE
ENTRY(large_page_table)
.space PAGE_SIZE
diff -puN arch/sh/kernel/head_64.S~mm-arch-remove-empty_bad_page arch/sh/kernel/head_64.S
--- a/arch/sh/kernel/head_64.S~mm-arch-remove-empty_bad_page
+++ a/arch/sh/kernel/head_64.S
@@ -101,14 +101,6 @@ empty_zero_page:
mmu_pdtp_cache:
.space PAGE_SIZE, 0
- .global empty_bad_page
-empty_bad_page:
- .space PAGE_SIZE, 0
-
- .global empty_bad_pte_table
-empty_bad_pte_table:
- .space PAGE_SIZE, 0
-
.global fpu_in_use
fpu_in_use: .quad 0
diff -puN arch/um/kernel/mem.c~mm-arch-remove-empty_bad_page arch/um/kernel/mem.c
--- a/arch/um/kernel/mem.c~mm-arch-remove-empty_bad_page
+++ a/arch/um/kernel/mem.c
@@ -22,8 +22,6 @@
/* allocated in paging_init, zeroed in mem_init, and unchanged thereafter */
unsigned long *empty_zero_page = NULL;
EXPORT_SYMBOL(empty_zero_page);
-/* allocated in paging_init and unchanged thereafter */
-static unsigned long *empty_bad_page = NULL;
/*
* Initialized during boot, and readonly for initializing page tables
@@ -146,7 +144,6 @@ void __init paging_init(void)
int i;
empty_zero_page = (unsigned long *) alloc_bootmem_low_pages(PAGE_SIZE);
- empty_bad_page = (unsigned long *) alloc_bootmem_low_pages(PAGE_SIZE);
for (i = 0; i < ARRAY_SIZE(zones_size); i++)
zones_size[i] = 0;
diff -puN include/linux/page-flags.h~mm-arch-remove-empty_bad_page include/linux/page-flags.h
--- a/include/linux/page-flags.h~mm-arch-remove-empty_bad_page
+++ a/include/linux/page-flags.h
@@ -17,7 +17,7 @@
* Various page->flags bits:
*
* PG_reserved is set for special pages, which can never be swapped out. Some
- * of them might not even exist (eg empty_bad_page)...
+ * of them might not even exist...
*
* The PG_private bitflag is set on pagecache pages if they contain filesystem
* specific data (which is normally at page->private). It can be used by
_
Patches currently in -mm which might be from mhocko@suse.com are
mm-memory_hotplug-do-not-back-off-draining-pcp-free-pages-from-kworker-context.patch
mm-memory_hotplug-do-not-fail-offlining-too-early.patch
mm-memory_hotplug-remove-timeout-from-__offline_memory.patch
mm-hugetlb-drop-hugepages_treat_as_movable-sysctl.patch
mm-arch-remove-empty_bad_page.patch
^ permalink raw reply
* Re: [PATCH] fix security_release_secctx seems broken
From: James Morris @ 2017-10-04 22:10 UTC (permalink / raw)
To: Konstantin Khlebnikov
Cc: Casey Schaufler, linux-kernel, Serge Hallyn, James Morris,
LSM List, Stephen Smalley
In-Reply-To: <ff77bdc9-e642-113d-dbde-f4d0770fff00@yandex-team.ru>
On Wed, 4 Oct 2017, Konstantin Khlebnikov wrote:
> Just "getcap /bin/ping" is enough to tigger leak if file has capabilities.
> Selinux shouldn't be loaded because its release_secctx hook call kfree.
Ahh, makes sense.
>
> But sometimes it takes some time for kmemleak to find leak. Presumably
> because stale poiner stays on stack which could be reused nowdays.
Thanks for finding this!
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* [PATCH] Update James Hogan's email address
From: James Hogan @ 2017-10-04 22:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, James Hogan
From: James Hogan <jhogan@kernel.org>
Update my imgtec.com and personal email address to my kernel.org one in
a few places as MIPS will soon no longer be part of Imagination
Technologies, and add mappings in .mailcap so get_maintainer.pl reports
the right address.
Signed-off-by: James Hogan <jhogan@kernel.org>
---
Linus: Are you happy to apply this patch directly?
---
.mailmap | 2 ++
Documentation/ABI/testing/sysfs-power | 2 +-
MAINTAINERS | 6 +++---
drivers/i2c/busses/i2c-img-scb.c | 2 +-
drivers/media/rc/ir-sharp-decoder.c | 2 +-
5 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/.mailmap b/.mailmap
index 5273cfd70ad6..c7b10caecc4e 100644
--- a/.mailmap
+++ b/.mailmap
@@ -68,6 +68,8 @@ Jacob Shin <Jacob.Shin@amd.com>
James Bottomley <jejb@mulgrave.(none)>
James Bottomley <jejb@titanic.il.steeleye.com>
James E Wilson <wilson@specifix.com>
+James Hogan <jhogan@kernel.org> <james.hogan@imgtec.com>
+James Hogan <jhogan@kernel.org> <james@albanarts.com>
James Ketrenos <jketreno@io.(none)>
Javi Merino <javi.merino@kernel.org> <javi.merino@arm.com>
<javier@osg.samsung.com> <javier.martinez@collabora.co.uk>
diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power
index 713cab1d5f12..a1d1612f3651 100644
--- a/Documentation/ABI/testing/sysfs-power
+++ b/Documentation/ABI/testing/sysfs-power
@@ -127,7 +127,7 @@ Description:
What; /sys/power/pm_trace_dev_match
Date: October 2010
-Contact: James Hogan <james@albanarts.com>
+Contact: James Hogan <jhogan@kernel.org>
Description:
The /sys/power/pm_trace_dev_match file contains the name of the
device associated with the last PM event point saved in the RTC
diff --git a/MAINTAINERS b/MAINTAINERS
index 65b0c88d5ee0..3f05fc6961ad 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6738,7 +6738,7 @@ F: Documentation/devicetree/bindings/auxdisplay/img-ascii-lcd.txt
F: drivers/auxdisplay/img-ascii-lcd.c
IMGTEC IR DECODER DRIVER
-M: James Hogan <james.hogan@imgtec.com>
+M: James Hogan <jhogan@kernel.org>
S: Maintained
F: drivers/media/rc/img-ir/
@@ -7562,7 +7562,7 @@ F: arch/arm64/include/asm/kvm*
F: arch/arm64/kvm/
KERNEL VIRTUAL MACHINE FOR MIPS (KVM/mips)
-M: James Hogan <james.hogan@imgtec.com>
+M: James Hogan <jhogan@kernel.org>
L: linux-mips@linux-mips.org
S: Supported
F: arch/mips/include/uapi/asm/kvm*
@@ -8885,7 +8885,7 @@ F: Documentation/devicetree/bindings/media/meson-ao-cec.txt
T: git git://linuxtv.org/media_tree.git
METAG ARCHITECTURE
-M: James Hogan <james.hogan@imgtec.com>
+M: James Hogan <jhogan@kernel.org>
L: linux-metag@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/metag.git
S: Odd Fixes
diff --git a/drivers/i2c/busses/i2c-img-scb.c b/drivers/i2c/busses/i2c-img-scb.c
index 84fb35f6837f..eb1d91b986fd 100644
--- a/drivers/i2c/busses/i2c-img-scb.c
+++ b/drivers/i2c/busses/i2c-img-scb.c
@@ -1459,6 +1459,6 @@ static struct platform_driver img_scb_i2c_driver = {
};
module_platform_driver(img_scb_i2c_driver);
-MODULE_AUTHOR("James Hogan <james.hogan@imgtec.com>");
+MODULE_AUTHOR("James Hogan <jhogan@kernel.org>");
MODULE_DESCRIPTION("IMG host I2C driver");
MODULE_LICENSE("GPL v2");
diff --git a/drivers/media/rc/ir-sharp-decoder.c b/drivers/media/rc/ir-sharp-decoder.c
index ed43a4212479..129b558acc92 100644
--- a/drivers/media/rc/ir-sharp-decoder.c
+++ b/drivers/media/rc/ir-sharp-decoder.c
@@ -245,5 +245,5 @@ module_init(ir_sharp_decode_init);
module_exit(ir_sharp_decode_exit);
MODULE_LICENSE("GPL");
-MODULE_AUTHOR("James Hogan <james.hogan@imgtec.com>");
+MODULE_AUTHOR("James Hogan <jhogan@kernel.org>");
MODULE_DESCRIPTION("Sharp IR protocol decoder");
--
2.14.1
^ permalink raw reply related
* Re: [PATCH V2] Bug fix for PME interrupt handler, add Root Status check
From: Bjorn Helgaas @ 2017-10-04 22:11 UTC (permalink / raw)
To: Qiang Zheng; +Cc: linux-pci, linux-pm, gabriele.paoloni, linuxarm
In-Reply-To: <1506737526-94266-1-git-send-email-zhengqiang10@huawei.com>
On Sat, Sep 30, 2017 at 10:12:06AM +0800, Qiang Zheng wrote:
> PCIe PME and hot plug share same interrupt number. In some special case,
> Link down event cause hot plug interrupt, devices is not disconnected,
> But read config will return 0xff.
>
> In that case, PME work function will run and not return Because
> Root Status PME bit always 1 and can not be cleared.
>
> This patch add Root Status check in PME interrupt handler,
> Just do same as pciehp isr Slot status check.
>
> Signed-off-by: Qiang Zheng <zhengqiang10@huawei.com>
> ---
> drivers/pci/pcie/pme.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/pcie/pme.c b/drivers/pci/pcie/pme.c
> index fafdb16..2ff2e57 100644
> --- a/drivers/pci/pcie/pme.c
> +++ b/drivers/pci/pcie/pme.c
> @@ -273,7 +273,7 @@ static irqreturn_t pcie_pme_irq(int irq, void *context)
> spin_lock_irqsave(&data->lock, flags);
> pcie_capability_read_dword(port, PCI_EXP_RTSTA, &rtsta);
>
> - if (!(rtsta & PCI_EXP_RTSTA_PME)) {
> + if (rtsta == U32_MAX || !(rtsta & PCI_EXP_RTSTA_PME)) {
> spin_unlock_irqrestore(&data->lock, flags);
> return IRQ_NONE;
> }
>
I applied the patch below to pci/misc for v4.15.
I think we need a similar test in pcie_pme_work_fn() itself. Without
it, I think there's a race: if we get a legitimate PME, enter
pcie_pme_work_fn(), and the link goes down, we could still get
0xffffffff the next time we read PCI_EXP_RTSTA.
I also used "(u32) ~0" instead of U32_MAX because that's the style
used elsewhere. It might be clunkier than necessary, but U32_MAX
suggests a limit, and that's not really the concept here.
I didn't add your reviewed-by, Rafael, since I made non-trivial
changes to the patch.
Bjorn
commit 303029d6d55ba10a37c82c31a89eb5550cde77ec
Author: Qiang <zhengqiang10@huawei.com>
Date: Thu Sep 28 11:54:34 2017 +0800
PCI/PME: Handle invalid data when reading Root Status
PCIe PME and native hotplug share the same interrupt number, so hotplug
interrupts are also processed by PME. In some cases, e.g., a Link Down
interrupt, a device may be present but unreachable, so when we try to
read its Root Status register, the read fails and we get all ones data
(0xffffffff).
Previously, we interpreted that data as PCI_EXP_RTSTA_PME being set, i.e.,
"some device has asserted PME," so we scheduled pcie_pme_work_fn(). This
caused an infinite loop because pcie_pme_work_fn() tried to handle PME
requests until PCI_EXP_RTSTA_PME is cleared, but with the link down,
PCI_EXP_RTSTA_PME can't be cleared.
Check for the invalid 0xffffffff data everywhere we read the Root Status
register.
1469d17dd341 ("PCI: pciehp: Handle invalid data when reading from
non-existent devices") added similar checks in the hotplug driver.
Signed-off-by: Qiang Zheng <zhengqiang10@huawei.com>
[bhelgaas: changelog, also check in pcie_pme_work_fn(), use "~0" to follow
other similar checks]
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
diff --git a/drivers/pci/pcie/pme.c b/drivers/pci/pcie/pme.c
index fafdb165dd2e..df290aa58dce 100644
--- a/drivers/pci/pcie/pme.c
+++ b/drivers/pci/pcie/pme.c
@@ -226,6 +226,9 @@ static void pcie_pme_work_fn(struct work_struct *work)
break;
pcie_capability_read_dword(port, PCI_EXP_RTSTA, &rtsta);
+ if (rtsta == (u32) ~0)
+ break;
+
if (rtsta & PCI_EXP_RTSTA_PME) {
/*
* Clear PME status of the port. If there are other
@@ -273,7 +276,7 @@ static irqreturn_t pcie_pme_irq(int irq, void *context)
spin_lock_irqsave(&data->lock, flags);
pcie_capability_read_dword(port, PCI_EXP_RTSTA, &rtsta);
- if (!(rtsta & PCI_EXP_RTSTA_PME)) {
+ if (rtsta == (u32) ~0 || !(rtsta & PCI_EXP_RTSTA_PME)) {
spin_unlock_irqrestore(&data->lock, flags);
return IRQ_NONE;
}
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: qcom: Rename SBC to DragonBoard 410c
From: Rob Clark @ 2017-10-04 22:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171004220923.GB457@codeaurora.org>
On Wed, Oct 4, 2017 at 6:09 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 10/04, Rob Clark wrote:
>> On Tue, Oct 3, 2017 at 2:54 PM, Rob Clark <robdclark@gmail.com> wrote:
>> > On Tue, Oct 3, 2017 at 1:49 PM, Nicolas Dechesne
>> > <nicolas.dechesne@linaro.org> wrote:
>> >> On Tue, Oct 3, 2017 at 6:37 PM, Rob Clark <robdclark@gmail.com> wrote:
>> >>> On Tue, Oct 3, 2017 at 8:25 AM, Srinivas Kandagatla
>> >>> <srinivas.kandagatla@linaro.org> wrote:
>> >>>>
>> >>>>
>> >>>> On 03/10/17 10:11, Linus Walleij wrote:
>> >>>>>
>> >>>>> Naming the DragonBoard 410c "SBC" (I guess "single board computer")
>> >>>>> is not very helpful for users looking for their device tree in
>> >>>>> the kernel. Also the db820c is named properly.
>> >>>>>
>> >>>>> Rectify this, simply, do not change the compatible strings but name
>> >>>>> the DTS files in a consistent manner.
>> >>>>>
>> >>>>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>> >>>>
>> >>>> I did not like the sbc naming convention too, This was primarily done due to
>> >>>> some legacy build tools + bootloaders which have used sbc compatible to
>> >>>> identify boards from multiple dtb blobs. Now that we can append dtb to
>> >>>> kernel with new LK, this should not be a issue anymore.
>> >>>
>> >>> maybe it would be an idea to update skales/dbttool first to look for
>> >>> the new name, and then give people some time to upgrade, before
>> >>> changing this in the kernel. Otherwise I expect you'll cause some
>> >>> confusion..
>> >>
>> >> iirc, skale is using the compatible name, not the filename.
>> >>
>> >
>> > ahh, yes, I think you are right.. u-boot is using a different filename.
>> >
>> > So in this case, no issue to pick a saner name :-)
>> >
>>
>> So, actually u-boot encodes the board's fdtname.. so as much as I'd
>> like to rename it to something more sane, unless the kernel can manage
>> to install a symlink for backwards compat, NAK
>>
>> I was trying to think of hacks for u-boot to check for multiple fdt
>> names, but if we want to get to the point of being able to install
>> multiple distro's on a single disk, we actually need to pass fdtname
>> to grub (where distro specific grub.cfg is encoding the UUID of the
>> distro's /boot partition, so it knows where to load the dtb from)..
>> this gets nearly impossible when one name becomes multiple names. So
>> hurray for the fdt name becoming accidental ABI!
>>
>> If we managed to get this in before the 4.14 LTS I might feel
>> differently. But afterwards, totally not. :-(
>>
>
> How do you install dtbs onto your device? Should be simple enough
> to run 'mv' on the new filename to the old one?
>
it is part of the kernel package.. but fixing it in the distro means
fixing it in *every* distro..
if we are going for a workaround, then it should be the kernel
installing a symlink. Not every distro having to fix things up in the
same way for one particular board.
BR,
-R
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: Rename SBC to DragonBoard 410c
From: Rob Clark @ 2017-10-04 22:12 UTC (permalink / raw)
To: Stephen Boyd
Cc: Nicolas Dechesne, Srinivas Kandagatla, Linus Walleij,
linux-arm-kernel@lists.infradead.org, linux-arm-msm, Andy Gross,
David Brown, Bjorn Andersson, linux-soc, Alexander Graf
In-Reply-To: <20171004220923.GB457@codeaurora.org>
On Wed, Oct 4, 2017 at 6:09 PM, Stephen Boyd <sboyd@codeaurora.org> wrote:
> On 10/04, Rob Clark wrote:
>> On Tue, Oct 3, 2017 at 2:54 PM, Rob Clark <robdclark@gmail.com> wrote:
>> > On Tue, Oct 3, 2017 at 1:49 PM, Nicolas Dechesne
>> > <nicolas.dechesne@linaro.org> wrote:
>> >> On Tue, Oct 3, 2017 at 6:37 PM, Rob Clark <robdclark@gmail.com> wrote:
>> >>> On Tue, Oct 3, 2017 at 8:25 AM, Srinivas Kandagatla
>> >>> <srinivas.kandagatla@linaro.org> wrote:
>> >>>>
>> >>>>
>> >>>> On 03/10/17 10:11, Linus Walleij wrote:
>> >>>>>
>> >>>>> Naming the DragonBoard 410c "SBC" (I guess "single board computer")
>> >>>>> is not very helpful for users looking for their device tree in
>> >>>>> the kernel. Also the db820c is named properly.
>> >>>>>
>> >>>>> Rectify this, simply, do not change the compatible strings but name
>> >>>>> the DTS files in a consistent manner.
>> >>>>>
>> >>>>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>> >>>>
>> >>>> I did not like the sbc naming convention too, This was primarily done due to
>> >>>> some legacy build tools + bootloaders which have used sbc compatible to
>> >>>> identify boards from multiple dtb blobs. Now that we can append dtb to
>> >>>> kernel with new LK, this should not be a issue anymore.
>> >>>
>> >>> maybe it would be an idea to update skales/dbttool first to look for
>> >>> the new name, and then give people some time to upgrade, before
>> >>> changing this in the kernel. Otherwise I expect you'll cause some
>> >>> confusion..
>> >>
>> >> iirc, skale is using the compatible name, not the filename.
>> >>
>> >
>> > ahh, yes, I think you are right.. u-boot is using a different filename.
>> >
>> > So in this case, no issue to pick a saner name :-)
>> >
>>
>> So, actually u-boot encodes the board's fdtname.. so as much as I'd
>> like to rename it to something more sane, unless the kernel can manage
>> to install a symlink for backwards compat, NAK
>>
>> I was trying to think of hacks for u-boot to check for multiple fdt
>> names, but if we want to get to the point of being able to install
>> multiple distro's on a single disk, we actually need to pass fdtname
>> to grub (where distro specific grub.cfg is encoding the UUID of the
>> distro's /boot partition, so it knows where to load the dtb from)..
>> this gets nearly impossible when one name becomes multiple names. So
>> hurray for the fdt name becoming accidental ABI!
>>
>> If we managed to get this in before the 4.14 LTS I might feel
>> differently. But afterwards, totally not. :-(
>>
>
> How do you install dtbs onto your device? Should be simple enough
> to run 'mv' on the new filename to the old one?
>
it is part of the kernel package.. but fixing it in the distro means
fixing it in *every* distro..
if we are going for a workaround, then it should be the kernel
installing a symlink. Not every distro having to fix things up in the
same way for one particular board.
BR,
-R
^ permalink raw reply
* + mm-account-pud-page-tables-fix.patch added to -mm tree
From: akpm @ 2017-10-04 22:14 UTC (permalink / raw)
To: kirill.shutemov, mhocko, riel, vbabka, mm-commits
The patch titled
Subject: mm-account-pud-page-tables-fix
has been added to the -mm tree. Its filename is
mm-account-pud-page-tables-fix.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-account-pud-page-tables-fix.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-account-pud-page-tables-fix.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Subject: mm-account-pud-page-tables-fix
s/pmd_t/pud_t/
Link: http://lkml.kernel.org/r/20171004074305.x35eh5u7ybbt5kar@black.fi.intel.com
Cc: Rik van Riel <riel@redhat.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/proc/task_mmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN fs/proc/task_mmu.c~mm-account-pud-page-tables-fix fs/proc/task_mmu.c
--- a/fs/proc/task_mmu.c~mm-account-pud-page-tables-fix
+++ a/fs/proc/task_mmu.c
@@ -51,7 +51,7 @@ void task_mem(struct seq_file *m, struct
swap = get_mm_counter(mm, MM_SWAPENTS);
ptes = PTRS_PER_PTE * sizeof(pte_t) * atomic_long_read(&mm->nr_ptes);
pmds = PTRS_PER_PMD * sizeof(pmd_t) * mm_nr_pmds(mm);
- puds = PTRS_PER_PUD * sizeof(pmd_t) * mm_nr_puds(mm);
+ puds = PTRS_PER_PUD * sizeof(pud_t) * mm_nr_puds(mm);
seq_printf(m,
"VmPeak:\t%8lu kB\n"
"VmSize:\t%8lu kB\n"
_
Patches currently in -mm which might be from kirill.shutemov@linux.intel.com are
mm-account-pud-page-tables.patch
mm-account-pud-page-tables-fix.patch
mm-add-infrastructure-for-get_user_pages_fast-benchmarking.patch
^ permalink raw reply
* Re: [PATCH v4 rdma-next 17/18] IB/core: Define 'ib' and 'roce' rdma_ah_attr types
From: Don Hiatt @ 2017-10-04 22:15 UTC (permalink / raw)
To: Parav Pandit, Dasaratharaman Chandramouli, Doug Ledford; +Cc: linux-rdma
In-Reply-To: <VI1PR0502MB30083D21E466C23698A93228D1730-o1MPJYiShExKsLr+rGaxW8DSnupUy6xnnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
On 10/4/2017 2:24 PM, Parav Pandit wrote:
>> -----Original Message-----
>> From: linux-rdma-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org [mailto:linux-rdma-
>> owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org] On Behalf Of Dasaratharaman Chandramouli
>> Sent: Saturday, April 29, 2017 1:41 PM
>> To: Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> Cc: linux-rdma <linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
>> Subject: [PATCH v4 rdma-next 17/18] IB/core: Define 'ib' and 'roce'
>> rdma_ah_attr types
>> +/*Get AH type */
>> +static inline enum rdma_ah_attr_type rdma_ah_find_type(struct ib_device
>> *dev,
>> + u32 port_num)
>> +{
>> + if ((rdma_protocol_roce(dev, port_num)) ||
>> + (rdma_protocol_iwarp(dev, port_num)))
>> + return RDMA_AH_ATTR_TYPE_ROCE;
> Check for iWarp to define AH attribute type as RoCE appears error to me.
> Taking quick look at i40iw and nes drivers appears to return -ENOSYS for i40iw_create_ah(), nes_create_ah.
> Will you please submit a fix that avoids above iWarp check?
>
>
i40iw_port_immutable sets the RDMA_CORE_PORT_IWARP immutable flag, hence
the check. Are you having an issue?
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [lockdep] b09be676e0 BUG: unable to handle kernel NULL pointer dereference at 000001f2
From: Josh Poimboeuf @ 2017-10-04 22:15 UTC (permalink / raw)
To: lkp
In-Reply-To: <CA+55aFy9r2GAFenswm92sdz0qnbazPcofm668JqYrxEVFALfZA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4815 bytes --]
On Wed, Oct 04, 2017 at 02:30:42PM -0700, Linus Torvalds wrote:
> On Wed, Oct 4, 2017 at 2:06 PM, Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> >
> > I compiled the same kernel with a similar version of GCC. It turns out
> > that GCC *does* create unaligned stacks with frame pointers enabled:
>
> Christ. What a piece of crap.
>
> It doesn't even seem to make any sense. Spill room for the "u16
> item_count" and "u8 move_type"?
I didn't have the patience to try to figure out what it thought it was
trying to do. But it doesn't even use %esp in the function, so it's
obviously just pointless code. Pasting the full function below.
> That function is disgusting anyway (the switch really should be
> outside the loop, not inside it), but whatever. No excuse for that
> kind of garbage code generation.
>
> > This was a leaf function. For no apparent reason, GCC 4.8 decided to
> > subtract 3 from the stack pointer in the prologue.
>
> Can you make objtool warn about unaligned stack pointer additions like that?
That should be easy to add, and a good idea to check for. I don't look
forward to the continual 0-day bot complaints, so hopefully we can
figure out a way to fix them (or deprecate GCC 4!), or at least disable
the checking for older versions of GCC with the known issue.
> Maybe it only happens in very limited cases, and we can find a pattern
> to why gcc generates garbage code like that? And perhaps even how to
> just avoid it?
Just from grepping the objdump I can tell it happened in several
different functions. For example all the following functions have 'sub
$0x1,%esp':
match_wildcard()
pci_vpd_find_tag()
strspn()
sub $0x2,%esp:
rgb_foreground()
scsi_extd_sense_format()
sub $0x5,%esp:
iot2040_rs485_config()
sub $0x6,%esp:
x86_match_cpu()
clear_buffer_attributes()
The only thing I can see they have in common is that they're leaf
functions. In all cases the stack pointer is otherwise unused.
The problem seemed to go away when I built the same kernel with GCC 5.3.
FYI, here's the full function (4.14-rc3 compiled with RHEL GCC 4.8.3-9).
Config is attached.
c124a388 <acpi_rs_move_data>:
c124a388: 55 push %ebp
c124a389: 89 e5 mov %esp,%ebp
c124a38b: 57 push %edi
c124a38c: 56 push %esi
c124a38d: 89 d6 mov %edx,%esi
c124a38f: 53 push %ebx
c124a390: 31 db xor %ebx,%ebx
c124a392: 83 ec 03 sub $0x3,%esp
c124a395: 8a 55 08 mov 0x8(%ebp),%dl
c124a398: 66 89 4d f2 mov %cx,-0xe(%ebp)
c124a39c: 83 ea 15 sub $0x15,%edx
c124a39f: 88 55 f1 mov %dl,-0xf(%ebp)
c124a3a2: 0f b6 fa movzbl %dl,%edi
c124a3a5: 0f b7 4d f2 movzwl -0xe(%ebp),%ecx
c124a3a9: 39 cb cmp %ecx,%ebx
c124a3ab: 73 36 jae c124a3e3 <acpi_rs_move_data+0x5b>
c124a3ad: 80 7d f1 07 cmpb $0x7,-0xf(%ebp)
c124a3b1: 77 30 ja c124a3e3 <acpi_rs_move_data+0x5b>
c124a3b3: ff 24 bd cc e9 36 c1 jmp *-0x3ec91634(,%edi,4)
c124a3b6: R_386_32 .rodata
c124a3ba: 89 c7 mov %eax,%edi
c124a3bc: f3 a4 rep movsb %ds:(%esi),%es:(%edi)
c124a3be: eb 23 jmp c124a3e3 <acpi_rs_move_data+0x5b>
c124a3c0: 66 8b 0c 5e mov (%esi,%ebx,2),%cx
c124a3c4: 66 89 0c 58 mov %cx,(%eax,%ebx,2)
c124a3c8: eb 16 jmp c124a3e0 <acpi_rs_move_data+0x58>
c124a3ca: 8b 0c 9e mov (%esi,%ebx,4),%ecx
c124a3cd: 89 0c 98 mov %ecx,(%eax,%ebx,4)
c124a3d0: eb 0e jmp c124a3e0 <acpi_rs_move_data+0x58>
c124a3d2: 8b 14 de mov (%esi,%ebx,8),%edx
c124a3d5: 8b 4c de 04 mov 0x4(%esi,%ebx,8),%ecx
c124a3d9: 89 14 d8 mov %edx,(%eax,%ebx,8)
c124a3dc: 89 4c d8 04 mov %ecx,0x4(%eax,%ebx,8)
c124a3e0: 43 inc %ebx
c124a3e1: eb c2 jmp c124a3a5 <acpi_rs_move_data+0x1d>
c124a3e3: 83 c4 03 add $0x3,%esp
c124a3e6: 5b pop %ebx
c124a3e7: 5e pop %esi
c124a3e8: 5f pop %edi
c124a3e9: 5d pop %ebp
c124a3ea: c3 ret
[-- Attachment #2: config.gz --]
[-- Type: application/x-gunzip, Size: 15847 bytes --]
^ permalink raw reply
* Re: [lockdep] b09be676e0 BUG: unable to handle kernel NULL pointer dereference at 000001f2
From: Josh Poimboeuf @ 2017-10-04 22:15 UTC (permalink / raw)
To: Linus Torvalds
Cc: Tetsuo Handa, Wu Fengguang, Byungchul Park, Ingo Molnar,
Peter Zijlstra, Linux Kernel Mailing List, LKP, Borislav Petkov,
the arch/x86 maintainers, Peter Anvin, Thomas Gleixner
In-Reply-To: <CA+55aFy9r2GAFenswm92sdz0qnbazPcofm668JqYrxEVFALfZA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4710 bytes --]
On Wed, Oct 04, 2017 at 02:30:42PM -0700, Linus Torvalds wrote:
> On Wed, Oct 4, 2017 at 2:06 PM, Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> >
> > I compiled the same kernel with a similar version of GCC. It turns out
> > that GCC *does* create unaligned stacks with frame pointers enabled:
>
> Christ. What a piece of crap.
>
> It doesn't even seem to make any sense. Spill room for the "u16
> item_count" and "u8 move_type"?
I didn't have the patience to try to figure out what it thought it was
trying to do. But it doesn't even use %esp in the function, so it's
obviously just pointless code. Pasting the full function below.
> That function is disgusting anyway (the switch really should be
> outside the loop, not inside it), but whatever. No excuse for that
> kind of garbage code generation.
>
> > This was a leaf function. For no apparent reason, GCC 4.8 decided to
> > subtract 3 from the stack pointer in the prologue.
>
> Can you make objtool warn about unaligned stack pointer additions like that?
That should be easy to add, and a good idea to check for. I don't look
forward to the continual 0-day bot complaints, so hopefully we can
figure out a way to fix them (or deprecate GCC 4!), or at least disable
the checking for older versions of GCC with the known issue.
> Maybe it only happens in very limited cases, and we can find a pattern
> to why gcc generates garbage code like that? And perhaps even how to
> just avoid it?
Just from grepping the objdump I can tell it happened in several
different functions. For example all the following functions have 'sub
$0x1,%esp':
match_wildcard()
pci_vpd_find_tag()
strspn()
sub $0x2,%esp:
rgb_foreground()
scsi_extd_sense_format()
sub $0x5,%esp:
iot2040_rs485_config()
sub $0x6,%esp:
x86_match_cpu()
clear_buffer_attributes()
The only thing I can see they have in common is that they're leaf
functions. In all cases the stack pointer is otherwise unused.
The problem seemed to go away when I built the same kernel with GCC 5.3.
FYI, here's the full function (4.14-rc3 compiled with RHEL GCC 4.8.3-9).
Config is attached.
c124a388 <acpi_rs_move_data>:
c124a388: 55 push %ebp
c124a389: 89 e5 mov %esp,%ebp
c124a38b: 57 push %edi
c124a38c: 56 push %esi
c124a38d: 89 d6 mov %edx,%esi
c124a38f: 53 push %ebx
c124a390: 31 db xor %ebx,%ebx
c124a392: 83 ec 03 sub $0x3,%esp
c124a395: 8a 55 08 mov 0x8(%ebp),%dl
c124a398: 66 89 4d f2 mov %cx,-0xe(%ebp)
c124a39c: 83 ea 15 sub $0x15,%edx
c124a39f: 88 55 f1 mov %dl,-0xf(%ebp)
c124a3a2: 0f b6 fa movzbl %dl,%edi
c124a3a5: 0f b7 4d f2 movzwl -0xe(%ebp),%ecx
c124a3a9: 39 cb cmp %ecx,%ebx
c124a3ab: 73 36 jae c124a3e3 <acpi_rs_move_data+0x5b>
c124a3ad: 80 7d f1 07 cmpb $0x7,-0xf(%ebp)
c124a3b1: 77 30 ja c124a3e3 <acpi_rs_move_data+0x5b>
c124a3b3: ff 24 bd cc e9 36 c1 jmp *-0x3ec91634(,%edi,4)
c124a3b6: R_386_32 .rodata
c124a3ba: 89 c7 mov %eax,%edi
c124a3bc: f3 a4 rep movsb %ds:(%esi),%es:(%edi)
c124a3be: eb 23 jmp c124a3e3 <acpi_rs_move_data+0x5b>
c124a3c0: 66 8b 0c 5e mov (%esi,%ebx,2),%cx
c124a3c4: 66 89 0c 58 mov %cx,(%eax,%ebx,2)
c124a3c8: eb 16 jmp c124a3e0 <acpi_rs_move_data+0x58>
c124a3ca: 8b 0c 9e mov (%esi,%ebx,4),%ecx
c124a3cd: 89 0c 98 mov %ecx,(%eax,%ebx,4)
c124a3d0: eb 0e jmp c124a3e0 <acpi_rs_move_data+0x58>
c124a3d2: 8b 14 de mov (%esi,%ebx,8),%edx
c124a3d5: 8b 4c de 04 mov 0x4(%esi,%ebx,8),%ecx
c124a3d9: 89 14 d8 mov %edx,(%eax,%ebx,8)
c124a3dc: 89 4c d8 04 mov %ecx,0x4(%eax,%ebx,8)
c124a3e0: 43 inc %ebx
c124a3e1: eb c2 jmp c124a3a5 <acpi_rs_move_data+0x1d>
c124a3e3: 83 c4 03 add $0x3,%esp
c124a3e6: 5b pop %ebx
c124a3e7: 5e pop %esi
c124a3e8: 5f pop %edi
c124a3e9: 5d pop %ebp
c124a3ea: c3 ret
[-- Attachment #2: .config.gz --]
[-- Type: application/x-gunzip, Size: 15847 bytes --]
^ permalink raw reply
* Re: [PATCH 11/25] xfs: scrub the AGI
From: Dave Chinner @ 2017-10-04 22:16 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: linux-xfs
In-Reply-To: <20171004180204.GU6503@magnolia>
On Wed, Oct 04, 2017 at 11:02:04AM -0700, Darrick J. Wong wrote:
> On Wed, Oct 04, 2017 at 05:43:33PM +1100, Dave Chinner wrote:
> > It seems to me that we're using the superblock 0 values as the
> > golden master because it's a mounted filesystem, and then comparing
> > everything else against it. Maybe we should at least check a couple
> > of secondary superblocks to see that they match the primary
> > superblock - that way we'll have some confidence that at least
> > things like agcount, agblocks, dblocks, etc are valid before we go
> > any further...
>
> xfs_scrub_superblock does check the secondary superblock geometry
> against whatever's in mp->m_sb, which came from sb 0.
/me smacks forehead
The patch is even named "scrub the backup superblocks".
Perhaps it didn't sink in because they are normally called
"secondary superblocks". My bad....
> > BUt maybe all we need is comment in the overall scrub description -
> > that we're pretty much assuming that sb 0 is intact because we write
> > what is in memory back to it and so we can simply validate
> > everything else against the primary superblock contents...
>
> Correct. Since scrub is run against a mounted live filesystem we assume
> that the mount code fully validated sb 0 and therefore we can rely on it
> not being wrong.
>
> If OTOH sb 0 *is* wrong then the admin is better off running xfs_repair
> because there's too much whirring machinery to go changing fundamental
> geometry.
Yup, that makes sense.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply
* Re: [PATCH 07/13] drm/i915/cnl: DVFS for PLL enabling
From: Manasi Navare @ 2017-10-04 22:22 UTC (permalink / raw)
To: Rodrigo Vivi; +Cc: intel-gfx, Paulo Zanoni, Kahola
In-Reply-To: <20171003070614.18396-8-rodrigo.vivi@intel.com>
On Tue, Oct 03, 2017 at 12:06:08AM -0700, Rodrigo Vivi wrote:
> From: "Kahola, Mika" <mika.kahola@intel.com>
>
> Display Voltage and Frequency Switching (DVFS) is used to adjust the
> display voltage to match the display clock frequencies. If voltage is
> set too low, it will break functionality. If voltage is set too high,
> it will waste power. Voltage level is selected based on CD clock and
> DDI clock.
>
> The sequence before frequency change is the following and it requests
> the power controller to raise voltage to maximum
>
> - Ensure any previous GT Driver Mailbox transaction is complete.
> - Write GT Driver Mailbox Data Low = 0x3.
> - Write GT Driver Mailbox Data High = 0x0.
> - Write GT Driver Mailbox Interface = 0x80000007.
> - Poll GT Driver Mailbox Interface for Run/Busy indication cleared (bit 31 = 0).
> - Read GT Driver Mailbox Data Low, if bit 0 is 0x1, continue, else restart the sequence.
> Timeout after 3ms
>
> The sequence after frequency change is the following and it requests
> the port controller to raise voltage to the requested level.
>
> - Write GT Driver Mailbox Data Low
> * For level 0, write 0x0
> * For level 1, write 0x1
> * For level 2, write 0x2
> * For level 3, write 0x3
> - Write GT Driver Mailbox Data High = 0x0.
> - Write GT Driver Mailbox Interface = 0x80000007.
>
> For Cannonlake, the level 3 is not used and it aliases to level 2.
>
> v2: reuse Paulo's work on cdclk. This patch depends on Paulo's patch
> [PATCH 02/12] drm/i915/cnl: extract cnl_dvfs_{pre,post}_change
> v3: (By Rodrigo): Remove duplicated commend and fix typo on Paulo's name.
> v4: (By Rodrigo): Rebase on top "Unify and export gen9+ port_clock calculation"
> The port clock calculation here was only addressing DP, so let's reuse
> the current port calculation that is already in place without any duplication.
> Alos fix portclk <= 594000 instead of portclk < 594000.
>
> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Kahola, Mika <mika.kahola@intel.com>
> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Looks good, dowble checked with the voltage levels from the spec.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
> ---
> drivers/gpu/drm/i915/intel_dpll_mgr.c | 30 ++++++++++++++++++++++--------
> 1 file changed, 22 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index a2a3d93d67bd..6030fbafa580 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -1966,10 +1966,23 @@ static const struct intel_dpll_mgr bxt_pll_mgr = {
> .dump_hw_state = bxt_dump_hw_state,
> };
>
> +static int cnl_get_dvfs_level(int cdclk, int portclk)
> +{
> + if (cdclk == 168000 && portclk <= 594000)
> + return 0;
> + else if (cdclk == 336000 && portclk <= 594000)
> + return 1;
> + else
> + return 2;
> +}
> +
> static void cnl_ddi_pll_enable(struct drm_i915_private *dev_priv,
> struct intel_shared_dpll *pll)
> {
> uint32_t val;
> + int ret;
> + int level;
> + int cdclk, portclk;
>
> /* 1. Enable DPLL power in DPLL_ENABLE. */
> val = I915_READ(CNL_DPLL_ENABLE(pll->id));
> @@ -2006,11 +2019,9 @@ static void cnl_ddi_pll_enable(struct drm_i915_private *dev_priv,
> /*
> * 5. If the frequency will result in a change to the voltage
> * requirement, follow the Display Voltage Frequency Switching
> - * Sequence Before Frequency Change
> - *
> - * FIXME: (DVFS) is used to adjust the display voltage to match the
> - * display clock frequencies
> + * (DVFS) Sequence Before Frequency Change
> */
> + ret = cnl_dvfs_pre_change(dev_priv);
>
> /* 6. Enable DPLL in DPLL_ENABLE. */
> val = I915_READ(CNL_DPLL_ENABLE(pll->id));
> @@ -2028,11 +2039,14 @@ static void cnl_ddi_pll_enable(struct drm_i915_private *dev_priv,
> /*
> * 8. If the frequency will result in a change to the voltage
> * requirement, follow the Display Voltage Frequency Switching
> - * Sequence After Frequency Change
> - *
> - * FIXME: (DVFS) is used to adjust the display voltage to match the
> - * display clock frequencies
> + * (DVFS) Sequence After Frequency Change
> */
> + if (ret == 0) {
> + cdclk = dev_priv->cdclk.hw.cdclk;
> + portclk = intel_ddi_port_clock(dev_priv, pll->id);
> + level = cnl_get_dvfs_level(cdclk, portclk);
> + cnl_dvfs_post_change(dev_priv, level);
> + }
>
> /*
> * 9. turn on the clock for the DDI and map the DPLL to the DDI
> --
> 2.13.5
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* + cma-take-__gfp_nowarn-into-account-in-cma_alloc.patch added to -mm tree
From: akpm @ 2017-10-04 22:18 UTC (permalink / raw)
To: boris.brezillon, airlied, daniel, eric, iamjoonsoo.kim,
jaewon31.kim, labbott, mm-commits
The patch titled
Subject: mm/cma.c: take __GFP_NOWARN into account in cma_alloc()
has been added to the -mm tree. Its filename is
cma-take-__gfp_nowarn-into-account-in-cma_alloc.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/cma-take-__gfp_nowarn-into-account-in-cma_alloc.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/cma-take-__gfp_nowarn-into-account-in-cma_alloc.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Boris Brezillon <boris.brezillon@free-electrons.com>
Subject: mm/cma.c: take __GFP_NOWARN into account in cma_alloc()
cma_alloc() unconditionally prints an INFO message when the CMA allocation
fails. Make this message conditional on the non-presence of __GFP_NOWARN
in gfp_mask.
This patch aims at removing INFO messages that are displayed when the VC4
driver tries to allocate buffer objects. From the driver perspective an
allocation failure is acceptable, and the driver can possibly do something
to make following allocation succeed (like flushing the VC4 internal
cache).
Link: http://lkml.kernel.org/r/20171004125447.15195-1-boris.brezillon@free-electrons.com
Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Acked-by: Laura Abbott <labbott@redhat.com>
Cc: Jaewon Kim <jaewon31.kim@samsung.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Eric Anholt <eric@anholt.net>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
mm/cma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN mm/cma.c~cma-take-__gfp_nowarn-into-account-in-cma_alloc mm/cma.c
--- a/mm/cma.c~cma-take-__gfp_nowarn-into-account-in-cma_alloc
+++ a/mm/cma.c
@@ -460,7 +460,7 @@ struct page *cma_alloc(struct cma *cma,
trace_cma_alloc(pfn, page, count, align);
- if (ret) {
+ if (ret && !(gfp_mask & __GFP_NOWARN)) {
pr_info("%s: alloc failed, req-size: %zu pages, ret: %d\n",
__func__, count, ret);
cma_debug_show_areas(cma);
_
Patches currently in -mm which might be from boris.brezillon@free-electrons.com are
cma-take-__gfp_nowarn-into-account-in-cma_alloc.patch
^ permalink raw reply
* Re: [PATCH 08/13] drm/i915/cnl: DVFS for PLL disabling
From: Manasi Navare @ 2017-10-04 22:23 UTC (permalink / raw)
To: Rodrigo Vivi; +Cc: intel-gfx, Paulo Zanoni, Kahola
In-Reply-To: <20171003070614.18396-9-rodrigo.vivi@intel.com>
On Tue, Oct 03, 2017 at 12:06:09AM -0700, Rodrigo Vivi wrote:
> From: "Kahola, Mika" <mika.kahola@intel.com>
>
> Display Voltage and Frequency Switching (DVFS) is used to adjust the
> display voltage to match the display clock frequencies. To save power the
> voltage is set to minimum when disabling PLL.
>
> The sequence before frequency change is the following and it requests
> the power controller to raise voltage to maximum
>
> - Ensure any previous GT Driver Mailbox transaction is complete.
> - Write GT Driver Mailbox Data Low = 0x3.
> - Write GT Driver Mailbox Data High = 0x0.
> - Write GT Driver Mailbox Interface = 0x80000007.
> - Poll GT Driver Mailbox Interface for Run/Busy indication cleared (bit 31 = 0).
> - Read GT Driver Mailbox Data Low, if bit 0 is 0x1, continue, else restart the sequence.
> Timeout after 3ms
>
> The sequence after frequency change is the following and it requests
> the port controller to lower voltage to the minimum.
>
> - Write GT Driver Mailbox Data Low = 0x0
> - Write GT Driver Mailbox Data High = 0x0.
> - Write GT Driver Mailbox Interface = 0x80000007.
>
> v2: reuse Paulo's work on cdclk. This patch depends on Paulo's patch
> [PATCH 02/12] drm/i915/cnl: extract cnl_dvfs_{pre,post}_change
> v3: (By Rodrigo): Fix typo on Paulo's name.
>
> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Kahola, Mika <mika.kahola@intel.com>
> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Manasi
> ---
> drivers/gpu/drm/i915/intel_dpll_mgr.c | 14 ++++++--------
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 6030fbafa580..a71a6c396bbd 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -2058,6 +2058,7 @@ static void cnl_ddi_pll_disable(struct drm_i915_private *dev_priv,
> struct intel_shared_dpll *pll)
> {
> uint32_t val;
> + int ret;
>
> /*
> * 1. Configure DPCLKA_CFGCR0 to turn off the clock for the DDI.
> @@ -2067,11 +2068,9 @@ static void cnl_ddi_pll_disable(struct drm_i915_private *dev_priv,
> /*
> * 2. If the frequency will result in a change to the voltage
> * requirement, follow the Display Voltage Frequency Switching
> - * Sequence Before Frequency Change
> - *
> - * FIXME: (DVFS) is used to adjust the display voltage to match the
> - * display clock frequencies
> + * (DVFS) Sequence Before Frequency Change
> */
> + ret = cnl_dvfs_pre_change(dev_priv);
>
> /* 3. Disable DPLL through DPLL_ENABLE. */
> val = I915_READ(CNL_DPLL_ENABLE(pll->id));
> @@ -2089,11 +2088,10 @@ static void cnl_ddi_pll_disable(struct drm_i915_private *dev_priv,
> /*
> * 5. If the frequency will result in a change to the voltage
> * requirement, follow the Display Voltage Frequency Switching
> - * Sequence After Frequency Change
> - *
> - * FIXME: (DVFS) is used to adjust the display voltage to match the
> - * display clock frequencies
> + * (DVFS) Sequence After Frequency Change
> */
> + if (ret == 0)
> + cnl_dvfs_post_change(dev_priv, 0);
>
> /* 6. Disable DPLL power in DPLL_ENABLE. */
> val = I915_READ(CNL_DPLL_ENABLE(pll->id));
> --
> 2.13.5
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: Seeking Help on Corruption Issues
From: Hugo Mills @ 2017-10-04 22:19 UTC (permalink / raw)
To: Stephen Nesbitt; +Cc: Stephen Nesbitt, linux-btrfs
In-Reply-To: <e531fc75-8080-eb82-86bb-2f787bf0ea43@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2913 bytes --]
On Tue, Oct 03, 2017 at 03:49:25PM -0700, Stephen Nesbitt wrote:
>
> On 10/3/2017 2:11 PM, Hugo Mills wrote:
> > Hi, Stephen,
> >
> >On Tue, Oct 03, 2017 at 08:52:04PM +0000, Stephen Nesbitt wrote:
> >>Here it i. There are a couple of out-of-order entries beginning at 117. And
> >>yes I did uncover a bad stick of RAM:
> >>
> >>btrfs-progs v4.9.1
> >>leaf 2589782867968 items 134 free space 6753 generation 3351574 owner 2
> >>fs uuid 24b768c3-2141-44bf-ae93-1c3833c8c8e3
> >>chunk uuid 19ce12f0-d271-46b8-a691-e0d26c1790c6
> >[snip]
> >>item 116 key (1623012749312 EXTENT_ITEM 45056) itemoff 10908 itemsize 53
> >>extent refs 1 gen 3346444 flags DATA
> >>extent data backref root 271 objectid 24999978 offset 0 count 1
> >>item 117 key (1621939052544 EXTENT_ITEM 8192) itemoff 10855 itemsize 53
> >>extent refs 1 gen 3346495 flags DATA
> >>extent data backref root 271 objectid 21751764 offset 6733824 count 1
> >>item 118 key (1623012450304 EXTENT_ITEM 8192) itemoff 10802 itemsize 53
> >>extent refs 1 gen 3351513 flags DATA
> >>extent data backref root 271 objectid 5724364 offset 680640512 count 1
> >>item 119 key (1623012802560 EXTENT_ITEM 12288) itemoff 10749 itemsize 53
> >>extent refs 1 gen 3346376 flags DATA
> >>extent data backref root 271 objectid 21751764 offset 6701056 count 1
> >>>>hex(1623012749312)
> >'0x179e3193000'
> >>>>hex(1621939052544)
> >'0x179a319e000'
> >>>>hex(1623012450304)
> >'0x179e314a000'
> >>>>hex(1623012802560)
> >'0x179e31a0000'
> >
> > That's "e" -> "a" in the fourth hex digit, which is a single-bit
> >flip, and should be fixable by btrfs check (I think). However, even
> >fixing that, it's not ordered, because 118 is then before 117, which
> >could be another bitflip ("9" -> "4" in the 7th digit), but two bad
> >bits that close to each other seems unlikely to me.
> >
> > Hugo.
>
> Hope this is a duplicate reply - I might have fat fingered something.
>
> The underlying file is disposable/replaceable. Any way to zero
> out/zap the bad BTRFS entry?
Not really. Even trying to delete the related file(s), it's going
to fall over when reading the metadata in in the first place. (The key
order check is a metadata invariant, like the csum checks and transid
checks).
At best, you'd have to get btrfs check to fix it. It should be able
to manage a single-bit error, but you've got two single-bit errors in
close proximity, and I'm not sure it'll be able to deal with it. Might
be worth trying it. The FS _might_ blow up as a result of an attempted
fix, but you say it's replacable, so that's kind of OK. The worst I'd
_expect_ to happen with btrfs check --repair is that it just won't be
able to deal with it and you're left where you started.
Go for it.
Hugo.
--
Hugo Mills | You shouldn't anthropomorphise computers. They
hugo@... carfax.org.uk | really don't like that.
http://carfax.org.uk/ |
PGP: E2AB1DE4 |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v1 2/5] netduino2: Specify the valid CPUs
From: Philippe Mathieu-Daudé @ 2017-10-04 22:21 UTC (permalink / raw)
To: Alistair Francis, Igor Mammedov
Cc: qemu-devel@nongnu.org Developers, Eduardo Habkost,
Marcel Apfelbaum
In-Reply-To: <CAKmqyKPMJn92F1c+K8Wy_Ka6us0p1ver_0YQUcRdyr-TRoW_ew@mail.gmail.com>
>>> +const char *netduino_valid_cpus[] = { ARM_CPU_TYPE_NAME("cortex-m3"),
>> style nit, ^^^ put entries on new line with typical 4 space alignment
>
> Do you mean like this?
>
> const char *netduino_valid_cpus[] = {
> ARM_CPU_TYPE_NAME("cortex-m3"),
> ARM_CPU_TYPE_NAME("cortex-m4"),
> NULL };
I suppose he meant:
static const char *netduino_valid_cpus[] = {
ARM_CPU_TYPE_NAME("cortex-m3"),
ARM_CPU_TYPE_NAME("cortex-m4"),
NULL
};
^ permalink raw reply
* + mm-readahead-increase-maximum-readahead-window.patch added to -mm tree
From: akpm @ 2017-10-04 22:21 UTC (permalink / raw)
To: jack, darrick.wong, david, torvalds, mm-commits
The patch titled
Subject: mm: readahead: increase maximum readahead window
has been added to the -mm tree. Its filename is
mm-readahead-increase-maximum-readahead-window.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-readahead-increase-maximum-readahead-window.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-readahead-increase-maximum-readahead-window.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Jan Kara <jack@suse.cz>
Subject: mm: readahead: increase maximum readahead window
Increase default maximum allowed readahead window from 128 KB to 512 KB.
This improves performance for some workloads (see below for details) where
ability to scale readahead window to larger sizes allows for better total
throughput while chances for regression are rather low given readahead
window size is dynamically computed based on observation (and thus it
never grows large for workloads with a random read pattern).
Note that the same tuning can be done using udev rules or by manually
setting the sysctl parameter however we believe the new value is a better
default most users will want to use. As a data point we carry this patch
in SUSE kernels for over 8 years.
Some data from the last evaluation of this patch (on 4.4-based kernel, I
can rerun those tests on a newer kernel but nothing has changed in the
readahead area since 4.4). The patch was evaluated on two machines o a
UMA machine, 8 cores and rotary storage o A NUMA machine, 4 socket, 48
cores and SSD storage
Five basic tests were conducted;
1. paralleldd-single
paralleldd uses different instances of dd to access a single file and
write the contents to /dev/null. The performance of it depends on how
well readahead works for a single file. It's mostly sequential IO.
2. paralleldd-multi
Similar to test 1 except each instance of dd accesses a different file
so each instance of dd is accessing data sequentially but the timing
makes it look like random read IO.
3. pgbench-small
A standard init of pgbench and execution with a small data set
4. pgbench-large
A standard init of pgbench and execution with a large data set
5. bonnie++ with dataset sizes 2X RAM and in asyncronous mode
UMA paralleldd-single on ext3
4.4.0 4.4.0
vanilla readahead-v1r1
Amean Elapsd-1 5.42 ( 0.00%) 5.40 ( 0.50%)
Amean Elapsd-3 7.51 ( 0.00%) 5.54 ( 26.25%)
Amean Elapsd-5 7.15 ( 0.00%) 5.90 ( 17.46%)
Amean Elapsd-7 5.81 ( 0.00%) 5.61 ( 3.42%)
Amean Elapsd-8 6.05 ( 0.00%) 5.73 ( 5.36%)
Results speak for themselves, readahead is a major boost when there
are multiple readers of data. It's not displayed but system CPU
usage is overall. The IO stats support the results
4.4.0 4.4.0
vanillareadahead-v1r1
Mean sda-avgqusz 7.44 8.59
Mean sda-avgrqsz 279.77 722.52
Mean sda-await 31.95 48.82
Mean sda-r_await 3.32 11.58
Mean sda-w_await 127.51 119.60
Mean sda-svctm 1.47 3.46
Mean sda-rrqm 27.82 23.52
Mean sda-wrqm 4.52 5.00
It shows that the average request size is 2.5 times larger even
though the merging stats are similar. It's also interesting to
note that average wait times are higher but more IO is being
initiated per dd instance.
It's interesting to note that this is specific to ext3 and that xfs showed
a small regression with larger readahead.
UMA paralleldd-single on xfs
4.4.0 4.4.0
vanilla readahead-v1r1
Min Elapsd-1 6.91 ( 0.00%) 7.10 ( -2.75%)
Min Elapsd-3 6.77 ( 0.00%) 6.93 ( -2.36%)
Min Elapsd-5 6.82 ( 0.00%) 7.00 ( -2.64%)
Min Elapsd-7 6.84 ( 0.00%) 7.05 ( -3.07%)
Min Elapsd-8 7.02 ( 0.00%) 7.04 ( -0.28%)
Amean Elapsd-1 7.08 ( 0.00%) 7.20 ( -1.68%)
Amean Elapsd-3 7.03 ( 0.00%) 7.12 ( -1.40%)
Amean Elapsd-5 7.22 ( 0.00%) 7.38 ( -2.34%)
Amean Elapsd-7 7.07 ( 0.00%) 7.19 ( -1.75%)
Amean Elapsd-8 7.23 ( 0.00%) 7.23 ( -0.10%)
The IO stats are not displayed but show a similar ratio to ext3 and system
CPU usage is also lower. Hence, this slowdown is unexplained but may be
due to differences in XFS in the read path and how it locks even though
direct IO is not a factor. Tracing was not enabled to see what flags are
passed into xfs_ilock to see if the IO is all behind one lock but it's one
potential explanation.
UMA paralleldd-single on ext3
This showed nothing interesting as the test was too short-lived to draw
any conclusions. There was some difference in the kernels but it was
within the noise. The same applies for XFS.
UMA pgbench-small on ext3
This showed very little that was interesting. The database load time was
slower but by a very small margin. The actual transaction times were
highly variable and inconclusive.
NUMA pgbench-small on ext3
Load times are not reported but they completed 1.5% faster.
4.4.0 4.4.0
vanilla readahead-v1r1
Hmean 1 3000.54 ( 0.00%) 2895.28 ( -3.51%)
Hmean 8 20596.33 ( 0.00%) 19291.92 ( -6.33%)
Hmean 12 30760.68 ( 0.00%) 30019.58 ( -2.41%)
Hmean 24 74383.22 ( 0.00%) 73580.80 ( -1.08%)
Hmean 32 88377.30 ( 0.00%) 88928.70 ( 0.62%)
Hmean 48 88133.53 ( 0.00%) 96099.16 ( 9.04%)
Hmean 80 55981.37 ( 0.00%) 76886.10 ( 37.34%)
Hmean 112 74060.29 ( 0.00%) 87632.95 ( 18.33%)
Hmean 144 51331.50 ( 0.00%) 66135.77 ( 28.84%)
Hmean 172 44256.92 ( 0.00%) 63521.73 ( 43.53%)
Hmean 192 35942.74 ( 0.00%) 71121.35 ( 97.87%)
The impact here is substantial particularly for higher thread-counts.
It's interesting to note that there is an apparent regression for low
thread counts. In general, there was a high degree of variability but the
gains were all outside of the noise. In general, the io stats did not
show any particular pattern about request size as the workload is mostly
resident in memory. The real curiousity is that readahead should have had
little or no impact here as the data is mostly resident in memory.
Observing the transactions over time, there was a lot of variability and
the performance is likely dominated by whether the data happened to be
local or not. In itself, this test does not push for inclusion of the
patch due to the lack of IO but is included for completeness.
UMA pgbench-small on xfs
Similar observations to ext3 on the load times. The transaction times
were stable but showed no significant performance difference.
UMA pgbench-large on ext3
Database load times were slightly faster (3.36%). The transaction times
were slower on average, more variable but still very close to the noise.
UMA pgbench-large on xfs
No significant difference on either database load times or transactions.
UMA bonnie on ext3
4.4.0 4.4.0
vanilla readahead-v1r1
Hmean SeqOut Char 81079.98 ( 0.00%) 81172.05 ( 0.11%)
Hmean SeqOut Block 104416.12 ( 0.00%) 104116.24 ( -0.29%)
Hmean SeqOut Rewrite 44153.34 ( 0.00%) 44596.23 ( 1.00%)
Hmean SeqIn Char 88144.56 ( 0.00%) 91702.67 ( 4.04%)
Hmean SeqIn Block 134581.06 ( 0.00%) 137245.71 ( 1.98%)
Hmean Random seeks 258.46 ( 0.00%) 280.82 ( 8.65%)
Hmean SeqCreate ops 2.25 ( 0.00%) 2.25 ( 0.00%)
Hmean SeqCreate read 2.25 ( 0.00%) 2.25 ( 0.00%)
Hmean SeqCreate del 911.29 ( 0.00%) 880.24 ( -3.41%)
Hmean RandCreate ops 2.25 ( 0.00%) 2.25 ( 0.00%)
Hmean RandCreate read 2.00 ( 0.00%) 2.25 ( 12.50%)
Hmean RandCreate del 911.89 ( 0.00%) 878.80 ( -3.63%)
The difference in headline performance figures is marginal and well within noise.
The system CPU usage tells a slightly different story
4.4.0 4.4.0
vanillareadahead-v1r1
User 1817.53 1798.89
System 499.40 420.65
Elapsed 10692.67 10588.08
As do the IO stats
4.4.0 4.4.0
vanillareadahead-v1r1
Mean sda-avgqusz 1079.16 1083.35
Mean sda-avgrqsz 807.95 1225.08
Mean sda-await 7308.06 9647.13
Mean sda-r_await 119.04 133.27
Mean sda-w_await 19106.20 20255.41
Mean sda-svctm 4.67 7.02
Mean sda-rrqm 1.80 0.99
Mean sda-wrqm 5597.12 5723.32
NUMA bonnie on ext3
bonnie
4.4.0 4.4.0
vanilla readahead-v1r1
Hmean SeqOut Char 58660.72 ( 0.00%) 58930.39 ( 0.46%)
Hmean SeqOut Block 253950.92 ( 0.00%) 261466.37 ( 2.96%)
Hmean SeqOut Rewrite 151960.60 ( 0.00%) 161300.48 ( 6.15%)
Hmean SeqIn Char 57015.41 ( 0.00%) 55699.16 ( -2.31%)
Hmean SeqIn Block 600448.14 ( 0.00%) 627565.09 ( 4.52%)
Hmean Random seeks 0.00 ( 0.00%) 0.00 ( 0.00%)
Hmean SeqCreate ops 1.00 ( 0.00%) 1.00 ( 0.00%)
Hmean SeqCreate read 3.00 ( 0.00%) 3.00 ( 0.00%)
Hmean SeqCreate del 90.91 ( 0.00%) 79.88 (-12.14%)
Hmean RandCreate ops 1.00 ( 0.00%) 1.50 ( 50.00%)
Hmean RandCreate read 3.00 ( 0.00%) 3.00 ( 0.00%)
Hmean RandCreate del 92.95 ( 0.00%) 93.97 ( 1.10%)
The impact is small but in line with the UMA machine in a number of
details. As before, the CPU usage is lower even if the iostats show very
little differences overall.
Overall, the headline performance figures are mostly improved or show
little difference. There is a small anomaly with XFS that indicates it
may not always win there due to other factors. There is also the
possibility that a mostly random read workload that was larger than memory
with each read spanning multiple pages but less than the max readahead
window would suffer but the probability is low as the readahead window
should scale properly. On balance, this is a win -- particularly on the
large read workloads.
Link: http://lkml.kernel.org/r/20171004091205.468-1-jack@suse.cz
Signed-off-by: Jan Kara <jack@suse.cz>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
include/linux/mm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN include/linux/mm.h~mm-readahead-increase-maximum-readahead-window include/linux/mm.h
--- a/include/linux/mm.h~mm-readahead-increase-maximum-readahead-window
+++ a/include/linux/mm.h
@@ -2248,7 +2248,7 @@ int __must_check write_one_page(struct p
void task_dirty_inc(struct task_struct *tsk);
/* readahead.c */
-#define VM_MAX_READAHEAD 128 /* kbytes */
+#define VM_MAX_READAHEAD 512 /* kbytes */
#define VM_MIN_READAHEAD 16 /* kbytes (includes current page) */
int force_page_cache_readahead(struct address_space *mapping, struct file *filp,
_
Patches currently in -mm which might be from jack@suse.cz are
mm-readahead-increase-maximum-readahead-window.patch
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.