os/fs/mqueue: Fix mq inode initialization locking

[rish-sg]

Description:
This patch ensures that inode initialization and mq binding with the initialzed inode in processed under a single lock. This prevents stale initialisation of inodes and
consequent errors.

---

Problem:
We encountered a case where two processes (sender and receiver) wanted to communicate via a private mq. The environment had SMP enabled. Both had the permission to create the mq via the OCREAT flag.

Now, the process which has the sched_lock() goes to blocked state while waiting for a semaphore during initialisation of the mq inode. This leads to partial initialisation of the inode and context switch.

Now, when the other process accesses the same partially initialised inode, it returns error (err no 6, code ENXIO: inode exists but not a mq)

And if we do not introduce critical_section(), then after the context switch, both the processes go on to create the inode and errno 17 (EEXIST) is returned from inode_reserve().

---

Logs:
sched_addreadytorun: new task scheduled with pid = 32, name = csifw_sample, cpu = 0 mq_open: entering sched_lock: pid = 32, cpu = 0, path => /var/mqueue/tm_public_mq mq_open: leaving sched_lock: pid = 32, cpu = 0
sched_addreadytorun: new task scheduled with pid = 17, name = task_manager, cpu = 1 mq_open: entering sched_lock: pid = 32, cpu = 0, path => /var/mqueue/tm_priv_mq32 up_block_task: task_state = 6 set by pid = 32, name = csifw_sample, cpu = 0 up_block_task: task_state = 6 set by pid = 17, name = task_manager, cpu = 1 sched_addreadytorun: new task scheduled with pid = 32, name = csifw_sample, cpu = 0 up_block_task: task_state = 6 set by pid = 32, name = csifw_sample, cpu = 0 sched_addreadytorun: new task scheduled with pid = 17, name = task_manager, cpu = 0 mq_open: entering sched_lock: pid = 17, cpu = 0, path => /var/mqueue/tm_priv_mq32 mq_open: leaving sched_lock: pid = 17, cpu = 0
taskmgr_send_response: mq_open failed!, errno = 6, cpu = 0 sched_addreadytorun: new task scheduled with pid = 32, name = csifw_sample, cpu = 1 mq_open: leaving sched_lock: pid = 32, cpu = 1
up_block_task: task_state = 9 set by pid = 32, name = csifw_sample, cpu = 1 up_block_task: task_state = 9 set by pid = 17, name = task_manager, cpu = 0

---

Logs (without critical_section):
sched_addreadytorun: new task scheduled with pid = 17, name = task_manager, cpu = 1 mmqq__oopepne:n :e netneterriinngg sscchehde_dl_loocckk:: ppiidd == 3172,, ccppuu
== 01,, ppaatthh ==>> //vvaarr//mmqquueeuuee//ttmm__pprriivv__mmqq3322

up_block_task: TSTATE_WAIT_SEM set by pid = 32, name = csifw_sample, cpu = 0
up_block_task: TSTATE_WAIT_SEM set by pid = 17, name = task_manager, cpu = 1
sched_addreadytorun: new task scheduled with pid = 32, name = csifw_sample, cpu = 0
up_block_task: TSTATE_WAIT_SEM set by pid = 32, name = csifw_sample, cpu = 0
sched_addreadytorun: new task scheduled with pid = 17, name = task_manager, cpu = 0
mq_open: leaving sched_lock: pid = 17, cpu = 0
up_block_task: TSTATE_WAIT_SEM set by pid = 17, name = task_manager, cpu = 0
sched_addreadytorun: new task scheduled with pid = 32, name = csifw_sample, cpu = 0
mq_open: leaving sched_lock: pid = 32, cpu = 0
taskmgr_receive_response: mq_open failed!, errno = 17, cpu = 0
up_block_task: TSTATE_WAIT_SEM set by pid = 32, name = csifw_sample, cpu = 0

---

Fix:
We release the inode semaphore after the mq has been bound to the inode and take critical_section after taking the sched_lock()

---

Signed-Off By: Rishabh Singh ris.singh@samsung.com

[seokhun-eom24]

Can you update comment for that sched_lock is not sufficient for SMP environment.

[rish-sg]

updated

[seokhun-eom24]

We neet do call sem_give() for error case.
Also in line 203

[seokhun-eom24]

Are both sched_lock and enter_critical_section necessary?
If it is for synchronization, enter_critical_section alone might be sufficient.

[aashish-l]

LGTM~