linux-kernel - Re: [RFC PATCH 4/7] sound: core: Avoid using timespec for struct snd_rawmidi

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 22 Sep 2017 09:54:39 +0800
From:   Baolin Wang <baolin.wang@...aro.org>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
        Liam Girdwood <lgirdwood@...il.com>,
        Ingo Molnar <mingo@...nel.org>,
        Takashi Sakamoto <o-takashi@...amocchi.jp>,
        SF Markus Elfring <elfring@...rs.sourceforge.net>,
        Dan Carpenter <dan.carpenter@...cle.com>, jeeja.kp@...el.com,
        Vinod Koul <vinod.koul@...el.com>, dharageswari.r@...el.com,
        guneshwor.o.singh@...el.com, Bhumika Goyal <bhumirks@...il.com>,
        gudishax.kranthikumar@...el.com, Naveen M <naveen.m@...el.com>,
        hardik.t.shah@...el.com, Arvind Yadav <arvind.yadav.cs@...il.com>,
        Fabian Frederick <fabf@...net.be>,
        Mark Brown <broonie@...nel.org>,
        Deepa Dinamani <deepa.kernel@...il.com>,
        alsa-devel@...a-project.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 4/7] sound: core: Avoid using timespec for struct snd_rawmidi_status

Hi Arnd,

On 21 September 2017 at 20:56, Arnd Bergmann <arnd@...db.de> wrote:
> On Thu, Sep 21, 2017 at 8:18 AM, Baolin Wang <baolin.wang@...aro.org> wrote:
>
>> -       case SNDRV_RAWMIDI_IOCTL_STATUS:
>> +#if __BITS_PER_LONG == 32
>> +       case SNDRV_RAWMIDI_IOCTL_STATUS32:
>> +       {
>> +               int err = 0;
>> +               struct snd_rawmidi_status32 __user *status = argp;
>> +               struct snd_rawmidi_status32 status32;
>> +               struct snd_rawmidi_status64 status64;
>> +
>> +               if (copy_from_user(&status32, argp,
>> +                                  sizeof(struct snd_rawmidi_status32)))
>> +                       return -EFAULT;
>> +               switch (status32.stream) {
>> +               case SNDRV_RAWMIDI_STREAM_OUTPUT:
>> +                       if (rfile->output == NULL)
>> +                               return -EINVAL;
>> +                       err = snd_rawmidi_output_status(rfile->output, &status64);
>> +                       break;
>> +               case SNDRV_RAWMIDI_STREAM_INPUT:
>> +                       if (rfile->input == NULL)
>> +                               return -EINVAL;
>> +                       err = snd_rawmidi_input_status(rfile->input, &status64);
>> +                       break;
>> +               default:
>> +                       return -EINVAL;
>> +               }
>> +               if (err < 0)
>> +                       return err;
>> +
>> +               if (put_user(status64.stream, &status->stream) ||
>> +                   put_user(status64.tstamp.tv_sec, &status->tstamp.tv_sec) ||
>> +                   put_user(status64.tstamp.tv_nsec, &status->tstamp.tv_nsec) ||
>> +                   put_user(status64.avail, &status->avail) ||
>> +                   put_user(status64.xruns, &status->xruns))
>> +                       return -EFAULT;
>> +               return 0;
>> +       }
>
> This follows the existing coding style for the other functions, but I think
> it would be nicer to express the last part as
>
>        status32 = (struct snd_rawmidi_status32) {
>                .stream = status->stream,
>                .tstamp.tv_sec, &status->tstamp.tv_sec,
>                .tstamp.tv_nsec, &status->tstamp.tv_nsec,
>                .avail, &status->avail,
>                .xruns, &status->xruns,
>        };
>        if (copy_to_user(status, &status32, sizeof(*status))
>               return -EFAULT;
>        return 0;
>
> It's completely equivalent, I just find my version easier to read, and
> it should produce slightly better object code.
>
> Maybe the maintainers have a preference, or there might be
> a good reason to use the series of put_user() instead.

I just saw there are not many put_user() will be used in this
function, but I agree with you and I like to change as you suggested.

-- 
Baolin.wang
Best Regards