On Mon, 2 Sept 2024 at 13:49, Andrew Morton wrote:
>
> uprobe_clear_state() is a pretty simple low-level thing. Side-effects
> seem unlikely?
I think uprobe_clear_state() should be removed from fork.c entirely,
made 'static', and then we'd have
area->xol_mapping.close = uprobe_clear_sta
top and internet, I'm unlikely to work on this any more.
Andrew - I think this is good, but there may be other issues lurking.
Do with it as you see fit,
Linus
From ef4e84d69c3d669e606b5d386625267a3b9c9573 Mon Sep 17 00:00:00 2001
From: Linus Torvalds
Date: Tue, 20 Aug 2024 15:14:47
On Tue, 20 Aug 2024 at 14:17, Rob Landley wrote:
>
> Hexagon also has &&vdso_page which I don't understand (but have a toolchain
> for
> somewhere to at least smoketest...)
The '&&' is just a typo. It should obviously be just a single '&'. As
mentioned, the only testing that patch got was a x86-
On Mon, 19 Aug 2024 at 23:26, Michael Ellerman wrote:
>
> Linus Torvalds writes:
> > +static struct vm_special_mapping vdso_mapping = {
> > + .name = "[vdso]",
> > + .pages = syscall_pages;
> ^
>
On Mon, 19 Aug 2024 at 18:05, Andrew Morton wrote:
>
> >
> > I forgot to actually attach that "this". Here it is. For real, this time.
>
> Thanks. Do you think your one-liner remains desirable with this fix in
> place?
That patch actually removes the whole 'legacy_special_mapping_vmops'
that my
On Mon, 19 Aug 2024 at 13:15, Linus Torvalds
wrote:
>
> Ok, I did a quick hack-job to remove that disgusting
> install_special_mapping() legacy case.
>
> With this [..]
I forgot to actually attach that "this". Here it is. For real, this time.
Linus
On Mon, 19 Aug 2024 at 12:51, Nathan Chancellor wrote:
>
> Yes, that appears to fix it for me. I don't have much to say about the
> rest but others might :)
Ok, I did a quick hack-job to remove that disgusting
install_special_mapping() legacy case.
With this, the old "install_special_mapping()"
On Mon, 19 Aug 2024 at 11:53, Nathan Chancellor wrote:
>
>
> Modules linked in:
> Pid: 24, comm: mount Not tainted 6.11.0-rc4-next-20240819
> RIP: 0033:0x68006f6c
> RSP: 6c8bfc68 EFLAGS: 00010206
> RAX: 68006f6c RBX: 68a0aa18 RCX: 600d8b09
> RDX: R
On Tue, 16 Jul 2024 at 17:53, Nathan Chancellor wrote:
>
> Can confirm. I tried it initially and it did not seem to work but I
> think I may have been using the wrong object folder or something.
I wonder if our dependency rules might not be confused by a new header
file just showing up earlier in
On Tue, 16 Jul 2024 at 16:18, Linus Torvalds
wrote:
>
> Hmm... Does this simple (whitespace-damaged) patch fix it for you?
I verified that it seemed to generate the right (generic) code, so
I've committed this fix. I didn't actually run your test-case, but it
looks ObviouslyCorr
On Tue, 16 Jul 2024 at 07:36, Nathan Chancellor wrote:
>
> Our continuous integration notices a crash when booting User Mode Linux
> after commit e3c92e81711d ("runtime constants: add x86 architecture
> support")
Ahh.
Yes, UML should *not* be using the x86-specific (or any "native")
runtime cons
On Thu, 28 Sept 2023 at 20:50, Amir Goldstein wrote:
>
> OTOH, it is perfectly fine if the vfs wants to stop providing sub 100ns
> services to filesystems. It's just going to be the fs problem and the
> preserved pre-historic/fine-grained time on existing files would only
> need to be provided in
On Thu, 28 Sept 2023 at 04:06, Jeff Layton wrote:
>
> Move i_blocks up above the i_lock, which moves the new 4 byte hole to
> just after the timestamps, without changing the size of the structure.
I'm sure others have mentioned this, but 'struct inode' is marked with
__randomize_layout, so the ac
On Thu, 28 Sept 2023 at 14:28, Theodore Ts'o wrote:
>
> I don't think anyone will complain about breaking the userspace API
> --- especially since if, say, the CIA was using this for their spies'
> drop boxes, they probably wouldn't want to admit it. :-)
Well, you will find that real apps do kin
On Tue, 19 Sept 2023 at 11:37, Steven Rostedt wrote:
>
> We could simply leave the cond_resched() around but defined as nops for
> everything but the "nostalgia club" to keep them from having any regressions.
I doubt the nostalgia club cares about some latencies (that are
usually only noticeable
On Tue, 19 Sept 2023 at 06:48, John Paul Adrian Glaubitz
wrote:
>
> As Geert poined out, I'm not seeing anything particular problematic with the
> architectures lacking CONFIG_PREEMPT at the moment. This seems to be more
> something about organizing KConfig files.
It can definitely be problematic
On Thu, Nov 17, 2022 at 2:58 PM Kees Cook wrote:
>
> Oh, er, why does get_arg_page() even need FOLL_FORCE? This is writing the
> new stack contents to the nascent brpm->vma, which was newly allocated
> with VM_STACK_FLAGS, which an arch can override, but they all appear to
> include
> VM_WRITE |
On Wed, Nov 16, 2022 at 2:30 AM David Hildenbrand wrote:
>
> Let's make it clearer that functionality provided by FOLL_FORCE is
> really only for ptrace access.
I'm not super-happy about this one.
I do understand the "let's rename the bit so that no new user shows up".
And it's true that the ma
Applied directly, just because I love seeing old nasty stuff like this go away.
Linus
___
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
19 matches
Mail list logo
