Re: [PATCH 3/3] fork, vhost: Use CLONE_THREAD to fix freezer/ps regression

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

Re: [RFC PATCH 0/8] vhost_tasks: Use CLONE_THREAD/SIGHAND

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.

Re: [PATCH 3/3] fork, vhost: Use CLONE_THREAD to fix freezer/ps regression

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

Re: [PATCH 3/3] fork, vhost: Use CLONE_THREAD to fix freezer/ps regression

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

Re: [PATCH 3/3] fork, vhost: Use CLONE_THREAD to fix freezer/ps regression

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

Re: [RFC PATCH 2/8] vhost/vhost_task: Hook vhost layer into signal handler

On Wed, May 17, 2023 at 5:09 PM Mike Christie wrote: > > + __set_current_state(TASK_RUNNING); > + rc = get_signal(); > + set_current_state(TASK_INTERRUPTIBLE); > + return rc; The games with current_state seem nonsensical. What are they all about? get_signal() shouldn't

Re: [PATCH v11 8/8] vhost: use vhost_tasks for worker threads

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

Re: [PATCH v11 8/8] vhost: use vhost_tasks for worker threads

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' to actually matc

Re: [PATCH v11 8/8] vhost: use vhost_tasks for worker threads

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

Re: [PATCH v11 8/8] vhost: use vhost_tasks for worker threads

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 get

Re: [PATCH v11 8/8] vhost: use vhost_tasks for worker threads

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

Re: [PATCH v11 8/8] vhost: use vhost_tasks for worker threads

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

Re: [PATCH v11 8/8] vhost: use vhost_tasks for worker threads

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

Re: [PATCH v11 8/8] vhost: use vhost_tasks for worker threads

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,

Re: [PATCH 00/11] Use copy_process in vhost layer

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

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

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

Re: [PATCH v11 6/8] vhost_task: Allow vhost layer to use copy_process

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

Re: [PATCH v11 4/8] fork: Add USER_WORKER flag to ignore signals

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

Re: [PATCH v11 3/8] fork: add USER_WORKER flag to not dup/clone files

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

Re: [PATCH v11 1/8] fork: Make IO worker options flag based

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

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

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

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

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: [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 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: 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: [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: 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: [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 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 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: 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 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: [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: [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: [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 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] 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: [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: [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: 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: [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: 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: 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: [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: 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: __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: [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 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 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 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: [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: [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 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 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

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 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 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 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: [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: [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: [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] 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] 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] 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: [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, 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: [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: [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] 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: [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: 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: [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: [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: [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: [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: [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: [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] 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: 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: [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: [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: [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: [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: [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

  1   2   >