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:
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 (d
* 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 (den
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 b/fs/udf/
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 sig
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 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
> --- a/driver
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 c
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 look
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 PREEMP
12 matches
Mail list logo