Michael,
Per our previous discussion, here are the updates to the execve(2)
manpage resulting from the variable length argument support patch in
linux-2.6.23-rc1. The execve API is unmodified. However, the
following should be noted in the "Notes" section.
Prior to linux-2.6.23, the memory used
Michael,
Per our previous discussion, here are the updates to the execve(2)
manpage resulting from the variable length argument support patch in
linux-2.6.23-rc1. The execve API is unmodified. However, the
following should be noted in the "Notes" section.
Prior to linux-2.6.23, the memory used
Michael,
Per our previous discussion, here are the updates to the execve(2)
manpage resulting from the variable length argument support patch in
linux-2.6.23-rc1. The execve API is unmodified. However, the
following should be noted in the Notes section.
Prior to linux-2.6.23, the memory used
Michael,
Per our previous discussion, here are the updates to the execve(2)
manpage resulting from the variable length argument support patch in
linux-2.6.23-rc1. The execve API is unmodified. However, the
following should be noted in the Notes section.
Prior to linux-2.6.23, the memory used
On 7/29/07, Mark Fortescue <[EMAIL PROTECTED]> wrote:
> Hi All,
>
> Unfortunatly Sparc32 sun4c low level memory management apears to be
> incompatible with commit b6a2fea39318e43fee84fa7b0b90d68bed92d2ba
> mm: variable length argument support.
I feel like I ought to help out with this since it's
On 7/29/07, Mark Fortescue [EMAIL PROTECTED] wrote:
Hi All,
Unfortunatly Sparc32 sun4c low level memory management apears to be
incompatible with commit b6a2fea39318e43fee84fa7b0b90d68bed92d2ba
mm: variable length argument support.
I feel like I ought to help out with this since it's my
On 6/15/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
On Thu, 2007-06-14 at 13:58 -0700, Ollie Wild wrote:
> A good heuristic, though, might be to limit
> argument size to a percentage (say 25%) of maximum stack size and
> validate this inside copy_strings().
This seems to d
On 6/15/07, Peter Zijlstra [EMAIL PROTECTED] wrote:
On Thu, 2007-06-14 at 13:58 -0700, Ollie Wild wrote:
A good heuristic, though, might be to limit
argument size to a percentage (say 25%) of maximum stack size and
validate this inside copy_strings().
This seems to do:
Looks good
@@ -1385,6 +1401,10 @@ int do_execve(char * filename,
goto out;
bprm->argv_len = env_p - bprm->p;
+ retval = expand_arg_vma(bprm);
+ if (retval < 0)
+ goto out;
+
retval = search_binary_handler(bprm,regs);
if (retval >= 0) {
On 6/13/07, Luck, Tony <[EMAIL PROTECTED]> wrote:
Above 5Mbytes, I started seeing problems. The line/word/char
counts from "wc" started being "0 0 0". Not sure if this is
a problem in "wc" dealing with a single line >5MBytes, or some
other problem (possibly I was exceeding the per-process
On 6/13/07, Luck, Tony [EMAIL PROTECTED] wrote:
Above 5Mbytes, I started seeing problems. The line/word/char
counts from wc started being 0 0 0. Not sure if this is
a problem in wc dealing with a single line 5MBytes, or some
other problem (possibly I was exceeding the per-process stack
limit
@@ -1385,6 +1401,10 @@ int do_execve(char * filename,
goto out;
bprm-argv_len = env_p - bprm-p;
+ retval = expand_arg_vma(bprm);
+ if (retval 0)
+ goto out;
+
retval = search_binary_handler(bprm,regs);
if (retval = 0) {
On 6/6/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
PA-RISC will still need it, right?
Originally, I thought since the PA-RISC stack grows up, we'd want to
place the stack at the bottom of memory and have copy_strings() and
friends work in the opposite direction. It turns out, though, that
On 6/5/07, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
Provide functions for moving page tables upwards.
Now that we're initializing the temporary stack location to
STACK_TOP_MAX, do we still need move_page_tables_up() for variable
length argument support? I originally added it into
On 6/5/07, Peter Zijlstra [EMAIL PROTECTED] wrote:
Provide functions for moving page tables upwards.
Now that we're initializing the temporary stack location to
STACK_TOP_MAX, do we still need move_page_tables_up() for variable
length argument support? I originally added it into
On 6/6/07, Peter Zijlstra [EMAIL PROTECTED] wrote:
PA-RISC will still need it, right?
Originally, I thought since the PA-RISC stack grows up, we'd want to
place the stack at the bottom of memory and have copy_strings() and
friends work in the opposite direction. It turns out, though, that
OK. It sounds like a healthy dose of comments is in order. I'll
clean things up and send out a new patch sometime tonight or tomorrow.
Additional comments inline below:
> - len = strnlen_user((void __user *)p, PAGE_SIZE*MAX_ARG_PAGES);
> - if (!len || len >
OK. It sounds like a healthy dose of comments is in order. I'll
clean things up and send out a new patch sometime tonight or tomorrow.
Additional comments inline below:
- len = strnlen_user((void __user *)p, PAGE_SIZE*MAX_ARG_PAGES);
- if (!len || len
On 5/9/07, Rob Landley <[EMAIL PROTECTED]> wrote:
Just FYI, a really really quick and dirty way of testing this sort of thing on
more architectures and you're likely to physically have?
Does this properly emulate caching? On parisc, cache coherency was
the main issue we ran into. I suspect
On 5/9/07, Rob Landley [EMAIL PROTECTED] wrote:
Just FYI, a really really quick and dirty way of testing this sort of thing on
more architectures and you're likely to physically have?
Does this properly emulate caching? On parisc, cache coherency was
the main issue we ran into. I suspect
On 12/29/06, Ingo Molnar <[EMAIL PROTECTED]> wrote:
what is keeping this fix from going upstream?
There are still a couple outstanding issues which need to be resolved
before this is ready for inclusion in the mainline kernel.
The main one is support for CONFIG_STACK_GROWSUP, which I think
On 12/29/06, Ingo Molnar [EMAIL PROTECTED] wrote:
what is keeping this fix from going upstream?
There are still a couple outstanding issues which need to be resolved
before this is ready for inclusion in the mainline kernel.
The main one is support for CONFIG_STACK_GROWSUP, which I think is
Adrian Bunk wrote:
On Fri, Sep 02, 2005 at 10:26:56AM -0700, Ollie Wild wrote:
It's been about a week since I posted this bug report, and I haven't
gotten any responses. Is there someone I should contact directly? Can
someone please point me in the right direction?
The MAINTAINERS
It's been about a week since I posted this bug report, and I haven't
gotten any responses. Is there someone I should contact directly? Can
someone please point me in the right direction?
Thanks,
Ollie
Ollie Wild wrote:
There's a bug in Hitachi SuperH csum_partial_copy_generic
It's been about a week since I posted this bug report, and I haven't
gotten any responses. Is there someone I should contact directly? Can
someone please point me in the right direction?
Thanks,
Ollie
Ollie Wild wrote:
There's a bug in Hitachi SuperH csum_partial_copy_generic
Adrian Bunk wrote:
On Fri, Sep 02, 2005 at 10:26:56AM -0700, Ollie Wild wrote:
It's been about a week since I posted this bug report, and I haven't
gotten any responses. Is there someone I should contact directly? Can
someone please point me in the right direction?
The MAINTAINERS
There's a bug in Hitachi SuperH csum_partial_copy_generic()
implementation. If the supplied length is 1 (and several alignment
conditions are met), the function immediately branches to label 4.
However, the assembly at label 4 expects the length to be stored in
register r2. Since this has
There's a bug in Hitachi SuperH csum_partial_copy_generic()
implementation. If the supplied length is 1 (and several alignment
conditions are met), the function immediately branches to label 4.
However, the assembly at label 4 expects the length to be stored in
register r2. Since this has
Patrick McHardy wrote:
Checking the return value of ip_append_data seems cleaner to me.
Patch attached.
Works for me.
Thanks,
Ollie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Ollie Wild wrote:
Patrick McHardy wrote:
Your patch doesn't fit your description, the else-condition you're
adding triggers when the queue is empty, so what is the point?
Since we're only calling ip_append_data() once here, the two
conditions are identical.
I should mention
Patrick McHardy wrote:
Ollie Wild wrote:
If the ip_append_data() call in icmp_push_reply() fails,
ip_flush_pending_frames() needs to be called. Otherwise, ip_rt_put()
is never called on inet_sk(icmp_socket->sk)->cork.rt, which prevents
the route (and net_device) from ever being
Patrick McHardy wrote:
Ollie Wild wrote:
If the ip_append_data() call in icmp_push_reply() fails,
ip_flush_pending_frames() needs to be called. Otherwise, ip_rt_put()
is never called on inet_sk(icmp_socket-sk)-cork.rt, which prevents
the route (and net_device) from ever being freed
Ollie Wild wrote:
Patrick McHardy wrote:
Your patch doesn't fit your description, the else-condition you're
adding triggers when the queue is empty, so what is the point?
Since we're only calling ip_append_data() once here, the two
conditions are identical.
I should mention
Patrick McHardy wrote:
Checking the return value of ip_append_data seems cleaner to me.
Patch attached.
Works for me.
Thanks,
Ollie
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
roblem.
Ollie Wild
diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -368,6 +368,8 @@ static void icmp_push_reply(struct icmp_
icmph->checksum = csum_fold(csum);
skb->ip_summed = CHECKSUM_NONE;
ip_push_pending_frames(icmp_socket-&g
.
Ollie Wild
diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -368,6 +368,8 @@ static void icmp_push_reply(struct icmp_
icmph-checksum = csum_fold(csum);
skb-ip_summed = CHECKSUM_NONE;
ip_push_pending_frames(icmp_socket-sk);
+ } else
Hi,
The pfkey_xfrm_state2msg() was missing a return in an EINVAL statement.
This patch resolves the problem.
Please cc my address on any replies, as I am not on the linux kernel
mailing list.
Ollie
Fixes broken error handling in pfkey_xfrm_state2msg().
--- net/key/af_key.c.orig 2005-03-16
Hi,
The pfkey_xfrm_state2msg() was missing a return in an EINVAL statement.
This patch resolves the problem.
Please cc my address on any replies, as I am not on the linux kernel
mailing list.
Ollie
Fixes broken error handling in pfkey_xfrm_state2msg().
--- net/key/af_key.c.orig 2005-03-16
38 matches
Mail list logo
