[PATCH 4.4.y 046/101] x86/speculation: Move firmware_restrict_branch_speculation_*() from C to CPP

2018-07-14 Thread Srivatsa S. Bhat
...@redhat.com Cc: rkrc...@redhat.com Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman Signed-off-by: Srivatsa S. Bhat Reviewed-by: Matt Helsley (VMware) Reviewed-by: Alexey Makhalov Reviewed-by: Bo Gan --- arch/x86/include/asm/nospec-branch.h | 26

[PATCH 4.4.y 033/101] x86/asm/entry/32: Simplify pushes of zeroed pt_regs->REGs

2018-07-14 Thread Srivatsa S. Bhat
s Cook Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Steven Rostedt Cc: Thomas Gleixner Cc: Will Drewry Cc: linux-kernel@vger.kernel.org Link: http://lkml.kernel.org/r/1462201010-16846-1-git-send-email-dvlas...@redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Srivatsa S. Bhat Reviewed-by: M

[PATCH 4.4.y 037/101] x86/speculation: Clean up various Spectre related details

2018-07-14 Thread Srivatsa S. Bhat
Zijlstra Cc: Thomas Gleixner Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar Signed-off-by: Greg Kroah-Hartman Signed-off-by: Srivatsa S. Bhat Reviewed-by: Matt Helsley (VMware) Reviewed-by: Alexey Makhalov Reviewed-by: Bo Gan --- arch/x86/kernel/cpu/bugs.c | 25

Re: [PATCH 1/5] random: fix crng_ready() test

2018-05-16 Thread Srivatsa S. Bhat
On 4/13/18 10:00 AM, Theodore Y. Ts'o wrote: > On Fri, Apr 13, 2018 at 03:05:01PM +0200, Stephan Mueller wrote: >> >> What I would like to point out that more and more folks change to >> getrandom(2). As this call will now unblock much later in the boot cycle, >> these systems see a significant

Re: [PATCH 4.13 28/43] SMB3: Validate negotiate request must always be signed

2018-03-21 Thread Srivatsa S. Bhat
On 3/21/18 10:12 PM, Srivatsa S. Bhat wrote: > On 3/21/18 7:02 PM, Steve French wrote: >> Found a patch which solves the dependency issue. In my testing (on >> 4.9, with Windows 2016, and also to Samba) as Pavel suggested this >> appears to fix the problem, but I will

Re: [PATCH 4.13 28/43] SMB3: Validate negotiate request must always be signed

2018-03-21 Thread Srivatsa S. Bhat
lways be signed. Some Windows can fail the request if you send it unsigned See kernel bugzilla bug 197311 [ Fixed up for kernel version 4.4 ] CC: Stable <sta...@vger.kernel.org> Acked-by: Ronnie Sahlberg Signed-off-by: Steve French <smfre...@gmail.com> Signed-off-by: Srivatsa S. Bhat

Re: [PATCH 4.13 28/43] SMB3: Validate negotiate request must always be signed

2018-03-01 Thread Srivatsa S. Bhat
t if willing to backport a >> slightly larger set of fixes to the older stable, but I don't have a >> system running 4.9 stable. >> >> Is this the correct stable tree branch? >> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/?h=linux-4.9.y &g

Re: [PATCH 4.13 28/43] SMB3: Validate negotiate request must always be signed

2018-02-27 Thread Srivatsa S. Bhat
4.4, as I'm not that familiar with the internals of SMB/CIFS. ] > Is this the correct stable tree branch? > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/?h=linux-4.9.y > Yep! Regards, Srivatsa > On Tue, Feb 27, 2018 at 11:45 AM, Srivatsa S. Bhat > <

Re: [PATCH 4.13 28/43] SMB3: Validate negotiate request must always be signed

2018-02-27 Thread Srivatsa S. Bhat
On 2/27/18 4:40 AM, Greg Kroah-Hartman wrote: > On Tue, Feb 27, 2018 at 01:22:31AM -0800, Srivatsa S. Bhat wrote: >> On 2/27/18 12:54 AM, Greg Kroah-Hartman wrote: >>> On Mon, Feb 26, 2018 at 07:44:28PM -0800, Srivatsa S. Bhat wrote: >>>> On 1/3/18 6:15 PM, Srivatsa S

Re: [PATCH 4.13 28/43] SMB3: Validate negotiate request must always be signed

2018-02-27 Thread Srivatsa S. Bhat
On 2/27/18 12:54 AM, Greg Kroah-Hartman wrote: > On Mon, Feb 26, 2018 at 07:44:28PM -0800, Srivatsa S. Bhat wrote: >> On 1/3/18 6:15 PM, Srivatsa S. Bhat wrote: >>> On 11/1/17 8:18 AM, Greg Kroah-Hartman wrote: >>>> On Tue, Oct 31, 2017 at 03:02:11PM +0200, Th

Re: [PATCH 4.13 28/43] SMB3: Validate negotiate request must always be signed

2018-02-26 Thread Srivatsa S. Bhat
On 1/3/18 6:15 PM, Srivatsa S. Bhat wrote: > On 11/1/17 8:18 AM, Greg Kroah-Hartman wrote: >> On Tue, Oct 31, 2017 at 03:02:11PM +0200, Thomas Backlund wrote: >>> Den 31.10.2017 kl. 11:55, skrev Greg Kroah-Hartman: >>>> 4.13-stable review patch. If anyone has

Re: [PATCH 2/2] block, char_dev: Use correct format specifier for unsigned ints

2018-02-06 Thread Srivatsa S. Bhat
On 2/6/18 2:24 AM, Greg KH wrote: > On Mon, Feb 05, 2018 at 06:25:27PM -0800, Srivatsa S. Bhat wrote: >> From: Srivatsa S. Bhat <sriva...@csail.mit.edu> >> >> register_blkdev() and __register_chrdev_region() treat the major >> number as an unsigned int. So print i

[PATCH 2/2] block, char_dev: Use correct format specifier for unsigned ints

2018-02-05 Thread Srivatsa S. Bhat
From: Srivatsa S. Bhat <sriva...@csail.mit.edu> register_blkdev() and __register_chrdev_region() treat the major number as an unsigned int. So print it the same way to avoid absurd error statements such as: "... major requested (-1) is greater than the maximum (511) ..." (and als

[PATCH 1/2] char_dev: Fix off-by-one bugs in find_dynamic_major()

2018-02-05 Thread Srivatsa S. Bhat
From: Srivatsa S. Bhat <sriva...@csail.mit.edu> CHRDEV_MAJOR_DYN_END and CHRDEV_MAJOR_DYN_EXT_END are valid major numbers. So fix the loop iteration to include them in the search for free major numbers. While at it, also remove a redundant if condition ("cd->major != i"

Re: Change in register_blkdev() behavior

2018-02-01 Thread Srivatsa S. Bhat
On 2/1/18 5:10 PM, Logan Gunthorpe wrote: > > > On 01/02/18 05:23 PM, Srivatsa S. Bhat wrote: >> static int find_dynamic_major(void) >> { >> int i; >> struct char_device_struct *cd; >> >> for (i = ARRAY

Re: Change in register_blkdev() behavior

2018-02-01 Thread Srivatsa S. Bhat
On 1/31/18 6:24 AM, Greg KH wrote: > On Tue, Jan 30, 2018 at 04:56:32PM -0800, Srivatsa S. Bhat wrote: >> >> Hi, >> >> Before commit 133d55cdb2f "block: order /proc/devices by major number", >> if register_blkdev() was called with major = [1.

Re: Change in register_blkdev() behavior

2018-02-01 Thread Srivatsa S. Bhat
Hi Logan, On 1/30/18 5:26 PM, Logan Gunthorpe wrote: > > > On 30/01/18 05:56 PM, Srivatsa S. Bhat wrote: >> If the restriction on the major number was intentional, perhaps we >> should get the LTP testcase modified for kernel versions >= 4.14. >> Otherwise,

Change in register_blkdev() behavior

2018-01-30 Thread Srivatsa S. Bhat
Hi, Before commit 133d55cdb2f "block: order /proc/devices by major number", if register_blkdev() was called with major = [1..UINT_MAX], it used to succeed (provided the requested major number was actually free). However, while fixing the ordering in /proc/devices, commit 133d55cdb2f also added

Re: [PATCH 4.13 28/43] SMB3: Validate negotiate request must always be signed

2018-01-29 Thread Srivatsa S. Bhat
Hi Aurélien, On 1/19/18 5:23 AM, Aurélien Aptel wrote: > Hi, > > "Srivatsa S. Bhat" <sriva...@csail.mit.edu> writes: >>> Any thoughts on what is the right fix for stable kernels? Mounting SMB3 >>> shares works great on mainline (v4.15-rc5). It also work

Re: [PATCH 4.13 28/43] SMB3: Validate negotiate request must always be signed

2018-01-18 Thread Srivatsa S. Bhat
On 1/3/18 6:15 PM, Srivatsa S. Bhat wrote: > On 11/1/17 8:18 AM, Greg Kroah-Hartman wrote: >> On Tue, Oct 31, 2017 at 03:02:11PM +0200, Thomas Backlund wrote: >>> Den 31.10.2017 kl. 11:55, skrev Greg Kroah-Hartman: >>>> 4.13-stable review patch. If anyone has

Re: [PATCH 4.13 28/43] SMB3: Validate negotiate request must always be signed

2018-01-03 Thread Srivatsa S. Bhat
On 11/1/17 8:18 AM, Greg Kroah-Hartman wrote: > On Tue, Oct 31, 2017 at 03:02:11PM +0200, Thomas Backlund wrote: >> Den 31.10.2017 kl. 11:55, skrev Greg Kroah-Hartman: >>> 4.13-stable review patch. If anyone has any objections, please let me know. >>> >>> -- >>> >>> From: Steve

Re: [tip:smp/hotplug] cpu/hotplug: Restructure FROZEN state handling

2016-03-02 Thread Srivatsa S. Bhat
ger.kernel.org > Cc: Rik van Riel <r...@redhat.com> > Cc: Rafael Wysocki <rafael.j.wyso...@intel.com> > Cc: "Srivatsa S. Bhat" <sriva...@mit.edu> > Cc: Peter Zijlstra <pet...@infradead.org> > Cc: Arjan van de Ven <ar...@linux.intel.com> > Cc: Seb

Re: [tip:smp/hotplug] cpu/hotplug: Restructure FROZEN state handling

2016-03-02 Thread Srivatsa S. Bhat
ger.kernel.org > Cc: Rik van Riel <r...@redhat.com> > Cc: Rafael Wysocki <rafael.j.wyso...@intel.com> > Cc: "Srivatsa S. Bhat" <sriva...@mit.edu> > Cc: Peter Zijlstra <pet...@infradead.org> > Cc: Arjan van de Ven <ar...@linux.intel.com> > Cc: Seb

Re: [tip:smp/hotplug] cpu/hotplug: Split out cpu down functions

2016-03-02 Thread Srivatsa S. Bhat
y: Thomas Gleixner <t...@linutronix.de> > Cc: linux-a...@vger.kernel.org > Cc: Rik van Riel <r...@redhat.com> > Cc: Rafael Wysocki <rafael.j.wyso...@intel.com> > Cc: "Srivatsa S. Bhat" <sriva...@mit.edu> > Cc: Peter Zijlstra <pet...@infradead.org> > Cc:

Re: [tip:smp/hotplug] cpu/hotplug: Restructure cpu_up code

2016-03-02 Thread Srivatsa S. Bhat
...@linutronix.de> > Cc: linux-a...@vger.kernel.org > Cc: Rik van Riel <r...@redhat.com> > Cc: Rafael Wysocki <rafael.j.wyso...@intel.com> > Cc: "Srivatsa S. Bhat" <sriva...@mit.edu> > Cc: Peter Zijlstra <pet...@infradead.org> > Cc: Arjan

Re: [tip:sched/core] irq_work: Remove BUG_ON in irq_work_run()

2014-07-17 Thread Srivatsa S. Bhat
://lkml.org/lkml/2014/7/1/473 https://lkml.org/lkml/2014/7/4/16 I didn't find this fix in mainline yet, so I thought of sending a note. Thank you! Regards, Srivatsa S. Bhat Because of a collision with 8d056c48e486 (CPU hotplug, smp: flush any pending IPI callbacks before CPU offline), which

Re: [PATCH v2] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend

2014-07-16 Thread Srivatsa S. Bhat
On 07/15/2014 11:05 PM, skan...@codeaurora.org wrote: Srivatsa S. Bhat wrote: On 07/15/2014 11:06 AM, Saravana Kannan wrote: On 07/14/2014 09:35 PM, Viresh Kumar wrote: On 15 July 2014 00:38, Saravana Kannan skan...@codeaurora.org wrote: Yeah, it definitely crashes if policy-cpu

Re: [PATCH v2] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend

2014-07-16 Thread Srivatsa S. Bhat
On 07/16/2014 11:14 AM, Viresh Kumar wrote: On 15 July 2014 12:28, Srivatsa S. Bhat sriva...@mit.edu wrote: Wait, allowing an offline CPU to be the policy-cpu (i.e., the CPU which is considered as the master of the policy/group) is just absurd. Yeah, that was as Absurd as I am :) I have

Re: [PATCH v3 1/2] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend

2014-07-16 Thread Srivatsa S. Bhat
doesn't re-introduce those deadlock possibilities! break; } } I am still not sure if everything will work as expected as I seriously doubt my reviewing capabilities. There might be corner cases which I am still missing. Regards, Srivatsa S

Re: [PATCH v3 1/2] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend

2014-07-16 Thread Srivatsa S. Bhat
On 07/16/2014 06:43 PM, Viresh Kumar wrote: On 16 July 2014 16:46, Srivatsa S. Bhat sriva...@mit.edu wrote: Short answer: If the sysfs directory has already been created by cpufreq, then yes, it will remain as it is. However, if the online operation failed before that, then cpufreq won't know

Re: [PATCH v2] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend

2014-07-15 Thread Srivatsa S. Bhat
:-) Regards, Srivatsa S. Bhat So, even if we are sure cpufreq.c is fine, it's 137 other uses spread across all the other files. I definitely don't want to try and fix those as part of this patch. Way too risky and hard to get the test coverage it would need. Even some of the acpi cpufreq drivers seem

Re: [PATCH v2] cpufreq: Don't destroy/realloc policy/sysfs on hotplug/suspend

2014-07-11 Thread Srivatsa S. Bhat
I had a hard time reviewing all of this in one go. Thank you for taking up this work! Regards, Srivatsa S. Bhat I should also be able to remove get_online_cpus() in the store function and replace it with just a check for policy-governor_enabled. That should theoretically reduce some

Re: [PATCH] cpufreq: report driver's successful {un}registration

2014-07-10 Thread Srivatsa S. Bhat
); if (cpufreq_boost_supported()) Regards, Srivatsa S. Bhat -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org

Re: [PATCH 2/6] irq_work: Implement remote queueing

2014-06-25 Thread Srivatsa S. Bhat
context (which has irqs disabled). I guess you meant to remove the in_irq() check inside irq_work_run() instead? Regards, Srivatsa S. Bhat if (llist_empty(list)) return; -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message

Re: [migration] kernel BUG at kernel/irq_work.c:175!

2014-06-25 Thread Srivatsa S. Bhat
for that. Regards, Srivatsa S. Bhat git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master commit 68c90b2c635f18ad51ae7440162f6c082ea1288d Merge: f08af6f ec11f8c Author: Stephen Rothwell s...@canb.auug.org.au AuthorDate: Mon Jun 23 14:12:48 2014 +1000 Merge branch 'akpm

Re: [PATCH 2/6] irq_work: Implement remote queueing

2014-06-25 Thread Srivatsa S. Bhat
On 06/25/2014 03:09 PM, Peter Zijlstra wrote: On Wed, Jun 25, 2014 at 11:36:57AM +0200, Peter Zijlstra wrote: On Wed, Jun 25, 2014 at 12:07:05PM +0530, Srivatsa S. Bhat wrote: I don't think irqs_disabled() is the problematic condition, since hotplug_cfg() invokes irq_work_run() from CPU_DYING

Re: [PATCH 2/6] irq_work: Implement remote queueing

2014-06-25 Thread Srivatsa S. Bhat
On 06/25/2014 03:20 PM, Srivatsa S. Bhat wrote: On 06/25/2014 03:09 PM, Peter Zijlstra wrote: On Wed, Jun 25, 2014 at 11:36:57AM +0200, Peter Zijlstra wrote: On Wed, Jun 25, 2014 at 12:07:05PM +0530, Srivatsa S. Bhat wrote: I don't think irqs_disabled() is the problematic condition, since

Re: [PATCH 2/6] irq_work: Implement remote queueing

2014-06-25 Thread Srivatsa S. Bhat
On 06/25/2014 03:49 PM, Peter Zijlstra wrote: On Wed, Jun 25, 2014 at 03:24:11PM +0530, Srivatsa S. Bhat wrote: Wait, that was a stupid idea. hotplug_cfd() already invokes irq_work_run indirectly via flush_smp_call_function_queue(). So irq_work_cpu_notify() doesn't need to invoke it again

Re: [PATCH 2/6] irq_work: Implement remote queueing

2014-06-25 Thread Srivatsa S. Bhat
On 06/25/2014 10:08 PM, Peter Zijlstra wrote: On Wed, Jun 25, 2014 at 10:23:21AM -0600, Stephen Warren wrote: On 06/25/2014 04:19 AM, Peter Zijlstra wrote: On Wed, Jun 25, 2014 at 03:24:11PM +0530, Srivatsa S. Bhat wrote: Wait, that was a stupid idea. hotplug_cfd() already invokes irq_work_run

Re: [PATCH v7 2/2] CPU hotplug, smp: Flush any pending IPI callbacks before CPU offline

2014-06-25 Thread Srivatsa S. Bhat
On 06/25/2014 09:12 PM, Sasha Levin wrote: On 05/26/2014 07:08 AM, Srivatsa S. Bhat wrote: During CPU offline, in stop-machine, we don't enforce any rule in the _DISABLE_IRQ stage, regarding the order in which the outgoing CPU and the other CPUs disable their local interrupts. Hence, we can

Re: Boot warnings on exynos5420 based boards

2014-06-17 Thread Srivatsa S. Bhat
: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com [PATCH] CPU hotplug, smp: Execute any pending IPI callbacks before CPU offline There is a race between the CPU offline code (within stop-machine) and the smp-call-function code, which can lead to getting IPIs on the outgoing CPU, *after* it has gone

Re: Boot warnings on exynos5420 based boards

2014-06-17 Thread Srivatsa S. Bhat
/srivatsabhat/linux.git ipi-offline-fix-v3 ] From: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com [PATCH] CPU hotplug, smp: Execute any pending IPI callbacks before CPU offline There is a race between the CPU offline

Re: Boot warnings on exynos5420 based boards

2014-06-17 Thread Srivatsa S. Bhat
On 06/17/2014 05:25 PM, Sachin Kamat wrote: Hi Srivatsa, On Tue, Jun 17, 2014 at 3:24 PM, Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com wrote: On 06/17/2014 03:03 PM, Sachin Kamat wrote: Below is an updated patch, please let me know how it goes. (You'll have to revert c47a9d7cca first

Re: [CPU hotplug, smp] WARNING: CPU: 1 PID: 0 at kernel/smp.c:209 generic_smp_call_function_single_interrupt()

2014-06-15 Thread Srivatsa S. Bhat
On 06/15/2014 12:56 PM, Jet Chen wrote: Hi Srivatsa, 0day kernel testing robot got the below dmesg and the first bad commit is git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master commit ab7a42783d939cdbe729c18ab32dbf0d25746ea2 Author: Srivatsa S. Bhat srivatsa.b

Re: [PATCH] powerpc, kexec: Fix Processor X is stuck issue during kexec from ST mode

2014-06-12 Thread Srivatsa S. Bhat
Hi Joel, On 06/12/2014 12:09 PM, Joel Stanley wrote: Hi Srivatsa, On Sat, Jun 7, 2014 at 7:16 AM, Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com wrote: And with the following hunk added (which I had forgotten earlier), it worked just fine on powernv :-) How are the patches coming

[PATCH v2] CPU hotplug, smp: Execute any pending IPI callbacks before CPU offline

2014-06-10 Thread Srivatsa S. Bhat
-style fixes] Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com Suggested-by: Frederic Weisbecker fweis...@gmail.com Cc: Paul E. McKenney paul...@linux.vnet.ibm.com Cc: Borislav Petkov b...@suse.de Cc: Christoph Hellwig h...@infradead.org Cc: Frederic Weisbecker fweis...@gmail.com Cc

Re: [PATCH] cpufreq: governor: remove copy_prev_load from 'struct cpu_dbs_common_info'

2014-06-09 Thread Srivatsa S. Bhat
to the current interval only once, upon the first wake-up from idle. */ - bool copy_prev_load; + unsigned int prev_load; struct cpufreq_policy *cur_policy; struct delayed_work work; /* Thank you! Regards, Srivatsa S. Bhat -- To unsubscribe from this list: send

Re: [PATCH Resend] cpufreq: governor: remove copy_prev_load from 'struct cpu_dbs_common_info'

2014-06-09 Thread Srivatsa S. Bhat
+ if (unlikely(wall_time (2 * sampling_rate) + j_cdbs-prev_load)) { Signed-off-by: Viresh Kumar viresh.ku...@linaro.org --- Resend: Updated comments/logs as suggested by Srivatsa. Looks good! Reviewed-by: Srivatsa S. Bhat srivatsa.b

[PATCH] PM / Documentation: Update Srivatsa S. Bhat's email address

2014-06-09 Thread Srivatsa S. Bhat
My @linux.vnet.ibm.com email address is going to disappear soon, as I will be beginning my M.S./PhD studies at MIT in a few months. So update my email address in the documentation. Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com Signed-off-by: Srivatsa S. Bhat sriva...@mit.edu

Re: [PATCH] PM / Documentation: Update Srivatsa S. Bhat's email address

2014-06-09 Thread Srivatsa S. Bhat
On 06/09/2014 04:02 PM, Viresh Kumar wrote: On 9 June 2014 15:54, Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com wrote: My @linux.vnet.ibm.com email address is going to disappear soon, as I will be beginning my M.S./PhD studies at MIT in a few months. So update my email address

Re: [PATCH] PM / Documentation: Update Srivatsa S. Bhat's email address

2014-06-09 Thread Srivatsa S. Bhat
On 06/09/2014 04:58 PM, Rafael J. Wysocki wrote: On Monday, June 09, 2014 03:54:49 PM Srivatsa S. Bhat wrote: My @linux.vnet.ibm.com email address is going to disappear soon, as I will be beginning my M.S./PhD studies at MIT in a few months. Congratulations! Thanks a lot! :-) So update

Re: [PATCH] PM / Documentation: Update Srivatsa S. Bhat's email address

2014-06-09 Thread Srivatsa S. Bhat
On 06/09/2014 04:53 PM, Srivatsa S. Bhat wrote: But what about .mailmap? Can I add to that? I guess I can, since that's not related to copyrights and it is meant to handle email-id changes and such. Ah, nevermind.. mailmap only helps if we want to update our name (if it was mis-spelled in any

[PATCH] PM / Documentation: Update copyright in suspend-and-cpuhotplug.txt

2014-06-09 Thread Srivatsa S. Bhat
Extend the year to 2014 in the copyright. Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com --- Documentation/power/suspend-and-cpuhotplug.txt |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/power/suspend-and-cpuhotplug.txt b/Documentation

Re: [PATCH] cpufreq: governor: Be friendly towards latency-sensitive bursty workloads

2014-06-07 Thread Srivatsa S. Bhat
that implements that logic (and it also fixes the 64 bit division problem reported by Fengguang's build robot in the v2 of the patch). I'll test this patch and then send out the v3 later today. Please let me know your thoughts! Regards, Srivatsa S. Bhat

[PATCH v3] cpufreq: governor: Be friendly towards latency-sensitive bursty workloads

2014-06-07 Thread Srivatsa S. Bhat
not reduce the idle time or idle residency; and the high frequency of the CPU when it goes to cpu-idle does not affect/hurt the power-savings of deep idle states). Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com Reviewed-by: Gautham R. Shenoy e...@linux.vnet.ibm.com Acked-by: Viresh Kumar

Re: [PATCH] smp, ipi: Speed up IPI handling by invoking the callbacks in reverse order

2014-06-06 Thread Srivatsa S. Bhat
On 06/05/2014 12:56 PM, Peter Zijlstra wrote: On Thu, Jun 05, 2014 at 01:37:25AM +0530, Srivatsa S. Bhat wrote: On 06/05/2014 01:17 AM, Peter Zijlstra wrote: On Thu, Jun 05, 2014 at 01:09:35AM +0530, Srivatsa S. Bhat wrote: The current implementation of lockless list (llist) has a drawback

Re: [PATCH v2 2/2] powerpc/powernv : Disable subcore for UP configs

2014-06-06 Thread Srivatsa S. Bhat
subcore.o and subcore-asm.o for UP builds. Signed-off-by: Shreyas B. Prabhu shre...@linux.vnet.ibm.com Reviewed-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com Regards, Srivatsa S. Bhat --- Changes in v2: Excluding subcore-asm.o which is part of the subcore feature for UP configs

Re: [PATCH] powerpc, kexec: Fix Processor X is stuck issue during kexec from ST mode

2014-06-06 Thread Srivatsa S. Bhat
On 06/04/2014 03:39 AM, Benjamin Herrenschmidt wrote: On Wed, 2014-06-04 at 01:58 +0530, Srivatsa S. Bhat wrote: Yep, that makes sense. But unfortunately I don't have enough insight into why exactly powerpc has to online the CPUs before doing a kexec. I just know from the commit log

Re: [PATCH] powerpc, kexec: Fix Processor X is stuck issue during kexec from ST mode

2014-06-06 Thread Srivatsa S. Bhat
On 06/04/2014 07:16 PM, Vivek Goyal wrote: On Wed, Jun 04, 2014 at 08:09:25AM +1000, Benjamin Herrenschmidt wrote: On Wed, 2014-06-04 at 01:58 +0530, Srivatsa S. Bhat wrote: Yep, that makes sense. But unfortunately I don't have enough insight into why exactly powerpc has to online the CPUs

Re: [PATCH] powerpc, kexec: Fix Processor X is stuck issue during kexec from ST mode

2014-06-06 Thread Srivatsa S. Bhat
On 06/04/2014 07:11 PM, Vivek Goyal wrote: On Wed, Jun 04, 2014 at 01:58:40AM +0530, Srivatsa S. Bhat wrote: On 05/28/2014 07:01 PM, Vivek Goyal wrote: On Tue, May 27, 2014 at 04:25:34PM +0530, Srivatsa S. Bhat wrote: If we try to perform a kexec when the machine is in ST (Single-Threaded

Re: [PATCH] powerpc, kexec: Fix Processor X is stuck issue during kexec from ST mode

2014-06-06 Thread Srivatsa S. Bhat
On 06/06/2014 05:59 PM, Srivatsa S. Bhat wrote: +bool kexec_cpu_wake(void) +{ + kexec_smp_down(NULL); + + /* NOTREACHED */ + return true; +} + This function doesn't have to return anything, so we can define it as void. The bool is a remnant of my previous attempt at making

Re: [PATCH] powerpc, kexec: Fix Processor X is stuck issue during kexec from ST mode

2014-06-06 Thread Srivatsa S. Bhat
On 06/06/2014 11:57 PM, Vivek Goyal wrote: On Fri, Jun 06, 2014 at 06:00:43PM +0530, Srivatsa S. Bhat wrote: On 06/04/2014 07:16 PM, Vivek Goyal wrote: On Wed, Jun 04, 2014 at 08:09:25AM +1000, Benjamin Herrenschmidt wrote: On Wed, 2014-06-04 at 01:58 +0530, Srivatsa S. Bhat wrote: Yep

Re: [PATCH] powerpc, kexec: Fix Processor X is stuck issue during kexec from ST mode

2014-06-06 Thread Srivatsa S. Bhat
On 06/06/2014 05:59 PM, Srivatsa S. Bhat wrote: On 06/04/2014 03:39 AM, Benjamin Herrenschmidt wrote: On Wed, 2014-06-04 at 01:58 +0530, Srivatsa S. Bhat wrote: Yep, that makes sense. But unfortunately I don't have enough insight into why exactly powerpc has to online the CPUs before doing

Re: [PATCH v2] cpufreq: governor: Be friendly towards latency-sensitive bursty workloads

2014-06-06 Thread Srivatsa S. Bhat
On 06/07/2014 03:07 AM, Rafael J. Wysocki wrote: On Wednesday, June 04, 2014 03:17:00 AM Srivatsa S. Bhat wrote: Cpufreq governors like the ondemand governor calculate the load on the CPU periodically by employing deferrable timers. A deferrable timer won't fire if the CPU is completely idle

[PATCH] smp, ipi: Speed up IPI handling by invoking the callbacks in reverse order

2014-06-04 Thread Srivatsa S. Bhat
. Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com --- kernel/smp.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/kernel/smp.c b/kernel/smp.c index 5295388..be55094 100644 --- a/kernel/smp.c +++ b/kernel/smp.c @@ -229,7 +229,6 @@ static void

Re: [PATCH] smp, ipi: Speed up IPI handling by invoking the callbacks in reverse order

2014-06-04 Thread Srivatsa S. Bhat
On 06/05/2014 01:17 AM, Peter Zijlstra wrote: On Thu, Jun 05, 2014 at 01:09:35AM +0530, Srivatsa S. Bhat wrote: The current implementation of lockless list (llist) has a drawback: if we want to traverse the list in FIFO order (oldest to newest), we need to reverse the list first (and this can

Re: [PATCH] cpufreq: governor: Be friendly towards latency-sensitive bursty workloads

2014-06-03 Thread Srivatsa S. Bhat
On 06/03/2014 01:48 PM, Viresh Kumar wrote: On 27 May 2014 02:23, Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com wrote: Looks fine, some nits.. diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c -void dbs_check_cpu(struct dbs_data *dbs_data, int cpu

Re: [PATCH] cpufreq: governor: Be friendly towards latency-sensitive bursty workloads

2014-06-03 Thread Srivatsa S. Bhat
On 06/03/2014 03:09 PM, Viresh Kumar wrote: On 3 June 2014 15:02, Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com wrote: diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c index e1c6433..3e8588f 100644 --- a/drivers/cpufreq/cpufreq_governor.c +++ b

Re: [PATCH] cpufreq: governor: Be friendly towards latency-sensitive bursty workloads

2014-06-03 Thread Srivatsa S. Bhat
On 06/03/2014 03:38 PM, Viresh Kumar wrote: On 3 June 2014 15:34, Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com wrote: Well, the method I used keeps the organization such that the code following the comment does precisely what the comment says (i.e, get the sampling_rate, fetch

Re: [PATCH] cpufreq: governor: Be friendly towards latency-sensitive bursty workloads

2014-06-03 Thread Srivatsa S. Bhat
On 06/03/2014 03:46 PM, Viresh Kumar wrote: On 3 June 2014 15:43, Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com wrote: diff --git a/drivers/cpufreq/cpufreq_governor.c b/drivers/cpufreq/cpufreq_governor.c index e1c6433..2597bbe 100644 --- a/drivers/cpufreq/cpufreq_governor.c +++ b

Re: [PATCH] powerpc, kexec: Fix Processor X is stuck issue during kexec from ST mode

2014-06-03 Thread Srivatsa S. Bhat
On 05/28/2014 07:01 PM, Vivek Goyal wrote: On Tue, May 27, 2014 at 04:25:34PM +0530, Srivatsa S. Bhat wrote: If we try to perform a kexec when the machine is in ST (Single-Threaded) mode (ppc64_cpu --smt=off), the kexec operation doesn't succeed properly, and we get the following messages

[PATCH v2] cpufreq: governor: Be friendly towards latency-sensitive bursty workloads

2014-06-03 Thread Srivatsa S. Bhat
or idle residency; and the high frequency of the CPU when it goes to cpu-idle does not affect/hurt the power-savings of deep idle states). Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com Reviewed-by: Gautham R. Shenoy e...@linux.vnet.ibm.com Acked-by: Viresh Kumar viresh.ku

Re: [PATCH] cpufreq: governor: Be friendly towards latency-sensitive bursty workloads

2014-06-02 Thread Srivatsa S. Bhat
On 06/02/2014 01:03 PM, Gautham R Shenoy wrote: Hi, On Tue, May 27, 2014 at 02:23:38AM +0530, Srivatsa S. Bhat wrote: [..snip..] Experimental results: I ran a modified version of ebizzy (called 'sleeping-ebizzy') that sleeps in between its execution such that its

Re: [PATCH] cpufreq: governor: Be friendly towards latency-sensitive bursty workloads

2014-06-02 Thread Srivatsa S. Bhat
On 06/03/2014 10:46 AM, Gautham R Shenoy wrote: On Mon, Jun 02, 2014 at 01:45:38PM +0530, Srivatsa S. Bhat wrote: On 06/02/2014 01:03 PM, Gautham R Shenoy wrote: Hi, On Tue, May 27, 2014 at 02:23:38AM +0530, Srivatsa S. Bhat wrote: [..snip..] Experimental results

[PATCH] powerpc, kexec: Fix Processor X is stuck issue during kexec from ST mode

2014-05-27 Thread Srivatsa S. Bhat
to reboot cpu) Cc: sta...@vger.kernel.org Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com --- arch/powerpc/kernel/machine_kexec_64.c |2 +- kernel/kexec.c |8 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/kernel

Re: [PATCH 3/3][update] PM / sleep: Introduce command line argument for sleep state enumeration

2014-05-26 Thread Srivatsa S. Bhat
above, I hope that this is a temporary solution and we can remove or enhance this once all those user-space frameworks have been fixed. Regards, Srivatsa S. Bhat For this reason, add a new kernel command line argument, relative_sleep_states, allowing the users of those systems to change

Re: [PATCH 3/3][update] PM / sleep: Introduce command line argument for sleep state enumeration

2014-05-26 Thread Srivatsa S. Bhat
On 05/26/2014 04:30 PM, Rafael J. Wysocki wrote: On Monday, May 26, 2014 02:01:14 PM Srivatsa S. Bhat wrote: On 05/23/2014 06:33 PM, Rafael J. Wysocki wrote: From: Rafael J. Wysocki rafael.j.wyso...@intel.com On some systems the platform doesn't support neither PM_SUSPEND_MEM nor

[PATCH v7 1/2] smp: Print more useful debug info upon receiving IPI on an offline CPU

2014-05-26 Thread Srivatsa S. Bhat
linked list and print out the payload (i.e., the name of the function which was supposed to be executed by the target CPU). This would give us an insight as to who might have sent the IPI and help us debug this further. Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com --- kernel

[PATCH v7 0/2] CPU hotplug: Fix the long-standing IPI to offline CPU issue

2014-05-26 Thread Srivatsa S. Bhat
state into two: MULTI_STOP_DISABLE_IRQ_INACTIVE and MULTI_STOP_DISABLE_IRQ_ACTIVE, and used this framework to ensure that the CPU going offline always disables its interrupts last. Suggested by Tejun Heo. v1 and v2: https://lkml.org/lkml/2014/5/6/474 Srivatsa S. Bhat (2): smp: Print more

[PATCH v7 2/2] CPU hotplug, smp: Flush any pending IPI callbacks before CPU offline

2014-05-26 Thread Srivatsa S. Bhat
-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com --- kernel/smp.c | 56 1 file changed, 48 insertions(+), 8 deletions(-) diff --git a/kernel/smp.c b/kernel/smp.c index 306f818..5295388 100644 --- a/kernel/smp.c +++ b/kernel/smp.c @@ -29,6

[PATCH] cpufreq: governor: Be friendly towards latency-sensitive bursty workloads

2014-05-26 Thread Srivatsa S. Bhat
or idle residency; and the high frequency of the CPU when it goes to cpu-idle does not affect/hurt the power-savings of deep idle states). Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com --- drivers/cpufreq/cpufreq_conservative.c |2 +- drivers/cpufreq/cpufreq_governor.c

Re: [PATCH] cpufreq: governor: Be friendly towards latency-sensitive bursty workloads

2014-05-26 Thread Srivatsa S. Bhat
On 05/27/2014 04:57 AM, Rafael J. Wysocki wrote: Hi Srivatsa, On Tuesday, May 27, 2014 02:23:38 AM Srivatsa S. Bhat wrote: Cpufreq governors like the ondemand governor calculate the load on the CPU periodically by employing deferrable timers. A deferrable timer won't fire if the CPU

[PATCH v6 3/3] CPU hotplug, smp: Flush any pending IPI callbacks before CPU offline

2014-05-23 Thread Srivatsa S. Bhat
didn't want to add an uglier-looking double-underscore prefixed version. 'flush_smp_call_function_queue' is a much more meaningful name). Suggested-by: Frederic Weisbecker fweis...@gmail.com Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com --- kernel/smp.c | 59

[PATCH v6 1/3] smp: Print more useful debug info upon receiving IPI on an offline CPU

2014-05-23 Thread Srivatsa S. Bhat
linked list and print out the payload (i.e., the name of the function which was supposed to be executed by the target CPU). This would give us an insight as to who might have sent the IPI and help us debug this further. Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com --- kernel

[PATCH v6 0/3] CPU hotplug: Fix the long-standing IPI to offline CPU issue

2014-05-23 Thread Srivatsa S. Bhat
disables its interrupts last. Suggested by Tejun Heo. v1 and v2: https://lkml.org/lkml/2014/5/6/474 Srivatsa S. Bhat (3): smp: Print more useful debug info upon receiving IPI on an offline CPU CPU hotplug, stop-machine: Plug race-window that leads to IPI-to-offline-CPU CPU

[PATCH v6 2/3] CPU hotplug, stop-machine: Plug race-window that leads to IPI-to-offline-CPU

2014-05-23 Thread Srivatsa S. Bhat
future invocations of smp_call_function() and friends will automatically prune that CPU out. Thus, we can guarantee that no CPU will end up *inadvertently* sending IPIs to an offline CPU. Signed-off-by: Srivatsa S. Bhat srivatsa.b...@linux.vnet.ibm.com --- kernel/stop_machine.c | 39

Re: [PATCH v6 2/3] CPU hotplug, stop-machine: Plug race-window that leads to IPI-to-offline-CPU

2014-05-23 Thread Srivatsa S. Bhat
On 05/23/2014 06:52 PM, Frederic Weisbecker wrote: On Fri, May 23, 2014 at 03:42:20PM +0530, Srivatsa S. Bhat wrote: During CPU offline, stop-machine is used to take control over all the online CPUs (via the per-cpu stopper thread) and then run take_cpu_down() on the CPU that is to be taken

Re: [PATCH v6 3/3] CPU hotplug, smp: Flush any pending IPI callbacks before CPU offline

2014-05-23 Thread Srivatsa S. Bhat
On 05/23/2014 06:57 PM, Frederic Weisbecker wrote: On Fri, May 23, 2014 at 03:42:35PM +0530, Srivatsa S. Bhat wrote: During CPU offline, in the stop-machine loop, we use 2 separate stages to disable interrupts, to ensure that the CPU going offline doesn't get any new IPIs from the other CPUs

Re: [PATCH v6 2/3] CPU hotplug, stop-machine: Plug race-window that leads to IPI-to-offline-CPU

2014-05-23 Thread Srivatsa S. Bhat
On 05/23/2014 08:42 PM, Peter Zijlstra wrote: On Fri, May 23, 2014 at 08:15:35PM +0530, Srivatsa S. Bhat wrote: + * During CPU offline, we don't want the other CPUs to send + * IPIs to the active_cpu (the outgoing CPU) *after* it has + * disabled interrupts

Re: [PATCH v6 2/3] CPU hotplug, stop-machine: Plug race-window that leads to IPI-to-offline-CPU

2014-05-23 Thread Srivatsa S. Bhat
On 05/23/2014 08:34 PM, Frederic Weisbecker wrote: On Fri, May 23, 2014 at 08:15:35PM +0530, Srivatsa S. Bhat wrote: On 05/23/2014 06:52 PM, Frederic Weisbecker wrote: On Fri, May 23, 2014 at 03:42:20PM +0530, Srivatsa S. Bhat wrote: During CPU offline, stop-machine is used to take control

Re: [PATCH v6 2/3] CPU hotplug, stop-machine: Plug race-window that leads to IPI-to-offline-CPU

2014-05-23 Thread Srivatsa S. Bhat
On 05/23/2014 08:51 PM, Peter Zijlstra wrote: On Fri, May 23, 2014 at 03:42:20PM +0530, Srivatsa S. Bhat wrote: Re-enable interrupts Re-enable interrupts The pending IPI is noted

Re: [PATCH v6 2/3] CPU hotplug, stop-machine: Plug race-window that leads to IPI-to-offline-CPU

2014-05-23 Thread Srivatsa S. Bhat
On 05/23/2014 09:01 PM, Peter Zijlstra wrote: On Fri, May 23, 2014 at 08:48:07PM +0530, Srivatsa S. Bhat wrote: On 05/23/2014 08:42 PM, Peter Zijlstra wrote: On Fri, May 23, 2014 at 08:15:35PM +0530, Srivatsa S. Bhat wrote: + * During CPU offline, we don't want the other CPUs

Re: [PATCH v6 2/3] CPU hotplug, stop-machine: Plug race-window that leads to IPI-to-offline-CPU

2014-05-23 Thread Srivatsa S. Bhat
On 05/23/2014 09:03 PM, Srivatsa S. Bhat wrote: On 05/23/2014 09:01 PM, Peter Zijlstra wrote: On Fri, May 23, 2014 at 08:48:07PM +0530, Srivatsa S. Bhat wrote: On 05/23/2014 08:42 PM, Peter Zijlstra wrote: On Fri, May 23, 2014 at 08:15:35PM +0530, Srivatsa S. Bhat wrote

Re: [PATCH v6 2/3] CPU hotplug, stop-machine: Plug race-window that leads to IPI-to-offline-CPU

2014-05-23 Thread Srivatsa S. Bhat
On 05/23/2014 09:18 PM, Peter Zijlstra wrote: On Fri, May 23, 2014 at 09:07:18PM +0530, Srivatsa S. Bhat wrote: On 05/23/2014 09:03 PM, Srivatsa S. Bhat wrote: On 05/23/2014 09:01 PM, Peter Zijlstra wrote: On Fri, May 23, 2014 at 08:48:07PM +0530, Srivatsa S. Bhat wrote: On 05/23/2014 08:42

Re: [PATCH v6 2/3] CPU hotplug, stop-machine: Plug race-window that leads to IPI-to-offline-CPU

2014-05-23 Thread Srivatsa S. Bhat
On 05/23/2014 09:23 PM, Srivatsa S. Bhat wrote: On 05/23/2014 09:18 PM, Peter Zijlstra wrote: On Fri, May 23, 2014 at 09:07:18PM +0530, Srivatsa S. Bhat wrote: On 05/23/2014 09:03 PM, Srivatsa S. Bhat wrote: On 05/23/2014 09:01 PM, Peter Zijlstra wrote: On Fri, May 23, 2014 at 08:48:07PM

Re: [PATCH] intel_rapl: Correct hotplug correction

2014-05-22 Thread Srivatsa S. Bhat
() from intel-rapl driver. Jacob/Srinivas, is the above assumption correct for rapl? Regards, Srivatsa S. Bhat Let me do what was supposed to be done. Cc: Srinivas Pandruvada srinivas.pandruv...@linux.intel.com Cc: Ingo Molnar mi...@kernel.org Cc: Jacob Pan jacob.jun@linux.intel.com Cc

Re: [PATCH] intel_rapl: Correct hotplug correction

2014-05-22 Thread Srivatsa S. Bhat
On 05/22/2014 03:38 PM, Borislav Petkov wrote: On Thu, May 22, 2014 at 03:13:46PM +0530, Srivatsa S. Bhat wrote: On 05/22/2014 02:53 PM, Borislav Petkov wrote: From: Borislav Petkov b...@suse.de So 009f225ef050 (powercap, intel-rapl: Fix CPU hotplug callback registration) says how get_

Re: [PATCH] x86, MCE: Kill CPU_POST_DEAD

2014-05-22 Thread Srivatsa S. Bhat
.. the original commit 88ccbedd9 didn't explain that. Either way, cmci_rediscover() doesn't seem to have any reason why it should be called specifically in the POST_DEAD stage only. So I'm sure we can get rid of that one way or other easily. Regards, Srivatsa S. Bhat So we were working around some

Re: [PATCH] intel_rapl: Correct hotplug correction

2014-05-22 Thread Srivatsa S. Bhat
On 05/22/2014 06:02 PM, Peter Zijlstra wrote: On Thu, May 22, 2014 at 05:24:33PM +0530, Srivatsa S. Bhat wrote: Yeah, its complicated and perhaps we can do much better than that. But I'll try to explain why there are so many different locks in the existing code. [...] So I think we can

Re: [PATCH] x86, MCE: Kill CPU_POST_DEAD

2014-05-22 Thread Srivatsa S. Bhat
On 05/23/2014 03:01 AM, Borislav Petkov wrote: On Fri, May 23, 2014 at 02:43:31AM +0530, Srivatsa S. Bhat wrote: After you move the cmci_rediscover() call, it is now in a place where we are no longer ignoring frozen (i.e. the old placement did the rediscover even if the CPU_TASKS_FROZEN

  1   2   3   4   5   6   7   8   9   10   >