On Tue, 7 Jul 2009, Peter Zijlstra wrote:
>
> Another issue, at about >=256 vmas we'll overflow the preempt count. So
> disabling lockdep will only 'fix' this for a short while, until you've
> bloated beyond that ;-)
We would?
I don't think so. Sure, we'd "overflow" into the softirq bits, but
On Mon, Jul 25, 2011 at 10:27 AM, Pekka Enberg wrote:
>
> Here's the same pull request with a small fixlet for a compile-time problem
> reported by Ingo Molnar.
Ok, having thought this over, I'm going to skip the KVM tool merge
this merge window. You'll need to convince me it's really worthwhile,
On Wed, Aug 10, 2011 at 11:40 PM, David Gibson
wrote:
>
> This patch, therefore, stores a pointer to the inode instead of the
> address_space in the page private data for hugepages. More
> importantly it correctly adjusts the reference count on the inodes
> when they're added to the page private
Missing diffstat. Please please *please* always make sure you have
diffstats, because I really want to know that what I'm pulling matches
what you *think* that I'm pulling. And the diffstat isn't just for me
- it hopefully really makes you look at the whole "this is what I'm
asking Linus to pull" t
On Fri, Jul 13, 2012 at 8:45 AM, Linus Torvalds
wrote:
> Missing diffstat. Please please *please* always make sure you have
> diffstats, because I really want to know that what I'm pulling matches
> what you *think* that I'm pulling. And the diffstat isn't just for me
On Fri, Jul 13, 2012 at 11:28 AM, Thomas Gleixner wrote:
>
> We already discussed to let the irq chip (in this case MSI) tell the
> core that it does not need the extra oneshot handling. That way the
> code which requests an threaded irq with the NULL primary handler
> works on both MSI and normal
Ok, this caused conflicts with the s390 and ppc trees. I think I fixed
them correctly, but the respective arch people really should take a
look.
Linus
On Mon, Jul 23, 2012 at 2:12 AM, Avi Kivity wrote:
> Linus, please pull from the repo and tag at:
>
> git://git.kernel.org/pu
On Mon, Jul 30, 2012 at 4:17 PM, Alex Williamson
wrote:
>
> I'm pretty anxious to find out as well. Linus, ping, any thoughts on
> including this in 3.6? Thanks,
I just pulled it, but then I unpulled again when I realized it's not a
signed tag and it's on github.
Please, people. Do tagged rele
On Thu, Aug 23, 2012 at 12:30 AM, Marcelo Tosatti wrote:
>
> Please pull from
>
> git://git.kernel.org/pub/scm/virt/kvm/kvm.git master
>
> To receive the following KVM bug fixes:
I'm not seeing what you claim is there. This commit seems to be
missing: forgot to push?
> Avi Kivity (1):
> KV
On Thu, Sep 1, 2011 at 5:54 PM, Jeremy Fitzhardinge wrote:
>
> The inner part of ticket lock code becomes:
> inc = xadd(&lock->tickets, inc);
> inc.tail &= ~TICKET_SLOWPATH_FLAG;
>
> for (;;) {
> unsigned count = SPIN_THRESHOLD;
>
> do {
>
On Fri, Sep 2, 2011 at 1:07 PM, Jeremy Fitzhardinge wrote:
>
> I don't know whether that fastpath code is small enough to consider
> inlining everywhere?
No.
There's no point in inlining something that ends up containing a
conditional function call: gcc will have to effectively save/restore
regi
On Mon, Sep 5, 2011 at 2:42 AM, Avi Kivity wrote:
> Linus, please pull from
>
> git://github.com/avikivity/kvm.git kvm-updates/3.1
>
> to receive a fix for a build failure due to a missing instruction size
> suffix in inline assembly.
Again, please give me a warm and fuzzy feeling that this is r
On Tue, Sep 6, 2011 at 6:19 PM, Josh Boyer wrote:
>
> Maybe asking for some extra warm fuzzies from now on wouldn't be a
> horrible idea as general practice.
I think that realistically we should definitely look at our practices,
but at the same time, I personally do put a lot of trust in "human
r
On Tue, Sep 27, 2011 at 9:44 AM, Jeremy Fitzhardinge wrote:
>
> I guess it comes down to throwing myself on the efficiency of some kind
> of fence instruction. I guess an lfence would be sufficient; is that
> any more efficient than a full mfence? At least I can make it so that
> its only presen
On Wed, Sep 28, 2011 at 8:55 AM, Jan Beulich wrote:
>
>> just use "lock xaddw" there too.
>
> I'm afraid that's not possible, as that might carry from the low 8 bits
> into the upper 8 ones, which must be avoided.
Oh damn, you're right. So I guess the "right" way to do things is with
cmpxchg, but
On Wed, Sep 28, 2011 at 9:47 AM, Jeremy Fitzhardinge wrote:
>
> Could do something like:
>
> if (ticket->head >= 254)
> prev = xadd(&ticket->head_tail, 0xff02);
> else
> prev = xadd(&ticket->head_tail, 0x0002);
>
> to compensate for the overflow.
Oh wow
On Wed, Sep 28, 2011 at 11:08 AM, Stephan Diestelhorst
wrote:
>
> I must have missed the part when this turned into the propose-the-
> craziest-way-that-this-still-works.contest :)
So doing it just with the "lock addb" probably works fine, but I have
to say that I personally shudder at the "surro
On Tue, May 22, 2012 at 6:08 AM, Avi Kivity wrote:
> Linus, please pull the KVM updates for the 3.5 cycle from
Ok. The way I resolved a the x86 kvm_para.h conflict, I suspect it is
now being *unnecessarily* careful about doing the CPUID thing, and I
think that the "cpuid_level < 0" check that cam
On Tue, Feb 28, 2012 at 3:21 AM, Avi Kivity wrote:
>
> Can you elaborate on what you don't like in the kvm code (apart from "it
> does virtualiztion")?
It doesn't fit any of the patterns of the x87 save/restore code, and I
don't know what it does.
It does clts on its own, in random places withou
On Tue, Feb 28, 2012 at 9:21 AM, Avi Kivity wrote:
>
> What you described is the slow path.
Indeed. I'd even call it the "glacial and stupid" path.
>The fast path is
>
> void kvm_load_guest_fpu(struct kvm_vcpu *vcpu)
> {
> if (vcpu->guest_fpu_loaded)
> return;
>
> If we're emulat
On Tue, Feb 28, 2012 at 9:37 AM, Linus Torvalds
wrote:
>
> So where's the comment about why you actually own and control CR0.TS,
> and nobody else does?
So what I think KVM should strive for (but I really don't know the
code, so maybe there are good reasons why it is impossibl
On Tue, Feb 28, 2012 at 10:09 AM, Avi Kivity wrote:
>
> This is done by preempt notifiers. Whenever a task switch happens we
> push the guest fpu state into memory (if loaded) and let the normal
> stuff happen. So the if we had a task switch during instruction
> emulation, for example, then we'd
On Tue, Feb 28, 2012 at 11:06 AM, Avi Kivity wrote:
>
> No, the scheduler saves the state into task_struct. I need it saved
> into the vcpu structure. We have two fpu states, the user state, and
> the guest state. APIs that take a task_struct as a parameter, or
> reference current implicitly, a
On Wed, Mar 21, 2012 at 3:21 AM, Raghavendra K T
wrote:
> From: Jeremy Fitzhardinge
>
> The code size expands somewhat, and its probably better to just call
> a function rather than inline it.
>
> Signed-off-by: Jeremy Fitzhardinge
> Signed-off-by: Raghavendra K T
> ---
> arch/x86/Kconfig
On Thu, Mar 22, 2012 at 5:10 PM, Benjamin Herrenschmidt
wrote:
>
> That means that everything gets constantly rebased, and it makes life
> very much harder for us working with this.
Ben, thanks for pointing this out.
I will not be pulling this tree at all. It's pure and utter shit, and
I wonder
On Tue, Mar 27, 2012 at 9:02 PM, Benjamin Herrenschmidt
wrote:
>
> Linus, what's your feeling here ? I'd really like to have the bulk of
> the powerpc updates this time around, they already missed the previous
> merge window due to maintainers taking too long to deal with their
> inbox :-)
If the
On Thu, Apr 5, 2012 at 9:40 AM, Avi Kivity wrote:
> Linus, please pull a few fixes from
>
> git://git.kernel.org/pub/scm/virt/kvm/kvm.git kvm-updates/3.4
>
> A bunch of powerpc KVM fixes, a guest and a host RCU fix (unrelated),
> and a small build fix.
Grr.
static inline int pull_function(vo
On Mon, Jan 10, 2011 at 1:21 AM, Avi Kivity wrote:
>
> - asynchronous page faults, which allow a guest to continue processing
> interrupts even when its memory is being paged in; in the case of a Linux
> 2.6.38+ guest, it will receive a notification that the host is servicing a
> page fault, and m
On Tue, Jan 11, 2011 at 1:25 AM, Avi Kivity wrote:
>
> What are your issues with the patch?
My issues are mainly two-fold:
- I think "MINOR" is a totally idiotic and meaningless term. It has
no technical meaning. Why would IO be special? Is it because of
deadlock concerns with filesystem or blo
On Wed, Jan 12, 2011 at 12:33 PM, Rik van Riel wrote:
>
> Now that we have FAULT_FLAG_ALLOW_RETRY, the async
> pagefault patches can be a little smaller.
I suspect you do still want a new page flag, to say that
FAULT_FLAG_ALLOW_RETRY shouldn't actually wait for the page that it
allows retry for.
On Thu, Jan 13, 2011 at 4:53 AM, Gleb Natapov wrote:
>
> I implemented get_user_pages_nowait() on top of your patch. In my testing
> it works as expected when used inside KVM. Does this looks OK to you?
It looks reasonable, although I suspect the subtle behavior wrt the
mmap_sem means that you sh
On Wed, Feb 20, 2013 at 5:17 PM, Marcelo Tosatti wrote:
>
> Please pull from
>
> git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/kvm-3.9-1
>
> to receive the KVM updates for the 3.9 merge window [..]
Ok, particularly the s390 people should check me resolution of the
conflicts, since they inclu
On Thu, May 2, 2013 at 12:33 PM, Michael S. Tsirkin wrote:
>
> I prefer not rebasing,
Good.
> will play with git to see why
> does request-pull get me a wrong diffstat and how
> to trick it into doing the right thing.
> Maybe merging my branch into master will do this.
No, don
On Thu, May 2, 2013 at 1:11 PM, Michael S. Tsirkin wrote:
> Hi Linus,
> This is exactly same code as my previous pull sent earlier, the diffstat
> was wrong however, I did a merge with master which fixed that.
See my other email. THIS IS NOT A VALID REASON TO DO A BACK-MERGE!
Extraneous merge co
I pulled the previous tag, which didn't have the merge.
And what the heck is up with "virtualizat...@lists.osdl.org"? That
thing doesn't work. "osdl.org"? Did we suddenly take a delorean back a
decade? Nonworking list cc removed.
Linus
--
To unsubscribe from this list: send the lin
On Thu, May 23, 2013 at 3:41 AM, Gleb Natapov wrote:
>
> MAINTAINERS |7 ++--
> arch/mips/include/asm/kvm.h | 55
> ---
> arch/mips/include/uapi/asm/kvm.h | 55
> +++
> arch/mips/kvm/kvm_tl
On Thu, May 23, 2013 at 10:13 AM, Gleb Natapov wrote:
>
> Ugh, yes "-M" and "--summary" were missing. I updated the script now. Thanks!
> Should I regenerate pull request?
No, I pulled,
Linus
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message t
On Tue, Sep 3, 2013 at 5:10 AM, Gleb Natapov wrote:
>
> This pull request adds tlb_gather_mmu() caller in S390 code, but 2b047252
> in your tree added another parameter to the function, so the patch bellow
> have to be applied during merge to resolve the conflicts. The patch was
> used in linux-ne
On Tue, Jul 1, 2014 at 3:44 AM, Paolo Bonzini wrote:
>
> git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus
I've pulled this, but I was pretty close to saying "screw this shit".
Look at commit 9a630d15f16d, and pray tell me why those kinds of
commit logs are excusable?
That commit m
On Fri, Sep 5, 2014 at 3:16 AM, Paolo Bonzini wrote:
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus
Nothing new there. Forgot to push out, or perhaps to use "-f" to
overwrite the previous tag of the same name?
Linus
--
To
This needs more explanation than that one-liner comment. Make the
commit message explain why the new FOLL_TRIED flag exists.
Linus
On Fri, Oct 3, 2014 at 10:07 AM, Andrea Arcangeli wrote:
> From: Andres Lagar-Cavilla
>
> Reviewed-by: Radim Krčmář
> Signed-off-by: Andres Lagar-Cavilla
>
On Fri, Oct 3, 2014 at 10:07 AM, Andrea Arcangeli wrote:
> This teaches gup_fast and __gup_fast to re-enable irqs and
> cond_resched() if possible every BATCH_PAGES.
This is disgusting.
Many (most?) __gup_fast() users just want a single page, and the
stupid overhead of the multi-page version is
On Fri, Oct 3, 2014 at 10:08 AM, Andrea Arcangeli wrote:
>
> Overall this looks a fairly small change to the rmap code, notably
> less intrusive than the nonlinear vmas created by remap_file_pages.
Considering that remap_file_pages() was an unmitigated disaster, and
-mm has a patch to remove it e
On Mon, Oct 6, 2014 at 12:41 PM, Andrea Arcangeli wrote:
>
> Of course if somebody has better ideas on how to resolve an anonymous
> userfault they're welcome.
So I'd *much* rather have a "write()" style interface (ie _copying_
bytes from user space into a newly allocated page that gets mapped)
t
On Tue, Oct 7, 2014 at 10:19 AM, Andrea Arcangeli wrote:
>
> I see what you mean. The only cons I see is that we couldn't use then
> recv(tmp_addr, PAGE_SIZE), remap_anon_pages(faultaddr, tmp_addr,
> PAGE_SIZE, ..) and retain the zerocopy behavior. Or how could we?
> There's no recvfile(userfault
On Mon, Nov 10, 2014 at 12:18 PM, Christian Borntraeger
wrote:
>
> Now: I can reproduces belows miscompile on gcc46 and gcc 47
> gcc 45 seems ok, gcc 48 is fixed. This makes blacklisting
> a bit hard, especially since it is not limited to s390, but
> covers all architectures.
> In essence ACCESS_
On Tue, Nov 11, 2014 at 1:16 PM, Christian Borntraeger
wrote:
>
> Are you ok with the patch as is in kvm/next for the time being or shall
> we revert that and replace it with the .val scheme?
Is that the one that was quoted at the beginning of the thread, that
uses barrier()?
I guess as a workar
On Tue, Nov 11, 2014 at 4:33 PM, Linus Torvalds
wrote:
>
> I guess as a workaround it is fine, as long as we don't lose sight of
> trying to eventually do a better job.
Oh, and when it comes to the actual gcc bug - do you have any reason
to believe that it's somehow trigg
On Thu, Nov 20, 2014 at 3:39 AM, Christian Borntraeger
wrote:
>
> So It looks like we could make a change to ACCESS_ONCE. Would something like
>
> CONFIG_ARCH_SCALAR_ACCESS_ONCE be a good start?
No, if it's just a handful of places to be fixed, let's not add config
options for broken cases.
> Th
On Wed, Oct 16, 2013 at 5:00 AM, Jan Beulich wrote:
>
> The basic idea here is to either use a priori information on the
> intended state layout (in the case of 32-bit processes) or "sense" the
> proper layout (in the case of KVM guests) by inspecting the already
> saved FPU rip/rdp, and reading t
On Wed, Oct 16, 2013 at 8:36 AM, Jan Beulich wrote:
>
> In that case we use a 32-bit operand size [F]XRSTOR, and hence
> the upper halves get treated as selectors, and the offsets get
> zero-extended from the low halves, i.e. we preserve even more
> state for such a 64-bit environment now too (alb
On Wed, Oct 16, 2013 at 9:13 AM, Jan Beulich wrote:
>
> But again - this isn't being done for ordinary 64-bit applications,
> this is only happening for KVM guests. And there not being a
> protocol for telling the caller whether a certain context hold
> 64-bit offsets or selector/offset pairs shou
Ugh. I won't comment on the actual kvm part of this patch, somebody
who knows that code should do so.
But I reacted to this:
On Tue, Oct 29, 2013 at 8:13 AM, Tim Gardner wrote:
>
> sudo modprobe kvm_amd
> modprobe: ERROR: could not insert 'kvm_amd': Bad address
"Bad address"? Christ people, are
On Tue, Oct 29, 2013 at 12:27 PM, Raghavendra K T
wrote:
>
> Could one solution be cascading actual error
> that is lost in fs/debugfs/inode.c:__create_file(), so that we could
> take correct action in case of failure of debugfs_create_dir()?
>
> (ugly side is we increase total number of params fo
On Tue, May 27, 2014 at 3:08 PM, Paul Mackerras wrote:
>
> Linus seems not to have done this pull yet - Paolo, maybe you should
> resend the request and cc Linus this time?
Indeed. I don't pull stuff unless it's explicitly sent to me, and this
one seems to have been sent just to the lists. Please
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 Thu, Jun 10, 2010 at 2:31 AM, Avi Kivity wrote:
> Linus, please pull from
>
> git://git.kernel.org/pub/scm/virt/kvm/kvm.git kvm-updates/2.6.35
>
> to receive a bunch of KVM fixes for 2.6.35-rc2, including a workaround for a
> cpu erratum that can allow a guest to crash the host.
Hmm. This loo
On Thu, Jun 10, 2010 at 10:34 AM, Avi Kivity wrote:
>
> Ok. I've dropped the SRAO patch; this still leaves ~100 changed lines, but
> they are almost all due to the erratum 383 workaround, which can result in a
> guest killing the host. The rest of the patches are less critical, but they
> are on
On Wed, 23 Dec 2009, Gregory Haskins wrote:
> >
> > And upstream submission is not always like this!
>
> I would think the process would come to a grinding halt if it were ;)
Well, in all honesty, if it had been non-virtualized drivers I would just
have pulled. The pull request all looked san
On Fri, 19 Dec 2008, Rusty Russell wrote:
>
> Linus, please apply. Otherwise those using it in transition patches (eg. kvm)
> can't compile with CONFIG_SMP=n:
Umm. I already applied this a long time ago. It's commit
d2ff911882b6bc693d86ca9566daac70aacbb2b3
Linus
--
To unsubscr
On Fri, 19 Dec 2008, Rusty Russell wrote:
>
> On Friday 19 December 2008 08:46:37 Linus Torvalds wrote:
> >
> > Umm. I already applied this a long time ago. It's commit
> > d2ff911882b6bc693d86ca9566daac70aacbb2b3
>
> Wow, it's like Santa came ear
Just a small comment fix.
On Thu, 5 Jun 2008, Andrea Arcangeli wrote:
> + /*
> + * AS_MM_ALL_LOCKS can't change from under us because
> + * we hold the global_mm_spinlock.
There's no global_mm_spinlock, you mean the 'mm_all_locks_mutex'.
(There was at least
On Wed, 25 Jun 2008, Avi Kivity wrote:
>
> Linus, please pull from the repo and branch at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git kvm-updates-2.6.26
>
> to receive kvm updates for 2.6.26-rc7. The patches fix host oopses,
> guest interrupt loss, and total kvm clock borka
On Wed, Dec 12, 2012 at 1:19 PM, Stephen Rothwell wrote:
>
> There is a section of this tree (the kvm-ppc tree in linux-next) that has
> been rebased before being merged into this tree. Alexander, please
> don't do that (especially since it has *not* bee rebased in the kvm-ppc
> tree but more wo
On Thu, Dec 13, 2012 at 3:03 PM, Stephen Rothwell wrote:
>
> Actually only in my tree (until Alexander cleans his tree up). I am
> going to have a conversation with Alexander about process.
Ok, as long as it's contained, I guess I'll pull.
Linus
--
To unsubscribe from this list: sen
On Fri, Apr 17, 2015 at 4:39 PM, Andy Lutomirski wrote:
>
> On my box, vclock_gettime using kvm-clock is about 40 ns. An empty
> syscall is about 33 ns. clock_gettime *should* be around 17 ns.
>
> The clock_gettime syscall is about 73 ns.
>
> Could we figure out why clock_gettime (the syscall) i
On Fri, Apr 17, 2015 at 5:42 PM, Andy Lutomirski wrote:
>
> Muahaha. The auditors have invaded your system. (I did my little
> benchmark with a more sensible configuration -- see way below).
>
> Can you send the output of:
>
> # auditctl -s
> # auditctl -l
# auditctl -s
enabled 1
flag 1
On Mon, Jun 15, 2015 at 12:19 PM, Andrea Arcangeli wrote:
>
> Yes, it would leave the other blocked, how is it different from having
> just 1 reader and it gets killed?
Either is completely wrong. But the read() code can at least see that
"I'm returning early due to a signal, so I'll wake up any
On Tue, Jun 23, 2015 at 9:49 AM, Paolo Bonzini wrote:
>
> There are some x86 conflicts, one with the rc8 pull request and
> the rest with Ingo's FPU rework.
Hmm. I'm dropping the "fx_init(..init_state)" changes from you pull
request, since fx_init is static and only has one caller, and that one
h
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.
On Thu, Aug 13, 2015 at 2:26 PM, Andy Lutomirski wrote:
>
> VERW is no good, because it considers non-present segments to be
> writable. Test cases for the win!
Seriously? That's crazy. I don't think I've actually ever used VERW,
but the documentation certainly says that the segment has to be
wr
Hmm:
On Fri, Aug 14, 2015 at 4:57 PM, Paolo Bonzini wrote:
>
> Xiao Guangrong (9):
> KVM: MMU: fully check zero bits for sptes
The above commit causes an annoying new compiler warning.
The warning is bogus ("variable 'leaf' possibly uninitialized"),
because the use of the variable is prot
On Sun, Sep 20, 2015 at 5:02 PM, Andy Lutomirski wrote:
> This demotes an OOPS and likely panic due to a failed non-"safe" MSR
> access to a WARN_ON_ONCE and a return of zero (in the RDMSR case).
> We still write a pr_info entry unconditionally for debugging.
No, this is wrong.
If you really wan
On Mon, Sep 21, 2015 at 1:46 AM, Ingo Molnar wrote:
>
> Linus, what's your preference?
So quite frankly, is there any reason we don't just implement
native_read_msr() as just
unsigned long long native_read_msr(unsigned int msr)
{
int err;
unsigned long long val;
val = na
On Mon, Sep 21, 2015 at 9:49 AM, Arjan van de Ven wrote:
>>
>> How many msr reads are so critical that the function call
>> overhead would matter?
>
> if anything qualifies it'd be switch_to() and friends.
Is there anything else than the FS/GS_BASE thing (possibly hidden
behind inlines etc that I
On Mon, Sep 21, 2015 at 11:16 AM, Andy Lutomirski wrote:
>
> In the interest of sanity, I want to drop the "native_", too
Yes. I think the only reason it exists is to have that wrapper layer
for PV. And that argument just goes away if you just make the
non-inline helper function do all the PV log
On Tue, Sep 29, 2015 at 1:35 PM, Andy Lutomirski wrote:
>
> Does anyone know what happens if you stick a non-accessed segment in
> the GDT, map the GDT RO, and access it?
You should get a #PF, as you guess, but go ahead and test it if you
want to make sure.
We do something very similar for the o
On Sat, Jan 17, 2015 at 1:19 PM, Andy Lutomirski wrote:
> Linus, I suspect you'll either like or hate this series. Or maybe
> you'll think it's crazy but you'll like it anyway. I'm curious
> which of those is the case. :)
I have no hugely strong reaction to the patches, but it seems to be a
goo
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 Thu, Mar 5, 2015 at 9:18 AM, Andrea Arcangeli wrote:
> remap_pages is the lowlevel mm helper needed to implement
> UFFDIO_REMAP.
This function is nasty nasty nasty.
Is this really worth it? On real loads? That people are expected to use?
Considering how we just got rid of one special magic V
On Thu, Mar 5, 2015 at 10:51 AM, Andrea Arcangeli wrote:
>
> Thanks for your idea that the UFFDIO_COPY is faster, the userland code
> we submitted for qemu only uses UFFDIO_COPY|ZEROPAGE, it never uses
> UFFDIO_REMAP.
Ok. So there's no actual expected use of the remap interface. Good.
That makes
85 matches
Mail list logo
