On 08/29/2013 08:34 AM, Sedat Dilek wrote: > On Wed, Aug 28, 2013 at 1:58 PM, Vineet Gupta > <Vineet.Gupta1@xxxxxxxxxxxx> wrote: >> Hi David, >> >> On 06/26/2013 04:59 AM, Davidlohr Bueso wrote: >>> On Tue, 2013-06-25 at 23:41 +0200, Sedat Dilek wrote: >>>> On Tue, Jun 25, 2013 at 10:33 PM, Davidlohr Bueso >>>> <davidlohr.bueso@xxxxxx> wrote: >>>>> On Tue, 2013-06-25 at 18:10 +0200, Sedat Dilek wrote: >>>>> [...] >>>>> >>>>>> I did some more testing with Linux-Testing-Project (release: >>>>>> ltp-full-20130503) and next-20130624 (Monday) which has still the >>>>>> issue, here. >>>>>> >>>>>> If I revert the mentioned two commits from my local >>>>>> revert-ipc-next20130624-5089fd1c6a6a-ab9efc2d0db5 GIT repo, everything >>>>>> is fine. >>>>>> >>>>>> I have tested the LTP ***IPC*** and ***SYSCALLS*** testcases. >>>>>> >>>>>> root# ./runltp -f ipc >>>>>> >>>>>> root# ./runltp -f syscalls >>>>> These are nice test cases! >>>>> >>>>> So I was able to reproduce the issue with LTP and manually running >>>>> msgctl08. We seemed to be racing at find_msg(), so take to q_perm lock >>>>> before calling it. The following changes fixes the issue and passes all >>>>> 'runltp -f syscall' tests, could you give it a try? >>>>> >>>> Cool, that fixes the issues here. >>>> >>>> Building with fakeroot & make deb-pkg is now OK, again. >>>> >>>> The syscalls/msgctl08 test-case ran successfully! >>> Andrew, could you pick this one up? I've made the patch on top of >>> 3.10.0-rc7-next-20130625 >> LTP msgctl08 hangs on 3.11-rc7 (ARC port) with some of my local changes. I >> bisected it, sigh... didn't look at this thread earlier :-( and landed into this. >> >> ------------->8------------------------------------ >> 3dd1f784ed6603d7ab1043e51e6371235edf2313 is the first bad commit >> commit 3dd1f784ed6603d7ab1043e51e6371235edf2313 >> Author: Davidlohr Bueso <davidlohr.bueso@xxxxxx> >> Date: Mon Jul 8 16:01:17 2013 -0700 >> >> ipc,msg: shorten critical region in msgsnd >> >> do_msgsnd() is another function that does too many things with the ipc >> object lock acquired. Take it only when needed when actually updating >> msq. >> ------------->8------------------------------------ >> >> If I revert 3dd1f784ed66 and 9ad66ae "ipc: remove unused functions" - the test >> passes. I can confirm that linux-next also has the issue (didn't try the revert >> there though). >> >> 1. arc 3.11-rc7 config attached (UP + PREEMPT) >> 2. dmesg prints "msgmni has been set to 479" >> 3. LTP output (this is slightly dated source, so prints might vary) >> >> ------------->8------------------------------------ >> <<<test_start>>> >> tag=msgctl08 stime=1377689180 >> cmdline="msgctl08" >> contacts="" >> analysis=exit >> initiation_status="ok" >> <<<test_output>>> >> ------------->8-------- hung here ------------------ >> >> >> Let me know if you need more data/test help. >> > Cannot say much to your constellation as I had the issue on x86-64 and > Linux-next. > But I have just seen a post-v3.11-rc7 IPC-fix in [1]. > > I have here a v3.11-rc7 kernel with drm-intel-nightly on top... did not run LTP. Not sure what you mean - I'd posted that Im seeing the issue on ARC Linux (an FPGA board) 3.11-rc7 as well as linux-next of yesterday. > Which LTP release do you use? The LTP build I generally use is from a 2007 based sources (lazy me). However I knew this would come up so before posting, I'd built the latest from buildroot and ran the msgctl08 from there standalone and it did the same thing. > Might be good to attach your kernel-config for followers? It was already there in my orig msg - you probably missed it. > [1] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=368ae537e056acd3f751fa276f48423f06803922 I tried linux-next of today, same deal - msgctl08 still hangs. -Vineet -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
