On December 19, 2015 8:11:50 PM PST, ebied...@xmission.com wrote:
>ebied...@xmission.com (Eric W. Biederman) writes:
>
In that system ptys simply did not work after boot when I tested
associating /dev/ptmx with the first mount of the devpts
>filesystem.
>>>
>>> Assuming userspace isn't br
On 12/18/15 15:37, Dmitry V. Levin wrote:
Check for TS_COMPAT instead of TIF_IA32 to distinguish ia32 tasks
from 64-bit tasks.
Check for __X32_SYSCALL_BIT only if CONFIG_X86_X32_ABI is defined.
Signed-off-by: Dmitry V. Levin
Cc: Elvira Khabirova
Cc: Andy Lutomirski
---
arch/x86/kernel/signa
On 12/18/2015 12:49 PM, Andy Lutomirski wrote:
>
> IOW, I like my idea in which signal delivery always sets PKRU to the
> application-requested-by-syscall values and sigreturn restores it.
> Kinda like sigaltstack, but applies to all signals and affects PKRU
> instead of RSP.
>
I think this is t
On December 18, 2015 10:50:40 AM PST, "Luis R. Rodriguez"
wrote:
>On Thu, Dec 17, 2015 at 08:25:19PM -0800, H. Peter Anvin wrote:
>> On 12/17/15 15:46, Luis R. Rodriguez wrote:
>> >
>> > I explain why I do that there but the gist of it is that on Linux
>
On December 17, 2015 9:29:21 PM PST, Andy Lutomirski
wrote:
>On Dec 17, 2015 6:53 PM, "Dave Hansen"
>wrote:
>>
>> On 12/17/2015 06:32 PM, Andy Lutomirski wrote:
>> > On Thu, Dec 17, 2015 at 6:13 PM, Dave Hansen
> wrote:
>> >> But what about the register state when delivering a signal? Don't
>we
On 12/17/15 20:25, H. Peter Anvin wrote:
>
> /* DECLARE_LINKTABLE_RO */
> extern const struct foo tablename[], tablename__end[];
>
> /* DEFINE_LINKTABLE_RO */
> DECLARE_LINKTABLE_RO(struct foo, tablename);
>
> const struct
> foo__attribute__((used,section(".roda
On 12/17/15 15:46, Luis R. Rodriguez wrote:
>
> I explain why I do that there but the gist of it is that on Linux we may also
> want stronger semantics for specific linker table solutions, and solutions
> such
> as those devised on the IOMMU init stuff do memmove() for sorting depending on
> sema
On 12/17/15 12:48, Andy Lutomirski wrote:
>
> I'm entirely ignorant of anything going on in gPXE/iPXE.
>
> Can you explain what a linker table *does*? It looks like all you've
> done in this patch is to move code around. What actually happens?
>
A linker table is a data structure that is stit
I think we can make this even more generic. In particular, I would love
to see a solution for link tables that:
a) can be used for any kind of data structures, not just function
pointers (the latter is a specialization of the former);
b) doesn't need any changes to the linker scripts once the ini
On December 15, 2015 2:16:29 PM PST, "Luis R. Rodriguez"
wrote:
>From: "Luis R. Rodriguez"
>
> A long time ago in a galaxy far,
> far away...
>
>Konrad Rzeszutek Wilk posted patches which eventually got merged to
>help
>with modularizing the IOMMUs we have on x86 [0]. Thi
On 12/15/15 06:08, Pavel Machek wrote:
>
> But it still says:
>
> address sizes : 32 bits physical, 32 bits virtual
>
> I thought pae would be 36bit virtual?
>
It should be unless the CPU reports otherwise, which your CPU probably
does (a CPUID dump might be useful.)
-hpa
--
To unsu
On December 14, 2015 4:49:51 PM PST, Jeff Merkey wrote:
>On 12/14/15, Jeff Merkey wrote:
>> Please consider the attached patch.
>>
>> SUMMARY
>>
>> This patch corrects a hard lockup failure of the system kernel if the
>> operating system receives a breakpoint exception at a code execution
>> addr
On 12/14/15 13:03, Jeff Merkey wrote:
> Please consider the attached patch.
>
> I have reviewed all the code that touches this patch and have
> determined it will function and support all of the software that
> depends on this handler properly. I have compiled and tested this
> patch with a test
On 12/14/15 11:47, Peter Hurley wrote:
> On 12/11/2015 11:40 AM, Eric W. Biederman wrote:
>> Forcing newinstance for every mount of the devpts filesystem actually
>> requires the association between /dev/ptmx and the currently mounted
>> instance of devpts at /dev/pts. Simply remembering the first
On 12/11/15 09:52, Daniel Cashman wrote:
> From: dcashman
>
> x86: arch_mmap_rnd() uses hard-coded values, 8 for 32-bit and 28 for
> 64-bit, to generate the random offset for the mmap base address.
> This value represents a compromise between increased ASLR
> effectiveness and avoiding address-sp
On December 11, 2015 3:16:48 PM PST, Andy Lutomirski
wrote:
>On Fri, Dec 11, 2015 at 3:07 PM, H. Peter Anvin wrote:
>> On December 11, 2015 3:00:49 PM PST, Andy Lutomirski
> wrote:
>>>On Fri, Dec 11, 2015 at 2:58 PM, Jann Horn wrote:
>>>> On Fri, Dec 1
ndy Lutomirski writes:
>>> >
>>> >> On Fri, Dec 11, 2015 at 2:07 PM, H. Peter Anvin
>wrote:
>>> >>> On 12/11/15 13:48, Andy Lutomirski wrote:
>>> >>>> On Fri, Dec 11, 2015 at 1:11 PM, Eric W. Biederman
>>> >>&g
On December 11, 2015 2:35:16 PM PST, ebied...@xmission.com wrote:
>Andy Lutomirski writes:
>
>> On Fri, Dec 11, 2015 at 2:07 PM, H. Peter Anvin
>wrote:
>>> On 12/11/15 13:48, Andy Lutomirski wrote:
>>>> On Fri, Dec 11, 2015 at 1:11 PM, Eric W. Biederma
On 12/11/15 14:24, Andy Lutomirski wrote:
>
> To do the whole shebang at once:
>
> ioctl(ptmx_fd, TIOCWHATEVER, fd_to_devpts_mount);
>
> returns the slave number if fd_to_devpts_mount points to the right
> place or an error if not.
>
> ptsname(fd) logically does:
>
> fd_to_devpts_mount = open(
On 12/11/15 14:12, Andy Lutomirski wrote:
>>
>> For the newinstance case st_dev should match between the master and the
>> slave. Unfortunately this is not the case for a legacy ptmx, as a
>> stat() on the master descriptor still returns the st_dev, st_rdev, and
>> st_ino for the ptmx device node.
On 12/11/15 13:48, Andy Lutomirski wrote:
> On Fri, Dec 11, 2015 at 1:11 PM, Eric W. Biederman
> wrote:
>> Al Viro writes:
>>
>>> On Fri, Dec 11, 2015 at 01:40:40PM -0600, Eric W. Biederman wrote:
>>>
+inode = path.dentry->d_inode;
+filp->f_path = path;
+filp->f_inode =
On December 8, 2015 12:30:06 PM PST, Kees Cook wrote:
>On Tue, Dec 8, 2015 at 6:19 AM, Borislav Petkov wrote:
>> On Tue, Dec 08, 2015 at 12:25:57PM +, Matt Fleming wrote:
>>> On Mon, 07 Dec, at 11:10:43PM, Kosuke Tatsukawa wrote:
>>> >
>>> > Thank you pointing that out.
>>> >
>>> > linux-4.4-
On December 4, 2015 2:48:37 PM PST, Borislav Petkov wrote:
>On Fri, Dec 04, 2015 at 02:35:38PM -0800, H. Peter Anvin wrote:
>> How about this: it is easy too easy to hard code MSR accesses, and
>the
>> last things we need is alien non-GPL drivers doing their own
>low-lev
On December 4, 2015 2:14:46 PM PST, Peter Zijlstra wrote:
>On Fri, Dec 04, 2015 at 09:51:02AM -0800, Jacob Pan wrote:
>> On Fri, 4 Dec 2015 09:22:56 +0100
>> Peter Zijlstra wrote:
>>
>> > Also, yuck @ powercap/intel_rapl.c for doing rdmsr_on_cpu() +
>> > wrmsr_on_cpu() all over the place.
>> Can
On December 4, 2015 10:30:17 AM PST, Borislav Petkov wrote:
>On Fri, Dec 04, 2015 at 10:28:02AM -0800, Andi Kleen wrote:
>> Because making them GPL would prevent any non GPL driver from
>> using MSRs with tracing compiled in, which doesn't make any sense.
>
>I know what EXPORT_SYMBOL_GPL means - I
On 12/01/15 17:26, Elliott, Robert (Persistent Memory) wrote:
Per an hpa suggestion, I compared two versions of grub:
upstream grub (with "linux" in grub.cfg):
tboot_probe boot_params[0] = 0080 0070
tboot_probe boot_params[16] = 100400032000 00913000
tboot_pr
On 12/01/15 14:18, Sinclair Yeh wrote:
> These macros will be used by multiple VMWare modules for handling
> host communication.
> + __asm__ __volatile__ ("inl %%dx" : \
This is odd at best; the standard assembly form of this instruction is:
inl (%dx),%ea
On 11/25/15 16:15, PaX Team wrote:
> On 25 Nov 2015 at 15:31, Kees Cook wrote:
>
>> diff --git a/include/asm-generic/vmlinux.lds.h
>> b/include/asm-generic/vmlinux.lds.h
>> index c4bd0e2c173c..772c784ba763 100644
>> --- a/include/asm-generic/vmlinux.lds.h
>> +++ b/include/asm-generic/vmlinux.lds.
On 11/30/15 13:33, Kees Cook wrote:
>>
>> I think what should do is have a debug option which can be set to "rw",
>> "log" or "oops"; the latter should probably be the default.
>
> Can someone write that patch, and then I will include it in the
> series? I haven't touched fault handler code, and i
On 11/29/15 00:05, Ingo Molnar wrote:
>
> * Andy Lutomirski wrote:
>
- print a warning and a backtrace, and just mark the page read-write
so that the machine survives, but we get notified and can fix whatever
broken code
>>>
>>> This seems very easy to add. Should I basically rev
On 11/25/2015 10:54 AM, Kees Cook wrote:
>>
>> We should not wait for compile-time support, that doesn't make any
>> sense. What would be useful would be a way to override this on the
>> command line -- that way, if disabling RO or RO-after-init memory makes
>> something work, we have an instant d
On 11/25/15 01:13, Mathias Krause wrote:
>
> While having that annotation makes perfect sense, not only from a
> security perspective but also from a micro-optimization point of view
> (much like the already existing __read_mostly annotation), it has its
> drawbacks. Violating the "r/o after init"
On 11/16/15 13:25, Thomas Gleixner wrote:
> On Mon, 16 Nov 2015, Borislav Petkov wrote:
>> -/*
>> - * disable flag for tsc. Takes effect by clearing the TSC cpu flag
>> - * in cpu/common.c
>> - */
>> -int __init notsc_setup(char *str)
>> +/* Disable the TSC feature flag to avoid further TSC use. */
On 11/16/15 12:22, Borislav Petkov wrote:
>
> Huh, so what's wrong with a jump:
>
> jmp 1f
> swapgs
> 1:
>
What is the point of that jump?
>> If it would make you feel better, it could be X86_BUG_XENPV :-p
>
> That doesn't matter - I just don't want to open the flood gates o
On 11/06/15 15:17, Dan Williams wrote:
>>
>> Is it really required to do that on all cpus?
>
> I believe it is, but I'll double check.
>
It's required on all CPUs on which the DAX memory may have been dirtied.
This is similar to the way we flush TLBs.
-hpa
--
To unsubscribe from this
On November 5, 2015 3:59:46 PM PST, Dan Williams
wrote:
>On Wed, Oct 28, 2015 at 3:51 PM, Ross Zwisler
> wrote:
>> On Wed, Oct 28, 2015 at 06:24:29PM -0400, Jeff Moyer wrote:
>>> Ross Zwisler writes:
>>>
>>> > This series implements the very slow but correct handling for
>>> > blkdev_issue_flush
On 11/05/15 10:56, Boris Ostrovsky wrote:
> The range between 0x8000 and 0x87ff is reserved
> for hypervisor and therefore we should not try to follow PGD's indexes
> corresponding to those addresses.
>
> While this has alsways been a problem, with commit e1a58320a38d ("x86
On November 4, 2015 4:50:23 PM PST, Amanieu d'Antras wrote:
>x86 can't use the generic versions because it needs to support
>x32, so we replace the ad-hoc implementations with something
>that is closer to the generic versions.
>
>This is done by completely replacing the existing code with the
>gen
On 10/20/2015 10:04 AM, Borislav Petkov wrote:
> On Tue, Oct 20, 2015 at 09:58:18AM -0700, H. Peter Anvin wrote:
>> I would like to keep nosmap until SMAP hardware is more ubiquitous
>> since SMAP is vulnerable to kernel bugs. We have already had a case
>> where a maintainer
s they're not needed anymore.
>
>Requested-by: "H. Peter Anvin"
>Signed-off-by: Borislav Petkov
>---
> Documentation/kernel-parameters.txt | 10 --
> arch/x86/kernel/cpu/common.c| 22 --
> 2 files changed, 32 deletions(-)
>
>di
On October 14, 2015 2:39:58 PM PDT, Andy Lutomirski wrote:
>On Wed, Oct 14, 2015 at 2:00 PM, Matt Fleming
> wrote:
>> On Wed, 14 Oct, at 09:22:03AM, Andy Lutomirski wrote:
>>> On Wed, Oct 14, 2015 at 6:52 AM, Matt Fleming
> wrote:
>>> > (Pulling in luto for low-level x86 fu)
>>> >
>>> > On Wed, 14
On 10/06/2015 01:29 PM, Pranith Kumar wrote:
> On Tue, Oct 6, 2015 at 4:16 PM, H. Peter Anvin wrote:
>>
>> NAK. We already have the "+m" for exactly this reason; adding an
>> explicit memory clobber should only be used to prevent movement of
>> *other* memo
On 10/06/2015 11:54 AM, Pranith Kumar wrote:
> We are reading from memory locations pointed to by p1 and p2 in the asm
> block. Add a memory clobber flag to make gcc aware of this.
>
> Signed-off-by: Pranith Kumar
> ---
> arch/x86/include/asm/cmpxchg.h | 3 ++-
> 1 file changed, 2 insertions(+),
On October 5, 2015 1:22:44 PM PDT, Linus Torvalds
wrote:
>We could probably do them outside the loop, rather than tightly around
>the actual move instructions. Peter (hpa), is there some sane
>interface to try to do that?
There are... in particular the get_user_try/catch mechanism, used among ot
On 09/21/2015 09:36 AM, Linus Torvalds wrote:
>
> How many msr reads are so critical that the function call
> overhead would matter? Get rid of the inline version of the _safe()
> thing too, and put that thing there too.
>
Probably only the ones that may go in the context switch path.
-
No, it is a natural result of an implemention which treats setting the A bit as
an abnormal flow (e.g. in microcode as opposed to hardware).
On September 29, 2015 7:11:59 PM PDT, ebied...@xmission.com wrote:
>"H. Peter Anvin" writes:
>
>> On 09/29/2015 06:20 PM, E
On 09/29/2015 06:20 PM, Eric W. Biederman wrote:
> Linus Torvalds writes:
>
>> 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
On 09/29/2015 06:16 PM, Andy Lutomirski wrote:
>
> Can we at least do 1:1 without an offset on arm64? Given that Linux
> seems to be more of a reference on arm64 than Windows is, maybe that
> would give everyone something vaguely sane to work with.
>
I have no idea. That's a question for the A
On 09/27/2015 12:06 AM, Ingo Molnar wrote:
>
> * Ard Biesheuvel wrote:
>
>>> If we allocate the EFI runtime as a single virtual memory block then issues
>>> like rounding between sections does not even come up as a problem: we map
>>> the
>>> original offsets and sizes byte by byte.
>>
>> Wel
On 09/29/2015 07:36 AM, Matt Fleming wrote:
>
> That's a pretty good summary for x86. I think specifically the reason
> we map the EFI memmap entries "backwards" (entry N has higher VA than
> entry N+1) is because the code was easier to write that way, but
> you'll know better than me ;-)
>
The
On 09/27/2015 11:16 PM, Ingo Molnar wrote:
>
> So the question is, what does Windows do?
>
> PC firmware is a hostile environment for Linux, to be compatible the best we
> can
> do is to mimic the environment that the firmware is tested under - i.e. try
> to use
> the firmware in the way Wind
On 09/29/2015 11:02 AM, Andy Lutomirski wrote:
> On Tue, Sep 29, 2015 at 10:50 AM, Linus Torvalds
> wrote:
>> 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
Ugh. Didn't realize that.
On September 29, 2015 11:22:04 AM PDT, Andy Lutomirski
wrote:
>On Tue, Sep 29, 2015 at 11:18 AM, H. Peter Anvin wrote:
>> SGDT would be easy to use, and it is logical that it is faster since
>it reads an internal register. SIDT does too but unl
:
>>
>>
>> * Denys Vlasenko wrote:
>>
>> > On 09/28/2015 09:58 AM, Ingo Molnar wrote:
>> > >
>> > > * Denys Vlasenko wrote:
>> > >
>> > >> On 09/26/2015 09:50 PM, H. Peter Anvin wrote:
>> > >>> NAK.
On 09/29/2015 10:06 AM, Borislav Petkov wrote:
> On Tue, Sep 29, 2015 at 06:25:46PM +0200, Ksenija Stanojevic wrote:
>> Fix build warnings:
>>
>> error: implicit declaration of function ‘olpc_board_at_least’
>> [-Werror=implicit-function-declaration]
>>
>> error: implicit declaration of function ‘
Need to fix. Not sure where the rwx mapping comes from.
On September 28, 2015 3:05:33 PM PDT, Kees Cook wrote:
>On Mon, Sep 28, 2015 at 2:16 PM, H. Peter Anvin wrote:
>> On 09/25/2015 12:22 AM, Ingo Molnar wrote:
>>>>
>>>> To me it looks like another align
On 09/25/2015 12:22 AM, Ingo Molnar wrote:
>>
>> To me it looks like another alignment/padding issue like got fixed
>> before. The space between __ex_table and rodata is (seems?) unused, so
>> the default page table permissions end up being W+X. Can we fix the
>> default to be NX instead? It'll mak
ys Vlasenko
>CC: Ingo Molnar
>CC: Andy Lutomirski
>CC: "H. Peter Anvin"
>CC: Borislav Petkov
>CC: Brian Gerst
>CC: x...@kernel.org
>CC: linux-kernel@vger.kernel.org
>---
> arch/x86/kernel/signal.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
.
On September 26, 2015 1:09:17 PM PDT, Ard Biesheuvel
wrote:
>
>> On 26 sep. 2015, at 12:57, Matt Fleming
>wrote:
>>
>>> On Sat, 26 Sep, at 12:49:26PM, H. Peter Anvin wrote:
>>>
>>> It is still a hack unless all relative offsets are preserved. That
&
080 cpu_gdt <<<
>HERE
> 00016000 wO .data..percpu 0018 cpu_tlbstate
>...
> 00018418 g .data..percpu __per_cpu_end
>
>Run-tested on a 144 CPU machine.
>
>Signed-off-by: Denys Vlas
It is still a hack unless all relative offsets are preserved. That is actually
simpler, even: no sorting necessary.
On September 26, 2015 11:15:57 AM PDT, Ard Biesheuvel
wrote:
>On 26 September 2015 at 10:20, H. Peter Anvin wrote:
>> I think it "works" because the affect
I think it "works" because the affected BIOSes don't put spaces between the
chunks. I have discussed this with Matt.
On September 26, 2015 10:01:14 AM PDT, Andy Lutomirski
wrote:
>On Fri, Sep 25, 2015 at 10:56 PM, Ingo Molnar wrote:
>>
>> So this commit worries me.
>>
>> This bug is a good fi
On 08/13/2014 01:06 PM, Arnd Bergmann wrote:
> On Wednesday 13 August 2014 03:06:53 Ben Hutchings wrote:
>>> On the kernel side, it also adds more complexity, where we have to add
>>> even more complex compat support for 64bit systems to handle all the
>>> various 32bit applications possible.
>> [.
However, the difference between one CONFIG and another is quite frankly crazy.
We should explicitly use the safe versions where this is appropriate, and then
yes, we should do this.
Yet another reason the paravirt code is batshit crazy.
On September 17, 2015 2:31:34 AM PDT, Borislav Petkov wr
On 09/14/2015 06:35 AM, Ingo Molnar wrote:
>>
>> I missed sys_ipc entirely.
>>
>> Ingo, Thomas, want to just wire those up, too? I can send a patch
>> next week, but it'll be as trivial as the socket one.
>
> Yeah, sure - split out system calls are so much better (and slightly faster)
> than
>
On 09/14/2015 03:50 PM, Palmer Dabbelt wrote:
> While I don't think this was ever meant to be exposed to userspace, if
> anyone is using it then this will at least provide a correct (if
> unlikely) definition.
>
> MAX_RAW_MINORS used to be used in the kernel, where it's been replaced
> with CONFIG
d submit a patch to add a comment, but
this version is:
Nacked-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 r
On 09/02/2015 02:48 AM, Geert Uytterhoeven wrote:
>
> Should all other architectures follow suit?
> Or should we follow the s390 approach:
>
It is up to the maintainer(s), largely dependent on how likely you are
going to want to support this in your libc, but in general, socketcall
is an abomina
On 09/01/2015 08:03 AM, Michael S. Tsirkin wrote:
>>>
>>> Hmm - so do you take back the ack?
>>
>> I have no strong feelings either way, it simply strikes me as misguided to
>> explicitly optimize for something that is listed as a high overhead
>> instruction.
>>
>
> [mst@robin test]$ diff a.c
Presumably because gcc can't generate bt... whether or not it is worth it is
another matter.
On August 30, 2015 11:05:49 PM PDT, Ingo Molnar wrote:
>
>* Michael S. Tsirkin wrote:
>
>> +static __always_inline int __constant_test_bit(long nr, const
>unsigned long *addr)
>> +{
>> +return ((1UL
On 08/23/2015 04:45 AM, tip-bot for Andy Lutomirski wrote:
> Commit-ID: 47edb65178cb7056c2eea0b6c41a7d8c84547192
> Gitweb: http://git.kernel.org/tip/47edb65178cb7056c2eea0b6c41a7d8c84547192
> Author: Andy Lutomirski
> AuthorDate: Thu, 23 Jul 2015 12:14:40 -0700
> Committer: Ingo Molnar
On 08/20/2015 09:35 PM, Borislav Petkov wrote:
> On Thu, Aug 20, 2015 at 11:22:43AM -0700, H. Peter Anvin wrote:
>> There is a valid reason to do this, which is that currently
>> copy_{to,from}_user() effectively bypass SMAP as they don't verify that
>> the kernel po
gt;> It looks like the code never does, for example, (test_bit() == 1) so
>this
>> change should not have any impact.
>>
>> Cc: Thomas Gleixner
>> Cc: Ingo Molnar
>> Cc: "H. Peter Anvin"
>> Cc: x...@kernel.org
>> Cc: linux-kernel@vger.kernel.
On 08/16/2015 09:16 PM, Borislav Petkov wrote:
> On Mon, Aug 17, 2015 at 11:27:01AM +0800, yalin wang wrote:
>> i just want the x86 copy_from{to,in}_user() function have
>> the same behaviour as other platforms.
>
> Back to the original question from 2 mails ago:
>
> How else would we be able to
ratio between the trap
overhead and the actual emulation code.)
On August 19, 2015 3:33:50 PM PDT, Linus Torvalds
wrote:
>On Wed, Aug 19, 2015 at 3:00 AM, H. Peter Anvin wrote:
>>
>> And I bet if CPUID actually reported the right thing it probably
>would work
>> okay. As I s
On 08/18/2015 11:50 PM, Ingo Molnar wrote:
>
> So I take back my claim, math-emu works. If math-emu grew support for some P6
> era
> FPU instructions it might even boot up generic distros without too much
> trouble.
>
For the record, I used a RedHat 4.1 (not Fedora or RHEL!) userspace.
http
On 08/18/15 23:50, Ingo Molnar wrote:
Ah, so I was able to make math-emu work with the 'no387 nofxsr' boot options.
It turns out that the crash happens due 'no387' not turning off all modern FPU
features in cpufeatures, which confuses the FPU code. (This is a far less severe
bug than math emu n
I should make it clear: I was using a 486SX model in Qemu.
On August 17, 2015 5:19:10 PM PDT, Andy Lutomirski wrote:
>On Mon, Aug 17, 2015 at 5:06 PM, H. Peter Anvin wrote:
>> User space does not need to treat for FPU instructions, except for
>performance reasons, because the ker
, H. Peter Anvin wrote:
>> User space does not need to treat for FPU instructions, except for
>performance reasons, because the kernel emulates the full x87 FPU. So
>it is localized to the kernel.
>
>But user space needs to avoid SSE2 and such, I suspect. In general,
>I'
User space does not need to treat for FPU instructions, except for performance
reasons, because the kernel emulates the full x87 FPU. So it is localized to
the kernel.
On August 17, 2015 4:59:18 PM PDT, Andy Lutomirski wrote:
>On Mon, Aug 17, 2015 at 1:01 AM, Ingo Molnar wrote:
>> So when I r
I ran a hacked Qemu with FPU off.
On August 17, 2015 4:59:18 PM PDT, Andy Lutomirski wrote:
>On Mon, Aug 17, 2015 at 1:01 AM, Ingo Molnar wrote:
>> So when I re-introduced static allocations math-emu started working
>again, to a
>> limited degree: on a modern distro, trying to boot /bin/bash I g
On 08/17/2015 10:17 AM, Linus Torvalds wrote:
> On Mon, Aug 17, 2015 at 9:58 AM, H. Peter Anvin wrote:
>> That is not true. It *does* work, and I have tested it fairly recently.
>
> Ok, so it's not too badly broken. Good.
>
> Also, while it's been a long time s
Let me see when I last treated this... but I thought it was much more recently
than that.
On August 17, 2015 1:01:43 AM PDT, Ingo Molnar wrote:
>
>(Sorry about the late reply, wasn't around on the weekend.)
>
>* Linus Torvalds wrote:
>
>> Now that said, I doubt anybody cares. Since we don't sup
That is not true. It *does* work, and I have tested it fairly recently.
On August 17, 2015 9:47:01 AM PDT, Linus Torvalds
wrote:
>On Mon, Aug 17, 2015 at 1:01 AM, Ingo Molnar wrote:
>>
>> Any objections against removing all of math-emu in v4.3? This would
>simplify the
>> FPU code in various p
On 07/27/2015 10:29 PM, Andy Lutomirski wrote:
> modify_ldt has questionable locking and does not synchronize
> threads. Improve it: redesign the locking and synchronize all
> threads' LDTs using an IPI on all modifications.
>
> This will dramatically slow down modify_ldt in multithreaded
> progr
NAK. This is crazy.
On August 12, 2015 3:30:19 PM PDT, Jan-Simon Moeller wrote:
>Hi all!
>
>> You could mention that this is to fix the clang build. But why is it
>> needed? It isn't that clang just doesn't accept the option, is it?
>> Otherwise we could just use $(call cc-option, -falign-jumps=
One option might be to do the addition in assembly, i.e.:
"i" (key), "i" (index)
... and put the addition into the assembly source.
On August 12, 2015 11:17:17 AM PDT, Boris Ostrovsky
wrote:
>On 08/12/2015 01:46 PM, Peter Zijlstra wrote:
>> On Wed, Aug 12, 2015 at 07:21:05PM +0200, Peter Zijls
Desnoyers ,"linux-...@vger.kernel.org"
,"linux-kernel@vger.kernel.org"
,Peter Zijlstra
Message-ID:
Let me see if I can unbury it - probably not until Monday, though.
On July 31, 2015 11:18:06 PM PDT, Josh Triplett wrote:
>On Fri, Jul 31, 2015 at 09:56:46PM -0700, H. P
On 07/31/2015 09:32 PM, Josh Triplett wrote:
>
> Sure, agreed. But I really hope we don't create new kernel ABIs that
> involve constructs like that.
>
It's worth noting I have pushed for auto-marshalling in general for a
long time, not the least to get rid of the awful syscall(3) wrapper. I
e
On 07/29/2015 09:32 PM, Lee, Chun-Yi wrote:
> When testing hibernate, I found the EFI runtime services was broken
> on some old EFI machines on my hand, Intel DQ57TM development board
> and Acer Gateway Z5WT2 notebook.
>
> After printing the EFI memmap and virtual address mapping on -4G area,
> fo
On 07/28/2015 08:02 AM, Julien Grall wrote:
> Hi all,
>
> This patch series aims to use the memory terminologies described in
> include/linux/mm.h [1] for Linux xen code.
>
> Linux is using mistakenly MFN when GFN is meant, I suspect this is because the
> first support of Xen was for PV. This has
However... perhaps we can do the flags stuff first? There are certainly a ton
of changes we ought to do.
On July 27, 2015 4:58:29 PM PDT, Andy Lutomirski wrote:
>On Mon, Jul 27, 2015 at 4:56 PM, H. Peter Anvin wrote:
>> Sure... but now you have to wrap things in stac/clac. I
There are certainly applications. That just isn't one of them.
On July 27, 2015 4:58:29 PM PDT, Andy Lutomirski wrote:
>On Mon, Jul 27, 2015 at 4:56 PM, H. Peter Anvin wrote:
>> Sure... but now you have to wrap things in stac/clac. I'm not sure I
>see the point sin
Sure... but now you have to wrap things in stac/clac. I'm not sure I see the
point since the code is already pretty much optimal.
On July 27, 2015 4:49:46 PM PDT, Andy Lutomirski wrote:
>On Mon, Jul 27, 2015 at 4:46 PM, H. Peter Anvin wrote:
>> Sure, but that is different than
On 07/27/2015 01:01 PM, Uros Bizjak wrote:
> On Mon, Jul 27, 2015 at 9:04 PM, H. Peter Anvin wrote:
>
>> I wonder if using "set" would be a performance regression over "sbb" for
>> the existing bitops, in which case it would slot quite nicely into this
&
On 07/27/2015 01:38 PM, Andy Lutomirski wrote:
>
> As long as we're thinking about this stuff, there are bunch of places
> where we use exception fixups and do awful things involving translating
> them to error codes. Ideally they'd use as goto instead, but last time
> I checked, GCC was quite pi
On 07/27/2015 10:48 AM, Uros Bizjak wrote:
> From: Uros Bizjak
>
> This patch introduces GCC ASM flags to bitops.
>
> The new functionality depends on __GCC_ASM_FLAG_OUTPUTS__ preprocessor
> symbol, which is automatically set by GCC version 6 or later when
> ASM flags feature is supported.
>
>
On 07/16/2015 12:14 PM, Dave Hansen wrote:
> The FPU rewrite removed the dynamic allocations of 'struct fpu'.
> But, this potentially wastes massive amounts of memory (2k per
> task on systems that do not have AVX-512 for instance).
>
> Instead of having a separate slab, this patch just appends th
Actually we could statically associate a biggerbuffer based on the XCR0
features we support. That would preclude dynamic enabling and really just adds
complexity for no good reason.
On July 14, 2015 12:46:17 PM PDT, Dave Hansen
wrote:
>On 05/05/2015 10:49 AM, Ingo Molnar wrote:
>> @@ -574,12
On 07/01/2015 09:38 AM, Brown, Len wrote:
>
> BTW. I've had a discussion w/ LLNL about their needs,
> both for security and performance. For security, as concluded
> by this thread, a white list is the only way to go.
> I'm thinking a bit-vector of allowed MSR offsets...
> For performance, they a
501 - 600 of 6113 matches
Mail list logo
