On Tue, Feb 13, 2007 at 03:29:04PM +0200, Hasso Tepper wrote:
There is long standing issue in kernel which makes using /etc/sysctl.conf
useless for boottime configuration of specific interface properties and
breaks probably any software relying on unconditional existence of the
conf trees like
On Tue, Feb 13, 2007 at 02:43:32PM -0500, Vlad Yasevich wrote:
Neil Horman wrote:
On Tue, Feb 13, 2007 at 03:29:04PM +0200, Hasso Tepper wrote:
There is long standing issue in kernel which makes using /etc/sysctl.conf
useless for boottime configuration of specific interface properties
On Wed, Feb 14, 2007 at 10:16:44PM -0800, v j wrote:
On 2/14/07, v j [EMAIL PROTECTED] wrote:
This has nothing to do with politics. I am not a Linux contributor. I
realize that people who have contributed to the Linux Kernel have very
valid points. It is their sweat and blood. They have a
On Wed, Feb 14, 2007 at 10:27:10PM -0800, v j wrote:
On 2/14/07, Dave Jones [EMAIL PROTECTED] wrote:
On Wed, Feb 14, 2007 at 09:16:28PM -0800, v j wrote:
Welcome to three months ago.
Here in the future, this was deemed a non-issue.
However this does highlight another problem.
End-users who
On Thu, Feb 15, 2007 at 10:25:12PM -0800, v j wrote:
It's written in black and white, in the license.
Please point me to where it says I cannot load proprietary modules in
the Kernel.
It doesn't, but EXPORT_SYMBOL_GPL makes it quite clear what you can not do if
you are not a GPL module.
On Fri, Feb 23, 2007 at 01:49:47PM +0200, Markku Savela wrote:
The IPv6 and IPv4 both seem to be rather akwardly hardcoded to support
only link layers they know.
This is a pity, because it would be so easy to make the both stacks
totally independent of the actual link layers. It only needs
On Thu, Dec 13, 2007 at 10:32:22AM -0500, Neil Horman wrote:
On Thu, Dec 13, 2007 at 04:16:29PM +0100, Andi Kleen wrote:
On Thu, Dec 13, 2007 at 09:39:22AM -0500, Neil Horman wrote:
Ok, new patch attached, taking into account Andi's request for a cleaner
method
Sorry
On Mon, Dec 17, 2007 at 04:16:42PM +0100, Ingo Molnar wrote:
* Neil Horman [EMAIL PROTECTED] wrote:
Ok, new patch attached, taking into account Andi's request for a
cleaner method to implement single application quirks. I've spoken
with Ben, who is continuing to retest, and reports
--
/***
*Neil Horman
*Software Engineer
*Red Hat, Inc.
[EMAIL PROTECTED]
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On Thu, Nov 29, 2007 at 07:54:16PM -0700, Eric W. Biederman wrote:
Ben Woodard [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Vivek Goyal [EMAIL PROTECTED] writes:
Ok. Got it. So in this case we route the interrupts directly through LAPIC
and put LVT0 in ExtInt mode and IOAPIC is
On Fri, Nov 30, 2007 at 09:51:31AM -0500, Neil Horman wrote:
On Fri, Nov 30, 2007 at 09:42:50AM -0500, Vivek Goyal wrote:
snip
Thats what I'm doing at the moment. I'm working on a RHEL5 patch at the
moment
(since thats whats on the production system thats failing), and will forward
port
On Thu, Dec 06, 2007 at 05:11:43PM -0500, Vivek Goyal wrote:
On Thu, Dec 06, 2007 at 04:39:51PM -0500, Neil Horman wrote:
On Fri, Nov 30, 2007 at 09:51:31AM -0500, Neil Horman wrote:
On Fri, Nov 30, 2007 at 09:42:50AM -0500, Vivek Goyal wrote:
snip
Thats what I'm doing at the moment
On Thu, Dec 06, 2007 at 05:33:31PM -0700, Eric W. Biederman wrote:
Vivek Goyal [EMAIL PROTECTED] writes:
On Thu, Dec 06, 2007 at 04:39:51PM -0500, Neil Horman wrote:
On Fri, Nov 30, 2007 at 09:51:31AM -0500, Neil Horman wrote:
On Fri, Nov 30, 2007 at 09:42:50AM -0500, Vivek Goyal wrote
On Fri, Dec 07, 2007 at 09:39:44AM -0500, Vivek Goyal wrote:
On Thu, Dec 06, 2007 at 07:10:23PM -0500, Neil Horman wrote:
On Thu, Dec 06, 2007 at 05:11:43PM -0500, Vivek Goyal wrote:
On Thu, Dec 06, 2007 at 04:39:51PM -0500, Neil Horman wrote:
On Fri, Nov 30, 2007 at 09:51:31AM -0500
the patch to make this check occur for any pci class 0600
device from vendor AMD, since its possible that more than just nvidia chipsets
can be affected.
I'll repost as soon as I've tested, thanks!
Neil
--
/***
*Neil Horman
*Software Engineer
*Red Hat
On Fri, Dec 07, 2007 at 10:16:23AM -0500, Vivek Goyal wrote:
On Fri, Dec 07, 2007 at 09:53:15AM -0500, Neil Horman wrote:
On Fri, Dec 07, 2007 at 09:39:44AM -0500, Vivek Goyal wrote:
On Thu, Dec 06, 2007 at 07:10:23PM -0500, Neil Horman wrote:
On Thu, Dec 06, 2007 at 05:11:43PM -0500
On Fri, Dec 07, 2007 at 09:21:44AM -0500, Neil Horman wrote:
On Fri, Dec 07, 2007 at 01:22:04AM -0800, Yinghai Lu wrote:
On Dec 7, 2007 12:50 AM, Yinghai Lu [EMAIL PROTECTED] wrote:
On Dec 6, 2007 4:33 PM, Eric W. Biederman [EMAIL PROTECTED] wrote:
...
My feel
On Fri, Dec 07, 2007 at 11:36:58AM -0700, Eric W. Biederman wrote:
Neil Horman [EMAIL PROTECTED] writes:
this seems reasonable, I can reroll the patch for this. As I think about
it I'm
also going to update the patch to make this check occur for any pci class
0600
device from vendor
accomplished that. Tested by myself and
the origional reporter with successful results.
Regards,
Neil
Signed-off-by: Neil Horman [EMAIL PROTECTED]
arch/x86/kernel/crash.c | 46 ++
include/linux/kexec.h |3 +++
init/main.c |6
On Mon, Nov 26, 2007 at 09:12:25PM -0700, Eric W. Biederman wrote:
Neil Horman [EMAIL PROTECTED] writes:
Hey all-
I've been working on an issue lately involving multi socket x86_64
systems connected via hypertransport bridges. It appears that some systems,
disable
On Tue, Nov 27, 2007 at 11:55:03AM +0100, Andi Kleen wrote:
On Mon, Nov 26, 2007 at 08:47:40PM -0500, Neil Horman wrote:
Hey all-
I've been working on an issue lately involving multi socket x86_64
systems connected via hypertransport bridges. It appears that some systems,
disable
On Tue, Nov 27, 2007 at 06:28:13AM -0700, Eric W. Biederman wrote:
Neil Horman [EMAIL PROTECTED] writes:
What makes you say this? I don't see any need for interrupts prior to
calibrate_delay()
Yes. calibrate_delay() is the first place we send interrupts over
hypertransport. However I
On Tue, Nov 27, 2007 at 02:45:56PM +0100, Andi Kleen wrote:
his is any less reliable that what we have currently.
It doesn't make things more reliable, and it adds code to a code path
that already has to much code to be solid reliable (thus your
problem).
Putting the system back in
On Tue, Nov 27, 2007 at 03:43:11PM +0100, Andi Kleen wrote:
As for solution 2, that brings me to my previous question. Is that really
as
simple as just not moving the apic to legacy mode? It would seem some
additional programming would be in order to route the interrupt in question
On Tue, Nov 27, 2007 at 07:56:44AM -0700, Eric W. Biederman wrote:
Andi Kleen [EMAIL PROTECTED] writes:
his is any less reliable that what we have currently.
It doesn't make things more reliable, and it adds code to a code path
that already has to much code to be solid reliable (thus
On Tue, Nov 27, 2007 at 08:30:47AM -0700, Eric W. Biederman wrote:
Neil Horman [EMAIL PROTECTED] writes:
So, it sounds to me then, like unless I'm willing to really re-write the
APIC
setup code (which I don't feel qualified to do quite yet), that the
immediate
solution would
objections. I
see no reason why we can't implment this 'both' solution.
Regards
Neil
--
/***
*Neil Horman
*Software Engineer
*Red Hat, Inc.
[EMAIL PROTECTED]
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
On Tue, Nov 27, 2007 at 03:00:11PM -0500, Vivek Goyal wrote:
On Tue, Nov 27, 2007 at 02:42:20PM -0500, Neil Horman wrote:
[..]
Ben I tend to agree. I think re-enabling the APIC early in the boot process
provides a greater degree of reliability in that it more quickly restores
On Tue, Nov 27, 2007 at 12:50:52PM -0800, Ben Woodard wrote:
Eric W. Biederman wrote:
Neil Horman [EMAIL PROTECTED] writes:
So, it sounds to me then, like unless I'm willing to really re-write the
APIC
setup code (which I don't feel qualified to do quite yet), that the
immediate
On Tue, Nov 27, 2007 at 03:38:52PM -0700, Eric W. Biederman wrote:
Neil Horman [EMAIL PROTECTED] writes:
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
Ben, what chipset is this?
Ok, I think from what I understand of what we're reading here, the apic2 =
-1
and pin2 = -1
On Tue, Nov 27, 2007 at 04:05:58PM -0500, Neil Horman wrote:
On Tue, Nov 27, 2007 at 12:50:52PM -0800, Ben Woodard wrote:
Eric W. Biederman wrote:
Neil Horman [EMAIL PROTECTED] writes:
So, it sounds to me then, like unless I'm willing to really re-write the
APIC
setup code (which I
issues in the past.
Thanks
Vivek
--
/***
*Neil Horman
*Software Engineer
*Red Hat, Inc.
[EMAIL PROTECTED]
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***/
-
To unsubscribe from
On Wed, Nov 28, 2007 at 10:36:12AM -0700, Eric W. Biederman wrote:
Neil Horman [EMAIL PROTECTED] writes:
On Wed, Nov 28, 2007 at 10:36:49AM -0500, Vivek Goyal wrote:
On Tue, Nov 27, 2007 at 03:24:35PM -0800, Ben Woodard wrote:
Andi Kleen wrote:
Are we putting the system back in PIC
--
/***
*Neil Horman
*Software Engineer
*Red Hat, Inc.
[EMAIL PROTECTED]
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
On Fri, Dec 07, 2007 at 11:19:10AM -0800, yhlu wrote:
On Dec 7, 2007 9:58 AM, Neil Horman [EMAIL PROTECTED] wrote:
On Fri, Dec 07, 2007 at 09:21:44AM -0500, Neil Horman wrote:
On Fri, Dec 07, 2007 at 01:22:04AM -0800, Yinghai Lu wrote:
On Dec 7, 2007 12:50 AM, Yinghai Lu [EMAIL PROTECTED
On Fri, Dec 07, 2007 at 12:58:32PM -0500, Neil Horman wrote:
Ok, New patch attached. It preforms the same function as previously
described,
but is more restricted in its application. As Yinghai pointed out, the
broadcast mask bit (bit 17 in the htcfg register) should only be enabled
On Mon, Dec 10, 2007 at 06:08:03PM -0700, Eric W. Biederman wrote:
Neil Horman [EMAIL PROTECTED] writes:
snip
Ok. This test is broken. Please remove the == 1. You are looking
for == (1 18). So just saying: if (htcfg (1 18)) should be clearer.
Fixed. Thanks!
+ printk(KERN_INFO
On Mon, Dec 10, 2007 at 09:48:11PM -0700, Eric W. Biederman wrote:
Neil Horman [EMAIL PROTECTED] writes:
Almost there.
cool! :)
snip
We should not need check_hypertransport_config as the generic loop
now does the work for us.
+
static void __init nvidia_bugs(void)
{
#ifdef
On Tue, Dec 11, 2007 at 08:29:20AM -0700, Eric W. Biederman wrote:
Neil Horman [EMAIL PROTECTED] writes:
On Mon, Dec 10, 2007 at 09:48:11PM -0700, Eric W. Biederman wrote:
Neil Horman [EMAIL PROTECTED] writes:
Ok. I just looked at read_pci_config. It doesn't do the right thing
On Tue, Dec 11, 2007 at 10:00:00AM -0800, Yinghai Lu wrote:
On Dec 11, 2007 7:29 AM, Eric W. Biederman [EMAIL PROTECTED] wrote:
Neil Horman [EMAIL PROTECTED] writes:
On Mon, Dec 10, 2007 at 09:48:11PM -0700, Eric W. Biederman wrote:
Neil Horman [EMAIL PROTECTED] writes:
Almost
On Tue, Dec 11, 2007 at 11:46:34AM -0700, Eric W. Biederman wrote:
Neil Horman [EMAIL PROTECTED] writes:
Ok. My only remaining nit to pick is that fix_hypertransport_config
is right in the middle of the nvidia quirks, which can be a bit
confusing when reading through the code. Otherwise I
will be the
result. The fix is to add this patch, whcih add an early pci quirk check, to
forcibly enable this bit in the httcfg register. This enables all cpus on a
system to receive interrupts, and allows kdump kernel bootup to procede
normally.
Regards
Neil
Signed-off-by: Neil Horman [EMAIL
work on this at this point that I'm invested in
not abandoning this fix. If this solves the problem on dual core system, but
not quad core, I'd much rather move forward with this fix and address your quad
core problem as a separate issue.
Neil
-ben
Neil Horman wrote:
Recently a kdump
--
/***
*Neil Horman
[EMAIL PROTECTED]
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo
iteration of this patch.
Thanks Regards
Neil
Eric
--
/***
*Neil Horman
[EMAIL PROTECTED]
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***/
--
To unsubscribe from this list: send the line
this patch, whcih add an early pci quirk check, to
forcibly enable this bit in the httcfg register. This enables all cpus on a
system to receive interrupts, and allows kdump kernel bootup to procede
normally.
Regards
Neil
Signed-off-by: Neil Horman [EMAIL PROTECTED]
early-quirks.c | 86
On Thu, Dec 13, 2007 at 04:16:29PM +0100, Andi Kleen wrote:
On Thu, Dec 13, 2007 at 09:39:22AM -0500, Neil Horman wrote:
Ok, new patch attached, taking into account Andi's request for a cleaner
method
Sorry for not noticing that earlier, but was there a specific reason this
needs
Neil
___
kexec mailing list
[EMAIL PROTECTED]
http://lists.infradead.org/mailman/listinfo/kexec
--
/***
*Neil Horman
*Software Engineer
*Red Hat, Inc.
[EMAIL PROTECTED]
*gpg keyid: 1024D
--
/
* Neil Horman [EMAIL PROTECTED]
* Software Engineer, Red Hat
/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
along the value after that to the requester, so that consistency
checks aren't being run against stale and possibly known data.
CC: Herbert Xu herb...@gondor.apana.org.au
CC: David S. Miller da...@davemloft.net
CC: Neil Horman nhor...@tuxdriver.com
CC: Matt Mackall m...@selenic.com
CC: linux
be called with spinlock already held, so bring
back some extra lock/unlock calls.
CC: Herbert Xu herb...@gondor.apana.org.au
CC: David S. Miller da...@davemloft.net
CC: Neil Horman nhor...@tuxdriver.com
CC: Matt Mackall m...@selenic.com
CC: linux-cry...@vger.kernel.org
Signed-off-by: Jarod
On Thu, Oct 18, 2012 at 10:33:29PM -0400, Sasha Levin wrote:
Hi all,
While fuzzing with trinity inside a KVM tools (lkvm) guest running today's
linux-next, I've
stumbled on the following:
[ 439.574039] BUG: unable to handle kernel paging request at 88001b9f40c8
[ 439.576486] IP:
:) ).
The following 2 patches have been tested out by me.
Thanks Regards
Neil
--
/***
*Neil Horman
*Software Engineer
*Red Hat, Inc.
[EMAIL PROTECTED]
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
Patch 1/2 to fix netfilter socket option removal
This patch changes netfilter socket options to do reference counting on the
module refcounter (And saves us 4 bytes in the structure to boot :) ).
regards
Neil
Signed-off-by: Neil Horman [EMAIL PROTECTED]
include/linux/netfilter.h
Hey-
2nd of two patches. This patch enhances modprobe to operate like rmmod
in non-blocking mode. It also adds a -w option to allow for explicit blocking
operation.
Regards
Neil
Signed-off-by: Neil Horman [EMAIL PROTECTED]
modprobe.8 |9 +
modprobe.c | 21
describe above.
Thanks Regards
Neil
--
/***
*Neil Horman
*Software Engineer
*Red Hat, Inc.
[EMAIL PROTECTED]
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***/
-
To unsubscribe from this list
On Thu, Sep 06, 2007 at 03:41:37AM +1000, Rusty Russell wrote:
On Wed, 2007-09-05 at 13:08 -0400, Neil Horman wrote:
On Thu, Sep 06, 2007 at 02:13:26AM +1000, Rusty Russell wrote:
On Wed, 2007-09-05 at 17:22 +0200, Patrick McHardy wrote:
But I'm wondering, wouldn't module refcounting
On Wed, Sep 05, 2007 at 05:39:11PM -0400, Jon Masters wrote:
On Wed, 2007-09-05 at 15:27 -0400, Neil Horman wrote:
Now, I suppose its possible that I've not been looking at the right source
tree
when doing my work. I've based my modprobe patch on this git tree:
http://git.kernel.org
On Thu, Sep 06, 2007 at 12:33:52PM +0200, Patrick McHardy wrote:
Neil Horman wrote:
On Thu, Sep 06, 2007 at 02:13:26AM +1000, Rusty Russell wrote:
On Wed, 2007-09-05 at 17:22 +0200, Patrick McHardy wrote:
But I'm wondering, wouldn't module refcounting alone fix this problem?
If we make
On Wed, Sep 05, 2007 at 05:39:11PM -0400, Jon Masters wrote:
On Wed, 2007-09-05 at 15:27 -0400, Neil Horman wrote:
Now, I suppose its possible that I've not been looking at the right source
tree
when doing my work. I've based my modprobe patch on this git tree:
http://git.kernel.org
On Thu, Sep 06, 2007 at 09:35:32AM -0400, Jon Masters wrote:
On Thu, 2007-09-06 at 08:55 -0400, Neil Horman wrote:
On Wed, Sep 05, 2007 at 05:39:11PM -0400, Jon Masters wrote:
On Wed, 2007-09-05 at 15:27 -0400, Neil Horman wrote:
Now, I suppose its possible that I've not been looking
On Sun, Sep 09, 2007 at 10:25:50PM +0200, Adrian Bunk wrote:
sctp_addto_param() can become static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
ACK, seems reasonable to me.
Neil
--
/***
*Neil Horman
[EMAIL PROTECTED]
*gpg keyid: 1024D
:
- sctp_memory_pressure
- sctp_memory_allocated
- sctp_sockets_allocated
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Looks fine to me
Acked-by: Neil Horman [EMAIL PROTECTED]
Neil
--
/***
*Neil Horman
[EMAIL PROTECTED]
*gpg keyid: 1024D / 0x92A74FA1
*http
it on their
own, and it allows for do_coredump to specify a infinite limit in the event that
a pipe is configured in /proc/sys/kernel/core_pattern, in which case ulimit -c
should not apply.
Regards
Neil
Signed-off-by: Neil Horman [EMAIL PROTECTED]
arch/mips/kernel/irixelf.c |5
On Tue, Jul 24, 2007 at 02:09:39AM -0700, Andrew Morton wrote:
On Sun, 22 Jul 2007 11:39:47 -0400 Neil Horman [EMAIL PROTECTED] wrote:
This is a follow on to the patch entitled:
update-coredump-path-in-kernel-to-not-check-coredump-rlim-if-core_pattern-is-a-pipe.patch
It allows
On Tue, Jul 24, 2007 at 02:09:39AM -0700, Andrew Morton wrote:
On Sun, 22 Jul 2007 11:39:47 -0400 Neil Horman [EMAIL PROTECTED] wrote:
This is a follow on to the patch entitled:
update-coredump-path-in-kernel-to-not-check-coredump-rlim-if-core_pattern-is-a-pipe.patch
It allows
: 'flat_core_dump' defined but not used
Damn! Sorry about that. At least I have a mediocre excuse in that it was on an
arch I didn't have hardware to test with. Should have caught that sooner
though. Heres the patch for it.
Regards
Neil
Signed-off-by: Neil Horman [EMAIL PROTECTED
application. It also add
a format specifier, %c, which allows the RLIM_CORE value of the crashing
application to be passed on the command line, since RLIMIT_CORE is reduced to
zero when execing the userspace helper
Tested successfully by me on x86 x86_64.
Regards
Neil
Signed-off-by: Neil Horman
On Thu, Jul 26, 2007 at 12:47:31PM -0700, Andrew Morton wrote:
On Thu, 26 Jul 2007 15:31:45 -0400 Neil Horman [EMAIL PROTECTED] wrote:
On Thu, Jul 26, 2007 at 11:48:32AM -0700, Andrew Morton wrote:
On Thu, 26 Jul 2007 13:40:19 -0400 Neil Horman [EMAIL PROTECTED] wrote
On Thu, Jul 26, 2007 at 11:48:32AM -0700, Andrew Morton wrote:
On Thu, 26 Jul 2007 13:40:19 -0400 Neil Horman [EMAIL PROTECTED] wrote:
Currently, core dumps can be redirected to a pipe by placing the
following string template in /proc/sys/kernel/core_pattern:
|path/to/application
On Thu, Jul 26, 2007 at 01:35:36PM -0700, Andrew Morton wrote:
On Thu, 26 Jul 2007 16:20:18 -0400 Neil Horman [EMAIL PROTECTED] wrote:
If you'd like to back them all out, I have them
all in a git tree here, and I can repost (say early next week when I finish
local testing) as a patch
On Thu, Jul 26, 2007 at 03:02:19PM -0700, Jeremy Fitzhardinge wrote:
Neil Horman wrote:
+static void free_argv_array(char **argv)
+{
+ int i;
+ if (argv != NULL) {
+ for (i = 0; argv[i] != NULL; i++)
+ kfree(argv[i]);
+ kfree(argv
to format_corename
such that the origional value of RLIMIT_CORE can be passed to userspace as an
argument.
Thanks Regards
Neil
Signed-off-by: Neil Horman [EMAIL PROTECTED]
exec.c | 25 ++---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/fs/exec.c b/fs
results.
Thanks Regards
Neil
--
/***
*Neil Horman
*Software Engineer
*Red Hat, Inc.
[EMAIL PROTECTED]
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***/
-
To unsubscribe from this list: send
Hey,
Patch 1/3 for the core_pattern enhancements. This removes the check of
RLIMIT_CORE if core_pattern is a pipe. In the event that core_pattern is a
pipe, the entire core will be fed to the user mode helper.
Thanks Regards
Neil
Signed-off-by: Neil Horman [EMAIL PROTECTED]
arch
ad-infinitum.
Thanks Regards
Neil
Signed-off-by: Neil Horman [EMAIL PROTECTED]
fs/exec.c | 14 +-
kernel/kmod.c |2 +-
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/fs/exec.c b/fs/exec.c
index 6855a52..1398d07 100644
--- a/fs/exec.c
+++ b/fs/exec.c
On Fri, Jul 27, 2007 at 01:54:19PM -0700, Jeremy Fitzhardinge wrote:
Neil Horman wrote:
+ int helper_argc = 0;
+ helper_argv = argv_split(GFP_KERNEL, corename+1, helper_argc);
Hm, I suspect most users of argv_split don't really care about argc, so
it would useful
On Wed, Aug 22, 2007 at 09:40:37PM -0500, Matt Mackall wrote:
On Tue, Aug 21, 2007 at 11:56:11AM -0700, Andy Isaacson wrote:
On Fri, Aug 17, 2007 at 12:45:47PM -0700, Andrew Morton wrote:
On Fri, 17 Aug 2007 06:59:18 -0400
Neil Horman [EMAIL PROTECTED] wrote:
Currently, there exists
written this patch which
exports all of a processes limits via /proc/pid/limits. Tested successfully
by myself on x86 on top of 2.6.23-rc2-mm1.
Thanks Regards
Neil
Signed-off-by: Neil Horman [EMAIL PROTECTED]
base.c | 65 +
1
On Mon, Aug 13, 2007 at 12:47:38PM -0400, [EMAIL PROTECTED] wrote:
On Mon, 13 Aug 2007 10:00:44 EDT, Neil Horman said:
Hey there-
Currently, there exists no method for a process to query the resource
limits of another process. They can be inferred via some mechanisms
-by: Neil Horman [EMAIL PROTECTED]
base.c | 65 +
1 file changed, 65 insertions(+)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index ed2b224..b3ddf08 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -74,6 +74,7 @@
#include linux
On Tue, Aug 14, 2007 at 01:04:02AM +0400, Alexey Dobriyan wrote:
On Mon, Aug 13, 2007 at 04:11:30PM -0400, Neil Horman wrote:
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -323,6 +324,68 @@ static int proc_oom_score(struct task_struct *task,
char *buffer)
return sprintf(buffer, %lu
Neil
Signed-off-by: Neil Horman [EMAIL PROTECTED]
base.c | 69 +
1 file changed, 69 insertions(+)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index ed2b224..4fb34a5 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -74,6 +74,7
On Fri, Aug 17, 2007 at 04:09:26AM -0400, [EMAIL PROTECTED] wrote:
On Thu, 16 Aug 2007 08:35:38 EDT, Neil Horman said:
Hey again-
Andrew requested that I repost this cleanly, after running the patch
through checkpatch. As requested here it is with the changelog.
Currently
);
}
if (waitpid(kid, rval, 0) != kid) {
perror(waitpid);
}
}
return 0;
}
--
/***
*Neil Horman
*Software Engineer
*Red Hat, Inc.
[EMAIL PROTECTED]
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
On Fri, Aug 17, 2007 at 12:45:47PM -0700, Andrew Morton wrote:
On Fri, 17 Aug 2007 06:59:18 -0400
Neil Horman [EMAIL PROTECTED] wrote:
Currently, there exists no method for a process to query the resource
limits of another process. They can be inferred via some mechanisms
On Sat, Aug 18, 2007 at 02:22:28AM +0400, Oleg Nesterov wrote:
Neil Horman wrote:
+static int proc_pid_limits(struct task_struct *task, char *buffer)
+{
+ unsigned int i;
+ int count = 0;
+ char *bufptr = buffer;
+
+ struct rlimit rlim[RLIM_NLIMITS];
+
+ read_lock
determined. Given that this information can be
usefull to know during the debugging of an application, I've written this
patch which exports all of a processes limits via /proc/pid/limits.
Regards
Neil
Signed-off-by: Neil Horman [EMAIL PROTECTED]
base.c | 77
.
Signed-off-by: Neil Horman [EMAIL PROTECTED]
base.c | 77 +
1 file changed, 77 insertions(+)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index ed2b224..86130b0 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -74,6 +74,7
this
patch which exports all of a processes limits via /proc/pid/limits.
Signed-off-by: Neil Horman [EMAIL PROTECTED]
base.c | 75 +
1 file changed, 75 insertions(+)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index ed2b224
On Sat, Jul 28, 2007 at 11:23:55AM +0200, Martin Pitt wrote:
Hi Neil,
thanks a lot for your work on this!
Neil Horman [2007-07-27 16:08 -0400]:
Hey
Patch 2/3 of my core_pattern enhancements. This patch is a rewrite of
my previous post for this enhancement. It uses jeremy's
On Sat, Jul 28, 2007 at 06:17:25PM +0200, Martin Pitt wrote:
Hi Neil,
Neil Horman [2007-07-28 9:46 -0400]:
I just want to mention a potential problem with this: If you first
expand the macros (from pattern to corename) and then split
corename into an argv, then this breaks macro
On Sat, Jul 28, 2007 at 03:52:02PM -0700, Jeremy Fitzhardinge wrote:
Neil Horman wrote:
Jeremy asked that I make a patch next week to address split_argv's
requirement
that the argc parameter be non-NULL. I'll be fixing that next week, and
what I
can do is further enhance
On Sun, Jul 29, 2007 at 06:40:43PM +0800, Eugene Teo wrote:
Neil Horman wrote:
Ok, here we go
As promised, I'm reposting the core_pattern enhancements I've done over the
past
few days. These three patches replace and conintue the work contained in
the
following patches, and can
On Sun, Jul 29, 2007 at 02:23:10PM +0530, Aneesh Kumar K.V wrote:
Neil Horman wrote:
On Sat, Jul 28, 2007 at 06:17:25PM +0200, Martin Pitt wrote:
Hi Neil,
Neil Horman [2007-07-28 9:46 -0400]:
I just want to mention a potential problem with this: If you first
expand the macros (from
On Sun, Jul 29, 2007 at 11:34:18AM +0200, Martin Pitt wrote:
Hi Neil,
Neil Horman [2007-07-28 13:21 -0400]:
Jeremy asked that I make a patch next week to address split_argv's
requirement
that the argc parameter be non-NULL. I'll be fixing that next week, and
what I
can do
On Sun, Jul 29, 2007 at 09:03:29PM +0800, Eugene Teo wrote:
Neil Horman wrote:
[...]
+ /* core limit size */
+ case 'c':
+ rc = snprintf(out_ptr, out_end - out_ptr,
+ %lu,
current
--
/***
*Neil Horman
*Software Engineer
*Red Hat, Inc.
[EMAIL PROTECTED]
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED
accomplishes
that. Tested by me, with successful results.
Thanks Regards
Neil
Signed-off-by: Neil Horman [EMAIL PROTECTED]
argv_split.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/lib/argv_split.c b/lib/argv_split.c
index 4096ed4..fad6ce4 100644
--- a/lib
On Tue, Jul 31, 2007 at 09:56:35AM -0700, Jeremy Fitzhardinge wrote:
Neil Horman wrote:
As Jeremy and I had discussed in a previous thread, it would be nice if the
argv_split library function could gracefully handle a NULL pointer in the
argcp
parameter, so as to allow functions using
1 - 100 of 1155 matches
Mail list logo
