date:20220325

[linux-yocto] [PATCH v5.15 0/1] aufs: remove overhead for typically disabled Yocto use case

2022-03-25 Thread Paul Gortmaker

After having looked at the AUFS stuff some for the Yocto uprev, what I
wanted to look at a bit more was the raw patches, like the aufs5-mmap.patch
which touches existing core kernel files like mmap.c and fork.c etc.

It is worth noting that the Yocto use case is quite different from the
typical RYO user who goes out and sources AUFS for themselves.  In the
Yocto use case, we have probably 99% of our users who implicitly have
AUFS code present but disabled via Kconfig.  In the RYO case the code
is rarely ever disabled since it was intentionally put there to be used.

For those of us who used preempt-rt patches from over a decade ago, we
can remember instances where the present-and-enabled case got all the
testing and use, and the present-but-disabled case might not even build.

That means we should be paying extra attention to ensure the present but
disabled case isn't leaving us open to regressions, or any size or
performance burdens vs. the unpatched case with no AUFS code present.

To that end, I noticed overhead in AUFS that would remain even when
disabled that could be relatively easily avoided and I fix that here.

Boot testing included AUFS disabled, =y and =m (plus insmod) cases, on
the yocto v5.15.30 baseline with the previous AUFS update applied.

The two changes made here for the non-MMU case are untested but hopefully
"obviously" correct as parallels to the tested MMU instances.

Paul.
---

Paul Gortmaker (1):
  aufs: reduce overhead for "code present but disabled" use case.

 include/linux/mm.h   | 15 +++
 include/linux/mm_types.h |  4 
 mm/Makefile  |  3 ++-
 mm/mmap.c| 12 +++-
 4 files changed, 32 insertions(+), 2 deletions(-)

-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11084): 
https://lists.yoctoproject.org/g/linux-yocto/message/11084
Mute This Topic: https://lists.yoctoproject.org/mt/90039129/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto] [PATCH 1/1] aufs: reduce overhead for "code present but disabled" use case.

2022-03-25 Thread Paul Gortmaker

The AUFS code introduces a new mm/prfile.c which is used to hook in a
shadow structure plus some __FUNC__ and __LINE__ tracing via hijacking
some fs/file and mm/vma calls (see aufs5-standalone/aufs5-mmap.patch).

As these tiny stubs live in a separate source module, we are always going
to be bouncing through them, even with AUFS completely disabled.  We also
see AUFS adding some content to existing structs even with AUFS disabled.

We can fix the 1st by getting rid of prfile.c in the disabled case; we
replace it with macros that collapse to the original unpatched code.

We can fix the latter by using IS_ENABLED(CONFIG_AUFS_FS) around the
extra content AUFS adds/changes so they aren't present when disabled.
This covers both the CONFIG_AUFS_FS=m and CONFIG_AUFS_FS=y cases.

Finally, there is the deprecated remap_file_pages() syscall - and while
it has been deprecated since 2014 - it does add unused code and possibly
exposure to regressions/CVE etc. - and so I also used the very same
IS_ENABLED() there so we have the original code in the disabled case.

The size difference for the disabled case is easy to detect/display.
Functions found in prfile.c show up as "-" below since it isn't built:

  linux-yocto$ size ../aufs*/vmlinux
 textdata bss dec hex filename
  201760198124604 2019564 303201871cea63b 
../aufs-debloat/vmlinux
  201762598124604 2019564 303204271cea72b 
../aufs-default/vmlinux

  linux-yocto$./scripts/bloat-o-meter ../aufs-default/vmlinux 
../aufs-debloat/vmlinux
  add/remove: 0/4 grow/shrink: 0/14 up/down: 0/-871 (-871)
  Function old new   delta
  filemap_page_mkwrite 252 247  -5
  gate_vma 200 192  -8
  mmap_region 15281517 -11
  __vma_adjust23572345 -12
  remove_vma   104  91 -13
  dup_mm.isra 14031387 -16
  map_files_get_link   429 408 -21
  copy_vma 597 576 -21
  __split_vma  420 394 -26
  show_numa_map944 917 -27
  vma_do_pr_or_file 29   - -29
  vma_do_get_file   35   - -35
  show_map_vma 350 310 -40
  vma_do_fput   47   - -47
  vma_do_file_update_time   47   - -47
  __func__   17583   17424-159
  __ia32_sys_remap_file_pages  786 623-163
  __x64_sys_remap_file_pages   817 626-191
  Total: Before=17285664, After=17284793, chg -0.01%
  linux-yocto$

Performance should be restored to the original non-AUFS baseline given
the above reduction in code and removal of out-of-line stubs.

Signed-off-by: Paul Gortmaker 
---
 include/linux/mm.h   | 15 +++
 include/linux/mm_types.h |  4 
 mm/Makefile  |  3 ++-
 mm/mmap.c| 12 +++-
 4 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 31afd5410740..04c46c1ff2bf 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -1813,6 +1813,7 @@ static inline void unmap_shared_mapping_range(struct 
address_space *mapping,
unmap_mapping_range(mapping, holebegin, holelen, 0);
 }
 
+#if IS_ENABLED(CONFIG_AUFS_FS)
 extern void vma_do_file_update_time(struct vm_area_struct *, const char[], 
int);
 extern struct file *vma_do_pr_or_file(struct vm_area_struct *, const char[],
  int);
@@ -1835,6 +1836,20 @@ extern void vmr_do_fput(struct vm_region *, const 
char[], int);
 #define vmr_fput(region)   vmr_do_fput(region, __func__, __LINE__)
 #endif /* !CONFIG_MMU */
 
+#else /* !CONFIG_AUFS_FS */
+
+#define vma_file_update_time(vma)  file_update_time((vma)->vm_file)
+#define vma_pr_or_file(vma)(vma)->vm_file
+#define vma_get_file(vma)  get_file((vma)->vm_file)
+#define vma_fput(vma)  fput((vma)->vm_file)
+
+#ifndef CONFIG_MMU
+#define vmr_pr_or_file(region) (region)->vm_file
+#define vmr_fput(region)   fput((region)->vm_file)
+#endif /* !CONFIG_MMU */
+
+#endif /* !CONFIG_AUFS_FS */
+
 extern int access_process_vm(struct task_struct *tsk, unsigned long addr,
void *buf, int len, unsigned int gup_flags);
 extern int access_remote_vm(struct mm_struct *mm, unsigned long addr,
diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
index 3a9a798a4ae1..8fea872e08f7 100644
--- a/include/linux/mm_types.h
+++ b/include/linux/mm_types.h
@@ -294,7 +294,9 @@ struct vm_region {
unsigned

[linux-yocto] [PATCH v5.15-rt] aufs: update compile fix for v5.15+ preempt-rt kernels

2022-03-25 Thread Paul Gortmaker

The AUFS preempt-rt fix from v5.10 was forward ported to v5.15 in yocto
commit 3f9f162d9bb0 ("aufs: i_op: Add handling for au_pin_hdir_set_owner
with RT kernel") but that isn't quite correct, as we'll stll get:

fs/aufs/i_op.c: In function ‘au_pin_hdir_set_owner’:
fs/aufs/i_op.c:641:28: error: ‘struct rw_semaphore’ has no member named 
‘rtmutex’
  p->hdir->hi_inode->i_rwsem.rtmutex.owner = task;
^

This is because there has been some restructuring between v5.10 and v5.15
kernels; the  is gone and there is a new level of indirection:

In linux 5.10-rt

 -- include/linux/rwsem-rt.h --

struct rw_semaphore {
atomic_treaders;
struct rt_mutex rtmutex;
#ifdef CONFIG_DEBUG_LOCK_ALLOC
struct lockdep_map  dep_map;
#endif
};

In linux 5.15-rt

 -- include/linux/rwsem.h --

struct rw_semaphore {
struct rwbase_rtrwbase;
#ifdef CONFIG_DEBUG_LOCK_ALLOC
struct lockdep_map  dep_map;
#endif
};

 -- include/linux/rwbase_rt.h --

struct rwbase_rt {
atomic_treaders;
struct rt_mutex_basertmutex;
};

Hence we need to bounce through the rwbase to get to the rtmutex now.

Cc: He Zhe 
Signed-off-by: Paul Gortmaker 

diff --git a/fs/aufs/i_op.c b/fs/aufs/i_op.c
index 354fcb8ea1cb..ce36045f48cb 100644
--- a/fs/aufs/i_op.c
+++ b/fs/aufs/i_op.c
@@ -638,7 +638,7 @@ int au_pin_hdir_relock(struct au_pin *p)
 static void au_pin_hdir_set_owner(struct au_pin *p, struct task_struct *task)
 {
 #ifdef CONFIG_PREEMPT_RT
-   p->hdir->hi_inode->i_rwsem.rtmutex.owner = task;
+   p->hdir->hi_inode->i_rwsem.rwbase.rtmutex.owner = task;
 #else
atomic_long_set(>hdir->hi_inode->i_rwsem.owner, (long)task);
 #endif
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#11083): 
https://lists.yoctoproject.org/g/linux-yocto/message/11083
Mute This Topic: https://lists.yoctoproject.org/mt/90024952/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] CVE patch updates

2022-03-25 Thread Monsees, Steven C (US) via lists.yoctoproject.org

Thanks Tim,  subscribed…

From: Tim Orling 
Sent: Thursday, March 24, 2022 9:03 PM
To: Richard Purdie 
Cc: Monsees, Steven C (US) ; 
yocto@lists.yoctoproject.org
Subject: Re: [yocto] CVE patch updates

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click 
on a link, decrypt/open an attachment, or enable macros.  For further 
information on how to spot phishing, access “Cybersecurity OneSpace Page” and 
report phishing by clicking the button “Report Phishing” on the Outlook toolbar.

On Thu, Mar 24, 2022 at 2:45 PM Richard Purdie 
mailto:richard.pur...@linuxfoundation.org>> 
wrote:
On Thu, 2022-03-24 at 16:56 +, Monsees, Steven C (US) via
lists.yoctoproject.org wrote:
>
> I am currently building in cve-check to see what is reported, and I was 
> curious
> if Yocto might provide any CVE based patch repositories ?
>
> Is there a yocto page somewhere that goes over this side of things ?,
> I did not see much in the mega-manual… I am running on zeus based platforms 
> (for
> both armarch64 and x86_64).
>

You'll see output of cve-check on the yocto-security list for layers that are
still in maintenance:

https://lists.yoctoproject.org/g/yocto-security/messages

although zeus is out of maintenance.

We merge CVE fixes to the branches that are in maintenance.

A graph showing the data over time:

https://docs.google.com/spreadsheets/d/e/2PACX-1vRgNISmH0Ditf0bRtSezeR2XsgKIiSFJKF6KJUHpnzocNGzvKZbuSDKfmV3n64BFXDRqElBSJnhHtG4/pubchart?oid=1993375488=interactive

Steven, if you haven’t already, you should subscribe to
https://lists.yoctoproject.org/g/yocto-security

Emails are sent out, usually on Sunday. If you see a CVE that interests you… 
grab it and fix it.

This is mostly a community effort. There is no special dedicated squad of 
security champions.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56562): https://lists.yoctoproject.org/g/yocto/message/56562
Mute This Topic: https://lists.yoctoproject.org/mt/90004034/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] CVE patch updates

2022-03-25 Thread Monsees, Steven C (US) via lists.yoctoproject.org

Thanks Richard, will do…

From: Tim Orling 
Sent: Thursday, March 24, 2022 9:03 PM
To: Richard Purdie 
Cc: Monsees, Steven C (US) ; 
yocto@lists.yoctoproject.org
Subject: Re: [yocto] CVE patch updates

External Email Alert

This email has been sent from an account outside of the BAE Systems network.
Please treat the email with caution, especially if you are requested to click 
on a link, decrypt/open an attachment, or enable macros.  For further 
information on how to spot phishing, access “Cybersecurity OneSpace Page” and 
report phishing by clicking the button “Report Phishing” on the Outlook toolbar.

On Thu, Mar 24, 2022 at 2:45 PM Richard Purdie 
mailto:richard.pur...@linuxfoundation.org>> 
wrote:
On Thu, 2022-03-24 at 16:56 +, Monsees, Steven C (US) via
lists.yoctoproject.org wrote:
>
> I am currently building in cve-check to see what is reported, and I was 
> curious
> if Yocto might provide any CVE based patch repositories ?
>
> Is there a yocto page somewhere that goes over this side of things ?,
> I did not see much in the mega-manual… I am running on zeus based platforms 
> (for
> both armarch64 and x86_64).
>

You'll see output of cve-check on the yocto-security list for layers that are
still in maintenance:

https://lists.yoctoproject.org/g/yocto-security/messages

although zeus is out of maintenance.

We merge CVE fixes to the branches that are in maintenance.

A graph showing the data over time:

https://docs.google.com/spreadsheets/d/e/2PACX-1vRgNISmH0Ditf0bRtSezeR2XsgKIiSFJKF6KJUHpnzocNGzvKZbuSDKfmV3n64BFXDRqElBSJnhHtG4/pubchart?oid=1993375488=interactive

Steven, if you haven’t already, you should subscribe to
https://lists.yoctoproject.org/g/yocto-security

Emails are sent out, usually on Sunday. If you see a CVE that interests you… 
grab it and fix it.

This is mostly a community effort. There is no special dedicated squad of 
security champions.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56561): https://lists.yoctoproject.org/g/yocto/message/56561
Mute This Topic: https://lists.yoctoproject.org/mt/90004034/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto] [PATCH v5.15 0/1] aufs: remove overhead for typically disabled Yocto use case

[linux-yocto] [PATCH 1/1] aufs: reduce overhead for "code present but disabled" use case.

[linux-yocto] [PATCH v5.15-rt] aufs: update compile fix for v5.15+ preempt-rt kernels

Re: [yocto] CVE patch updates

Re: [yocto] CVE patch updates

5 matches

Site Navigation

Mail list logo

Footer information