On Tue, Aug 29, 2017 at 4:54 PM, Jérôme Glisse wrote:
>
> Note this is barely tested. I intend to do more testing of next few days
> but i do not have access to all hardware that make use of the mmu_notifier
> API.
Thanks for doing this.
> First 2 patches convert existing call of mmu_notifier_in
On Thu, Aug 24, 2017 at 2:13 PM, Thomas Garnier wrote:
>
> My original performance testing was done with an Ubuntu generic
> configuration. This configuration has the CONFIG_FUNCTION_TRACER
> option which was incompatible with PIE. The tracer failed to replace
> the __fentry__ call by a nop slide
On Wed, Aug 23, 2017 at 3:36 PM, Kirill A. Shutemov
wrote:
>
> Below is test cases that allocates a lot of page tables and measuare
> fork/exit time. (I'm not entirely sure it's the best way to stress the
> codepath.)
Looks ok to me. Doing a profile (without the RCU freeing, obviously) gives me
On Wed, Aug 23, 2017 at 12:59 PM, Kirill A. Shutemov
wrote:
>
> In this case we need performance numbers for !PARAVIRT kernel.
Yes.
> Numbers for tight loop of "mmap(MAP_POPULATE); munmap()" might be
> interesting too for worst case scenario.
Actually, I don't think you want to populate all the
On Wed, Aug 23, 2017 at 6:45 AM, Vitaly Kuznetsov wrote:
>
> Solve the issue by enabling RCU-based table free mechanism when PARAVIRT
> is selected in config. Testing with kernbench doesn't show any notable
> performance impact:
I wonder if we should just make it unconditional if it doesn't reall
On Fri, Jul 21, 2017 at 3:17 AM, Juergen Gross wrote:
> drivers/xen/pvcalls-back.c | 1236
>
This really doesn't look like a fix.
The merge window is over.
So I'm not pulling this without way more explanations of why I should.
Linu
On Tue, Jul 11, 2017 at 8:17 PM, Linus Torvalds
wrote:
>
> If that's the case, I'd prefer just turning off the format-truncation
> (but not overflow) warning with '-Wno-format-trunction".
Doing
KBUILD_CFLAGS += $(call cc-disable-warning, format-truncation)
in the
On Tue, Jul 11, 2017 at 8:10 PM, Guenter Roeck wrote:
>
> The hwmon warnings are all about supporting no more than 9,999 sensors
> (applesmc) to 999,999,999 sensors (scpi) of a given type.
Yeah, I think that's enough.
> Easy "fix" would be to replace snprintf() with scnprintf(), presumably
> bec
[ Very random list of maintainers and mailing lists, at least
partially by number of warnings generated by gcc-7.1.1 that is then
correlated with the get_maintainers script ]
So I upgraded one of my boxes to F26, which upgraded the compiler to gcc-7.1.1
Which in turn means that my nice clean allm
On Mon, Oct 24, 2016 at 9:37 AM, David Vrabel wrote:
>
> I think the changes are trivial and uncontroversial.
Hmm. Sadly, they are also buggy.
This:
if (files->mode & S_IFLNK) {
is simply wrong. The correct test for S_IFLNK is to do
if ((files->mode & S_IFMT) =
On Wed, Jul 27, 2016 at 4:09 PM, Rafael J. Wysocki wrote:
>
> The STAO definition document:
>
> http://wiki.xenproject.org/mediawiki/images/0/02/Status-override-table.pdf
>
> requires as to "operate as if that device does not exist", quite literally.
Well, first off, documentation is one thing, a
On Wed, Jul 27, 2016 at 6:45 AM, David Vrabel wrote:
>
> Shannon Zhao (16):
> Xen: ACPI: Hide UART used by Xen
So this caused a trivial conflict. No biggie, it wasn't bad and the
patch was acked by Rafael. However, looking at it made me somewhat
unhappy.
Should the device entry in ACPI rea
Having upgraded one of my machines to F24, I get a few new warnings
during the kernel compile due to a new compiler.
Some of them are just annoying and wrong, but one of them points to a
real Xen bug:
arch/x86/xen/mmu.c:1116:57: warning: array subscript is above array
bounds [-Warray-bounds]
On Sun, Apr 3, 2016 at 8:55 AM, Andy Lutomirski wrote:
>
> In this regard, at least, my patch is the right approach. Calling the
> handler, whatever it is, is less likely to panic than refusing to call
> it.
Agreed, the patch series looks like a good thing in general.
Linus
___
On Sun, Apr 3, 2016 at 3:07 AM, Borislav Petkov wrote:
>
> I'm wondering whether making it try to EFAULT correctly is the right
> thing to do... We're certainly more conservative if we panic and not
> allow some silently failed attempt at recovery which looks successful,
> to continue.
No, please
On Sat, Apr 2, 2016 at 10:13 AM, Andy Lutomirski wrote:
>
> I also tried a bad wrmsrl at a couple early points. Very very early
> it just works with not warning. A little later and it prints the
> warning.
Ok, that sounds like the correct behavior - I'm sure the very very
early ones "warned" to
This patch series looks much nicer than the last one. I assume you
tested that the early-trap handling actually worked too? I only looked
at the patches..
Ack to it all,
Linus
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.x
On Mon, Mar 14, 2016 at 11:24 AM, Andy Lutomirski wrote:
>
> The code in my queue is, literally:
>
> bool ex_handler_rdmsr_unsafe(const struct exception_table_entry *fixup,
> struct pt_regs *regs, int trapnr)
> {
> WARN_ONCE(1, "unchecked MSR access error: RDMSR from 0x%x",
>
On Mon, Mar 14, 2016 at 11:10 AM, Andy Lutomirski wrote:
>
> A couple of the wrmsr users actually care about performance. These
> are the ones involved in context switching and, to a lesser extent, in
> switching in and out of guest mode.
.. ok, see the crossed emails.
I'd *much* rather special
On Mon, Mar 14, 2016 at 11:04 AM, Linus Torvalds
wrote:
>
> None of this insane complicated crap that buys us exactly *nothing*,
> and depends on fancy new exception handling support etc etc.
Actually, the one _new_ thing we could do is to instead of removing
the old crappy rdms
On Mon, Mar 14, 2016 at 10:17 AM, Andy Lutomirski wrote:
>
> So yes, let's please warn. I'm okay with removing the panic_on_oops
> thing though. (But if anyone suggests that we should stop OOPSing on
> bad kernel page faults, I *will* fight back.)
Bad kernel page faults are something completely
On Mar 14, 2016 10:05 AM, "Andy Lutomirski" wrote:
>
> We could probably remove that check and let custom fixups run early.
> I don't see any compelling reason to keep them disabled. That should
> probably be a separate change, though.
Or we could just use the existing wrmsr_safe() code and not
On Mar 14, 2016 9:53 AM, "Andy Lutomirski" wrote:
>
> Can you clarify? KVM uses the native version, and the native version
> only oopses with this series applied if panic_on_oops is set.
Can we please remove that idiocy?
There is no reason to panic whatsoever. Seriously. What's the upside of
th
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 cache award"
thing, and a
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 documentation
> reasons, though.
On Tue, Jan 26, 2016 at 2:15 PM, Linus Torvalds
wrote:
>
> You might as well just write it as
>
> struct foo x = READ_ONCE(*ptr);
> x->bar = 5;
>
> because that "smp_read_barrier_depends()" does NOTHING wrt the second write.
Just to clarify: on alpha
On Tue, Jan 26, 2016 at 12:10 PM, Paul E. McKenney
wrote:
> On Tue, Jan 26, 2016 at 11:44:46AM -0800, Linus Torvalds wrote:
>>
>> > struct foo *x = READ_ONCE(*ptr);
>> > smp_read_barrier_depends();
>> > x->bar = 5;
>>
>>
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 removed a
number of bogus
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 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 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 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 Fri, Aug 14, 2015 at 12:16 AM, Ingo Molnar wrote:
>
> I just sent it to Linus, so barring a catastrophy it should be upstream soon.
Well, I just rejected that pull as completely broken, so I guess the
catastrophy happened... Or, alternatively, I mis-read the code, which
does happen, but my gia
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 Tue, Apr 21, 2015 at 5:45 AM, Ingo Molnar wrote:
>
> Totally untested and not signed off yet: because we'd first have to
> make sure (via irq flags debugging) that it's not used in reverse, to
> re-disable interrupts:
Not only might that happen in some place, I *really* doubt that a
conditiona
On Thu, Feb 19, 2015 at 5:05 PM, Kirill A. Shutemov
wrote:
>
> I'm feeling I miss very basic background on how Xen works, but why does it
> set _PAGE_GLOBAL on userspace entries? It sounds strange to me.
It is definitely strange. I'm guessing that it's some ancient Xen hack
for the early Intel vi
On Thu, Feb 19, 2015 at 5:06 AM, David Vrabel wrote:
>
> The NUMA_BALANCING series beginning with 5d833062139d (mm: numa: do not
> dereference pmd outside of the lock during NUMA hinting fault) and
> specifically 8a0516ed8b90 (mm: convert p[te|md]_numa users to
> p[te|md]_protnone_numa) breaks Xen
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 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 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 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 Mon, Dec 22, 2014 at 6:26 PM, Stephen Rothwell wrote:
> Hi Linus,
>
> I have been carrying this merge fix patch for some time that is now
> needed in your tree:
No, it's not. Look more closely.
My merge put the
dev->archdata.dma_coherent = coherent;
line at the top of the function,
42 matches
Mail list logo
