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 <gko...@codeaurora.org>
diff --git a/drivers/tty/tty_port.c b/drivers/tty/tty_port.c
index 25d7368..5d
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 <gko...@codeaurora.org>
---
Changes since V1:
- Fix compilation, In case TTY is
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 <gko...@codeaurora.org>
---
Changes since V0:
- Add semaphore lock as suggested.
(!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
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
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
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 <gko...@codeaurora.org>
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 6fd9773..5f4cc4b 100644
--
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 <gko...@codeaurora.org>
diff --git a/lib/percpu_counter.c b/lib/percpu_counter.c
index c72577e..6
l state changes.
Suggested-by: Pavankumar Kondeti <pkond...@codeaurora.org>
Co-developed-by: Neeraj Upadhyay <neer...@codeaurora.org>
Signed-off-by: Neeraj Upadhyay <neer...@codeaurora.org>
Signed-off-by: Gaurav Kohli <gko...@codeaurora.org>
---
Changes since V1:
- Add comme
l state changes.
Suggested-by: Pavankumar Kondeti <pkond...@codeaurora.org>
Co-developed-by: Neeraj Upadhyay <neer...@codeaurora.org>
Signed-off-by: Neeraj Upadhyay <neer...@codeaurora.org>
Signed-off-by: Gaurav Kohli <gko...@codeaurora.org>
diff --git a/kernel/smpboot
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
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
l 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 @@ static
l 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 100644
--- a/ke
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
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
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
ake 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/kernel/tr
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
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 in my
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
ake 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
+++ b/kernel/tr
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/kernel
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 +
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
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
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
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
diff
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/arch
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
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.
>
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)
>> >
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(>mutex);
>>> +}
>>> +EXPORT_SYMBOL_GPL
On 9/15/2020 11:43 PM, Steven Rostedt wrote:
Actually available reader lock is not helping
here(_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 you
ake 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 @@ b
ake 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 @@ b
ned-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.c
@@ -4866,6 +486
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
>
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 --
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 d
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
+
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
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
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:
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,
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 ,
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
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 doubt
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
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;
size_t
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 kref
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
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_device
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_cell
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
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
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/kernfs/dir.c
index b
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
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 read
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
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
, 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/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
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
(!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
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
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
69 matches
Mail list logo
