[PATCH] ibmvfc: add new fields for version 2 of several MADs

2020-10-25 Thread Tyrel Datwyler
Introduce a targetWWPN field to several MADs. Its possible that a scsi ID of a target can change due to some fabric changes. The WWPN of the scsi target provides a better way to identify the target. Also, add flags for receiving MAD versioning information and advertising client support for targetWW

Re: [PATCH 0/4] arch, mm: improve robustness of direct map manipulation

2020-10-25 Thread Edgecombe, Rick P
On Sun, 2020-10-25 at 12:15 +0200, Mike Rapoport wrote: > Indeed, for architectures that define CONFIG_ARCH_HAS_SET_DIRECT_MAP > it is > possible that __kernel_map_pages() would fail, but since this > function is > void, the failure will go unnoticed. Could you elaborate on how this could happen?

Re: [PATCH 4/4] arch, mm: make kernel_page_present() always available

2020-10-25 Thread Edgecombe, Rick P
On Sun, 2020-10-25 at 12:15 +0200, Mike Rapoport wrote: > index 7f248fc45317..16f878c26667 100644 > --- a/arch/x86/mm/pat/set_memory.c > +++ b/arch/x86/mm/pat/set_memory.c > @@ -2228,7 +2228,6 @@ void __kernel_map_pages(struct page *page, int > numpages, int enable) > } > #endif /* CONFIG_DEBUG_P

Re: [PATCH 2/4] PM: hibernate: improve robustness of mapping pages in the direct map

2020-10-25 Thread Edgecombe, Rick P
On Sun, 2020-10-25 at 12:15 +0200, Mike Rapoport wrote: > From: Mike Rapoport > > When DEBUG_PAGEALLOC or ARCH_HAS_SET_DIRECT_MAP is enabled a page may > be > not present in the direct map and has to be explicitly mapped before > it > could be copied. > > On arm64 it is possible that a page woul

Re: [PATCH 0/3] warn and suppress irqflood

2020-10-25 Thread Pingfan Liu
On Thu, Oct 22, 2020 at 4:37 PM Thomas Gleixner wrote: > > On Thu, Oct 22 2020 at 13:56, Pingfan Liu wrote: > > I hit a irqflood bug on powerpc platform, and two years ago, on a x86 > > platform. > > When the bug happens, the kernel is totally occupies by irq. Currently, > > there > > may be no

[PATCH 4/4] arch, mm: make kernel_page_present() always available

2020-10-25 Thread Mike Rapoport
From: Mike Rapoport For architectures that enable ARCH_HAS_SET_MEMORY having the ability to verify that a page is mapped in the kernel direct map can be useful regardless of hibernation. Add RISC-V implementation of kernel_page_present() and update its forward declarations and stubs to be a part

[PATCH 3/4] arch, mm: restore dependency of __kernel_map_pages() of DEBUG_PAGEALLOC

2020-10-25 Thread Mike Rapoport
From: Mike Rapoport The design of DEBUG_PAGEALLOC presumes that __kernel_map_pages() must never fail. With this assumption is wouldn't be safe to allow general usage of this function. Moreover, some architectures that implement __kernel_map_pages() have this function guarded by #ifdef DEBUG_PAGE

[PATCH 2/4] PM: hibernate: improve robustness of mapping pages in the direct map

2020-10-25 Thread Mike Rapoport
From: Mike Rapoport When DEBUG_PAGEALLOC or ARCH_HAS_SET_DIRECT_MAP is enabled a page may be not present in the direct map and has to be explicitly mapped before it could be copied. On arm64 it is possible that a page would be removed from the direct map using set_direct_map_invalid_noflush() bu

[PATCH 1/4] mm: introduce debug_pagealloc_map_pages() helper

2020-10-25 Thread Mike Rapoport
From: Mike Rapoport When CONFIG_DEBUG_PAGEALLOC is enabled, it unmaps pages from the kernel direct mapping after free_pages(). The pages than need to be mapped back before they could be used. Theese mapping operations use __kernel_map_pages() guarded with with debug_pagealloc_enabled(). The only

[PATCH 0/4] arch, mm: improve robustness of direct map manipulation

2020-10-25 Thread Mike Rapoport
From: Mike Rapoport Hi, During recent discussion about KVM protected memory, David raised a concern about usage of __kernel_map_pages() outside of DEBUG_PAGEALLOC scope [1]. Indeed, for architectures that define CONFIG_ARCH_HAS_SET_DIRECT_MAP it is possible that __kernel_map_pages() would fail,