On 10/14/19 12:24 PM, Steven Rostedt wrote:
> On Thu, 10 Oct 2019 11:51:17 -0700
> "Srivatsa S. Bhat" wrote:
>
>> From: Srivatsa S. Bhat (VMware)
>>
>> Update the source file name in the comments, and fix a grammatical
>> error.
>
> Patch
From: Srivatsa S. Bhat (VMware)
Update the source file name in the comments, and fix a grammatical
error.
Signed-off-by: Srivatsa S. Bhat (VMware)
---
kernel/trace/trace_hwlat.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace_hwlat.c b/kernel
From: Srivatsa S. Bhat (VMware)
max_latency is intended to record the maximum ever observed hardware
latency, which may occur in either part of the loop (inner/outer). So
we need to also consider the outer-loop sample when updating
max_latency.
Fixes: e7c15cd8a113 ("tracing: Added har
From: Srivatsa S. Bhat (VMware)
nmi_total_ts is supposed to record the total time spent in *all* NMIs
that occur on the given CPU during the (active portion of the)
sampling window. However, the code seems to be overwriting this
variable for each NMI, thereby only recording the time spent
subtle bug causing loss of control over I/O bandwidths
>
Thanks a lot for these patches, Paolo!
Would you mind adding:
Reported-by: Srivatsa S. Bhat (VMware)
Tested-by: Srivatsa S. Bhat (VMware)
to the first 5 patches, as appropriate?
Thank you!
>
> [1] https://lkml.org/lkml/2019/
On 5/22/19 2:12 AM, Paolo Valente wrote:
>
>> Il giorno 22 mag 2019, alle ore 11:02, Srivatsa S. Bhat
>> ha scritto:
>>
>>
>> Let's continue here on LKML itself.
>
> Just done :)
>
>> The only reason I created the
>> bugzilla
On 5/22/19 2:09 AM, Paolo Valente wrote:
>
> First, thank you very much for testing my patches, and, above all, for
> sharing those huge traces!
>
> According to the your traces, the residual 20% lower throughput that you
> record is due to the fact that the BFQ injection mechanism takes a few
>
From: Srivatsa S. Bhat (VMware)
To disable a tracing option using the trace_options file, the option
name needs to be prefixed with 'no', and not suffixed, as the README
states. Fix it.
Signed-off-by: Srivatsa S. Bhat (VMware)
---
kernel/trace/trace.c |2 +-
1 file changed, 1 insertion
...@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
...@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
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
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
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
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
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
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
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
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
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
indows can fail the request if you send it unsigned
See kernel bugzilla bug 197311
[ Fixed up for kernel version 4.4 ]
CC: Stable
Acked-by: Ronnie Sahlberg
Signed-off-by: Steve French
Signed-off-by: Srivatsa S. Bhat
---
fs/cifs/smb2pdu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/fs/c
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
> 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
>>
>> On Tue, Feb 2
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
> <
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
> wrote:
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
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
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
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
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
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
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
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
>>
>> register_blkdev() and __register_chrdev_region() treat the major
>> number as an unsigned int. So print it the same way to avoid
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
From: Srivatsa S. Bhat
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 also fix off-by-one bugs in the er
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"
From: Srivatsa S. Bhat
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"),
as it will never be true
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
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
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.
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.
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,
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,
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
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
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
Hi Aurélien,
On 1/19/18 5:23 AM, Aurélien Aptel wrote:
> Hi,
>
> "Srivatsa S. Bhat" writes:
>>> Any thoughts on what is the right fix for stable kernels? Mounting SMB3
>>> shares works great on mainline (v4.15-rc5). It also works on 4.4.109 if
>>&g
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
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
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
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
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
n extra variable which is updated under
> the hotplug lock and let the users interested deal with it w/o
> imposing that extra state checks on everyone.
>
> Signed-off-by: Thomas Gleixner
> Cc: linux-a...@vger.kernel.org
> Cc: Rik van Riel
> Cc: Rafael Wysocki
> Cc: "S
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
n extra variable which is updated under
> the hotplug lock and let the users interested deal with it w/o
> imposing that extra state checks on everyone.
>
> Signed-off-by: Thomas Gleixner
> Cc: linux-a...@vger.kernel.org
> Cc: Rik van Riel
> Cc: Rafael Wysocki
> Cc: "S
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:
Cc: Rik van Riel
> Cc: Rafael Wysocki
> Cc: "Srivatsa S. Bhat"
> Cc: Peter Zijlstra
> Cc: Arjan van de Ven
> Cc: Sebastian Siewior
> Cc: Rusty Russell
> Cc: Steven Rostedt
> Cc: Oleg Nesterov
> Cc: Tejun Heo
> Cc: Andrew Morton
> Cc:
...@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
inus Torvalds
> Cc: Paul Turner
> Link: http://lkml.kernel.org/r/20160226182340.429389...@linutronix.de
> Signed-off-by: Thomas Gleixner
> ---
Reviewed-by: Srivatsa S. Bhat
Regards,
Srivatsa S. Bhat
> kernel/cpu.c | 69
> +
/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 befor
://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
On 07/16/2014 06:43 PM, Viresh Kumar wrote:
> On 16 July 2014 16:46, Srivatsa S. Bhat 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 cpu
ge
was well-suited for that.
Commit 1aee40ac9c8 (cpufreq: Invoke __cpufreq_remove_dev_finish() after
releasing cpu_hotplug.lock) explains this in detail. Saravana, please take a
look at that reasoning and ensure that your patch doesn't re-introduce those
deadlock possibilities!
>>
On 07/16/2014 11:14 AM, Viresh Kumar wrote:
> On 15 July 2014 12:28, Srivatsa S. Bhat 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
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 wrote:
>>>>> Yeah, it
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
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
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
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
achieve the simplification by keeping sane semantics, then we
shouldn't do the simplification!
That said, I think we should keep trying - we haven't exhausted all ideas
yet :-)
Regards,
Srivatsa S. Bhat
> So, even if we are sure cpufreq.c is fine, it's 137 other uses spread
> across all the o
:-)
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
, splitting up this patch into multiple smaller, reviewable pieces
(accompanied by well-written changelogs that explain the intent) is the utmost
priority. Just like Viresh, even I had a hard time reviewing all of this in
one go.
Thank you for taking up this work!
Regards,
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
of the function that tells us that
we successfully registered the driver. We can do the same thing for
unregistration as well.)
>
> subsys_interface_unregister(_interface);
> if (cpufreq_boost_supported())
>
Regards,
Srivatsa S. Bhat
--
To unsubscribe from this list: send the l
);
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
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 th
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.
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()
>> d
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(
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()
ing on a fix 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
> AuthorDate: Mon Jun 23 14:12:48 2014 +1000
>
> M
t think irqs_disabled() is the problematic condition, since
hotplug_cfg() invokes irq_work_run() from CPU_DYING 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))
>
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
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
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
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
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
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
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
On 06/17/2014 05:25 PM, Sachin Kamat wrote:
> Hi Srivatsa,
>
> On Tue, Jun 17, 2014 at 3:24 PM, Srivatsa S. Bhat
> 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
everted the 2 old commits and added this updated patch.
git://github.com/srivatsabhat/linux.git ipi-offline-fix-v3
]
--------
From: Srivatsa S. Bhat
[PATCH] CPU hotplug, smp: Execute any pending IPI callbacks before CPU offline
The
Execute any pending IPI callbacks before CPU
offline]
[56e692182 - CPU hotplug, smp: flush any pending IPI callbacks before CPU
offline]
Andrew, can you please use this patch instead?
Thanks a lot!
: 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
/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
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
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:
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
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
> wrote:
>> And with the following hunk added (which I had forgotten earlier), it worked
>> just
>> fine on powernv :-)
>
> How are the
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
linux-foundation.org: coding-style fixes]
Signed-off-by: Srivatsa S. Bhat
Suggested-by: Frederic Weisbecker
Cc: "Paul E. McKenney"
Cc: Borislav Petkov
Cc: Christoph Hellwig
Cc: Frederic Weisbecker
Cc: Gautham R Shenoy
Cc: Ingo Molnar
Cc: Mel Gorman
Cc: Mike Galbraith
Cc: Oleg Ne
-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
1 - 100 of 2690 matches
Mail list logo
