[PATCH v13 0/9] namei: openat2(2) path resolution restrictions

This patchset is being developed here: It depends on the copy_struct_from_user() helpers being developed here: and posted here:

[PATCH v13 4/9] namei: O_BENEATH-style path resolution flags

Add the following flags to allow various restrictions on path resolution (these affect the *entire* resolution, rather than just the final path component -- as is the case with LOOKUP_FOLLOW). The primary justification for these flags is to allow for programs to be far more strict about how they

[PATCH v13 7/9] open: openat2(2) syscall

The most obvious syscall to add support for the new LOOKUP_* scoping flags would be openat(2). However, there are a few reasons why this is not the best course of action: * The new LOOKUP_* flags are intended to be security features, and openat(2) will silently ignore all unknown flags. This

[PATCH v13 6/9] namei: permit ".." resolution with LOOKUP_{IN_ROOT,BENEATH}

This patch allows for LOOKUP_BENEATH and LOOKUP_IN_ROOT to safely permit ".." resolution (in the case of LOOKUP_BENEATH the resolution will still fail if ".." resolution would resolve a path outside of the root -- while LOOKUP_IN_ROOT will chroot(2)-style scope it). Magic-link jumps are still

[PATCH v13 9/9] Documentation: update path-lookup to mention trailing magic-links

We've introduced new (somewhat subtle) behaviour regarding trailing magic-links, so it's best to make sure everyone can follow along with the reasoning behind trailing_magiclink(). Signed-off-by: Aleksa Sarai --- Documentation/filesystems/path-lookup.rst | 80 ++- 1 file

Re: [PATCH v13 7/9] open: openat2(2) syscall

Hi Aleksa, Thank you for the patch! Yet something to improve: [auto build test ERROR on linus/master] [cannot apply to v5.4-rc1 next-20190930] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system. BTW, we also suggest to use '--base' option to specify

Darlehen

Grüße dich. Willkommen bei Frau Christabel als Teil ihres Wohlfahrtspaketes Anbieten eines Floating Loans mit 2% Zinssatz ohne jegliche Sicherheiten Sicherheit. Dies soll Einzelpersonen und Unternehmen helfen, ihre Finanzen zu erreichen Ziele. * Persönlicher Kredit (ungesichert) *

[PATCH RESEND v3 01/26] PCI: Add define for the number of standard PCI BARs

Code that iterates over all standard PCI BARs typically uses PCI_STD_RESOURCE_END. However, it requires the "unusual" loop condition "i <= PCI_STD_RESOURCE_END" rather than something more standard like "i < PCI_STD_NUM_BARS". This patch adds the definition PCI_STD_NUM_BARS which is equivalent to

[PATCH RESEND v3 00/26] Add definition for the number of standard PCI BARs

Code that iterates over all standard PCI BARs typically uses PCI_STD_RESOURCE_END, but this is error-prone because it requires "i <= PCI_STD_RESOURCE_END" rather than something like "i < PCI_STD_NUM_BARS". We could add such a definition and use it the same way PCI_SRIOV_NUM_BARS is used. The

[PATCH 23/29] parisc: Move EXCEPTION_TABLE to RO_DATA segment

The EXCEPTION_TABLE is read-only, so collapse it into RO_DATA. Signed-off-by: Kees Cook --- arch/parisc/kernel/vmlinux.lds.S | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/arch/parisc/kernel/vmlinux.lds.S b/arch/parisc/kernel/vmlinux.lds.S index

[PATCH 21/29] ia64: Move EXCEPTION_TABLE to RO_DATA segment

The EXCEPTION_TABLE is read-only, so collapse it into RO_DATA. Signed-off-by: Kees Cook --- arch/ia64/kernel/vmlinux.lds.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/ia64/kernel/vmlinux.lds.S b/arch/ia64/kernel/vmlinux.lds.S index 0d86fc8e88d5..18a732597112 100644

[PATCH 11/29] vmlinux.lds.h: Replace RODATA with RO_DATA

There's no reason to keep the RODATA macro: just replace the callers with the expected RO_DATA macro. Signed-off-by: Kees Cook --- arch/alpha/kernel/vmlinux.lds.S | 2 +- arch/ia64/kernel/vmlinux.lds.S | 2 +- arch/microblaze/kernel/vmlinux.lds.S | 2 +-

[PATCH 15/29] x86: Actually use _etext for end of text segment

Various calculations are using the end of the exception table (which does not need to be executable) as the end of the text segment. Instead, in preparation for moving the exception table into RO_DATA, move _etext after the exception table and update the calculations. Signed-off-by: Kees Cook

[PATCH 22/29] microblaze: Move EXCEPTION_TABLE to RO_DATA segment

The EXCEPTION_TABLE is read-only, so collapse it into RO_DATA. Signed-off-by: Kees Cook --- arch/microblaze/kernel/vmlinux.lds.S | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/microblaze/kernel/vmlinux.lds.S b/arch/microblaze/kernel/vmlinux.lds.S index

[PATCH 16/29] x86: Move EXCEPTION_TABLE to RO_DATA segment

The exception table was needlessly marked executable. In preparation for execute-only memory, this moves the table into the RO_DATA segment via a new macro that can be used by any architectures that want to make a similar consolidation. Signed-off-by: Kees Cook --- arch/x86/kernel/vmlinux.lds.S

[PATCH 03/29] powerpc: Rename PT_LOAD identifier "kernel" to "text"

In preparation for moving NOTES into RO_DATA, this renames the linker script internal identifier for the PT_LOAD Program Header from "kernel" to "text" to match other architectures. Signed-off-by: Kees Cook --- arch/powerpc/kernel/vmlinux.lds.S | 12 ++-- 1 file changed, 6

[PATCH 00/29] vmlinux.lds.h: Refactor EXCEPTION_TABLE and NOTES

This series works to move the linker sections for NOTES and EXCEPTION_TABLE into the RO_DATA area, where they belong on most (all?) architectures. The problem being addressed was the discovery by Rick Edgecombe that the exception table was accidentally marked executable while he was developing his

[PATCH 12/29] vmlinux.lds.h: Replace RO_DATA_SECTION with RO_DATA

This finishes renaming RO_DATA_SECTION to RO_DATA. (Calling this a "section" is a lie, since it's multiple sections and section flags cannot be applied to the macro.) Signed-off-by: Kees Cook --- arch/arc/kernel/vmlinux.lds.S | 2 +- arch/c6x/kernel/vmlinux.lds.S | 2 +-

[PATCH 07/29] x86: Restore "text" Program Header with dummy section

Instead of depending on markings in the section following NOTES to restore the associated Program Header, use a dummy section, as done in other architectures. This is preparation for moving NOTES into the RO_DATA macro. Signed-off-by: Kees Cook --- arch/x86/kernel/vmlinux.lds.S | 3 ++- 1 file

[PATCH 10/29] vmlinux.lds.h: Move NOTES into RO_DATA

The .notes section should be non-executable read-only data. As such, it can live in the RO_DATA macro instead of being per-architecture defined. Signed-off-by: Kees Cook --- arch/alpha/kernel/vmlinux.lds.S | 2 -- arch/arc/kernel/vmlinux.lds.S| 2 --

[PATCH 18/29] arm64: Move EXCEPTION_TABLE to RO_DATA segment

The EXCEPTION_TABLE is read-only, so collapse it into RO_DATA. Signed-off-by: Kees Cook --- arch/arm64/kernel/vmlinux.lds.S | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S index

[PATCH 09/29] vmlinux.lds.h: Move Program Header restoration into NOTES macro

In preparation for moving NOTES into RO_DATA, the Program Header assignment restoration needs to be part of the NOTES macro itself. Signed-off-by: Kees Cook --- arch/alpha/kernel/vmlinux.lds.S | 5 + arch/ia64/kernel/vmlinux.lds.S| 4 +--- arch/mips/kernel/vmlinux.lds.S| 3 +--

[PATCH 25/29] xtensa: Move EXCEPTION_TABLE to RO_DATA segment

The EXCEPTION_TABLE is read-only, so collapse it into RO_DATA. Signed-off-by: Kees Cook --- arch/xtensa/kernel/vmlinux.lds.S | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/xtensa/kernel/vmlinux.lds.S b/arch/xtensa/kernel/vmlinux.lds.S index bdbd7c4056c1..7341964722ae

[PATCH 29/29] x86: Use INT3 instead of NOP for linker fill bytes

Instead of using 0x90 (NOP) to fill bytes between functions, which makes it easier to sloppily target functions in function pointer overwrite attacks, fill with 0xCC (INT3) to force a trap. Also drops the space between "=" and the value to better match the binutils documentation

[PATCH 17/29] alpha: Move EXCEPTION_TABLE to RO_DATA segment

The EXCEPTION_TABLE is read-only, so collapse it into RO_DATA. Signed-off-by: Kees Cook --- arch/alpha/kernel/vmlinux.lds.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/alpha/kernel/vmlinux.lds.S b/arch/alpha/kernel/vmlinux.lds.S index edc45f45523b..72303827bcb4

[PATCH 14/29] vmlinux.lds.h: Allow EXCEPTION_TABLE to live in RO_DATA

Many architectures have an EXCEPTION_TABLE that needs only to be read-only. As such, it should live in RO_DATA. This creates a macro to identify this case for the architectures that can move EXCEPTION_TABLE into RO_DATA. Signed-off-by: Kees Cook --- include/asm-generic/vmlinux.lds.h | 12

[PATCH 08/29] vmlinux.lds.h: Provide EMIT_PT_NOTE to indicate export of .notes

In preparation for moving NOTES into RO_DATA, this provides a mechanism for architectures that want to emit a PT_NOTE Program Header to do so. Signed-off-by: Kees Cook --- arch/alpha/kernel/vmlinux.lds.S | 3 +++ arch/ia64/kernel/vmlinux.lds.S| 2 ++ arch/mips/kernel/vmlinux.lds.S|

[PATCH 19/29] c6x: Move EXCEPTION_TABLE to RO_DATA segment

The EXCEPTION_TABLE is read-only, so collapse it into RO_DATA. Signed-off-by: Kees Cook --- arch/c6x/kernel/vmlinux.lds.S | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/arch/c6x/kernel/vmlinux.lds.S b/arch/c6x/kernel/vmlinux.lds.S index a3547f9d415b..9a09aab63ab3

[PATCH 24/29] powerpc: Move EXCEPTION_TABLE to RO_DATA segment

The EXCEPTION_TABLE is read-only, so collapse it into RO_DATA. Signed-off-by: Kees Cook --- arch/powerpc/kernel/vmlinux.lds.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S index

[PATCH 01/29] powerpc: Rename "notes" PT_NOTE to "note"

The Program Header identifiers are internal to the linker scripts. In preparation for moving the NOTES segment declaration into RO_DATA, standardize the identifier for the PT_NOTE entry to "note" as used by all other architectures that emit PT_NOTE. Signed-off-by: Kees Cook ---

[PATCH 26/29] x86/mm: Remove redundant on addresses

The on addresses are redundant and are better removed to match all the other similar functions. Signed-off-by: Kees Cook --- arch/x86/mm/init_64.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c index

[PATCH 04/29] alpha: Rename PT_LOAD identifier "kernel" to "text"

In preparation for moving NOTES into RO_DATA, this renames the linker script internal identifier for the PT_LOAD Program Header from "kernel" to "text" to match other architectures. Signed-off-by: Kees Cook --- arch/alpha/kernel/vmlinux.lds.S | 8 1 file changed, 4 insertions(+), 4

[PATCH 28/29] x86/mm: Report actual image regions in /proc/iomem

The resource reservations in made for the kernel image did not reflect the gaps between text, rodata, and data. This adds the rodata resource and updates the start/end calculations to match the respective calls to free_kernel_image_pages(). Before (booted with "nokaslr" for easier comparison):

[PATCH 27/29] x86/mm: Report which part of kernel image is freed

The memory freeing report wasn't very useful for figuring out which parts of the kernel image were being freed. This adds the details for clearer reporting. Before: [2.150450] Freeing unused kernel image memory: 1348K [2.154574] Write protecting the kernel read-only data: 20480k [

[PATCH 13/29] vmlinux.lds.h: Replace RW_DATA_SECTION with RW_DATA

This renames RW_DATA_SECTION to RW_DATA. (Calling this a "section" is a lie, since it's multiple sections and section flags cannot be applied to the macro.) Signed-off-by: Kees Cook --- arch/alpha/kernel/vmlinux.lds.S | 2 +- arch/arc/kernel/vmlinux.lds.S| 2 +-

[PATCH 20/29] h8300: Move EXCEPTION_TABLE to RO_DATA segment

The EXCEPTION_TABLE is read-only, so collapse it into RO_DATA. Signed-off-by: Kees Cook --- arch/h8300/kernel/vmlinux.lds.S | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/h8300/kernel/vmlinux.lds.S b/arch/h8300/kernel/vmlinux.lds.S index 2ac7bdcd2fe0..aba90398b774

[PATCH 05/29] ia64: Rename PT_LOAD identifier "code" to "text"

In preparation for moving NOTES into RO_DATA, this renames the linker script internal identifier for the PT_LOAD Program Header from "code" to "text" to match other architectures. Signed-off-by: Kees Cook --- arch/ia64/kernel/vmlinux.lds.S | 14 +++--- 1 file changed, 7 insertions(+), 7

[PATCH 06/29] s390: Move RO_DATA into "text" PT_LOAD Program Header

In preparation for moving NOTES into RO_DATA, this moves RO_DATA back into the "text" PT_LOAD Program Header, as done with other architectures. The "data" PT_LOAD now starts with the writable data section. Signed-off-by: Kees Cook --- arch/s390/kernel/vmlinux.lds.S | 4 ++-- 1 file changed, 2

[PATCH 02/29] powerpc: Remove PT_NOTE workaround

The kernel requires gcc 4.6 now, so this PT_NOTE workaround can be removed in preparation for moving NOTES into RO_DATA. Signed-off-by: Kees Cook --- arch/powerpc/kernel/vmlinux.lds.S | 24 ++-- 1 file changed, 2 insertions(+), 22 deletions(-) diff --git

Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On Thu, Sep 26, 2019 at 11:05:59AM +0200, Peter Zijlstra wrote: > On Wed, Sep 25, 2019 at 11:45:26PM +0200, Peter Zijlstra wrote: > > [7.149889] [Firmware Bug]: device: 'pci:7f': no node assigned on > > NUMA capable HW > > [7.882888] [Firmware Bug]: device: 'pci:ff': no node

Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On Wed, Sep 25, 2019 at 11:45:26PM +0200, Peter Zijlstra wrote: > [7.149889] [Firmware Bug]: device: 'pci:7f': no node assigned on NUMA > capable HW > [7.882888] [Firmware Bug]: device: 'pci:ff': no node assigned on NUMA > capable HW Going by the limited number of intel numa

Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On Wed, Sep 25, 2019 at 06:31:54PM +0200, Peter Zijlstra wrote: > On Wed, Sep 25, 2019 at 03:25:44PM +0200, Michal Hocko wrote: > > I am sorry but I still do not understand why you consider this whack a > > mole better then simply live with the fact that NUMA_NO_NODE is a > > reality and that

Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On Wed 25-09-19 12:40:40, Peter Zijlstra wrote: > On Tue, Sep 24, 2019 at 03:19:39PM +0200, Michal Hocko wrote: > > > > The below would get rid of the PMU and workqueue warnings with no > > > side-effects (the device isn't used for anything except sysfs). > > > > Hardcoding to 0 is simply wrong,

Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On Wed, Sep 25, 2019 at 05:14:20PM +0800, Yunsheng Lin wrote: > From the discussion above, It seems making the node_to_cpumask_map() > NUMA_NO_NODE aware is the most feasible way to move forwad. That's still wrong.

Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On Tue, Sep 24, 2019 at 03:19:39PM +0200, Michal Hocko wrote: > > The below would get rid of the PMU and workqueue warnings with no > > side-effects (the device isn't used for anything except sysfs). > > Hardcoding to 0 is simply wrong, if the node0 is cpuless for example... It doesn't

Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On 2019/9/24 21:19, Michal Hocko wrote: > On Tue 24-09-19 14:59:36, Peter Zijlstra wrote: >> On Tue, Sep 24, 2019 at 02:43:25PM +0200, Peter Zijlstra wrote: >>> On Tue, Sep 24, 2019 at 02:25:00PM +0200, Michal Hocko wrote: On Tue 24-09-19 14:09:43, Peter Zijlstra wrote: >>> > We can push

Re: [PATCH v2 00/21] Refine memblock API

On Mon, Jan 21, 2019 at 2:05 AM Mike Rapoport wrote: > > Hi, > > Current memblock API is quite extensive and, which is more annoying, > duplicated. Except the low-level functions that allow searching for a free > memory region and marking it as reserved, memblock provides three (well, > two and a

Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On Tue 24-09-19 14:59:36, Peter Zijlstra wrote: > On Tue, Sep 24, 2019 at 02:43:25PM +0200, Peter Zijlstra wrote: > > On Tue, Sep 24, 2019 at 02:25:00PM +0200, Michal Hocko wrote: > > > On Tue 24-09-19 14:09:43, Peter Zijlstra wrote: > > > > > > We can push back and say we don't respect the

Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On Tue, Sep 24, 2019 at 02:43:25PM +0200, Peter Zijlstra wrote: > On Tue, Sep 24, 2019 at 02:25:00PM +0200, Michal Hocko wrote: > > On Tue 24-09-19 14:09:43, Peter Zijlstra wrote: > > > > We can push back and say we don't respect the specification because it > > > is batshit insane ;-) > > > >

Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On Tue, Sep 24, 2019 at 02:25:00PM +0200, Michal Hocko wrote: > On Tue 24-09-19 14:09:43, Peter Zijlstra wrote: > > We can push back and say we don't respect the specification because it > > is batshit insane ;-) > > Here is my fingers crossed. > > [...] > > > Now granted; there's a number of

Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On Tue 24-09-19 14:09:43, Peter Zijlstra wrote: > On Tue, Sep 24, 2019 at 01:54:01PM +0200, Michal Hocko wrote: > > On Tue 24-09-19 13:23:49, Peter Zijlstra wrote: > > > On Tue, Sep 24, 2019 at 12:56:22PM +0200, Michal Hocko wrote: > > [...] > > > > To be honest I really fail to see why to object

Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On 2019/9/24 19:58, Peter Zijlstra wrote: > On Tue, Sep 24, 2019 at 07:44:28PM +0800, Yunsheng Lin wrote: >> From [1], there is a lot of devices with node id of NUMA_NO_NODE with the >> FW_BUG. >> >> [1] >> https://lore.kernel.org/lkml/5a188e2b-6c07-a9db-fbaa-561e9362d...@huawei.com/ > > So

Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On 2019/9/24 19:28, Peter Zijlstra wrote: > On Tue, Sep 24, 2019 at 07:07:36PM +0800, Yunsheng Lin wrote: >> On 2019/9/24 17:25, Peter Zijlstra wrote: >>> On Tue, Sep 24, 2019 at 09:29:50AM +0800, Yunsheng Lin wrote: On 2019/9/24 4:34, Peter Zijlstra wrote: >>> > I'm saying the ACPI

Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On Tue, Sep 24, 2019 at 07:07:36PM +0800, Yunsheng Lin wrote: > On 2019/9/24 17:25, Peter Zijlstra wrote: > > On Tue, Sep 24, 2019 at 09:29:50AM +0800, Yunsheng Lin wrote: > >> On 2019/9/24 4:34, Peter Zijlstra wrote: > > > >>> I'm saying the ACPI standard is wrong. Explain to me how it is > >>>

Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On Tue, Sep 24, 2019 at 12:56:22PM +0200, Michal Hocko wrote: > On Tue 24-09-19 11:17:14, Peter Zijlstra wrote: > > On Tue, Sep 24, 2019 at 09:47:51AM +0200, Michal Hocko wrote: > > > On Mon 23-09-19 22:34:10, Peter Zijlstra wrote: > > > > On Mon, Sep 23, 2019 at 06:52:35PM +0200, Michal Hocko

Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On 2019/9/24 17:25, Peter Zijlstra wrote: > On Tue, Sep 24, 2019 at 09:29:50AM +0800, Yunsheng Lin wrote: >> On 2019/9/24 4:34, Peter Zijlstra wrote: > >>> I'm saying the ACPI standard is wrong. Explain to me how it is >>> physically possible to have a device without NUMA affinity in a NUMA >>>

Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On Tue 24-09-19 11:17:14, Peter Zijlstra wrote: > On Tue, Sep 24, 2019 at 09:47:51AM +0200, Michal Hocko wrote: > > On Mon 23-09-19 22:34:10, Peter Zijlstra wrote: > > > On Mon, Sep 23, 2019 at 06:52:35PM +0200, Michal Hocko wrote: > > [...] > > > > I even the > > > > ACPI standard is considering

Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On Tue, Sep 24, 2019 at 09:29:50AM +0800, Yunsheng Lin wrote: > On 2019/9/24 4:34, Peter Zijlstra wrote: > > I'm saying the ACPI standard is wrong. Explain to me how it is > > physically possible to have a device without NUMA affinity in a NUMA > > system? > > > > 1) The fundamental

Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On Tue, Sep 24, 2019 at 09:47:51AM +0200, Michal Hocko wrote: > On Mon 23-09-19 22:34:10, Peter Zijlstra wrote: > > On Mon, Sep 23, 2019 at 06:52:35PM +0200, Michal Hocko wrote: > [...] > > > I even the > > > ACPI standard is considering this optional. Yunsheng Lin has referred to > > > the

Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On Mon 23-09-19 22:34:10, Peter Zijlstra wrote: > On Mon, Sep 23, 2019 at 06:52:35PM +0200, Michal Hocko wrote: [...] > > I even the > > ACPI standard is considering this optional. Yunsheng Lin has referred to > > the specific part of the standard in one of the earlier discussions. > > Trying to

Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On 2019/9/24 4:34, Peter Zijlstra wrote: > On Mon, Sep 23, 2019 at 06:52:35PM +0200, Michal Hocko wrote: >> On Mon 23-09-19 17:48:52, Peter Zijlstra wrote: > >> To the NUMA_NO_NODE itself. Your earlier email noted: >> : > + >> : > if ((unsigned)node >= nr_node_ids) { >> : >

Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On Mon, Sep 23, 2019 at 06:52:35PM +0200, Michal Hocko wrote: > On Mon 23-09-19 17:48:52, Peter Zijlstra wrote: > To the NUMA_NO_NODE itself. Your earlier email noted: > : > + > : > if ((unsigned)node >= nr_node_ids) { > : > printk(KERN_WARNING > : >

Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On Mon 23-09-19 17:48:52, Peter Zijlstra wrote: > On Mon, Sep 23, 2019 at 05:28:56PM +0200, Michal Hocko wrote: > > On Mon 23-09-19 17:15:19, Peter Zijlstra wrote: > > > > > diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c > > > > index 4123100e..9859acb 100644 > > > > ---

Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On Mon, Sep 23, 2019 at 05:28:56PM +0200, Michal Hocko wrote: > On Mon 23-09-19 17:15:19, Peter Zijlstra wrote: > > > diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c > > > index 4123100e..9859acb 100644 > > > --- a/arch/x86/mm/numa.c > > > +++ b/arch/x86/mm/numa.c > > > @@ -861,6 +861,9 @@

Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On Mon 23-09-19 17:15:19, Peter Zijlstra wrote: > On Tue, Sep 17, 2019 at 08:48:54PM +0800, Yunsheng Lin wrote: > > When passing the return value of dev_to_node() to cpumask_of_node() > > without checking if the device's node id is NUMA_NO_NODE, there is > > global-out-of-bounds detected by KASAN.

Re: [PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On Tue, Sep 17, 2019 at 08:48:54PM +0800, Yunsheng Lin wrote: > When passing the return value of dev_to_node() to cpumask_of_node() > without checking if the device's node id is NUMA_NO_NODE, there is > global-out-of-bounds detected by KASAN. > > From the discussion [1], NUMA_NO_NODE really means

FROM MS LISA HUGH(BUSINESS)....

Dear Friend, I am Ms Lisa Hugh work with the department of Audit and accounting manager here in the Bank(B.O.A). Please i need your assistance for the transferring of thIs fund to your bank account for both of us benefit for life time investment, amount (US$4.5M DOLLARS). I have every

FROM MS LISA HUGH(BUSINESS).

Dear Friend, I am Ms Lisa Hugh work with the department of Audit and accounting manager here in the Bank(B.O.A). Please i need your assistance for the transferring of thIs fund to your bank account for both of us benefit for life time investment, amount (US$4.5M DOLLARS). I have every

Re: [PATCH v12 05/12] namei: obey trailing magic-link DAC permissions

On 2019-09-18, Aleksa Sarai wrote: > On 2019-09-17, Jann Horn wrote: > > On Wed, Sep 4, 2019 at 10:21 PM Aleksa Sarai wrote: > > > The ability for userspace to "re-open" file descriptors through > > > /proc/self/fd has been a very useful tool for all sorts of usecases > > > (container runtimes

Re: [PATCH v12 05/12] namei: obey trailing magic-link DAC permissions

On 2019-09-17, Jann Horn wrote: > On Wed, Sep 4, 2019 at 10:21 PM Aleksa Sarai wrote: > > The ability for userspace to "re-open" file descriptors through > > /proc/self/fd has been a very useful tool for all sorts of usecases > > (container runtimes are one common example). However, the current

Re: [PATCH v12 05/12] namei: obey trailing magic-link DAC permissions

On Wed, Sep 4, 2019 at 10:21 PM Aleksa Sarai wrote: > The ability for userspace to "re-open" file descriptors through > /proc/self/fd has been a very useful tool for all sorts of usecases > (container runtimes are one common example). However, the current > interface for doing this has resulted

[PATCH v6] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

When passing the return value of dev_to_node() to cpumask_of_node() without checking if the device's node id is NUMA_NO_NODE, there is global-out-of-bounds detected by KASAN. >From the discussion [1], NUMA_NO_NODE really means no node affinity, which also means all cpus should be usable. So the

Re: [PATCH v5] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On 2019/9/17 18:08, Michal Hocko wrote: > On Tue 17-09-19 17:53:57, Yunsheng Lin wrote: >> On 2019/9/17 17:36, Michal Hocko wrote: >>> On Tue 17-09-19 14:20:11, Yunsheng Lin wrote: On 2019/9/17 13:28, Michael Ellerman wrote: > Yunsheng Lin writes: >>> [...] >> But we cannot really

Re: [PATCH v5] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On Tue 17-09-19 17:53:57, Yunsheng Lin wrote: > On 2019/9/17 17:36, Michal Hocko wrote: > > On Tue 17-09-19 14:20:11, Yunsheng Lin wrote: > >> On 2019/9/17 13:28, Michael Ellerman wrote: > >>> Yunsheng Lin writes: > > [...] > But we cannot really copy the page allocator logic. Simply because

Re: [PATCH v5] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On 2019/9/17 17:36, Michal Hocko wrote: > On Tue 17-09-19 14:20:11, Yunsheng Lin wrote: >> On 2019/9/17 13:28, Michael Ellerman wrote: >>> Yunsheng Lin writes: > [...] But we cannot really copy the page allocator logic. Simply because the page allocator doesn't enforce the near node

Re: [PATCH v5] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On Tue 17-09-19 14:20:11, Yunsheng Lin wrote: > On 2019/9/17 13:28, Michael Ellerman wrote: > > Yunsheng Lin writes: [...] > >> But we cannot really copy the page allocator logic. Simply because the > >> page allocator doesn't enforce the near node affinity. It just picks it > >> up as a

Re: [PATCH v5] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On 2019/9/17 13:28, Michael Ellerman wrote: > Yunsheng Lin writes: >> When passing the return value of dev_to_node() to cpumask_of_node() >> without checking if the device's node id is NUMA_NO_NODE, there is >> global-out-of-bounds detected by KASAN. >> >> From the discussion [1], NUMA_NO_NODE

Re: [PATCH v5] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

Yunsheng Lin writes: > When passing the return value of dev_to_node() to cpumask_of_node() > without checking if the device's node id is NUMA_NO_NODE, there is > global-out-of-bounds detected by KASAN. > > From the discussion [1], NUMA_NO_NODE really means no node affinity, > which also means all

[PATCH v3 08/26] alpha/PCI: Use PCI_STD_NUM_BARS

Use define PCI_STD_NUM_BARS instead of PCI_ROM_RESOURCE for the number of PCI BARs. Cc: Richard Henderson Cc: Ivan Kokshaysky Cc: Matt Turner Signed-off-by: Denis Efremov --- arch/alpha/kernel/pci-sysfs.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git

[PATCH v5] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

When passing the return value of dev_to_node() to cpumask_of_node() without checking if the device's node id is NUMA_NO_NODE, there is global-out-of-bounds detected by KASAN. >From the discussion [1], NUMA_NO_NODE really means no node affinity, which also means all cpus should be usable. So the

Re: [PATCH v4] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On 2019/9/16 20:23, Michal Hocko wrote: > On Mon 16-09-19 20:07:22, Yunsheng Lin wrote: > [...] @@ -861,9 +861,12 @@ void numa_remove_cpu(int cpu) */ const struct cpumask *cpumask_of_node(int node) { - if (node >= nr_node_ids) { + if (node == NUMA_NO_NODE)

Re: [PATCH v4] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On Mon 16-09-19 20:07:22, Yunsheng Lin wrote: [...] > >> @@ -861,9 +861,12 @@ void numa_remove_cpu(int cpu) > >> */ > >> const struct cpumask *cpumask_of_node(int node) > >> { > >> - if (node >= nr_node_ids) { > >> + if (node == NUMA_NO_NODE) > >> + return cpu_online_mask; > >> + >

Re: [PATCH v4] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On 2019/9/16 16:43, Michal Hocko wrote: > On Sun 15-09-19 16:20:56, Yunsheng Lin wrote: >> When passing the return value of dev_to_node() to cpumask_of_node() >> without checking if the device's node id is NUMA_NO_NODE, there is >> global-out-of-bounds detected by KASAN. >> >> >From the discussion

Re: [PATCH v4] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

On Sun 15-09-19 16:20:56, Yunsheng Lin wrote: > When passing the return value of dev_to_node() to cpumask_of_node() > without checking if the device's node id is NUMA_NO_NODE, there is > global-out-of-bounds detected by KASAN. > > >From the discussion [1], NUMA_NO_NODE really means no node

[PATCH v4] numa: make node_to_cpumask_map() NUMA_NO_NODE aware

When passing the return value of dev_to_node() to cpumask_of_node() without checking if the device's node id is NUMA_NO_NODE, there is global-out-of-bounds detected by KASAN. >From the discussion [1], NUMA_NO_NODE really means no node affinity, which also means all cpus should be usable. So the

Re: [PATCH v3 7/8] mips: numa: make node_to_cpumask_map() NUMA_NO_NODE aware for mips

On 2019/9/15 14:46, Mike Rapoport wrote: > On Sun, Sep 15, 2019 at 02:13:51PM +0800, Yunsheng Lin wrote: >> On 2019/9/15 13:49, Mike Rapoport wrote: >>> Hi, >>> >>> On Thu, Sep 12, 2019 at 06:15:33PM +0800, Yunsheng Lin wrote: When passing the return value of dev_to_node() to

Re: [PATCH v3 7/8] mips: numa: make node_to_cpumask_map() NUMA_NO_NODE aware for mips

On Sun, Sep 15, 2019 at 02:13:51PM +0800, Yunsheng Lin wrote: > On 2019/9/15 13:49, Mike Rapoport wrote: > > Hi, > > > > On Thu, Sep 12, 2019 at 06:15:33PM +0800, Yunsheng Lin wrote: > >> When passing the return value of dev_to_node() to cpumask_of_node() > >> without checking the node id if the

Re: [PATCH v3 7/8] mips: numa: make node_to_cpumask_map() NUMA_NO_NODE aware for mips

On 2019/9/15 13:49, Mike Rapoport wrote: > Hi, > > On Thu, Sep 12, 2019 at 06:15:33PM +0800, Yunsheng Lin wrote: >> When passing the return value of dev_to_node() to cpumask_of_node() >> without checking the node id if the node id is NUMA_NO_NODE, there is >> global-out-of-bounds detected by

Re: [PATCH v3 7/8] mips: numa: make node_to_cpumask_map() NUMA_NO_NODE aware for mips

Hi, On Thu, Sep 12, 2019 at 06:15:33PM +0800, Yunsheng Lin wrote: > When passing the return value of dev_to_node() to cpumask_of_node() > without checking the node id if the node id is NUMA_NO_NODE, there is > global-out-of-bounds detected by KASAN. > > From the discussion [1], NUMA_NO_NODE

[PATCH v3 0/8] make node_to_cpumask_map() NUMA_NO_NODE aware

When passing the return value of dev_to_node() to cpumask_of_node() without checking the node id if the node id is NUMA_NO_NODE, there is global-out-of-bounds detected by KASAN: [ 42.970381] == [ 42.977595] BUG: KASAN:

[PATCH v3 8/8] mips: numa: make node_to_cpumask_map() NUMA_NO_NODE aware for loongson64

When passing the return value of dev_to_node() to cpumask_of_node() without checking the node id if the node id is NUMA_NO_NODE, there is global-out-of-bounds detected by KASAN. >From the discussion [1], NUMA_NO_NODE really means no node affinity, which also means all cpus should be usable. So

[PATCH v3 4/8] powerpc: numa: make node_to_cpumask_map() NUMA_NO_NODE aware for powerpc

When passing the return value of dev_to_node() to cpumask_of_node() without checking the node id if the node id is NUMA_NO_NODE, there is global-out-of-bounds detected by KASAN. >From the discussion [1], NUMA_NO_NODE really means no node affinity, which also means all cpus should be usable. So

[PATCH v3 7/8] mips: numa: make node_to_cpumask_map() NUMA_NO_NODE aware for mips

When passing the return value of dev_to_node() to cpumask_of_node() without checking the node id if the node id is NUMA_NO_NODE, there is global-out-of-bounds detected by KASAN. >From the discussion [1], NUMA_NO_NODE really means no node affinity, which also means all cpus should be usable. So

[PATCH v3 5/8] s390: numa: make node_to_cpumask_map() NUMA_NO_NODE aware for s390

When passing the return value of dev_to_node() to cpumask_of_node() without checking the node id if the node id is NUMA_NO_NODE, there is global-out-of-bounds detected by KASAN. >From the discussion [1], NUMA_NO_NODE really means no node affinity, which also means all cpus should be usable. So

[PATCH v3 6/8] sparc64: numa: make node_to_cpumask_map() NUMA_NO_NODE aware for sparc64

When passing the return value of dev_to_node() to cpumask_of_node() without checking the node id if the node id is NUMA_NO_NODE, there is global-out-of-bounds detected by KASAN. >From the discussion [1], NUMA_NO_NODE really means no node affinity, which also means all cpus should be usable. So

[PATCH v3 2/8] x86: numa: make node_to_cpumask_map() NUMA_NO_NODE aware for x86

When passing the return value of dev_to_node() to cpumask_of_node() without checking the node id if the node id is NUMA_NO_NODE, there is global-out-of-bounds detected by KASAN. >From the discussion [1], NUMA_NO_NODE really means no node affinity, which also means all cpus should be usable. So

[PATCH v3 1/8] arm64: numa: make node_to_cpumask_map() NUMA_NO_NODE aware for arm64

When passing the return value of dev_to_node() to cpumask_of_node() without checking the node id if the node id is NUMA_NO_NODE, there is global-out-of-bounds detected by KASAN. >From the discussion [1], NUMA_NO_NODE really means no node affinity, which also means all cpus should be usable. So

[PATCH v3 3/8] alpha: numa: make node_to_cpumask_map() NUMA_NO_NODE aware for alpha

When passing the return value of dev_to_node() to cpumask_of_node() without checking the node id if the node id is NUMA_NO_NODE, there is global-out-of-bounds detected by KASAN. >From the discussion [1], NUMA_NO_NODE really means no node affinity, which also means all cpus should be usable. So

Re: [PATCH v12 01/12] lib: introduce copy_struct_{to,from}_user helpers

On 2019-09-05, Peter Zijlstra wrote: > On Thu, Sep 05, 2019 at 11:43:05AM +0200, Peter Zijlstra wrote: > > On Thu, Sep 05, 2019 at 07:26:22PM +1000, Aleksa Sarai wrote: > > > On 2019-09-05, Peter Zijlstra wrote: > > > > On Thu, Sep 05, 2019 at 06:19:22AM +1000, Aleksa Sarai wrote: > > > > > +/**

Re: [PATCH v12 11/12] open: openat2(2) syscall

* Linus Torvalds wrote: > On Sat, Sep 7, 2019 at 10:42 AM Andy Lutomirski wrote: > > > > Linus, you rejected resolveat() because you wanted a *nice* API > > No. I rejected resoveat() because it was a completely broken garbage > API that couldn't do even basic stuff right (like O_CREAT). > >

<    1   2   3   4   5   6   7   8   9   10   >