On Mon, 8 Apr 2024 at 20:24, Alexei Starovoitov
wrote:
>
> On Mon, Apr 8, 2024 at 2:30 AM Marco Elver wrote:
> >
> > On Fri, 5 Apr 2024 at 22:28, Andrii Nakryiko
> > wrote:
> > >
> > > On Fri, Apr 5, 2024 at 1:28 AM Marco Elver wrote:
> > > >
> > > > On Fri, 5 Apr 2024 at 01:23, Alexei Starovo
Prior to v2.6.39 write access to /proc//mem was restricted,
after which it got allowed in commit 198214a7ee50 ("proc: enable
writing to /proc/pid/mem"). Famous last words from that patch:
"no longer a security hazard". :)
Afterwards exploits started causing drama like [1]. The exploits
using /proc
Some systems might have difficulty changing their bootloaders
to enable the newly added restrict_proc_mem* params, for e.g.
remote embedded doing OTA updates, so this provides a set of
Kconfigs to set /proc/pid/mem restrictions at build-time.
The boot params take precedence over the Kconfig values
Re-send of TPM documentation updates. Note that in this patch set the
patch versions do not have relation to the patch set version, as they
were before managed as independent patches.
Cc: Alexander Steffen
CC: Daniel P. Smith
Cc: James Bottomley
Cc: Jason Gunthorpe
Cc: Jonathan Corbet
Cc: Lin
Add TPM driver test suite URL to the MAINTAINERS files and move the wiki
URL to more appropriate location.
Link: https://gitlab.com/jarkkojs/linux-tpmdd-test
Link: https://kernsec.org/wiki/index.php/Linux_Kernel_Integrity
Acked-by: Paul Menzel
Signed-off-by: Jarkko Sakkinen
---
v2:
- Typo fix:
Based recent discussions on LKML, provide preliminary bits of tpm_tis_core
dependent drivers. Includes only bare essentials but can be extended later
on case by case. This way some people may even want to read it later on.
Signed-off-by: Jarkko Sakkinen
---
v4:
- Extended the text to address some
This series tracks the mapcount of large folios in a single value, so
it can be read efficiently and atomically, just like the mapcount of
small folios.
folio_mapcount() is then used in a couple more places, most notably to
reduce false negatives in folio_likely_mapped_shared(), and many users of
As we grow the code, the compiler might make stupid decisions and
unnecessarily degrade fork() performance. Let's make sure to always inline
functions that operate on a single PTE so the compiler will always
optimize out the loop and avoid a function call.
This is a preparation for maintining a to
Commit 53277bcf126d ("mm: support page_mapcount() on page_has_type()
pages") made it impossible to detect mapcount underflows by treating
any negative raw mapcount value as a mapcount of 0.
We perform such underflow checks in zap_present_folio_ptes() and
zap_huge_pmd(), which would currently no lo
Let's add a fast-path for small folios to all relevant rmap functions.
Note that only RMAP_LEVEL_PTE applies.
This is a preparation for tracking the mapcount of large folios in a
single value.
Signed-off-by: David Hildenbrand
---
include/linux/rmap.h | 13 +
mm/rmap.c| 2
Let's track the mapcount of large folios in a single value. The mapcount of
a large folio currently corresponds to the sum of the entire mapcount and
all page mapcounts.
This sum is what we actually want to know in folio_mapcount() and it is
also sufficient for implementing folio_mapped().
With P
We can now read the mapcount of large folios very efficiently. Use it to
improve our handling of partially-mappable folios, falling back
to making a guess only in case the folio is not "obviously mapped shared".
We can now better detect partially-mappable folios where the first page is
not mapped
We already handle it properly for large folios. Let's also return "0"
for small typed folios, like page_mapcount() currently would.
Consequently, folio_mapcount() will never return negative values for
typed folios, but may return negative values for underflows.
Signed-off-by: David Hildenbrand
-
We want to limit the use of page_mapcount() to the places where it is
absolutely necessary. In zap_present_folio_ptes(), let's simply check
the folio mapcount(). If there is some issue, it will underflow at some
point either way when unmapping.
As indicated already in commit 10ebac4f95e7 ("mm/memo
We want to limit the use of page_mapcount() to the places where it is
absolutely necessary. Let's similarly check for folio_mapcount() underflows
instead of page_mapcount() underflows like we do in
zap_present_folio_ptes() now.
Instead of the VM_BUG_ON(), we should actually be doing something like
We want to limit the use of page_mapcount() to the places where it is
absolutely necessary. We can only unmap full folios; page_mapped(),
which we check here, is translated to folio_mapped() -- based on
folio_mapcount(). So let's print the folio mapcount instead.
Signed-off-by: David Hildenbrand
We want to limit the use of page_mapcount() to the places where it is
absolutely necessary.
For tracing purposes, we use page_mapcount() in
__alloc_contig_migrate_range(). Adding that mapcount to total_mapped sounds
strange: total_migrated and total_reclaimed would count each page only
once, not m
We want to limit the use of page_mapcount() to the places where it is
absolutely necessary. In add_page_for_migration(), we actually want to
check if the folio is mapped shared, to reject such folios. So let's
use folio_likely_mapped_shared() instead.
For small folios, fully mapped THP, and hugetl
We want to limit the use of page_mapcount() to the places where it is
absolutely necessary.
We're already using folio_mapped in copy_user_highpage() and
copy_to_user_page() for a similar purpose so ... let's also simply use
it for copy_from_user_page().
There is no change for small folios. Likely
We want to limit the use of page_mapcount() to the places where it is
absolutely necessary.
Let's use folio_mapcount() instead of filemap_unaccount_folio().
No functional change intended, because we're only dealing with small
folios.
Signed-off-by: David Hildenbrand
---
mm/filemap.c | 2 +-
1
We want to limit the use of page_mapcount() to the places where it is
absolutely necessary. Let's convert migrate_vma_check_page() to work on
a folio internally so we can remove the page_mapcount() usage.
Note that we reject any large folios.
There is a lot more folio conversion to be had, but th
We want to limit the use of page_mapcount() to the places where it is
absolutely necessary. We already trace raw page->refcount, raw page->flags
and raw page->mapping, and don't involve any folios. Let's also trace the
raw mapcount value that does not consider the entire mapcount of large
folios, a
We want to limit the use of page_mapcount() to the places where it is
absolutely necessary. So let's convert check_tlb_entry() to perform
sanity checks on folios instead of pages.
This essentially already happened: page_count() is mapped to
folio_ref_count(), and page_mapped() to folio_mapped() in
Let's simplify and only print the page mapcount: we already print the
large folio mapcount and the entire folio mapcount for large folios
separately; that should be sufficient to figure out what's happening.
While at it, print the page mapcount also if it had an underflow,
filtering out only typed
Let's stop talking about page_mapcount().
Signed-off-by: David Hildenbrand
---
Documentation/admin-guide/cgroup-v1/memory.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/cgroup-v1/memory.rst
b/Documentation/admin-guide/cgroup-v1/memory.rst
i
On 9 Apr 2024, at 15:22, David Hildenbrand wrote:
> Commit 53277bcf126d ("mm: support page_mapcount() on page_has_type()
> pages") made it impossible to detect mapcount underflows by treating
> any negative raw mapcount value as a mapcount of 0.
>
> We perform such underflow checks in zap_present_
On 9 Apr 2024, at 15:22, David Hildenbrand wrote:
> Let's track the mapcount of large folios in a single value. The mapcount of
> a large folio currently corresponds to the sum of the entire mapcount and
> all page mapcounts.
>
> This sum is what we actually want to know in folio_mapcount() and it
On Tue, Apr 9, 2024 at 1:11 AM Marco Elver wrote:
>
> On Mon, 8 Apr 2024 at 20:24, Alexei Starovoitov
> wrote:
> >
> > On Mon, Apr 8, 2024 at 2:30 AM Marco Elver wrote:
> > >
> > > On Fri, 5 Apr 2024 at 22:28, Andrii Nakryiko
> > > wrote:
> > > >
> > > > On Fri, Apr 5, 2024 at 1:28 AM Marco El
On Tue, Apr 09, 2024 at 09:22:44PM +0200, David Hildenbrand wrote:
> Commit 53277bcf126d ("mm: support page_mapcount() on page_has_type()
> pages") made it impossible to detect mapcount underflows by treating
> any negative raw mapcount value as a mapcount of 0.
Yes, but I don't think this is the
29 matches
Mail list logo
