From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f45.google.com (mail-wm0-f45.google.com [74.125.82.45]) by dpdk.org (Postfix) with ESMTP id 54FD82BA8 for ; Fri, 1 Jul 2016 16:54:15 +0200 (CEST) Received: by mail-wm0-f45.google.com with SMTP id v199so29857762wmv.0 for ; Fri, 01 Jul 2016 07:54:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=DEGMspegIW335yJRLP7G0JrqTpaYwdZMmyxsrbPxhyQ=; b=F+RF06HGJ+15Yhj75mPrKA9kaK0tpTOlSCw/ny4l1T8wxJLbBh8W2CtfPFK//N6ml4 qNc1AJ/10jwt7/X3WrHSGFghe37UIuTkirPJ77mooobHT4LEWY5KkvARQh8i5CT1UdCV lE3OQS/0nLi2RZcPuGLwii2xWuHcgTRgYz/sW0W2lonpSLtbvqw0pn39/VB6OhjCDhbz guZoI56M2YN5McqafXYoFYrRtnts/LVXbFO0mS2GHRmMXoFPUhb5eG1BquZfFDI7YGgb n0FHMdxo7mHWo4SF1qImEBK2nR8jwMmrfxUeyttVDbgnWB4L1hMTqNIk8SiXRkZyx8JG d2Qg== 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:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=DEGMspegIW335yJRLP7G0JrqTpaYwdZMmyxsrbPxhyQ=; b=UnPYVcNW8AuJss1Ag239sw0GuLIajRAilxWyoVsCPzbw+7lXQSHGAm2uuWb6MhQKo+ ph+pQDyDSNOani1piRQmZ2uEXtMM2C51j5p7lEcgGJlx7hS94nHe8N6hkUstCnlIzoxK fhMubzA8BqfXfn1W0nnwqI+L+j099w/GyW50OdcZyWcv/Sdllsg4oRXgdyyxb1wpZ8OS d+N4i0dl+W15oS2MbfBAF+9NT6lJ2z90t8w1pKIUzX9fHTCcsH1mFP9oXpDHUMsjZ+yY 9kN1VejV/Bm/Gc8+WJqkPAfl1iYajxUR2edaLQcCanfgUDNPgldHnUwMqwVCWnmuWk0z D/aA== X-Gm-Message-State: ALyK8tJE8Gek4Zc+fl1Mde4toi/5v55Vod5nMWoYCv0WLmje+Tddszp/hHcLGPl3TnFjtmxj X-Received: by 10.28.148.1 with SMTP id w1mr34421976wmd.63.1467384855070; Fri, 01 Jul 2016 07:54:15 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id z5sm3919494wme.5.2016.07.01.07.54.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Jul 2016 07:54:14 -0700 (PDT) From: Thomas Monjalon To: Ferruh Yigit Cc: dev@dpdk.org, Stephen Hemminger Date: Fri, 01 Jul 2016 16:54:13 +0200 Message-ID: <11034006.JJrSj2UUop@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <577680BE.60408@intel.com> References: <57764BA3.5030903@intel.com> <4689144.y76TPTqy0y@xps13> <577680BE.60408@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] igb_uio: fix mmap failure X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2016 14:54:15 -0000 2016-07-01 15:39, Ferruh Yigit: > On 7/1/2016 1:47 PM, Thomas Monjalon wrote: > >> As a workaround igb_uio can stop reserving PCI memory resources, from > >> kernel point of view io-memory region looks like idle and mmap works > >> again. > >> > >> With this update device io-memory range is not protected against any > >> other kernel driver claim ownership on those resources, which shouldn't > >> be a problem for dpdk usage module. > > > > Why it should not be a problem? > > request_mem_region() is a way for driver informing the rest of the > kernel that memory region is used. > And with CONFIG_IO_STRICT_DEVMEM=y, userspace also prevented to touch > that ares. > But for igb_uio, we explicitly want userspace to access that memory range. > > > Please could you give an example of what could happen? > > Technically device lost a protection of its memory region against any > other driver, but I am not sure if this is real threat in practical life. > Also this is same in uio_pci_generic, it doesn't reserve the memory. OK thanks for the explanations. So we are not sure how this memory region can be stolen and we assume it won't. > > This patch fixes a problem with recent kernels (not mentioned above) > > which offer the uio_pci_generic alternative. > > Will give kernel version information. > > > That's why I think we should fix it only if there is absolutely no > > regression for older kernels. > > Totally agreed, that is why I expressed my concern, let this patch hang > around a little. It may be valuable to have in 16.07. I suggest to wait RC3 (mid-July) to integrate it. We will have a RC4 to test it.