Signed-off-by: Javier Martinez Canillas
---
drivers/base/dma-buf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index ea77701..840c7fa 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -491,7 +491,7 @@ EXPORT
commit c0b00a5 ("dma-buf: update debugfs output") modified the
default exporter name to be the KBUILD_MODNAME pre-processor
macro instead of __FILE__ but the documentation was not updated.
Also the "Supporting existing mmap interfaces in exporters" section
title seems wrong since talks about the i
Please re-send this patch with a correct commit message (subject). Add
at least "drm: " prefix to it.
2014-04-09 23:11 GMT+02:00 Micah Richert :
> Signed-off-by: Micah Richert
You have some weird indent before "Signed-off-by".
Hi Dan,
Thanks for the patch.
On 04/09/2014 05:21 PM, Dan Carpenter wrote:
> Smatch complains that we are reading beyond the end of the array here:
>
> drivers/gpu/drm/panel/panel-s6e8aa0.c:852 s6e8aa0_read_mtp_id()
> warn: buffer overflow 's6e8aa0_variants' 4 <= 4
>
> We set the erro
Hi Dave,
Could you pick up this patch?
It touches drm core and different drm drivers so I guess
your repo is the best place for it.
Regards
Andrzej
On 04/03/2014 11:21 PM, Daniel Vetter wrote:
> On Wed, Apr 02, 2014 at 12:29:46PM +0200, Andrzej Hajda wrote:
>> Many drm connectors do not need mod
+0900
r600g: Don't leak bytecode on shader compile failure
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/
On Thu, Apr 10, 2014 at 01:30:06AM +0200, Javier Martinez Canillas wrote:
> commit c0b00a5 ("dma-buf: update debugfs output") modified the
> default exporter name to be the KBUILD_MODNAME pre-processor
> macro instead of __FILE__ but the documentation was not updated.
>
> Also the "Supporting exis
nux/fence.h | 22 ++
> include/linux/reservation.h | 40
> 4 files changed, 224 insertions(+), 31 deletions(-)
>
-- next part --
A non-text attachment was scrubbed...
Name: rcu_fence.diff
Type: text/x-patch
Size: 4139 bytes
Desc: not availabl
This is leftover stuff from my previous doc round which I kinda wanted
to do but didn't yet due to rebase hell.
The modeset helpers and the probing helpers a independent and e.g.
i915 uses the probing stuff but has its own modeset infrastructure. It
hence makes to split this up. While at it add a
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #9 from sdh ---
Hi,
Any update on this? Is there any other information required to fix the bug?
--
You are receiving this mail because:
You are watching the assignee of the bug.
Hey,
op 10-04-14 10:46, Thomas Hellstrom schreef:
> Hi!
>
> Ugh. This became more complicated than I thought, but I'm OK with moving
> TTM over to fence while we sort out
> how / if we're going to use this.
>
> While reviewing, it struck me that this is kind of error-prone, and hard
> to follow si
On 09.04.2014 15:39, Thierry Reding wrote:
> From: Thierry Reding
>
> The version of the drm_tegra_submit structure that was merged all the
> way back in 3.10 contains a pad field that was originally intended to
> properly pad the following __u64 field. Unfortunately it seems like a
> different f
org/archives/dri-devel/attachments/20140410/7568c976/attachment.html>
Adding Rob and Rusty in the review thread.
Kindly review these patches for interface being proposed to set
color/alpha property of planes modeled after glBlendFunc.
http://lists.freedesktop.org/archives/intel-gfx/2014-March/042350.html
http://lists.freedesktop.org/archives/intel-gfx/2014-March
On 04/10/2014 12:07 PM, Maarten Lankhorst wrote:
> Hey,
>
> op 10-04-14 10:46, Thomas Hellstrom schreef:
>> Hi!
>>
>> Ugh. This became more complicated than I thought, but I'm OK with moving
>> TTM over to fence while we sort out
>> how / if we're going to use this.
>>
>> While reviewing, it struck
On 04/10/2014 01:08 PM, Thomas Hellstrom wrote:
> On 04/10/2014 12:07 PM, Maarten Lankhorst wrote:
>> Hey,
>>
>> op 10-04-14 10:46, Thomas Hellstrom schreef:
>>> Hi!
>>>
>>> Ugh. This became more complicated than I thought, but I'm OK with moving
>>> TTM over to fence while we sort out
>>> how / if
This was originally un-inlined by Andi Kleen in 2011 citing size concerns.
Indeed, inlining it grows radeon.ko by 7%.
However, 2% of cpu is spent in this function. Inlining it gives 1% more fps
in Urban Terror.
Signed-off-by: Lauri Kasanen
---
drivers/gpu/drm/radeon/r100.c | 18 --
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/0b570f5d/attachment.html>
68
and it looked great, too. 368 vs 100 on 24P made vary little difference too
me.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/afa0392f/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=71891
--- Comment #10 from Christian K?nig ---
Created attachment 131871
--> https://bugzilla.kernel.org/attachment.cgi?id=131871&action=edit
Possible fix.
Please try the attached patch.
--
You are receiving this mail because:
You are watching the
check-recursive] Error 1
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/cd9a06f3/attachment.html>
top.org/archives/dri-devel/attachments/20140410/c74601ff/attachment-0001.html>
--- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/93a4e11e/attachment.html>
op 10-04-14 13:08, Thomas Hellstrom schreef:
> On 04/10/2014 12:07 PM, Maarten Lankhorst wrote:
>> Hey,
>>
>> op 10-04-14 10:46, Thomas Hellstrom schreef:
>>> Hi!
>>>
>>> Ugh. This became more complicated than I thought, but I'm OK with moving
>>> TTM over to fence while we sort out
>>> how / if we
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/380dc5fc/attachment-0001.html>
Hi Rahul,
On 02.04.2014 19:13, Rahul Sharma wrote:
> From: Rahul Sharma
>
> Exynos drm hdmi driver used to get dummy hdmiphy clock to
> control the PMU bit for hdmiphy. This clock is removed
> during CCF migration. This should also be cleaned from
> hdmi driver.
>
> Signed-off-by: Rahul Sharma
>
-
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/5ebd0bb9/attachment.html>
On Thu, Apr 10, 2014 at 9:08 AM, Lauri Kasanen wrote:
> This was originally un-inlined by Andi Kleen in 2011 citing size concerns.
> Indeed, inlining it grows radeon.ko by 7%.
>
> However, 2% of cpu is spent in this function. Inlining it gives 1% more fps
> in Urban Terror.
>
> Signed-off-by: Laur
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/568c44b0/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140410/bf8b06cd/attachment.html>
Hi Rahul,
On 02.04.2014 19:13, Rahul Sharma wrote:
> From: Rahul Sharma
>
> Hdmiphy control bit needs to be set before setting the resolution
> to hdmi hardware. This was handled using dummy hdmiphy clock which
> is removed now.
>
> PMU is already defined as system controller for exynos SoC. Regi
On 02.04.2014 19:13, Rahul Sharma wrote:
> From: Rahul Sharma
>
> Cleaning up unnecessary i2c read call after hdmiphy configuration.
> This check is redundant since check for hdmiphy pll lock status
> confirms the correct settings for phy.
>
> Signed-off-by: Rahul Sharma
> Signed-off-by: Daniel K
On Wed, Apr 9, 2014 at 1:40 PM, Thierry Reding
wrote:
> diff --git a/tegra/fence.c b/tegra/fence.c
> new file mode 100644
> index ..f58725ca8472
> --- /dev/null
> +++ b/tegra/fence.c
> +drm_public
> +int drm_tegra_fence_wait(struct drm_tegra_fence *fence)
> +{
> + return drm_teg
On Wed, Apr 9, 2014 at 1:40 PM, Thierry Reding
wrote:
> diff --git a/libdrm.h b/libdrm.h
> new file mode 100644
> index ..23926e6f6741
> --- /dev/null
> +++ b/libdrm.h
> @@ -0,0 +1,34 @@
> +/*
> + * Copyright ? 2014 NVIDIA Corporation
> + *
> + * Permission is hereby granted, free of
Hi Rahul,
On 02.04.2014 19:13, Rahul Sharma wrote:
> From: Rahul Sharma
>
> Previous SoCs have hdmi phys which are accessible through
> dedicated i2c lines. Newer SoCs have Apb mapped hdmi phys.
> Hdmi driver is modified to support apb mapped phys.
>
> Signed-off-by: Rahul Sharma
> ---
> drive
On Wed, Apr 9, 2014 at 1:40 PM, Thierry Reding
wrote:
> From: Thierry Reding
>
> Add the libdrm_tegra helper library to encapsulate Tegra-specific
> interfaces to the DRM.
>
> Furthermore, Tegra is added to the list of supported chips in the
> modetest and vbltest programs.
>
> Signed-off-by: Th
On Wed, Apr 9, 2014 at 1:40 PM, Thierry Reding
wrote:
> From: Thierry Reding
>
> This test opens a device, dumps the version information and checks that
> a Tegra DRM context can be opened on it.
>
> Signed-off-by: Thierry Reding
Looks good!
On Wed, Apr 9, 2014 at 1:40 PM, Thierry Reding
wrote:
> diff --git a/tests/tegra/gr2d-fill.c b/tests/tegra/gr2d-fill.c
> new file mode 100644
> index ..b6ba35a9d668
> --- /dev/null
> +++ b/tests/tegra/gr2d-fill.c
> @@ -0,0 +1,146 @@
> +/*
> + * Copyright ? 2014 NVIDIA Corporation
> +
attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/59ff658e/attachment.html>
On Wed, Apr 9, 2014 at 1:40 PM, Thierry Reding
wrote:
> From: Thierry Reding
>
> This library provides helpers for common functionality needed by test
> programs.
>
> Signed-off-by: Thierry Reding
> ---
> Changes in v2:
> - fix a couple of memory leaks and get rid of some unneeded code
>
> tes
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/48aa7175/attachment.html>
-
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/56e30573/attachment-0001.html>
org/archives/dri-devel/attachments/20140410/46d5eeec/attachment.html>
On Thu, 10 Apr 2014 12:19:10 -0400
Ilia Mirkin wrote:
> > +static inline uint32_t r100_mm_rreg(struct radeon_device *rdev, uint32_t
> > reg,
> > + bool always_indirect)
> > +{
> > + if (reg < rdev->rmmio_size && !always_indirect)
> > + return
On Thu, Apr 10, 2014 at 2:46 PM, Lauri Kasanen wrote:
> On Thu, 10 Apr 2014 12:19:10 -0400
> Ilia Mirkin wrote:
>
>> > +static inline uint32_t r100_mm_rreg(struct radeon_device *rdev, uint32_t
>> > reg,
>> > + bool always_indirect)
>> > +{
>> > + if (reg <
ssignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/b6be7ea7/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/959c434e/attachment.html>
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/35a63a1a/attachment.html>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Libdrm 2.4.53 has been released.
Emil Velikov (1):
freedreno: do not leak drmVersion
Fran?ois Tigeot (1):
Enable libkms by default on DragonFly
Lucas Stach (1):
modeprint: pretty print connector names
Marek Ol??k (2):
radeo
Am 10.04.2014 20:52, schrieb Ilia Mirkin:
> On Thu, Apr 10, 2014 at 2:46 PM, Lauri Kasanen wrote:
>> On Thu, 10 Apr 2014 12:19:10 -0400
>> Ilia Mirkin wrote:
>>
+static inline uint32_t r100_mm_rreg(struct radeon_device *rdev, uint32_t
reg,
+ bool
Hello Andreas,
after pulling and rebooting my machine this morning, nouveau was no
longer working:
[6.455247] nouveau [ DEVICE][:02:00.0] BOOT0 : 0x0ac080b1
[6.455312] nouveau [ DEVICE][:02:00.0] Chipset: MCP79/MCP7A (NVAC)
[6.455374] nouveau [ DEVICE][:02:00.0] Fami
---
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/dec5cde4/attachment.sig>
On 04/02/2014 06:38 AM, Konstantin Khlebnikov wrote:
> On Wed, Mar 19, 2014 at 11:06 PM, David Herrmann
> wrote:
>> memfd_create() is similar to mmap(MAP_ANON), but returns a file-descriptor
>> that you can pass to mmap(). It explicitly allows sealing and
>> avoids any connection to user-visible
On 03/20/2014 09:38 AM, tytso at mit.edu wrote:
> On Thu, Mar 20, 2014 at 04:48:30PM +0100, David Herrmann wrote:
>> On Thu, Mar 20, 2014 at 4:32 PM, wrote:
>>> Why not make sealing an attribute of the "struct file", and enforce it
>>> at the VFS layer? That way all file system objects would hav
On 04/08/2014 06:00 AM, Florian Weimer wrote:
> On 03/19/2014 08:06 PM, David Herrmann wrote:
>
>> Unlike existing techniques that provide similar protection, sealing
>> allows
>> file-sharing without any trust-relationship. This is enforced by
>> rejecting seal
>> modifications if you don't own a
Recently, Exynos DP driver was moved from drivers/video/exynos/
directory to drivers/gpu/drm/exynos/ directory. So, I update
and add maintainer entry for Exynos DP driver.
Signed-off-by: Jingoo Han
---
MAINTAINERS |6 ++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAI
On Thu, Mar 20, 2014 at 11:32 AM, tytso at mit.edu wrote:
>
> Looking at your patches, and what files you are modifying, you are
> enforcing this in the low-level file system.
I would love for this to be implemented in the filesystem level as
well. Something like the ext4 immutable bit, but wit
On 04/10/2014 07:45 AM, Colin Walters wrote:
> On Thu, Mar 20, 2014 at 11:32 AM, tytso at mit.edu wrote:
>>
>> Looking at your patches, and what files you are modifying, you are
>> enforcing this in the low-level file system.
>
> I would love for this to be implemented in the filesystem level as
>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/d424c842/attachment-0001.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/ff779190/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/7df7cc73/attachment.html>
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/29e573e2/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/ce997ce6/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/2e188999/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/3528cc3c/attachment.html>
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/813ab94c/attachment.html>
u are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/c52ec9b9/attachment-0001.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140410/133f3d50/attachment.html>
vel/attachments/20140410/0f83b096/attachment.html>
res.
If the fix from that bug does it, you can mark this as a duplicate.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/d409cff6/attachment.html>
On Thu, Apr 10, 2014 at 12:14:27PM -0700, Andy Lutomirski wrote:
>
> This is the second time in a week that someone has asked for a way to
> have a struct file (or struct inode or whatever) that can't be reopened
> through /proc/pid/fd. This should be quite easy to implement as a
> separate featu
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/77837bf9/attachment.html>
Hi
On Thu, Apr 10, 2014 at 10:37 PM, Andy Lutomirski
wrote:
> It occurs to me that, before going nuts with these kinds of flags, it
> may pay to just try to fix the /proc/self/fd issue for real -- we
> could just make open("/proc/self/fd/3", O_RDWR) fail if fd 3 is
> read-only. That may be enou
s in the game play over time.
That symptom at least is still present.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/2
hment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/3d170444/attachment.html>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/a33e09af/attachment.html>
The src_w / src_h parameters to update_plane include a subpixel offset;
we need to shift off the subpixel bits before comparing to CRTC size
when checking for primary plane scaling.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/drm_plane_helper.c | 2 ++
1 file changed, 2 insertions(+)
diff --g
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/ba04cd3a/attachment.html>
Signed-off-by: Matt Roper
---
include/drm/drm.h | 8
xf86drmMode.h | 4
2 files changed, 12 insertions(+)
diff --git a/include/drm/drm.h b/include/drm/drm.h
index f0b4c16..229a29f 100644
--- a/include/drm/drm.h
+++ b/include/drm/drm.h
@@ -627,6 +627,14 @@ struct drm_get_cap {
stable?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/23121b65/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/4e91cc30/attachment.html>
receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/5e37ae02/attachment-0001.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/2099034b/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/b516a0c3/attachment.html>
own? E.g., change 157500
to:
15
10
8
5
3
etc.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140
nts/20140410/a804cf38/attachment.html>
on (even though it was being used
before suspend)
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/cdcc65ea/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/1e295df7/attachment.html>
e max and disabling any other changes?
Thanks
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140410/c11952a7/attachment.html>
dri-devel/attachments/20140410/1e1d61a1/attachment.html>
Don't try and runtime suspend the APU in PX systems. We
only want to power down the dGPU.
v2: fix harder
v3: fix stupid typo
v4: consolidate runpm enablement to a single flag
bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=75127
https://bugzilla.kernel.org/show_bug.cgi?id=72701
Signed-off-by
As per internal recommendations.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/ci_dpm.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ci_dpm.c b/drivers/gpu/drm/radeon/ci_dpm.c
index cad89a9..f92ac5e 100644
--- a/d
Setting higher mclks seems to cause stability issues
on some R7 260X boards. Disable it for now for stability
until we find a proper fix.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=75992
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/ci_dpm.c | 4 ++
Colin Walters wrote:
> On Thu, Apr 10, 2014 at 3:15 PM, Andy Lutomirski
> wrote:
>>
>>
>> COW links can do this already, I think. Of course, you'll have to
>> use a
>> filesystem that supports them.
>
> COW is nice if the filesystem supports them, but my userspace code
> needs to be filesyste
On Thu, Apr 10, 2014 at 3:15 PM, Andy Lutomirski
wrote:
>
>
> COW links can do this already, I think. Of course, you'll have to
> use a
> filesystem that supports them.
COW is nice if the filesystem supports them, but my userspace code
needs to be filesystem agnostic. Because of that, the
On Thu, Apr 10, 2014 at 1:32 PM, Theodore Ts'o wrote:
> On Thu, Apr 10, 2014 at 12:14:27PM -0700, Andy Lutomirski wrote:
>>
>> This is the second time in a week that someone has asked for a way to
>> have a struct file (or struct inode or whatever) that can't be reopened
>> through /proc/pid/fd.
The list of machines in the "Use native backlight" table is getting longer
and longer, which is a solid indication that we're doing something wrong.
Disable the ACPI backlight interface if the system claims to be Windows 8
or later.
Signed-off-by: Matthew Garrett
---
Let's at least get this into
On Thu, Apr 10, 2014 at 1:49 PM, David Herrmann
wrote:
> Hi
>
> On Thu, Apr 10, 2014 at 10:37 PM, Andy Lutomirski
> wrote:
>> It occurs to me that, before going nuts with these kinds of flags, it
>> may pay to just try to fix the /proc/self/fd issue for real -- we
>> could just make open("/proc
(reposted from my comments at http://lwn.net/Articles/593918/)
I may have thought of a way to subvert SEAL_WRITE using O_DIRECT and
asynchronous I/O. I am not sure if this is a real problem or not, but
better to ask, right?
The exploit would go like this:
1) mmap() the shared memory
2) open som
On Thu, Apr 10, 2014 at 3:57 PM, David Herrmann
wrote:
> Hi
>
> On Thu, Apr 10, 2014 at 11:16 PM, Andy Lutomirski
> wrote:
>> Would it make sense for the initial mode on a memfd inode to be 000?
>> Anyone who finds this to be problematic could use fchmod to fix it.
>
> memfd_create() should be
1 - 100 of 102 matches
Mail list logo
