On 2014/12/05, 3:41 PM, "Tristan Lelong" <tristan@xxxxxxxxxx> wrote:
>On Fri, Dec 05, 2014 at 01:27:23PM -0800, Greg KH wrote:
>> On Fri, Dec 05, 2014 at 12:03:47AM -0800, Tristan Lelong wrote:
>> > static ssize_t
>> > -fld_proc_hash_seq_write(struct file *file, const char *buffer,
>> > - size_t count, loff_t *off)
>> > +fld_proc_hash_seq_write(struct file *file,
>> > + const char __user *buffer,
>> > + size_t count, loff_t *off)
>> > {
>> > struct lu_client_fld *fld;
>> > struct lu_fld_hash *hash = NULL;
>> > + char name[80];
>> > int i;
>> >
>> > + if (count > 80)
>> > + return -ENAMETOOLONG;
>> > +
>> > + if (copy_from_user(name, buffer, count) != 0)
>> > + return -EFAULT;
>>
>> How was this code ever working before?
>
>I have no idea, and was actually surprised that this was there.
>
>>
>> And I know Joe asked, but how do you know that 80 is ok? And why on the
>> stack?
>
>80 is the sizeof(struct lu_fld_hash.fh_name) and there is no define for
>that. A few other structure members are using this 80 value internally,
>and as I told Joe, I will analyze if they are all related and submit a
>patch to use a define instead.
Sorry, but I don't see where you get 80 from? fh_name is declared as a
"const char *", and initialized in the declaration of fld_hash[]. I'd
thought to reply that sizeof(fh_name) would even be better than a #define,
but sizeof(const char *) doesn't actually make sense.
The longest declared fh_name is 4 characters, but I'm not sure of an easy
way to determine this at compile time. I guess one option is to change
the declaration of struct lu_fld_hash to use "const char fh_name[4];" and
then use sizeof(fh_name), but I don't know if that is better than just
declaring a small buffer (8 chars) for this usage. IMHO that is small
enough to fit on the stack, since it is at the top of a very short
callchain (userspace->sys_write->vfs_write->fld_proc_hash_seq_write())
that just saves the value so the chance of stack overflow is basically nil.
>>
>> Shouldn't you just compare count to strlen(fld_hash[i].fh_name)? like
>>you
>> do later on?
>>
>
>This is actually done in the for loop already. I first compare with the
>maximum size, then the loop use the strlen of each entries in the table,
>and finally does the strncmp.
>
>>
>> Anyway, I don't like large stack variables like this, can you make it
>> dynamic instead?
>>
>
>I can definitely do this with a kmalloc, I'll submit a v2 tonight.
>
>Thanks
>
Cheers, Andreas
--
Andreas Dilger
Lustre Software Architect
Intel High Performance Data Division
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
