On 04/23/2015 03:29 PM, Andy Lutomirski wrote:
>>
>> Yes, the NULL SS is a special thing in 64-bit mode. I agree that
>> context-switching it is probably the way to go; it should be cheap
>> enough. We might even be able to conditionalize it on an X86_BUG_ flag.
>
> I still don't see why context
On 04/23/2015 02:10 PM, Borislav Petkov wrote:
> On Thu, Apr 23, 2015 at 10:01:16PM +0200, Denys Vlasenko wrote:
>> Naturally, CS can't be NULL, and up until today
>> I thought SS also can't. But the bit is probably implemented
>> for all eight cached descriptors.
>
> There's this section about NU
On 04/23/2015 08:28 AM, Dave Hansen wrote:
> On 04/23/2015 02:13 PM, Liang Li wrote:
>> When compiling kernel on westmere, the performance of eager FPU
>> is about 0.4% faster than lazy FPU.
>
> Do you have an theory why this is? What does the regression come from?
>
This is interesting since p
On 04/15/2015 01:42 PM, Andy Lutomirski wrote:
>
> I disagree. We should try to NACK any new code that can't function
> without MTRRs.
>
> (Plus, ARM is growing in popularity in the server space, and ARM quite
> sensibly doesn't have MTRRs.)
>
Yes. People need to understand that MTRRs are f
On 04/06/2015 02:13 PM, Paul Menzel via Syslinux wrote:
>>
>> The kernel boot protocol should probably be extended to accept a block
>> of values to be passed from the loader to the OS, and be exported
>> somewhere by the kernel itself to userspace.
>>
We have that, it is called initramfs. It con
On 04/03/2015 11:37 AM, Linus Torvalds wrote:
> On Fri, Apr 3, 2015 at 11:35 AM, H. Peter Anvin wrote:
>>
>> For the record, I actually measured the impact of the jump-to-jump when
>> I wrote it. It has a small, *but measurable*, positive impact.
>
> What did you c
On 04/03/2015 11:08 AM, Linus Torvalds wrote:
> On Fri, Apr 3, 2015 at 9:54 AM, Denys Vlasenko wrote:
>>
>> How about this version?
>> It's still isn't a star of readability,
>> but the structure of the 32-byte code block is more visible now...
>
> Do we really even want to be this clever in the
On 04/01/2015 01:52 PM, Denys Vlasenko wrote:
> On 04/01/2015 05:50 PM, Linus Torvalds wrote:
>> On Wed, Apr 1, 2015 at 4:10 AM, Denys Vlasenko wrote:
>>>
>>> I did not know that. I was sure they are always zero extended.
>>
>> On all half-way modern cpu's they are. But on some older cpu's
>> (pos
Ok, "movabs" is crazier than I thought.
On March 25, 2015 5:05:50 PM PDT, Linus Torvalds
wrote:
>On Wed, Mar 25, 2015 at 4:56 PM, H. Peter Anvin wrote:
>> No, movabs is yet another instruction (with a 64-bit absolute
>address.) But movq can mean 10 or 7 bytes...
>
&g
No, movabs is yet another instruction (with a 64-bit absolute address.) But
movq can mean 10 or 7 bytes...
On March 25, 2015 4:51:50 PM PDT, Linus Torvalds
wrote:
>On Wed, Mar 25, 2015 at 10:18 AM, Denys Vlasenko
>wrote:
>> The $AUDIT_ARCH_X86_64 parameter to syscall_trace_enter_phase1/2
>> is
On 03/17/2015 07:13 AM, Arjun Sreedharan wrote:
>
> On a related note, IMO strcmp() should return {-1,0,1} since many
> programmers just expect this behavior. just my opinion.
>
I would challenge that assumption, *especially* in the context of kernel
programming. Let's not waste time on that cr
On 03/16/2015 01:35 AM, Ingo Molnar wrote:
>
> :-/
>
> Not sure what hpa's problem with 'void *' was: especially in MM code
> we are using 'void *' rather widely.
>
> All compilers that aim for being able to build the Linux kernel
> implement 'void *' as well, so that 'standard C' argument is
On 03/09/2015 12:13 PM, Andy Lutomirski wrote:
> On Mon, Mar 9, 2015 at 10:44 AM, H. Peter Anvin wrote:
>> On 03/09/2015 09:44 AM, Linus Torvalds wrote:
>>>
>>> And remember: those zero-cost out-of-order branches turn quite
>>> expensive if they *ever* misp
On 03/09/2015 09:44 AM, Linus Torvalds wrote:
>
> And remember: those zero-cost out-of-order branches turn quite
> expensive if they *ever* mispredict. Even a 5% mispredict rate is
> likely to mean "it's better to have a data dependency chain".
>
> So it could easily go either way. I'm not convin
On 03/09/2015 09:08 AM, Linus Torvalds wrote:
>
> Sure, the btl is easier to explain in the source code, but instead of this:
>
>> + btl $X86_EFLAGS_VM_BIT,PT_EFLAGS(%esp)
>
> you'd have to add a comment, like
>
> testb $2, PT_EFLAGS+2(%esp) # X86_EFLAGS_VM_BIT
>
> or something.
Seriously, if type 12 is the de facto standard for NvDIMMs, I think we
should add it. The documented ACPI method of using flags was doomed
from the start.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
On 03/03/2015 10:22 PM, Brian Gerst wrote:
>
> It looks like most cases can simply be replaced. There are some
> subtle relations with the x32 ABI though, and that will take some time
> to sort out.
>
Yes, some aspects of CONFIG_COMPAT is used also by x32.
Overall the current Linux kernel hand
On 06/23/2014 06:08 AM, Konrad Rzeszutek Wilk wrote:
> On Wed, Mar 19, 2014 at 08:02:22AM -0700, H. Peter Anvin wrote:
>> On 03/19/2014 06:21 AM, Konrad Rzeszutek Wilk wrote:
>>>>
>>>> The following patch does the always eager allocation. It's a
On 02/25/2015 01:20 AM, Ingo Molnar wrote:
I think the fundamental fragility is that we allow the high
32 bits to be nonzero.
So could we just zap the high 32 bits of RAX early in the
entry code, and then from that point on we could both use
32-bit ops and won't have to remember the possibility
On 02/24/2015 02:56 PM, Andy Lutomirski wrote:
> On Tue, Feb 24, 2015 at 2:52 PM, H. Peter Anvin wrote:
>> On 02/24/2015 02:25 PM, Andy Lutomirski wrote:
>>> On Tue, Feb 24, 2015 at 10:51 AM, Denys Vlasenko
>>> wrote:
>>>> In all three 32-bit entry points,
On 02/24/2015 02:25 PM, Andy Lutomirski wrote:
> On Tue, Feb 24, 2015 at 10:51 AM, Denys Vlasenko wrote:
>> In all three 32-bit entry points, %eax is zero-extended to %rax.
>> It is safe to do 32-bit compare when checking that syscall#
>> is not too large.
>
> Applied. Thanks!
>
NAK NAK NAK NA
On 02/24/2015 12:36 PM, Borislav Petkov wrote:
> On Tue, Feb 24, 2015 at 09:13:03PM +0100, Denys Vlasenko wrote:
>> They aren't equal. $1 and $2 in two lowest bits will also
>> be interpreted as "userspace" here. "Equal to $3" sends
>> a wrong message here to a human reading the code,
>> the code
On 02/24/2015 01:48 PM, Ross Zwisler wrote:
> On Tue, 2015-02-24 at 13:41 -0800, H. Peter Anvin wrote:
>> On 02/24/2015 01:40 PM, H. Peter Anvin wrote:
>>> On 02/24/2015 01:30 AM, Borislav Petkov wrote:
>>>> On Mon, Feb 23, 2015 at 03:14:01PM -0800, H. Peter Anvin w
On 02/24/2015 01:40 PM, H. Peter Anvin wrote:
> On 02/24/2015 01:30 AM, Borislav Petkov wrote:
>> On Mon, Feb 23, 2015 at 03:14:01PM -0800, H. Peter Anvin wrote:
>>> That may cause the same line to be flushed twice. I would suggest,
>>> instead, also removing the arit
On 02/24/2015 01:30 AM, Borislav Petkov wrote:
> On Mon, Feb 23, 2015 at 03:14:01PM -0800, H. Peter Anvin wrote:
>> That may cause the same line to be flushed twice. I would suggest,
>> instead, also removing the arithmetic on void *:
>
> Btw, should we hold down all t
On 02/20/2015 02:31 AM, tip-bot for Ross Zwisler wrote:
>
> This function shows how to properly use clwb/clflushopt/clflush
> and pcommit with appropriate fencing:
>
> void flush_and_commit_buffer(void *vaddr, unsigned int size)
> {
> void *vend = vaddr + size - 1;
>
> for (; vaddr <
ccepted to memory
> and is durable on the DIMM.
Acked-by: H. Peter Anvin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
op(); /* from pcommit(), via alternatives */
>
> /*
> * sfence to order pcommit
> * mfence via mb() also works
> */
> wmb();
> }
>
> This is still correct, but now you've got two fences separated by only a
> nop. With
On 01/30/2015 01:26 PM, Scotty Bauer wrote:
> mwait_play_dead previously issued a CLFLUSH to work around a bug on
> some xeon processors. We can now determine if the CPU is a buggy CPU.
> This patch checks if if we're on a buggy CPU which allows non-buggy
> cpu's to eliminate the CLFLUSH.
Here is
On 01/30/2015 01:26 PM, Scotty Bauer wrote:
> mwait_play_dead previously issued a CLFLUSH to work around a bug on
> some xeon processors. We can now determine if the CPU is a buggy CPU.
> This patch checks if if we're on a buggy CPU which allows non-buggy
> cpu's to eliminate the CLFLUSH.
Here is
On 02/11/2015 12:36 PM, Andy Lutomirski wrote:
>
> This is sort of a reply to the wrong thread, but wouldn't it be nicer
> if we could pop a bunch of regs instead of using mov followed by add?
> (Yes, this could be a followup, but it could be easier to spot now by
> changing macros like RESTORE_XY
On 02/06/2015 11:23 AM, Kees Cook wrote:
>
> Strictly speaking (ISO C, "man 3 errno"), errno is supposed to be a
> full int, though digging around I find this in include/linux/err.h:
>
That doesn't mean the kernel has to support them.
> /*
> * Kernel pointers have redundant information, so we
On 02/04/2015 11:17 PM, Ingo Molnar wrote:
Even for the 8bit ones? Since we have the *H and *L register
we have more 8 bit regs than we have 16/32 bit regs and it
might just be worth it.
Fewer, actually. gcc doesn't really use the H registers much,
Is that true for other compilers as well?
On 01/20/2015 07:37 PM, Baoquan He wrote:
Leftover problem:
hpa want to see the physical randomization can cover the whole physical
memory. I
checked code and found it's hard to do. Because in
arch/x86/boot/compressed/head_64.S
an identity mapping of 4G is built and then kaslr and decompr
plicitly initialize
global/static pointer variables to NULL (that happens automatically anyway.)
Other than that,
Acked-by: H. Peter Anvin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo
On 01/30/2015 12:04 AM, Markus Pargmann wrote:
> Yes, that was the first idea how to implement a complete netboot for an
> embedded ARM device. However, an initramfs is at least around 1MB in
> size...
No, it's not.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux
On 01/26/2015 11:51 AM, Ross Zwisler wrote:
>
> This is fine, but now you've got two fences in a row. Another slightly more
> messy choice would be to include the fence in the pcommit assembly, so
> you either get pcommit + sfence or a pair of NOPs.
>
If that is the required usage pattern, it s
On 01/23/2015 12:40 PM, Ross Zwisler wrote:
> This patch set adds support for two new persistent memory instructions,
> pcommit
> and clwb. These instructions were announced in the document "Intel
> Architecture Instruction Set Extensions Programming Reference" with reference
> number 319433-022.
On 01/23/2015 11:34 AM, Rik van Riel wrote:
> While working on a patch series to defer FPU state loading until
> kernel -> user space transition, and be more lazy with FPU state
> while in the kernel, I came across this code in save_xstate_sig().
>
> Not only is this broken with my new code, but i
On 01/19/2015 02:04 AM, Peter Zijlstra wrote:
> On Mon, Jan 19, 2015 at 07:54:22AM +1200, Linus Torvalds wrote:
>> Why?
>>
>> The 8- and 16- bit versions are the same as the 32-bit one. This seems
>> pointless. If you want something where the sign is in bit 3, they all
>> return the same value, jus
On 01/15/2015 11:41 AM, Matt Fleming wrote:
Tianocore makes assumptions about the kernel's GDT layout? Yuck.
No, but 32-bit Tianocore does rely on the second GDT entry being a
32-bit CS.
It has no knowledge of Linux's GDT layout.
If it assumes that descriptor 16 is a 32-bit CS (and what a
On 01/12/2015 12:14 PM, Andy Lutomirski wrote:
> On Mon, Jan 12, 2015 at 12:11 PM, Borislav Petkov wrote:
>> On Mon, Jan 12, 2015 at 11:46:53AM -0800, Andy Lutomirski wrote:
>>> Dumb example:
>>>
>>> pushq_cfi $__KERNEL_DS /* ss */
>>>
>>> This doesn't save anything that the unwinder would car
Yes, the -512 is not related to STACK_SIZE, so this patch is wrong. NAK.
On December 26, 2014 9:03:38 AM PST, Alexander Kuleshov
wrote:
>Yes, you're right,
>
>At first i thought that it is just typo, and right after that i
>thought about this case when somebody will change STACK_SIZE
>
>2014-12
>> 4*8 = 32 bytes, where did 256 bytes come from?
>
> You are right. It should be 32 bytes. I will change the wording in future
> patch. The real calculation in code is right though.
I don't know if it makes sense to round up to a cache line. My
suspicion is that it won't matter, as these field
On 12/17/2014 01:47 PM, Fenghua Yu wrote:
> From: Fenghua Yu
>
> X86 32-bit machine and kernel use PAE paging, which currently wastes about
> 4K of memory per process on Linux where we have to reserve an entire page to
> support a single 256-byte PGD structure. It would be a very good thing if
>
On 12/18/2014 03:16 AM, tip-bot for Andy Lutomirski wrote:
> Commit-ID: 3fb2f4237bb452eb4e98f6a5dbd5a445b4fed9d0
> Gitweb: http://git.kernel.org/tip/3fb2f4237bb452eb4e98f6a5dbd5a445b4fed9d0
> Author: Andy Lutomirski
> AuthorDate: Wed, 17 Dec 2014 14:48:30 -0800
> Committer: Ingo Molnar
On 12/16/2014 01:58 AM, Juergen Gross wrote:
> VMWare seems not to emulate the PAT MSR correctly: reaeding
> MSR_IA32_CR_PAT returns 0 even after writing another value to it.
>
> Detect this bug and don't use the read value if it is 0.
>
> Commit bd809af16e3ab1f8d55b3e2928c47c67e2a865d2 ("x86: En
On 12/10/2014 12:49 PM, Linus Torvalds wrote:
> On Wed, Dec 10, 2014 at 12:39 PM, Dave Hansen
> wrote:
>>
>> I misspoke there. I meant SMAP (I placed MPX below its config option).
>
> Ok, I agree on SMAP, we might want to have that be configurable too,
> especially for smaller systems (I *think*
On 12/10/2014 05:03 PM, Luis R. Rodriguez wrote:
>
> This is an issue onloy for for non*-preemptive kernels.
>
> Some of Xen's hypercalls can take a long time and unfortunately for
> *non*-preemptive kernels this can be quite a bit of an issue.
> We've handled situations like this with cond_resch
On 12/10/2014 03:34 PM, Luis R. Rodriguez wrote:
> diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S
> index 344b63f..40b5c0c 100644
> --- a/arch/x86/kernel/entry_32.S
> +++ b/arch/x86/kernel/entry_32.S
> @@ -982,7 +982,28 @@ ENTRY(xen_hypervisor_callback)
> ENTRY(xen_do_upcall)
On 11/19/2014 06:58 PM, nick wrote:
> Greeting Thomas and other kernel coders,
> I am wondering about the fix in the code below and whether this is still
> valid as reading it seems to may no sense as
> we are using completion variables and therefore the delayed version of
> schedule_work_on see
On 11/17/2014 06:23 PM, Greg Thelen wrote:
>
> On Mon, Nov 17 2014, Greg Thelen wrote:
> [...]
>> Given that bss and brk are nobits (i.e. only ALLOC) sections, does
>> file_offset make sense as a load address. This fails with gold:
>>
It really doesn't. We have that information elsewhere.
On 11/10/2014 12:37 PM, Austin S Hemmelgarn wrote:
> On 2014-11-10 12:04, Matthew Garrett wrote:
>> On Mon, Nov 10, 2014 at 11:45:06AM -0500, Austin S Hemmelgarn wrote:
>>
>>> I agree, without it you need PC CMOS RTC support to access the RTC
>>> on most systems, which in turn means that you have t
On 11/04/2014 11:45 AM, tip-bot for Jan Beulich wrote:
> Commit-ID: 97b67ae559947f1e208439a1bf6a734da3087006
> Gitweb: http://git.kernel.org/tip/97b67ae559947f1e208439a1bf6a734da3087006
> Author: Jan Beulich
> AuthorDate: Tue, 4 Nov 2014 08:50:48 +
> Committer: Thomas Gleixner
> Com
On 11/03/2014 01:11 PM, Andy Lutomirski wrote:
> On Tue, Oct 28, 2014 at 4:14 AM, tip-bot for Andy Lutomirski
> wrote:
>> Commit-ID: 2c7577a7583747c9b71f26dced7f696b739da745
>> Gitweb:
>> http://git.kernel.org/tip/2c7577a7583747c9b71f26dced7f696b739da745
>> Author: Andy Lutomirski
>> Au
On 10/31/2014 02:22 PM, Dave Hansen wrote:
>
> -struct bndregs_struct {
> - u64 bndregs[8];
> +struct bndreg_struct {
> + u64 lb; /* lower bound */
> + u64 ub; /* upper bound */
> } __packed;
>
> struct bndcsr_struct {
> @@ -394,7 +395,7 @@ struct xsave_struct {
> struct xsa
On 10/31/2014 01:11 PM, Vivek Goyal wrote:
> On Fri, Oct 31, 2014 at 10:42:51AM -0700, Andi Kleen wrote:
+void __puthex(unsigned long value)
+{
+ char alpha[2] = "0";
+ int bits;
+ unsigned char byte;
>>>
>>> what is 'byte' for? (unused)
>>
>> Well the whole function is
On 10/30/2014 10:03 AM, Prarit Bhargava wrote:
> There have been several times where I have had to rebuild a kernel to
> cause a panic when hitting a WARN() in the code in order to get a crash
> dump from a system. Sometimes this is easy to do, other times (such as
> in the case of a remote admin)
On 10/29/2014 10:17 AM, j...@joshtriplett.org wrote:
>>
>> But this is entirely a style decision, so I leave it up to the x86
>> maintainers ...
>
> I can certainly do that if the x86 maintainers prefer, but that tends to
> produce a net increase in lines of code, as well as duplicating all the
>
On 10/28/2014 10:29 AM, Thomas Gleixner wrote:
> On Tue, 28 Oct 2014, H. Peter Anvin wrote:
>> On 10/28/2014 04:06 AM, Thomas Gleixner wrote:
>>>>
>>>> The available address we can use is lower than FIXADDR_BOOT_START. So
>>>> We will set the k
On 10/28/2014 04:06 AM, Thomas Gleixner wrote:
>>
>> The available address we can use is lower than FIXADDR_BOOT_START. So
>> We will set the kmap boundary below the FIXADDR_BOOT_START, if configure
>> the high memory.
>>
>> If we configure the high memory, the vmalloc reserve area should end
>> up
On 10/27/2014 06:55 AM, Eric Paris wrote:
> My patch was already committed to the -tip urgent branch. I believe any
> optimization should be based on that branch, Richard. If you are trying
> to wrangle every bit of speed out of this, should you
>
> push %esi;
> push %edi;
> CFI_ADJUST_CFA_OFFSE
On x86 we have discussed to combine thread_info and task_struct into a single
allocation with a percpu variable lining pointng at it.
On October 26, 2014 11:09:39 AM PDT, Al Viro wrote:
>On Sun, Oct 26, 2014 at 10:36:45AM -0700, Andy Lutomirski wrote:
>
>> I never said it was the *only* juicy ta
On 10/24/2014 05:22 PM, Andy Lutomirski wrote:
> Is there any good reason not to use vmalloc for x86_64 stacks?
Additional TLB pressure if anything else.
Now, on the flipside: what is the *benefit*?
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
On 10/24/2014 03:09 PM, Andreas Dilger wrote:
> On Oct 24, 2014, at 9:10 AM, Dmitry Vyukov wrote:
>> On Fri, Oct 24, 2014 at 7:04 PM, Sasha Levin wrote:
>>> On 10/24/2014 09:42 AM, Peter Zijlstra wrote:
On Fri, Oct 24, 2014 at 09:23:35AM -0400, Sasha Levin wrote:
>
> i >> 32 may happ
On 10/24/2014 02:05 PM, One Thousand Gnomes wrote:
> On Fri, 24 Oct 2014 19:10:49 +0400
> Dmitry Vyukov wrote:
>
>> On Fri, Oct 24, 2014 at 7:04 PM, Sasha Levin wrote:
>>> On 10/24/2014 09:42 AM, Peter Zijlstra wrote:
On Fri, Oct 24, 2014 at 09:23:35AM -0400, Sasha Levin wrote:
>
>
On 10/23/2014 12:38 PM, Eric Paris wrote:
>>
>> After the call __audit_syscall_entry aren't they already polluted?
>> Isn't that the reason we need to reload EAX?
>
> Well, I guess EAX is special...
>
Because system calls are "asmlinkage", all the parameters are on the
stack, but %eax is used as
to __audit_syscall_entry all we need to do is
>get that
>>> >> > now useless junk off the stack (pair of pops) and reload %eax
>with the
>>> >> > original syscall so other stuff can keep going about it's
>business.
>>> >> >
>>> &g
_entry all we need to do is get that
>> now useless junk off the stack (pair of pops) and reload %eax with
>the
>> original syscall so other stuff can keep going about it's business.
>>
>> Signed-off-by: Eric Paris
>> Cc: Thomas Gleixner
>> Cc: Ingo Moln
On 10/22/2014 02:38 PM, Eric Paris wrote:
>
> It was sent, numerous times, to the x86 list for reviews, and lived in
> -next for 2 complete devel cycles without a complaint. I'm trying to
> get an i386 system to test a fix. But yes, it's total crap.
>
You don't need an i386 system -- you can i
Hi Linus,
This patchset falls under the "maintainers that grovel" clause in the
v3.18-rc1 announcement. We had intended to push it late in the merge
window since we got it into the -tip tree relatively late.
Many of these are relatively simple things, but there are a couple of
key bits, especial
On 10/16/2014 09:47 AM, Boris Ostrovsky wrote:
> diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h
> index 8cd27e0..a78c509 100644
> --- a/arch/x86/include/asm/smp.h
> +++ b/arch/x86/include/asm/smp.h
> @@ -149,7 +149,11 @@ static inline void
> arch_send_call_function_ipi_mask(c
On 10/22/2014 08:32 AM, David Vrabel wrote:
> On 16/10/14 17:47, Boris Ostrovsky wrote:
>> Commit 2ed53c0d6cc9 ("x86/smpboot: Speed up suspend/resume by avoiding
>> 100ms sleep for CPU offline during S3") introduced completions to CPU
>> offlining process. These completions are not initialized on X
On 10/21/2014 03:14 AM, Peter Zijlstra wrote:
> On Mon, Oct 20, 2014 at 04:22:27PM -0400, Pranith Kumar wrote:
>>> Generating a volatile pointer is really not necessary here. This is the only
>>> location where a volatile pointer is being generated for use in asm.
>>>
>>> This commit removes the un
On 10/20/2014 02:57 PM, Andy Lutomirski wrote:
>
> Should I send a replacement for patch 8 or should I let you merge 1-7
> and fold this into the followup series?
>
Please send a replacement.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
On 09/23/2014 10:50 AM, Andy Lutomirski wrote:
>
> Patch 8 removes the vvar that selects the getcpu mode. That vvar
> has been unnecessary for a couple of years, ever since alternative
> patching has worked in the vdso.
>
Is there any fundamental reason to not always use LSL at this point?
On 10/19/2014 01:20 PM, Al Viro wrote:
> On Fri, Oct 17, 2014 at 02:45:03PM -0700, Andy Lutomirski wrote:
>
>> For example, I want to be able to reliably do something like nsenter
>> --namespace-flags-here toybox sh. Toybox's shell is unusual in that
>> it is more or less fully functional, so thi
On 10/17/2014 01:01 PM, Fabian Frederick wrote:
> define MSR_CHUNK_SIZE instead of hard-coded value (8).
>
> Signed-off-by: Fabian Frederick
I don't like the name, as it isn't a "chunk" but the actual width of an MSR.
Furthermore, the last hunk is just plain wrong; the 8 there refers to
the num
oquan He wrote:
>On 10/14/14 at 08:49am, Vivek Goyal wrote:
>> On Mon, Oct 13, 2014 at 01:22:42PM -0400, Vivek Goyal wrote:
>> > On Mon, Oct 13, 2014 at 08:43:00AM -0700, H. Peter Anvin wrote:
>> > > On 10/13/2014 08:19 AM, Vivek Goyal wrote:
>> > > >&
On 10/15/2014 09:03 AM, Prarit Bhargava wrote:
>>
>> It is kind of a messy situation, because this code needs to allocate
>> memory but is run before the secondary CPU is fully up. As such, it is
>> a false positive, at least in some ways.
>
> Interesting -- FWIW, I can reproduce this 100% of the
On 10/09/2014 08:35 AM, Prarit Bhargava wrote:
>
> Non-fatal warning seen with latest kernel tree during kernel boot.
>
> WARNING: CPU: 64 PID: 0 at kernel/locking/lockdep.c:2744
> lockdep_trace_alloc+0xdd/0xe0()
> DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
> Modules linked in:
>
> CPU:
On 10/15/2014 08:38 AM, Jarkko Sakkinen wrote:
> Trampoline code is only needed for SMP and in x86-64 for wakeup
> code. Make it conditional in order to minimize the kernel size.
>
> Signed-off-by: Jarkko Sakkinen
> ---
> arch/x86/realmode/rm/Makefile | 4
> 1 file changed, 4 insertions(+)
On 10/13/2014 08:19 AM, Vivek Goyal wrote:
>>>
>>> This really shouldn't have happened this way on x86-64. It has to happen
>>> this way on i386, but I worry that this may be a serious misdesign in kaslr
>>> on x86-64. I'm also wondering if there is any other fallout of this?
>>
>> I agree. On x8
That's not a justification for change. Claiming no harm is nevessary but not
sufficient.
On October 12, 2014 9:53:32 AM PDT, Chuck Ebbert wrote:
>On Sun, 12 Oct 2014 09:47:53 -0700
>"H. Peter Anvin" wrote:
>
>[replying to the list this time, sigh]
>
>>
We changed this to asm because the C broke some compilers. Why are you
changing it back?
On October 12, 2014 9:43:53 AM PDT, Chuck Ebbert wrote:
>Use C instead of asm for accessing the stack pointer. And define some
>macros to make the code easier to understand.
>
>Signed-off-by: Chuck Ebbert
On 10/10/2014 08:14 PM, Baoquan He wrote:
On 10/08/14 at 03:27pm, Vivek Goyal wrote:
On Wed, Oct 08, 2014 at 08:09:59AM -0700, H. Peter Anvin wrote:
Sorry... this makes no sense.
For x86-64, there is no direct connection between the physical and
virtual address spaces that the kernel runs
On 10/08/2014 12:49 PM, Chris Wilson wrote:
>
> Indeed, this appears to be the explanation. (And here I thought PAT
> superseded mtrrs - i915.ko stopped trying to use assign an mtrr for its
> GTT quite a while ago.)
>
> Replacing the stop_machine there with on_each_cpu does the trick:
>
It shou
On 10/08/2014 02:09 PM, Chuck Ebbert wrote:
>>
>> Breaking cross-compilation is not okay, though, regardless of what
>> Fedora does. It should be okay to, for example, build an i386 kernel on
>> an ARM box.
>>
>
> I think they tried that for a while, and ended up chasing compiler
> and makefile b
On 10/08/2014 01:46 PM, Chuck Ebbert wrote:
>
> Fedora doesn't cross-compile i686 builds because of problems like
> this. It sets up an i386 chroot and runs all native tools inside of
> it.
>
Breaking cross-compilation is not okay, though, regardless of what
Fedora does. It should be okay to, f
This still has the cross-build problems, no?
On October 8, 2014 12:49:24 PM PDT, Peter Foley wrote:
>vdso_standalone_test_x86 needs -lgcc_s to build succesfully on 32bit.
>
>Signed-off-by: Peter Foley
>---
> Documentation/vDSO/Makefile | 3 +++
> 1 file changed, 3 insertions(+)
>
>diff --git a/Do
On 10/01/2014 06:52 AM, Vivek Goyal wrote:
>
> Hi Peter,
>
> I think there is some confusion. I will try to clarify.
>
> If we have 32bit signed overflow, we will not have a functional kernel.
> And that's the message we get when we try to kexec with
> CONFIG_RANDOMIZE_BASE=y.
>
And how does t
On 08/30/2014 05:47 AM, Paul Bolle wrote:
>
> Obviously, this can only break compiling those libraries, or other
> users. It can't break already compiled binaries. Besides I don't think
> those libraries, etc actually exist. Maximilian mentioned klibc in
> January, but I wasn't able to find a vers
On 10/06/2014 09:45 AM, Andy Lutomirski wrote:
> On Mon, Oct 6, 2014 at 9:41 AM, H. Peter Anvin wrote:
>> On 10/06/2014 09:39 AM, Andy Lutomirski wrote:
>>> On Wed, Oct 1, 2014 at 11:49 AM, Andy Lutomirski
>>> wrote:
>>>> Anish Bhatt noticed that
On 10/01/2014 12:49 PM, Andy Lutomirski wrote:
> On Wed, Oct 1, 2014 at 11:49 AM, Andy Lutomirski wrote:
>> The NT flag doesn't do anything in long mode other than causing IRET
>> to #GP. Oddly, CPL3 code can still set NT using popf.
>>
>
> [...]
>
>> +
>> + /*
>> +* Sysenter does
On 10/06/2014 09:39 AM, Andy Lutomirski wrote:
> On Wed, Oct 1, 2014 at 11:49 AM, Andy Lutomirski wrote:
>> Anish Bhatt noticed that user programs can set RFLAGS.NT before
>> syscall or sysenter, and the kernel entry code doesn't filter out
>> NT. This causes kernel C code and, depending on threa
Yes, it is.
On October 3, 2014 3:53:08 PM PDT, Andy Lutomirski wrote:
>On Fri, Oct 3, 2014 at 3:48 PM, Chuck Ebbert
>wrote:
>> On Fri, 3 Oct 2014 23:41:24 +0200
>> Oleg Nesterov wrote:
>>
>>> On 10/03, Chuck Ebbert wrote:
>>> >
>>> > > [ 921.917752] ? ___preempt_schedule_context
>(arch/x86/lib
On 10/01/2014 12:49 PM, Andy Lutomirski wrote:
> On Wed, Oct 1, 2014 at 11:49 AM, Andy Lutomirski wrote:
>> The NT flag doesn't do anything in long mode other than causing IRET
>> to #GP. Oddly, CPL3 code can still set NT using popf.
>>
>
> [...]
>
>> +
>> + /*
>> +* Sysenter does
On 10/01/2014 11:28 AM, Andy Lutomirski wrote:
>
> #define __EXTRA_CLOBBER \
> , "rcx", "rbx", "rdx", "r8", "r9", "r10", "r11", \
> - "r12", "r13", "r14", "r15"
> + "r12", "r13", "r14", "r15", "flags"
>
I was under the impression that gcc *always* assumes the flags were
clo
On 10/01/2014 11:28 AM, Andy Lutomirski wrote:
> Anish Bhatt noticed that user programs can set RFLAGS.NT before
> syscall or sysenter, and the kernel entry code doesn't filter out
> NT. This causes kernel C code and, depending on thread flags, the
> exit slow path to run with NT set.
>
> The for
On 10/01/2014 11:08 AM, Kees Cook wrote:
>>
>> The use of (u64) in the assignment to avoid.start gives a nuisance
>> warning on 32 bits.
>
> Ah, good catch! This should be (unsigned long), I think. Shall I send
> a follow-up patch, or do you want to fix this directly?
>
Please do.
In theory it
701 - 800 of 6113 matches
Mail list logo
