public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Prarit Bhargava <prarit@redhat.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: linux-kernel@vger.kernel.org, stable@kernel.org,
	phillip@lougher.demon.co.uk, alain@knaff.lu, hpa@zytor.com
Subject: Re: [PATCH]: bunzip2: Fix warning in get_next_block()
Date: Sat, 22 May 2010 14:07:32 -0400	[thread overview]
Message-ID: <4BF81D64.8000700@redhat.com> (raw)
In-Reply-To: <20100522140741.GM31073@ZenIV.linux.org.uk>



On 05/22/2010 10:07 AM, Al Viro wrote:
> On Sat, May 22, 2010 at 10:04:07AM -0400, Prarit Bhargava wrote:
>    
>> Fix checkstack compile warning in get_next_block():
>>
>> lib/decompress_bunzip2.c: In function `get_next_block':
>> lib/decompress_bunzip2.c:511: warning: the frame size of 1920 bytes is larger than 1024 bytes
>>      
>
>    
>>   	int dbufCount, nextSym, dbufSize, groupCount, selector,
>> -		i, j, k, t, runPos, symCount, symTotal, nSelectors,
>> -		byteCount[256];
>> -	unsigned char uc, symToByte[256], mtfSymbol[256], *selectors;
>> +		i, j, k, t, runPos, symCount, symTotal, nSelectors;
>> +	static int byteCount[256];
>> +	unsigned char uc, *selectors;
>> +	static unsigned char symToByte[256], mtfSymbol[256];
>>   	unsigned int *dbuf, origPtr;
>>      
> Um...  Some details might be useful, starting with "why can't that function
> be called from several processes at once"...
>    

Al, to be honest, I'm not 100% if this is single-threaded or not :/.  I 
was hoping that by throwing the patch out I would get either an ACK or a 
NAK on it because of the single threaded issue.  It seems to me (and I 
admit I might be totally wrong) that the bunzip2 function is only called 
during early boot,

#ifdef PREBOOT
STATIC int INIT decompress(unsigned char *buf, int len,
                         int(*fill)(void*, unsigned int),
                         int(*flush)(void*, unsigned int),
                         unsigned char *outbuf,
                         int *pos,
                         void(*error_fn)(char *x))
{
         return bunzip2(buf, len - 4, fill, flush, outbuf, pos, error_fn);
}
#endif

... which (again, if the assumptions I'm making are correct) means that 
only one cpu will be active.

/me hopes someone will correct him if he's wrong and that's why hpa and 
phillip are cc'd directly

If it isn't single threaded, then you're right -- a PREBOOT malloc is 
the way to go.

P.

      reply	other threads:[~2010-05-22 18:12 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-22 14:04 [PATCH]: bunzip2: Fix warning in get_next_block() Prarit Bhargava
2010-05-22 14:07 ` Al Viro
2010-05-22 18:07   ` Prarit Bhargava [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BF81D64.8000700@redhat.com \
    --to=prarit@redhat.com \
    --cc=alain@knaff.lu \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=phillip@lougher.demon.co.uk \
    --cc=stable@kernel.org \
    --cc=viro@ZenIV.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox