Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable

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

Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable

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.

Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable

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. Well it causes additional problems

Re: [patch 13/26] Xen-paravirt_ops: Consistently wrap paravirt ops callsites to make them patchable

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 the outer

Re: [PATCH 1/7] lguest: documentation pt I: Preparation

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 With

Re: [git pull] lguest: paravirt boot code

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 through

Re: [git pull] lguest: paravirt boot code

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

Re: [git pull] lguest: paravirt boot code

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 all and

Re: [PATCH 1 of 4] mm: add a ptep_modify_prot transaction abstraction

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 [EMAIL PROTECTED] for what it's worth

Re: [PATCH 1 of 4] mm: add a ptep_modify_prot transaction abstraction

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

Re: [PATCH 1 of 4] mm: add a ptep_modify_prot transaction abstraction

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 that,

Re: [PATCH 1 of 4] mm: add a ptep_modify_prot transaction abstraction

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 reason for using the byte versions

Re: [PATCH 1 of 4] mm: add a ptep_modify_prot transaction abstraction

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

Re: [PATCH 1 of 4] mm: add a ptep_modify_prot transaction abstraction

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 if

Re: [PATCH 1 of 4] mm: add a ptep_modify_prot transaction abstraction

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 ___

Re: [PATCH] virtio_balloon: fix towards_target when deflating balloon

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. - return

Re: [PATCH] virtio_balloon: fix towards_target when deflating balloon

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: Mon Mar 17

Re: [PATCH] virtio-rng: Remove false BUG for spurious callbacks

On Thu, 23 Apr 2009, Rusty Russell wrote: From: Christian Borntraeger borntrae...@de.ibm.com 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.

Re: [PULL] virtio fixes

On Mon, 19 Oct 2009, Rusty Russell wrote: ssh://master.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus.git master Already up-to-date.. Forgot to push? Linus ___ Virtualization mailing list

Re: [PATCH] virtio: update MAINTAINERS

On Mon, Jan 31, 2011 at 4:16 PM, Rusty Russell ru...@rustcorp.com.au wrote: Patches should keep coming through Rusty but it helps if I'm Cc'd as well. This commit log makes no sense as being yours. It's clearly frm Michael, but you're missing that vital piece of information, ie the From:

Re: [RESENDx2] [PULL] virtio: fix barriers for virtio-mmio

On Thu, Dec 22, 2011 at 9:16 PM, Rusty Russell ru...@rustcorp.com.au wrote: This one as a signed tag on github, in case the inline patch was the reason you dropped this. No, and please why do you make your tag-names be your email address? That's just odd. It seems to be related to some broken

Re: [RESENDx2] [PULL] virtio: fix barriers for virtio-mmio

On Fri, Dec 23, 2011 at 1:31 AM, Linus Torvalds torva...@linux-foundation.org wrote: So the whole thing looks confused. There's never any reason to actually use the expensive sfence/rfences at all. Afaik you still just want smp_*mb() for all cases. But note that I haven't thought deeply about

Re: [PULL] virtio and lguest

On Wed, Jan 11, 2012 at 9:22 PM, Rusty Russell ru...@rustcorp.com.au wrote: Amit Shah (12):      virtio: pci: switch to new PM API Hmm. Afaik, this is broken, or at least not complete. Sure, it switches to the new PM API, but it still does the PCI ops itself. It should not need to - the PCI

Re: [PATCH RFC V6 2/11] x86/ticketlock: don't inline _spin_unlock when using paravirt spinlocks

On Wed, Mar 21, 2012 at 3:21 AM, Raghavendra K T raghavendra...@linux.vnet.ibm.com wrote: From: Jeremy Fitzhardinge jeremy.fitzhardi...@citrix.com The code size expands somewhat, and its probably better to just call a function rather than inline it. Signed-off-by: Jeremy Fitzhardinge

Re: [GIT PULL] x86/mm changes for v3.9-rc1

On Thu, Feb 21, 2013 at 4:34 PM, H. Peter Anvin h...@linux.intel.com 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

Re: [RFC] Implement Batched (group) ticket lock

On Wed, May 28, 2014 at 2:55 PM, Rik van Riel r...@redhat.com 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

Re: Rusty away 18th September -- 11th October

On Wed, Sep 10, 2014 at 5:56 PM, Rusty Russell ru...@rustcorp.com.au 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

Re: [PATCH] x86 spinlock: Fix memory corruption on completing completions

On Fri, Feb 6, 2015 at 7:20 AM, Sasha Levin sasha.le...@oracle.com 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

Re: [PATCH] x86 spinlock: Fix memory corruption on completing completions

On Fri, Feb 6, 2015 at 6:49 AM, Raghavendra K T raghavendra...@linux.vnet.ibm.com 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

Re: [PATCH] x86 spinlock: Fix memory corruption on completing completions

On Feb 11, 2015 3:15 PM, Jeremy Fitzhardinge jer...@goop.org 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

Re: [PATCH] x86 spinlock: Fix memory corruption on completing completions

On Mon, Feb 9, 2015 at 4:02 AM, Peter Zijlstra pet...@infradead.org 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

Re: [PATCH v16 13/14] pvqspinlock: Improve slowpath performance by avoiding cmpxchg

On Wed, Apr 29, 2015 at 11:11 AM, Peter Zijlstra pet...@infradead.org 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

Re: [PULL] virtio/vhost: cross endian support

On Wed, Jul 1, 2015 at 2:31 AM, Michael S. Tsirkin m...@redhat.com 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

Re: [PULL] virtio/vhost: cross endian support

On Wed, Jul 1, 2015 at 12:02 PM, Linus Torvalds torva...@linux-foundation.org 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

Re: [PULL] virtio/vhost: cross endian support

On Fri, Jul 3, 2015 at 12:59 AM, Michael S. Tsirkin m...@redhat.com 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?

Re: [PATCH 3/4] x86,asm: Re-work smp_store_mb()

On Tue, Jan 12, 2016 at 9:45 AM, Michael S. Tsirkin wrote: > > By the way, the comment in barrier.h says: > > /* > * Some non-Intel clones support out of order store. wmb() ceases to be > * a nop for these. > */ > > and while the 1st sentence may well be true, if you have > an

Re: [PATCH 3/4] x86,asm: Re-work smp_store_mb()

On Tue, Jan 12, 2016 at 12:59 PM, Andy Lutomirski wrote: > > Here's an article with numbers: > > http://shipilev.net/blog/2014/on-the-fence-with-dependencies/ Well, that's with the busy loop and one set of code generation. It doesn't show the "oops, deeper stack isn't even

Re: [PATCH 3/4] x86,asm: Re-work smp_store_mb()

On Tue, Jan 12, 2016 at 12:30 PM, Andy Lutomirski wrote: > > I recall reading somewhere that lock addl $0, 32(%rsp) or so (maybe even 64) > was better because it avoided stomping on very-likely-to-be-hot write > buffers. I suspect it could go either way. You want a small

Re: [PATCH 3/4] x86,asm: Re-work smp_store_mb()

On Tue, Jan 12, 2016 at 2:55 PM, H. Peter Anvin wrote: > > Be careful with this: if it only shows up in a microbenchmark, we may > introduce a hard-to-debug regression for no real benefit. So I can pretty much guarantee that it shouldn't regress from a correctness angle, since we

Re: [PATCH 3/4] x86,asm: Re-work smp_store_mb()

On Tue, Jan 12, 2016 at 5:57 AM, Michael S. Tsirkin wrote: > #ifdef xchgrz > /* same as xchg but poking at gcc red zone */ > #define barrier() do { int ret; asm volatile ("xchgl %0, -4(%%" SP ");": > "=r"(ret) :: "memory", "cc"); } while (0) > #endif That's not safe in general.

Re: [PATCH 3/4] x86,asm: Re-work smp_store_mb()

On Wed, Jan 13, 2016 at 8:42 AM, Michael S. Tsirkin wrote: > > Oh, I think this means we need a "cc" clobber. It's probably a good idea to add one. Historically, gcc doesn't need one on x86, and always considers flags clobbered. We are probably missing the cc clobber in a *lot*

Re: virtio pull for 4.5 (was Re: [PULL] virtio: barrier rework+fixes)

On Mon, Jan 18, 2016 at 5:21 AM, Michael S. Tsirkin wrote: > Hi Linus, > Just making sure nothing's wrong with this pull request. > If there's an issue, pls let me know! It was just pulled because I wasn't 100% sure I wanted the extra indirection. Oh well, pulled now. One

Re: [PULL] virtio: fixes, tests

On Wed, Jan 27, 2016 at 2:15 PM, Michael S. Tsirkin wrote: >> >> Anyway, pulled. Just curious about how that thing happened. > > That's because apparently diffstat obeys orderfile rules: Ugh. I guess that makes sense, but it's still very annoying for something like a pull

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Jan 26, 2016 23:51, "Peter Zijlstra" wrote: > > So for a moment it looked like MIPS wanted to equal or surpass Alpha in > this respect. If there is an architecture that I'd expect to try to take the "sucks more" crown, MIPS would be it. They've already done the "worst

Re: [PATCH v4 5/5] x86: drop mfence in favor of lock+addl

On Wed, Jan 27, 2016 at 7:10 AM, Michael S. Tsirkin wrote: > > -#define __smp_mb() mb() > +#define __smp_mb() asm volatile("lock; addl $0,-4(%%esp)" ::: "memory", > "cc") So this doesn't look right for x86-64. Using %esp rather than %rsp. How did that even work for you?

Re: [PULL] virtio: fixes, tests

On Wed, Jan 27, 2016 at 11:12 AM, Michael S. Tsirkin wrote: > > arch/sh/include/asm/barrier.h| 1 - > tools/virtio/asm/barrier.h | 22 +- > tools/virtio/linux/compiler.h| 9 + > tools/virtio/linux/kernel.h | 1 + >

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Tue, Jan 26, 2016 at 9:22 AM, Peter Zijlstra wrote: > > This is distinct from: That may be distinct, but: > struct foo *x = READ_ONCE(*ptr); > smp_read_barrier_depends(); > x->bar = 5; This case is complete BS. Stop perpetuating it. I already

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

On Tue, Jan 26, 2016 at 3:29 PM, Paul E. McKenney wrote: > > No trailing data-dependent read, so agreed, no smp_read_barrier_depends() > needed. That said, I believe that we should encourage rcu_dereference*() > or lockless_dereference() instead of READ_ONCE() for

Re: [PULL] vhost: cleanups and fixes

On Mon, Jan 23, 2017 at 7:05 AM, Michael S. Tsirkin wrote: > > virtio, vhost: fixes, cleanups Was there a reason why you sent this twice? Or was this *supposed* to be the ARM DMA fix pull request? Because it wasn't. Linus

Re: [PATCH] x86/paravirt: Do not trace _paravirt_ident_*() functions

On Fri, Sep 2, 2016 at 7:46 AM, Steven Rostedt wrote: > > Can someone please pull this in. And mark it for stable, it goes > probably as far back as 2.6.32. Applied. Linus ___ Virtualization mailing list

Re: [PATCH 0/3] virtio/vringh: kill off ACCESS_ONCE()

On Fri, Nov 25, 2016 at 9:28 AM, Dmitry Vyukov wrote: On Fri, Nov 25, 2016 at 5:17 PM, Peter Zijlstra wrote: >> >> IE, they are strictly stronger than {READ,WRITE}_ONCE(). No, they are strictly bullshit. Stop this idiocy. We went through this once

Re: [PATCH 0/3] virtio/vringh: kill off ACCESS_ONCE()

On Fri, Nov 25, 2016 at 10:07 AM, Mark Rutland <mark.rutl...@arm.com> wrote: > On Fri, Nov 25, 2016 at 09:52:50AM -0800, Linus Torvalds wrote: >> READ/WRITE_ONCE() are atomic *WHEN*THAT*IS*POSSIBLE*. > >> But sometimes it's not going to be atomic. > > That's the prob

Re: [PULL] virtio, vhost: new device, fixes, speedups

On Thu, Dec 15, 2016 at 3:05 PM, Michael S. Tsirkin wrote: > > git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus Pulled, but I wonder... > Documentation/translations/zh_CN/sparse.txt| 7 +- > arch/arm/plat-samsung/include/plat/gpio-cfg.h

Re: [PULL] virtio, vhost: new device, fixes, speedups

On Fri, Dec 16, 2016 at 9:09 AM, Michael S. Tsirkin wrote: > > Oh, that's because I set orderfile globally rather than > just for the qemu project which wants it. > Fixed, sorry about that. That explains it. I should have remembered, I think this came up once before with

Re: [PULL] virtio: last minute bugfix

On Tue, Nov 7, 2017 at 7:28 AM, Michael S. Tsirkin wrote: > We had a lot of trouble agreeing on a fix, but apparently there's > finally a consensus. This is big and doesn't have a sign-off on the commit itself, even if you then do it in the tag. That's not how this is all

Re: [PULL] virtio: last minute bugfix

On Tue, Nov 7, 2017 at 9:23 AM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > I guess I'll take it, but please don't do things like this to me. Oh no I wont. The garbage you sent me doesn't even compile cleanly, and is utter shite. Not acceptable for last-minute bugfixes

Re: [PULL] vhost: cleanups and fixes

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

Re: [PATCH v33 1/4] mm: add a function to get free page blocks

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.

Re: [PULL] vhost: cleanups and fixes

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

Re: [PULL] vhost: cleanups and fixes

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 single-entry.

Re: [PATCH v33 1/4] mm: add a function to get free page blocks

[ 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

Re: [PATCH v35 1/5] mm: support to get hints of free page blocks

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

Re: [PATCH v35 1/5] mm: support to get hints of free page blocks

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

Re: [PATCH v35 1/5] mm: support to get hints of free page blocks

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

Re: [PATCH v35 1/5] mm: support to get hints of free page blocks

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

Re: [PATCH] vhost: fix vhost_vq_access_ok() log check

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) >

Re: [PULL] vhost: cleanups and fixes

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

Re: [PULL] vhost: cleanups and fixes

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 realized that &qu

Re: [PULL] vhost: cleanups and fixes

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

Re: [PULL] vhost: cleanups and fixes

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

Re: [PULL] vhost: cleanups and fixes

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

Re: [PULL] vhost: cleanups and fixes

On Thu, Nov 1, 2018 at 4:00 PM Kees Cook wrote: > > + memset(, 0, sizeof(rsp)); > + rsp.response = VIRTIO_SCSI_S_FUNCTION_REJECTED; > + resp = vq->iov[out].iov_base; > + ret = __copy_to_user(resp, , sizeof(rsp)); > > Is it actually safe to trust that iov_base has passed an

Re: __get_user slower than get_user (was Re: [RFC PATCH V3 0/5] Hi:)

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

Re: INFO: rcu detected stall in vhost_worker

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 commi

Re: [PULL] vhost: cleanups and fixes

On Sun, Feb 9, 2020 at 10:03 PM Michael S. Tsirkin wrote: > > https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus Hmm? Pull request re-send? This already got merged on Friday as commit e0f121c5cc2c, as far as I can tell. It looks like the pr-tracker-bot didn't reply

Re: [GIT PULL] vhost: cleanups and fixes

On Tue, Apr 14, 2020 at 9:36 AM Michael S. Tsirkin wrote: > > virtio: fixes, cleanups Looking at this, about 75% of it looks like it should have come in during the merge window, not now. Linus ___ Virtualization mailing list

Re: [GIT PULL] vhost: cleanups and fixes

On Thu, Apr 16, 2020 at 5:20 AM Michael S. Tsirkin wrote: > Well it's all just fallout from What? No. Half of it seems to be the moving of "struct vring" around to other headers and stuff. And then that is done very confusingly too, using two different structures both called "struct vring". No

Re: [GIT PULL] vhost: fixes, vdpa

On Mon, Apr 6, 2020 at 2:11 PM Michael S. Tsirkin wrote: > > The new vdpa subsystem with two first drivers. So this one is really annoying to configure. First it asks for vDPA driver for virtio devices (VIRTIO_VDPA) support. If you say 'n', it then asks *again* for VDPA drivers (VDPA_MENU).

Re: [GIT PULL] virtio: features, fixes

On Tue, Jun 9, 2020 at 9:45 PM Michael S. Tsirkin wrote: > > I also upgraded the machine I used to sign > the tag (didn't change the key) - hope the signature is still ok. If not > pls let me know! All looks normal as far as I can tell, Linus

Re: [patch V3 22/37] highmem: High implementation details and document API

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); >

Re: [GIT PULL] virtio: a last minute fix

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

Re: [GIT PULL] virtio,vdpa,vhost: features, fixes

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

Re: [GIT PULL V2] virtio,vdpa,vhost: features, fixes

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: >

Re: [GIT PULL] virtio,vdpa,vhost: features, fixes

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 >

Re: [PATCH] kthread: Generalize pf_io_worker so it can point to struct kthread

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.

Re: regression with mainline kernel

[ 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

Re: [PATCH] virtio: Workaround fix for hard hang on guest using fifos

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.

Re: [GIT PULL] virtio: last minute fixup

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

Re: [GIT PULL] virtio: last minute fixup

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 can j

Re: [GIT PULL] virtio: last minute fixup

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

Re: [GIT PULL] virtio: last minute fixup

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

Re: [GIT PULL] virtio: last minute fixup

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*

Re: [GIT PULL] virtio: fixes, features

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

Re: [PATCH] virtio_pci: use irq to detect interrupt support

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

Re: [GIT PULL] virtio: fixes, features

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 >

Re: IOTLB support for vhost/vsock breaks crosvm on Android

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.

Re: [PATCH v3 0/5] virtio: drop sizing vqs during init

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 ___

Re: upstream kernel crashes

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

Re: [GIT PULL] virtio,vhost,vdpa: features, fixes, cleanups

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.. --

Re: [GIT PULL] virtio,vhost,vdpa: features, fixes, cleanups

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

  1   2   >