On Thu, Sep 12, 2013 at 3:13 PM, Jörn Engel jo...@logfs.org wrote:
On Thu, 12 September 2013 19:39:47 -0400, Jeff Garzik wrote:
On Thu, Sep 12, 2013 at 5:57 PM, Jörn Engel jo...@logfs.org wrote:
On Wed, 11 September 2013 14:47:04 -0400, David Safford wrote:
But I also think that the existing
This test program:
#include stdio.h
#include err.h
#include fcntl.h
#include unistd.h
#define __O_TMPFILE 02000
#define O_TMPFILE (__O_TMPFILE | O_DIRECTORY)
#define AT_EMPTY_PATH 0x1000
int main(int argc, char **argv)
{
char buf[128];
if (argc != 3)
errx(1, Usage: flinktest PATH
O_TMPFILE, like O_CREAT, should respect the requested mode and should
create regular files.
This fixes two bugs: O_TMPFILE required privilege (because the mode
ended up as 000) and it produced bogus inodes with no type.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
fs/open.c | 2 +-
1
(tmpfd, , dfd, path, AT_EMPTY_PATH)
Let's allow it.
If this turns out to be excessively scary, it we could instead require
that the inode in question be I_LINKABLE, but this seems pointless given
the /proc situation
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
fs/namei.c | 10
[cc: some ARM people]
After a bit of an adventure, I got QEMU working. (Linux 3.12's smc91x
driver and qemu 1.6 don't get along. It would be great if some
kernel.org page described a standard way to boot a modern Linux image
on a modern QEMU version, but I digress.)
The current state of
On Tue, Nov 5, 2013 at 4:40 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
On Tue, Nov 05, 2013 at 04:14:49PM -0800, Kees Cook wrote:
I would agree: option 1 seems cleanest of the 3. 3 is sort of like a
built-in automatic check for a mismatched arch, so maybe that works
better?
On Wed, Nov 6, 2013 at 11:33 AM, Oleg Nesterov o...@redhat.com wrote:
Hi Serge,
On 11/06, Serge Hallyn wrote:
Hi Oleg,
commit 40a0d32d1eaffe6aac7324ca92604b6b3977eb0e :
fork: unify and tighten up CLONE_NEWUSER/CLONE_NEWPID checks
breaks lxc-attach in 3.12. That code forks a child which
On Wed, Nov 6, 2013 at 12:06 PM, Oleg Nesterov o...@redhat.com wrote:
On 11/06, Andy Lutomirski wrote:
On Wed, Nov 6, 2013 at 11:33 AM, Oleg Nesterov o...@redhat.com wrote:
Hi Serge,
On 11/06, Serge Hallyn wrote:
Hi Oleg,
commit 40a0d32d1eaffe6aac7324ca92604b6b3977eb0e :
fork
, 2013-11-05 at 14:36 -0800, Andy Lutomirski wrote:
1. Set a different audit arch for OABI syscalls (e.g.
AUDIT_ARCH_ARMOABI). That is, treat OABI syscall entries the same way
that x86_64 treats int 80.
As the audit maintainer, I like #1. It might break ABI, but the ABI is
flat wrong now
On Wed, Nov 6, 2013 at 2:30 PM, Matt Sealey n...@bakuhatsu.net wrote:
On Tue, Nov 5, 2013 at 6:14 PM, Kees Cook keesc...@chromium.org wrote:
Alternatively, CONFIG_SECCOMP_FILTER could depend on
!CONFIG_OABI_COMPAT. That seems like the least work, given the desire
to kill OABI in the real
) !=
current-nsproxy-pid_ns_for_children))
Acked-by: Andy Lutomirski l...@amacapital.net
I don't know if there are shells that CLONE_PARENT can confuse but if
there are lxcattach and nsenter using this functionality should be
enough to slowly get that confusion
AUDIT_ARCH_ARM_OABI or something (maybe for
seccomp only) if needed.
--Andy
--
Kees Cook
Chrome OS Security
--
Andy Lutomirski
AMA Capital Management, LLC
--
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
On Thu, Nov 7, 2013 at 10:56 AM, Eric Paris epa...@redhat.com wrote:
On Thu, 2013-11-07 at 10:39 -0800, Kees Cook wrote:
On Thu, Nov 7, 2013 at 10:16 AM, Andy Lutomirski l...@amacapital.net wrote:
On Thu, Nov 7, 2013 at 9:47 AM, Kees Cook keesc...@chromium.org wrote:
Make sure that seccomp
On Fri, Nov 8, 2013 at 8:29 AM, Paul Moore pmo...@redhat.com wrote:
On Thursday, November 07, 2013 11:05:26 AM Andy Lutomirski wrote:
On Thu, Nov 7, 2013 at 10:56 AM, Eric Paris epa...@redhat.com wrote:
Isn't x32 similarly screwy? Does it work because the syscall numbers
are different
On Fri, Sep 27, 2013 at 6:02 PM, Andy Lutomirski l...@amacapital.net wrote:
Intel LGA2011 machines have dedicated SMBUS controllers for DIMM
sockets. Because they're dedicated, they can be safely and accurately
probed, since all devices on them are known to be attached to DIMMs.
The devices
On 10/01/2013 01:26 PM, Djalal Harouni wrote:
Since /proc entries varies at runtime, permission checks need to happen
during each system call.
However even with that /proc file descriptors can be passed to a more
privileged process (e.g. a suid-exec) which will pass the classic
On 10/01/2013 01:26 PM, Djalal Harouni wrote:
Some fields of the /proc/*/stat are sensitive fields that need
appropriate protection.
However, /proc file descriptors can be passed to a more privileged
process (e.g. a suid-exec) which will pass the classic
ptrace_may_access() permission check
On 10/01/2013 01:26 PM, Djalal Harouni wrote:
/proc/pid/* entries varies at runtime, appropriate permission checks
need to happen during each system call.
Currently some of these sensitive entries are protected by performing
the ptrace_may_access() check. However even with that the /proc
On Wed, Oct 2, 2013 at 3:55 PM, Djalal Harouni tix...@opendz.org wrote:
On Tue, Oct 01, 2013 at 06:36:34PM -0700, Andy Lutomirski wrote:
On 10/01/2013 01:26 PM, Djalal Harouni wrote:
Since /proc entries varies at runtime, permission checks need to happen
during each system call.
However
On Wed, Oct 2, 2013 at 4:14 PM, Djalal Harouni tix...@opendz.org wrote:
On Tue, Oct 01, 2013 at 06:39:00PM -0700, Andy Lutomirski wrote:
On 10/01/2013 01:26 PM, Djalal Harouni wrote:
Some fields of the /proc/*/stat are sensitive fields that need
appropriate protection.
However, /proc
On Wed, Oct 2, 2013 at 3:37 PM, Djalal Harouni tix...@opendz.org wrote:
On Tue, Oct 01, 2013 at 06:40:41PM -0700, Andy Lutomirski wrote:
On 10/01/2013 01:26 PM, Djalal Harouni wrote:
/proc/pid/* entries varies at runtime, appropriate permission checks
need to happen during each system call
On Wed, Oct 2, 2013 at 10:48 AM, Kees Cook keesc...@chromium.org wrote:
On Wed, Oct 2, 2013 at 9:51 AM, Andy Lutomirski l...@amacapital.net wrote:
On Wed, Oct 2, 2013 at 3:37 PM, Djalal Harouni tix...@opendz.org wrote:
On Tue, Oct 01, 2013 at 06:40:41PM -0700, Andy Lutomirski wrote:
On 10/01
On Thu, Oct 3, 2013 at 3:36 PM, Djalal Harouni tix...@opendz.org wrote:
On Wed, Oct 02, 2013 at 05:44:17PM +0100, Andy Lutomirski wrote:
On Wed, Oct 2, 2013 at 3:55 PM, Djalal Harouni tix...@opendz.org wrote:
On Tue, Oct 01, 2013 at 06:36:34PM -0700, Andy Lutomirski wrote:
On 10/01/2013 01
On Thu, Oct 3, 2013 at 1:29 PM, Djalal Harouni tix...@opendz.org wrote:
On Thu, Oct 03, 2013 at 08:12:44AM +0200, Ingo Molnar wrote:
* Djalal Harouni tix...@opendz.org wrote:
Regardless, glibc uses /proc/self/maps, which would be fine here, right?
I did not touch /proc/self/maps and
On Thu, Oct 3, 2013 at 4:40 PM, Djalal Harouni tix...@opendz.org wrote:
On Thu, Oct 03, 2013 at 04:15:43PM +0100, Andy Lutomirski wrote:
On Thu, Oct 3, 2013 at 1:29 PM, Djalal Harouni tix...@opendz.org wrote:
On Thu, Oct 03, 2013 at 08:12:44AM +0200, Ingo Molnar wrote:
Now procfs might
On Thu, Oct 3, 2013 at 12:29 PM, Djalal Harouni tix...@opendz.org wrote:
On Thu, Oct 03, 2013 at 04:12:37PM +0100, Andy Lutomirski wrote:
On Thu, Oct 3, 2013 at 3:36 PM, Djalal Harouni tix...@opendz.org wrote:
On Wed, Oct 02, 2013 at 05:44:17PM +0100, Andy Lutomirski wrote:
On Wed, Oct 2
On Thu, Oct 3, 2013 at 1:13 PM, Djalal Harouni tix...@opendz.org wrote:
On Thu, Oct 03, 2013 at 12:37:49PM -0700, Andy Lutomirski wrote:
On Thu, Oct 3, 2013 at 12:29 PM, Djalal Harouni tix...@opendz.org wrote:
On Thu, Oct 03, 2013 at 04:12:37PM +0100, Andy Lutomirski wrote:
On Thu, Oct 3
On Fri, Oct 4, 2013 at 9:59 AM, Djalal Harouni tix...@opendz.org wrote:
On Thu, Oct 03, 2013 at 02:09:55PM -0700, Andy Lutomirski wrote:
On Thu, Oct 3, 2013 at 1:13 PM, Djalal Harouni tix...@opendz.org wrote:
On Thu, Oct 03, 2013 at 12:37:49PM -0700, Andy Lutomirski wrote:
On Thu, Oct 3
On Fri, Oct 4, 2013 at 7:23 PM, Djalal Harouni tix...@opendz.org wrote:
On Fri, Oct 04, 2013 at 04:40:01PM +0100, Andy Lutomirski wrote:
On Fri, Oct 4, 2013 at 9:59 AM, Djalal Harouni tix...@opendz.org wrote:
On Thu, Oct 03, 2013 at 02:09:55PM -0700, Andy Lutomirski wrote:
On Thu, Oct 3
On Fri, Oct 4, 2013 at 12:11 PM, Djalal Harouni tix...@opendz.org wrote:
On Fri, Oct 04, 2013 at 07:34:08PM +0100, Andy Lutomirski wrote:
On Fri, Oct 4, 2013 at 7:23 PM, Djalal Harouni tix...@opendz.org wrote:
On Fri, Oct 04, 2013 at 04:40:01PM +0100, Andy Lutomirski wrote:
On Fri, Oct 4
On Fri, Oct 4, 2013 at 12:27 PM, Djalal Harouni tix...@opendz.org wrote:
On Fri, Oct 04, 2013 at 12:16:26PM -0700, Andy Lutomirski wrote:
On Fri, Oct 4, 2013 at 12:11 PM, Djalal Harouni tix...@opendz.org wrote:
On Fri, Oct 04, 2013 at 07:34:08PM +0100, Andy Lutomirski wrote:
On Fri, Oct 4
On Fri, Oct 4, 2013 at 12:41 PM, Djalal Harouni tix...@opendz.org wrote:
On Fri, Oct 04, 2013 at 12:32:09PM -0700, Andy Lutomirski wrote:
On Fri, Oct 4, 2013 at 12:27 PM, Djalal Harouni tix...@opendz.org wrote:
On Fri, Oct 04, 2013 at 12:16:26PM -0700, Andy Lutomirski wrote:
On Fri, Oct 4
On Fri, Oct 4, 2013 at 3:55 PM, Eric W. Biederman ebied...@xmission.com wrote:
Andy Lutomirski l...@amacapital.net writes:
On Fri, Oct 4, 2013 at 12:41 PM, Djalal Harouni tix...@opendz.org wrote:
On Fri, Oct 04, 2013 at 12:32:09PM -0700, Andy Lutomirski wrote:
On Fri, Oct 4, 2013 at 12:27 PM
On Fri, Oct 4, 2013 at 3:59 PM, Andy Lutomirski l...@amacapital.net wrote:
I'd really like a solution where there are no read or write
implementations in the entire kernel that check permissions. Failing
that, just getting it for procfs would be nice. (uid_map, etc will
probably need
On 10/01/2013 09:00 AM, Miklos Szeredi wrote:
This series adds a new syscall, renameat2(), which is the same as renameat()
but
with a flags argument. Internally i_op-reaname2() is also added, which can
later be merged with -rename() but is kept separately for now, since this
would
just
I was looking at the stack expansion code, and I'm not convinced it's
safe. Aside from the obvious scariness of down_read(mmap_sem) not
actually preventing vma changes, I think there's a real race. Suppose
that you have a VM_GROWSDOWN vma above a VM_GROWSUP vma with a
single-page gap between
I'm trying to arrange for a process to have a different memory policy
on its stack as compared to everything else (e.g. mapped libraries).
Before I start looking for kludges, is there any clean way to do this?
So far, the best I can come up with is to either parse /proc/self/maps
on startup or to
On Mon, Nov 25, 2013 at 3:35 PM, Andy Lutomirski l...@amacapital.net wrote:
I'm trying to arrange for a process to have a different memory policy
on its stack as compared to everything else (e.g. mapped libraries).
Before I start looking for kludges, is there any clean way to do this?
So far
On 11/25/2013 04:37 PM, Andi Kleen wrote:
From: Andi Kleen a...@linux.intel.com
[Addressed all addressable review feedback in v2]
Properly patching running code (cross modification)
is a quite complicated business on x86.
The CPU has specific rules that need to be followed, including
On Wed, Nov 27, 2013 at 2:02 PM, H. Peter Anvin h...@zytor.com wrote:
For the record, this is the entire patch necessary to do the
sync_cores() system call -- and no potential interactions with security
frameworks or whatnot, simply because no security-sensitive operations
are performed of any
On Fri, Nov 29, 2013 at 9:37 AM, Peter Zijlstra pet...@infradead.org wrote:
Use the 'latch' data structure for cyc2ns.
This is a data structure first proposed by me and later named by
Mathieu. If anybody's got a better name; do holler.
That structure must exist in the literature, but I have
[Subject changed because this isn't relevant to the patches in
question any more.]
On Sat, Nov 30, 2013 at 1:18 AM, Peter Zijlstra pet...@infradead.org wrote:
On Fri, Nov 29, 2013 at 03:22:45PM -0800, Andy Lutomirski wrote:
On Fri, Nov 29, 2013 at 9:37 AM, Peter Zijlstra pet...@infradead.org
On Mon, Dec 2, 2013 at 11:12 AM, John Stultz john.stu...@linaro.org wrote:
On 11/30/2013 09:29 AM, Andy Lutomirski wrote:
[Subject changed because this isn't relevant to the patches in
question any more.]
On Sat, Nov 30, 2013 at 1:18 AM, Peter Zijlstra pet...@infradead.org wrote:
On Fri, Nov
On 11/11/2013 02:10 PM, H. Peter Anvin wrote:
You probably want to rotate by an odd number of bits... the point is to
spread out any pattern in the bytes.
Would it make more sense to just use a real cryptographic hash function?
I don't think that any of the real kernel code is available this
On Thu, Nov 14, 2013 at 3:10 AM, Gao feng gaof...@cn.fujitsu.com wrote:
On 11/13/2013 03:26 PM, Gao feng wrote:
On 11/09/2013 01:42 PM, Eric W. Biederman wrote:
Right now I would rather not have the empty directory exception than
remove this code.
The test is a little trickier to write than
On 11/18/2013 04:27 PM, Andi Kleen wrote:
From: Andi Kleen a...@linux.intel.com
Properly patching running code (cross modification)
is a quite complicated business on x86.
The CPU has specific rules that need to be followed, including
multiple global barriers.
Self modifying code is
On 11/19/2013 12:06 PM, Thomas Hellstrom wrote:
Hi!
Before going any further with this I'd like to check whether this is an
acceptable way to go.
Background:
GPU buffer objects in general and vmware svga GPU buffers in
particular are mapped by user-space using MIXEDMAP or PFNMAP. Sometimes
)
+ return err;
+ }
+
return security_ops-inode_rename(old_dir, old_dentry,
new_dir, new_dentry);
}
--
1.8.1.4
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line unsubscribe
On Wed, Nov 20, 2013 at 12:12 AM, Thomas Hellstrom
thellst...@vmware.com wrote:
On 11/19/2013 11:51 PM, Andy Lutomirski wrote:
On 11/19/2013 12:06 PM, Thomas Hellstrom wrote:
Hi!
Before going any further with this I'd like to check whether this is an
acceptable way to go.
Background:
GPU
On Wed, Nov 20, 2013 at 8:44 AM, Miklos Szeredi mik...@szeredi.hu wrote:
On Wed, Nov 20, 2013 at 5:39 PM, Andy Lutomirski l...@amacapital.net wrote:
On Wed, Nov 20, 2013 at 5:01 AM, Miklos Szeredi mik...@szeredi.hu wrote:
From: Miklos Szeredi mszer...@suse.cz
If flags contain RENAME_EXCHANGE
On Wed, Nov 20, 2013 at 12:16 PM, Thomas Hellstrom
thellst...@vmware.com wrote:
On 11/20/2013 05:50 PM, Andy Lutomirski wrote:
On Wed, Nov 20, 2013 at 12:12 AM, Thomas Hellstrom
thellst...@vmware.com wrote:
On 11/19/2013 11:51 PM, Andy Lutomirski wrote:
On 11/19/2013 12:06 PM, Thomas
On Wed, Mar 12, 2014 at 8:46 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Wed, Mar 12, 2014 at 7:41 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
Having looked at it a bit more, I think the correct solution is:
- leave the legacy compat-vdso FIXMAP entry at a single
is to simplify this stuff, I don't really like
any of these choices. That's a lot of code to save 4k per process,
and when it breaks (which I suspect it will the next time anyone
touches the address space layout) so one will notice that 4k gets
wasted again.
On March 11, 2014 11:09:11 PM PDT, Andy Lutomirski
want to
add funny interactions with ASLR to support such a narrow use case.
On March 12, 2014 9:20:50 AM PDT, Andy Lutomirski l...@amacapital.net wrote:
On Tue, Mar 11, 2014 at 11:14 PM, H. Peter Anvin h...@zytor.com wrote:
There is one sensible address: end of address space perhaps minus
some
The compat vDSO is a complicated hack that's needed to maintain
compatibility with a small range of never-released glibc versions.
This removes it and replaces it with a much simpler hack: a config
option to disable the 32-bit vDSO by default.
Signed-off-by: Andy Lutomirski l...@amacapital.net
The only reason that the user bit was set was to support userspace
access to the compat vDSO in the fixmap. The compat vDSO is gone,
so the user bit can be removed.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/include/asm/pgtable_types.h | 7 +--
1 file changed, 1
the nakking. The critical difference is that this
version defaults to the compatible vdso-less mode instead of the modern
incompatible mode.
Changes from v1:
- CONFIG_ENABLE_VDSO32_BY_DEFAULT now defaults to n
- Improved the config text and description
- Improved the kernel parameter docs
Andy
On Wed, Mar 12, 2014 at 11:39 AM, Dave Jones da...@redhat.com wrote:
On Wed, Mar 12, 2014 at 11:29:45AM -0700, Andy Lutomirski wrote:
The only reason that the user bit was set was to support userspace
access to the compat vDSO in the fixmap. The compat vDSO is gone,
so the user bit can
and description
- Improved the kernel parameter docs
Andy Lutomirski (2):
x86: Remove compat vdso support
x86_32: Remove user bit from identity map PDE
Documentation/kernel-parameters.txt | 23 +++-
arch/x86/Kconfig | 28 +++--
arch/x86/include/asm/elf.h | 4 -
arch/x86
The only reason that the user bit was set was to support userspace
access to the compat vDSO in the fixmap. The compat vDSO is gone,
so the user bit can be removed.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/include/asm/pgtable_types.h | 7 +--
1 file changed, 1
The compat vDSO is a complicated hack that's needed to maintain
compatibility with a small range of never-released glibc versions.
This removes it and replaces it with a much simpler hack: a config
option to disable the 32-bit vDSO by default.
Signed-off-by: Andy Lutomirski l...@amacapital.net
the
offsets of all the variables into the linker script. I'll play around
a bit.
--Andy
It would be nice to get rid of the vvar declaration stuff, too
Linus
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
On 03/12/2014 01:46 PM, Vivek Goyal wrote:
Hi,
This is V2 of patches. Fixed the function format issue and also I was using
CONFIG_CGROUP instead of CONFIG_CGROUPS. That led to crash at boot. Fixed
that.
Some applications like sssd want to know the cgroup of connected peer over
unix
On 03/12/2014 01:46 PM, Vivek Goyal wrote:
Implement SO_PEERCGROUP along the lines of SO_PEERCRED. This returns the
cgroup of first mounted hierarchy of the task. For the case of client,
it represents the cgroup of client at the time of opening the connection.
After that client cgroup might
On Wed, Mar 12, 2014 at 1:59 PM, Simo Sorce sso...@redhat.com wrote:
On Wed, 2014-03-12 at 13:56 -0700, Andy Lutomirski wrote:
On 03/12/2014 01:46 PM, Vivek Goyal wrote:
Hi,
This is V2 of patches. Fixed the function format issue and also I was using
CONFIG_CGROUP instead
On Wed, Mar 12, 2014 at 2:00 PM, Andy Lutomirski l...@amacapital.net wrote:
On 03/12/2014 01:46 PM, Vivek Goyal wrote:
Implement SO_PEERCGROUP along the lines of SO_PEERCRED. This returns the
cgroup of first mounted hierarchy of the task. For the case of client,
it represents the cgroup
On Wed, Mar 12, 2014 at 2:16 PM, Simo Sorce sso...@redhat.com wrote:
On Wed, 2014-03-12 at 14:12 -0700, Andy Lutomirski wrote:
On Wed, Mar 12, 2014 at 2:00 PM, Andy Lutomirski l...@amacapital.net wrote:
On 03/12/2014 01:46 PM, Vivek Goyal wrote:
Implement SO_PEERCGROUP along the lines
On Wed, Mar 12, 2014 at 2:37 PM, H. Peter Anvin h...@linux.intel.com wrote:
On 03/12/2014 12:41 PM, Linus Torvalds wrote:
So my reaction was don't do that.
But people pointing out that we can't do what x86-64 does made me
think: we could avoid the whole nasty code for a legacy case by
, the
hpet, or anything else that the vdso uses.
Linus
--
Andy Lutomirski
AMA Capital Management, LLC
--
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
increase the code size of the VDSO
- remove vsyscall and prevent wrong conditional VVAR_PAGE mapping
- handle VDSO larger than a page
The patch set is agains tip 7ed5ee279499a02bf35c77f0a91d657c24f6474e
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send
On Wed, Mar 12, 2014 at 3:58 PM, H. Peter Anvin h...@zytor.com wrote:
On 03/12/2014 03:51 PM, Stefani Seibold wrote:
This patch enables 32 bit vDSO which are larger than a page. Currently
two pages are reserved, this should be enough for future improvements.
Signed-off-by: Stefani Seibold
On Wed, Mar 12, 2014 at 4:06 PM, H. Peter Anvin h...@linux.intel.com wrote:
On 03/12/2014 02:49 PM, Andy Lutomirski wrote:
On Wed, Mar 12, 2014 at 2:46 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Wed, Mar 12, 2014 at 2:37 PM, H. Peter Anvin h...@linux.intel.com
wrote:
How
On Wed, Mar 12, 2014 at 6:17 PM, Simo Sorce sso...@redhat.com wrote:
On Wed, 2014-03-12 at 14:19 -0700, Andy Lutomirski wrote:
On Wed, Mar 12, 2014 at 2:16 PM, Simo Sorce sso...@redhat.com wrote:
Connection time is all we do and can care about.
You have not answered why.
We are going
On Wed, Mar 12, 2014 at 6:43 PM, Simo Sorce sso...@redhat.com wrote:
On Wed, 2014-03-12 at 18:21 -0700, Andy Lutomirski wrote:
On Wed, Mar 12, 2014 at 6:17 PM, Simo Sorce sso...@redhat.com wrote:
On Wed, 2014-03-12 at 14:19 -0700, Andy Lutomirski wrote:
On Wed, Mar 12, 2014 at 2:16 PM, Simo
On Thu, Mar 13, 2014 at 9:33 AM, Simo Sorce sso...@redhat.com wrote:
On Thu, 2014-03-13 at 11:00 -0400, Vivek Goyal wrote:
On Thu, Mar 13, 2014 at 10:55:34AM -0400, Simo Sorce wrote:
[..]
This might not be quite as awful as I thought. At least you're
looking up the cgroup at
On Thu, Mar 13, 2014 at 8:53 AM, H. Peter Anvin h...@zytor.com wrote:
On 03/12/2014 03:59 PM, Andy Lutomirski wrote:
Note that this code is completely unnecessary if either of my patch
sets is accepted. Since you're the maintainer, can you give an
opinion? :)
I'm trying to unwind all
On Thu, Mar 13, 2014 at 10:51 AM, Simo Sorce sso...@redhat.com wrote:
On Wed, 2014-03-12 at 19:12 -0700, Andy Lutomirski wrote:
On Wed, Mar 12, 2014 at 6:43 PM, Simo Sorce sso...@redhat.com wrote:
On Wed, 2014-03-12 at 18:21 -0700, Andy Lutomirski wrote:
On Wed, Mar 12, 2014 at 6:17 PM, Simo
On Thu, Mar 13, 2014 at 10:58 AM, Simo Sorce sso...@redhat.com wrote:
On Thu, 2014-03-13 at 10:55 -0700, Andy Lutomirski wrote:
So give each container its own unix socket. Problem solved, no?
Not really practical if you have hundreds of containers.
I don't see the problem. Sockets
On Thu, Mar 13, 2014 at 10:57 AM, Simo Sorce sso...@redhat.com wrote:
On Thu, 2014-03-13 at 10:55 -0700, Andy Lutomirski wrote:
On Thu, Mar 13, 2014 at 10:51 AM, Simo Sorce sso...@redhat.com wrote:
On Wed, 2014-03-12 at 19:12 -0700, Andy Lutomirski wrote:
On Wed, Mar 12, 2014 at 6:43 PM
On Thu, Mar 13, 2014 at 11:21 AM, H. Peter Anvin h...@zytor.com wrote:
On 03/13/2014 11:08 AM, H. Peter Anvin wrote:
On 03/13/2014 10:28 AM, Andy Lutomirski wrote:
Does this mean you prefer the relocation approach to the compat vdso
removal approach? It seems like Linus is okay with either
On Thu, Mar 13, 2014 at 12:06 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On my phone, so the lists will reject this, and sorry for top posting.
Maybe we could do something similar to the vsyscall=native thing, where the
compat vdso just does the system calls, but at least uses
On Thu, Mar 13, 2014 at 12:21 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Mar 13, 2014 12:13 PM, Andy Lutomirski l...@amacapital.net wrote:
How? We either set null in AT_SYSINFO_EHDR, we set something simple
that SuSE is okay with (and compile separate images?) or we set
On Thu, Mar 13, 2014 at 12:53 PM, Vivek Goyal vgo...@redhat.com wrote:
On Thu, Mar 13, 2014 at 10:55:16AM -0700, Andy Lutomirski wrote:
[..]
2. Docker is a container system, so use the container (aka
namespace) APIs. There are probably several clever things that could
be done with /proc
On Thu, Mar 13, 2014 at 1:06 PM, Vivek Goyal vgo...@redhat.com wrote:
On Thu, Mar 13, 2014 at 12:58:14PM -0700, Andy Lutomirski wrote:
On Thu, Mar 13, 2014 at 12:53 PM, Vivek Goyal vgo...@redhat.com wrote:
On Thu, Mar 13, 2014 at 10:55:16AM -0700, Andy Lutomirski wrote:
[..]
2. Docker
--
users configuring kernels from scratch almost certainly want that
choice.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
Documentation/kernel-parameters.txt | 22 +++-
arch/x86/Kconfig| 26 ++--
arch/x86/include/asm/elf.h | 4 -
arch/x86/include/asm/fixmap.h
that I missed.
Changes from v1:
- CONFIG_ENABLE_VDSO32_BY_DEFAULT now defaults to n
- Improved the config text and description
- Improved the kernel parameter docs
Andy Lutomirski (2):
x86: Remove compat vdso support
x86_32: Remove user bit from identity map PDE
Documentation/kernel
The only reason that the user bit was set was to support userspace
access to the compat vDSO in the fixmap. The compat vDSO is gone,
so the user bit can be removed.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/include/asm/pgtable_types.h | 7 +--
1 file changed, 1
On Fri, Feb 21, 2014 at 7:32 AM, One Thousand Gnomes
gno...@lxorguk.ukuu.org.uk wrote:
I'm suggesting identifying a range of addresses on a bus with a port
(or whatever it should be called). Multiple ports could claim
non-overlapping ranges on the same bus.
Which is fine until you meant a
On 02/17/2014 10:07 PM, Yan, Zheng wrote:
This patch series adds LBR call stack support. User can enabled/disable
this through an sysfs attribute file in the CPU PMU directory:
echo 1 /sys/bus/event_source/devices/cpu/lbr_callstack
This seems like an unpleasant way to control this. It
On 02/20/2014 04:29 AM, Dieter Mummenschanz wrote:
Hello,
on my Lenovo T440p Laptop the Haswell i7-4600M CPU refuses to enter lower PC
states resulting in 14-15 Watts continuous power drain even if the system is
idle and every tunalbes in powertop 2.5 are enabled. The issue is
On 02/20/2014 08:23 AM, Alexey Perevalov wrote:
From: Anton Vorontsov an...@enomsg.org
This patch implements a userland-side API for generic deferrable timers,
per linux/timer.h:
* A deferrable timer will work normally when the system is busy, but
* will not cause a CPU to come out of
On 02/20/2014 08:55 PM, H. Peter Anvin wrote:
This seems like really deep magic when looking at it... at the very
least, this needs to be very carefully commented, including why it works
on the various platforms.
How much does this actually affect the output? I only see three uses of
On 02/21/2014 09:56 AM, Thomas Gleixner wrote:
Deferrable timers are beneficial for power saving. They behave like
standard timers except that their expiry can be delayed up to the
expiry of the next non deferred timer. That prevents them from waking
up cpus from deep idle periods.
What does
On Wed, Feb 26, 2014 at 12:04 AM, Stephane Eranian eran...@google.com wrote:
On Wed, Feb 26, 2014 at 3:39 AM, Andy Lutomirski l...@amacapital.net wrote:
On 02/17/2014 10:07 PM, Yan, Zheng wrote:
This patch series adds LBR call stack support. User can enabled/disable
this through an sysfs
On Wed, Feb 26, 2014 at 10:55 AM, Andi Kleen a...@firstfloor.org wrote:
I'm suggesting a perf event option, just like the way that PEBS works.
Right now it's a somewhat experimental feature and just having
the sysctl is fine. If it turns out that is what everyone uses
such an option could be
On Thu, Feb 20, 2014 at 6:44 PM, Ren Qiaowei qiaowei@intel.com wrote:
On 02/13/2014 04:19 AM, Andy Lutomirski wrote:
On 02/12/2014 10:36 AM, Qiaowei Ren wrote:
An access to an invalid bound directory entry will cause a #BR
exception. This patch hook #BR exception handler to allocate
one
On Wed, Feb 26, 2014 at 11:19 AM, David Ahern dsah...@gmail.com wrote:
On 2/26/14, 11:59 AM, Andy Lutomirski wrote:
I wonder if anyone who uses perf for userspace profiling *ever* uses
FP and gets away with it. There's precious little userspace software
compiled with frame pointers
future?
- Stefani
--
Andy Lutomirski
AMA Capital Management, LLC
--
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
On Wed, Feb 26, 2014 at 12:14 PM, David Ahern dsah...@gmail.com wrote:
On 2/26/14, 12:25 PM, Andy Lutomirski wrote:
On Wed, Feb 26, 2014 at 11:19 AM, David Ahern dsah...@gmail.com wrote:
On 2/26/14, 11:59 AM, Andy Lutomirski wrote:
I wonder if anyone who uses perf for userspace profiling
that there's no
performance regression.
--Andy
thanks,
greg k-h
--
Andy Lutomirski
AMA Capital Management, LLC
--
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
301 - 400 of 19466 matches
Mail list logo
