On 1/24/2021 8:51 AM, Steven Rostedt wrote:
On Sat, 23 Jan 2021 22:03:27 +0530
Gaurav Kohli wrote:
Sure I will do, I have never posted on backport branches. Let me check
and post it.
Basically you take your original patch that was in mainline (as the
subject and commit message), and
ges
for sanity.
Take buffer lock to fix this.
Link:
https://lkml.kernel.org/r/1601976833-24377-1-git-send-email-gko...@codeaurora.org
Reported-by: Denis Efremov
Signed-off-by: Gaurav Kohli
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 077877e..7283741 100644
--- a/kerne
On 1/23/2021 4:19 PM, Denis Efremov wrote:
On 1/22/21 5:37 PM, Steven Rostedt wrote:
On Fri, 22 Jan 2021 16:55:29 +0530
Gaurav Kohli wrote:
That could possibly work.
Yes, this will work, As i have tested similar patch for internal testing
for kernel branches like 5.4/4.19.
Can you
On 1/22/2021 4:29 PM, Greg KH wrote:
On Thu, Jan 21, 2021 at 03:37:32PM -0500, Steven Rostedt wrote:
On Thu, 21 Jan 2021 23:15:22 +0300
Denis Efremov wrote:
On 1/21/21 10:09 PM, Steven Rostedt wrote:
On Thu, 21 Jan 2021 17:30:40 +0300
Denis Efremov wrote:
Hi,
This patch (CVE-2020-2
sanity.
Take buffer lock to fix this.
Signed-off-by: Gaurav Kohli
Cc: sta...@vger.kernel.org
---
Changes since v0:
-Addressed Steven's review comments.
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 93ef0ab..15bf28b 100644
--- a/kernel/trace/ring_buffer.c
On 10/5/2020 10:02 PM, Steven Rostedt wrote:
On Mon, 5 Oct 2020 21:59:02 +0530
Gaurav Kohli wrote:
Hi Steven,
I am using normal git send-email(never saw problem with this), Not sure
what is wrong. In my older mail i have kept you in to and rest in cc.
Let me try to resent it.
The Cc is
On 10/5/2020 7:57 PM, Steven Rostedt wrote:
On Mon, 5 Oct 2020 10:25:15 -0400
Steven Rostedt wrote:
On Mon, 5 Oct 2020 10:09:34 +0530
Gaurav Kohli wrote:
Hi Steven,
please let us know, if below looks good to you or need modifications.
Strange, I don't have your original email
Hi Steven,
please let us know, if below looks good to you or need modifications.
Thanks
Gaurav
On 9/24/2020 7:25 PM, Gaurav Kohli wrote:
Below race can come, if trace_open and resize of
cpu buffer is running parallely on different cpus
CPUXCPUY
sanity.
Signed-off-by: Gaurav Kohli
Cc: sta...@vger.kernel.org
---
Changes since v0:
-Addressed Steven's review comments.
diff --git a/kernel/trace/ring_buffer.c b/kernel/trace/ring_buffer.c
index 93ef0ab..15bf28b 100644
--- a/kernel/trace/ring_buffer.c
+++ b/kernel/trace/ring_buffer.
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
>
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 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);
>>> +}
>>> +EXP
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)
>> >>>
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.
>>
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
es
for sanity.
Take ring buffer lock in trace_open to avoid resetting of cpu buffer.
Signed-off-by: Gaurav Kohli
diff --git a/include/linux/ring_buffer.h b/include/linux/ring_buffer.h
index 136ea09..55f9115 100644
--- a/include/linux/ring_buffer.h
+++ b/include/linux/ring_buffer.h
@@ -163,6 +163,8
es
for sanity.
Take ring buffer lock in trace_open to avoid resetting of cpu buffer.
Signed-off-by: Gaurav Kohli
diff --git a/include/linux/ring_buffer.h b/include/linux/ring_buffer.h
index 136ea09..55f9115 100644
--- a/include/linux/ring_buffer.h
+++ b/include/linux/ring_buffer.h
@@ -163,6 +163,8
On 8/12/2020 7:00 PM, Will Deacon wrote:
On Tue, Aug 04, 2020 at 07:44:42PM +0530, Gaurav Kohli wrote:
In a system where no cpu's implement SSBS, for
them no need to set pstate. This might help to save
few cpu cycles during context switch.
Signed-off-by: Gaurav Kohli
diff --git a
Hi,
Please let us know, is below patch good to have
or not for non ssbs systems.
On 8/4/2020 7:44 PM, Gaurav Kohli wrote:
In a system where no cpu's implement SSBS, for
them no need to set pstate. This might help to save
few cpu cycles during context switch.
Signed-off-by: Gaurav Kohli
Please ignore this patch also, sent due to git send mistake.
Apologies for the spam.
On 8/4/2020 7:44 PM, Gaurav Kohli wrote:
From: Srinivas Kandagatla
Many nvmem providers are not very keen on having default sysfs
nvmem entry, as most of the usecases for them are inside kernel
itself. And
Please ignore this patch, some problem in my git send mail.
Apologies for the spam.
On 8/4/2020 7:44 PM, Gaurav Kohli wrote:
From: Srinivas Kandagatla
Some users might not want to expose nvmem entry to sysfs and
only intend to use kernel interface so add such provision.
Signed-off-by
From: Srinivas Kandagatla
Some users might not want to expose nvmem entry to sysfs and
only intend to use kernel interface so add such provision.
Signed-off-by: Srinivas Kandagatla
---
Documentation/ABI/stable/sysfs-bus-nvmem | 2 ++
drivers/nvmem/Kconfig| 5 +
dri
In a system where no cpu's implement SSBS, for
them no need to set pstate. This might help to save
few cpu cycles during context switch.
Signed-off-by: Gaurav Kohli
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 6089638..79f80f1 100644
--- a/arch/arm64/k
+
Hi Peter, Jen,
As we are not taking pi_lock here , is there possibility of same task dead
call comes as this point of time for current thread, bcoz of which we have
seen earlier issue after this commit 0619317ff8ba
[T114538] do_task_dead+0xf0/0xf8
[T114538] do_exit+0xd5c/0x10fc
[T114538]
On 6/7/2019 7:53 PM, Peter Zijlstra wrote:
On Fri, Jun 07, 2019 at 03:35:41PM +0200, Peter Zijlstra wrote:
On Wed, Jun 05, 2019 at 09:04:02AM -0600, Jens Axboe wrote:
How about the following plan - if folks are happy with this sched patch,
we can queue it up for 5.3. Once that is in, I'll ki
Thanks for the comment, will check the patch and update.
Regards
Gaurav
On 5/10/2019 4:52 AM, Benjamin Herrenschmidt wrote:
On Thu, 2019-05-09 at 20:08 +0530, Gaurav Kohli wrote:
Hi ,
Last patch will serialize the addition of child to parent directory,
won't it affect performance.
I
Hi ,
Last patch will serialize the addition of child to parent directory,
won't it affect performance.
Regards
Gaurav
On 5/4/2019 9:04 PM, Greg KH wrote:
On Sat, May 04, 2019 at 10:47:07PM +0800, Muchun Song wrote:
Benjamin Herrenschmidt 于2019年5月2日周四 下午2:25写道：
The basic idea yes, the who
Hi ,
Sorry for spam,
when is the plan to merge this patch.
Regards
Gaurav
On 4/16/2019 4:45 PM, Gaurav Kohli wrote:
Hi ,
I have reviewed and tested for both enabled and disabled and working as
expected.
Please feel free to add:
Reviewed-by: Gaurav Kohli
Tested-by: Gaurav Kohli
Hi ,
I have reviewed and tested for both enabled and disabled and working as
expected.
Please feel free to add:
Reviewed-by: Gaurav Kohli
Tested-by: Gaurav Kohli
Regards
Gaurav
On 4/16/2019 4:31 PM, Mika Westerberg wrote:
On Tue, Apr 16, 2019 at 10:59:24AM +0100, Srinivas Kandagatla
Hi Srinivas,
Thanks for the patch,
By default NVMEM_SYSFS should be set true, those whose don't want they
can disable the same.
If we go with disable option, there are chances of eeprom may break in
below case:
if (config->compat) {
rval = nvmem_sysfs_setup_compat(nvmem, con
On 4/5/2019 6:01 PM, Mukesh Ojha wrote:
On 4/5/2019 5:40 PM, Greg KH wrote:
On Fri, Apr 05, 2019 at 05:13:00PM +0530, Gaurav Kohli wrote:
On 4/5/2019 5:03 PM, Greg KH wrote:
On Fri, Apr 05, 2019 at 04:51:07PM +0530, Gaurav Kohli wrote:
While adding kernfs node for child to the parent
On 4/5/2019 5:03 PM, Greg KH wrote:
On Fri, Apr 05, 2019 at 04:51:07PM +0530, Gaurav Kohli wrote:
While adding kernfs node for child to the parent kernfs
node and when child node founds that parent kn count is
zero, then below comes like:
WARNING: fs/kernfs/dir.c:494 kernfs_get+0x64/0x88
nue for parent.
kmem_cache_free(parent)
To prevent this race, child simply has to decrement count of parent
kernfs node and keep continue the free path for itself.
Signed-off-by: Gaurav Kohli
Signed-off-by: Mukesh Ojha
diff --git a/fs/kernfs/dir.c b/fs/kern
Hi Srinivas,
Thanks for the patch, Can you please merge , So will cherry pick the same.
Regards
Gaurav
On 3/25/2019 11:45 AM, Gaurav Kohli wrote:
On 3/22/2019 11:42 PM, Gaurav Kohli wrote:
Hi Srinivas,
Thanks for the patch, Something like this only i have tested in the
morning, instead
On 3/25/2019 4:28 PM, Srinivas Kandagatla wrote:
On 24/03/2019 15:25, Gaurav Kohli wrote:
On 3/22/2019 8:53 PM, Srinivas Kandagatla wrote:
On 20/03/2019 05:53, Gaurav Kohli wrote:
From: Shiraz Hashim
Existing nvmem framework export full register space
as nvmem binary, but not
On 3/22/2019 11:42 PM, Gaurav Kohli wrote:
Hi Srinivas,
Thanks for the patch, Something like this only i have tested in the
morning, instead of unused, i have put dev group inside config as well.
We will test the exact patch and update the same.
Regards
Gaurav
On 3/22/2019 8:32 PM
On 3/22/2019 8:53 PM, Srinivas Kandagatla wrote:
On 20/03/2019 05:53, Gaurav Kohli wrote:
From: Shiraz Hashim
Existing nvmem framework export full register space
as nvmem binary, but not exporting child node of nvmem
which is nvmem cell. Kernel can read the specific cell
by using
, Gaurav Kohli wrote:
Is root only option not helping you in this case?
Yes we want to protect at root level as well, i mean it is better if
we can avoid exposing to userspace at all.
Can you try below patch!
We could go down the route of adding new config option something
like
On 3/20/2019 9:56 PM, Srinivas Kandagatla wrote:
On 20/03/2019 15:50, Gaurav Kohli wrote:
On 3/20/2019 8:04 PM, Srinivas Kandagatla wrote:
On 17/03/2019 14:12, Gaurav Kohli wrote:
Current nvmem framework allows user space to read all register space
populated by nvmem binary file, In
On 3/20/2019 8:04 PM, Srinivas Kandagatla wrote:
On 17/03/2019 14:12, Gaurav Kohli wrote:
Current nvmem framework allows user space to read all register space
populated by nvmem binary file, In case we don't want to expose value
of registers to userspace and only want kernel space to
l, So
userspace can use it directly.
Signed-off-by: Shiraz Hashim
Signed-off-by: Gaurav Kohli
Co-developed-by: Gaurav Kohli
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index f24008b..e4b6160 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -47,6 +47,7 @@ struct nvmem
event read
from userspace.
Signed-off-by: Gaurav Kohli
---
v2: Fix build error
v1: Fix no_read_write update condition
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index f24008b..f1c44fc 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -27,6 +27,7 @@ struct nvmem_d
patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Gaurav-Kohli/nvmem-core-Set-no-read-write-provider-to-avoid-userspace-read-write/20190317-105219
config: i386-randconfig-x010-201911 (attached as .config
event read
from userspace.
Signed-off-by: Gaurav Kohli
---
v1: Fix no_read_write update condition
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index f24008b..d9594ee 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -27,6 +27,7 @@ struct nvmem_device {
struct
event read
from userspace.
Signed-off-by: Gaurav Kohli
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index f24008b..edd0e9f 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -27,6 +27,7 @@ struct nvmem_device {
struct kref refcnt;
s
Commit-ID: 363e934d8811d799c88faffc5bfca782fd728334
Gitweb: https://git.kernel.org/tip/363e934d8811d799c88faffc5bfca782fd728334
Author: Gaurav Kohli
AuthorDate: Thu, 2 Aug 2018 14:21:03 +0530
Committer: Thomas Gleixner
CommitDate: Thu, 2 Aug 2018 12:52:38 +0200
timers: Clear
This can cause large
granularity values for timers, i.e. the accuracy of the expiry time
suffers.
Prevent this by clearing the flag with base->lock held, so that the
forwarding takes place before the cleared flag is observable by a remote
CPU.
Signed-off-by: Gaurav Kohli
---
Changes since v2:
erves it as
cleared, but the base clock is still stale. This can cause large
granularity values for timers, i.e. the accuracy of the expiry time
suffers.
Prevent this by clearing the flag with base->lock held, so that the
forwarding takes place before the cleared flag is observable by a rem
erves it as
cleared, but the base clock is still stale. This can cause large
granularity values for timers, i.e. the accuracy of the expiry time
suffers.
Prevent this by clearing the flag with base->lock held, so that the
forwarding takes place before the cleared flag is observable by a rem
(!base->must_forward_clk))
return;
So preventing the same by putting must_forward_clk inside
base lock.
Signed-off-by: Gaurav Kohli
diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index cc2d23e..675241d 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -165
pi_lock to serial state changes.
Suggested-by: Pavankumar Kondeti
Co-developed-by: Neeraj Upadhyay
Signed-off-by: Neeraj Upadhyay
Signed-off-by: Gaurav Kohli
---
Changes since V1:
- Add comment to explain need of pi_lock.
diff --git a/kernel/smpboot.c b/kernel/smpboot.c
index 5043e74..c5c5184 1006
pi_lock to serial state changes.
Suggested-by: Pavankumar Kondeti
Co-developed-by: Neeraj Upadhyay
Signed-off-by: Neeraj Upadhyay
Signed-off-by: Gaurav Kohli
diff --git a/kernel/smpboot.c b/kernel/smpboot.c
index 1650578..514b232 100644
--- a/kernel/smpboot.c
+++ b/kernel/smpboot.c
@@ -121,7 +121,9
During percpu_counter destroy, debug_object_free is calling
twice which may create race. So removing once instance of call
from debug_percpu_counter_deactivate.
Signed-off-by: Gaurav Kohli
diff --git a/lib/percpu_counter.c b/lib/percpu_counter.c
index c72577e..68ad030 100644
--- a/lib
security_capable_noaudit+0x64/0x94
has_capability_noaudit+0x38/0x58
oom_badness.part.21+0x114/0x1c0
oom_badness+0x50/0x5c
proc_oom_score+0x48/0x80
proc_single_show+0x5c/0xb8
Signed-off-by: Gaurav Kohli
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 6fd9773..5f4cc4b 100644
--- a/mm/oom_kill.c
+++ b/mm
uf2() tty_ldisc_open.isra.3()
-002|tty_ldisc_receive_buf(inline) tty_ldisc_setup()
Using ldisc semaphore lock in tty_init_dev till disc_data
initializes completely.
Signed-off-by: Gaurav Kohli
---
Changes since V1:
- Fix compilation, In case TTY is disabled in build.
diff --gi
uf2() tty_ldisc_open.isra.3()
-002|tty_ldisc_receive_buf(inline) tty_ldisc_setup()
Using ldisc semaphore lock in tty_init_dev till disc_data
initializes completely.
Signed-off-by: Gaurav Kohli
---
Changes since V0:
- Add semaphore lock as suggested.
- Tested it for 4-5 days
001|n_tty_receive_buf2() tty_ldisc_open.isra.3()
-002|tty_ldisc_receive_buf(inline) tty_ldisc_setup()
If tty->disc_data is NULL, then return from flush_to_ldisc
Signed-off-by: Gaurav Kohli
diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c
index 25d7368..5d49183 100644
--- a/drive
57 matches
Mail list logo
