Re: [PATCH v8 3/6] cpuset: Add cpuset.sched.load_balance flag to v2

On Thu, May 24, 2018 at 02:55:25PM -0400, Waiman Long wrote: > On 05/24/2018 11:43 AM, Peter Zijlstra wrote: > > I'm confused... why exactly do we have both domain and load_balance ? > > The domain is for partitioning the CPUs only. It doesn't change the load > b

Re: [PATCH v8 2/6] cpuset: Add new v2 cpuset.sched.domain flag

On Thu, May 24, 2018 at 02:53:31PM -0400, Waiman Long wrote: > On 05/24/2018 11:41 AM, Peter Zijlstra wrote: > > On Thu, May 17, 2018 at 04:55:41PM -0400, Waiman Long wrote: > >> A new cpuset.sched.domain boolean flag is added to cpuset v2. This new > >> flag indicates t

Re: [PATCH v8 3/6] cpuset: Add cpuset.sched.load_balance flag to v2

On Thu, May 17, 2018 at 04:55:42PM -0400, Waiman Long wrote: > The sched.load_balance flag is needed to enable CPU isolation similar to > what can be done with the "isolcpus" kernel boot parameter. Its value > can only be changed in a scheduling domain with no child cpusets. On > a non-scheduling

Re: [PATCH v8 2/6] cpuset: Add new v2 cpuset.sched.domain flag

On Thu, May 17, 2018 at 04:55:41PM -0400, Waiman Long wrote: > A new cpuset.sched.domain boolean flag is added to cpuset v2. This new > flag indicates that the CPUs in the current cpuset should be treated > as a separate scheduling domain. The traditional name for this is a partition. >

Re: [PATCH 13/18] wait: wait.h: Get rid of a kernel-doc/Sphinx warnings

On Thu, May 10, 2018 at 06:38:05AM -0300, Mauro Carvalho Chehab wrote: > Em Thu, 10 May 2018 01:38:38 -0700 > Christoph Hellwig escreveu: > > > > * Use either while holding wait_queue_head::lock or when used for > > > wakeups > > > - * with an extra smp_mb() like: > > > +

Re: [PATCH 13/18] wait: wait.h: Get rid of a kernel-doc/Sphinx warnings

On Wed, May 09, 2018 at 12:35:40PM -0600, Jonathan Corbet wrote: > On Wed, 9 May 2018 17:20:26 +0200 > Peter Zijlstra <pet...@infradead.org> wrote: > > > The whole rst wankery is detrimental to that interface in order to > > pander to something else.. I don't see the

Re: [PATCH 13/18] wait: wait.h: Get rid of a kernel-doc/Sphinx warnings

On Wed, May 09, 2018 at 08:45:18AM -0600, Jonathan Corbet wrote: > On Wed, 9 May 2018 10:41:20 +0200 > Peter Zijlstra <pet...@infradead.org> wrote: > > > > This is easily done by using "::" instead of just ":". > > > > And I'll voi

Re: [PATCH 13/18] wait: wait.h: Get rid of a kernel-doc/Sphinx warnings

On Mon, May 07, 2018 at 06:35:49AM -0300, Mauro Carvalho Chehab wrote: > The flow diagram should be inside a code-block to avoid those > warnings: > ./include/linux/wait.h:110: WARNING: Block quote ends without a blank > line; unexpected unindent. > ./include/linux/wait.h:113:

Re: [PATCH v7 3/5] cpuset: Add a root-only cpus.isolated v2 control file

On Thu, Apr 19, 2018 at 09:47:02AM -0400, Waiman Long wrote: > diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt > index c970bd7..8d89dc2 100644 > --- a/Documentation/cgroup-v2.txt > +++ b/Documentation/cgroup-v2.txt > @@ -1484,6 +1484,31 @@ Cpuset Interface Files > a

Re: [PATCH v7 2/5] cpuset: Add cpuset.sched_load_balance to v2

On Wed, May 02, 2018 at 09:47:00AM -0400, Waiman Long wrote: > > I've read half of the next patch that adds the isolation thing. And > > while that kludges around the whole root cgorup is magic thing, it > > doesn't help if you move the above scenario on level down: > > > > > > R > > /

Re: [PATCH v7 2/5] cpuset: Add cpuset.sched_load_balance to v2

On Wed, May 02, 2018 at 09:29:54AM -0400, Waiman Long wrote: > On 05/02/2018 06:24 AM, Peter Zijlstra wrote: > > On Thu, Apr 19, 2018 at 09:47:01AM -0400, Waiman Long wrote: > >> + cpuset.sched_load_balance > >> + A read-write single value file which exists on

Re: [PATCH v7 2/5] cpuset: Add cpuset.sched_load_balance to v2

On Thu, Apr 19, 2018 at 09:47:01AM -0400, Waiman Long wrote: > + cpuset.sched_load_balance > + A read-write single value file which exists on non-root cgroups. Uhhm.. it should very much exist in the root group too. Otherwise you cannot disable it there, which is required to allow smaller

Re: [PATCH] sched/fair: add support to tune PELT ramp/decay timings

On Mon, Apr 09, 2018 at 05:51:34PM +0100, Patrick Bellasi wrote: > The PELT half-life is the time [ms] required by the PELT signal to build > up a 50% load/utilization, starting from zero. This time is currently > hardcoded to be 32ms, a value which seems to make sense for most of the > workloads.

Re: [PATCH] docs/memory-barriers.txt: Fix broken DMA vs MMIO ordering example

On Wed, Mar 28, 2018 at 10:57:11AM -0700, Tony Luck wrote: > On Wed, Mar 28, 2018 at 6:02 AM, Sinan Kaya wrote: > > +linux-ia64 > > Does IA64 follow this requirement? If not, is implementation planned? > > > > "no wmb() before writel()" > > > > Linus asked us to get rid of

Re: [PATCH 1/5] x86/smpboot: Add the missing description of possible_cpus

On Wed, Mar 21, 2018 at 01:33:24PM +0800, Dou Liyang wrote: > How about: > > possible_cpus=[s390,x86_64] Set the number of possible CPUs which > are determined by the ACPI tables MADT or mptables by > default. possible_cpus=n : n >= 1 enforces the possible >

Re: [PATCH 3/5] x86/smpboot: Make the check code more clear in prefill_possible_map()

On Tue, Mar 20, 2018 at 07:04:30PM +0800, Dou Liyang wrote: > case 1: no | no | no | --> min (setup_possible_cpus, nr_cpu_ids, > setup_max_cpus) > case 2: no | no | yes| --> min (setup_possible_cpus, nr_cpu_ids) > case 3: no | yes | no | --> 1 > case 4:

Re: [PATCH 1/5] x86/smpboot: Add the missing description of possible_cpus

On Tue, Mar 20, 2018 at 07:04:28PM +0800, Dou Liyang wrote: > + possible_cpus= [s390,x86_64] Use this to set hotpluggable cpus. > + This option sets possible_cpus bits in cpu_possible_map. > + Thus keeping the numbers of bits set constant even if > +

Re: [PATCH] Improve mutex documentation

On Thu, Mar 15, 2018 at 04:58:12AM -0700, Matthew Wilcox wrote: > On Wed, Mar 14, 2018 at 01:56:31PM -0700, Andrew Morton wrote: > > My memory is weak and our documentation is awful. What does > > mutex_lock_killable() actually do and how does it differ from > > mutex_lock_interruptible()? > >

Re: [PATCH v4] cpuset: Enable cpuset controller in default hierarchy

On Fri, Mar 09, 2018 at 03:43:34PM -0500, Waiman Long wrote: > The isolcpus= parameter just reduce the cpus available to the rests of > the system. The cpuset controller does look at that value and make > adjustment accordingly, but it has no dependence on exclusive cpu/mem > features of cpuset.

Re: [PATCH 00/13] Remove metag architecture

On Wed, Feb 21, 2018 at 11:38:12PM +, James Hogan wrote: > So lets call it a day and drop the Meta architecture port from the > kernel. RIP Meta. So long, and thanks for all the fish! Nice cleanup though, most welcome :-) Acked-by: Peter Zijlstra (Intel) <pet...@infr

Re: [PATCH 0/2] Update lockdep doc and add section about annotations

dep > asserts might help spread adoption even wider (mostly regarding > lockdep_pin_lock stuff, which is pretty new and maybe got unnoticed > outside of the scheduler?). Thanks for writing that Juri! Acked-by: Peter Zijlstra (Intel) <pet...@infradead.org> -- To unsubscribe from this

Re: [PATCH] acpi, spcr: Make SPCR available to x86

On Mon, Feb 12, 2018 at 10:18:06AM -0500, Prarit Bhargava wrote: > > But when I specify "earlyprintk=serial,ttyS0,115200" this SPCR crud will > > not interfere? > > > > I tested "earlyprintk=serial,ttyS0,115200" on a system which is known to have > a > functional console with

Re: [PATCH] acpi, spcr: Make SPCR available to x86

On Mon, Feb 12, 2018 at 08:47:57AM -0500, Prarit Bhargava wrote: > > > On 02/12/2018 08:34 AM, Peter Zijlstra wrote: > > On Thu, Jan 18, 2018 at 10:09:51AM -0500, Prarit Bhargava wrote: > >> config ACPI_SPCR_TABLE > >> + bool "ACPI Serial Port Console

Re: [PATCH] acpi, spcr: Make SPCR available to x86

On Thu, Jan 18, 2018 at 10:09:51AM -0500, Prarit Bhargava wrote: > config ACPI_SPCR_TABLE > + bool "ACPI Serial Port Console Redirection Support" > + default y if X86 > + help > + Enable support for Serial Port Console Redirection (SPCR) Table. > + This table provides

Re: [PATCH] doc: memory-barriers: reStructure Text

On Wed, Jan 03, 2018 at 03:04:36PM +0530, afzal mohammed wrote: > Let PDF & HTML's be created out of memory-barriers Text by > reStructuring. > > reStructuring done were, > 1. Section headers modification, lower header case except start > 2. Removal of manual index(contents section), since it now

Re: [PATCH V2 2/3] perf/x86/intel/bm.c: Add Intel Branch Monitoring support

On Tue, Dec 12, 2017 at 03:08:00PM -0800, Megha Dey wrote: > > > > There's work on the way to allow multiple HW PMUs. You'll either have to > > wait for that or help in making that happen. What you do not do is > > silently hack around it. > > Could I get a pointer to the code implementing this?

Re: [PATCH V2 2/3] perf/x86/intel/bm.c: Add Intel Branch Monitoring support

On Tue, Dec 12, 2017 at 01:10:57PM -0800, Megha Dey wrote: > On Mon, 2017-11-20 at 12:57 +0100, Peter Zijlstra wrote: > > On Fri, Nov 17, 2017 at 05:54:05PM -0800, Megha Dey wrote: > > > + mutex_lock(_counter_mutex); > > > + for (i

Re: [PATCH V2 2/3] perf/x86/intel/bm.c: Add Intel Branch Monitoring support

On Fri, Nov 17, 2017 at 05:54:05PM -0800, Megha Dey wrote: > + mutex_lock(_counter_mutex); > + for (i = 0; i < BM_MAX_COUNTERS; i++) { > + if (bm_counter_owner[i] == NULL) { > + counter_to_use = i; > + bm_counter_owner[i] = event; > +

Re: [PATCH RFC v3 0/6] x86/idle: add halt poll support

On Mon, Nov 13, 2017 at 07:01:40PM +0800, Quan Xu wrote: > Documentation/sysctl/kernel.txt | 35 > arch/x86/include/asm/paravirt.h |5 ++ > arch/x86/include/asm/paravirt_types.h |6 +++ > arch/x86/kernel/kvm.c | 73 >

Re: [PATCH RFC v3 3/6] sched/idle: Add a generic poll before enter real idle path

On Mon, Nov 13, 2017 at 06:06:02PM +0800, Quan Xu wrote: > From: Yang Zhang > > Implement a generic idle poll which resembles the functionality > found in arch/. Provide weak arch_cpu_idle_poll function which > can be overridden by the architecture code if needed. No,

Re: [PATCH v2] sched/deadline: fix runtime accounting in documentation

On Tue, Nov 14, 2017 at 12:19:26PM +0100, Claudio Scordino wrote: > Signed-off-by: Claudio Scordino <clau...@evidence.eu.com> > Signed-off-by: Luca Abeni <luca.ab...@santannapisa.it> > Acked-by: Daniel Bristot de Oliveira <bris...@redhat.com> > CC: Jonathan Corbet

Re: [PATCH V1 2/3] perf/x86/intel/bm.c: Add Intel Branch Monitoring support

On Sat, Nov 11, 2017 at 01:20:05PM -0800, Megha Dey wrote: > Currently, the cannonlake family of Intel processors support the > branch monitoring feature. Intel's Branch monitoring feature is trying > to utilize heuristics to detect the occurrence of an ROP (Return > Oriented Programming) attack.

Re: [PATCHv3 1/1] locking/qspinlock/x86: Avoid test-and-set when PV_DEDICATED is set

On Fri, Nov 10, 2017 at 10:07:56AM +0800, Wanpeng Li wrote: > >> Also, you should not put cpumask_t on stack, that's 'broken'. > > Thanks pointing out this. I found a useful comments in arch/x86/kernel/irq.c: > > /* These two declarations are only used in check_irq_vectors_for_cpu_disable() >

Re: [PATCHv3 1/1] locking/qspinlock/x86: Avoid test-and-set when PV_DEDICATED is set

On Thu, Nov 09, 2017 at 06:15:11PM +0100, Peter Zijlstra wrote: > On Thu, Nov 09, 2017 at 06:12:41PM +0100, Peter Zijlstra wrote: > > On Thu, Nov 09, 2017 at 05:45:23PM +0100, Radim Krcmar wrote: > > > 2017-11-09 17:17+0100, Peter Zijlstra: > > > > On Thu, Nov 09, 2

Re: [PATCHv3 1/1] locking/qspinlock/x86: Avoid test-and-set when PV_DEDICATED is set

On Thu, Nov 09, 2017 at 06:12:41PM +0100, Peter Zijlstra wrote: > On Thu, Nov 09, 2017 at 05:45:23PM +0100, Radim Krcmar wrote: > > 2017-11-09 17:17+0100, Peter Zijlstra: > > > On Thu, Nov 09, 2017 at 05:05:36PM +0100, Radim Krcmar wrote: > > > > 2017-11-09 10:53-0

Re: [PATCHv3 1/1] locking/qspinlock/x86: Avoid test-and-set when PV_DEDICATED is set

On Thu, Nov 09, 2017 at 05:45:23PM +0100, Radim Krcmar wrote: > 2017-11-09 17:17+0100, Peter Zijlstra: > > On Thu, Nov 09, 2017 at 05:05:36PM +0100, Radim Krcmar wrote: > > > 2017-11-09 10:53-0500, Pankaj Gupta: > > > > 2] PV TLB should also behave as per

Re: [PATCHv3 1/1] locking/qspinlock/x86: Avoid test-and-set when PV_DEDICATED is set

On Thu, Nov 09, 2017 at 05:05:36PM +0100, Radim Krcmar wrote: > 2017-11-09 10:53-0500, Pankaj Gupta: > > 2] PV TLB should also behave as per option PV_DEDICATED for better > > performance. > > Right, Shouldn't KVM do flush_tlb_other() in any case? Not sure how PV_DEDICATED can help with that.

Re: [PATCH 1/1] locking/qspinlock/x86: Avoid test-and-set when PV_DEDICATED is set

On Mon, Oct 23, 2017 at 05:44:27PM -0700, Eduardo Valentin wrote: > @@ -46,6 +48,8 @@ static inline bool virt_spin_lock(struct qspinlock *lock) > if (!static_cpu_has(X86_FEATURE_HYPERVISOR)) > return false; > > + if (kvm_para_has_feature(KVM_FEATURE_PV_DEDICATED)) > +

Re: [PATCH resend] x86,kvm: Add a kernel parameter to disable PV spinlock

On Tue, Sep 05, 2017 at 10:52:06AM +0200, Juergen Gross wrote: > > Hmm, that might work. Could we somehow nop that call when > > !X86_FEATURE_HYPERVISOR?, that saves native from having to do the call > > and would be a win for everyone. > > So in fact we want a "always false" shortcut for bare

Re: [PATCH resend] x86,kvm: Add a kernel parameter to disable PV spinlock

On Tue, Sep 05, 2017 at 10:14:21AM +0200, Juergen Gross wrote: > On 05/09/17 10:10, Peter Zijlstra wrote: > > On Tue, Sep 05, 2017 at 09:35:40AM +0200, Juergen Gross wrote: > >>> So the problem with qspinlock is that it will revert to a classic > >>> test-and-set

Re: [PATCH resend] x86,kvm: Add a kernel parameter to disable PV spinlock

On Tue, Sep 05, 2017 at 09:35:40AM +0200, Juergen Gross wrote: > > So the problem with qspinlock is that it will revert to a classic > > test-and-set spinlock if you don't do paravirt but are running a HV. > > In the Xen case we just use the bare metal settings when xen_nopvspin > has been

Re: [PATCH resend] x86,kvm: Add a kernel parameter to disable PV spinlock

On Tue, Sep 05, 2017 at 08:57:16AM +0200, Oscar Salvador wrote: > It may be that the original patch was just to keep consistency between Xen > and KVM, and also only for testing purposes. > But we find a case when a customer of ours is running some workloads with > 1<->1 mapping between physical

Re: [PATCH resend] x86,kvm: Add a kernel parameter to disable PV spinlock

On Tue, Sep 05, 2017 at 08:28:10AM +0200, Juergen Gross wrote: > On 05/09/17 00:21, Davidlohr Bueso wrote: > > On Mon, 04 Sep 2017, Peter Zijlstra wrote: > > > >> For testing its trivial to hack your kernel and I don't feel this is > >> something an Admin ca

Re: [PATCH resend] x86,kvm: Add a kernel parameter to disable PV spinlock

On Mon, Sep 04, 2017 at 04:28:36PM +0200, Oscar Salvador wrote: > This is just a resend of Waiman Long's patch. > I could not find why it was not merged to upstream, so I thought > to give it another chance. > What follows is what Waiman Long wrote. > > Xen has an kernel command line argument

Re: [RFC PATCH v2 7/7] sched/idle: update poll time when wakeup from idle

On Tue, Aug 29, 2017 at 11:46:41AM +, Yang Zhang wrote: > In ttwu_do_wakeup, it will update avg_idle when wakeup from idle. Here > we just reuse this logic to update the poll time. It may be a little > late to update the poll in ttwu_do_wakeup, but the test result shows no > obvious

Re: [RFC PATCH v2 3/7] sched/idle: Add poll before enter real idle path

On Tue, Aug 29, 2017 at 11:46:37AM +, Yang Zhang wrote: > Add poll in do_idle. For UP VM, if there are running task, it will not > goes into idle path, so we only enable poll in SMP VM. > > Signed-off-by: Yang Zhang > Signed-off-by: Quan Xu

Re: [PATCH v4] printk: Add monotonic, boottime, and realtime timestamps

On Mon, Aug 07, 2017 at 01:36:39PM -0700, Paul E. McKenney wrote: > On Mon, Aug 07, 2017 at 04:06:09PM -0400, Prarit Bhargava wrote: > > peterz? Want to offer a suggestion? The issue is that I'm changing a bool > > config option to an int and that impacts all the arch's defconfigs. John > >

Re: [PATCH v4] printk: Add monotonic, boottime, and realtime timestamps

On Mon, Aug 07, 2017 at 11:52:42AM -0400, Prarit Bhargava wrote: > +static u64 printk_get_ts(void) > +{ > + u64 mono, offset_real; > + > + if (printk_time <= PRINTK_TIME_LOCAL) > + return local_clock(); > + > + if (printk_time == PRINTK_TIME_BOOT) > + return

Re: [PATCH v4] printk: Add monotonic, boottime, and realtime timestamps

On Mon, Aug 07, 2017 at 09:52:10AM -0700, John Stultz wrote: > On Mon, Aug 7, 2017 at 8:52 AM, Prarit Bhargava wrote: > > +u64 ktime_get_real_log_ts(u64 *offset_real) > > +{ > > + *offset_real = ktime_to_ns(tk_core.timekeeper.offs_real); > > + > > + if

Re: [PATCH 2/2] printk: Add boottime and real timestamps

On Tue, Jul 25, 2017 at 08:17:27AM -0400, Prarit Bhargava wrote: > diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug > index 5b1662ec546f..6cd38a25f8ea 100644 > --- a/lib/Kconfig.debug > +++ b/lib/Kconfig.debug > @@ -1,8 +1,8 @@ > menu "printk and dmesg options" > > config PRINTK_TIME > -

Re: [PATCH 3/3] rtmutex: remove unnecessary adjust prio

On Wed, Jul 12, 2017 at 10:14:49AM -0400, Steven Rostedt wrote: > On Tue, 11 Jul 2017 22:39:24 +0800 > Alex Shi wrote: > > > Any comments for this little change? It's passed on 0day testing. > > I think the problem was that this was a third patch after two > documentation

Re: [RFC PATCH v2 11/17] cgroup: Implement new thread mode semantics

On Thu, Jun 01, 2017 at 10:50:42AM -0400, Tejun Heo wrote: > Hello, Waiman. > > A short update. I tried making root special while keeping the > existing threaded semantics but I didn't really like it because we > have to couple controller enables/disables with threaded > enables/disables. I'm

Re: [PATCH 04/36] mutex, futex: adjust kernel-doc markups to generate ReST

On Mon, May 15, 2017 at 02:22:39PM -0300, Mauro Carvalho Chehab wrote: > Yet, on the other hand, nobody wants lots of warnings/errors > produced when building the Kernel or the documentation, as it can ride > important things that would require fixes. So would that actually generate a

Re: [PATCH 04/36] mutex, futex: adjust kernel-doc markups to generate ReST

On Mon, May 15, 2017 at 01:29:58PM +0300, Jani Nikula wrote: > On Mon, 15 May 2017, Peter Zijlstra <pet...@infradead.org> wrote: > > The intention is to aid readability. Making comments worse so that some > > retarded script can generate better html or whatnot is ju

Re: [PATCH 04/36] mutex, futex: adjust kernel-doc markups to generate ReST

On Mon, May 15, 2017 at 06:00:46AM -0300, Mauro Carvalho Chehab wrote: > > Well, I don't mind the '-' thing before return values too much, but the > > below chunk is just pure drivel. It makes a perfectly good comment > > worse. > > > > --- a/kernel/locking/mutex.c > > +++

Re: [PATCH 04/36] mutex, futex: adjust kernel-doc markups to generate ReST

On Fri, May 12, 2017 at 03:19:17PM -0700, Darren Hart wrote: > On Sat, May 13, 2017 at 12:11:09AM +0200, Peter Zijlstra wrote: > > And I really _really_ hate to see that rest crap spread here. Can't we > > just delete all that nonsense and go back to 80 column 7bit ASCII ? >

Re: [PATCH 04/36] mutex, futex: adjust kernel-doc markups to generate ReST

On Fri, May 12, 2017 at 06:51:50PM -0300, Mauro Carvalho Chehab wrote: > > * Return: > > * * 0 - ready to wait > > * * 1 - acquired the lock > > * * <0 - error > > > > I'm fine with either though, just curious if this would be an improvement, > > or if > > we have an established policy

Re: [PATCH v2 1/3] rtmutex: update rt-mutex-design

On Fri, Apr 21, 2017 at 10:12:53PM +0800, Alex Shi wrote: > diff --git a/Documentation/locking/rt-mutex-design.txt > b/Documentation/locking/rt-mutex-design.txt > index 8666070..11beb55 100644 > --- a/Documentation/locking/rt-mutex-design.txt > +++ b/Documentation/locking/rt-mutex-design.txt > @@

Re: [PATCH v3 2/4] Documentation/atomic_ops.txt: convert to ReST markup

On Mon, Nov 28, 2016 at 01:16:45PM +0200, Jani Nikula wrote: > Using rst we can produce decent HTML pages, and make them available at > [1], in context. You don't have to read that, but it will be a lot more > discoverable for other people, another important quality of good > documentation. And

Re: [PATCH v3 2/4] Documentation/atomic_ops.txt: convert to ReST markup

On Mon, Nov 28, 2016 at 09:08:55AM -0200, Mauro Carvalho Chehab wrote: > - use *foo* (for italics) or **foo** (for bold) instead of _foo_; That's daft, and also you're wrong. The normal convention is: /italic/ *bold* _underlined_ >

Re: [PATCH v3 2/4] Documentation/atomic_ops.txt: convert to ReST markup

On Mon, Nov 28, 2016 at 09:44:42AM +0100, Daniel Vetter wrote: > > > > Why change them? What was wrong with txt to begin with? > > In my opinion good docs matter, and one of the key things is to be able to > cross reference stuff. Well, good docs begin with useful content; and many docs lack

Re: [PATCH v3 2/4] Documentation/atomic_ops.txt: convert to ReST markup

On Sun, Nov 27, 2016 at 04:59:14PM -0700, Jonathan Corbet wrote: > On Fri, 25 Nov 2016 22:58:14 +0100 > Peter Zijlstra <pet...@infradead.org> wrote: > > > Not a fan of this. The atomic_ops.txt file needs a lot of love, and I > > wouldn't want to edit a .rst file. >

Re: [PATCH v3 2/4] Documentation/atomic_ops.txt: convert to ReST markup

On Fri, Nov 25, 2016 at 03:59:45PM +0100, Silvio Fricke wrote: > ... and move to core-api folder. > > Signed-off-by: Silvio Fricke > --- > Documentation/atomic_ops.txt => Documentation/core-api/atomic_ops.rst | 777 >

Re: [PATCH 2/4] x86: Prepare vm86 tasks to handle User-Mode Instruction Prevention

On Tue, Nov 08, 2016 at 08:01:39AM -0800, Andy Lutomirski wrote: > > diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c > > index 0888a87..32b7301 100644 > > --- a/arch/x86/kernel/process.c > > +++ b/arch/x86/kernel/process.c > > @@ -233,6 +233,16 @@ void __switch_to_xtra(struct

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

On Mon, Nov 07, 2016 at 10:12:09PM -0800, Ricardo Neri wrote: > There is a caveat, however. Certain applications running in virtual-8086 > mode, such as DOSEMU[1] and Wine[2], want to utilize the SGDT, SIDT and > SLDT instructions for legitimate reasons. In order to keep such > applications

Re: [kernel-hardening] [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Tue, Oct 18, 2016 at 05:15:01PM -0400, Daniel Micay wrote: > It's also worth noting that fine-grained control via a scoped mechanism > would likely only be used to implement *more restrictions* on Android, > not to make the feature less aggressive. > It's desirable for perf events to be

Re: [kernel-hardening] [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Wed, Oct 19, 2016 at 07:26:02AM -0300, Arnaldo Carvalho de Melo wrote: > Em Wed, Oct 19, 2016 at 12:01:26PM +0200, Peter Zijlstra escreveu: > > On Tue, Oct 18, 2016 at 05:15:01PM -0400, Daniel Micay wrote: > > > It's also worth noting that fine-grained control via a scoped mec

Re: [PATCH v15 04/13] task_isolation: add initial support

On Tue, Sep 27, 2016 at 04:22:20PM +0200, Frederic Weisbecker wrote: > The RCU context tracking doesn't take care of callbacks. It's only there > to tell the RCU core whether the CPU runs code that may or may not run > RCU read side critical sections. This is assumed by "kernel may use RCU, >

Re: [RFC PATCH v2 3/5] futex: Throughput-optimized (TO) futexes

On Wed, Sep 21, 2016 at 07:37:34PM -0400, Waiman Long wrote: > On 09/21/2016 02:59 AM, Mike Galbraith wrote: > >On Tue, 2016-09-20 at 09:42 -0400, Waiman Long wrote: > >>This patch introduces a new futex implementation called > >>throughput-optimized (TO) futexes. > >nit: 'TO' sounds way too much

Re: sparc: bpf_jit: Rename jump labels in bpf_jit_compile()

On Tue, Sep 06, 2016 at 04:34:13PM +0200, Jean Delvare wrote: > > [diff "default"] > > xfuncname = "^[[:alpha:]$_].*[^:]$" > > OK, I see. As mentioned somewhere else, it fails for labels which have > comments. Heh, There's labels that have comments? > My worry is that you recommending

Re: sparc: bpf_jit: Rename jump labels in bpf_jit_compile()

On Mon, Sep 05, 2016 at 01:54:45PM +0200, Jean Delvare wrote: > On Mon, 5 Sep 2016 13:37:04 +0200, Peter Zijlstra wrote: > > On Mon, Sep 05, 2016 at 01:07:37PM +0200, Jean Delvare wrote: > > > Now I see in http://patchwork.ozlabs.org/patch/664966/ that Peter > > >

Re: sparc: bpf_jit: Rename jump labels in bpf_jit_compile()

On Mon, Sep 05, 2016 at 01:07:37PM +0200, Jean Delvare wrote: > Now I see in http://patchwork.ozlabs.org/patch/664966/ that Peter > Zijlstra reportedly changed the behavior of "diff -p" so that it > handles unindented C labels nicely. If this actually happens, it could > c

Re: [PATCH v15 04/13] task_isolation: add initial support

On Fri, Sep 02, 2016 at 10:03:52AM -0400, Chris Metcalf wrote: > Any thoughts on the question of "just re-enter the loop" vs. > schedule_timeout()? schedule_timeout() should only be used for things you do not have control over, like things outside of the machine. If you want to actually block

Re: [PATCH v15 04/13] task_isolation: add initial support

On Mon, Aug 29, 2016 at 12:40:32PM -0400, Chris Metcalf wrote: > On 8/29/2016 12:33 PM, Peter Zijlstra wrote: > >On Tue, Aug 16, 2016 at 05:19:27PM -0400, Chris Metcalf wrote: > >>+ /* > >>+* Request rescheduling unless we are in full dynticks mode. > >&g

Re: [PATCH v15 04/13] task_isolation: add initial support

On Mon, Aug 29, 2016 at 12:40:32PM -0400, Chris Metcalf wrote: > On 8/29/2016 12:33 PM, Peter Zijlstra wrote: > >On Tue, Aug 16, 2016 at 05:19:27PM -0400, Chris Metcalf wrote: > >>+ /* > >>+* Request rescheduling unless we are in full dynticks mode. > >&g

Re: [PATCH v15 04/13] task_isolation: add initial support

On Tue, Aug 16, 2016 at 05:19:27PM -0400, Chris Metcalf wrote: > + /* > + * Request rescheduling unless we are in full dynticks mode. > + * We would eventually get pre-empted without this, and if > + * there's another task waiting, it would run; but by > + * explicitly

Re: clocksource_watchdog causing scheduling of timers every second (was [v13] support "task_isolation" mode)

On Thu, Aug 11, 2016 at 12:16:58AM +0200, Frederic Weisbecker wrote: > I had similar issues, this seems to happen when the tsc is considered not > reliable > (which doesn't necessarily mean unstable. I think it has to do with some x86 > CPU feature > flag). Right, as per the other email, in

Re: [PATCH v13 00/12] support "task_isolation" mode

On Fri, Jul 22, 2016 at 08:50:44AM -0400, Chris Metcalf wrote: > On 7/21/2016 10:20 PM, Christoph Lameter wrote: > >On Thu, 21 Jul 2016, Chris Metcalf wrote: > >>On 7/20/2016 10:04 PM, Christoph Lameter wrote: > >>unstable, and then scheduling work to safely remove that timer. > >>I haven't looked

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Thu, Aug 04, 2016 at 10:13:29AM -0500, Eric W. Biederman wrote: > The bits useful to the perf situation are: > - user namespaces nest. > - anyone can create a user namespace. > - a sysctl can be bound to the userns that takes local privilege to > change so you can't override it arbitrarily.

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Thu, Aug 04, 2016 at 09:45:23AM -0400, Daniel Micay wrote: > Qualcomm's perf driver is out-of-tree along with most of their other > drivers. So you're asking us to maim upstream perf for some out of tree junk? Srously? *plonk* -- To unsubscribe from this list: send the line "unsubscribe

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Wed, Aug 03, 2016 at 11:53:41AM -0700, Kees Cook wrote: > > Kees Cook <keesc...@chromium.org> writes: > > > >> On Tue, Aug 2, 2016 at 1:30 PM, Peter Zijlstra <pet...@infradead.org> > >> wrote: > >> Let me take this another way instead. Wha

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

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

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

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:

Re: [kernel-hardening] Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Tue, Aug 02, 2016 at 12:04:34PM -0700, Kees Cook wrote: > Now, obviously, these API have huge value, otherwise they wouldn't > exist in the first place, and they wouldn't be built into end-user > kernels if they were universally undesirable. But that's not the > situation: the APIs are needed,

Re: [PATCH 1/2] security, perf: allow further restriction of perf_event_open

On Wed, Jul 27, 2016 at 07:45:46AM -0700, Jeff Vander Stoep wrote: > When kernel.perf_event_paranoid is set to 3 (or greater), disallow > all access to performance events by users without CAP_SYS_ADMIN. > > This new level of restriction is intended to reduce the attack > surface of the kernel.

Re: [PATCH 2/2] security, perf: Add config option to restrict perf_event_open

On Wed, Jul 27, 2016 at 07:46:23AM -0700, Jeff Vander Stoep wrote: > +++ b/kernel/events/core.c > @@ -355,7 +355,11 @@ static struct srcu_struct pmus_srcu; > * 2 - disallow kernel profiling for unpriv > * 3 - disallow all unpriv perf event use > */ > +#ifdef

Re: [kernel-hardening] [PATCH 2/2] security,perf: Allow further restriction of perf_event_open

On Thu, Jun 16, 2016 at 03:27:55PM -0700, Kees Cook wrote: > Hi guys, > > This patch wasn't originally CCed to you (I'm fixing that now). Would > you consider taking this into the perf tree? No. > It's been in active use > in both Debian and Android for a while now. Very nice of you all to

Re: [PATCH v12 07/13] task_isolation: add debug boot flag

On Thu, May 19, 2016 at 10:42:39AM -0400, Chris Metcalf wrote: > + rcu_read_lock(); > + p = cpu_curr(cpu); Here @cpu can schedule, hit TASK_DEAD and do put_task_struct() and kfree() the task. > + get_task_struct(p); And here we then do a use-after-free. > + rcu_read_unlock();

Re: [PATCH v12 04/13] task_isolation: add initial support

On Wed, May 18, 2016 at 12:34:22PM -0400, Chris Metcalf wrote: > On 5/18/2016 9:34 AM, Peter Zijlstra wrote: > >On Tue, Apr 05, 2016 at 01:38:33PM -0400, Chris Metcalf wrote: > >>diff --git a/kernel/signal.c b/kernel/signal.c > >>index aa9bf00749c1..53e4e62f2778 10064

Re: [PATCH v12 07/13] task_isolation: add debug boot flag

On Tue, Apr 05, 2016 at 01:38:36PM -0400, Chris Metcalf wrote: > +#ifdef CONFIG_TASK_ISOLATION > +void task_isolation_debug(int cpu) > +{ > + struct task_struct *p; > + > + if (!task_isolation_possible(cpu)) > + return; > + > + rcu_read_lock(); > + p = cpu_curr(cpu); >

Re: [PATCH v12 06/13] task_isolation: support PR_TASK_ISOLATION_STRICT mode

On Tue, Apr 05, 2016 at 01:38:35PM -0400, Chris Metcalf wrote: > +void task_isolation_interrupt(struct task_struct *task, const char *buf) > +{ > + siginfo_t info = {}; > + int sig; > + > + pr_warn("%s/%d: task_isolation strict mode violated by %s\n", > + task->comm,

Re: [PATCH v12 05/13] task_isolation: support CONFIG_TASK_ISOLATION_ALL

On Tue, Apr 05, 2016 at 01:38:34PM -0400, Chris Metcalf wrote: > This option, similar to NO_HZ_FULL_ALL, simplifies configuring > a system to boot by default with all cores except the boot core > running in task isolation mode. Hurm, we still have that option? I thought we killed it, because

Re: [PATCH v12 04/13] task_isolation: add initial support

On Tue, Apr 05, 2016 at 01:38:33PM -0400, Chris Metcalf wrote: > diff --git a/kernel/signal.c b/kernel/signal.c > index aa9bf00749c1..53e4e62f2778 100644 > --- a/kernel/signal.c > +++ b/kernel/signal.c > @@ -34,6 +34,7 @@ > #include > #include > #include > +#include > > #define

Re: [PATCH v10 07/12] task_isolation: add debug boot flag

On Wed, Mar 02, 2016 at 03:09:31PM -0500, Chris Metcalf wrote: > +void task_isolation_debug(int cpu) > +{ > + struct task_struct *p; > + > + if (!task_isolation_possible(cpu)) > + return; > + > + rcu_read_lock(); > + p = cpu_curr(cpu); > + get_task_struct(p); As I