https://bugs.freedesktop.org/show_bug.cgi?id=112235
Sylvain BERTRAND changed:
What|Removed |Added
Resolution|--- |NOTOURBUG
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=98376
Michel Dänzer changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
On Tue, Nov 12, 2019 at 05:45:15PM +0100, Michel Dänzer wrote:
> On 2019-11-11 8:29 p.m., Bjorn Helgaas wrote:
> > From: Bjorn Helgaas
> >
> > Add definitions for these PCIe Link Control 2 register fields:
> >
> > Enter Compliance
> > Transmit Margin
> >
> > and use them in amdgpu and radeo
From: Bjorn Helgaas
Add definitions for the Enter Compliance and Transmit Margin fields of the
PCIe Link Control 2 register.
Signed-off-by: Bjorn Helgaas
---
include/uapi/linux/pci_regs.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/p
From: Bjorn Helgaas
Previously we masked PCIe Link Control 2 register values with "7 << 9",
which was apparently intended to be the Transmit Margin field, but instead
was the high order bit of Transmit Margin, the Enter Modified Compliance
bit, and the Compliance SOS bit.
Correct the mask to "7
From: Bjorn Helgaas
Replace hard-coded magic numbers with the descriptive PCI_EXP_LNKCTL2
definitions. No functional change intended.
Signed-off-by: Bjorn Helgaas
Reviewed-by: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/cik.c | 22 ++
drivers/gpu/drm/amd/amdgpu/si.c | 22
From: Bjorn Helgaas
amdgpu and radeon do a bit of mucking with the PCIe Link Control 2
register, some of it using hard-coded magic numbers. The idea here is to
replace those with #defines.
Since v2:
- Fix a gpu_cfg2 case in amdgpu/si.c that I had missed
- Separate out the functional changes
There's a pile of things protecting against racing hotunplugs:
- drm_dev_enter/exit against the underlying device disappearing
- drm_dev_get/put against drm_device disappearing
- we unregister everything in drm_dev_unregister to stop userspace from
creating new open files to access the drm_device
Not sure we don't yet have this as a patch somewhere ...
Motivation is that the automatic lifetime management of the generic fbdev
code is quite tricky, and it'll get even more tricky. Allowing drivers
to just use the fb_probe looks like a recipe for disaster.
Cc: Gerd Hoffmann
Cc: Noralf Trønne
.
Signed-off-by: Torsten Duwe
---
The commits in question are ff1e8fb68ea06 and ee68c743f8d07, but I guess the
next rebase will change these. next-20191112 plus the anx6345-v5a series plus
this patch compile cleanly on arm64.
--- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
+++ b/drivers/gpu
guess the
> next rebase will change these. next-20191112 plus the anx6345-v5a series plus
> this patch compile cleanly on arm64.
>
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> @@ -19,6 +19,7 @@
>
On Tue, Nov 12, 2019 at 2:00 PM Mihail Atanassov
wrote:
>
> On Monday, 11 November 2019 15:53:14 GMT Liviu Dudau wrote:
> > On Thu, Nov 07, 2019 at 11:42:44AM +, Mihail Atanassov wrote:
> > > It's possible to get multiple events in a single frame/flip, so add an
> > > option to print them all.
On Tue, Nov 12, 2019 at 08:09:09PM +0300, Wambui Karuga wrote:
> Add the DRM_DEV_WARN helper macro for printing warnings
> that use device pointers in their log output format.
> DRM_DEV_WARN can replace the use of dev_warn in such cases.
>
> Signed-off-by: Wambui Karuga
Can you pls include this
https://bugs.freedesktop.org/show_bug.cgi?id=112103
erik.brandsb...@gmail.com changed:
What|Removed |Added
Priority|not set |high
--- Comment #1 from eri
On Tue, Nov 12, 2019 at 09:37:45AM -0600, Rob Herring wrote:
> On Tue, Nov 12, 2019 at 3:35 AM Daniel Vetter wrote:
> >
> > On Tue, Nov 12, 2019 at 09:52:54AM +0100, Gerd Hoffmann wrote:
> > > On Fri, Nov 08, 2019 at 05:55:28PM +0100, Daniel Vetter wrote:
> > > > On Fri, Nov 08, 2019 at 05:27:59PM
> On Nov 11, 2019, at 9:57 AM, Thomas Zimmermann wrote:
>
> Hi John
>
> Am 08.11.19 um 19:07 schrieb John Donnelly:
>>
>>
>>> On Nov 8, 2019, at 9:06 AM, Thomas Zimmermann wrote:
>>>
>>> Hi
>>>
>>> Am 08.11.19 um 13:55 schrieb John Donnelly:
> On Nov 8, 2019, at 1:46 AM, T
> -Original Message-
> From: amd-gfx On Behalf Of
> Bjorn Helgaas
> Sent: Tuesday, November 12, 2019 12:35 PM
> To: Deucher, Alexander ; Koenig, Christian
> ; Zhou, David(ChunMing)
> ; David Airlie ; Daniel Vetter
>
> Cc: Frederick Lawler ; linux-...@vger.kernel.org;
> Michel Dänzer ; lin
On Tue, Nov 12, 2019 at 06:59:40PM +0100, Torsten Duwe wrote:
>
> The anx6345 driver originally was copied from anx78xx.c, which has meanwhile
> seen a few changes. In particular, the removal of drm_dp_link helpers and the
> discontinuation to include drm_bridge.h from drm_crtc.h breaks compilation
On Tue, Nov 12, 2019 at 8:13 PM John Donnelly
wrote:
>
>
>
> > On Nov 11, 2019, at 9:57 AM, Thomas Zimmermann wrote:
> >
> > Hi John
> >
> > Am 08.11.19 um 19:07 schrieb John Donnelly:
> >>
> >>
> >>> On Nov 8, 2019, at 9:06 AM, Thomas Zimmermann wrote:
> >>>
> >>> Hi
> >>>
> >>> Am 08.11.19 um
On Tue, Nov 12, 2019 at 10:17:10AM -0800, Yiwei Zhang wrote:
> Hi folks,
>
> What do you think about:
> > For the sysfs approach, I'm assuming the upstream vendors still need
> > to provide a pair of UMD and KMD, and this ioctl to label the BO is
> > kept as driver private ioctl. Then will each dr
On 2019-11-11 7:28 a.m., YueHaibing wrote:
> Fix a build warning:
>
> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:75:1:
> warning: 'static' is not at beginning of declaration
> [-Wold-style-declaration]
>
> Signed-off-by: YueHaibing
Reviewed-by: Harry Wentland
Harry
> ---
> drivers
On 2019-11-12 2:51 a.m., Yuehaibing wrote:
> On 2019/11/12 10:39, Joe Perches wrote:
>> On Mon, 2019-11-11 at 20:28 +0800, YueHaibing wrote:
>>> Fix a build warning:
>>>
>>> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:75:1:
>>> warning: 'static' is not at beginning of declaration
>>> [-Wol
On Tue, Nov 12, 2019 at 08:32:07AM -0800, Rob Clark wrote:
> On Tue, Nov 12, 2019 at 6:01 AM Daniel Vetter wrote:
> >
> > On Tue, Nov 12, 2019 at 11:40:01AM +0100, Johan Hovold wrote:
> > > On Wed, Oct 30, 2019 at 11:01:46AM +0100, Johan Hovold wrote:
> > > > On Thu, Oct 10, 2019 at 03:13:30PM +02
Den 12.11.2019 18.50, skrev Daniel Vetter:
> Not sure we don't yet have this as a patch somewhere ...
>
> Motivation is that the automatic lifetime management of the generic fbdev
> code is quite tricky, and it'll get even more tricky. Allowing drivers
> to just use the fb_probe looks like a rec
Den 12.11.2019 18.50, skrev Daniel Vetter:
> There's a pile of things protecting against racing hotunplugs:
> - drm_dev_enter/exit against the underlying device disappearing
> - drm_dev_get/put against drm_device disappearing
> - we unregister everything in drm_dev_unregister to stop userspace fr
On Tue, Nov 12, 2019 at 9:57 PM Noralf Trønnes wrote:
> Den 12.11.2019 18.50, skrev Daniel Vetter:
> > There's a pile of things protecting against racing hotunplugs:
> > - drm_dev_enter/exit against the underlying device disappearing
> > - drm_dev_get/put against drm_device disappearing
> > - we u
On 11/12/19 12:38 PM, Jason Gunthorpe wrote:
> On Mon, Nov 11, 2019 at 04:06:37PM -0800, John Hubbard wrote:
>> Hi,
>>
>> The cover letter is long, so the more important stuff is first:
>>
>> * Jason, if you or someone could look at the the VFIO cleanup (patch 8)
>> and conversion to FOLL_PIN (pa
On 11/12/19 12:44 PM, Jason Gunthorpe wrote:
> On Mon, Nov 11, 2019 at 04:06:48PM -0800, John Hubbard wrote:
>> @@ -542,7 +541,7 @@ static int ib_umem_odp_map_dma_single_page(
>> }
>>
>> out:
>> -put_user_page(page);
>> +put_page(page);
>>
>> if (remove_existing_mapping) {
>
On Tue, Nov 12, 2019 at 1:06 PM Daniel Vetter wrote:
>
> On Tue, Nov 12, 2019 at 09:37:45AM -0600, Rob Herring wrote:
> > On Tue, Nov 12, 2019 at 3:35 AM Daniel Vetter wrote:
> > >
> > > On Tue, Nov 12, 2019 at 09:52:54AM +0100, Gerd Hoffmann wrote:
> > > > On Fri, Nov 08, 2019 at 05:55:28PM +010
LGTM, thanks,
Reviewed-by: Dave Airlie
On Sat, 9 Nov 2019 at 10:52, Manasi Navare wrote:
>
> In case of tiled displays, if we hotplug just one connector,
> fbcon currently just selects the preferred mode and if it is
> tiled mode then that becomes a problem if rest of the tiles are
> not presen
On Tue, Nov 12, 2019 at 07:35:53PM +, Deucher, Alexander wrote:
> > -Original Message-
> > From: amd-gfx On Behalf Of
> > Bjorn Helgaas
> > Sent: Tuesday, November 12, 2019 12:35 PM
> > To: Deucher, Alexander ; Koenig, Christian
> > ; Zhou, David(ChunMing)
> > ; David Airlie ; Daniel V
On Mon, Nov 11, 2019 at 4:07 PM John Hubbard wrote:
>
> As it says in the updated comment in gup.c: current FOLL_LONGTERM
> behavior is incompatible with FAULT_FLAG_ALLOW_RETRY because of the
> FS DAX check requirement on vmas.
>
> However, the corresponding restriction in get_user_pages_remote()
Booting the adreno driver on a imx53 board leads to the following
error message:
adreno 3000.gpu: [drm:adreno_gpu_init] *ERROR* Could not find the GPU
powerlevels
As the "qcom,gpu-pwrlevels" property is optional and never present on
i.MX5, turn the message into debug level instead.
Signed-o
On Tue, Nov 12, 2019 at 10:31 PM Rob Herring wrote:
>
> On Tue, Nov 12, 2019 at 1:06 PM Daniel Vetter wrote:
> >
> > On Tue, Nov 12, 2019 at 09:37:45AM -0600, Rob Herring wrote:
> > > On Tue, Nov 12, 2019 at 3:35 AM Daniel Vetter wrote:
> > > >
> > > > On Tue, Nov 12, 2019 at 09:52:54AM +0100, G
On Tue, Nov 12, 2019 at 03:06:31PM +0100, Christoph Hellwig wrote:
> On Tue, Nov 12, 2019 at 02:04:16PM +0100, Daniel Vetter wrote:
> > Wut ... Maybe I'm missing something, but from how we use mtrr in other
> > gpu drivers it's a) either you use MTRR because that's all you got or
> > b) you use pat
For gen12+ architectures, i915 no longer supports use of GET_TILING
ioctl [1]. This breaks the usage of two libdrm functions on those
platforms:
drm_intel_bo_gem_create_from_name() and
drm_intel_bo_gem_create_from_prime().
We also have IGTs which test drm_intel_gem_bo_flink() followed by
drm_i
On 11/12/19 1:57 PM, Dan Williams wrote:
...
>> diff --git a/drivers/vfio/vfio_iommu_type1.c
>> b/drivers/vfio/vfio_iommu_type1.c
>> index d864277ea16f..017689b7c32b 100644
>> --- a/drivers/vfio/vfio_iommu_type1.c
>> +++ b/drivers/vfio/vfio_iommu_type1.c
>> @@ -348,24 +348,20 @@ static int vaddr_g
On Tue, Nov 12, 2019 at 03:26:35PM +0100, Daniel Vetter wrote:
> On Tue, Nov 12, 2019 at 3:06 PM Christoph Hellwig wrote:
> > On Tue, Nov 12, 2019 at 02:04:16PM +0100, Daniel Vetter wrote:
> > > Wut ... Maybe I'm missing something, but from how we use mtrr in other
> > > gpu drivers it's a) either
On 11/12/19 12:43 PM, Jason Gunthorpe wrote:
...
>> -}
>> +ret = get_user_pages_remote(NULL, mm, vaddr, 1, flags | FOLL_LONGTERM,
>> +page, vmas, NULL);
>> +/*
>> + * The lifetime of a vaddr_get_pfn() page pin is
>> + * userspace-controlle
On Tue, Nov 12, 2019 at 2:24 PM John Hubbard wrote:
>
> On 11/12/19 1:57 PM, Dan Williams wrote:
> ...
> >> diff --git a/drivers/vfio/vfio_iommu_type1.c
> >> b/drivers/vfio/vfio_iommu_type1.c
> >> index d864277ea16f..017689b7c32b 100644
> >> --- a/drivers/vfio/vfio_iommu_type1.c
> >> +++ b/driver
On Tue, Nov 12, 2019 at 2:43 PM John Hubbard wrote:
>
> On 11/12/19 12:43 PM, Jason Gunthorpe wrote:
> ...
> >> -}
> >> +ret = get_user_pages_remote(NULL, mm, vaddr, 1, flags | FOLL_LONGTERM,
> >> +page, vmas, NULL);
> >> +/*
> >> + * The lif
On 11/12/19 2:43 PM, Dan Williams wrote:
...
> Ah, sorry. This was the first time I had looked at this series and
> jumped in without reading the background.
>
> Your patch as is looks ok, I assume you've removed the FOLL_LONGTERM
> warning in get_user_pages_remote in another patch?
>
Actually,
On Tue, Nov 12, 2019 at 3:08 PM John Hubbard wrote:
>
> On 11/12/19 2:43 PM, Dan Williams wrote:
> ...
> > Ah, sorry. This was the first time I had looked at this series and
> > jumped in without reading the background.
> >
> > Your patch as is looks ok, I assume you've removed the FOLL_LONGTERM
>
https://bugs.freedesktop.org/show_bug.cgi?id=111763
--- Comment #36 from John H ---
Also, for people who have a 5700XT card, check if yours has dual BIOS's
Typically one is for running at normal clock speeds, and the other is for
running overclocked values.
My card, the Powercolor Red Devil 570
On 11/12/19 2:45 PM, Dan Williams wrote:
> On Tue, Nov 12, 2019 at 2:43 PM John Hubbard wrote:
>>
>> On 11/12/19 12:43 PM, Jason Gunthorpe wrote:
>> ...
-}
+ret = get_user_pages_remote(NULL, mm, vaddr, 1, flags | FOLL_LONGTERM,
+page,
On 11/12/19 3:14 PM, Dan Williams wrote:
...
>>
>> Is that OK, or did you want to go further (possibly in a follow-up
>> patchset, as I'm hoping to get this one in soon)?
>
> That looks ok. Something to maybe push down into the core in a future
Great! I'll post a cleaned up v4 (with the extraneo
https://bugs.freedesktop.org/show_bug.cgi?id=111763
--- Comment #37 from Andrew Sheldon ---
(In reply to Daniel Suarez from comment #33)
> That workaround delays the hangs af best, and I have gotten hangs from
> OpenGl Games and also by using amdvlk.
>
Those hangs shouldn't be SDMA related, h
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/gem/i915_gem_context.c
between commit:
f8c08d8faee5 ("drm/i915/cmdparser: Add support for backward jumps")
from Linus' tree and commit:
a4e7ccdac38e ("drm/i915: Move context management under GEM")
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/gt/intel_engine_types.h
between commit:
311a50e76a33 ("drm/i915: Add support for mandatory cmdparsing")
from Linus' tree and commits:
cdb736fa8b8b ("drm/i915: Use engine relative LRIs on context set
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/gt/intel_gt_pm.c
between commit:
7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX corruption WA")
from Linus' tree and commit:
3e7abf814193 ("drm/i915: Extract GT render power state management")
from the
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/i915_drv.c
between commits:
7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX corruption WA")
2f216a850715 ("drm/i915: update rawclk also on resume")
from Linus' tree and commits:
5bcd53aa39f3 ("drm/i91
On Tue, Nov 12, 2019 at 3:43 PM Jason Gunthorpe wrote:
>
> On Tue, Nov 12, 2019 at 02:45:51PM -0800, Dan Williams wrote:
> > On Tue, Nov 12, 2019 at 2:43 PM John Hubbard wrote:
> > >
> > > On 11/12/19 12:43 PM, Jason Gunthorpe wrote:
> > > ...
> > > >> -}
> > > >> +ret = get_user_
On 11/12/19 4:58 PM, Dan Williams wrote:
...
It's not redundant relative to upstream which does not do anything the
FOLL_LONGTERM in the gup-slow path... but I have not looked at patches
1-7 to see if something there made it redundant.
Oh, the hunk John had below for get_user_pages_remote() als
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/i915_reg.h
between commit:
1d85a299c4db ("drm/i915: Lower RM timeout to avoid DSI hard hangs")
from Linus' tree and commit:
41286861b4c9 ("drm/i915/tgl: Add DC3CO counter in i915_dmc_info")
from th
Fix the build errors lead by
'commit 4039f0293bbd ("drm/komeda: Add option to print WARN- and INFO-level IRQ
events")'
Signed-off-by: james qian wang (Arm Technology China)
---
drivers/gpu/drm/arm/display/komeda/komeda_dev.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
On Tue, Nov 12, 2019 at 5:08 PM John Hubbard wrote:
>
> On 11/12/19 4:58 PM, Dan Williams wrote:
> ...
> >>> It's not redundant relative to upstream which does not do anything the
> >>> FOLL_LONGTERM in the gup-slow path... but I have not looked at patches
> >>> 1-7 to see if something there made
Hi all,
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/i915/i915_drv.h
drivers/gpu/drm/i915/intel_pm.c
drivers/gpu/drm/i915/intel_pm.h
between commit:
7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX corruption WA")
from Linus' tree and commits:
c113236718e8 (
On Tue, Nov 12, 2019 at 07:24:16PM +0100, Daniel Vetter wrote:
> On Tue, Nov 12, 2019 at 2:00 PM Mihail Atanassov
> wrote:
> >
> > On Monday, 11 November 2019 15:53:14 GMT Liviu Dudau wrote:
> > > On Thu, Nov 07, 2019 at 11:42:44AM +, Mihail Atanassov wrote:
> > > > It's possible to get multip
From: Jordan Crouse
[ Upstream commit 32aa27e15c28d3898ed6f9b3c98f95f34a81eab2 ]
The point of the 'force_dma' parameter for of_dma_configure
is to force the device to be set up even if DMA capability is
not described by the firmware which is exactly the use case
we have for GMU - we need SMMU t
From: Dan Carpenter
[ Upstream commit e5017716adb8aa5c01c52386c1b7470101ffe9c5 ]
The "index + count" addition can overflow. Both come directly from the
user. This bug leads to an information leak.
Signed-off-by: Dan Carpenter
Cc: Peter Malone
Cc: Philippe Ombredanne
Cc: Mathieu Malaterre
From: Dan Carpenter
[ Upstream commit d8bad911e5e55e228d59c0606ff7e6b8131ca7bf ]
I'm not sure why the code assumes that only the first put_user() needs
an access_ok() check. I have made all the put_user() and get_user()
calls checked.
Signed-off-by: Dan Carpenter
Cc: Philippe Ombredanne
Cc:
From: Randy Dunlap
[ Upstream commit aae3394ef0ef90cf00a21133357448385f13a5d4 ]
The framebuffer options and devices menu is unintentionally split
or broken because some items in it do not depend on FB (including
several under omap and mmp).
Fix this by moving FB_CMDLINE, FB_NOTIFY, and FB_CLPS71
From: Sam Ravnborg
[ Upstream commit 60e5e48dba72c6b59a7a9c7686ba320766913368 ]
When a device tree set a display-timing using native-mode
then according to the bindings doc this should:
native-mode:
The native mode for the display, in case multiple
modes are provided.
When omitt
From: Nathan Chancellor
[ Upstream commit 7cea645ae9c5a54aa7904fddb2cdf250acd63a6c ]
Clang warns that the address of a pointer will always evaluated as true
in a boolean context.
drivers/video/backlight/lm3639_bl.c:403:14: warning: address of
'pchip->cdev_torch' will always evaluate to 'true'
[
From: Dan Carpenter
[ Upstream commit e5017716adb8aa5c01c52386c1b7470101ffe9c5 ]
The "index + count" addition can overflow. Both come directly from the
user. This bug leads to an information leak.
Signed-off-by: Dan Carpenter
Cc: Peter Malone
Cc: Philippe Ombredanne
Cc: Mathieu Malaterre
From: Dan Carpenter
[ Upstream commit d8bad911e5e55e228d59c0606ff7e6b8131ca7bf ]
I'm not sure why the code assumes that only the first put_user() needs
an access_ok() check. I have made all the put_user() and get_user()
calls checked.
Signed-off-by: Dan Carpenter
Cc: Philippe Ombredanne
Cc:
From: Nathan Chancellor
[ Upstream commit 7cea645ae9c5a54aa7904fddb2cdf250acd63a6c ]
Clang warns that the address of a pointer will always evaluated as true
in a boolean context.
drivers/video/backlight/lm3639_bl.c:403:14: warning: address of
'pchip->cdev_torch' will always evaluate to 'true'
[
From: Nathan Chancellor
[ Upstream commit 7cea645ae9c5a54aa7904fddb2cdf250acd63a6c ]
Clang warns that the address of a pointer will always evaluated as true
in a boolean context.
drivers/video/backlight/lm3639_bl.c:403:14: warning: address of
'pchip->cdev_torch' will always evaluate to 'true'
[
From: Dan Carpenter
[ Upstream commit d8bad911e5e55e228d59c0606ff7e6b8131ca7bf ]
I'm not sure why the code assumes that only the first put_user() needs
an access_ok() check. I have made all the put_user() and get_user()
calls checked.
Signed-off-by: Dan Carpenter
Cc: Philippe Ombredanne
Cc:
From: Dan Carpenter
[ Upstream commit e5017716adb8aa5c01c52386c1b7470101ffe9c5 ]
The "index + count" addition can overflow. Both come directly from the
user. This bug leads to an information leak.
Signed-off-by: Dan Carpenter
Cc: Peter Malone
Cc: Philippe Ombredanne
Cc: Mathieu Malaterre
On Fri, Nov 08, 2019 at 04:09:54PM +, Ayan Halder wrote:
> On Mon, Nov 04, 2019 at 11:12:27PM +0100, Andrzej Pietrasiewicz wrote:
> > There are afbc helpers available.
> >
> > Signed-off-by: Andrzej Pietrasiewicz
> > ---
> > .../arm/display/komeda/komeda_format_caps.h | 1 -
> > .../arm/d
From: Dan Carpenter
[ Upstream commit d8bad911e5e55e228d59c0606ff7e6b8131ca7bf ]
I'm not sure why the code assumes that only the first put_user() needs
an access_ok() check. I have made all the put_user() and get_user()
calls checked.
Signed-off-by: Dan Carpenter
Cc: Philippe Ombredanne
Cc:
From: Dan Carpenter
[ Upstream commit e5017716adb8aa5c01c52386c1b7470101ffe9c5 ]
The "index + count" addition can overflow. Both come directly from the
user. This bug leads to an information leak.
Signed-off-by: Dan Carpenter
Cc: Peter Malone
Cc: Philippe Ombredanne
Cc: Mathieu Malaterre
From: Nathan Chancellor
[ Upstream commit 7cea645ae9c5a54aa7904fddb2cdf250acd63a6c ]
Clang warns that the address of a pointer will always evaluated as true
in a boolean context.
drivers/video/backlight/lm3639_bl.c:403:14: warning: address of
'pchip->cdev_torch' will always evaluate to 'true'
[
On 11/12/19 5:35 PM, Dan Williams wrote:
> On Tue, Nov 12, 2019 at 5:08 PM John Hubbard wrote:
>>
>> On 11/12/19 4:58 PM, Dan Williams wrote:
>> ...
> It's not redundant relative to upstream which does not do anything the
> FOLL_LONGTERM in the gup-slow path... but I have not looked at pat
On Mon, 4 Nov 2019 02:39:27 +0100, =?UTF-8?q?Andreas=20F=C3=A4rber?= wrote:
> Define a compatible string for Realtek RTD1295 SoC family.
>
> Signed-off-by: Andreas Färber
> ---
> Documentation/devicetree/bindings/gpu/arm,mali-midgard.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Applied, tha
On Mon, 4 Nov 2019 02:39:32 +0100, =?UTF-8?q?Andreas=20F=C3=A4rber?= wrote:
> Define a compatible string for Realtek RTD1619 SoC family.
>
> Signed-off-by: Andreas Färber
> ---
> Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Applied, tha
Hi Hans,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on v5.4-rc7 next-20191112]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use
Fix the gup benchmark flags to use the symbolic FOLL_WRITE,
instead of a hard-coded "1" value.
Also, clean up the filtering of gup flags a little, by just doing
it once before issuing any of the get_user_pages*() calls. This
makes it harder to overlook, instead of having little "gup_flags & 1"
phr
There are four locations in gup.c that have a fair amount of code
duplication. This means that changing one requires making the same
changes in four places, not to mention reading the same code four
times, and wondering if there are subtle differences.
Factor out the common code into static functi
As it says in the updated comment in gup.c: current FOLL_LONGTERM
behavior is incompatible with FAULT_FLAG_ALLOW_RETRY because of the
FS DAX check requirement on vmas.
However, the corresponding restriction in get_user_pages_remote() was
slightly stricter than is actually required: it forbade all
It's good to have basic unit test coverage of the new FOLL_PIN
behavior. Fortunately, the gup_benchmark unit test is extremely
fast (a few milliseconds), so adding it the the run_vmtests suite
is going to cause no noticeable change in running time.
So, add two new invocations to run_vmtests:
1) R
1. Change v4l2 from get_user_pages(FOLL_LONGTERM), to
pin_longterm_pages(), which sets both FOLL_LONGTERM and FOLL_PIN.
2. Because all FOLL_PIN-acquired pages must be released via
put_user_page(), also convert the put_page() call over to
put_user_pages_dirty_lock().
Acked-by: Hans Verkuil
Review
Add tracking of pages that were pinned via FOLL_PIN.
As mentioned in the FOLL_PIN documentation, callers who effectively set
FOLL_PIN are required to ultimately free such pages via put_user_page().
The effect is similar to FOLL_GET, and may be thought of as "FOLL_GET
for DIO and/or RDMA use".
Pag
An upcoming patch uses try_get_compound_head() more widely,
so move it to the top of gup.c.
Also fix a tiny spelling error and a checkpatch.pl warning.
Signed-off-by: John Hubbard
---
mm/gup.c | 29 +++--
1 file changed, 15 insertions(+), 14 deletions(-)
diff --git a/mm
OK, here we go. Any VFIO and Infiniband runtime testing from anyone, is
especially welcome here.
Changes since v3:
* VFIO fix (patch 8): applied further cleanup: removed a pre-existing,
unnecessary release and reacquire of mmap_sem. Moved the DAX vma
checks from the vfio call site, to gup int
Convert net/xdp to use the new pin_longterm_pages() call, which sets
FOLL_PIN. Setting FOLL_PIN is now required for code that requires
tracking of pinned pages.
In partial anticipation of this work, the net/xdp code was already
calling put_user_page() instead of put_page(). Therefore, in order to
And get rid of the mmap_sem calls, as part of that. Note
that get_user_pages_fast() will, if necessary, fall back to
__gup_longterm_unlocked(), which takes the mmap_sem as needed.
Reviewed-by: Jason Gunthorpe
Reviewed-by: Ira Weiny
Signed-off-by: John Hubbard
---
drivers/infiniband/core/umem.c
After DMA is complete, and the device and CPU caches are synchronized,
it's still required to mark the CPU pages as dirty, if the data was
coming from the device. However, this driver was just issuing a
bare put_page() call, without any set_page_dirty*() call.
Fix the problem, by calling set_page_
Convert infiniband to use the new wrapper calls, and stop
explicitly setting FOLL_LONGTERM at the call sites.
The new pin_longterm_*() calls replace get_user_pages*()
calls, and set both FOLL_LONGTERM and a new FOLL_PIN
flag. The FOLL_PIN flag requires that the caller must
return the pages via put
1. Change vfio from get_user_pages(FOLL_LONGTERM), to
pin_longterm_pages(), which sets both FOLL_LONGTERM and FOLL_PIN.
2. Because all FOLL_PIN-acquired pages must be released via
put_user_page(), also convert the put_page() call over to
put_user_pages().
Note that this effectively changes the co
A subsequent patch requires access to gup flags, so
pass the flags argument through to the __gup_device_*
functions.
Also placate checkpatch.pl by shortening a nearby line.
Reviewed-by: Jérôme Glisse
Reviewed-by: Ira Weiny
Cc: Kirill A. Shutemov
Signed-off-by: John Hubbard
---
mm/gup.c | 28
An upcoming patch changes and complicates the refcounting and
especially the "put page" aspects of it. In order to keep
everything clean, refactor the devmap page release routines:
* Rename put_devmap_managed_page() to page_is_devmap_managed(),
and limit the functionality to "read only": return
Convert process_vm_access to use the new pin_user_pages_remote()
call, which sets FOLL_PIN. Setting FOLL_PIN is now required for
code that requires tracking of pinned pages.
Also, release the pages via put_user_page*().
Also, rename "pages" to "pinned_pages", as this makes for
easier reading of p
Convert drm/via to use the new pin_user_pages_fast() call, which sets
FOLL_PIN. Setting FOLL_PIN is now required for code that requires
tracking of pinned pages, and therefore for any code that calls
put_user_page().
In partial anticipation of this work, the drm/via driver was already
calling put_
Up until now, gup_benchmark supported testing of the
following kernel functions:
* get_user_pages(): via the '-U' command line option
* get_user_pages_longterm(): via the '-L' command line option
* get_user_pages_fast(): as the default (no options required)
Add test coverage for the new correspon
1. Call the new global pin_user_pages_fast(), from pin_goldfish_pages().
2. As required by pin_user_pages(), release these pages via
put_user_page(). In this case, do so via put_user_pages_dirty_lock().
That has the side effect of calling set_page_dirty_lock(), instead
of set_page_dirty(). This i
1. Convert from get_user_pages(FOLL_LONGTERM) to pin_longterm_pages().
2. As required by pin_user_pages(), release these pages via
put_user_page(). In this case, do so via put_user_pages_dirty_lock().
That has the side effect of calling set_page_dirty_lock(), instead
of set_page_dirty(). This is
1. Avoid naming conflicts: rename local static function from
"pin_user_pages()" to "pin_goldfish_pages()".
An upcoming patch will introduce a global pin_user_pages()
function.
Reviewed-by: Jérôme Glisse
Reviewed-by: Ira Weiny
Signed-off-by: John Hubbard
---
drivers/platform/goldfish/goldfish_
Introduce pin_user_pages*() variations of get_user_pages*() calls,
and also pin_longterm_pages*() variations.
These variants all set FOLL_PIN, which is also introduced, and
thoroughly documented.
The pin_longterm*() variants also set FOLL_LONGTERM, in addition
to FOLL_PIN:
pin_user_pages()
101 - 200 of 247 matches
Mail list logo
