Re: [PATCH 4/9] staging/lustre: clean up and remove libcfs/linux/linux-fs.c

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jun 4, 2013 at 4:32 PM, Dan Carpenter <dan.carpenter@xxxxxxxxxx> wrote:
> On Mon, Jun 03, 2013 at 09:58:17PM +0800, Peng Tao wrote:
>>  int libcfs_kkuc_msg_put(struct file *filp, void *payload)
>>  {
>>       struct kuc_hdr *kuch = (struct kuc_hdr *)payload;
>> +     ssize_t count = kuch->kuc_msglen;
>> +     loff_t offset = 0;
>> +     mm_segment_t fs;
>>       int rc = -ENOSYS;
>>
>>       if (filp == NULL || IS_ERR(filp))
>> @@ -165,11 +168,18 @@ int libcfs_kkuc_msg_put(struct file *filp, void *payload)
>>               return -ENOSYS;
>>       }
>>
>> -     {
>> -             loff_t offset = 0;
>> -             rc = filp_user_write(filp, payload, kuch->kuc_msglen,
>> -                                  &offset);
>> +     fs = get_fs();
>> +     set_fs(KERNEL_DS);
>> +     while ((ssize_t)count > 0) {
>> +             rc = vfs_write(filp, (const void __user *)payload,
>> +                            count, &offset);
>> +             if (rc < 0)
>> +                     break;
>> +             count -= rc;
>> +             payload += rc;
>> +             rc = 0;
>>       }
>> +     set_fs(fs);
>>
>>       if (rc < 0)
>>               CWARN("message send failed (%d)\n", rc);
>
> This was all there in the original code, it has just been shifted.
> Still, I had some questions about it.  "payload" is a pointer to
> kernel stack memory, wouldn't the access_ok() check in vfs_write()
> fail every time on x86?
>
Thanks for reviewing. I am not familiar with access_ok() but I think
you are right and I'll test to see if it really breaks. In the
meantime, I took a look at other kernel callers of vfs_write() and
btrfs is also calling vfs_write() to write kernel stack memory
(fs/btrfs/send.c: send_header->write_buf->vfs_write). So I CC'ed btrfs
list in case someone knows better than I do.

> Some of the casting is not needed.  No need to cast "count" because
> it is already ssize_t.  I haven't tested but I think Sparse will
> complain about the __user cast until __force is added.  No need for
> the cast to const.
>
Thanks. I will fix it.

> I worry about partial writes and that this could be a forever loop
> but I don't know enough about anything to say if that's possible.
> Probably not.
>
For partial writes, both payload and count are advanced properly. So
it won't loop forever.

Thanks,
Tao
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel




[Index of Archives]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux