From patchwork Thu Mar 3 19:12:48 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ricardo Ribalda Delgado X-Patchwork-Id: 8495701 Return-Path: X-Original-To: patchwork-linux-media@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id D1FBD9F8A8 for ; Thu, 3 Mar 2016 19:13:34 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id F204720398 for ; Thu, 3 Mar 2016 19:13:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1C03C20394 for ; Thu, 3 Mar 2016 19:13:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755840AbcCCTM5 (ORCPT ); Thu, 3 Mar 2016 14:12:57 -0500 Received: from mail-lb0-f169.google.com ([209.85.217.169]:34595 "EHLO mail-lb0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754943AbcCCTM4 (ORCPT ); Thu, 3 Mar 2016 14:12:56 -0500 Received: by mail-lb0-f169.google.com with SMTP id cf7so19115182lbb.1; Thu, 03 Mar 2016 11:12:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id; bh=P3e6ZD3hhllX7TZPpT/gkCCJXDnMg0OPhyfg70bkcYw=; b=CqJ6HlR0JdWbAeYPefT/itbfUV0leoXJk8t6KcfdCGnp9E4FUzLmigJA01VsjUVGbH WsJiXEEmS6KQuJ1UfnG+emYbRtHruLZ/e4ZluUN091NBKkSTUAmu3EQAcdsjRAKnAS6/ L8iBLG8GQ8cTmmBOuamPhBD6DbQ2TUH9QQHKq/JYh23KUeTAhvrNrekpK0MWxPfMcqYV KjmjnKkcRhQnSPwdVY7G4mbI0W8hQ/axWR3oZlKbNBDIcbmCiQCUKGF48mNLwK1FMSaH flYLC2DCasHChSCPf6QEB6RQrZrJBMFnEBXXk4AlfS3Pzqv/IO/nkdMOe4T0ywxEoObw 84XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=P3e6ZD3hhllX7TZPpT/gkCCJXDnMg0OPhyfg70bkcYw=; b=R54cKh2Q13xUGnmRswSWhPfbk5Jvxbd/jt/AqR1WeKnstYTWOzv0OZv7lI1YztHzDK +CvclWR6Rjy0SlZTaR3tFCRWRoq2ydp0B52gw25G6X8wb3MIK3gRUkpbRcMDy3pG4B0j rfdGvZFXp78gprMFuXeQdd6FzfukBbDzkPHpRDN+JFPJScXIEVoQQX+BXvVM9EGuQNYi yGgFdFdHCOn5WscJgSo6U4TYtdUJvil/A0XChuU8o6kC/6N5VURyAYCiCFl+sS63cp9K VHMr40GX8GRyW3nWuVCmISlTpelOz9mj8Whed9oXx/4GWv3/tdDuiKXaBULwYmS81Lmv 8++w== X-Gm-Message-State: AD7BkJLBF3Kn3uDWpZjYGTUWv3+nOl4TZKxghZPzXRmiYeIgwHU9Lnp0AVgZSul2axDt/A== X-Received: by 10.25.153.12 with SMTP id b12mr1703489lfe.117.1457032374456; Thu, 03 Mar 2016 11:12:54 -0800 (PST) Received: from localhost.localdomain (x1-6-74-44-01-e3-62-1a.cpe.webspeed.dk. [80.167.115.215]) by smtp.gmail.com with ESMTPSA id x125sm6687706lfd.12.2016.03.03.11.12.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 03 Mar 2016 11:12:52 -0800 (PST) From: Ricardo Ribalda Delgado To: albert@newtec.dk, Jan Kara , Pawel Osciak , Marek Szyprowski , Kyungmin Park , Hans Verkuil , Mauro Carvalho Chehab , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org Cc: Ricardo Ribalda Delgado Subject: [PATCH 1/2] [media] vb2-memops: Fix over allocation of frame vectors Date: Thu, 3 Mar 2016 20:12:48 +0100 Message-Id: <1457032369-10503-1-git-send-email-ricardo.ribalda@gmail.com> X-Mailer: git-send-email 2.7.0 Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_DKIM_INVALID, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On page unaligned frames, create_framevec forces get_vaddr_frames to allocate an extra page at the end of the buffer. Under some circumstances, this leads to -EINVAL on VIDIOC_QBUF. E.g: We have vm_a that vm_area that goes from 0x1000 to 0x3000. And a frame that goes from 0x1800 to 0x2800, i.e. 2 pages. frame_vector_create will be called with the following params: get_vaddr_frames(0x1800 , 2, write, 1, vec); get_vaddr will allocate the first page after checking that the memory 0x1800-0x27ff is valid, but it will not allocate the second page because the range 0x2800-0x37ff is out of the vm_a range. This results in create_framevec returning -EFAULT Error Trace: [ 9083.793015] video0: VIDIOC_QBUF: 00:00:00.00000000 index=1, type=vid-cap, flags=0x00002002, field=any, sequence=0, memory=userptr, bytesused=0, offset/userptr=0x7ff2b023ca80, length=5765760 [ 9083.793028] timecode=00:00:00 type=0, flags=0x00000000, frames=0, userbits=0x00000000 [ 9083.793117] video0: VIDIOC_QBUF: error -22: 00:00:00.00000000 index=2, type=vid-cap, flags=0x00000000, field=any, sequence=0, memory=userptr, bytesused=0, offset/userptr=0x7ff2b07bc500, length=5765760 Fixes: 21fb0cb7ec65 ("[media] vb2: Provide helpers for mapping virtual addresses") Reported-by: Albert Antony Signed-off-by: Ricardo Ribalda Delgado Acked-by: Marek Szyprowski Reviewed-by: Jan Kara --- Maybe we should cc stable. This error has not pop-out yet because userptr is usually called with memory on the heap and malloc usually overallocate. This error has been a pain to trace :). Regards! drivers/media/v4l2-core/videobuf2-memops.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/v4l2-core/videobuf2-memops.c b/drivers/media/v4l2-core/videobuf2-memops.c index dbec5923fcf0..e4e4976c6849 100644 --- a/drivers/media/v4l2-core/videobuf2-memops.c +++ b/drivers/media/v4l2-core/videobuf2-memops.c @@ -49,7 +49,7 @@ struct frame_vector *vb2_create_framevec(unsigned long start, vec = frame_vector_create(nr); if (!vec) return ERR_PTR(-ENOMEM); - ret = get_vaddr_frames(start, nr, write, 1, vec); + ret = get_vaddr_frames(start & PAGE_MASK, nr, write, 1, vec); if (ret < 0) goto out_destroy; /* We accept only complete set of PFNs */