From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 304EAC433E0 for ; Sat, 2 Jan 2021 15:12:17 +0000 (UTC) Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9DF85224DF for ; Sat, 2 Jan 2021 15:12:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9DF85224DF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernelnewbies-bounces@kernelnewbies.org Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.94) (envelope-from ) id 1kviZU-0006Pk-Uc; Sat, 02 Jan 2021 10:12:00 -0500 Received: from mail-yb1-xb31.google.com ([2607:f8b0:4864:20::b31]) by shelob.surriel.com with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94) (envelope-from ) id 1kviZS-0006P7-6X for Kernelnewbies@kernelnewbies.org; Sat, 02 Jan 2021 10:11:58 -0500 Received: by mail-yb1-xb31.google.com with SMTP id j17so21801932ybt.9 for ; Sat, 02 Jan 2021 07:11:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9Ep+sfJi0gy1YLVvbW4yTdZxkxJitEkkbgsU1eJYfvY=; b=KNX+KvtVccvIaHZn/Ziy44fgTL2m9t75i8MB55a0tZHEmeo7jFO+QMb206d8t9Q5X1 1zkc/XATyFQZYMoGAPW4YoSf45gJabMWFXPFswSQKtxFdGerBZnkX2UqFlnUjqW+OcWy G69/cdxY04XlMCUSdGlusX4zt8Efx5hdexo0Y9To9VPfbKN1OuOJ0bhRyLDZQjxboQag SiwVsDL07c+P+laUHZQH2VmMShbk8wXAVgGr2wBiApU1gt2YiMNqrWG7S6Gdh5vW/UVf r3bjBee4B3+TumfltnI/lSVpXPN3VKpyzopaeWOWPaiyNiEaUzRRMwcJ6zVCHjFfQCZ1 PZaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9Ep+sfJi0gy1YLVvbW4yTdZxkxJitEkkbgsU1eJYfvY=; b=ZRx135hiqWiUTj1vtBFM0ol6fZKCPS3EGvuXMuiZYuRQ2RflSGfH8xT6OObTZdOGxo fAKgz6OxmjHA2vqx6iDsIGCG2sn7JjT3EsD0ZeUw3SmttJNrnn3kjiZOjj1hx2E71JBO PEHBfZw79L6zIX2H84SMbYFlDo+3icR+M+DFEMrKGSNHoMhgAii+QwN9E/KixwtbkwuU hmqLyVmrY5mUim1w9gxdXY7mb2iuEbgpuhs3c4q0tH4PIaezsfW3Z32vXjr/NYnGcNCO a8M8RkdnVUaS6nFrar+U4yQw54o3RJgN/DJphCBkx+uylTVnzRE7LAQXMvl98eLPKEh5 OdbA== X-Gm-Message-State: AOAM531LBweMnUmZlmtBs+rXaEO03L0EsTdydH0iuKMKkmZPOEs7W8RO QMJytH5z5TsBmuqUMXB9jcSBENTGfzp9dRnDQoc= X-Google-Smtp-Source: ABdhPJwRmIsH6482ixYNv+iZ8FCL58hqzlHhkzwAtyOYC9xDUS0a2LI2b3tkarnJ8/YW/6niWS58Ni1oG8+PrrAg/vw= X-Received: by 2002:a25:690c:: with SMTP id e12mr90790761ybc.482.1609600317191; Sat, 02 Jan 2021 07:11:57 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Sadanand Warrier Date: Sat, 2 Jan 2021 10:11:46 -0500 Message-ID: Subject: Re: get_user_pages and pinning To: Greg KH Cc: Kernelnewbies@kernelnewbies.org X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kernelnewbies-bounces@kernelnewbies.org Thanks Greg > You should get an error of -EFAULT when you try to do this when the > kernel tries to access memory you don't have. > > But the best way to be sure is to actually try it yourself and see! > There's nothing preventing you from doing that, right? :) Ah yes that is of course true.:-) I did try it on Centos 4.18 and sadly I do not get an -EFAULT. Even access_ok blithely passes it off to the depths in the driver. But I suppose unless the kernel actually tries to access the memory in the midst of get_user_pages I would not see an error. Since I do not see such an error I am supposing it doesn't (actually touch the pages I mean), I haven't yet delved into the bowels of the code yet. I thought I would ask here. Now after get_user_pages and after suitable calls to sg_dma_map etc to get the bus address associated with the buffer, this area is passed to a device. If the buffer has been allocated and initialized in user space all is good. This has been tried several times, by using memset, calloc, actually initializing every element of the allocated buffer etc. If not then I notice for various offsets in the buffer at page boundaries the physical(bus) address points to the same page. The device does the DMA and we end up with segmentation faults in unrelated areas . systemd seems to be a frequent victim, I guess our device has a bone to pick. I know 5,0 onwards has the pin_user_pages family which may have some solutions but for the moment I am stuck with 4.18. Perhaps some other adventurous soul has tried this? Again an IOMMU is not present in bit of hardware though that may be neither here nor there. S _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies