On Fri, Mar 8, 2013 at 9:59 AM, Oleg Nesterov wrote:
> By discussion with Mandeep Singh Baines .
>
> Change dump_write(), dump_seek() and do_coredump() to check
> signal_pending() and abort if it is true.
>
> We add the new trivial helper, dump_interrupted(), to document th
> decremented the counter, this is all we need.
>
> Signed-off-by: Oleg Nesterov
Acked-by: Mandeep Singh Baines
> ---
> fs/coredump.c | 15 +--
> 1 files changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/fs/coredump.c b/fs/coredump.c
> index 4
On Fri, Mar 8, 2013 at 9:59 AM, Oleg Nesterov wrote:
> Cleanup. Every linux_binfmt->core_dump() sets PF_DUMPCORE,
> move this into zap_threads() called by do_coredump().
>
> Signed-off-by: Oleg Nesterov
Acked-by: Mandeep Singh Baines
> ---
> arch/x86/ia32/ia32_
lready dead, it called do_exit()->complete_vfork_done().
>
> Reported-by: Artem Savkov
> Reported-by: Maciej Rutecki
> Signed-off-by: Oleg Nesterov
>
Reviewed-by: Mandeep Singh Baines
> --- x/drivers/platform/x86/thinkpad_acpi.c
> +++ x/drivers/platform/x86/thinkpa
On Wed, Mar 6, 2013 at 10:37 AM, Myklebust, Trond
wrote:
> On Wed, 2013-03-06 at 13:23 -0500, Jeff Layton wrote:
>> On Wed, 6 Mar 2013 07:59:01 -0800
>> Mandeep Singh Baines wrote:
>> > In general, holding a lock and freezing can cause a deadlock if:
>> >
>>
On Wed, Mar 6, 2013 at 4:06 AM, Jeff Layton wrote:
> On Wed, 6 Mar 2013 10:09:14 +0100
> Ingo Molnar wrote:
>
>>
>> * Mandeep Singh Baines wrote:
>>
>> > On Tue, Mar 5, 2013 at 5:16 PM, Tejun Heo wrote:
>> > > On Tue, Mar 05, 2013 at 08:05:07
On Sun, Mar 3, 2013 at 5:02 AM, Fengguang Wu wrote:
> Greetings,
>
> I got the below oops and the first bad commit is
>
> commit 6aa9707099c4b25700940eb3d016f16c4434360d
> Author: Mandeep Singh Baines
> Date: Wed Feb 27 17:03:18 2013 -0800
>
> lockdep: check t
On Tue, Mar 5, 2013 at 5:16 PM, Tejun Heo wrote:
> On Tue, Mar 05, 2013 at 08:05:07PM -0500, J. Bruce Fields wrote:
>> If it's really just a 2-line patch to try_to_freeze(), could it just be
>> carried out-of-tree by people that are specifically working on tracking
>> down these problems?
>>
>> Bu
On Tue, Mar 5, 2013 at 3:11 PM, J. Bruce Fields wrote:
> On Tue, Mar 05, 2013 at 09:49:54AM -0800, Tejun Heo wrote:
>> On Tue, Mar 05, 2013 at 09:46:48AM -0800, Tejun Heo wrote:
>> > So, I think this is why implementing freezer as a separate blocking
>> > mechanism isn't such a good idea. We're e
This check is turning up a lot of code paths which need to be
fixed so while those paths are fixed, let's make this check
optional so that folks can still use lockdep.
CC: Tejun Heo
CC: Jeff Layton
CC: "Myklebust, Trond"
CC: Oleg Nesterov
CC: Ming Lei
CC: "Rafael J. Wysocki"
CC: Andrew Morto
On Tue, Mar 5, 2013 at 10:05 AM, Oleg Nesterov wrote:
> On 03/05, Mandeep Singh Baines wrote:
>>
>> On Tue, Mar 5, 2013 at 9:48 AM, Oleg Nesterov wrote:
>> > On 03/05, Mandeep Singh Baines wrote:
>> >>
>> >> @@ -2462,13 +2462,13 @@ static int hot
On Tue, Mar 5, 2013 at 9:48 AM, Oleg Nesterov wrote:
> On 03/05, Mandeep Singh Baines wrote:
>>
>> @@ -2462,13 +2462,13 @@ static int hotkey_kthread(void *data)
>> unsigned int poll_freq;
>> bool was_frozen;
>>
>> + set_freezable();
>&g
block on the mutex, potentially via
writing to one of the sysfs attrs. This race is unlikely but
can be easily fixed by moving the set_freezable() call.
Reported-by: Maciej Rutecki
Signed-off-by: Mandeep Singh Baines
CC: Aaron Lu
CC: Henrique de Moraes Holschuh
CC: Tejun Heo
CC: Oleg Nesterov
CC
.9.0-rc1
>>
>> full dmesg:
>> http://mrutecki.pl/download/kernel/3.9.0-rc1/dmesg-3.9.0-rc1.txt
>>
>
> Thanks for the report!
>
> Looks like the following commit is related:
> commit 6aa9707099c4b25700940eb3d016f16c4434360d
> Author: Mandeep Singh Baines Thu Feb 28 09:03:18 20
On Tue, Mar 5, 2013 at 7:20 AM, Shawn Guo wrote:
> On Mon, Mar 04, 2013 at 10:52:10AM +0800, Shawn Guo wrote:
>> I'm running v3.9-rc1 kernel on an ARM platform (i.MX28) with
>> arch/arm/mxs_defconfig and getting the following BUG warning.
>>
> git bisect points me to the commit 6aa9707 (lockdep: c
On Mon, Mar 4, 2013 at 12:09 PM, Mandeep Singh Baines wrote:
> On Mon, Mar 4, 2013 at 7:53 AM, Myklebust, Trond
> wrote:
>> On Mon, 2013-03-04 at 23:33 +0800, Ming Lei wrote:
>>> Hi,
>>>
>>> CC guys who introduced the lockdep change.
>>>
>>
; I don't get it -- why is it bad to hold a lock across a freeze event?
>>
>> At least this may deadlock another mount.nfs during freezing, :-)
>>
>> See detailed explanation in the commit log:
>>
>> commit 6aa9707099c4b25700940eb3d016f16c4434360d
>> Author
+ rjw, akpm, tejun, mingo, oleg
On Mon, Mar 4, 2013 at 6:23 AM, Jeff Layton wrote:
> On Mon, 4 Mar 2013 14:14:23 +
> "Myklebust, Trond" wrote:
>
>> On Mon, 2013-03-04 at 21:57 +0800, Ming Lei wrote:
>> > Hi,
>> >
>> > The below warning can be triggered each time when mount.nfs is
>> > runnin
er_do_not_count + wait_event_interruptible.
>
> Signed-off-by: Oleg Nesterov
Acked-by: Mandeep Singh Baines
> ---
> fs/coredump.c | 12 ++--
> 1 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/fs/coredump.c b/fs/coredump.c
> index 4f3c8d1.
On Wed, Feb 27, 2013 at 10:08 AM, Oleg Nesterov wrote:
> On 02/26, Mandeep Singh Baines wrote:
>>
>> >> Change freeze_task() to check PF_DUMPCORE along with PF_KTHREAD. We
>> >> need to recheck PF_DUMPCORE under ->siglock to avoid the race with
>> >
On Tue, Feb 26, 2013 at 8:37 AM, Mandeep Singh Baines wrote:
> On Sun, Feb 24, 2013 at 10:36 AM, Oleg Nesterov wrote:
>> A coredumping thread can't be frozen anyway but the fake signal sent
>> by freeze_task() can confuse dump_write/wait_for_dump_helpers/etc
>>
On Sun, Feb 24, 2013 at 10:36 AM, Oleg Nesterov wrote:
> A coredumping thread can't be frozen anyway but the fake signal sent
> by freeze_task() can confuse dump_write/wait_for_dump_helpers/etc
> and interrupt the coredump.
>
> We are going to make the do_coredump() paths freezable but the fake
>
On Thu, Feb 21, 2013 at 1:42 PM, Andrew Morton
wrote:
> On Thu, 21 Feb 2013 08:51:41 -0800
> Mandeep Singh Baines wrote:
>
>> We shouldn't try_to_freeze if locks are held. Holding a lock
>> can cause a deadlock if the lock is later acquired in the
>> suspen
t;20130216170605.gc4...@redhat.com> Oleg Nesterovw
* Avoid unnecessary PF_NOFREEZE check when !CONFIG_LOCKDEP.
* Mandeep Singh Baines
* Generalize an exit specific printk.
Changes since v3:
* LKML: <20130220223013.ga15...@redhat.com> Oleg Nesterovw
* Remove stale vfork comment from com
On Thu, Feb 21, 2013 at 7:42 AM, Rafael J. Wysocki wrote:
> On Wednesday, February 20, 2013 07:17:07 PM Mandeep Singh Baines wrote:
>> We shouldn't try_to_freeze if locks are held.
>
> Has Ingo acked one of the previous versions or is my memory doing tricks?
>
Yes, In
On Wed, Feb 20, 2013 at 4:42 PM, Andrew Morton
wrote:
> On Wed, 20 Feb 2013 16:28:07 -0800
> Mandeep Singh Baines wrote:
>
>> > Backtraces aren't *that* bad. We'll easily be able to tell which of
>> > the two callsites triggered the trace.
>> >
&g
since v2:
* LKML: <20130216170605.gc4...@redhat.com> Oleg Nesterovw
* Avoid unnecessary PF_NOFREEZE check when !CONFIG_LOCKDEP.
* Mandeep Singh Baines
* Generalize an exit specific printk.
Changes since v3:
* LKML: <20130220223013.ga15...@redhat.com> Oleg Nesterovw
* Remove stale vfor
On Wed, Feb 20, 2013 at 4:20 PM, Andrew Morton
wrote:
> On Wed, 20 Feb 2013 16:17:39 -0800
> Mandeep Singh Baines wrote:
>
>> On Wed, Feb 20, 2013 at 3:24 PM, Andrew Morton
>> wrote:
>> > On Wed, 20 Feb 2013 15:17:16 -0800
>> > Mandeep Singh Baines wrote
On Wed, Feb 20, 2013 at 3:24 PM, Andrew Morton
wrote:
> On Wed, 20 Feb 2013 15:17:16 -0800
> Mandeep Singh Baines wrote:
>
>> We shouldn't try_to_freeze if locks are held.
>>
>> ...
>>
>> @@ -43,6 +44,9 @@ extern void thaw_kernel_threads(void);
&g
On Tue, Feb 19, 2013 at 12:20 PM, Mandeep Singh Baines
wrote:
> On Tue, Feb 19, 2013 at 11:45 AM, Oleg Nesterov wrote:
>> On 02/19, Mandeep Singh Baines wrote:
>>>
>>> On Tue, Feb 19, 2013 at 6:27 AM, Oleg Nesterov wrote:
>>> > Please look at 1-3 I s
since v2:
* LKML: <20130216170605.gc4...@redhat.com> Oleg Nesterovw
* Avoid unnecessary PF_NOFREEZE check when !CONFIG_LOCKDEP.
* Mandeep Singh Baines
* Generalize an exit specific printk.
Changes since v3:
* LKML: <20130220223013.ga15...@redhat.com> Oleg Nesterovw
* Remove stale vfor
On Wed, Feb 20, 2013 at 2:30 PM, Oleg Nesterov wrote:
> On 02/19, Mandeep Singh Baines wrote:
>>
>> We shouldn't try_to_freeze if locks are held. Verified that
>> I get no lockdep warnings after applying this patch and
>> "vfork: don't freezer_count()
On Sat, Feb 16, 2013 at 9:12 AM, Oleg Nesterov wrote:
> Forgot to mention...
>
> On 02/16, Oleg Nesterov wrote:
>> On 02/16, Mandeep Singh Baines wrote:
>> >
>> > --- a/kernel/freezer.c
>> > +++ b/kernel/freezer.c
>> > @@ -81,
sg string that gets passed in.
* LKML: <20130215154449.gd30...@redhat.com> Oleg Nesterov
* Check PF_NOFREEZE in try_to_freeze().
Changes since v2:
* LKML: <20130216170605.gc4...@redhat.com> Oleg Nesterov
* Avoid unnecessary PF_NOFREEZE check when !CONFIG_LOCKDEP.
* Mandeep Singh
On Tue, Feb 19, 2013 at 4:07 PM, Mandeep Singh Baines wrote:
> On Sat, Feb 16, 2013 at 9:05 AM, Oleg Nesterov wrote:
>> On 02/16, Mandeep Singh Baines wrote:
>>>
>>> We don't need to call freezer_do_not_count() for in-kernel users
>>> of CLONE_VFORK s
y modified) fix proposed in
> http://marc.info/?l=linux-kernel&m=136103469831268.
>
> Oleg.
For the whole series:
Tested-by: Mandeep Singh Baines
This was an important issue for us so I'm in the process of merging
these into the ChromiumOS kernel tree.
Thanks,
Mandeep
&g
On Sat, Feb 16, 2013 at 9:05 AM, Oleg Nesterov wrote:
> On 02/16, Mandeep Singh Baines wrote:
>>
>> We don't need to call freezer_do_not_count() for in-kernel users
>> of CLONE_VFORK since exec will get called in bounded time.
>>
>> We don't want
On Tue, Feb 19, 2013 at 11:45 AM, Oleg Nesterov wrote:
> On 02/19, Mandeep Singh Baines wrote:
>>
>> On Tue, Feb 19, 2013 at 6:27 AM, Oleg Nesterov wrote:
>> > Please look at 1-3 I sent. Btw, I slightly tested this series, seems
>> > to work...
>> >
>
On Tue, Feb 19, 2013 at 6:27 AM, Oleg Nesterov wrote:
> On 02/18, Mandeep Singh Baines wrote:
>>
>> On Sat, Feb 16, 2013 at 11:46 AM, Oleg Nesterov wrote:
>> >> --- x/fs/coredump.c
>> >> +++ x/fs/coredump.c
>> >> @@ -416,17
On Sat, Feb 16, 2013 at 11:46 AM, Oleg Nesterov wrote:
> On 02/16, Oleg Nesterov wrote:
>>
>> On 02/16, Mandeep Singh Baines wrote:
>> >
>> > +static int sigkill_pending(struct task_struct *tsk)
>> > +{
>> > + return signal_pending(tsk) &a
On Sat, Feb 16, 2013 at 11:46 AM, Oleg Nesterov wrote:
> On 02/16, Oleg Nesterov wrote:
>>
>> On 02/16, Mandeep Singh Baines wrote:
>> >
>> > +static int sigkill_pending(struct task_struct *tsk)
>> > +{
>> > + return signal_pending(tsk) &a
* Rebased after dropping earlier cleanup patch.
Signed-off-by: Mandeep Singh Baines
CC: Oleg Nesterov
CC: Tejun Heo
CC: Andrew Morton
CC: Rafael J. Wysocki
CC: Ingo Molnar
---
kernel/exit.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/exit.c b/kernel/e
sg string that gets passed in.
* LKML: <20130215154449.gd30...@redhat.com> Oleg Nesterov
* Check PF_NOFREEZE in try_to_freeze().
Signed-off-by: Mandeep Singh Baines
CC: Oleg Nesterov
CC: Tejun Heo
CC: Andrew Morton
CC: Rafael J. Wysocki
CC: Ingo Molnar
---
include/linux/debug_l
In freeze_task, a freeze request is sent as a fake signal.
Recalculate signal pending on exit from __refrigerator so that
TIF_SIGPENDING doesn't remain incorrectly set.
Signed-off-by: Mandeep Singh Baines
CC: Oleg Nesterov
CC: Tejun Heo
CC: Andrew Morton
CC: Rafael J. Wysocki
CC:
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
2514 root 20 0 1868 392 336 S0 0.0 0:00.00 sleep
localhost ~ # kill -KILL $!
[1]+ Aborted (core dumped) sleep 1d
Addresses http://crosbug.com/21559
Changes since v1:
* Mandeep Singh Baines
* To
in-kernel user because it may be
holding locks.
Changes since v1:
* <20130215152840.gc30...@redhat.com> Oleg Nesterov
* Use (p->flags & PF_KTHREAD) checks instead of p->mm.
Signed-off-by: Mandeep Singh Baines
CC: Oleg Nesterov
CC: Tejun Heo
CC: Andrew Morton
CC: Raf
On Fri, Feb 15, 2013 at 7:01 AM, Oleg Nesterov wrote:
> On 02/14, Mandeep Singh Baines wrote:
>>
>> This patch makes wait_for_dump_helpers() not to abort piping the core
>> dump data when the crashing process has received any but a fatal signal
>> (SIGKILL). The r
PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND
2514 root 20 0 1868 392 336 S0 0.0 0:00.00 sleep
Addresses http://crosbug.com/21559
Changes since v1:
* Mandeep Singh Baines
* To prevent blocking suspend, add try_to_freeze().
Changes since v2:
* LKML: <
From: Ben Chan
Make wait_for_dump_helpers() not abort piping the core dump data when the
crashing process has received a non-fatal signal. The abort still occurs
in the case of SIGKILL.
Addresses http://crosbug.com/21559
Changes since v1:
* Mandeep Singh Baines
* To prevent blocking suspend
Signed-off-by: Mandeep Singh Baines
CC: Oleg Nesterov
CC: Tejun Heo
CC: Andrew Morton
CC: Rafael J. Wysocki
CC: Ingo Molnar
---
fs/coredump.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/fs/coredump.c b/fs/coredump.c
index 1774932..54e31a3 100644
--- a/fs/coredump.
Replace the for loop with a simple if.
Signed-off-by: Mandeep Singh Baines
CC: Oleg Nesterov
CC: Tejun Heo
CC: Andrew Morton
CC: Rafael J. Wysocki
CC: Ingo Molnar
---
kernel/exit.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/kernel/exit.c b/kernel/exit.c
Prevents hung_task detector from panicing the machine. This is also
needed to prevent this wait from blocking suspend.
(It doesnt' currently block suspend but it would once the next
patch in this series is applied.)
Signed-off-by: Mandeep Singh Baines
CC: Oleg Nesterov
CC: Tejun He
We shouldn't try_to_freeze if locks are held. Verified that
I get no lockdep warnings after applying this patch and
"vfork: don't freezer_count() for in-kernel users of CLONE_VFORK".
Signed-off-by: Mandeep Singh Baines
CC: Oleg Nesterov
CC: Tejun Heo
CC: Andrew Morton
C
in-kernel user because it may be
holding locks.
In a follow-up patch, I call debug_check_no_locks_held() from
try_to_freeze(). After applying this patch, I get no lockdep
warnings with that patch.
Signed-off-by: Mandeep Singh Baines
CC: Oleg Nesterov
CC: Tejun Heo
CC: Andrew Morton
CC: Rafael
Commit-ID: 5224c3a31549f1c056039545b289e1b01ed02f12
Gitweb: http://git.kernel.org/tip/5224c3a31549f1c056039545b289e1b01ed02f12
Author: Mandeep Singh Baines
AuthorDate: Fri, 7 Sep 2012 18:12:19 -0700
Committer: Steven Rostedt
CommitDate: Mon, 24 Sep 2012 14:10:44 -0400
tracing: Add an
e "grep -v tracing_mark_write" but it would be nice
if I could just temporarily disable markers all together.
Signed-off-by: Mandeep Singh Baines
CC: Steven Rostedt
CC: Frederic Weisbecker
CC: Ingo Molnar
---
kernel/trace/trace.c |6 +-
kernel/trace/trace.h |1 +
2 files c
64260] drm_prime_init_file edc2e750
[8.004837] drm_prime_init_file ee36ded0
Signed-off-by: Mandeep Singh Baines
Acked-by: Seung-Woo Kim
---
drivers/gpu/drm/exynos/exynos_drm_drv.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gp
64260] drm_prime_init_file edc2e750
[8.004837] drm_prime_init_file ee36ded0
Signed-off-by: Mandeep Singh Baines
CC: Stéphane Marchesin
CC: Pawel Osciak
CC: Inki Dae
CC: Joonyoung Shim
CC: Seung-Woo Kim
CC: Kyungmin Park
CC: David Airlie
CC: dri-de...@lists.freedesktop.org
---
drivers/gpu/drm/e
|
|--88.61%-- ktime_get_ts
| |
| |--92.70%-- posix_ktime_get_ts
Signed-off-by: Mandeep Singh Baines
CC: Sonny Rao
CC: Olof Johansson
CC: Kukjin Kim
CC: Russell King
CC: linux-arm-ker...@lists.infradead.org
CC: linux-samsung-...@vger.kernel.org
---
arch/arm
|
|--88.61%-- ktime_get_ts
| |
| |--92.70%-- posix_ktime_get_ts
Signed-off-by: Mandeep Singh Baines
CC: Sonny Rao
CC: Olof Johansson
CC: Kukjin Kim
CC: Russell King
CC: linux-arm-ker...@lists.infradead.org
CC: linux-samsung
(exynos_target+0x1b0/0x220) from [<803a4a0c>]
(__cpufreq_driver_target+0xb0/0xd4)
[<803a4a0c>] (__cpufreq_driver_target+0xb0/0xd4) from [<803aab80>]
(cpufreq_interactive_updown_task+0x214/0x264)
[<803aab80>] (cpufreq_interactive_updown_task+0x214/0x264) from [<80047d04
Srivatsa S. Bhat (srivatsa.b...@linux.vnet.ibm.com) wrote:
> On 06/23/2012 03:36 AM, Mandeep Singh Baines wrote:
> > A cpu in the mm_cpumask could go offline before we send the invalidate
> > IPI causing us to wait forever. Avoid this by only waiting for online
> > cpus.
>
Srivatsa S. Bhat (srivatsa.b...@linux.vnet.ibm.com) wrote:
> On 06/21/2012 03:33 AM, mandeep.bai...@gmail.com wrote:
> > From: Mandeep Singh Baines
> >
> > A cpu in the mm_cpumask could go offline before we send the
> > invalidate IPI causing us to wait forever.
>
On Fri, Jun 22, 2012 at 3:06 PM, Mandeep Singh Baines wrote:
> A cpu in the mm_cpumask could go offline before we send the invalidate
> IPI causing us to wait forever. Avoid this by only waiting for online
> cpus.
>
> We are seeing a softlockup reporting during shutdown. The stac
64 matches
Mail list logo
