On Tuesday 26 February 2008 06:10:34 Jiri Kosina wrote:
> On Mon, 25 Feb 2008, Jan Kara wrote:
> > Yes, exactly two of them. One is non-trivial to get rid of - it's
> > used for encoding of filename before we write it,
>
> Why can't we do just
>
>
>
> UDF: Optimize stack usage
>
>
On Tue 26-02-08 12:37:17, Jiri Kosina wrote:
> On Tue, 26 Feb 2008, Ingo Molnar wrote:
>
> > > + name = kmalloc(sizeof(char) * UDF_NAME_LEN, GFP_KERNEL);
> > > + fname = kmalloc(sizeof(char) * UDF_NAME_LEN, GFP_KERNEL);
> > > +
> > > + if (!name || !fname) {
> > > + *err = -ENOMEM;
> > >
On Tue, 26 Feb 2008, Ingo Molnar wrote:
> > + name = kmalloc(sizeof(char) * UDF_NAME_LEN, GFP_KERNEL);
> > + fname = kmalloc(sizeof(char) * UDF_NAME_LEN, GFP_KERNEL);
> > +
> > + if (!name || !fname) {
> > + *err = -ENOMEM;
> > + return NULL;
> > + }
> > +
> > if
* Jiri Kosina <[EMAIL PROTECTED]> wrote:
> + name = kmalloc(sizeof(char) * UDF_NAME_LEN, GFP_KERNEL);
> + fname = kmalloc(sizeof(char) * UDF_NAME_LEN, GFP_KERNEL);
> +
> + if (!name || !fname) {
> + *err = -ENOMEM;
> + return NULL;
> + }
> +
> if
On Mon, 25 Feb 2008, Jan Kara wrote:
> Yes, exactly two of them. One is non-trivial to get rid of - it's
> used for encoding of filename before we write it,
Why can't we do just
UDF: Optimize stack usage
Signed-off-by: Jiri Kosina <[EMAIL PROTECTED]>
diff --git a/fs/udf/namei.c
On Mon, 25 Feb 2008, Jan Kara wrote:
Yes, exactly two of them. One is non-trivial to get rid of - it's
used for encoding of filename before we write it,
Why can't we do just
UDF: Optimize stack usage
Signed-off-by: Jiri Kosina [EMAIL PROTECTED]
diff --git a/fs/udf/namei.c
* Jiri Kosina [EMAIL PROTECTED] wrote:
+ name = kmalloc(sizeof(char) * UDF_NAME_LEN, GFP_KERNEL);
+ fname = kmalloc(sizeof(char) * UDF_NAME_LEN, GFP_KERNEL);
+
+ if (!name || !fname) {
+ *err = -ENOMEM;
+ return NULL;
+ }
+
if (dentry) {
On Tue, 26 Feb 2008, Ingo Molnar wrote:
+ name = kmalloc(sizeof(char) * UDF_NAME_LEN, GFP_KERNEL);
+ fname = kmalloc(sizeof(char) * UDF_NAME_LEN, GFP_KERNEL);
+
+ if (!name || !fname) {
+ *err = -ENOMEM;
+ return NULL;
+ }
+
if (dentry) {
On Tue 26-02-08 12:37:17, Jiri Kosina wrote:
On Tue, 26 Feb 2008, Ingo Molnar wrote:
+ name = kmalloc(sizeof(char) * UDF_NAME_LEN, GFP_KERNEL);
+ fname = kmalloc(sizeof(char) * UDF_NAME_LEN, GFP_KERNEL);
+
+ if (!name || !fname) {
+ *err = -ENOMEM;
+ return
On Tuesday 26 February 2008 06:10:34 Jiri Kosina wrote:
On Mon, 25 Feb 2008, Jan Kara wrote:
Yes, exactly two of them. One is non-trivial to get rid of - it's
used for encoding of filename before we write it,
Why can't we do just
UDF: Optimize stack usage
Signed-off-by: Jiri Kosina
On Mon, 25 Feb 2008 23:48:07 +0100 Jan Kara <[EMAIL PROTECTED]> wrote:
> > udf_process_sequence() seems to be another victim of gcc inlining.
> Hmm, I'll have a look what we can do.
noinline...
> > udf_add_entry() defines a couple of 256-byte local arrays.
> Yes, exactly two of them. One is
> On Sun, 24 Feb 2008 17:02:26 + Nix <[EMAIL PROTECTED]> wrote:
>
> > On 24 Feb 2008, Peter Osterlund told this:
> >
> > > Nix <[EMAIL PROTECTED]> writes:
> > >> But while I'd normally blame pktcdvd there's only one pktcdvd function
> > >> in these tracebacks (pkt_open) and it's not got a
On Sun, 24 Feb 2008 17:02:26 + Nix <[EMAIL PROTECTED]> wrote:
> On 24 Feb 2008, Peter Osterlund told this:
>
> > Nix <[EMAIL PROTECTED]> writes:
> >> But while I'd normally blame pktcdvd there's only one pktcdvd function
> >> in these tracebacks (pkt_open) and it's not got a significant
On Sun, 24 Feb 2008 17:56:09 +0100 Peter Osterlund <[EMAIL PROTECTED]> wrote:
>
> drivers/block/pktcdvd.c | 16
> 1 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
> index 674cd66..f2510e7 100644
> ---
On Sun, 24 Feb 2008 17:02:26 + Nix [EMAIL PROTECTED] wrote:
On 24 Feb 2008, Peter Osterlund told this:
Nix [EMAIL PROTECTED] writes:
But while I'd normally blame pktcdvd there's only one pktcdvd function
in these tracebacks (pkt_open) and it's not got a significant stack
footprint.
On Sun, 24 Feb 2008 17:56:09 +0100 Peter Osterlund [EMAIL PROTECTED] wrote:
drivers/block/pktcdvd.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
index 674cd66..f2510e7 100644
---
On Sun, 24 Feb 2008 17:02:26 + Nix [EMAIL PROTECTED] wrote:
On 24 Feb 2008, Peter Osterlund told this:
Nix [EMAIL PROTECTED] writes:
But while I'd normally blame pktcdvd there's only one pktcdvd function
in these tracebacks (pkt_open) and it's not got a significant stack
On Mon, 25 Feb 2008 23:48:07 +0100 Jan Kara [EMAIL PROTECTED] wrote:
udf_process_sequence() seems to be another victim of gcc inlining.
Hmm, I'll have a look what we can do.
noinline...
udf_add_entry() defines a couple of 256-byte local arrays.
Yes, exactly two of them. One is
Nix <[EMAIL PROTECTED]> writes:
> On 24 Feb 2008, [EMAIL PROTECTED] outgrape:
>
>> A loop mount/umounting a pcdrw or iso9660 (through the pktcdvd device)
>> sees a stack overflow in four or five tries. Doing the same thing with
>> the same CD in a normal non-pktcdvd-mounted drive doesn't cause a
On 24 Feb 2008, Peter Osterlund told this:
> Nix <[EMAIL PROTECTED]> writes:
>> But while I'd normally blame pktcdvd there's only one pktcdvd function
>> in these tracebacks (pkt_open) and it's not got a significant stack
>> footprint.
>
> Did you verify that with "make checkstack" or just by
On 24 Feb 2008, [EMAIL PROTECTED] outgrape:
> A loop mount/umounting a pcdrw or iso9660 (through the pktcdvd device)
> sees a stack overflow in four or five tries. Doing the same thing with
> the same CD in a normal non-pktcdvd-mounted drive doesn't cause a crash.
> (This may or may not be
On 24 Feb 2008, [EMAIL PROTECTED] outgrape:
A loop mount/umounting a pcdrw or iso9660 (through the pktcdvd device)
sees a stack overflow in four or five tries. Doing the same thing with
the same CD in a normal non-pktcdvd-mounted drive doesn't cause a crash.
(This may or may not be
On 24 Feb 2008, Peter Osterlund told this:
Nix [EMAIL PROTECTED] writes:
But while I'd normally blame pktcdvd there's only one pktcdvd function
in these tracebacks (pkt_open) and it's not got a significant stack
footprint.
Did you verify that with make checkstack or just by looking at the
Nix [EMAIL PROTECTED] writes:
On 24 Feb 2008, [EMAIL PROTECTED] outgrape:
A loop mount/umounting a pcdrw or iso9660 (through the pktcdvd device)
sees a stack overflow in four or five tries. Doing the same thing with
the same CD in a normal non-pktcdvd-mounted drive doesn't cause a crash.
24 matches
Mail list logo
