Received: by 10.192.165.148 with SMTP id m20csp3556513imm; Mon, 23 Apr 2018 08:29:09 -0700 (PDT) X-Google-Smtp-Source: AIpwx49x7U+rxBp84mGrs/jLCX3aW/CJMup+DtH/UWYnqSGiwOXWU+n2CihFsOOA0gzHNcHRUzr7 X-Received: by 10.101.102.3 with SMTP id w3mr17401974pgv.151.1524497348938; Mon, 23 Apr 2018 08:29:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524497348; cv=none; d=google.com; s=arc-20160816; b=a8ZdfRuuwwF6zevqt3voBGkDGnMsSaaLpe3xFzc9ux/Q5xEbySEmLQGKlR02A4zJrJ H+cFFTDFZ/Xqf6Bfcb/Q5hneTNOfRJ+7nW64k/e4iZ+j8In971zaKr7R4vG1HYuLwXbw lROpAGFaXmJfdAYZjOHp6hDSRATeziXkpXOaj3Mz+bRwtWvRhwFwUQhn1KRQy74vWWox BTTX3kxr/zPIsW9JKgNamyOQtl37xMWoNIauMJ3PkTIF9IU1i0AsAO7s5wrsJDhYr/JB NLjJYCa5MuSQq3ClFf9Ar1b+YIVu1gIFpjAJ2GYe34o0xTp3DoclClhoeepo+IWLH5hC V/Jg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=Dgxzmz99GPSdaO5n2HvsEqbUj513yMVVH7gpGO4e540=; b=GurSio8PptsYOtKSXE1r+BnJYg7u07Wg+A4rLz2uuTg0gfur2hgFIUmb9/y/vfi9wu vvNS/5NliG0Thl48FQgPxqT/BO1CXA49dJ+69libgvh0rMCoWv3SUAUCp4QSO+wqORg0 YTAk744QfkWTz6yrCImvUxsxdV1XCDSNRHdvY/4xT1WJObS7yBVe/Ymxnw+3LoenIqOx DBhHnX7mPSgHpMm1NAxifeMaPVfmwDHnODjAUixiZQEba9uoW4bDoOsdCUXqp+HzvAzR 7sWXddBIvlwLMplnpG0u2Pwiec64JhnxhG9vmv/aoTCPTUBBJ06LoykSeE7hAN6Np14R JQSg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r59-v6si11992126plb.218.2018.04.23.08.28.54; Mon, 23 Apr 2018 08:29:08 -0700 (PDT) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755902AbeDWP0D (ORCPT + 99 others); Mon, 23 Apr 2018 11:26:03 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:33332 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755666AbeDWP0B (ORCPT ); Mon, 23 Apr 2018 11:26:01 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2060CEC010; Mon, 23 Apr 2018 15:26:01 +0000 (UTC) Received: from redhat.com (ovpn-123-116.rdu2.redhat.com [10.10.123.116]) by smtp.corp.redhat.com (Postfix) with SMTP id 2624A1102E26; Mon, 23 Apr 2018 15:25:58 +0000 (UTC) Date: Mon, 23 Apr 2018 18:25:57 +0300 From: "Michael S. Tsirkin" To: Mikulas Patocka Cc: Matthew Wilcox , David Miller , Andrew Morton , linux-mm@kvack.org, eric.dumazet@gmail.com, edumazet@google.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, jasowang@redhat.com, virtualization@lists.linux-foundation.org, dm-devel@redhat.com, Vlastimil Babka Subject: Re: [PATCH] kvmalloc: always use vmalloc if CONFIG_DEBUG_VM Message-ID: <20180423181250-mutt-send-email-mst@kernel.org> References: <3e65977e-53cd-bf09-bc4b-0ce40e9091fe@gmail.com> <20180418.134651.2225112489265654270.davem@davemloft.net> <20180420114712.GB10788@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Mon, 23 Apr 2018 15:26:01 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Mon, 23 Apr 2018 15:26:01 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'mst@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 20, 2018 at 08:20:23AM -0400, Mikulas Patocka wrote: > > > On Fri, 20 Apr 2018, Matthew Wilcox wrote: > > > On Thu, Apr 19, 2018 at 12:12:38PM -0400, Mikulas Patocka wrote: > > > Unfortunatelly, some kernel code has bugs - it uses kvmalloc and then > > > uses DMA-API on the returned memory or frees it with kfree. Such bugs were > > > found in the virtio-net driver, dm-integrity or RHEL7 powerpc-specific > > > code. > > > > Maybe it's time to have the SG code handle vmalloced pages? This is > > becoming more and more common with vmapped stacks (and some of our > > workarounds are hideous -- allocate 4 bytes with kmalloc because we can't > > DMA onto the stack any more?). We already have a few places which do > > handle sgs of vmalloced addresses, such as the nx crypto driver: > > > > if (is_vmalloc_addr(start_addr)) > > sg_addr = page_to_phys(vmalloc_to_page(start_addr)) > > + offset_in_page(sg_addr); > > else > > sg_addr = __pa(sg_addr); > > > > and videobuf: > > > > pg = vmalloc_to_page(virt); > > if (NULL == pg) > > goto err; > > BUG_ON(page_to_pfn(pg) >= (1 << (32 - PAGE_SHIFT))); > > sg_set_page(&sglist[i], pg, PAGE_SIZE, 0); > > > > Yes, there's the potential that we have to produce two SG entries for a > > virtually contiguous region if it crosses a page boundary, and our APIs > > aren't set up right to make it happen. But this is something we should > > consider fixing ... otherwise we'll end up with dozens of driver hacks. > > The videobuf implementation was already copy-and-pasted into the saa7146 > > driver, for example. > > What if the device requires physically contiguous area and the vmalloc > area crosses a page? Will you use a bounce buffer? Where do you allocate > the bounce buffer from? What if you run out of bounce buffers? > > Mikulkas I agree with Matthew here. 4 byte variables are typically size aligned so won't cross a boundary. That's enough for virtio at least. People using structs can force alignment. We could wrap access in a macro (sizeof(x) >= alignof(x)) to help guarantee that. -- MST