linux-stable.git/fs/proc/kcore.c, branch v6.4

mm: vmalloc: convert vread() to vread_iter()

2023-04-06T02:42:57+00:00

Having previously laid the foundation for converting vread() to an
iterator function, pull the trigger and do so.

This patch attempts to provide minimal refactoring and to reflect the
existing logic as best we can, for example we continue to zero portions of
memory not read, as before.

Overall, there should be no functional difference other than a performance
improvement in /proc/kcore access to vmalloc regions.

Now we have eliminated the need for a bounce buffer in read_kcore_iter(),
we dispense with it, and try to write to user memory optimistically but
with faults disabled via copy_page_to_iter_nofault().  We already have
preemption disabled by holding a spin lock.  We continue faulting in until
the operation is complete.

Additionally, we must account for the fact that at any point a copy may
fail (most likely due to a fault not being able to occur), we exit
indicating fewer bytes retrieved than expected.

[sfr@canb.auug.org.au: fix sparc64 warning]
  Link: https://lkml.kernel.org/r/20230320144721.663280c3@canb.auug.org.au
[lstoakes@gmail.com: redo Stephen's sparc build fix]
  Link: https://lkml.kernel.org/r/8506cbc667c39205e65a323f750ff9c11a463798.1679566220.git.lstoakes@gmail.com
[akpm@linux-foundation.org: unbreak uio.h includes]
Link: https://lkml.kernel.org/r/941f88bc5ab928e6656e1e2593b91bf0f8c81e1b.1679511146.git.lstoakes@gmail.com
Signed-off-by: Lorenzo Stoakes 
Signed-off-by: Stephen Rothwell 
Reviewed-by: Baoquan He 
Cc: Alexander Viro 
Cc: David Hildenbrand 
Cc: Jens Axboe 
Cc: Jiri Olsa 
Cc: Liu Shixin 
Cc: Matthew Wilcox (Oracle) 
Cc: Uladzislau Rezki (Sony) 
Signed-off-by: Andrew Morton

fs/proc/kcore: convert read_kcore() to read_kcore_iter()

2023-04-06T02:42:56+00:00

For the time being we still use a bounce buffer for vread(), however in
the next patch we will convert this to interact directly with the iterator
and eliminate the bounce buffer altogether.

Link: https://lkml.kernel.org/r/ebe12c8d70eebd71f487d80095605f3ad0d1489c.1679511146.git.lstoakes@gmail.com
Signed-off-by: Lorenzo Stoakes 
Reviewed-by: David Hildenbrand 
Reviewed-by: Baoquan He 
Cc: Alexander Viro 
Cc: Jens Axboe 
Cc: Jiri Olsa 
Cc: Liu Shixin 
Cc: Matthew Wilcox (Oracle) 
Cc: Uladzislau Rezki (Sony) 
Signed-off-by: Andrew Morton

fs/proc/kcore: avoid bounce buffer for ktext data

2023-04-06T02:42:56+00:00

Patch series "convert read_kcore(), vread() to use iterators", v8.

While reviewing Baoquan's recent changes to permit vread() access to
vm_map_ram regions of vmalloc allocations, Willy pointed out [1] that it
would be nice to refactor vread() as a whole, since its only user is
read_kcore() and the existing form of vread() necessitates the use of a
bounce buffer.

This patch series does exactly that, as well as adjusting how we read the
kernel text section to avoid the use of a bounce buffer in this case as
well.

This has been tested against the test case which motivated Baoquan's
changes in the first place [2] which continues to function correctly, as
do the vmalloc self tests.


This patch (of 4):

Commit df04abfd181a ("fs/proc/kcore.c: Add bounce buffer for ktext data")
introduced the use of a bounce buffer to retrieve kernel text data for
/proc/kcore in order to avoid failures arising from hardened user copies
enabled by CONFIG_HARDENED_USERCOPY in check_kernel_text_object().

We can avoid doing this if instead of copy_to_user() we use
_copy_to_user() which bypasses the hardening check.  This is more
efficient than using a bounce buffer and simplifies the code.

We do so as part an overall effort to eliminate bounce buffer usage in the
function with an eye to converting it an iterator read.

Link: https://lkml.kernel.org/r/cover.1679566220.git.lstoakes@gmail.com
Link: https://lore.kernel.org/all/Y8WfDSRkc%2FOHP3oD@casper.infradead.org/ [1]
Link: https://lore.kernel.org/all/87ilk6gos2.fsf@oracle.com/T/#u [2]
Link: https://lkml.kernel.org/r/fd39b0bfa7edc76d360def7d034baaee71d90158.1679511146.git.lstoakes@gmail.com
Signed-off-by: Lorenzo Stoakes 
Reviewed-by: David Hildenbrand 
Reviewed-by: Baoquan He 
Cc: Alexander Viro 
Cc: Jens Axboe 
Cc: Jiri Olsa 
Cc: Liu Shixin 
Cc: Matthew Wilcox (Oracle) 
Cc: Uladzislau Rezki (Sony) 
Signed-off-by: Andrew Morton

mm: remove kern_addr_valid() completely

2022-11-09T01:37:18+00:00

Most architectures (except arm64/x86/sparc) simply return 1 for
kern_addr_valid(), which is only used in read_kcore(), and it calls
copy_from_kernel_nofault() which could check whether the address is a
valid kernel address.  So as there is no need for kern_addr_valid(), let's
remove it.

Link: https://lkml.kernel.org/r/20221018074014.185687-1-wangkefeng.wang@huawei.com
Signed-off-by: Kefeng Wang 
Acked-by: Geert Uytterhoeven 	[m68k]
Acked-by: Heiko Carstens 		[s390]
Acked-by: Christoph Hellwig 
Acked-by: Helge Deller 			[parisc]
Acked-by: Michael Ellerman 		[powerpc]
Acked-by: Guo Ren 			[csky]
Acked-by: Catalin Marinas 	[arm64]
Cc: Alexander Gordeev 
Cc: Andy Lutomirski 
Cc: Anton Ivanov 
Cc: 
Cc: Borislav Petkov 
Cc: Christian Borntraeger 
Cc: Christophe Leroy 
Cc: Chris Zankel 
Cc: Dave Hansen 
Cc: David S. Miller 
Cc: Dinh Nguyen 
Cc: Greg Ungerer 
Cc: H. Peter Anvin 
Cc: Huacai Chen 
Cc: Ingo Molnar 
Cc: Ivan Kokshaysky 
Cc: James Bottomley 
Cc: Johannes Berg 
Cc: Jonas Bonn 
Cc: Matt Turner 
Cc: Max Filippov 
Cc: Michal Simek 
Cc: Nicholas Piggin 
Cc: Palmer Dabbelt 
Cc: Paul Walmsley 
Cc: Peter Zijlstra 
Cc: Richard Henderson 
Cc: Richard Weinberger 
Cc: Rich Felker 
Cc: Russell King 
Cc: Stafford Horne 
Cc: Stefan Kristiansson 
Cc: Sven Schnelle 
Cc: Thomas Bogendoerfer 
Cc: Thomas Gleixner 
Cc: Vasily Gorbik 
Cc: Vineet Gupta 
Cc: Will Deacon 
Cc: Xuerui Wang 
Cc: Yoshinori Sato 
Signed-off-by: Andrew Morton

memory: move hotplug memory notifier priority to same file for easy sorting

2022-11-09T01:37:17+00:00

The priority of hotplug memory callback is defined in a different file. 
And there are some callers using numbers directly.  Collect them together
into include/linux/memory.h for easy reading.  This allows us to sort
their priorities more intuitively without additional comments.

Link: https://lkml.kernel.org/r/20220923033347.3935160-9-liushixin2@huawei.com
Signed-off-by: Liu Shixin 
Cc: Christoph Lameter 
Cc: David Hildenbrand 
Cc: Kefeng Wang 
Cc: Waiman Long 
Cc: zefan li 
Signed-off-by: Andrew Morton

fs/proc/kcore.c: use hotplug_memory_notifier() directly

2022-11-09T01:37:15+00:00

Commit 76ae847497bc52 ("Documentation: raise minimum supported version of
GCC to 5.1") updated the minimum gcc version to 5.1.  So the problem
mentioned in f02c69680088 ("include/linux/memory.h: implement
register_hotmemory_notifier()") no longer exist.  So we can now switch to
use hotplug_memory_notifier() directly rather than
register_hotmemory_notifier().

Link: https://lkml.kernel.org/r/20220923033347.3935160-3-liushixin2@huawei.com
Signed-off-by: Liu Shixin 
Reviewed-by: David Hildenbrand 
Cc: Christoph Lameter 
Cc: Kefeng Wang 
Cc: Waiman Long 
Cc: zefan li 
Signed-off-by: Andrew Morton

fs/proc/kcore.c: remove check of list iterator against head past the loop body

2022-04-29T21:37:59+00:00

When list_for_each_entry() completes the iteration over the whole list
without breaking the loop, the iterator value will be a bogus pointer
computed based on the head element.

While it is safe to use the pointer to determine if it was computed based
on the head element, either with list_entry_is_head() or &pos->member ==
head, using the iterator variable after the loop should be avoided.

In preparation to limit the scope of a list iterator to the list traversal
loop, use a dedicated pointer to point to the found element [1].

[akpm@linux-foundation.org: reduce scope of `iter']
Link: https://lore.kernel.org/all/CAHk-=wgRr_D8CB-D9Kg-c=EHreAsk5SqXPwr9Y7k9sA6cWXJ6w@mail.gmail.com/ [1]
Link: https://lkml.kernel.org/r/20220331223700.902556-1-jakobkoschel@gmail.com
Signed-off-by: Jakob Koschel 
Cc: Mike Rapoport 
Cc: David Hildenbrand 
Cc: Oscar Salvador 
Cc: "Brian Johannesmeyer" 
Cc: Cristiano Giuffrida 
Cc: "Bos, H.J." 
Cc: Alexey Dobriyan 
Signed-off-by: Andrew Morton

fs/proc/kcore: use page_offline_(freeze|thaw)

2021-07-01T03:47:28+00:00

Let's properly synchronize with drivers that set PageOffline().
Unfreeze/thaw every now and then, so drivers that want to set
PageOffline() can make progress.

Link: https://lkml.kernel.org/r/20210526093041.8800-7-david@redhat.com
Signed-off-by: David Hildenbrand 
Acked-by: Mike Rapoport 
Reviewed-by: Oscar Salvador 
Cc: Aili Yao 
Cc: Alexey Dobriyan 
Cc: Alex Shi 
Cc: Haiyang Zhang 
Cc: Jason Wang 
Cc: Jiri Bohac 
Cc: "K. Y. Srinivasan" 
Cc: "Matthew Wilcox (Oracle)" 
Cc: "Michael S. Tsirkin" 
Cc: Michal Hocko 
Cc: Mike Kravetz 
Cc: Naoya Horiguchi 
Cc: Roman Gushchin 
Cc: Stephen Hemminger 
Cc: Steven Price 
Cc: Wei Liu 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fs/proc/kcore: don't read offline sections, logically offline pages and hwpoisoned pages

2021-07-01T03:47:28+00:00

Let's avoid reading:

1) Offline memory sections: the content of offline memory sections is
   stale as the memory is effectively unused by the kernel.  On s390x with
   standby memory, offline memory sections (belonging to offline storage
   increments) are not accessible.  With virtio-mem and the hyper-v
   balloon, we can have unavailable memory chunks that should not be
   accessed inside offline memory sections.  Last but not least, offline
   memory sections might contain hwpoisoned pages which we can no longer
   identify because the memmap is stale.

2) PG_offline pages: logically offline pages that are documented as
   "The content of these pages is effectively stale.  Such pages should
   not be touched (read/write/dump/save) except by their owner.".
   Examples include pages inflated in a balloon or unavailble memory
   ranges inside hotplugged memory sections with virtio-mem or the hyper-v
   balloon.

3) PG_hwpoison pages: Reading pages marked as hwpoisoned can be fatal.
   As documented: "Accessing is not safe since it may cause another
   machine check.  Don't touch!"

Introduce is_page_hwpoison(), adding a comment that it is inherently racy
but best we can really do.

Reading /proc/kcore now performs similar checks as when reading
/proc/vmcore for kdump via makedumpfile: problematic pages are exclude.
It's also similar to hibernation code, however, we don't skip hwpoisoned
pages when processing pages in kernel/power/snapshot.c:saveable_page()
yet.

Note 1: we can race against memory offlining code, especially memory going
offline and getting unplugged: however, we will properly tear down the
identity mapping and handle faults gracefully when accessing this memory
from kcore code.

Note 2: we can race against drivers setting PageOffline() and turning
memory inaccessible in the hypervisor.  We'll handle this in a follow-up
patch.

Link: https://lkml.kernel.org/r/20210526093041.8800-4-david@redhat.com
Signed-off-by: David Hildenbrand 
Reviewed-by: Mike Rapoport 
Reviewed-by: Oscar Salvador 
Cc: Aili Yao 
Cc: Alexey Dobriyan 
Cc: Alex Shi 
Cc: Haiyang Zhang 
Cc: Jason Wang 
Cc: Jiri Bohac 
Cc: "K. Y. Srinivasan" 
Cc: "Matthew Wilcox (Oracle)" 
Cc: "Michael S. Tsirkin" 
Cc: Michal Hocko 
Cc: Mike Kravetz 
Cc: Naoya Horiguchi 
Cc: Roman Gushchin 
Cc: Stephen Hemminger 
Cc: Steven Price 
Cc: Wei Liu 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fs/proc/kcore: pfn_is_ram check only applies to KCORE_RAM

2021-07-01T03:47:28+00:00

Let's resturcture the code, using switch-case, and checking pfn_is_ram()
only when we are dealing with KCORE_RAM.

Link: https://lkml.kernel.org/r/20210526093041.8800-3-david@redhat.com
Signed-off-by: David Hildenbrand 
Reviewed-by: Mike Rapoport 
Cc: Aili Yao 
Cc: Alexey Dobriyan 
Cc: Alex Shi 
Cc: Haiyang Zhang 
Cc: Jason Wang 
Cc: Jiri Bohac 
Cc: "K. Y. Srinivasan" 
Cc: "Matthew Wilcox (Oracle)" 
Cc: "Michael S. Tsirkin" 
Cc: Michal Hocko 
Cc: Mike Kravetz 
Cc: Naoya Horiguchi 
Cc: Oscar Salvador 
Cc: Roman Gushchin 
Cc: Stephen Hemminger 
Cc: Steven Price 
Cc: Wei Liu 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds