failing LOCK1 smbtorture test

[MCCALL,DON (HP-USA,ex1)]

Hi Anton,
I would rather see better/more tests implemented, than a blacklist.  For one
thing, vendors that have bugs in the mmap implementation (as I believe HP
has at the moment, with returning a zero pa periodically) need to be
responsible and FIX these issues.  I think that we need to code as if the
man page for mmap (or other system functions) is reliable, and use our
testing etc. to make people aware that there are issues with a particular
implementation.  For instance, the issue with HP-UX not having a unified
buffer/page cache could be addressed by HP in the near future, and then we
would PASS the test that Jeremy is proposing, and once again be able to take
advantage of the mmap performance gains, without a code modification.  If
however, we set up a 'blacklist', where we hardcode ifdef's against
particular os'es, when they have addressed the issues, then a code
modification is required.
Just my opinion, but if a particular vendor requires ifdef's for their
implementation, I would like to see them submit them, if the issue is
something they are not planning to address.

Hope this helps,
Don

-----Original Message-----
From: Anton Blanchard [mailto:anton at samba.org]
Sent: Thursday, July 26, 2001 7:26
To: Jeremy Allison
Cc: MCCALL,DON (HP-USA,ex1); 'samba-technical at lists.samba.org'
Subject: Re: failing LOCK1 smbtorture test



Hi,

> 	I'm thinking the best thing to do might be to expand
> the tests/shared_mmap.c code to also test for a coherent mmap/
> read/write cache, and report a non-working mmap if this fails.

There are other mmap bugs that will be very hard to check for, maybe
we need a blacklist.

For example Tridge and I found a bug in the sparc32/64 linux shared
mmap code. It turns out we were allocating addresses for the tdb mmap
at different virtual colours.

This means that we could have two cache lines mapping to the same
physical address. Under just the right conditions (two processes with
the tdb mmap mapped at different virtual colours, most likely SMP,
both hitting the same part of the mmap at the same time) we would corrupt
the tdb.

I fixed this but older 2.2 and 2.4 sparc kernels will still have this
problem.

Anton