Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp949830ybl; Fri, 13 Dec 2019 07:09:35 -0800 (PST) X-Google-Smtp-Source: APXvYqwSEzwKjBPNBAk1nhWzF+26+cQfjXUk0ko7ruurUO+3Y4s3K+w8Oy4DGgdhaUvNDn3BEjDU X-Received: by 2002:aca:1e0e:: with SMTP id m14mr2496164oic.114.1576249775144; Fri, 13 Dec 2019 07:09:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576249775; cv=none; d=google.com; s=arc-20160816; b=bqdN8jHNyICZKqjkSFouLvYXTWsz2WO3KpXoT6GNv1w1OWhHYjJgfXnoTf2ZCHJHUB 7WKEU4ffXtAhThIdazQ/OYXH+Otl/vkMdrZmYp7RWq0GZQh6feGoCTpyNDA3UzDIdBqJ WjQ6UlvzLzr4L5wnKiMbROr0ql4ebixvExcsMTrcspdOqg+AbXYlVLszNKs3T8KesJ4D EH1YZxfznOaixEu70p4I0yDcOrjn3GgvTQduqiD7adm5X1Zr9x50Ew22kb7ByzXyDAuO 7BwMFhtp6iLjWBEJJ7QB+TehFO/3lNtSEr4BiWI2Lri5e4XiXFAHPCrKcR1KI+APEVzD rh+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=qzQZ3N2j42xvmhFm5+KhTHXsKU24BeZfSahus3BqSgE=; b=f7yy7rAAG2DEJBH4WLw2u1rIj1aYicAh9N+SxO5k/WO2vFakmXZEVgy9Q4SB8LhSqh fREpWZiktM+aNnUnIfVxGYyHrCOrxQwOGN9FBdZ7XmUx0yStemEt/KhGw/sip6emuekP YIP7LLLw/tEmqROqhEONPN1ZN1/EAbX8wxnrD+w/a+Q7chFh5kK7rrNvGuGHqHiWH6W3 /Q5yHnXAywTt2aoj/fiVMaNlq2mARpoIGLqo8cEz8zuuOZr8yFAflr8H2PaHdUs4Kf6E XqjWE7IofkGn0sOJvjL0n4um9fKxAsbYwPUgUkKmHiMfQladEPIWgjdD6Ilojf7YecB+ qUrg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z203si5100405oia.124.2019.12.13.07.09.17; Fri, 13 Dec 2019 07:09:35 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727667AbfLMPIc (ORCPT + 99 others); Fri, 13 Dec 2019 10:08:32 -0500 Received: from mout.kundenserver.de ([212.227.17.24]:35433 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727534AbfLMPIb (ORCPT ); Fri, 13 Dec 2019 10:08:31 -0500 Received: from mail-qv1-f50.google.com ([209.85.219.50]) by mrelayeu.kundenserver.de (mreue108 [212.227.15.145]) with ESMTPSA (Nemesis) id 1Mi2Fj-1i1myS0lv7-00e57m; Fri, 13 Dec 2019 16:08:29 +0100 Received: by mail-qv1-f50.google.com with SMTP id o18so953554qvf.1; Fri, 13 Dec 2019 07:08:28 -0800 (PST) X-Gm-Message-State: APjAAAXOxvg1WYd+/T/9EpmusdILm9OpW5nLt9b4oO/byJHB/Udd9bUu vvUFfwxfwojJBJGgRN6gpzyRXUiiqql25+iS2L8= X-Received: by 2002:a0c:aca2:: with SMTP id m31mr14072871qvc.222.1576249707957; Fri, 13 Dec 2019 07:08:27 -0800 (PST) MIME-Version: 1.0 References: <20191126161824.337724-1-arnd@arndb.de> <20191126161824.337724-7-arnd@arndb.de> <09c664fd-87fb-4fac-f104-9afbe7d33aa2@xs4all.nl> In-Reply-To: <09c664fd-87fb-4fac-f104-9afbe7d33aa2@xs4all.nl> From: Arnd Bergmann Date: Fri, 13 Dec 2019 16:08:11 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v5 6/8] media: v4l2-core: fix v4l2_buffer handling for time64 ABI To: Hans Verkuil Cc: Linux Media Mailing List , Mauro Carvalho Chehab , y2038 Mailman List , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:bcTVUHr5D9sBj8v+27Fb5K1qnoKmWUl3vCPuMnw3eva4GA3xlW3 xPztPSIh2UASPIwXxPAqWlWgptqoJk+idTDkFQsk12ksIJafKMZnpT/jq2/HX2JLoa+TtRO JT2ydFg2UEJaFlpTqPWLLpYkl/F/3eafQLGA0skX5TRLSsGsrqHXcI/2hPT19dclY1Upo8S VENI0ffJQ15gBSbHWQZAg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:mLdzpUq+mH8=:CBEaYGGaySZCGcc3a0GMC3 9nMTSieRNUFonNXkPyT62XTTfz6sQ3XjjLcZQxOR30FE3XwWLLZabv8P4ODHXcGhxI5GkoYW5 CKVUjb1WUQWvxlnT8p805Sg2WdxWWPxpjbDLstCdgeshRZFwI630jJGFQD/a55gtvWWriP4ha xt+kNoFN4OfNeHZQHdoyURzTgllYGQ/k7GSU0vQ9/u4eL+j/wXELAEjTAXHbO+2gT7XqvDXdY ayjW25pY+dp6jB0Z2+6T5cjTq5glJomBvpmt+wqTMDcQ4gEhb2i4OabU8Ffy2a6kW0B12Cpvm AEmO3Cqii6DnEV2YbYa87ud4NxrTi8sORQd12n2bicIRyEOlDPzGk4yXZWvdkUGVnRzoJmBug z0vzlKVqcixhTAgIP8PbJG9fCloNKqWBJF+76r2H1rNPFu5kLO7JuB7vTOu4gIDl7Xhxst5Fa gmZG1ROGW7FCGRN9fyd+iktB1lEbtIDsqpbd63U4dLBF+3oQdpmGUFJ9DGgM/SzeOMGdHEXT+ X56+pUzMnFlBXSAlepCmb8MSeAS4BP0gPultIXFJqwjw+K5Be6c3sJ34Rkv+gHpiBZdTYq+kY GsRluB60Ey1pgCQfZ/Tu5EeLY2+EW888FXpKEZpSmltWfZ67nJqq5r0B+7Q2sw2k59681pPMt uWNNRzyTcqdYu3CyQPnusgCnrmm1Pjx5GpBdKooMI+EXmYJE9XCS3xvTv+KkeuSM+V+O3sr7J 0uUrW+tR52ArSxlS+0h8FBRWRmyEzKnJptba7viTLkGFxLOxBOph9L9x/z1s4OqfrjUPK9gCl tOGv86SqyKDBcYux2L/wuiYV67UEWgEzn+f4JI0YHabCiiW6MxdNRkmAAPvYauwyAY/x2nG6S 7Li3GWLkfg/kgpKXy8xw== Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Dec 12, 2019 at 4:43 PM Hans Verkuil wrote: > > On 11/26/19 5:18 PM, Arnd Bergmann wrote: > > > > switch (cmd) { > > +#ifdef COMPAT_32BIT_TIME > > COMPAT_32BIT_TIME -> CONFIG_COMPAT_32BIT_TIME Fixed. > > + *vb = (struct v4l2_buffer) { > > + .index = vb32.index, > > + .type = vb32.type, > > + .bytesused = vb32.bytesused, > > + .flags = vb32.flags, > > + .field = vb32.field, > > + .timestamp.tv_sec = vb32.timestamp.tv_sec, > > + .timestamp.tv_usec = vb32.timestamp.tv_usec, > > + .timecode = vb32.timecode, > > You forgot to copy sequence. > > > + .memory = vb32.memory, > > + .m.userptr = vb32.m.usercopy, > > usercopy -> userptr Fixed. > > + .length = vb32.length, > > + .request_fd = vb32.request_fd, > > + }; > > + > > + if (cmd == VIDIOC_QUERYBUF_TIME32) > > + memset(&vb->length, 0, sizeof(*vb) - > > + offsetof(struct v4l2_buffer, length)); > > It's from the field AFTER vb->length that this needs to be zeroed. It's best to > use the CLEAR_AFTER_FIELD macro here. I'm a bit lost about this one: the fields that are not explicitly uninitialized here are already set to zero by the assignment above. Should this simply be a if (cmd == VIDIOC_QUERYBUF_TIME32) vb->request_fd = 0; then? I don't remember where that memset() originally came from or why request_fd has to be cleared here. > > @@ -3100,6 +3141,30 @@ static int video_put_user(void __user *arg, void *parg, unsigned int cmd) > > return -EFAULT; > > break; > > } > > + case VIDIOC_QUERYBUF_TIME32: > > + case VIDIOC_QBUF_TIME32: > > + case VIDIOC_DQBUF_TIME32: > > + case VIDIOC_PREPARE_BUF_TIME32: { > > + struct v4l2_buffer *vb = parg; > > + struct v4l2_buffer_time32 vb32 = { > > + .index = vb->index, > > + .type = vb->type, > > + .bytesused = vb->bytesused, > > + .flags = vb->flags, > > + .field = vb->field, > > + .timestamp.tv_sec = vb->timestamp.tv_sec, > > + .timestamp.tv_usec = vb->timestamp.tv_usec, > > + .timecode = vb->timecode, > > You forgot to copy sequence. Fixed. > With these changes this patch series passed both the 64 and 32 bit compliance > tests (in fact, all the issues mentioned above were found with these compliance > tests). Yay compliance tests! > I am unable to test with musl since v4l2-ctl and v4l2-compliance are C++ programs, > and there doesn't appear to be an easy way to compile a C++ program with musl. > > If you happen to have a test environment where you can compile C++ with musl, > then let me know and I can give instructions on how to run the compliance tests. > > If you can't test that, then I can merge this regardless, and hope for the best > once the Y2038 fixes end up in glibc. But ideally I'd like to have this tested. I've heard good things about the prebuilt toolchains from http://musl.cc/. These seems to come with a libstdc++, but I have not tried that myself. I've folded the change below into this patch in my y2038-v4l2-v6 branch but have not been able to update the copy on git.kernel.org yet because of server-side issues today. Arnd 8<----- diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v4l2-ioctl.c index c416870a3166..667225712343 100644 --- a/drivers/media/v4l2-core/v4l2-ioctl.c +++ b/drivers/media/v4l2-core/v4l2-ioctl.c @@ -3055,7 +3055,7 @@ static int video_get_user(void __user *arg, void *parg, unsigned int cmd, } switch (cmd) { -#ifdef COMPAT_32BIT_TIME +#ifdef CONFIG_COMPAT_32BIT_TIME case VIDIOC_QUERYBUF_TIME32: case VIDIOC_QBUF_TIME32: case VIDIOC_DQBUF_TIME32: @@ -3075,15 +3075,15 @@ static int video_get_user(void __user *arg, void *parg, unsigned int cmd, .timestamp.tv_sec = vb32.timestamp.tv_sec, .timestamp.tv_usec = vb32.timestamp.tv_usec, .timecode = vb32.timecode, + .sequence = vb32.sequence, .memory = vb32.memory, - .m.userptr = vb32.m.usercopy, + .m.userptr = vb32.m.userptr, .length = vb32.length, .request_fd = vb32.request_fd, }; if (cmd == VIDIOC_QUERYBUF_TIME32) - memset(&vb->length, 0, sizeof(*vb) - - offsetof(struct v4l2_buffer, length)); + vb->request_fd = 0; break; } @@ -3155,6 +3155,7 @@ static int video_put_user(void __user *arg, void *parg, unsigned int cmd) .timestamp.tv_sec = vb->timestamp.tv_sec, .timestamp.tv_usec = vb->timestamp.tv_usec, .timecode = vb->timecode, + .sequence = vb->sequence, .memory = vb->memory, .m.userptr = vb->m.userptr, .length = vb->length,