[linux-cifs-client] [PATCH] cifs: Fix insufficient memory allocation for nativeFileSystem field

[Jeff Layton]

On Mon, 06 Apr 2009 22:33:09 +0530
Suresh Jayaraman <sjayaraman at suse.de> wrote:

> Steve French wrote:
> > I don't think that we should be using these size assumptions
> > (multiples of UCS stringlen).    A new UCS helper function should be
> > created that calculates how much memory would be needed for a
> > converted string - and we need to use this before we do the malloc and
> > string conversion.  In effect a strlen and strnlen function that takes
> > a target code page argument.  For strings that will never be more than
> > a hundred bytes this may not be needed, and we can use the length
> > assumption, but since mallocs in kernel can be so expensive I would
> > rather calculate the actual string length needed for the target.
> 
> Ah, ok. I thought of writing a little function based on
> cifs_strncpy_to_host() and adding a comment like below:
> 
> /* UniStrnlen() returns length in 16 bit Unicode  characters
>  * (UCS-2) with base length of 2 bytes per character. An UTF-8
>  * character can be up to 8 bytes maximum, so we need to
>  * allocate (len/2) * 4 bytes (or) (4 * len) bytes for the
>  * UTF-8 string */
> 
> and make the callers use this. May be Steve's idea is a better one.
> However, I could find any utility function inside kernel source that
> calculates length of a UTF-8 string. It's not clear how can I find the
> length of a UTF-8 string.
> 
> Thanks,
> 

I think you'll have to basically do the conversion twice. Walk the
string once and convert each character determine its length and then
discard it. Get the total and allocate that many bytes (plus the null
termination), and do the conversion again into the buffer.

Another option might be to have a static buffer already allocated
somewhere (maybe even a whole page?) and do the conversion into that
while keeping a count of bytes. Then memcpy it into the destination
buffer after you allocate it.

I'm not truly convinced this is really necessary though. You have to
figure that kmalloc is a power-of-two allocator. If you kmalloc 17
bytes, you get 32 anyway. You'll probably end up using roughly the same
amount of memory that you would have had you just estimated the size.

-- 
Jeff Layton <jlayton at redhat.com>