* [GIT PULL RESEND] kselftest-3.20-rc1 (4.0-rc1)
From: Shuah Khan @ 2015-02-23 19:23 UTC (permalink / raw)
To: torvalds; +Cc: linux-kernel, Shuah Khan, linux-api
Hi Linus,
I sent the following pull request in time for rc-1. I didn't see
it included in 4.0-rc1. Wondering what happened? Resending just
in case it got lost.
thanks,
-- Shuah
The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672:
Linux 3.19-rc1 (2014-12-20 17:08:50 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
tags/linux-kselftest-3.20-rc1
for you to fetch changes up to 6ddf898c23d62c974e148efd9e509731324a167a:
selftests/exec: Check if the syscall exists and bail if not
(2015-02-04 10:17:35 -0700)
----------------------------------------------------------------
Kselftest updates for 3.20-rc1
This update adds:
- Kselftest install target feature
- Fix for selftests/exec test
----------------------------------------------------------------
Michael Ellerman (1):
selftests/exec: Check if the syscall exists and bail if not
Shuah Khan (20):
selftests/breakpoints: add install target to enable test install
selftests/cpu-hotplug: add install target to enable test install
selftests/efivarfs: add install target to enable test install
selftests/firmware: add install target to enable test install
selftests/ftrace: add install target to enable test install
selftests/ipc: add install target to enable test install
selftests/kcmp: add install target to enable test install
selftests/memfd: add install target to enable test install
selftests/memory-hotplug: add install target to enable test install
selftests/mount: add install target to enable test install
selftests/mqueue: add install target to enable test install
selftests/net: add install target to enable test install
selftests/ptrace: add install target to enable test install
selftests/size: add install target to enable test install
selftests/sysctl: add install target to enable test install
selftests/timers: add install target to enable test install
selftests/user: add install target to enable test install
selftests/vm: add install target to enable test install
selftests: add install target to enable test install
kbuild: add a new kselftest_install make target to install selftests
Makefile | 14 +++++-
tools/testing/selftests/Makefile | 54
+++++++++++++++++++++-
tools/testing/selftests/breakpoints/Makefile | 19 +++++++-
tools/testing/selftests/cpu-hotplug/Makefile | 14 +++++-
.../{on-off-test.sh => cpu-on-off-test.sh} | 0
tools/testing/selftests/efivarfs/Makefile | 16 ++++++-
tools/testing/selftests/exec/execveat.c | 10 +++-
tools/testing/selftests/firmware/Makefile | 43 ++++++++++-------
tools/testing/selftests/ftrace/Makefile | 13 +++++-
tools/testing/selftests/ipc/Makefile | 19 +++++++-
tools/testing/selftests/kcmp/Makefile | 13 +++++-
tools/testing/selftests/memfd/Makefile | 17 +++++--
tools/testing/selftests/memory-hotplug/Makefile | 14 +++++-
.../{on-off-test.sh => mem-on-off-test.sh} | 0
tools/testing/selftests/mount/Makefile | 12 ++++-
tools/testing/selftests/mqueue/Makefile | 18 ++++++--
tools/testing/selftests/net/Makefile | 20 ++++++--
tools/testing/selftests/ptrace/Makefile | 16 +++++--
tools/testing/selftests/size/Makefile | 12 ++++-
tools/testing/selftests/sysctl/Makefile | 17 ++++++-
tools/testing/selftests/timers/Makefile | 12 ++++-
tools/testing/selftests/user/Makefile | 12 ++++-
tools/testing/selftests/vm/Makefile | 11 ++++-
23 files changed, 326 insertions(+), 50 deletions(-)
rename tools/testing/selftests/cpu-hotplug/{on-off-test.sh =>
cpu-on-off-test.sh} (100%)
rename tools/testing/selftests/memory-hotplug/{on-off-test.sh =>
mem-on-off-test.sh} (100%)
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shuahkh@osg.samsung.com | (970) 217-8978
^ permalink raw reply
* Re: [PATCH v3 linux-trace 1/8] tracing: attach eBPF programs to tracepoints and syscalls
From: Alexei Starovoitov @ 2015-02-23 18:55 UTC (permalink / raw)
To: He Kuang
Cc: Steven Rostedt, Ingo Molnar, Namhyung Kim,
Arnaldo Carvalho de Melo, Jiri Olsa, Masami Hiramatsu, Linux API,
Network Development, LKML, Linus Torvalds, Peter Zijlstra,
Eric W. Biederman, wangnan0-hv44wF8Li93QT0dZR+AlfA
On Mon, Feb 16, 2015 at 6:26 AM, He Kuang <hekuang-hv44wF8Li93QT0dZR+AlfA@public.gmane.org> wrote:
> Hi, Alexei
>
> Another suggestion on bpf syscall interface. Currently, BPF +
> syscalls/kprobes depends on CONFIG_BPF_SYSCALL. In kernel used on
> commercial products, CONFIG_BPF_SYSCALL is probably disabled, in this
> case, bpf bytecode cannot be loaded to the kernel.
I'm seeing a flurry of use cases for bpf in ovs, tc, tracing, etc
When it's all ready, we can turn that config on by default.
> If we turn the functionality of BPF_SYSCALL into a loadable module, then
> we can use it without any dependencies on the kernel. What about change
> bpf syscall to a /dev node or /sys file which can be exported by a
> kernel module?
I don't think we will allow extending bpf by modules.
'bpf in modules' is an interface that is too easy to abuse.
So all of bpf core, helper functions and program types will be builtin.
As far as bpf+tracing the plan is to do bpf+kprobe and bpf+syscalls
first. Then add right set of helpers to make sure that use cases
like 'tcp stack instrumentation' are fully addressed.
Then there were few great ideas of accelerating kprobes
with trace markers and debug tracepoints that we can do later.
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Christoph Lameter @ 2015-02-23 18:27 UTC (permalink / raw)
To: Serge Hallyn
Cc: Serge E. Hallyn, Serge Hallyn, Andy Lutomirski, Aaron Jones,
Ted Ts'o, linux-security-module, akpm, Andrew G. Morgan,
Mimi Zohar, Austin S Hemmelgarn, Markku Savela, Jarkko Sakkinen,
linux-kernel, linux-api, Michael Kerrisk, Jonathan Corbet
In-Reply-To: <20150223181553.GE25477@ubuntumail>
On Mon, 23 Feb 2015, Serge Hallyn wrote:
> > So the cap was dropped from the cap perm set but it is still active
> > in the ambient set?
>
> Right, and the legacy program doesn't know to check the new set.
Does it have to? The ambient set could not show up in permitted.
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Serge Hallyn @ 2015-02-23 18:15 UTC (permalink / raw)
To: Christoph Lameter
Cc: Serge E. Hallyn, Serge Hallyn, Andy Lutomirski, Aaron Jones,
Ted Ts'o, linux-security-module, akpm, Andrew G. Morgan,
Mimi Zohar, Austin S Hemmelgarn, Markku Savela, Jarkko Sakkinen,
linux-kernel, linux-api, Michael Kerrisk, Jonathan Corbet
In-Reply-To: <alpine.DEB.2.11.1502231049110.21926@gentwo.org>
Quoting Christoph Lameter (cl@linux.com):
> On Mon, 23 Feb 2015, Serge E. Hallyn wrote:
>
> > > I do not see a problem with dropping privilege since the ambient set
> > > is supposed to be preserved across a drop of priviledge.
> >
> > Because you're tricking the program into thinking it has dropped
> > the privilege, when in fact it has not.
>
> So the cap was dropped from the cap perm set but it is still active
> in the ambient set?
Right, and the legacy program doesn't know to check the new set.
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Christoph Lameter @ 2015-02-23 16:50 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Serge Hallyn, Serge Hallyn, Andy Lutomirski, Aaron Jones,
Ted Ts'o, linux-security-module, akpm, Andrew G. Morgan,
Mimi Zohar, Austin S Hemmelgarn, Markku Savela, Jarkko Sakkinen,
linux-kernel, linux-api, Michael Kerrisk, Jonathan Corbet
In-Reply-To: <20150223164623.GB32181@mail.hallyn.com>
On Mon, 23 Feb 2015, Serge E. Hallyn wrote:
> > I do not see a problem with dropping privilege since the ambient set
> > is supposed to be preserved across a drop of priviledge.
>
> Because you're tricking the program into thinking it has dropped
> the privilege, when in fact it has not.
So the cap was dropped from the cap perm set but it is still active
in the ambient set?
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Christoph Lameter @ 2015-02-23 16:47 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Serge Hallyn, Serge Hallyn, Aaron Jones, Ted Ts'o, LSM List,
Andrew Morton, Andrew G. Morgan, Mimi Zohar, Austin S Hemmelgarn,
Markku Savela, Jarkko Sakkinen, linux-kernel@vger.kernel.org,
Linux API, Michael Kerrisk, Jonathan Corbet
In-Reply-To: <CALCETrW78805ayUL=ZYBdFwVdDvJZus2JL0VVmEBE8=L1Nm5Sw@mail.gmail.com>
On Mon, 23 Feb 2015, Andy Lutomirski wrote:
> Is there really a need to drop privilege and then regain it or is it
> sufficient to keep the privilege permitted (and perhaps ambient, too)
> and just to have execve not drop it for you? I assume the latter.
I would think just keep the ambient set active as long as there is no
prctl switching the cap off in the child processes. Do not let it be
affected by the usual drop privs stuff.
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Serge E. Hallyn @ 2015-02-23 16:46 UTC (permalink / raw)
To: Christoph Lameter
Cc: Serge Hallyn, Serge Hallyn, Andy Lutomirski, Aaron Jones,
Ted Ts'o, linux-security-module, akpm, Andrew G. Morgan,
Mimi Zohar, Austin S Hemmelgarn, Markku Savela, Jarkko Sakkinen,
linux-kernel, linux-api, Michael Kerrisk, Jonathan Corbet
In-Reply-To: <alpine.DEB.2.11.1502231041580.21784@gentwo.org>
On Mon, Feb 23, 2015 at 10:44:32AM -0600, Christoph Lameter wrote:
> On Mon, 23 Feb 2015, Serge Hallyn wrote:
>
> > The core concern for amorgan is that an unprivileged user not be
> > able to cause a privileged program to run in a way that it fails to
> > drop privilege before running unprivileged-user-provided code.
>
> I do not see a problem with dropping privilege since the ambient set
> is supposed to be preserved across a drop of priviledge.
Because you're tricking the program into thinking it has dropped
the privilege, when in fact it has not.
> > Since your desire is precisely for a mode where dropping privilege
> > works as usual, but exec then re-gains some or all of that privilege,
>
> I would say that the ambient set stays active even if the setuid binary
> drops to regular perms.
>
> > we need to either agree on a way to enter that mode that ordinary
> > use caes can't be tricked into using, or find a way for legacy
> > users to be tpiped off as to what's going on (without having to be
> > re-written)
>
> Well if the ambient set is completely separate then the existing
> semantics are preserved while the ambient set stays active as intended.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Serge E. Hallyn @ 2015-02-23 16:45 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Serge Hallyn, Christoph Lameter, Serge Hallyn, Aaron Jones,
Ted Ts'o, LSM List, Andrew Morton, Andrew G. Morgan,
Mimi Zohar, Austin S Hemmelgarn, Markku Savela, Jarkko Sakkinen,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux API,
Michael Kerrisk, Jonathan Corbet
In-Reply-To: <CALCETrW78805ayUL=ZYBdFwVdDvJZus2JL0VVmEBE8=L1Nm5Sw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Feb 23, 2015 at 08:33:58AM -0800, Andy Lutomirski wrote:
> On Mon, Feb 23, 2015 at 8:16 AM, Serge Hallyn <serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org> wrote:
> > Quoting Christoph Lameter (cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org):
> >> Ok 4.0-rc1 is out and this patch has been sitting here for a couple of
> >> weeks without comment after an intensive discussion about the RFCs.
> >>
> >> Since there were no objections: Is there any chance to get this into -next
> >> somehow?
> >
> > Andrew Morgan and Andy Lutomirski appear to have a similar concern
> > but competing ideas on how to address them. We need them to agree
> > on an approach.
> >
> > The core concern for amorgan is that an unprivileged user not be
> > able to cause a privileged program to run in a way that it fails to
> > drop privilege before running unprivileged-user-provided code.
> >
> > Andy Lutomirski's concern is simply that code which is currently
> > doing the right thing to drop privilege not be run in a way that
> > it thinks it is dropping privilege, but in fact is not.
> >
>
> I share both concerns.
>
> > (Please correct me where I've mis-spoken or misunderstood)
> >
> > Since your desire is precisely for a mode where dropping privilege
> > works as usual, but exec then re-gains some or all of that privilege,
> > we need to either agree on a way to enter that mode that ordinary
> > use caes can't be tricked into using, or find a way for legacy
> > users to be tpiped off as to what's going on (without having to be
> > re-written)
>
> Is there really a need to drop privilege and then regain it or is it
> sufficient to keep the privilege permitted (and perhaps ambient, too)
> and just to have execve not drop it for you? I assume the latter.
Well right, any perceived security benefit of the temporary drop would
seem to be easily debunked (just run shell for exec /bin/sh to get
around it)
So this is more of a desire, I suspect, for regular programs which
drop privilege to still be usable in this environment.
I think this may be a decent place for a compromise. Attempts to
drop privilege when ambient caps are set return EPERM.
-serge
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Christoph Lameter @ 2015-02-23 16:44 UTC (permalink / raw)
To: Serge Hallyn
Cc: Serge Hallyn, Andy Lutomirski, Aaron Jones, Ted Ts'o,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
akpm-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, Andrew G. Morgan,
Mimi Zohar, Austin S Hemmelgarn, Markku Savela, Jarkko Sakkinen,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, Michael Kerrisk,
Jonathan Corbet
In-Reply-To: <20150223161625.GD25477@ubuntumail>
On Mon, 23 Feb 2015, Serge Hallyn wrote:
> The core concern for amorgan is that an unprivileged user not be
> able to cause a privileged program to run in a way that it fails to
> drop privilege before running unprivileged-user-provided code.
I do not see a problem with dropping privilege since the ambient set
is supposed to be preserved across a drop of priviledge.
> Since your desire is precisely for a mode where dropping privilege
> works as usual, but exec then re-gains some or all of that privilege,
I would say that the ambient set stays active even if the setuid binary
drops to regular perms.
> we need to either agree on a way to enter that mode that ordinary
> use caes can't be tricked into using, or find a way for legacy
> users to be tpiped off as to what's going on (without having to be
> re-written)
Well if the ambient set is completely separate then the existing
semantics are preserved while the ambient set stays active as intended.
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Christoph Lameter @ 2015-02-23 16:41 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Serge Hallyn, Aaron Jones, Ted Ts'o, LSM List, Andrew Morton,
Andrew G. Morgan, Mimi Zohar, Austin S Hemmelgarn, Markku Savela,
Jarkko Sakkinen, linux-kernel@vger.kernel.org, Linux API,
Michael Kerrisk, Jonathan Corbet
In-Reply-To: <CALCETrUR7+44ie2fiy0BzC3ktLQ2dcArSL-O3AHnp8kFF92fjg@mail.gmail.com>
On Mon, 23 Feb 2015, Andy Lutomirski wrote:
> If you set ambient caps and then run a setuid program (without
> no_new_privs), then the ambient set *must* be cleared by the kernel
> because that's what the setuid program expects. Yes, the whole
Why would a setuid program expect that? I'd say we expect the ambient set
to remain in effect. What would break if the ambient set would stay
active?
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Andy Lutomirski @ 2015-02-23 16:33 UTC (permalink / raw)
To: Serge Hallyn
Cc: Christoph Lameter, Serge Hallyn, Aaron Jones, Ted Ts'o,
LSM List, Andrew Morton, Andrew G. Morgan, Mimi Zohar,
Austin S Hemmelgarn, Markku Savela, Jarkko Sakkinen,
linux-kernel@vger.kernel.org, Linux API, Michael Kerrisk,
Jonathan Corbet
In-Reply-To: <20150223161625.GD25477@ubuntumail>
On Mon, Feb 23, 2015 at 8:16 AM, Serge Hallyn <serge.hallyn@ubuntu.com> wrote:
> Quoting Christoph Lameter (cl@linux.com):
>> Ok 4.0-rc1 is out and this patch has been sitting here for a couple of
>> weeks without comment after an intensive discussion about the RFCs.
>>
>> Since there were no objections: Is there any chance to get this into -next
>> somehow?
>
> Andrew Morgan and Andy Lutomirski appear to have a similar concern
> but competing ideas on how to address them. We need them to agree
> on an approach.
>
> The core concern for amorgan is that an unprivileged user not be
> able to cause a privileged program to run in a way that it fails to
> drop privilege before running unprivileged-user-provided code.
>
> Andy Lutomirski's concern is simply that code which is currently
> doing the right thing to drop privilege not be run in a way that
> it thinks it is dropping privilege, but in fact is not.
>
I share both concerns.
> (Please correct me where I've mis-spoken or misunderstood)
>
> Since your desire is precisely for a mode where dropping privilege
> works as usual, but exec then re-gains some or all of that privilege,
> we need to either agree on a way to enter that mode that ordinary
> use caes can't be tricked into using, or find a way for legacy
> users to be tpiped off as to what's going on (without having to be
> re-written)
Is there really a need to drop privilege and then regain it or is it
sufficient to keep the privilege permitted (and perhaps ambient, too)
and just to have execve not drop it for you? I assume the latter.
--Andy
^ permalink raw reply
* Re: Documenting MS_LAZYTIME
From: Eric Sandeen @ 2015-02-23 16:24 UTC (permalink / raw)
To: Austin S Hemmelgarn, Theodore Ts'o
Cc: Michael Kerrisk, Ext4 Developers List,
Linux btrfs Developers List, XFS Developers,
linux-man-u79uwXL29TY76Z2rM5mHXA, Linux-Fsdevel, Linux API
In-Reply-To: <54EB1B19.8050808-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On 2/23/15 6:20 AM, Austin S Hemmelgarn wrote:
> On 2015-02-20 21:56, Theodore Ts'o wrote:
>> On Fri, Feb 20, 2015 at 09:49:34AM -0600, Eric Sandeen wrote:
>>>
>>>> This mount option significantly reduces writes to the
>>>> inode table for workloads that perform frequent random
>>>> writes to preallocated files.
>>>
>>> This seems like an overly specific description of a single workload out
>>> of many which may benefit, but what do others think? "inode table" is also
>>> fairly extN-specific.
>>
>> How about somethign like "This mount significantly reduces writes
>> needed to update the inode's timestamps, especially mtime and actime.
>> Examples of workloads where this could be a large win include frequent
>> random writes to preallocated files, as well as cases where the
>> MS_STRICTATIME mount option is enabled."?
>>
>> (The advantage of MS_STRICTATIME | MS_LAZYTIME is that stat system
>> calls will return the correctly updated atime, but those atime updates
>> won't get flushed to disk unless the inode needs to be updated for
>> file system / data consistency reasons, or when the inode is pushed
>> out of memory, or when the file system is unmounted.)
>>
> If you want to list some specific software, it should help with
> anything that uses sqlite (which notably includes firefox and
> chrome), as well as most RDMS software and systemd-journald.
I'm really uneasy with starting to list specific workloads and applications
here. It's going to get dated quickly, and will lead to endless cargo-cult
tuning.
I'd strongly prefer to just describe what it does (reduces the number of
certain metadata writes to disk) and leave it at that....
-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Serge Hallyn @ 2015-02-23 16:16 UTC (permalink / raw)
To: Christoph Lameter
Cc: Serge Hallyn, Andy Lutomirski, Aaron Jones, Ted Ts'o,
linux-security-module, akpm, Andrew G. Morgan, Mimi Zohar,
Austin S Hemmelgarn, Markku Savela, Jarkko Sakkinen, linux-kernel,
linux-api, Michael Kerrisk, Jonathan Corbet
In-Reply-To: <alpine.DEB.2.11.1502230856400.21238@gentwo.org>
Quoting Christoph Lameter (cl@linux.com):
> Ok 4.0-rc1 is out and this patch has been sitting here for a couple of
> weeks without comment after an intensive discussion about the RFCs.
>
> Since there were no objections: Is there any chance to get this into -next
> somehow?
Andrew Morgan and Andy Lutomirski appear to have a similar concern
but competing ideas on how to address them. We need them to agree
on an approach.
The core concern for amorgan is that an unprivileged user not be
able to cause a privileged program to run in a way that it fails to
drop privilege before running unprivileged-user-provided code.
Andy Lutomirski's concern is simply that code which is currently
doing the right thing to drop privilege not be run in a way that
it thinks it is dropping privilege, but in fact is not.
(Please correct me where I've mis-spoken or misunderstood)
Since your desire is precisely for a mode where dropping privilege
works as usual, but exec then re-gains some or all of that privilege,
we need to either agree on a way to enter that mode that ordinary
use caes can't be tricked into using, or find a way for legacy
users to be tpiped off as to what's going on (without having to be
re-written)
-serge
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Andy Lutomirski @ 2015-02-23 15:59 UTC (permalink / raw)
To: Christoph Lameter
Cc: Serge Hallyn, Aaron Jones, Ted Ts'o, LSM List, Andrew Morton,
Andrew G. Morgan, Mimi Zohar, Austin S Hemmelgarn, Markku Savela,
Jarkko Sakkinen, linux-kernel@vger.kernel.org, Linux API,
Michael Kerrisk, Jonathan Corbet
In-Reply-To: <alpine.DEB.2.11.1502230950440.21238@gentwo.org>
On Mon, Feb 23, 2015 at 7:53 AM, Christoph Lameter <cl@linux.com> wrote:
> On Mon, 23 Feb 2015, Andy Lutomirski wrote:
>
>> At the very least, I think it needs to define and implement what
>> happens when a cap is added to ambient and then dropped from
>> permitted. We also may need LSM_UNSAFE_something to clear the ambient
>> set to avoid a major security issue.
>
> The ambient cap needs to stay otherwise we will have issues again if
> another binary/script is forked. IMHO the only way to switch off an
> ambient capability should be another prctl action. The intend is after all
> to have the cap available for all inherited processes.
No, sadly.
If you set ambient caps and then run a setuid program (without
no_new_privs), then the ambient set *must* be cleared by the kernel
because that's what the setuid program expects. Yes, the whole
concept of setuid is daft, but it exists and we have to keep it
working safely, or at least as safely as it ever worked.
--Andy
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Christoph Lameter @ 2015-02-23 15:53 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Serge Hallyn, Aaron Jones, Ted Ts'o, LSM List, Andrew Morton,
Andrew G. Morgan, Mimi Zohar, Austin S Hemmelgarn, Markku Savela,
Jarkko Sakkinen,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux API,
Michael Kerrisk, Jonathan Corbet
In-Reply-To: <CALCETrWJCcBBGGp21C4cdtiU79K-P3t+6rFJUWcXcLR1jqrrFQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, 23 Feb 2015, Andy Lutomirski wrote:
> At the very least, I think it needs to define and implement what
> happens when a cap is added to ambient and then dropped from
> permitted. We also may need LSM_UNSAFE_something to clear the ambient
> set to avoid a major security issue.
The ambient cap needs to stay otherwise we will have issues again if
another binary/script is forked. IMHO the only way to switch off an
ambient capability should be another prctl action. The intend is after all
to have the cap available for all inherited processes.
Frankly, I'd rather have the ambient caps separate. We could do a stronger
separation by checking for permitted or ambient in capable().
> I'd like to discuss (in the hallway if nothing else) at LSF/MM with
> whatever other interested people will be there.
Ok. I will be at the MM meeting in Boston. 8th and 9th of March.
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Andy Lutomirski @ 2015-02-23 15:44 UTC (permalink / raw)
To: Christoph Lameter
Cc: Serge Hallyn, Aaron Jones, Ted Ts'o, LSM List, Andrew Morton,
Andrew G. Morgan, Mimi Zohar, Austin S Hemmelgarn, Markku Savela,
Jarkko Sakkinen, linux-kernel@vger.kernel.org, Linux API,
Michael Kerrisk, Jonathan Corbet
In-Reply-To: <alpine.DEB.2.11.1502230856400.21238@gentwo.org>
On Mon, Feb 23, 2015 at 6:58 AM, Christoph Lameter <cl@linux.com> wrote:
> Ok 4.0-rc1 is out and this patch has been sitting here for a couple of
> weeks without comment after an intensive discussion about the RFCs.
>
> Since there were no objections: Is there any chance to get this into -next
> somehow?
>
At the very least, I think it needs to define and implement what
happens when a cap is added to ambient and then dropped from
permitted. We also may need LSM_UNSAFE_something to clear the ambient
set to avoid a major security issue.
I'd like to discuss (in the hallway if nothing else) at LSF/MM with
whatever other interested people will be there.
--Andy
--
Andy Lutomirski
AMA Capital Management, LLC
^ permalink raw reply
* Re: [RFC PATCH 1/3] eeprom: Add a simple EEPROM framework
From: Srinivas Kandagatla @ 2015-02-23 15:38 UTC (permalink / raw)
To: Mark Brown
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Maxime Ripard,
Rob Herring, Pawel Moll, Kumar Gala,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Stephen Boyd, Arnd Bergmann,
Greg Kroah-Hartman
In-Reply-To: <20150223150415.GF6236-bheZrs9scGb3/WHNxyQH9YN0K6Il/+VY@public.gmane.org>
Thankyou for the comments.
On 23/02/15 15:04, Mark Brown wrote:
> On Thu, Feb 19, 2015 at 05:08:28PM +0000, Srinivas Kandagatla wrote:
>
>> .../devicetree/bindings/eeprom/eeprom.txt | 48 ++++
>> drivers/Kconfig | 2 +
>> drivers/Makefile | 1 +
>> drivers/eeprom/Kconfig | 19 ++
>> drivers/eeprom/Makefile | 9 +
>> drivers/eeprom/core.c | 290 +++++++++++++++++++++
>> include/linux/eeprom-consumer.h | 73 ++++++
>> include/linux/eeprom-provider.h | 51 ++++
>
> This seems to have a bunch of different things in it - there's some
> binding, there's some framework code, there's some user code for the
> framework... splitting it up more would probably help with review.
> I'd at least make sure the framework is split from the DT code, that
> will cut down on the bulk and help make sure the framework isn't too DT
> tied.
Yes I agree, will make sure that I split it into different patches in
next version.
>
>> + if (read)
>> + rc = regmap_bulk_read(eeprom->regmap, offset,
>> + buf, count/eeprom->stride);
>> + else
>> + rc = regmap_bulk_write(eeprom->regmap, offset,
>> + buf, count/eeprom->stride);
>> +
>> + if (IS_ERR_VALUE(rc))
>> + return 0;
>> +
>> + return count;
>> +}
>
>> +static ssize_t bin_attr_eeprom_read(struct file *filp, struct kobject *kobj,
>> + struct bin_attribute *attr,
>> + char *buf, loff_t offset, size_t count)
>> +{
>> + return bin_attr_eeprom_read_write(kobj, buf, offset, count, true);
>> +}
>
> I'm not sure the factoring out is actually helping the clarity here TBH.
>
ok.
>> +int eeprom_unregister(struct eeprom_device *eeprom)
>> +{
>> + device_del(&eeprom->edev);
>> +
>> + mutex_lock(&eeprom_list_mutex);
>> + list_del(&eeprom->list);
>> + mutex_unlock(&eeprom_list_mutex);
>> +
>> + return 0;
>> +}
>> +EXPORT_SYMBOL(eeprom_unregister);
>
> Here we return having dropped the lock without doing anything else with
> the eeprom, meaning the caller could delete it.
>
>> + mutex_lock(&eeprom_list_mutex);
>> +
>> + list_for_each_entry(e, &eeprom_list, list) {
>> + if (args.np == e->edev.of_node) {
>> + eeprom = e;
>> + break;
>> + }
>> + }
>> + mutex_unlock(&eeprom_list_mutex);
>
> Here we iterate the list, find the relevant eeprom and drop the lock
> while still holding a reference to the eeprom we just found. This means
> that a removal could race with us and free the eeprom underneath us.
> I'm also not seeing anything stopping or even noticing a device being
> removed with a cell active on it.
>
As suggested by Stephen Boyd reference counting on eeprom should ensure
safe removal of eeprom.
>> +/**
>> + * eeprom_cell_get(): Get eeprom cell of device form a given index.
>> + *
>> + * @dev: Device that will be interacted with
>> + * @index: Index of the eeprom cell.
>> + *
>> + * The return value will be an ERR_PTR() on error or a valid pointer
>> + * to a struct eeprom_cell. The eeprom_cell will be freed by the
>> + * eeprom_cell_put().
>> + */
>> +struct eeprom_cell *eeprom_cell_get(struct device *dev, int index);
>
> Normally the kerneldoc goes with the function definition, not the
> prototype.
Thats true, will fix it in next version.
>
^ permalink raw reply
* Re: [RFC PATCH 1/3] eeprom: Add a simple EEPROM framework
From: Mark Brown @ 2015-02-23 15:04 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Maxime Ripard,
Rob Herring, Pawel Moll, Kumar Gala,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Stephen Boyd, Arnd Bergmann,
Greg Kroah-Hartman
In-Reply-To: <1424365708-26681-1-git-send-email-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2967 bytes --]
On Thu, Feb 19, 2015 at 05:08:28PM +0000, Srinivas Kandagatla wrote:
> .../devicetree/bindings/eeprom/eeprom.txt | 48 ++++
> drivers/Kconfig | 2 +
> drivers/Makefile | 1 +
> drivers/eeprom/Kconfig | 19 ++
> drivers/eeprom/Makefile | 9 +
> drivers/eeprom/core.c | 290 +++++++++++++++++++++
> include/linux/eeprom-consumer.h | 73 ++++++
> include/linux/eeprom-provider.h | 51 ++++
This seems to have a bunch of different things in it - there's some
binding, there's some framework code, there's some user code for the
framework... splitting it up more would probably help with review.
I'd at least make sure the framework is split from the DT code, that
will cut down on the bulk and help make sure the framework isn't too DT
tied.
> + if (read)
> + rc = regmap_bulk_read(eeprom->regmap, offset,
> + buf, count/eeprom->stride);
> + else
> + rc = regmap_bulk_write(eeprom->regmap, offset,
> + buf, count/eeprom->stride);
> +
> + if (IS_ERR_VALUE(rc))
> + return 0;
> +
> + return count;
> +}
> +static ssize_t bin_attr_eeprom_read(struct file *filp, struct kobject *kobj,
> + struct bin_attribute *attr,
> + char *buf, loff_t offset, size_t count)
> +{
> + return bin_attr_eeprom_read_write(kobj, buf, offset, count, true);
> +}
I'm not sure the factoring out is actually helping the clarity here TBH.
> +int eeprom_unregister(struct eeprom_device *eeprom)
> +{
> + device_del(&eeprom->edev);
> +
> + mutex_lock(&eeprom_list_mutex);
> + list_del(&eeprom->list);
> + mutex_unlock(&eeprom_list_mutex);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(eeprom_unregister);
Here we return having dropped the lock without doing anything else with
the eeprom, meaning the caller could delete it.
> + mutex_lock(&eeprom_list_mutex);
> +
> + list_for_each_entry(e, &eeprom_list, list) {
> + if (args.np == e->edev.of_node) {
> + eeprom = e;
> + break;
> + }
> + }
> + mutex_unlock(&eeprom_list_mutex);
Here we iterate the list, find the relevant eeprom and drop the lock
while still holding a reference to the eeprom we just found. This means
that a removal could race with us and free the eeprom underneath us.
I'm also not seeing anything stopping or even noticing a device being
removed with a cell active on it.
> +/**
> + * eeprom_cell_get(): Get eeprom cell of device form a given index.
> + *
> + * @dev: Device that will be interacted with
> + * @index: Index of the eeprom cell.
> + *
> + * The return value will be an ERR_PTR() on error or a valid pointer
> + * to a struct eeprom_cell. The eeprom_cell will be freed by the
> + * eeprom_cell_put().
> + */
> +struct eeprom_cell *eeprom_cell_get(struct device *dev, int index);
Normally the kerneldoc goes with the function definition, not the
prototype.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [PATCH] capabilities: Ambient capability set V1
From: Christoph Lameter @ 2015-02-23 14:58 UTC (permalink / raw)
To: Serge Hallyn
Cc: Andy Lutomirski, Aaron Jones, Ted Ts'o,
linux-security-module-u79uwXL29TY76Z2rM5mHXA,
akpm-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r, Andrew G. Morgan,
Mimi Zohar, Austin S Hemmelgarn, Markku Savela, Jarkko Sakkinen,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, Michael Kerrisk,
Jonathan Corbet
In-Reply-To: <alpine.DEB.2.11.1502051554500.4876-gkYfJU5Cukgdnm+yROfE0A@public.gmane.org>
Ok 4.0-rc1 is out and this patch has been sitting here for a couple of
weeks without comment after an intensive discussion about the RFCs.
Since there were no objections: Is there any chance to get this into -next
somehow?
^ permalink raw reply
* Re: [PATCH 2/2] ASoC: pcm512x: Allow independently overclocking PLL, DAC and DSP
From: Mark Brown @ 2015-02-23 14:31 UTC (permalink / raw)
To: Peter Rosin
Cc: Peter Rosin, alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw@public.gmane.org,
Liam Girdwood, Jaroslav Kysela, Takashi Iwai, Lars-Peter Clausen,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <88616b158f38499fa5a466f31d25aa80-RtsSNOqGLlYRm0/ZmH0nkw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1392 bytes --]
On Sun, Feb 22, 2015 at 12:24:12AM +0000, Peter Rosin wrote:
> ...but I'm not sure everybody agrees that overclocking games should
> be allowed by any and all users?
I don't see why not, ASoC controls are already way beyond end user a lot
of the time.
> If you still want me to convert to ALSA controls, what control do you
> suggest? SOC_SINGLE_EXT? Or should I use an enumeration, because
> mixers tend to present volume controls as a percentage of max, which
> will be confusing: You are now at "volume" 75% (of max 40), when the
> value is 30. Eeek. But enumerations from 0% to 40% sounds tedious.
I'd just use a single value, it's a UI problem with the mixer and if the
control isn't called "Volume" that shouldn cause the UI to not present
it as a volume. He said hopefully.
Or possibly a binary control I guess which would have the nice side
effect of hiding from most non-specialist UIs.
> And how would you suggest that I name the controls?
> "Max Overclock DAC", "Max Overclock DSP" and "Max Overclock PLL"?
Those sound reasonable.
> BTW, the only troubles I've had with overclocking "too much" is that it
> has stopped working. I have not managed to fry any chip. But that is no
> guarantee, of course.
It's vanishingly unlikely that you'll cause physical damage with this
sort of thing, you're much more likely to hit performance and filter
problems than anything else.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] media: Fix ALSA and DVB representation at media controller API
From: Mauro Carvalho Chehab @ 2015-02-23 13:55 UTC (permalink / raw)
To: Devin Heitmueller
Cc: Hans Verkuil, Linux Media Mailing List, Mauro Carvalho Chehab,
Hans Verkuil, Sakari Ailus, Antti Palosaari, Ricardo Ribalda,
Marek Szyprowski, Ramakrishnan Muthukrishnan, Laurent Pinchart,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAGoCfiwi0nj_9sYNzEFOp5BvedFe+HphJ2bVtx_bnBw3d-Bsyw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Em Mon, 26 Jan 2015 09:41:41 -0500
Devin Heitmueller <dheitmueller-eb9eJ82Ua7k9XoPSrs7Ehg@public.gmane.org> escreveu:
> > It is actually trivial to get the device nodes once you have the
> > major/minor. The media-ctl library does that for you. See:
>
> No objection then.
>
> On a related note, you would be very well served to consider testing
> your dvb changes with a device that has more than one DVB tuner (such
> as the hvr-2200/2250). That will help you shake out any edge cases
> related to ensuring that the different DVB nodes appear in different
> groups.
Hi Devin,
I did some tests (and fixes) for WinTV Nova-TD, with has two adapters.
I saw two alternatives for it:
1) to create a media controller device for each adapter;
2) to create just one media controller.
I actually implemented (1), as, in the case of this device, AFAIKT, the
two devices are indepentent, e. g. it is not possible to, for example,
share the same tuner with two demods:
$ ls -la /dev/media?
crw-rw----. 1 root video 249, 0 Fev 23 10:02 /dev/media0
crw-rw----. 1 root video 249, 1 Fev 23 10:02 /dev/media1
The adapter 0 corresponds to /dev/media0, and the adapter 1
to /dev/media1:
$ media-ctl --print-dot -d /dev/media0
digraph board {
rankdir=TB
n00000001 [label="dvb-demux\n/dev/dvb/adapter0/demux0", shape=box, style=filled, fillcolor=yellow]
n00000001 -> n00000002
n00000002 [label="dvb-dvr\n/dev/dvb/adapter0/dvr0", shape=box, style=filled, fillcolor=yellow]
n00000003 [label="dvb-net\n/dev/dvb/adapter0/net0", shape=box, style=filled, fillcolor=yellow]
n00000004 [label="DiBcom 7000PC\n/dev/dvb/adapter0/frontend0", shape=box, style=filled, fillcolor=yellow]
n00000004 -> n00000001
}
$ media-ctl --print-dot -d /dev/media1
digraph board {
rankdir=TB
n00000001 [label="dvb-demux\n/dev/dvb/adapter1/demux0", shape=box, style=filled, fillcolor=yellow]
n00000001 -> n00000002
n00000002 [label="dvb-dvr\n/dev/dvb/adapter1/dvr0", shape=box, style=filled, fillcolor=yellow]
n00000003 [label="dvb-net\n/dev/dvb/adapter1/net0", shape=box, style=filled, fillcolor=yellow]
n00000004 [label="DiBcom 7000PC\n/dev/dvb/adapter1/frontend0", shape=box, style=filled, fillcolor=yellow]
n00000004 -> n00000001
}
On a more complex hardware where some components may be rewired
on a different way, however, using just one media controller
would be a better approach.
Comments?
Mauro
^ permalink raw reply
* Re: Documenting MS_LAZYTIME
From: Austin S Hemmelgarn @ 2015-02-23 12:20 UTC (permalink / raw)
To: Theodore Ts'o, Eric Sandeen
Cc: Michael Kerrisk, Ext4 Developers List,
Linux btrfs Developers List, XFS Developers,
linux-man-u79uwXL29TY76Z2rM5mHXA, Linux-Fsdevel, Linux API
In-Reply-To: <20150221025636.GB7922-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org>
On 2015-02-20 21:56, Theodore Ts'o wrote:
> On Fri, Feb 20, 2015 at 09:49:34AM -0600, Eric Sandeen wrote:
>>
>>> This mount option significantly reduces writes to the
>>> inode table for workloads that perform frequent random
>>> writes to preallocated files.
>>
>> This seems like an overly specific description of a single workload out
>> of many which may benefit, but what do others think? "inode table" is also
>> fairly extN-specific.
>
> How about somethign like "This mount significantly reduces writes
> needed to update the inode's timestamps, especially mtime and actime.
> Examples of workloads where this could be a large win include frequent
> random writes to preallocated files, as well as cases where the
> MS_STRICTATIME mount option is enabled."?
>
> (The advantage of MS_STRICTATIME | MS_LAZYTIME is that stat system
> calls will return the correctly updated atime, but those atime updates
> won't get flushed to disk unless the inode needs to be updated for
> file system / data consistency reasons, or when the inode is pushed
> out of memory, or when the file system is unmounted.)
>
If you want to list some specific software, it should help with anything
that uses sqlite (which notably includes firefox and chrome), as well as
most RDMS software and systemd-journald.
^ permalink raw reply
* Re: [PATCH 05/45] drm.h: include stdlib.h in userspace
From: Mikko Rapeli @ 2015-02-23 10:35 UTC (permalink / raw)
To: Emil Velikov
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <54EB0072.8020909-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Mon, Feb 23, 2015 at 10:26:58AM +0000, Emil Velikov wrote:
> On 16/02/15 23:05, Mikko Rapeli wrote:
> > Fixes <drm/drm.h> compilation error:
> >
> > drm/drm.h:132:2: error: unknown type name ‘size_t’
> >
> Hi Mikko,
>
> Can you let us know how you're getting these (series-wise) errors ? I've
> been meaning to sync the uapi/drm and libdrm headers and would be nice
> to have an extra step to test things.
This should have everything needed to reproduce these compile errors,
though some of the errors hide behind other errors and fixes:
https://lkml.org/lkml/2015/2/16/525
-Mikko
^ permalink raw reply
* Re: [PATCH v2 02/18] ARM: ARMv7M: Enlarge vector table to 256 entries
From: Maxime Coquelin @ 2015-02-23 10:33 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Andreas Färber, Geert Uytterhoeven, Rob Herring,
Philipp Zabel, Jonathan Corbet, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Russell King, Daniel Lezcano,
Thomas Gleixner, Linus Walleij, Greg Kroah-Hartman, Jiri Slaby,
Arnd Bergmann, Andrew Morton, David S. Miller,
Mauro Carvalho Chehab, Joe Perches, Antti Palosaari, Tejun Heo,
Will Deacon
In-Reply-To: <20150220194756.GS19388@pengutronix.de>
2015-02-20 20:47 GMT+01:00 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:
> On Fri, Feb 20, 2015 at 07:01:01PM +0100, Maxime Coquelin wrote:
>> From Cortex-M reference manuals, the nvic supports up to 240 interrupts.
>> So the number of entries in vectors table is up to 256.
>>
>> This patch adds a new config flag to specify the number of external interrupts.
>> Some ifdeferies are added in order to respect the natural alignment without
>> wasting too much space on smaller systems.
>>
>> Signed-off-by: Maxime Coquelin <mcoquelin.stm32@gmail.com>
>> ---
>> arch/arm/kernel/entry-v7m.S | 13 +++++++++----
>> arch/arm/mm/Kconfig | 15 +++++++++++++++
>> 2 files changed, 24 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/kernel/entry-v7m.S b/arch/arm/kernel/entry-v7m.S
>> index 8944f49..68cde36 100644
>> --- a/arch/arm/kernel/entry-v7m.S
>> +++ b/arch/arm/kernel/entry-v7m.S
>> @@ -117,9 +117,14 @@ ENTRY(__switch_to)
>> ENDPROC(__switch_to)
>>
>> .data
>> - .align 8
>> +#if CONFIG_CPUV7M_NUM_IRQ <= 112
> I would have called this CONFIG_CPU_V7M_NUM_IRQ to match the already
> existing CPU_V7M symbol.
That's better indeed.
It will be changed in v3.
>
>> + .align 9
>> +#else
>> + .align 10
>> +#endif
>> +
>
> Other than that:
> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>
> Who do you target to apply this series?
I guess it should go through Russell's Patch Tracking System?
Thanks,
Maxime
>
> Best regards
> Uwe
>
> --
> Pengutronix e.K. | Uwe Kleine-König |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH 05/45] drm.h: include stdlib.h in userspace
From: Emil Velikov @ 2015-02-23 10:26 UTC (permalink / raw)
To: Mikko Rapeli, linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: emil.l.velikov-Re5JQEeQqe8AvxtiuMwx3w,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-api-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1424127948-22484-6-git-send-email-mikko.rapeli-X3B1VOXEql0@public.gmane.org>
On 16/02/15 23:05, Mikko Rapeli wrote:
> Fixes <drm/drm.h> compilation error:
>
> drm/drm.h:132:2: error: unknown type name ‘size_t’
>
Hi Mikko,
Can you let us know how you're getting these (series-wise) errors ? I've
been meaning to sync the uapi/drm and libdrm headers and would be nice
to have an extra step to test things.
Thanks
Emil
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox