On Fri, 23 May 2008, Jeremy Fitzhardinge wrote:
>
> This series adds the pte_rmw_start() and pte_rmw_commit() operations,
> which change this sequence to:
>
> ptent = pte_rmw_start(mm, addr, pte);
> ptent = pte_modify(ptent, newprot);
> /* ... */
> pte_rmw_commit(mm, add
On Fri, 23 May 2008, Jeremy Fitzhardinge wrote:
>
> Well, you could use it to update the page and protection bits while preserving
> the AD bits, but I don't think that's very useful.
It's not that it's not "very useful" - it's that it would be TOTALLY
WRONG.
If you change the page and the AD
ot_commit() writes back the updated pte, makes sure that
> any hardware updates made since ptep_modify_prot_start() are
> preserved.
Ok, I'm fine with this now that it's renamed to be clearly about just
protection bits.
So
Acked-by: Linus Torvalds <[E
On Wed, 18 Jun 2008, Jeremy Fitzhardinge wrote:
>
> Along the lines of:
Hell no. There's a reason we have a special set_wrprotect() thing. We can
do it more efficiently on native hardware by just clearing the bit
atomically. No need to do the cmpxchg games.
Linus
_
On Wed, 18 Jun 2008, Jeremy Fitzhardinge wrote:
>
> It's not cmpxchg, just xchg.
> In other words, is:
>
> lock btr $_PAGE_BIT_RW, (%rbx)
Well, we can actually do it as
lock andl $~_PAGE_RW,(%rbx)
although we haven't bothered (I've wanted several times to make
clear_bit() do t
On Wed, 18 Jun 2008, Linus Torvalds wrote:
>
> And yes, the "lock andl" should be noticeably faster than the xchgl.
I dunno. Here's a untested (!!) patch that turns constant-bit
set/clear_bit ops into byte mask ops (lock orb/andb).
It's not exactly pretty. The
On Thu, 19 Jun 2008, Ingo Molnar wrote:
>
> Below is the commit, it needed a small amount of massaging to apply the
> void * -> unsigned long * change in the x86/bitops topic.
Well, that's your bug right there.
The macros very much depended on the pointers being "void *", due to the
pointer
On Fri, 20 Jun 2008, Jeremy Fitzhardinge wrote:
>
> Blows up on "gcc version 3.4.4 20050314 (prerelease) (Debian 3.4.3-13)":
Yeah, I was a bit worried about that. Gcc sometimes does insane things.
We literally just tested that the asm should only _ever_ be generated with
a constant value, but
On Fri, 20 Jun 2008, Ingo Molnar wrote:
>
> okay - Jeremy, could you try the fix below? (or tip/master, i just
> pushed this out)
Actually, don't try that one.
It needs to be a _byte_ registers, so "ir" was wrong. You need "iq".
Linus
_
On Mon, 18 Aug 2008, Anthony Liguori wrote: <
>
> This handles the case where v < vb->num_pages and ensures we get a
> small, negative, s64 as the result.
That's just horrible code.
Maybe the compiler notices that you're doing something stupid, but
basically, please don't do this.
> - r
On Mon, 18 Aug 2008, Anthony Liguori wrote:
>
> Nothing. It works just fine. However, I implemented it more verbosely
> because this is the second time we've "fixed" this problem. See
>
> commit bdc1681cdf1ab6a65fa935a2b3f8fc63b20c54ea
> Author: Rusty Russell <[EMAIL PROTECTED]>
> Date: Mo
On Thu, 23 Apr 2009, Rusty Russell wrote:
>
> From: Christian Borntraeger
>
> The virtio-rng drivers checks for spurious callbacks. Since
> callbacks can be implemented via shared interrupts (e.g. PCI) this
> could lead to guest kernel oopses with lots of virtio devices.
>
> Signed-off-by: Chr
On Mon, 19 Mar 2007, Eric W. Biederman wrote:
>
> True. You can use all of the call clobbered registers.
Quite often, the biggest single win of inlining is not so much the code
size (although if done right, that will be smaller too), but the fact that
inlining DOES NOT CLOBBER AS MANY REGIST
On Mon, 19 Mar 2007, Linus Torvalds wrote:
>
> So *please* don't believe that you can make it "as cheap" to have some
> automatic fixup of two sequences, one inlined and one as a "call". It may
> look so when you look at the single instruction gene
On Mon, 19 Mar 2007, Andi Kleen wrote:
>
> Initially we had some bugs that accounted for near all failures, but they
> were all fixed in the latest version.
No. The real bugs were that the people involved wouldn't even accept that
unwinding information was inevitably buggy and/or incomplete.
On Mon, 19 Mar 2007, Jeremy Fitzhardinge wrote:
>
> Zachary Amsden wrote:
> > For VMI, the default clobber was "cc", and you need a way to allow at
> > least that, because saving and restoring flags is too expensive on x86.
>
> According to lore (Andi, I think), asm() always clobbers cc.
On x8
On Tue, 20 Mar 2007, Eric W. Biederman wrote:
>
> If that is the case. In the normal kernel what would
> the "the oops, we got an interrupt code do?"
> I assume it would leave interrupts disabled when it returns?
> Like we currently do with the delayed disable of normal interrupts?
Yeah, disab
On Tue, 20 Mar 2007, Andi Kleen wrote:
>
> No, me and Jan fixed all reported bugs as far as I know.
No you did not. You didn't fix the ones I reported. Which is why it got
removed, and will not get added back until there is another maintainer.
The ones I reported were all about trusting the s
On Tue, 20 Mar 2007, Andi Kleen wrote:
>
> The code never did that. In fact many of the problems we had initially
> especially came out of that -- the fallback code that would handle
> this case wasn't fully correct.
I don't keep my emails any more, but you *never* fixed the problems in
arch/*
On Tue, 20 Mar 2007, Andi Kleen wrote:
>
> So what is your proposed alternative to handle long backtraces?
> You didn't answer that question. Please do, I'm curious about your thoughts
> in this area.
the thing is, I'd rather see a long backtrace that is hard to decipher but
that *never* *eve
On Tue, 20 Mar 2007, Andi Kleen wrote:
> On Tue, Mar 20, 2007 at 11:49:39AM -0700, Linus Torvalds wrote:
> >
> > the thing is, I'd rather see a long backtrace that is hard to decipher but
> > that *never* *ever* causes any additional problems, over a pretty one.
>
On Tue, 20 Mar 2007, Andi Kleen wrote:
>
> Linus is worried about the unwinder crashing -- that wouldn't help with that.
And to make it clear: this is not a theoretical worry. It happened many
times over the months the unwinder was in.
It was supposed to help debugging, but it made bugs that
On Tue, 20 Mar 2007, Zachary Amsden wrote:
>
> void local_irq_restore(int enabled)
> {
>pda.intr_mask = enabled;
>/*
> * note there is a window here where softirqs are not processed by
> * the interrupt handler, but that is not a problem, since it will
> * get done here in th
On Tue, 20 Mar 2007, Zachary Amsden wrote:
>
> Actually, I was thinking the irq handlers would just not mess around with
> eflags on the stack, just call the chip to ack the interrupt and re-enable
> hardware interrupts when they left, since that is free anyway with the iret.
No can do. Think l
On Tue, 24 Jul 2007, Rusty Russell wrote:
>
> Indeed, no code changes, and I feel strongly that it should go into
> 2.6.23 because it's *fun*. And (as often complained) there's not
> enough poetry in the kernel.
There's a reason for that.
There once was a lad from Braidwood
W
On Mon, 22 Oct 2007, Rusty Russell wrote:
>
> First attempt at git, so please pull carefully. I've just put the
> three i386 boot changes in the repo for the moment. If this works I'll pile
> on the 44 lguest patches.
Well, it looked ok, but I had already merged the same patches throug
On Tue, 23 Oct 2007, Rusty Russell wrote:
>
> Well, with that out the way, and some scatterlist fixups, please pull from
>
> git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-lguest.git
Ok. However, please include a proper diffstat. And by proper, I mean:
git diff -M
On Thu, 25 Oct 2007, Rusty Russell wrote:
> >
> > git diff -M --stat --summary
>
> Thanks, that is much better. I was just happy to locate git diff in the 133
> git commands on my system; finding options 4, 8 and 22 was beyond my skill.
Hey, we give you the power. Actually realizing it al
On Sat, May 13, 2023 at 7:39 AM Thorsten Leemhuis wrote:
>
> Jumping in here, as I found another problem with that patch: it broke
> s2idle on my laptop when a qemu-kvm VM is running, as freezing user
> space processes now fails for me:
Hmm. kthreads have PF_NOFREEZE by default, which is probably
On Mon, May 15, 2023 at 7:23 AM Christian Brauner wrote:
>
> So I think we will be able to address (1) and (2) by making vhost tasks
> proper threads and blocking every signal except for SIGKILL and SIGSTOP
> and then having vhost handle get_signal() - as you mentioned - the same
> way io uring al
On Mon, May 15, 2023 at 8:52 AM Jens Axboe wrote:
>
> On 5/15/23 9:44?AM, Linus Torvalds wrote:
> >
> > So I think the patch should just look something like the attached.
> > Mike, can you test this on whatever vhost test-suite?
>
> Seems like that didn't g
On Mon, May 15, 2023 at 8:52 AM Jens Axboe wrote:
>
> Only potential downside is that it does make file references more
> expensive for other syscalls, since you now have a shared file table.
> But probably not something to worry about here?
Would the vhost user worker user processes ever be othe
On Mon, May 15, 2023 at 8:54 AM Linus Torvalds
wrote:
>
> Blush. I decided to build-test it, and then forgot to attach it. Here.
Btw, if this tests out good and we end up doing this, I think we
should also just rename that '.ignore_signals' bitfield to
'.block_signals'
On Mon, May 15, 2023 at 3:23 PM Mike Christie
wrote:
>
> The vhost layer really doesn't want any signals and wants to work like
> kthreads
> for that case. To make it really simple can we do something like this where it
> separates user and io worker behavior where the major diff is how they hand
On Wed, May 17, 2023 at 5:09 PM Mike Christie
wrote:
>
> + __set_current_state(TASK_RUNNING);
> + rc = get_signal(&ksig);
> + set_current_state(TASK_INTERRUPTIBLE);
> + return rc;
The games with current_state seem nonsensical.
What are they all about? get_signal() shouldn
On Thu, May 25, 2023 at 8:30 AM Eric W. Biederman wrote:
>
> Basically with no patches that is where Linus's kernel is.
>
> User complained about the new thread showing up in ps.
Well, not only that, but it actively broke existing workflows for
managing things. Showing up in 'ps' wasn't just some
On Sat, May 27, 2023 at 2:49 AM Eric W. Biederman wrote:
>
> The real sticky widget for me is how to handle one of these processes
> coredumping. It really looks like it will result in a reliable hang.
Well, if *that* is the main worry, I think that's trivial enough to deal with.
In particular,
On Sat, May 27, 2023 at 6:17 PM Eric W. Biederman wrote:
>
> It seems like a good approach for including in the -rc series.
> I think the change should look more like my change below.
I have no objections. My patch was a fairly "hack and slash" thing to
just disassociate the IO workers entirely f
On Thu, Jun 1, 2023 at 6:47 AM Christian Brauner wrote:
>
> @Mike, do you want to prepare an updated version of the temporary fix.
> If @Linus prefers to just apply it directly he can just grab it from the
> list rather than delaying it. Make sure to grab a Co-developed-by line
> on this, @Mike.
On Fri, Jun 2, 2023 at 1:59 PM Oleg Nesterov wrote:
>
> As I said from the very beginning, this code is fine on x86 because
> atomic ops are fully serialised on x86.
Yes. Other architectures require __smp_mb__{before,after}_atomic for
the bit setting ops to actually be memory barriers.
We *shoul
On Thu, Feb 21, 2013 at 4:34 PM, H. Peter Anvin wrote:
>
> This is a huge set of several partly interrelated (and concurrently
> developed) changes, which is why the branch history is messier than
> one would like.
>
> The *really* big items are two humonguous patchsets mostly developed
> by Yingh
[ Hmm. This email was marked as spam for me. I see no obvious reason
for it being marked as spam, but it happens.. ]
On Thu, Nov 11, 2021 at 12:52 PM Sudip Mukherjee
wrote:
>
> # first bad commit: [cd7f5ca33585918febe5e2f6dc090a21cfa775b0]
> drm/virtio: implement context init: add virtio_gpu_fenc
On Wed, Dec 22, 2021 at 9:19 PM Eric W. Biederman wrote:
>
> Instead of continuing to use the set_child_tid field of task_struct
> generalize the pf_io_worker field of task_struct and use it to hold
> the kthread pointer.
Well that patch certainly looks like a nice cleanup to me. Thanks.
On Fri, Mar 25, 2022 at 2:20 PM Steven Rostedt wrote:
>
> With the updates to change the size being passed in the splice from
> page_size to pipe_size, this never finished (it would copy around a meg or
> so). And stopped. When I killed the agent-fifo task on the guest, the guest
> hung hard.
Wit
On Tue, Nov 3, 2020 at 2:33 AM Thomas Gleixner wrote:
>
> +static inline void *kmap(struct page *page)
> +{
> + void *addr;
> +
> + might_sleep();
> + if (!PageHighMem(page))
> + addr = page_address(page);
> + else
> + addr = kmap_high(page);
> +
On Sun, Aug 29, 2021 at 8:53 AM Michael S. Tsirkin wrote:
>
> Donnu if it's too late - was on vacation and this only arrived
> Wednesday. Seems to be necessary to avoid introducing a regression
> in virtio-mem.
Heh. Not too late for 5.14, but too late in the sense that I had
picked this one up ma
On Thu, Sep 9, 2021 at 6:56 AM Michael S. Tsirkin wrote:
>
> NB: when merging this with
> b542e383d8c0 ("eventfd: Make signal recursion protection a task bit")
> from Linus' tree, replace eventfd_signal_count with
> eventfd_signal_allowed, and drop the export of eventfd_wake_count from
> ("eventfd
On Sat, Sep 11, 2021 at 5:11 PM Michael S. Tsirkin wrote:
>
> It's in the tag for_linus_v2 - the point of keeping for_linus
> intact was so anyone can compare these two.
Well, since I had already spent the effort in trying to figure things
out, I had merged the original branch.
I just didn't _li
On Sat, Sep 11, 2021 at 5:42 PM wrote:
>
> The pull request you sent on Sat, 11 Sep 2021 20:05:04 -0400:
>
> > https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git
> > tags/for_linus_v2
>
> has been merged into torvalds/linux.git:
> https://git.kernel.org/torvalds/c/a93a962669cdbe56bb0bc
On Thu, Dec 22, 2022 at 11:43 AM Michael S. Tsirkin wrote:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus
I see none of this in linux-next.
Linus
___
Virtualization mailing list
Virtualization@lists.li
On Fri, Dec 23, 2022 at 2:27 PM Michael S. Tsirkin wrote:
>
> They were all there, just not as these commits, as I squashed fixups to
> avoid bisect breakages with some configs. Did I do wrong?
I am literally looking at the next-20221214 state right now, doing
git log linus/master.. -- drive
On Fri, Dec 23, 2022 at 9:35 PM Michael S. Tsirkin wrote:
>
> They were in next-20221220 though.
So, perfect for the *next* merge window.
Do you understand what the word "next" means? We don't call it
"linux-this", do we?
This is not a new rule. Things are supposed to be ready *before* the
mer
On Thu, Feb 2, 2023 at 3:25 PM Mike Christie
wrote:
>
> struct kernel_clone_args {
> u64 flags;
> + u32 worker_flags;
> int __user *pidfd;
> int __user *child_tid;
> int __user *parent_tid;
Minor nit: please put this next to "exit_signal".
As it is, you've
On Thu, Feb 2, 2023 at 3:25 PM Mike Christie
wrote:
>
> - retval = copy_files(clone_flags, p);
> + retval = copy_files(clone_flags, p,
> + args->worker_flags & USER_WORKER_NO_FILES);
Just to hit the previous email comment home, adding just another
bitfield ca
On Thu, Feb 2, 2023 at 3:25 PM Mike Christie
wrote:
>
> + if (args->worker_flags & USER_WORKER_SIG_IGN)
> + ignore_signals(p);
Same comment as for the other case.
There are real reasons to avoid bitfields:
- you can't pass addresses to them around
- it's easier to read or
On Thu, Feb 2, 2023 at 3:25 PM Mike Christie
wrote:
>
> +/**
> + * vhost_task_start - start a vhost_task created with vhost_task_create
> + * @vtsk: vhost_task to wake up
> + * @namefmt: printf-style format string for the thread name
> + */
> +void vhost_task_start(struct vhost_task *vtsk, const c
On Wed, Feb 22, 2023 at 11:06 PM Michael S. Tsirkin wrote:
>
> Did I muck this one up? Pls let me know and maybe I can fix it up
> before the merge window closes.
No much-ups, I've just been merging other things, and came back to
architectures updates and virtualization now, so it's next in my
q
On Fri, Mar 10, 2023 at 2:04 PM Mike Christie
wrote:
>
> The following patches were made over Linus's tree and apply over next. They
> allow the vhost layer to use copy_process instead of using
> workqueue_structs to create worker threads for VM's devices.
Ok, all these patches looked fine to me
On Fri, May 5, 2023 at 6:40 AM Nicolas Dichtel
wrote:
>
> Is this an intended behavior?
> This breaks some of our scripts.
It doesn't just break your scripts (which counts as a regression), I
think it's really wrong.
The worker threads should show up as threads of the thing that started
them, no
On Fri, May 5, 2023 at 3:38 PM Mike Christie
wrote:
>
> If it's ok to change the behavior of "ps -u root", then we can do this patch:
I think this is the right thing to do.
Making the user worker threads show up as threads with the vhost
process as the parent really seems like a much better mode
On Tue, May 10, 2022 at 5:24 AM Michael S. Tsirkin wrote:
>
> A last minute fixup of the transitional ID numbers.
> Important to get these right - if users start to depend on the
> wrong ones they are very hard to fix.
Hmm. I've pulled this, but those numbers aren't exactly "new".
They've been t
On Tue, May 10, 2022 at 4:12 PM Nathan Chancellor wrote:
>
> For what it's worth, as someone who is frequently tracking down and
> reporting issues, a link to the mailing list post in the commit message
> makes it much easier to get these reports into the right hands, as the
> original posting is
On Wed, May 11, 2022 at 3:12 AM Michael Ellerman wrote:
>
> Which I read as you endorsing Link: tags :)
I absolutely adore "Link:" tags. They've been great.
But they've been great for links that are *usedful*.
They are wonderful when they link to the original problem.
They are *really* wonderf
On Thu, May 12, 2022 at 6:30 AM Michael Ellerman wrote:
>
> Links to other random places don't serve that function.
What "function"?
This is my argument. Those Link: things need to have a *reason*.
Saying "they are a change ID" is not a reason. That's just a random
word-salad. You need to have
On Thu, May 12, 2022 at 10:10 AM Linus Torvalds
wrote:
>
> And most definitely not just random data that can be trivially
> auto-generated after-the-fact.
Put another way: when people asked for change ID's and I said "we have
links", I by no means meant that "you
On Fri, Aug 5, 2022 at 11:11 AM Will Deacon wrote:
>
> [tl;dr a change from ~18 months ago breaks Android userspace and I don't
> know what to do about it]
Augh.
I had hoped that android being "closer" to upstream would have meant
that somebody actually tests android with upstream kernels. Peop
On Mon, Aug 15, 2022 at 3:00 PM Michael S. Tsirkin wrote:
>
> But the benefit is unclear in any case, so let's revert for now.
Should I take this patch series directly, or will you be sending a
pull request (preferred)?
Linus
___
Virtualiz
On Tue, Aug 16, 2022 at 11:47 PM Xuan Zhuo wrote:
>
> + BUG_ON(num != virtqueue_get_vring_size(vq));
> +
Please, no more BUG_ON.
Add a WARN_ON_ONCE() and return an error.
Linus
___
Virtualization mailing list
Virtualization@lists.lin
On Wed, Oct 12, 2022 at 8:51 AM Michael S. Tsirkin wrote:
>
> Are you sure?
MichaelE is right.
This is just bogus historical garbage:
> arch/arm/include/asm/irq.h:#ifndef NO_IRQ
> arch/arm/include/asm/irq.h:#define NO_IRQ ((unsigned int)(-1))
that I've tried to get rid of for years, but
On Wed, Oct 12, 2022 at 3:04 PM Michael S. Tsirkin wrote:
>
> This seems to happen because pci_dev->pin is not populated in
> pci_assign_irq().
Yeah, I have to say, I wonder why it was looking at pci_dev->pin in
the first place.
I was curious, as this is fairly odd.
Of course, I only did a fair
On Wed, Oct 12, 2022 at 11:29 PM Arnd Bergmann wrote:
>
> On Thu, Oct 13, 2022, at 12:08 AM, Michael S. Tsirkin wrote:
> >
> > Do these two boxes even have pci?
>
> Footbridge/netwinder has PCI and PC-style ISA on-board devices
> (floppy, ps2 mouse/keyboard, parport, soundblaster, ...), RiscPC
> h
On Feb 28, 2014 1:30 AM, "Peter Zijlstra" wrote:
>
> At low contention the cmpxchg won't have to be retried (much) so using
> it won't be a problem and you get to have arbitrary atomic ops.
Peter, the difference between an atomic op and *no* atomic op is huge.
And Waiman posted numbers for the o
On Wed, May 28, 2014 at 2:55 PM, Rik van Riel wrote:
>
> Or maybe cmpxchg is cheap once you already own the cache line
> exclusively?
A locked cmpxchg ends up being anything between ~15-50 cycles
depending on microarchitecture if things are already exclusively in
the cache (with the P4 being an o
On Wed, Sep 10, 2014 at 5:56 PM, Rusty Russell wrote:
>
> Probably won't read mail. Linus, I'll have pull requests early
> next week; if there's anything needed I'm sure Michael Tsirkin can
> handle it.
So according to "normal timing", I would do the 3.17 release about
three weeks from n
On Fri, Feb 6, 2015 at 7:20 AM, Sasha Levin wrote:
>
> Can we modify it slightly to avoid potentially accessing invalid memory:
So I think there's a race with that.
And I'll warn you: the kernel does do speculative reads of memory that
might be invalid, not just in places like this. See the comm
On Fri, Feb 6, 2015 at 6:49 AM, Raghavendra K T
wrote:
> Paravirt spinlock clears slowpath flag after doing unlock.
[ fix edited out ]
So I'm not going to be applying this for 3.19, because it's much too
late and the patch is too scary. Plus the bug probably effectively
never shows up in real lif
On Mon, Feb 9, 2015 at 4:02 AM, Peter Zijlstra wrote:
> On Mon, Feb 09, 2015 at 03:04:22PM +0530, Raghavendra K T wrote:
>> So we have 3 choices,
>> 1. xadd
>> 2. continue with current approach.
>> 3. a read before unlock and also after that.
>
> For the truly paranoid we have probe_kernel_address
On Feb 11, 2015 3:15 PM, "Jeremy Fitzhardinge" wrote:
>
> Right now it needs to be a locked operation to prevent read-reordering.
> x86 memory ordering rules state that all writes are seen in a globally
> consistent order, and are globally ordered wrt reads *on the same
> addresses*, but reads to
On Tue, Jan 8, 2019 at 8:31 PM Michael S. Tsirkin wrote:
>
> Linus, given that you just changed all users of access_ok anyway, do
> you still think that the access_ok() conversion to return a speculation
> sanitized pointer or NULL is too big a conversion?
I didn't actually change a single access
On Fri, Jul 26, 2019 at 8:26 AM syzbot
wrote:
>
> syzbot has bisected this bug to:
>
> commit 0ecfebd2b52404ae0c54a878c872bb93363ada36
> Author: Linus Torvalds
> Date: Sun Jul 7 22:41:56 2019 +
>
> Linux 5.2
That seems very unlikely. That commit li
On Mon, Apr 9, 2018 at 6:10 AM, Stefan Hajnoczi wrote:
> @@ -1246,7 +1246,7 @@ int vhost_vq_access_ok(struct vhost_virtqueue *vq)
> {
> int ret = vq_log_access_ok(vq, vq->log_base);
>
> - if (ret || vq->iotlb)
> + if (!ret || vq->iotlb)
> return ret;
That logi
On Mon, Jun 11, 2018 at 9:24 AM Michael S. Tsirkin wrote:
>
> virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT
Is this really a good idea?
Plus it seems entirely broken.
The report_pfn_range() callback is done under the zone lock, but
virtio_balloon_send_free_pages() (which is the only cal
On Mon, Jun 11, 2018 at 11:32 AM Linus Torvalds
wrote:
>
> So now we apparently do a GFP_KERNEL allocation insider the mm zone
> lock, which is broken on just _so_ many levels.
Oh, I see the comment about how it doesn't actually do an allocation
at all because it's a singl
On Mon, Jun 11, 2018 at 6:36 PM Michael S. Tsirkin wrote:
>
> Maybe it will help to have GFP_NONE which will make any allocation
> fail if attempted. Linus, would this address your comment?
It would definitely have helped me initially overlook that call chain.
But then when I started looking at
On Fri, Jun 15, 2018 at 2:08 PM Wei Wang wrote:
>
> This patch adds a function to get free pages blocks from a free page
> list. The obtained free page blocks are hints about free pages, because
> there is no guarantee that they are still on the free page list after
> the function returns.
Ack. T
[ Sorry for slow reply, my travels have made a mess of my inbox ]
On Mon, Jun 25, 2018 at 6:55 PM Michael S. Tsirkin wrote:
>
> Linus, do you think it would be ok to have get_from_free_page_list
> actually pop entries from the free list and use them as the buffer
> to store PAs?
Honestly, what I
NAK.
On Tue, Jul 10, 2018 at 2:56 AM Wei Wang wrote:
>
> +
> + buf_page = list_first_entry_or_null(pages, struct page, lru);
> + if (!buf_page)
> + return -EINVAL;
> + buf = (__le64 *)page_address(buf_page);
Stop this garbage.
Why the hell would you pass in some
On Tue, Jul 10, 2018 at 6:24 PM Wei Wang wrote:
>
> We only get addresses of the "MAX_ORDER-1" blocks into the array. The
> max size of the array that could be allocated by kmalloc is
> KMALLOC_MAX_SIZE (i.e. 4MB on x86). With that max array, we could load
> "4MB / sizeof(u64)" addresses of "MAX_O
On Wed, Jul 11, 2018 at 2:21 AM Michal Hocko wrote:
>
> We already have an interface for that. alloc_pages(GFP_NOWAIT, MAX_ORDER -1).
> So why do we need any array based interface?
That was actually my original argument in the original thread - that
the only new interface people might want is one
On Wed, Jul 11, 2018 at 7:17 PM Wei Wang wrote:
>
> Would it be better to remove __GFP_THISNODE? We actually want to get all
> the guest free pages (from all the nodes).
Maybe. Or maybe it would be better to have the memory balloon logic be
per-node? Maybe you don't want to remove too much memory
On Thu, Nov 1, 2018 at 2:19 PM Michael S. Tsirkin wrote:
>
> virtio, vhost: fixes, tweaks
Pulled.
Linus
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virt
On Thu, Nov 1, 2018 at 4:00 PM Kees Cook wrote:
>
> + memset(&rsp, 0, sizeof(rsp));
> + rsp.response = VIRTIO_SCSI_S_FUNCTION_REJECTED;
> + resp = vq->iov[out].iov_base;
> + ret = __copy_to_user(resp, &rsp, sizeof(rsp));
>
> Is it actually safe to trust that iov_base has pa
On Fri, Nov 2, 2018 at 6:04 AM Michael S. Tsirkin wrote:
>
> I've tried making access_ok mask the parameter it gets.
PLEASE don't do this.
Just use "copy_to/from_user()".
We have had lots of bugs because code bitrots.
And no, the access_ok() checks aren't expensive, not even in a loop.
They *u
On Fri, Nov 2, 2018 at 9:59 AM Michael S. Tsirkin wrote:
>
> Just for completeness I'd like to point out for vhost the copies are
> done from the kernel thread. So yes we can switch to copy_to/from_user
> but for e.g. 32-bit userspace running on top of a 64 bit kernel it is
> IIUC not sufficient
On Fri, Nov 2, 2018 at 10:10 AM Linus Torvalds
wrote:
>
> Don't you take over the VM with "use_mm()" when you do the copies? So
> yes, it's a kernel thread, but it has a user VM, and though that
> should have the user limits.
Oooh. *Just* as I sent this, I realize
On Fri, Nov 2, 2018 at 10:21 AM Michael S. Tsirkin wrote:
>
> it seems that it depends on current not on the active mm.
Yes, see my other suggestion to just fix "use_mm()" to update the address range.
Would you mind testing that?
Because that would seem to be the *much* less error-prone model..
On Wed, Apr 29, 2015 at 11:11 AM, Peter Zijlstra wrote:
> On Fri, Apr 24, 2015 at 02:56:42PM -0400, Waiman Long wrote:
>> In the pv_scan_next() function, the slow cmpxchg atomic operation is
>> performed even if the other CPU is not even close to being halted. This
>> extra cmpxchg can harm slowpa
On Wed, Jul 1, 2015 at 2:31 AM, Michael S. Tsirkin wrote:
> virtio/vhost: cross endian support
Ugh. Does this really have to be dynamic?
Can't virtio do the sane thing, and just use a _fixed_ endianness?
Doing a unconditional byte swap is faster and simpler than the crazy
conditionals. That's t
On Wed, Jul 1, 2015 at 12:02 PM, Linus Torvalds
wrote:
>
> Doing a unconditional byte swap is faster and simpler than the crazy
> conditionals.
Unconditional endianness not only makes for simpler and faster code,
it also ends up being easier to debug and add things like type
annota
On Fri, Jul 3, 2015 at 12:59 AM, Michael S. Tsirkin wrote:
>
> Linus, could you please clarify whether making the
> feature depend on the cross-endian guest support
> would address your comment, and whether you think
> this can be merged as is, and the dependency added
> after -rc1?
I'll take it.
1 - 100 of 134 matches
Mail list logo
