On 4/11/24 5:40 AM, Marek Szyprowski wrote:
> Hi,
>
> On 11.04.2024 00:27, Jens Axboe wrote:
>> On 4/9/24 9:22 AM, Jens Axboe wrote:
>>> @@ -312,8 +313,8 @@ static ssize_t timerfd_read(struct file *file, char __user *buf, size_t count,
>>> ctx->ticks = 0;
>>> }
>>> spin_unlock_irq(&ctx->wqh.lock);
>>> - if (ticks)
>>> - res = put_user(ticks, (u64 __user *) buf) ? -EFAULT: sizeof(ticks);
>>> + if (ticks && !copy_to_iter_full(&ticks, sizeof(ticks), to))
>>> + res = -EFAULT;
>>> return res;
>>> }
>> Dumb thinko here, as that should be:
>>
>> if (ticks) {
>> res = copy_to_iter(&ticks, sizeof(ticks), to);
>> if (!res)
>> res = -EFAULT;
>> }
>>
>> I've updated my branch, just a heads-up. Odd how it passing testing,
>> guess I got stack lucky...
>
> The old version got its way into today's linux-next and bisecting the
> boot issues directed me here. There is nothing more to report, but I can
> confirm that the above change indeed fixes the problems observed on
> next-20240411.
Yeah sorry about that :(
> Tested-by: Marek Szyprowski <m.szyprowski@xxxxxxxxxxx>
Thanks!
> I hope that tomorrow's linux-next will have the correct version of this
> patch.
It should, the branches have been updated.
--
Jens Axboe
