Replace open-coded pieces with sysfs_emit() helper in sysfs .show()
callbacks.
Signed-off-by: Paulo Miguel Almeida
---
Changelog:
- v2: amend commit message (Req: Maciej W. Rozycki)
- v1: https://lore.kernel.org/lkml/zw2grqkbx8z8d...@mail.google.com/
---
arch/mips/sgi-ip22/ip22-gio.c | 7 +++
On Thu, Oct 17, 2024 at 12:51:04AM +, jef...@chromium.org wrote:
> From: Jeff Xu
>
> Two fixes for madvise(MADV_DONTNEED) when sealed.
>
> For PROT_NONE mappings, the previous blocking of
> madvise(MADV_DONTNEED) is unnecessary. As PROT_NONE already prohibits
> memory access, madvise(MADV_DONT
On Thu, Oct 17, 2024 at 12:51:05AM +, jef...@chromium.org wrote:
> From: Jeff Xu
>
> Testcase for "Two fixes for madvise(MADV_DONTNEED) when sealed"
>
> test_seal_madvise_prot_none
> shall not block when mapping is PROT_NONE
>
> test_madvise_filebacked_writable
> shall not block writeable
On 10/16, Jeff Xu wrote:
>
> On Wed, Oct 16, 2024 at 6:10 PM Liam R. Howlett
> wrote:
> >
> > > + exec.seal_system_mappings = [KNL]
> > > + Format: { never | always }
> > > + Seal system mappings: vdso, vvar, sigpage, uprobes,
> > > +
NACK.
On Thu, Oct 17, 2024 at 12:51:03AM +, jef...@chromium.org wrote:
> From: Jeff Xu
>
> Two fixes for madvise(MADV_DONTNEED) when sealed.
>
> For PROT_NONE mappings, the previous blocking of
> madvise(MADV_DONTNEED) is unnecessary. As PROT_NONE already prohibits
> memory access, madvise(MA
NACK. Greg's bot got to it but...
As per Greg's bot, no signed-off-by line.
The subject should be something about adding a test.
You later say you are somehow dependning on things (what?) to make this work but
it's broken.
Jeff - you're doing things that were raised on previous reviews as if we
On Thu, Oct 17, 2024 at 10:46:10AM +0100, Lorenzo Stoakes wrote:
[snip]
> Anyway, let's try to decode (please take this as input as to how you should
> try to communicate these things):
>
>
> So we start with a VMA like this:
>
> 012345678901
>
>
> We then seal the middle, starting at
OK having said all of the below I think I know exactly what this is...
When an munmap() operation aborts due to error it does not attempt to
re-merge previously split VMAs so you might observe more splits than you
expect.
This is not a bug, it's expected behaviour. We do intend to address this
go
On Tue, Oct 15, 2024 at 03:01:13AM +0100, Maciej W. Rozycki wrote:
> On Tue, 15 Oct 2024, Paulo Miguel Almeida wrote:
>
> > snprintf() has the documented, but still rather strange trait of
> > returning the length of the data that *would have been* written to the
> > array if space were available,
sysfs_emit() helper function should be used when formatting the value to
be returned to user space.
This patch replaces open-coded snprint with sysfs_emit() helper in
sysfs .show() callbacks.
Signed-off-by: Paulo Miguel Almeida
---
arch/arm/mm/cache-l2x0-pmu.c | 2 +-
1 file changed, 1 insertio
Another thing about etiquette - sending a barely coherent _failing_ test
with basically zero explanation as a... patch is NOT how to interact with
the upstream community.
The sensible, respectful and workable way of doing this is to send
something like a [DISCUSSION] or something and say 'hey guys
On Thu, Oct 17, 2024 at 11:14:20AM -0700, Jeff Xu wrote:
> Hi Lorenzo and Muhammad
>
> Reviving this thread since the merging window is closed and we have
> more time to review /work on this code in the next few weeks.
>
> On Fri, Sep 13, 2024 at 3:50 PM Jeff Xu wrote:
> >
> > Hi Lorenzo
> >
> > O
Hi Pedro
On Thu, Oct 17, 2024 at 12:37 PM Pedro Falcato wrote:
>
> > For PROT_NONE mappings, the previous blocking of
> > madvise(MADV_DONTNEED) is unnecessary. As PROT_NONE already prohibits
> > memory access, madvise(MADV_DONTNEED) should be allowed to proceed in
> > order to free the page.
>
>
On Thu, Oct 17, 2024 at 11:29 AM Lorenzo Stoakes
wrote:
>
> On Thu, Oct 17, 2024 at 11:14:20AM -0700, Jeff Xu wrote:
> > Hi Lorenzo and Muhammad
> >
> > Reviving this thread since the merging window is closed and we have
> > more time to review /work on this code in the next few weeks.
> >
> > On
Hi Lorenzo and Muhammad
Reviving this thread since the merging window is closed and we have
more time to review /work on this code in the next few weeks.
On Fri, Sep 13, 2024 at 3:50 PM Jeff Xu wrote:
>
> Hi Lorenzo
>
> On Sat, Sep 7, 2024 at 12:28 PM Lorenzo Stoakes
> wrote:
> >
> >
> > I also
On Thu, Oct 17, 2024 at 09:20:20AM -0700, Jeff Xu wrote:
> On Thu, Oct 17, 2024 at 1:18 AM Lorenzo Stoakes
> wrote:
> >
> > NACK. Greg's bot got to it but...
> >
> > As per Greg's bot, no signed-off-by line.
> >
> Sorry for confusion, I wasn't meant to send this as a PATCH, but
> reporting the iss
On Thu, Oct 17, 2024 at 08:14:11PM +0100, Pedro Falcato wrote:
> On Thu, Oct 17, 2024 at 09:20:20AM -0700, Jeff Xu wrote:
> > On Thu, Oct 17, 2024 at 1:18 AM Lorenzo Stoakes
> > wrote:
> > >
> > > NACK. Greg's bot got to it but...
> > >
> > > As per Greg's bot, no signed-off-by line.
> > >
> > Sor
On Thu, Oct 17, 2024 at 12:14 PM Pedro Falcato wrote:
>
> On Thu, Oct 17, 2024 at 09:20:20AM -0700, Jeff Xu wrote:
> > On Thu, Oct 17, 2024 at 1:18 AM Lorenzo Stoakes
> > wrote:
> > >
> > > NACK. Greg's bot got to it but...
> > >
> > > As per Greg's bot, no signed-off-by line.
> > >
> > Sorry for
On Thu, Oct 17, 2024 at 11:47:15AM -0700, Jeff Xu wrote:
> On Thu, Oct 17, 2024 at 11:29 AM Lorenzo Stoakes
> wrote:
> >
> > On Thu, Oct 17, 2024 at 11:14:20AM -0700, Jeff Xu wrote:
> > > Hi Lorenzo and Muhammad
> > >
> > > Reviving this thread since the merging window is closed and we have
> > >
On Thu, Oct 17, 2024 at 12:51:04AM +, jef...@chromium.org wrote:
> From: Jeff Xu
>
> Two fixes for madvise(MADV_DONTNEED) when sealed.
>
Please separate these fixes into two separate patches.
> For PROT_NONE mappings, the previous blocking of
> madvise(MADV_DONTNEED) is unnecessary. As PROT
On Thu, Oct 17, 2024 at 01:34:53PM -0700, Jeff Xu wrote:
> Hi Pedro
>
> On Thu, Oct 17, 2024 at 12:37 PM Pedro Falcato
> wrote:
> >
> > > For PROT_NONE mappings, the previous blocking of
> > > madvise(MADV_DONTNEED) is unnecessary. As PROT_NONE already prohibits
> > > memory access, madvise(MADV
On Thu, Oct 17, 2024 at 1:49 PM Pedro Falcato wrote:
>
> On Thu, Oct 17, 2024 at 01:34:53PM -0700, Jeff Xu wrote:
> > Hi Pedro
> >
> > On Thu, Oct 17, 2024 at 12:37 PM Pedro Falcato
> > wrote:
> > >
> > > > For PROT_NONE mappings, the previous blocking of
> > > > madvise(MADV_DONTNEED) is unnece
On Thu, Oct 17, 2024 at 12:00 PM Lorenzo Stoakes
wrote:
>
> On Thu, Oct 17, 2024 at 11:47:15AM -0700, Jeff Xu wrote:
> > On Thu, Oct 17, 2024 at 11:29 AM Lorenzo Stoakes
> > wrote:
> > >
> > > On Thu, Oct 17, 2024 at 11:14:20AM -0700, Jeff Xu wrote:
> > > > Hi Lorenzo and Muhammad
> > > >
> > > >
On Thu, Oct 17, 2024 at 12:49:40PM -0700, Jeff Xu wrote:
> On Thu, Oct 17, 2024 at 12:00 PM Lorenzo Stoakes
> wrote:
> >
> > On Thu, Oct 17, 2024 at 11:47:15AM -0700, Jeff Xu wrote:
> > > On Thu, Oct 17, 2024 at 11:29 AM Lorenzo Stoakes
> > > wrote:
> > > >
> > > > On Thu, Oct 17, 2024 at 11:14:2
On Thu, Oct 17, 2024 at 1:38 AM Oleg Nesterov wrote:
>
> On 10/16, Jeff Xu wrote:
> >
> > On Wed, Oct 16, 2024 at 6:10 PM Liam R. Howlett
> > wrote:
> > >
> > > > + exec.seal_system_mappings = [KNL]
> > > > + Format: { never | always }
> > > > + Seal s
t;
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> master
> head: 15e7d45e786a62a211dd0098fee7c57f84f8c681
> commit: dfdb07df2ab66ff4fd2f82039e871e7ab922dc81 [4380/4439] Merge
> branch 'next' of
> git://git.kernel.org/pub/scm/linux/kerne
On Wed, Oct 16, 2024 at 11:04 PM Greg KH wrote:
>
> On Thu, Oct 17, 2024 at 02:26:27AM +, jef...@chromium.org wrote:
> > From: Jeff Xu
> >
> > It appears there is a regression on the latest mm,
> > when munmap sealed memory, it can cause unexpected VMA split.
> > E.g. repro use this test.
> >
On Thu, Oct 17, 2024 at 1:18 AM Lorenzo Stoakes
wrote:
>
> NACK. Greg's bot got to it but...
>
> As per Greg's bot, no signed-off-by line.
>
Sorry for confusion, I wasn't meant to send this as a PATCH, but
reporting the issue.
The diff was just sent as reference to repro the bug, and I forgot to
r
On Thu, Oct 17, 2024 at 09:07:13AM -0700, Kees Cook wrote:
> Something in the .config is causing the error. (!?) I will start a
> CONFIG bisect...
Well, I did a code bisect first, and it reported this which makes _no_
sense:
8afd8c8faa24 ("lsm: remove lsm_prop scaffolding")
O_o
--
Kees Cook
On Thu, Oct 17, 2024 at 09:23:25AM -0700, Kees Cook wrote:
> On Thu, Oct 17, 2024 at 09:07:13AM -0700, Kees Cook wrote:
> > Something in the .config is causing the error. (!?) I will start a
> > CONFIG bisect...
>
> Well, I did a code bisect first, and it reported this which makes _no_
> sense:
>
Alper Nebi Yasak wrote:
> Replace one-element array with a flexible-array member in `struct
> mwifiex_ie_types_wildcard_ssid_params` to fix the following warning
> on a MT8173 Chromebook (mt8173-elm-hana):
>
> [ 356.775250] [ cut here ]
> [ 356.784543] memcpy: detected
84f8c681
commit: dfdb07df2ab66ff4fd2f82039e871e7ab922dc81 [4380/4439] Merge
branch 'next' of
git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/lsm.git
config: x86_64-randconfig-005-20241017
(https://download.01.org/0day-ci/archive/20241017/202410171420.1v00icvg-...@intel.com/config)
compil
> On Wed, Oct 16, 2024 at 6:10 PM Liam R. Howlett
> wrote:
...
> > > diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c
> > > b/arch/x86/entry/vsyscall/vsyscall_64.c
> > > index 2fb7d53cf333..20a3000550d2 100644
> > > --- a/arch/x86/entry/vsyscall/vsyscall_64.c
> > > +++ b/arch/x86/entry/vsysca
On Thu, Oct 17, 2024 at 09:48:18AM -0700, Kees Cook wrote:
> On Thu, Oct 17, 2024 at 09:23:25AM -0700, Kees Cook wrote:
> > On Thu, Oct 17, 2024 at 09:07:13AM -0700, Kees Cook wrote:
> > > Something in the .config is causing the error. (!?) I will start a
> > > CONFIG bisect...
> >
> > Well, I did
34 matches
Mail list logo
