Um. This code doesn't work. I'll send a patch. I can't speak
towards how well it compiles in different configurations.
I can't speak towards how well it compiles in different
configurations. Also, vdso_fallback_gettime needs .cfi annotations, I
think. I could probably dredge the required
hpa, please either nuke x86/vdso or apply these. That branch is
certainly *not* ready for merging, but this gets it a little closer.
Andy Lutomirski (2):
x86: Mark __vdso entries as asmlinkage
x86: Inline the CLOCK_MONOTONIC vdso code
arch/x86/vdso/vclock_gettime.c | 14 +++---
1
This makes no difference for 64-bit, bit it's critical for 32-bit code:
these functions are called from outside the kernel, so they need to comply
with the ABI.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/vdso/vclock_gettime.c | 12 ++--
1 file changed, 6 insertions
This saves a nanosecond or so on my box.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/vdso/vclock_gettime.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c
index 260a422..9234c83 100644
On Wed, Feb 26, 2014 at 10:06 PM, H. Peter Anvin h...@zytor.com wrote:
On 02/26/2014 07:39 PM, Andi Kleen wrote:
On Wed, Feb 26, 2014 at 05:02:13PM -0800, Andy Lutomirski wrote:
This makes no difference for 64-bit, bit it's critical for 32-bit code:
these functions are called from outside
On Wed, Feb 26, 2014 at 9:22 PM, H. Peter Anvin h...@zytor.com wrote:
On 02/26/2014 09:19 PM, Andy Lutomirski wrote:
The normal ABI almost certainly makes more sense; as such -mregparm=3 is
probably not what we want, and I suspect it makes more sense to just
drop that from the CFLAGS line
Currently, dealing with Linux syscalls in an architecture-independent
way is a mess. Here are some issues:
1. There's no clean way to map between syscall names and numbers on
different architectures. The kernel contains a number of tables (that
work differently for different architectures).
rdtsc_barrier() needs this.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/include/asm/vdso.h | 2 ++
arch/x86/vdso/vdso32-setup.c | 25 +
arch/x86/vdso/vma.c | 9 ++---
3 files changed, 21 insertions(+), 15 deletions(-)
diff --git a/arch
asmlinkage.
- Add more fixes.
Andy Lutomirski (4):
x86: Use the default ABI for the 32-bit vDSO
x86: Inline the CLOCK_MONOTONIC vdso code
x86: Patch alternatives in the 32-bit vDSO
x86: Zero-pad the VVAR page
arch/x86/include/asm/vdso.h| 2 ++
arch/x86/kernel/vmlinux.lds.S | 5
to userspace.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/kernel/vmlinux.lds.S | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index 1d4897b..49edf2d 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel
There's no reason for the vDSO to use a special function call ABI. Use
the platform defaults.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/vdso/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/vdso/Makefile b/arch/x86/vdso/Makefile
index
This saves a nanosecond or so on my box.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/vdso/vclock_gettime.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c
index 82e..16d6861 100644
On Feb 28, 2014 11:15 AM, Mauro Carvalho Chehab m.che...@samsung.com wrote:
Em Wed, 19 Feb 2014 17:39:07 -0800
Andy Lutomirski l...@amacapital.net escreveu:
On Wed, Feb 19, 2014 at 11:03 AM, Luck, Tony tony.l...@intel.com wrote:
(I'm c/c Tony here, as he also shared the same concern
On Thu, Feb 27, 2014 at 11:33 PM, Stefani Seibold stef...@seibold.net wrote:
Am Donnerstag, den 27.02.2014, 16:18 -0800 schrieb Andy Lutomirski:
I'd still like someone else to confirm that the 32-bit vDSO is working
on all common configurations before I'm happy with it, but this should
On Fri, Feb 28, 2014 at 7:06 AM, H. Peter Anvin h...@zytor.com wrote:
How many internal function calls are there? It seems we should try to avoid
those as much as possible by suitable inlining.
There are no non-static calls at all, except for __x86.get_pc_thunk.
I imagine that gcc is smart
On Thu, Feb 27, 2014 at 11:22 PM, Stefani Seibold stef...@seibold.net wrote:
Am Mittwoch, den 26.02.2014, 16:55 -0800 schrieb Andy Lutomirski:
Once I patch it to work, your 32-bit code is considerably faster than
the 64-bit case. It's enough faster that I suspect a bug. Dumping
review and debug work that Andy Lutomirski did for the series. Please
add Acked-by or Reviewed-by tags to credit his contributions, as
appropriate. (if Andy is fine with that.)
I'm okay w/ Reviewed-by, except for the patch for 32-bit vdso on
64-bit, which I haven't really reviewed (nor do I feel
On Tue, Mar 4, 2014 at 12:58 PM, Thomas Gleixner t...@linutronix.de wrote:
On Tue, 25 Feb 2014, Andy Lutomirski wrote:
On the other hand, if you added a fancier version of timerfd_settime
that could explicitly set the slack value (or, equivalently, the
earliest and latest allowable times
On Tue, Mar 4, 2014 at 2:11 PM, Thomas Gleixner t...@linutronix.de wrote:
On Tue, 4 Mar 2014, Andy Lutomirski wrote:
On Tue, Mar 4, 2014 at 12:58 PM, Thomas Gleixner t...@linutronix.de wrote:
On Tue, 25 Feb 2014, Andy Lutomirski wrote:
On the other hand, if you added a fancier version
On Tue, Mar 4, 2014 at 4:10 PM, Thomas Gleixner t...@linutronix.de wrote:
On Tue, 4 Mar 2014, Andy Lutomirski wrote:
On Tue, Mar 4, 2014 at 2:11 PM, Thomas Gleixner t...@linutronix.de wrote:
We do no add another random special case syscall for timerfd just
because timerfd is linux specific
On Tue, Mar 4, 2014 at 11:27 AM, H. Peter Anvin h...@zytor.com wrote:
On 02/27/2014 12:40 PM, Andy Lutomirski wrote:
Currently, dealing with Linux syscalls in an architecture-independent
way is a mess. Here are some issues:
1. There's no clean way to map between syscall names and numbers
needs to know what the pointed-to type is for pointer
arguments, whether pointers are input, output, or both, and what kind
of flags / constants fit in which integer slot.
--Andy
-hpa
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line
On Thu, Mar 6, 2014 at 11:21 PM, Stefani Seibold stef...@seibold.net wrote:
Hi Fengguang,
i have build a kernel with the config, but my kvm is unable to start it.
I will try to find a way to test your kernek config.
One thing is the crash point:
The function sysenter_setup was modified by
On Fri, Mar 7, 2014 at 1:53 PM, Stefani Seibold stef...@seibold.net wrote:
Am Freitag, den 07.03.2014, 10:56 -0800 schrieb Andy Lutomirski:
On Thu, Mar 6, 2014 at 11:21 PM, Stefani Seibold stef...@seibold.net wrote:
Hi Fengguang,
i have build a kernel with the config, but my kvm is unable
On recent (3.13) kernels, I'm frequently getting messages like:
perf samples too long (2503 2500), lowering
kernel.perf_event_max_sample_rate to 5
a few seconds to minutes after bootup. As far as I know, I'm not
using perf. What's going on here?
--Andy
--
To unsubscribe from this list:
On Sat, Mar 8, 2014 at 1:13 AM, Markus Trippelsdorf
mar...@trippelsdorf.de wrote:
On 2014.03.08 at 08:51 +0100, Mike Galbraith wrote:
On Fri, 2014-03-07 at 17:57 -0800, Andy Lutomirski wrote:
On recent (3.13) kernels, I'm frequently getting messages like:
perf samples too long (2503 2500
The warning is not indicative of an actual problem, especially when
triggered by nmi_watchdog, so lower it to KERN_INFO. While I'm at
it, clarify the message and reference the sysctl that controls it.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
kernel/events/core.c | 5 ++---
1 file
If an administrator wants to use MEI, they can search the logs for
'mei'. Otherwise they don't need a glaring reminder that their
hardware doesn't actually support MEI.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
drivers/misc/mei/pci-me.c | 2 +-
1 file changed, 1 insertion(+), 1
A bunch of drivers that my system loads spew out KERN_ERR or
severity-less messages at startup. These message are not errors. Fix
them.
Andy Lutomirski (4):
mei: Don't log an error when the MEI device is quirked off
megaraid: Downgrade success messages from KERN_ERR to dev_dbg
sr: Add
Some of them are errors; some are not. Annotate them accordingly.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
lib/raid6/algos.c | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/lib/raid6/algos.c b/lib/raid6/algos.c
index f0b1aa3..6edc821 100644
The existence if scsi3-mmc capabilities is not an error.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
drivers/scsi/sr.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
index 40d8592..67baf7f 100644
--- a/drivers/scsi/sr.c
These messages are uninteresting indications of success.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
drivers/scsi/megaraid/megaraid_sas_base.c | 2 +-
drivers/scsi/megaraid/megaraid_sas_fusion.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi
On Sun, Mar 9, 2014 at 5:16 PM, H. Peter Anvin h...@linux.intel.com wrote:
On 03/09/2014 12:47 AM, Stefani Seibold wrote:
But let me ask an other question: Is the compat mode still needed
anymore?
Since Lguest, XEN, OPLC and the reservetop kernel parameter will change
the __FIXADDR_TOP,
On Sun, Mar 9, 2014 at 8:18 PM, Andy Lutomirski l...@amacapital.net wrote:
(Of course, I haven't the faintest idea what l_addr in glibc means.
If there was a way to arrange for l_addr to be zero, then maybe none
of this would matter. Hmm, I wonder if just not relocating the vdso
at all would
On Mon, Mar 10, 2014 at 8:11 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Mar 10, 2014 8:01 AM, H. Peter Anvin h...@linux.intel.com wrote:
I have mentioned in the past wanting to move the fixmap to the low part
of the kernel space, because the top isn't really fixed...
How
On Mon, Mar 10, 2014 at 10:24 AM, H. Peter Anvin h...@linux.intel.com wrote:
On 03/10/2014 10:12 AM, Andy Lutomirski wrote:
On Mon, Mar 10, 2014 at 8:11 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Mar 10, 2014 8:01 AM, H. Peter Anvin h...@linux.intel.com wrote:
I have
On Mon, Mar 10, 2014 at 10:38 AM, H. Peter Anvin h...@linux.intel.com wrote:
On 03/10/2014 10:31 AM, Andy Lutomirski wrote:
For 64-bit, this is an entirely different story. The vsyscall page is
stuck in the fixmap forever, although I want to add a way for
userspace to opt out. The vvar page
On Mon, Mar 10, 2014 at 10:48 AM, H. Peter Anvin h...@linux.intel.com wrote:
On 03/10/2014 10:46 AM, Andy Lutomirski wrote:
Yes, we'd have to switch the vdso to using syscall access. Doing that
from inside a system call is... interesting.
It's a little less interesting if it just involves
On Mon, Mar 10, 2014 at 10:58 AM, H. Peter Anvin h...@linux.intel.com wrote:
On 03/10/2014 10:52 AM, Andy Lutomirski wrote:
Hint: where is your RIP? Where is the RIP of other processes?
Whoa there, I'm not suggesting anything nearly that crazy :)
I'm suggesting changing out the vvar page
On Mon, Mar 10, 2014 at 2:20 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Mon, Mar 10, 2014 at 1:19 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
If the only immediate problem is the code generation size, then Andy
already had a (simpler) hack-around:
#undef
On Mon, Mar 10, 2014 at 2:53 PM, stef...@seibold.net wrote:
Zitat von Linus Torvalds torva...@linux-foundation.org:
On Mon, Mar 10, 2014 at 2:25 PM, stef...@seibold.net wrote:
This was discovered by me.
Sorry for the misattribution.
But this is not a real solution, at least when vcpu
On Mon, Mar 10, 2014 at 3:03 PM, Andy Lutomirski l...@amacapital.net wrote:
On Mon, Mar 10, 2014 at 2:53 PM, stef...@seibold.net wrote:
Zitat von Linus Torvalds torva...@linux-foundation.org:
On Mon, Mar 10, 2014 at 2:25 PM, stef...@seibold.net wrote:
This was discovered by me.
Sorry
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
On Mon, Mar 10, 2014 at 5:13 PM, H. Peter Anvin h...@linux.intel.com wrote:
On 03/10/2014 05:12 PM, Andy Lutomirski wrote:
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
On Mon, Mar 10, 2014 at 5:38 PM, Dave Jones da...@redhat.com wrote:
On Mon, Mar 10, 2014 at 05:19:27PM -0700, Andy Lutomirski wrote:
On Mon, Mar 10, 2014 at 5:13 PM, H. Peter Anvin h...@linux.intel.com
wrote:
On 03/10/2014 05:12 PM, Andy Lutomirski wrote:
The compat vDSO
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
On Mon, Mar 10, 2014 at 6:39 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Mon, Mar 10, 2014 at 6:03 PM, Andy Lutomirski l...@amacapital.net wrote:
This is a bit of an abuse of the no-breaking-userspace policy.
No it's not, because it won't be applied.
You need to fix it.
I'm
On Mon, Mar 10, 2014 at 8:09 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Mon, Mar 10, 2014 at 7:37 PM, Andy Lutomirski l...@amacapital.net wrote:
It does. My patch breaks OpenSuSE 9 when
CONFIG_ENABLE_VDSO32_BY_DEFAULT=y unless it's overridden by sysctl or
boot option.
Oh, I
On Mar 11, 2014 2:36 AM, Linus Torvalds torva...@linux-foundation.org wrote:
On Mon, Mar 10, 2014 at 9:10 PM, Andy Lutomirski l...@amacapital.net wrote:
I suspect that a lot of 32-bit Linux users want syscall and/or
sysenter, and Stefani certainly wants the fast timing that the vDSO
can
shouldn't care about
x86-32, and certainly not from a performance angle - we should
consider it a it's done, don't touch it issue.
I'll let other people fight this particular battle :)
Linus
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list
On Tue, Mar 11, 2014 at 9:42 AM, H. Peter Anvin h...@linux.intel.com wrote:
On 03/11/2014 09:30 AM, Linus Torvalds wrote:
No, the trivial solution is to stop adding crap to it.
And no, just reserve a little more space for it is neither trivial
nor a good idea. The fixed VDSO address is very
Looking forward, would it be reasonable to have an extensible set of
flags that live in the ELF interpreter's headers somewhere that
indicate compatibility hacks that the program in question doesn't
need? There are at least two things I can think of:
- no_compat_vdso32: indicates an interpreter
On Tue, Mar 11, 2014 at 10:09 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Tue, Mar 11, 2014 at 9:50 AM, Andy Lutomirski l...@amacapital.net wrote:
Looking forward, would it be reasonable to have an extensible set of
flags that live in the ELF interpreter's headers somewhere
be that CONFIG_COMPAT_VDSO users
get an extra line in their kernel log at startup. Perhaps a few
of them will stop using CONFIG_COMPAT_VDSO as a result.
This does not actually add support for vDSO images 4k, but it
will make it much easier to do so in the future.
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 now lives
in an ordinary vma, so the user bit can be removed.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/include/asm/pgtable_types.h | 7 +--
1
be that CONFIG_COMPAT_VDSO users
get an extra line in their kernel log at startup. Perhaps a few
of them will stop using CONFIG_COMPAT_VDSO as a result.
This does not actually add support for vDSO images 4k, but it
will make it much easier to do so in the future.
Signed-off-by: Andy Lutomirski l...@amacapital.net
The meat of this patch series is in patch 1. Patch 2 is split out for
improved bisectability.
Changes from v1: Split into two patches and fixed a comment.
Andy Lutomirski (2):
x86: Dynamically relocate the compat vdso
x86_32: Remove user bit from identity map PDE
Documentation/kernel
On Tue, Mar 11, 2014 at 3:03 AM, Winkler, Tomas tomas.wink...@intel.com wrote:
-Original Message-
From: Andy Lutomirski [mailto:l...@amacapital.net]
Sent: Saturday, March 08, 2014 20:58
To: linux-kernel@vger.kernel.org
Cc: triv...@kernel.org; Andy Lutomirski; Winkler, Tomas
Subject
On Sat, Mar 8, 2014 at 11:14 AM, Paul Bolle pebo...@tiscali.nl wrote:
On Sat, 2014-03-08 at 10:58 -0800, Andy Lutomirski wrote:
Some of them are errors; some are not. Annotate them accordingly.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
lib/raid6/algos.c | 13 +++--
1
On Mar 11, 2014 10:02 PM, H. Peter Anvin h...@zytor.com wrote:
On 03/11/2014 03:15 PM, Andy Lutomirski wrote:
The meat of this patch series is in patch 1. Patch 2 is split out for
improved bisectability.
Changes from v1: Split into two patches and fixed a comment.
Andy Lutomirski (2
On Fri, Jan 10, 2014 at 9:41 AM, Peter Zijlstra pet...@infradead.org wrote:
On Fri, Jan 10, 2014 at 06:02:23PM +0100, Peter Zijlstra wrote:
On Fri, Jan 10, 2014 at 05:58:22PM +0100, Peter Zijlstra wrote:
On Fri, Jan 10, 2014 at 10:29:13AM -0500, Waiman Long wrote:
Peter,
Call Trace:
On Fri, Jan 10, 2014 at 7:00 AM, Victor Porton por...@narod.ru wrote:
I don't quite understand your subreaper mode 2, but for me it looks like that
this would break compatibility (sandboxed applications ideally should not be
written in any special way, any application which does not open new
On 01/10/2014 10:14 AM, Victor Porton wrote:
I was told that it can be done using cgroups. So no urgent necessity to add
my new syscall.
Yeah, right. Good luck writing a program that will work on modern Red
Hat, Fedora, and Ubuntu systems.
Cgroups is IMO a complete and utter failure in
On Fri, Jan 10, 2014 at 11:43 AM, Waiman Long waiman.l...@hp.com wrote:
On 01/10/2014 01:54 PM, Andy Lutomirski wrote:
On Fri, Jan 10, 2014 at 9:41 AM, Peter Zijlstrapet...@infradead.org
wrote:
On Fri, Jan 10, 2014 at 06:02:23PM +0100, Peter Zijlstra wrote:
On Fri, Jan 10, 2014 at 05:58
On Fri, Jan 10, 2014 at 12:06 PM, Peter Zijlstra pet...@infradead.org wrote:
On Fri, Jan 10, 2014 at 10:54:52AM -0800, Andy Lutomirski wrote:
Yuck -- when I wrote that thing, I hadn't imagined that an interrupt
(there's nothing particularly special about NMIs here, I think) would
try to access
On 01/13/2014 12:30 PM, Will Drewry wrote:
Applying restrictive seccomp filter programs to large or diverse
codebases often requires handling threads which may be started early in
the process lifetime (e.g., by code that is linked in). While it is
possible to apply permissive programs prior
On Tue, Jan 14, 2014 at 10:59 AM, Will Drewry w...@chromium.org wrote:
On Mon, Jan 13, 2014 at 5:36 PM, Andy Lutomirski l...@amacapital.net wrote:
On 01/13/2014 12:30 PM, Will Drewry wrote:
Applying restrictive seccomp filter programs to large or diverse
codebases often requires handling
[cc: drh, who I suspect is responsible for the most widespread
userspace software that uses this stuff]
On Tue, Jan 14, 2014 at 11:27 AM, J. Bruce Fields bfie...@fieldses.org wrote:
On Thu, Jan 09, 2014 at 04:58:59PM -0800, Andy Lutomirski wrote:
On Thu, Jan 9, 2014 at 4:49 PM, Jeff Layton jlay
On Tue, Jan 14, 2014 at 12:59 PM, Will Drewry w...@chromium.org wrote:
On Tue, Jan 14, 2014 at 2:24 PM, Andy Lutomirski l...@amacapital.net wrote:
On Tue, Jan 14, 2014 at 10:59 AM, Will Drewry w...@chromium.org wrote:
On Mon, Jan 13, 2014 at 5:36 PM, Andy Lutomirski l...@amacapital.net
wrote
On Tue, Jan 14, 2014 at 1:10 PM, J. Bruce Fields bfie...@fieldses.org wrote:
On Tue, Jan 14, 2014 at 12:29:17PM -0800, Andy Lutomirski wrote:
[cc: drh, who I suspect is responsible for the most widespread
userspace software that uses this stuff]
On Tue, Jan 14, 2014 at 11:27 AM, J. Bruce
On Tue, Jan 14, 2014 at 1:19 PM, Frank Filz ffilz...@mindspring.com wrote:
On Tue, Jan 14, 2014 at 12:29:17PM -0800, Andy Lutomirski wrote:
[cc: drh, who I suspect is responsible for the most widespread
userspace software that uses this stuff]
On Tue, Jan 14, 2014 at 11:27 AM, J. Bruce
On Tue, Jan 14, 2014 at 1:21 PM, Richard Hipp d...@sqlite.org wrote:
I have no context here. I'm not sure what you are discussing or what
questions you have or what SQLite has to do with any of it. Nevertheless, I
have injected a few remarks inline
The discussion is about a new set of
[grr, gmail -- I didn't actually intend to send that.]
On Tue, Jan 14, 2014 at 1:24 PM, Andy Lutomirski l...@amacapital.net wrote:
On Tue, Jan 14, 2014 at 1:19 PM, Frank Filz ffilz...@mindspring.com wrote:
process 2 requests a write lock, gets -EDEADLK, unlocks and
requests a new
On Tue, Jan 14, 2014 at 1:51 PM, J. Bruce Fields bfie...@fieldses.org wrote:
On Tue, Jan 14, 2014 at 01:26:26PM -0800, Andy Lutomirski wrote:
[grr, gmail -- I didn't actually intend to send that.]
On Tue, Jan 14, 2014 at 1:24 PM, Andy Lutomirski l...@amacapital.net wrote:
On Tue, Jan 14
On Thu, Feb 13, 2014 at 6:50 AM, Peter Zijlstra pet...@infradead.org wrote:
On Wed, Feb 12, 2014 at 05:40:12PM -0800, Andy Lutomirski wrote:
This is a strawman proposal to simplify the idle implementation, eliminate
a race
Benefits over current code:
- ttwu_queue_remote doesn't use an IPI
On Thu, Feb 13, 2014 at 9:28 AM, Miklos Szeredi mik...@szeredi.hu wrote:
On Thu, Feb 13, 2014 at 5:42 PM, David Howells dhowe...@redhat.com wrote:
Miklos Szeredi mik...@szeredi.hu wrote:
Regarding whiteouts, I raised a couple of questions that nobody answered
yet, so let me ask again.
- If
On Thu, Feb 13, 2014 at 6:50 AM, Peter Zijlstra pet...@infradead.org wrote:
On Wed, Feb 12, 2014 at 05:40:12PM -0800, Andy Lutomirski wrote:
This is a strawman proposal to simplify the idle implementation, eliminate
a race
Benefits over current code:
- ttwu_queue_remote doesn't use an IPI
On Thu, Feb 13, 2014 at 12:16 PM, Peter Zijlstra pet...@infradead.org wrote:
On Thu, Feb 13, 2014 at 09:07:10AM -0800, Andy Lutomirski wrote:
I also don't really like how the polling state is an atomic; its a cpu
local property.
Your patch also makes polling state be an atomic (albeit one
On Thu, Feb 13, 2014 at 11:58 AM, Andy Lutomirski l...@amacapital.net wrote:
On Thu, Feb 13, 2014 at 6:50 AM, Peter Zijlstra pet...@infradead.org wrote:
On Wed, Feb 12, 2014 at 05:40:12PM -0800, Andy Lutomirski wrote:
This is a strawman proposal to simplify the idle implementation, eliminate
On Thu, Feb 13, 2014 at 6:50 AM, Peter Zijlstra pet...@infradead.org wrote:
On Wed, Feb 12, 2014 at 05:40:12PM -0800, Andy Lutomirski wrote:
This is a strawman proposal to simplify the idle implementation, eliminate
a race
Benefits over current code:
- ttwu_queue_remote doesn't use an IPI
On Fri, Feb 14, 2014 at 12:01 PM, Andy Lutomirski l...@amacapital.net wrote:
On Thu, Feb 13, 2014 at 6:50 AM, Peter Zijlstra pet...@infradead.org wrote:
On Wed, Feb 12, 2014 at 05:40:12PM -0800, Andy Lutomirski wrote:
This is a strawman proposal to simplify the idle implementation, eliminate
.
The patch is against kernel 3.14 (e7651b819e90da924991d727d3c007200a18670d)
Changelog:
25.11.2012 - first release and proof of concept for linux 3.4
11.12.2012 - Port to linux 3.7 and code cleanup
12.12.2012 - fixes suggested by Andy Lutomirski
- fixes suggested by John Stultz
On Tue, Feb 18, 2014 at 11:39 AM, Eric Paris epa...@redhat.com wrote:
On Fri, 2014-02-07 at 08:40 -0800, Andy Lutomirski wrote:
On Fri, Feb 7, 2014 at 4:58 AM, Jonas Bonn jonas.b...@gmail.com wrote:
Hi Andy,
On 5 February 2014 00:50, Andy Lutomirski l...@amacapital.net wrote:
I can't
On Wed, Feb 19, 2014 at 7:38 AM, Wolfram Sang w...@the-dreams.de wrote:
+config I2C_IMC
+ tristate Intel iMC (LGA 2011) SMBus Controller
+ depends on PCI X86
+ select I2C_DIMM_BUS
+ help
+ If you say yes to this option, support will be included for the Intel
+
On Wed, Feb 19, 2014 at 7:16 AM, Wolfram Sang w...@the-dreams.de wrote:
On Fri, Dec 20, 2013 at 05:45:13PM -0800, Andy Lutomirski wrote:
Add i2c_scan_dimm_bus to declare that a particular i2c_adapter
contains DIMMs. This will probe (and autoload modules!) for useful
SMBUS devices that live
On Wed, Feb 19, 2014 at 11:26 AM, One Thousand Gnomes
gno...@lxorguk.ukuu.org.uk wrote:
example, lots of graphics drivers provide i2c busses, and those busses
often contain eeproms, and, in theory, things should know that the
eeprom is associated with a particular graphics port, for example.
will contribute an engineer who help :)
--Andy
-Tony
--
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
On Thu, Feb 20, 2014 at 8:42 AM, Luck, Tony tony.l...@intel.com wrote:
NV-DIMM control registers are exposed via i2c, presumably because
trying to access them through the memory pins would be a giant mess.
So, one way or another, something needs to be able to initiate
transactions to access
On Mon, Feb 10, 2014 at 8:57 AM, Oleg Nesterov o...@redhat.com wrote:
On 02/08, Andy Lutomirski wrote:
+void audit_inc_n_rules()
+{
+ struct task_struct *p, *t;
+
+ read_lock(tasklist_lock);
+ audit_n_rules++;
+ smp_wmb();
+ if (audit_n_rules == 1
On Mon, Feb 10, 2014 at 9:47 AM, Steve Grubb sgr...@redhat.com wrote:
On Monday, February 10, 2014 09:29:19 AM Andy Lutomirski wrote:
Grr. Why is all this crap tied up with syscall auditing anyway? ISTM
it would have been a lot nicer if audit calls just immediately emitted
audit records
On Mon, Feb 10, 2014 at 9:29 AM, Andy Lutomirski l...@amacapital.net wrote:
On Mon, Feb 10, 2014 at 8:57 AM, Oleg Nesterov o...@redhat.com wrote:
On 02/08, Andy Lutomirski wrote:
+void audit_inc_n_rules()
+{
+ struct task_struct *p, *t;
+
+ read_lock(tasklist_lock
On 02/08/2014 02:24 PM, Linus Torvalds wrote:
On Sat, Feb 8, 2014 at 12:44 PM, Richard Yao r...@gentoo.org wrote:
However, is_vmalloc_addr() only applies to the vmalloc region. While all
architectures load kernel modules into virtual memory (to my knowledge),
some architectures do not load
On Mon, Feb 10, 2014 at 11:12 AM, Steve Grubb sgr...@redhat.com wrote:
On Monday, February 10, 2014 11:01:36 AM Andy Lutomirski wrote:
And I still think this needs more changes. Once again, I do not think
that, say, __audit_log_bprm_fcaps() should populate context-aux if
!TIF_SYSCALL_AUDIT
There are least three choices for what the current frequency is:
1. The frequency that the cpufreq driver thinks it has requested.
This shows up in scaling_cur_freq.
2. The frequency that is actually programmed into the CPU. This is
what acpi_cpufreq's cpuinfo_cur_freq reports.
3. A
Rumor has it that Linux 3.13 was supposed to get rid of all the silly
rescheduling interrupts. It doesn't, although it does seem to have
improved the situation.
A small number of reschedule interrupts appear to be due to a race:
both resched_task and wake_up_idle_cpu do, essentially:
On Tue, Feb 11, 2014 at 1:21 PM, Thomas Gleixner t...@linutronix.de wrote:
On Tue, 11 Feb 2014, Andy Lutomirski wrote:
Just adding Peter for now, as I'm too tired to grok the issue right
now.
Rumor has it that Linux 3.13 was supposed to get rid of all the silly
rescheduling interrupts
On Wed, Feb 12, 2014 at 2:13 AM, Peter Zijlstra pet...@infradead.org wrote:
On Tue, Feb 11, 2014 at 02:34:11PM -0800, Andy Lutomirski wrote:
On Tue, Feb 11, 2014 at 1:21 PM, Thomas Gleixner t...@linutronix.de wrote:
A small number of reschedule interrupts appear to be due to a race:
both
On Wed, Feb 12, 2014 at 8:39 AM, Peter Zijlstra pet...@infradead.org wrote:
On Wed, Feb 12, 2014 at 07:49:07AM -0800, Andy Lutomirski wrote:
On Wed, Feb 12, 2014 at 2:13 AM, Peter Zijlstra pet...@infradead.org wrote:
Exactly. AFAICT the only reason that any of this code holds rq-lock
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 bound table and bind it with that buond directory entry.
This will avoid the need of forwarding the #BR exception
to the
On Wed, Feb 12, 2014 at 12:40 PM, stef...@seibold.net wrote:
From: Stefani Seibold Stefani Seibold stef...@seibold.net
This patch adds conditional fixmap of the VVAR and HPET pages for a 32
bit kernel
Signed-off-by: Stefani Seibold Stefani Seibold stef...@seibold.net
Looks good to me.
401 - 500 of 19466 matches
Mail list logo
