On Thu, Mar 27, 2014 at 11:56 AM, Jeremy Allison j...@samba.org wrote:
On Thu, Mar 27, 2014 at 11:46:39AM -0700, Andy Lutomirski wrote:
On Thu, Mar 27, 2014 at 11:26 AM, Jeremy Allison j...@samba.org wrote:
Amen to that :-).
However, after talking with Jeff and Jim at CollabSummit,
I
On Thu, Mar 27, 2014 at 12:30 PM, Jim Lieb jl...@panasas.com wrote:
Rather than inline, I'm responding in the context of Jeremy's comments but I
have to answer others as well. It is Jeremy after all who said my baby was
ugly ;).
Jeremy is right about overloading fd. Maybe I can call it
On 03/27/2014 04:02 AM, Clemens Ladisch wrote:
Feng Tang wrote:
On many new phone/tablet platforms like Baytrail/Merrifield etc,
the HPET are either defeatured or has some problem to be used
as a reliable timer. As these platforms also have X86_64, we
should not make HPET_TIMER default y for
On Thu, Mar 27, 2014 at 1:44 PM, John Stultz john.stu...@linaro.org wrote:
On 03/17/2014 03:22 PM, Stefani Seibold wrote:
This patch add the VDSO time support for the IA32 Emulation Layer.
Due the nature of the kernel headers and the LP64 compiler where the
size of a long and a pointer
On Thu, Mar 27, 2014 at 1:47 PM, Jim Lieb jl...@panasas.com wrote:
On Thursday, March 27, 2014 12:45:30 Andy Lutomirski wrote:
On Thu, Mar 27, 2014 at 12:30 PM, Jim Lieb jl...@panasas.com wrote:
Rather than inline, I'm responding in the context of Jeremy's comments but
I have to answer
On Thu, Mar 27, 2014 at 2:27 PM, John Stultz john.stu...@linaro.org wrote:
On Thu, Mar 27, 2014 at 12:52 PM, Andy Lutomirski l...@amacapital.net wrote:
On 03/27/2014 04:02 AM, Clemens Ladisch wrote:
Feng Tang wrote:
The help text still says:
| You can safely choose Y here. [...]
| Choose N
On Mon, Apr 28, 2014 at 6:39 AM, Serge Hallyn serge.hal...@ubuntu.com wrote:
Quoting Andy Lutomirski (l...@amacapital.net):
On Fri, Apr 25, 2014 at 12:37 PM, Eric W. Biederman
ebied...@xmission.com wrote:
Andy Lutomirski l...@amacapital.net writes:
Unless I'm missing some trick, it's
On 04/28/2014 03:12 PM, Andi Kleen wrote:
From: Andi Kleen a...@linux.intel.com
IvyBridge added new instructions to directly write the fs and gs
64bit base registers. Previously this had to be done with a system
call to write to MSRs. The main use case is fast user space threading
and
that CAP_SYS_IMMUTABLE is needed. If this
gets merged, then it would be better to just drop CAP_SYS_IMMUTABLE
entirely.
Nacked-by: Andy Lutomirski l...@amacapital.net
--
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 Tue, Apr 29, 2014 at 4:06 PM, Theodore Ts'o ty...@mit.edu wrote:
On Tue, Apr 29, 2014 at 03:45:24PM -0700, Andy Lutomirski wrote:
Wait, what?
Inodes aren't owned by user namespaces; they're owned by users. And any
user can arrange to have a user namespace in which they pass
On Tue, Apr 29, 2014 at 4:20 PM, Marian Marinov m...@1h.com wrote:
On 04/30/2014 01:45 AM, Andy Lutomirski wrote:
On 04/29/2014 03:29 PM, Serge Hallyn wrote:
Quoting Marian Marinov (mm-108mbtlg...@public.gmane.org):
On 04/30/2014 01:02 AM, Serge Hallyn wrote:
Quoting Marian Marinov (mm
On Tue, Apr 29, 2014 at 4:47 PM, Stéphane Graber stgra...@ubuntu.com wrote:
On Tue, Apr 29, 2014 at 04:22:55PM -0700, Andy Lutomirski wrote:
On Tue, Apr 29, 2014 at 4:20 PM, Marian Marinov m...@1h.com wrote:
On 04/30/2014 01:45 AM, Andy Lutomirski wrote:
On 04/29/2014 03:29 PM, Serge
On Tue, Apr 29, 2014 at 5:01 PM, Stéphane Graber stgra...@ubuntu.com wrote:
On Tue, Apr 29, 2014 at 04:51:54PM -0700, Andy Lutomirski wrote:
On Tue, Apr 29, 2014 at 4:47 PM, Stéphane Graber stgra...@ubuntu.com wrote:
On Tue, Apr 29, 2014 at 04:22:55PM -0700, Andy Lutomirski wrote:
On Tue
On Tue, Apr 29, 2014 at 5:10 PM, Marian Marinov m...@1h.com wrote:
On 04/30/2014 03:01 AM, Stéphane Graber wrote:
On Tue, Apr 29, 2014 at 04:51:54PM -0700, Andy Lutomirski wrote:
On Tue, Apr 29, 2014 at 4:47 PM, Stéphane Graber stgra...@ubuntu.com
wrote:
On Tue, Apr 29, 2014 at 04:22:55PM
On Tue, Apr 29, 2014 at 5:21 PM, Serge Hallyn serge.hal...@ubuntu.com wrote:
Quoting Andy Lutomirski (l...@amacapital.net):
It should be a nonissue so long as we make sure that a file owned by a
uid outside the scope of the container may not be changed even though
fs_owner_uid is set
On Tue, Apr 29, 2014 at 5:32 PM, Theodore Ts'o ty...@mit.edu wrote:
On Wed, Apr 30, 2014 at 12:16:41AM +, Serge Hallyn wrote:
I forget the details, but there was another case where I wanted to
have the userns which 'owns' the whole fs available. I guess we'd
have to check against that
On Tue, Apr 29, 2014 at 5:44 PM, Serge Hallyn serge.hal...@ubuntu.com wrote:
Quoting Andy Lutomirski (l...@amacapital.net):
On Tue, Apr 29, 2014 at 5:21 PM, Serge Hallyn serge.hal...@ubuntu.com
wrote:
Quoting Andy Lutomirski (l...@amacapital.net):
It should be a nonissue so long as we
On Wed, Apr 30, 2014 at 10:47 AM, Kees Cook keesc...@google.com wrote:
On Wed, Apr 23, 2014 at 10:06 AM, Nathan Lynch nathan_ly...@mentor.com
wrote:
On 04/23/2014 11:30 AM, H. Peter Anvin wrote:
On 04/21/2014 09:52 AM, Nathan Lynch wrote:
Hi x86/vdso people,
I've been working on adding a
On Wed, Apr 30, 2014 at 11:13 AM, Kees Cook keesc...@google.com wrote:
On Wed, Apr 30, 2014 at 10:52 AM, Andy Lutomirski l...@amacapital.net wrote:
On Wed, Apr 30, 2014 at 10:47 AM, Kees Cook keesc...@google.com wrote:
On Wed, Apr 23, 2014 at 10:06 AM, Nathan Lynch nathan_ly...@mentor.com
On Wed, Apr 30, 2014 at 1:05 PM, Kees Cook keesc...@google.com wrote:
On Wed, Apr 30, 2014 at 11:30 AM, Andy Lutomirski l...@amacapital.net wrote:
On Wed, Apr 30, 2014 at 11:13 AM, Kees Cook keesc...@google.com wrote:
On Wed, Apr 30, 2014 at 10:52 AM, Andy Lutomirski l...@amacapital.net
wrote
On 04/29/2014 11:26 AM, Theodore Ts'o wrote:
On Tue, Apr 29, 2014 at 07:51:08PM +0200, Florian Weimer wrote:
I've got a (physical) machine where it happens after ten seconds, or much
longer if there is no activity.
I've seen cases where on the first boot of virtual machines, the SSH key was
On Tue, Apr 29, 2014 at 9:52 PM, H. Peter Anvin h...@zytor.com wrote:
On 04/29/2014 04:39 PM, Andi Kleen wrote:
Case 3 is annoying. If nothing tries to change the user gs base, then
everything is okay because the user gs base and the kernel gs bases are
equal. But if something does try to
On Wed, Apr 30, 2014 at 4:44 PM, Andy Lutomirski l...@amacapital.net wrote:
On Tue, Apr 29, 2014 at 9:52 PM, H. Peter Anvin h...@zytor.com wrote:
On 04/29/2014 04:39 PM, Andi Kleen wrote:
Case 3 is annoying. If nothing tries to change the user gs base, then
everything is okay because the user
On Thu, May 1, 2014 at 8:05 AM, ty...@mit.edu wrote:
On Wed, Apr 30, 2014 at 09:05:00PM -0700, H. Peter Anvin wrote:
Giving the guest a seed would be highly useful, though. There are a
number of ways to do that; changing the boot protocol is probably
only useful if Qemu itself bouts the
On Thu, May 1, 2014 at 8:35 AM, Andy Lutomirski l...@amacapital.net wrote:
On Thu, May 1, 2014 at 8:05 AM, ty...@mit.edu wrote:
On Wed, Apr 30, 2014 at 09:05:00PM -0700, H. Peter Anvin wrote:
Giving the guest a seed would be highly useful, though. There are a
number of ways to do
On Thu, May 1, 2014 at 11:59 AM, H. Peter Anvin h...@zytor.com wrote:
On 05/01/2014 11:53 AM, Andy Lutomirski wrote:
A CPUID leaf or an MSR advertised by a CPUID leaf has another
advantage: it's easy to use in the ASLR code -- I don't think there's
a real IDT, so there's nothing like
On May 1, 2014 12:26 PM, ty...@mit.edu wrote:
On Thu, May 01, 2014 at 12:02:49PM -0700, Andy Lutomirski wrote:
Is RDSEED really reasonable here? Won't it slow down by several
orders of magnitude?
That is I think the biggest problem; RDRAND and RDSEED are fast if
they are native
PDT, Andy Lutomirski l...@amacapital.net wrote:
On May 1, 2014 12:26 PM, ty...@mit.edu wrote:
On Thu, May 01, 2014 at 12:02:49PM -0700, Andy Lutomirski wrote:
Is RDSEED really reasonable here? Won't it slow down by several
orders of magnitude?
That is I think the biggest problem; RDRAND
On Thu, May 1, 2014 at 1:39 PM, ty...@mit.edu wrote:
On Thu, May 01, 2014 at 01:32:55PM -0700, Andy Lutomirski wrote:
On Thu, May 1, 2014 at 1:30 PM, H. Peter Anvin h...@zytor.com wrote:
RDSEED is not synchronous. It is, however, nonblocking.
What I mean is: IIUC it's reasonable to call
On Thu, May 1, 2014 at 2:01 PM, H. Peter Anvin h...@zytor.com wrote:
On 05/01/2014 01:56 PM, Andy Lutomirski wrote:
Even if we could emulate RDSEED effectively**, I don't really
understand what the guest is expected to do with it. And I generally
dislike defining an interface with no known
coming
from userspace at the very beginning and, if so, just jumped to the
non-paranoid entry?
That would work, but I doubt it would be worth it.
-Andi
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On Thu, May 1, 2014 at 2:51 PM, Andi Kleen a...@firstfloor.org wrote:
Allowing userspace to prevent itself from being rescheduled by loading
something strange into gsbase seems unfortunate.
The timer tick will eventually catch it, so any delay is tightly
bounded.
What about NO_HZ_FULL?
On Thu, May 1, 2014 at 2:58 PM, H. Peter Anvin h...@zytor.com wrote:
On 05/01/2014 02:15 PM, Andi Kleen wrote:
If usergs == kernelgs, then ebx will always be 1 and we'll never end
up in paranoid_userspace.
You may miss a reschedule in this obscure case. It shouldn't really
happen because
Is it supposed to work? It does, but this seems odd. If the current
behavior is intentional, then I'll submit a patch to add a new mount
flag to turn off ipc. If it's not, then I'll submit a patch to fix
it.
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send
On Thu, May 1, 2014 at 3:28 PM, ty...@mit.edu wrote:
On Thu, May 01, 2014 at 02:06:13PM -0700, Andy Lutomirski wrote:
I still don't see the point. What does this do better than virtio-rng?
I believe you had been complaining about how complicated it was to set
up virtio
On Thu, May 1, 2014 at 3:46 PM, H. Peter Anvin h...@zytor.com wrote:
On 05/01/2014 03:32 PM, Andy Lutomirski wrote:
On Thu, May 1, 2014 at 3:28 PM, ty...@mit.edu wrote:
On Thu, May 01, 2014 at 02:06:13PM -0700, Andy Lutomirski wrote:
I still don't see the point. What does this do better
On Thu, May 1, 2014 at 3:34 PM, Al Viro v...@zeniv.linux.org.uk wrote:
On Thu, May 01, 2014 at 03:20:00PM -0700, Andy Lutomirski wrote:
Is it supposed to work?
Why the hell not? Same as opening a device node on r/o filesystem for
write, or doing the same with FIFO.
You can't bind a socket
namespace unix sockets, but there is
currently no way to control access to FIFOs and sockets with paths
other than relying on DAC or MAC rules.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
fs/namei.c | 2 ++
fs/namespace.c | 4 +++-
fs/proc_namespace.c | 1
On Thu, May 1, 2014 at 4:51 PM, Al Viro v...@zeniv.linux.org.uk wrote:
On Thu, May 01, 2014 at 04:00:49PM -0700, Andy Lutomirski wrote:
On Thu, May 1, 2014 at 3:34 PM, Al Viro v...@zeniv.linux.org.uk wrote:
On Thu, May 01, 2014 at 03:20:00PM -0700, Andy Lutomirski wrote:
Is it supposed
This speeds up my kernel_pf microbenchmark by about 17%. The cfi
annotations need some work.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
My test case is here:
https://gitorious.org/linux-test-utils/linux-clock-tests/source/kernel_pf.c
This could have some other interesting benefits
On Fri, May 2, 2014 at 12:31 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Fri, May 2, 2014 at 12:04 PM, Andy Lutomirski l...@amacapital.net wrote:
This speeds up my kernel_pf microbenchmark by about 17%. The cfi
annotations need some work.
Sadly, performance of page faults
Rather than using 'vdso_enabled' and an awful #define, just call the
parameters vdso32_enabled and vdso64_enabled.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/include/asm/elf.h | 20 +---
arch/x86/um/vdso/vma.c | 2 +-
arch/x86/vdso/vdso32-setup.c
- I think Gold is working (this is a side effect of the rebase)
Andy Lutomirski (6):
x86: Clean up 32-bit vs 64-bit vdso params
x86: Move syscall and sysenter setup into kernel/cpu/common.c
x86: Reimplement vdso.so preparation in build-time C
x86: Move the 32-bit vdso special pages after
This makes the 64-bit and x32 vdsos use the same mechanism as the
32-bit vdso. Most of the churn is deleting all the old fixmap code.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/include/asm/fixmap.h| 10 +++---
arch/x86/include/asm/vvar.h | 20
dynamic relocations, so we won't
silently generate bad vdso images.
(Dynamic relocations are a problem because nothing will even attempt
to relocate the vdso.)
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/ia32/ia32_signal.c | 8 +--
arch/x86/include/asm/elf.h| 7
These definitions had no effect.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/vdso/vdso.lds.S | 7 +--
arch/x86/vdso/vdso32/vdso32.lds.S | 5 +
arch/x86/vdso/vdsox32.lds.S | 7 +--
3 files changed, 3 insertions(+), 16 deletions(-)
diff --git a/arch
This unifies the vdso mapping code and teaches it how to map special
pages at addresses corresponding to symbols in the vdso image. The
new code is used for all vdso variants, but so far only the 32-bit
variants use the new vvar page position.
Signed-off-by: Andy Lutomirski l...@amacapital.net
This just moves code around.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/include/asm/proto.h | 2 --
arch/x86/kernel/cpu/common.c | 32
arch/x86/vdso/vdso32-setup.c | 30 --
3 files changed, 32 insertions(+), 32
On Fri, May 2, 2014 at 2:01 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Fri, May 2, 2014 at 1:30 PM, Thomas Gleixner t...@linutronix.de wrote:
So what about manipulating the stack so that the popf does not enable
interrupts and do an explicit sti to get the benefit of the
On Fri, May 2, 2014 at 2:37 PM, H. Peter Anvin h.peter.an...@intel.com wrote:
On 05/02/2014 02:07 PM, Linus Torvalds wrote:
On Fri, May 2, 2014 at 2:04 PM, Andy Lutomirski l...@amacapital.net wrote:
Because otherwise I'd have to keep track of whether it's a zeroentry
or an errorentry. I
On my box, this saves about 100ns on each interrupt and trap that
happens while running in kernel space. This speeds up my kernel_pf
microbenchmark by about 17%.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
Changes from the RFC:
- Much better comments
- Rewritten to use popq_cfi
On my box, this saves about 100ns on each interrupt and trap that
happens while running in kernel space. This speeds up my kernel_pf
microbenchmark by about 17%.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
Changes from v1:
- Comment fix *facepalm*
Changes from the RFC:
- Much
On Sat, May 3, 2014 at 3:19 PM, H. Peter Anvin h...@zytor.com wrote:
On 05/03/2014 04:24 AM, Steven Rostedt wrote:
On Fri, 02 May 2014 21:03:10 -0700
H. Peter Anvin h...@zytor.com wrote:
I'd really like to see a workload which would genuinely benefit before
adding more complexity. Now...
On Sat, May 3, 2014 at 4:51 PM, Andy Lutomirski l...@amacapital.net wrote:
On Sat, May 3, 2014 at 3:19 PM, H. Peter Anvin h...@zytor.com wrote:
On 05/03/2014 04:24 AM, Steven Rostedt wrote:
On Fri, 02 May 2014 21:03:10 -0700
H. Peter Anvin h...@zytor.com wrote:
I'd really like to see
On May 3, 2014 3:19 PM, H. Peter Anvin h...@zytor.com wrote:
On 05/03/2014 04:24 AM, Steven Rostedt wrote:
On Fri, 02 May 2014 21:03:10 -0700
H. Peter Anvin h...@zytor.com wrote:
I'd really like to see a workload which would genuinely benefit before
adding more complexity. Now... if
I'm testing 39bfe90706ab0f588db7cb4d1c0e6d1181e1d2f9. I'm not sure
what's going on here.
voffset.h contains:
#define VO__end 0x8111c7a0
#define VO__end 0x8db9a000
#define VO__text 0x8100
because
$ nm vmlinux|grep ' _end'
8111c7a0 t _end
8db9a000 B
This code is used during CPU setup, and it isn't strictly speaking
related to the 32-bit vdso. It's easier to understand how this
works when the code is closer to its callers.
This also lets syscall32_cpu_init be static, which might save some
trivial amount of kernel text.
Signed-off-by: Andy
This unifies the vdso mapping code and teaches it how to map special
pages at addresses corresponding to symbols in the vdso image. The
new code is used for all vdso variants, but so far only the 32-bit
variants use the new vvar page position.
Signed-off-by: Andy Lutomirski l...@amacapital.net
These definitions had no effect.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/vdso/vdso.lds.S | 7 +--
arch/x86/vdso/vdso32/vdso32.lds.S | 5 +
arch/x86/vdso/vdsox32.lds.S | 7 +--
3 files changed, 3 insertions(+), 16 deletions(-)
diff --git a/arch
This makes the 64-bit and x32 vdsos use the same mechanism as the
32-bit vdso. Most of the churn is deleting all the old fixmap code.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/include/asm/fixmap.h| 11 ---
arch/x86/include/asm/vvar.h | 20
dynamic relocations, so we won't
silently generate bad vdso images.
(Dynamic relocations are a problem because nothing will even attempt
to relocate the vdso.)
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/ia32/ia32_signal.c | 8 +--
arch/x86/include/asm/elf.h| 7
Rather than using 'vdso_enabled' and an awful #define, just call the
parameters vdso32_enabled and vdso64_enabled.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/include/asm/elf.h | 20 +---
arch/x86/um/vdso/vma.c | 2 +-
arch/x86/vdso/vdso32-setup.c
The early_ioremap code requires that its buffers not span a PMD
boundary. The logic for ensuring that only works if the fixmap is
aligned, so assert that it's aligned correctly.
To make this work reliably, reserve_top_address needs to be
adjusted.
Signed-off-by: Andy Lutomirski l
:
- Rebased
- I think Gold is working (this is a side effect of the rebase)
Andy Lutomirski (7):
x86,mm: Ensure correct alignment of the fixmap
x86: Clean up 32-bit vs 64-bit vdso params
x86: Move syscall and sysenter setup into kernel/cpu/common.c
x86: Reimplement vdso.so preparation
tested it beyond that.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/include/asm/calling.h| 10 ++
arch/x86/kernel/entry_64.S| 14 ++
arch/x86/kernel/process_64.c | 37 +
arch/x86/kernel/vsyscall_64.c | 2
On Tue, May 6, 2014 at 2:25 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Tue, May 6, 2014 at 2:00 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
I'll do profiles and test the kernel compile too, but the raw timings
are certainly promising. The sysret hack is pretty
vvar and hpet sections and segments. The vdso and
hpet symbols are still there, and nothing needed the sections or
segments.
Reported-by: Markus Trippelsdorf mar...@trippelsdorf.de
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/vdso/vdso-layout.lds.S | 19 ---
1
On 04/02/2014 10:32 AM, Serge E. Hallyn wrote:
(Sorry - the lxc-devel list has moved, so replying to all with the
correct list address; please reply to this rather than my previous
email)
Quoting Serge Hallyn (serge.hal...@ubuntu.com):
Hi Eric,
(sorry, I don't seem to have the email I
On 04/03/2014 10:05 AM, Theodore Ts'o wrote:
On Thu, Apr 03, 2014 at 12:43:08PM +0200, Joerg Roedel wrote:
How about just ignoring writes to /dev/kmsg altogether by default
(unless explicitly enabled in Kconfig or on the kernel cmdline)? Maybe I
am missing something but what are the
On Fri, Apr 4, 2014 at 11:32 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Fri, Apr 4, 2014 at 11:21 AM, Andy Lutomirski l...@amacapital.net wrote:
The other thing I've used /dev/kmsg for is to shove a I'm starting
something now message in. This is only really necessary because
On Fri, Apr 4, 2014 at 11:42 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Fri, Apr 4, 2014 at 11:21 AM, Andy Lutomirski l...@amacapital.net wrote:
I'm using /dev/kmsg in virtme so that I can easily capture, with
timestamps, the ten or so log lines that it produces. It would
On Fri, Apr 4, 2014 at 11:30 AM, Serge Hallyn serge.hal...@ubuntu.com wrote:
Quoting Andy Lutomirski (l...@amacapital.net):
On 04/02/2014 10:32 AM, Serge E. Hallyn wrote:
(Sorry - the lxc-devel list has moved, so replying to all with the
correct list address; please reply to this rather
On Fri, Apr 4, 2014 at 12:10 PM, Serge Hallyn serge.hal...@ubuntu.com wrote:
Quoting Andy Lutomirski (l...@amacapital.net):
On Fri, Apr 4, 2014 at 11:30 AM, Serge Hallyn serge.hal...@ubuntu.com
wrote:
Quoting Andy Lutomirski (l...@amacapital.net):
On 04/02/2014 10:32 AM, Serge E. Hallyn
On Wed, Apr 23, 2014 at 8:55 AM, Vivek Goyal vgo...@redhat.com wrote:
On Tue, Apr 22, 2014 at 04:05:58PM -0400, David Miller wrote:
From: Vivek Goyal vgo...@redhat.com
Date: Tue, 15 Apr 2014 17:15:44 -0400
This is another version of patchset to add support passing cgroup
information of
On Wed, Apr 23, 2014 at 1:01 PM, Richard Weinberger
richard.weinber...@gmail.com wrote:
On Wed, Apr 23, 2014 at 12:12 AM, Andy Lutomirski l...@amacapital.net wrote:
I want to set up a little container. So I unshare the mount namespace
and mount something somewhere (say /mnt) that I want
On Wed, Apr 23, 2014 at 7:39 PM, Al Viro v...@zeniv.linux.org.uk wrote:
On Tue, Apr 22, 2014 at 03:12:11PM -0700, Andy Lutomirski wrote:
I want to set up a little container. So I unshare the mount namespace
and mount something somewhere (say /mnt) that I want to be my new
root. Now what
These definitions had no effect.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/vdso/vdso.lds.S | 7 +--
arch/x86/vdso/vdso32/vdso32.lds.S | 5 +
arch/x86/vdso/vdsox32.lds.S | 7 +--
3 files changed, 3 insertions(+), 16 deletions(-)
diff --git a/arch
This makes the 64-bit and x32 vdsos use the same mechanism as the
32-bit vdso. Most of the churn is deleting all the old fixmap code.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/include/asm/fixmap.h| 10 +++---
arch/x86/include/asm/vvar.h | 20
This unifies the vdso mapping code and teaches it how to map special
pages at addresses corresponding to symbols in the vdso image. The
new code is used for all vdso variants, but so far only the 32-bit
variants use the new vvar page position.
Signed-off-by: Andy Lutomirski l...@amacapital.net
This just moves code around.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/include/asm/proto.h | 2 --
arch/x86/kernel/cpu/common.c | 32
arch/x86/vdso/vdso32-setup.c | 30 --
3 files changed, 32 insertions(+), 32
dynamic relocations, so we won't
silently generate bad vdso images.
(Dynamic relocations are a problem because nothing will even attempt
to relocate the vdso.)
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/ia32/ia32_signal.c | 8 +--
arch/x86/include/asm/elf.h| 7
(this is a side effect of the rebase)
Andy Lutomirski (6):
x86: Clean up 32-bit vs 64-bit vdso params
x86: Move syscall and sysenter setup into kernel/cpu/common.c
x86: Reimplement vdso.so preparation in build-time C
x86: Move the 32-bit vdso special pages after the text
x86: Move the vvar and hpet
Rather than using 'vdso_enabled' and an awful #define, just call the
parameters vdso32_enabled and vdso64_enabled.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/include/asm/elf.h | 20 +---
arch/x86/um/vdso/vma.c | 2 +-
arch/x86/vdso/vdso32-setup.c
namespace before you can finish setting it up.
Would it make sense to add a mount option to procfs to request a mount
for pid_ns_for_children instead of task_active_pid_ns?
--Andy
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Fri, Apr 25, 2014 at 12:37 PM, Eric W. Biederman
ebied...@xmission.com wrote:
Andy Lutomirski l...@amacapital.net writes:
Unless I'm missing some trick, it's currently rather painful to mount
a namespace /proc. You have to actually be in the pid namespace to
mount the correct /proc
On Fri, Apr 25, 2014 at 1:25 PM, Eric W. Biederman
ebied...@xmission.com wrote:
Andy Lutomirski l...@amacapital.net writes:
On Fri, Apr 25, 2014 at 12:37 PM, Eric W. Biederman
ebied...@xmission.com wrote:
Andy Lutomirski l...@amacapital.net writes:
Unless I'm missing some trick, it's
On Fri, Apr 25, 2014 at 1:46 PM, Andy Lutomirski l...@amacapital.net wrote:
On Fri, Apr 25, 2014 at 1:25 PM, Eric W. Biederman
ebied...@xmission.com wrote:
Andy Lutomirski l...@amacapital.net writes:
On Fri, Apr 25, 2014 at 12:37 PM, Eric W. Biederman
ebied...@xmission.com wrote:
Andy
On Fri, Apr 25, 2014 at 2:17 PM, Eric W. Biederman
ebied...@xmission.com wrote:
Andy Lutomirski l...@amacapital.net writes:
On Fri, Apr 25, 2014 at 1:25 PM, Eric W. Biederman
ebied...@xmission.com wrote:
Andy Lutomirski l...@amacapital.net writes:
On Fri, Apr 25, 2014 at 12:37 PM, Eric W
On Mon, Apr 21, 2014 at 8:03 AM, Vivek Goyal vgo...@redhat.com wrote:
So what happened to logger use case where logger accepts stream
connections and logs the cgroup of client too.
W.r.t systemd, looks like journald is accepting connections at
/run/systemd/journal/stdout. (stdout_stream_new()
This is a prototype of a real fix for a longstanding issue. See patch 2
for the full descripton.
Andy Lutomirski (2):
fs,proc: Pass nameidata to proc_get_link implementations
fs,proc: Respect FMODE_WRITE when opening /proc/pid/fd/N
fs/namei.c| 3 +++
fs/proc/base.c| 13
fix the accidental flink-via-proc
thing, too.
This may break userspace. If so, I would guess that anything broken
by it is either an actual exploit or is so broken that it doesn't
deserve to continue working. If it breaks something important, then
maybe it will need a sysctl.
Signed-off-by: Andy
proc_fd_link should respect fs modes, and it needs to know the open
mode to do so.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
fs/proc/base.c | 13 -
fs/proc/fd.c | 3 ++-
fs/proc/internal.h | 3 ++-
3 files changed, 12 insertions(+), 7 deletions(-)
diff --git
On Mon, Apr 21, 2014 at 10:00 AM, Andy Lutomirski l...@amacapital.net wrote:
On Mon, Apr 21, 2014 at 9:30 AM, Al Viro v...@zeniv.linux.org.uk wrote:
On Mon, Apr 21, 2014 at 09:22:48AM -0700, Andy Lutomirski wrote:
+static int proc_may_follow(struct nameidata *nd, struct file *f
On Mon, Apr 21, 2014 at 9:30 AM, Al Viro v...@zeniv.linux.org.uk wrote:
On Mon, Apr 21, 2014 at 09:22:48AM -0700, Andy Lutomirski wrote:
+static int proc_may_follow(struct nameidata *nd, struct file *f)
+{
+ if (!nd)
+ return 0; /* This is readlink, */
+
+ if ((nd
On Mon, Apr 21, 2014 at 10:04 AM, Andy Lutomirski l...@amacapital.net wrote:
On Mon, Apr 21, 2014 at 10:00 AM, Andy Lutomirski l...@amacapital.net wrote:
On Mon, Apr 21, 2014 at 9:30 AM, Al Viro v...@zeniv.linux.org.uk wrote:
On Mon, Apr 21, 2014 at 09:22:48AM -0700, Andy Lutomirski wrote
On 04/21/2014 09:45 AM, Jeff Layton wrote:
On Mon, 21 Apr 2014 12:10:04 -0400
Rich Felker dal...@libc.org wrote:
I'm well aware of that. The problem is that the proposed API is using
the two-letter abbreviation FD, which ALWAYS means file descriptor and
NEVER means file description (in
On Tue, Apr 22, 2014 at 5:44 AM, David Herrmann dh.herrm...@gmail.com wrote:
Hi
On Mon, Apr 21, 2014 at 6:22 PM, Andy Lutomirski l...@amacapital.net wrote:
This patch does this:
I can see _what_ the patch does, but your patch lacks any discussion
_why_ it is needed. Can you provide at least
On Tue, Apr 22, 2014 at 7:17 AM, David Herrmann dh.herrm...@gmail.com wrote:
Hi
On Tue, Apr 22, 2014 at 3:49 PM, Andy Lutomirski l...@amacapital.net wrote:
Anyone who opens a file read-only and sends it over SCM_RIGHTS is
likely broken. They may think that it's read-only, so it can't
On Tue, Apr 22, 2014 at 8:03 AM, David Herrmann dh.herrm...@gmail.com wrote:
Hi
On Tue, Apr 22, 2014 at 4:33 PM, Andy Lutomirski l...@amacapital.net wrote:
On Tue, Apr 22, 2014 at 7:17 AM, David Herrmann dh.herrm...@gmail.com
wrote:
I think it's safe to assume that any object you create
On Tue, Apr 22, 2014 at 8:19 AM, David Herrmann dh.herrm...@gmail.com wrote:
Hi
On Tue, Apr 22, 2014 at 4:31 PM, Pavel Machek pa...@ucw.cz wrote:
Such as here?
http://www.securityfocus.com/archive/1/507386
Thanks, that's the first real example someone mentioned.
Quoted from your link:
1001 - 1100 of 19466 matches
Mail list logo
