On Friday 16 May 2008, Helge Deller wrote:
> On Wednesday 14 May 2008, Subrata Modak wrote:
> > On Wed, 2008-05-14 at 16:26 +0800, Roy Lee wrote:
> > > Hi,
> > >
> > > Is it necessary for the following testcases to attach their shm to a
> > > 'specific address' rather than NULL?
> > >
> > > testcases/kernel/mem/shmt02.c
> > > testcases/kernel/mem/shmt04.c
> > > testcases/kernel/mem/shmt05.c
> > > testcases/kernel/mem/shmt06.c
> > > testcases/kernel/mem/shmt07.c
> >
> > I hope you are talking about:
> >
> > ltp/testcases/kernel/mem/shmt
> >
> > series of test cases. Mike did some cleanup on them => Tue Mar 13
> > 20:15:16 2007 UTC. Also, i saw some hppa support added by Helge Deller.
>
> Hello Roy,
>
> Yes, I added the HPPA/parisc support and wondered myself.
> I think in a few tests all architectures could use NULL.
> Let's see:
>
> shm02.c:
> #if defined (__ia64__) || defined (__ARM_ARCH_4T__) || defined(__hppa__)
> cp = (char *)shmat(shmid, (void *)NULL, 0);
> #else
> cp = (char *)shmat(shmid, (void *)0x80000, 0);
> #endif
>
> the test checks if shmat() works in general.
> For i386 it's tried to attach memory at 0x80000.
> This only works sucessfully, if the executable hasn't mapped memory there yet
> (e.g. code/text, data or stack).
> On HPPA the 0x80000 is used already by code or data segments, which is why on
> HPPA I choosed NULL (=> map to any address).
> I assume, that all architectures could use NULL here without breaking the
> testcase.
>
> shm04.c:
> -> I think all architectures should use NULL here.
>
> shm05.c:
> A little bit more complicated.
> Test is, that the second shared mem area should overlap with the first memory
> area.
> This means:
> -> I think all architectures should use NULL in the first shmat() call
> -> then the second shmat() should map e.g. at (cp+PAGESIZE) [cp+PAGESIZE
> should be smaller than SIZE]
> (One note: HPPA can only map at specific page addresses/offsets. E.g. mapping
> to cp+2048 won't work and I assume this is true for IA64 as well..)
>
> shm06.c:
> Test is about, that shmat() can map at different(!) addresses.
> Pretty much platform dependend. I wouldn't touch the current code...
>
> shm07.c:
> -> I think every architecture could use NULL here, without breaking the logic
> of the test.
Hello Subrata,
I see Roy's patch was already checked in.
In principle I agree with the patch, but a few things are wrong now and IMHO
does not fulfill what it should test any longer.
shm05.c -> see my (untested!!!) patch below.
Some architectures can only map at specific offsets.
Current version "sucessfully" fails, because e.g. hppa can't map at cp+4096.
So, it's not failing because the memory regions overlap, although that was
intended to be tested...
shm06.c now does basically the same test as shm04.c ?!?
Doesn't make sense...
I would revert the patch for shm06, but maybe others think different????
Other patches seem ok, although I haven't looked too deep into them yet...
Helge
Index: shmt05.c
===================================================================
RCS file: /cvsroot/ltp/ltp/testcases/kernel/mem/shmt/shmt05.c,v
retrieving revision 1.7
diff -u -p -r1.7 shmt05.c
--- shmt05.c 15 May 2008 06:54:17 -0000 1.7
+++ shmt05.c 16 May 2008 20:17:34 -0000
@@ -53,7 +53,7 @@ extern int Tst_count; /* Test Case coun
key_t key[2];
-#define SIZE 16*1024
+#define SIZE (2*SHMLBA)
int rm_shm(int);
@@ -93,7 +93,7 @@ int main()
"Error: shmget: shmid1 = %d, errno = %d\n",
shmid1, errno);
} else {
- cp1 = (char *)shmat(shmid1, cp + 4096, 0);
+ cp1 = (char *)shmat(shmid1, cp + (SIZE/2), 0);
if (cp1 != (char *)-1) {
perror("shmat");
tst_resm(TFAIL,
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
