On Fri, Jul 22, 2016 at 04:10:44PM +0200, Tomeu Vizoso wrote:
> Adds files and directories to debugfs for controlling and reading frame
> CRCs, per CRTC:
>
> dri/0/crtc-0/crc
> dri/0/crtc-0/crc/control
> dri/0/crtc-0/crc/data
>
> Drivers can implement the set_crc_source callback() in drm_crtc_fun
On Wed, Aug 03, 2016 at 10:06:38AM +0300, Ville Syrjälä wrote:
> On Fri, Jul 22, 2016 at 04:10:44PM +0200, Tomeu Vizoso wrote:
> > Adds files and directories to debugfs for controlling and reading frame
> > CRCs, per CRTC:
> >
> > dri/0/crtc-0/crc
> > dri/0/crtc-0/crc/control
> > dri/0/crtc-0/crc/
* Kees Cook wrote:
> > I see 0 up-sides of this approach and, as per the above, a whole bunch of
> > very
> > serious downsides.
> >
> > A global (esp. default inhibited) knob is too coarse and limiting.
>
> I haven't suggested it be default inhibit in the upstream Kconfig. And
> having this
> The default has no impact on the "it's too coarse and limiting"
> negative property
> of this patch, which is the show-stopper aspect. Please fix that
> aspect instead of
> trying to argue around it.
Disabling perf events in the kernel configuration is even more limiting,
and is currently the
Having this in Yama would also make it probable that there would be a
security-centric default. It would end up wiping out unprivileged perf
events access on distributions using Yama for ptrace_scope unless they
make the explicit decision to disable it. Having the perf subsystem
extend the existing
On Wed, Aug 03, 2016 at 08:28:10AM -0400, Daniel Micay wrote:
> I don't think there are runtimes using this for JIT tracing. Perhaps it
> doesn't actually suit their needs. It's a theoretical use case.
I know there are compiler teams using perf for FDO, see for example:
https://gcc.gnu.org/wiki
On Tue, Aug 02, 2016 at 01:51:47PM -0700, Kees Cook wrote:
> Let me take this another way instead. What would be a better way to
> provide a mechanism for system owners to disable perf without an LSM?
> (Since far fewer folks run with an enforcing "big" LSM: I'm seeking as
> wide a coverage as poss
> -Original Message-
> From: Peter Zijlstra [mailto:pet...@infradead.org]
> Sent: Wednesday, August 03, 2016 7:41 AM
> To: Kees Cook
> Cc: Jeff Vander Stoep ; Ingo Molnar ;
> Arnaldo Carvalho de Melo ; Alexander Shishkin
> ; linux-doc@vger.kernel.org; kernel-
> harden...@lists.openwall.com
On Wed, Aug 3, 2016 at 10:25 AM, Eric W. Biederman
wrote:
>
> Sigh.
>
> Kees we have already had this conversation about user namespaces and
> apparently you missed the point.
Well, I didn't miss the point: that's why I CCed you. :) This is
nearly the same discussion (though in this case there is
> One of the strengths of linux is applications of features the authors
> of
> the software had not imagined. Your proposals seem to be trying to
> put
> the world a tiny little box where if someone had not imagined and
> preapproved a use of a feature it should not happen. Let's please
> avoid
Sigh.
Kees we have already had this conversation about user namespaces and
apparently you missed the point.
As I have said before the problem with a system wide off switch is what
happens when you have a single application that needs to use the
feature. Without care your system wide protection
On Wed, Aug 03, 2016 at 03:44:17PM -0600, Jonathan Corbet wrote:
> On Tue, 2 Aug 2016 23:23:57 +0900
> "seokhoon.yoon" wrote:
>
> > cgroup's document path is changed to "cgroup-v1". update it.
>
> Seems worthy to me, applied to the docs tree.
Acked-late-by: Tejun Heo
Thanks!
--
tejun
--
To
On Tue, 2 Aug 2016 23:23:57 +0900
"seokhoon.yoon" wrote:
> cgroup's document path is changed to "cgroup-v1". update it.
Seems worthy to me, applied to the docs tree.
Thanks,
jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.
On Wed, Aug 03, 2016 at 11:53:41AM -0700, Kees Cook wrote:
> > Kees Cook writes:
> >
> >> On Tue, Aug 2, 2016 at 1:30 PM, Peter Zijlstra
> >> wrote:
> >> Let me take this another way instead. What would be a better way to
> >> provide a mechanism for system owners to disable perf without an LSM?
Peter Zijlstra writes:
> On Wed, Aug 03, 2016 at 11:53:41AM -0700, Kees Cook wrote:
>> > Kees Cook writes:
>> >
>> >> On Tue, Aug 2, 2016 at 1:30 PM, Peter Zijlstra
>> >> wrote:
>> >> Let me take this another way instead. What would be a better way to
>> >> provide a mechanism for system owner
Provide managed resource version of reboot_mode_register() and
reboot_mode_unregister() to simplify implementations.
Cc: John Stultz
Signed-off-by: Bjorn Andersson
---
John, here's a "pointer" to what I meant with my comment on your
sram-reboot-mode patch. Only compile tested though.
Document
Use the managed resource version of reboot_mode_register().
Cc: John Stultz
Signed-off-by: Bjorn Andersson
---
John, here's a "pointer" to what I meant with my comment on your
sram-reboot-mode patch. Only compile tested though.
drivers/power/reset/syscon-reboot-mode.c | 12 +---
1 fil
17 matches
Mail list logo
