Date: Thu, 07 May 2015 07:19:07 +0000 (GMT)
From: Maninder Singh <maninder1.s@samsung.com>
Subject: Re: [EDT][PATCH 1/1] msgsnd use freezable blocking call
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Vaneet Narang <v.narang@samsung.com>,
        "Rafael J. Wysocki" <rjw@rjwysocki.net>,
        Peter Zijlstra <a.p.zijlstra@chello.nl>,
        "yn.gaur@samsung.com" <yn.gaur@samsung.com>
Reply-to: maninder1.s@samsung.com
MIME-version: 1.0
Msgkey: 20150507071644060@maninder1.s
Content-type: text/plain; charset=windows-1252
MIME-version: 1.0
Message-id: <1210676194.185311430983147190.JavaMail.weblogic@epmlwas06c>
DLP-Filter: Pass
Sender: linux-kernel-owner@vger.kernel.org
Content-Transfer-Encoding: 8bit
Content-Length: 2844
Lines: 63

EP-F6AA0618C49C4AEDA73BFF1B39950BAB
>On Wed, 06 May 2015 11:29:57 +0000 (GMT) Maninder Singh wrote:

>> EP-F6AA0618C49C4AEDA73BFF1B39950BAB
>> 
>> Hi ,
>> 
>> Recently shared a patch for using freezable_schedule instead of schedule in msgrcv,
>> and after analysing message queuie implemntation we have realized even msgsnd can also block, if queue is full,
>> So in this scenerio msgsnd sets task state as TASK_INTERRUPTIBLE and can schedule function, similar behaviour as msgrcv.
>> This change is applicable for msgsnd as well.
>> 
>> we have created patch for remotes/linux-next/akpm, because msgrcv patch is already applied at this branch.
.> so we didnt include  
>> 

>This changelog is quite poor.  It doesn't explain why the change is
>being made, it doesn't explain the user-visible effects which are being
>fixed, etc.

>So I threw it away and copied text from "ipc/msg.c: use freezable
>blocking call":

>One thing which isn't clear to me: *why* do we want to "Avoid waking up
>every thread sleeping in XXX during suspend and resume"?  Suspend and
>resume are rare operations.  Why do we care if a few threads wake up
>then go to sleep again?

When any task is stuck in Interruptible or Uninterruptible state then waking up of that task fails.
If wakeup fails, then suspend operation fails and all process send to frezeer state at this moment also gets wakeup.
Correct implementation is that if suspend fails, then kernel would retry suspend operation again after some specific timeinterval for some fixed retry count.
But as changes suggested by Mr Colin Cross on LKML https://lkml.org/lkml/2013/5/1/424, for the system calls for which issue has been faced process flag being appended with PF_FREEZER_SKIP.

we are testing some scenerio in which we have to do multi suspend-resume scenario, and we faced the problem thats why suggested the change for msgsnd and msgrcv


Signed-off-by: Vaneet narang <v.narang@samsung.com>
Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
Cc: Yogesh Gaur <yn.gaur@samsung.com>
Cc: Manjeet Pawar <manjeet.p@samsung.com>
Cc: Ajeet Yadav <ajeet.y@samsung.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 ipc/msg.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff -puN ipc/msg.c~ipc-msgc-msgsnd-use-freezable-blocking-call ipc/msg.c
--- a/ipc/msg.c~ipc-msgc-msgsnd-use-freezable-blocking-call
+++ a/ipc/msg.c
@@ -673,7 +673,7 @@ long do_msgsnd(int msqid, long mtype, vo
 
 		ipc_unlock_object(&msq->q_perm);
 		rcu_read_unlock();
-		schedule();
+		freezable_schedule();
 
 		rcu_read_lock();
 		ipc_lock_object(&msq->q_perm);
_
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m????????????I?