On Sun, 24 Jan 2021 11:05:28 +0100
Greg KH wrote:
> On Sun, Jan 24, 2021 at 03:26:33PM +0530, Gaurav Kohli wrote:
> > Below race can come, if trace_open and resize of
>
>
>
> You forgot to cc: stable, and put the git id that this patch is
> upstream...
Hi Greg,
Sorry for the confusion. I w
On Sun, Jan 24, 2021 at 03:26:33PM +0530, Gaurav Kohli wrote:
> Below race can come, if trace_open and resize of
You forgot to cc: stable, and put the git id that this patch is
upstream...
Below race can come, if trace_open and resize of
cpu buffer is running parallely on different cpus
CPUXCPUY
ring_buffer_resize
atomic_read(&buffer->resize_disabled)
tracing_open
tracing_reset_onl
Sorry for not replying sooner, my email is still rather full from my 10 day
vacation, and I'm still in "skimming" mode at looking at it.
On Wed, 16 Sep 2020 12:02:46 +0530
Gaurav Kohli wrote:
> >> Yes, got your point. then we can avoid export. Actually we are seeing
> >> issue in older kernel l
On 9/16/2020 12:02 PM, Gaurav Kohli wrote:
Yes, got your point. then we can avoid export. Actually we are seeing
issue in older kernel like 4.19/4.14/5.4 and there below patch was not
present in stable branches:
ommit b23d7a5f4a07 ("ring-buffer: speed up buffer resets by
> avoiding synchr
On 9/15/2020 11:43 PM, Steven Rostedt wrote:
Actually available reader lock is not helping
here(&cpu_buffer->reader_lock), So i took ring buffer mutex lock to
resolve this(this came on 4.19/5.4), in latest tip it is trace buffer
lock. Due to this i have exported api.
I'm saying, why don't y
On Tue, 15 Sep 2020 10:38:03 +0530
Gaurav Kohli wrote:
>
> >>> +void ring_buffer_mutex_release(struct trace_buffer *buffer)
> >>> +{
> >>> +mutex_unlock(&buffer->mutex);
> >>> +}
> >>> +EXPORT_SYMBOL_GPL(ring_buffer_mutex_release);
> >
> > I really do not like to export these.
> >
On 9/15/2020 6:53 PM, Steven Rostedt wrote:
On Tue, 15 Sep 2020 10:38:03 +0530
Gaurav Kohli wrote:
>>> +void ring_buffer_mutex_release(struct trace_buffer *buffer)
>>> +{
>>> +mutex_unlock(&buffer->mutex);
>>> +}
>>> +EXPORT_SYMBOL_GPL(ring_buffer_mutex_release);
>
> I re
On Tue, 15 Sep 2020 22:53:32 +0530
Gaurav Kohli wrote:
> On 9/15/2020 6:53 PM, Steven Rostedt wrote:
> > On Tue, 15 Sep 2020 10:38:03 +0530
> > Gaurav Kohli wrote:
> >
> >>
> >> >>> +void ring_buffer_mutex_release(struct trace_buffer *buffer)
> >> >>> +{
> >> >>> +mutex_unlock(&bu
Sorry for spam, saw some failure so sending mail again.
On 9/15/2020 6:53 PM, Steven Rostedt wrote:
> On Tue, 15 Sep 2020 10:38:03 +0530
> Gaurav Kohli wrote:
>
>>
>> >>> +void ring_buffer_mutex_release(struct trace_buffer *buffer)
>> >>> +{
>> >>> +mutex_unlock(&buffer->mutex);
>> >
Hi Steven,
thanks for reply.
On 9/14/2020 9:49 PM, Steven Rostedt wrote:
> On Mon, 14 Sep 2020 10:00:50 +0530
> Gaurav Kohli wrote:
>
>> Hi Steven,
>>
>> Please let us know, if below change looks good.
>> Or let us know some other way to solve this.
>>
>> Thanks,
>> Gaurav
>>
>>
>
> Hmm, for
On Mon, 14 Sep 2020 10:00:50 +0530
Gaurav Kohli wrote:
> Hi Steven,
>
> Please let us know, if below change looks good.
> Or let us know some other way to solve this.
>
> Thanks,
> Gaurav
>
>
Hmm, for some reason, I don't see this in my INBOX, but it shows up in my
LKML folder. :-/
>
> On
Hi Steven,
Please let us know, if below change looks good.
Or let us know some other way to solve this.
Thanks,
Gaurav
On 9/4/2020 11:39 AM, Gaurav Kohli wrote:
Below race can come, if trace_open and resize of
cpu buffer is running parallely on different cpus
CPUX
Below race can come, if trace_open and resize of
cpu buffer is running parallely on different cpus
CPUXCPUY
ring_buffer_resize
atomic_read(&buffer->resize_disabled)
tracing_open
tracing_reset_onl
14 matches
Mail list logo
