failing LOCK1 smbtorture test

Jeremy Allison jeremy at
Wed Jul 25 18:48:05 GMT 2001

"MCCALL,DON (HP-USA,ex1)" wrote:
> Hi Jeremy,
> I have been having a hard time getting samba 2.2.latestcvs to pass LOCK1
> smbtorture test,
> and I think i MAY have discovered why...
> I added some debug statements to the code to print out the tdb->map_ptr
> value after
> opening/expanding/ect  a tdb file when calling tdb_mmap, and discovered that
> HP-UX mmap can return a tdb_mmap value of '0'.  The man page for mmap SAYS
> that this
> should not happen, but hey...
> I think what is happening in my case is that because we are falling thru to
> filesystem
> reads and writes if mmap isn't working, and HP-UX doesn't have a unified
> buffer cache, that
> when we DO use a tdb_mmap of 0, we start using reads and writes (see code
> snippet from tdb.c
> below)
> /* read a lump of data at a specified offset, maybe convert */
> static int tdb_read(TDB_CONTEXT *tdb,tdb_off off,void *buf,tdb_len len,int
> cv)
> {
>         if (tdb_oob(tdb, off + len, 0) != 0) return -1;
>         if (tdb->map_ptr) memcpy(buf, off + (char *)tdb->map_ptr, len);
>         else if (lseek(tdb->fd, off, SEEK_SET) != off
>                  || read(tdb->fd, buf, len) != (ssize_t)len) {
> ...
> but not all of the other tdb calls (like tdb_fetch, for example)  test
> against tdb->map_ptr
> being 0...

All tdb fetch/set calls eventually go through tdb_read()
and tdb_write(). These calls check for tdb->map_ptr being
null and then use lseek/read/write instead.

The problem is that when one tdb using process changes to
read/write, under a system with a non-coherent mmap/read/write
cache all processes must change to doing so. Currently this doesn't
happen, as when one process tries to re-mmap and it fails,
other processes that happily have it mmapped will continue
to write to areas within the mmapped range using memcpy,
only switching to read/write when they need to write to
an area outside their current mmapped range.

I'm looking at a way to cause tdb to switch to read/write
for all processes once a mmap has failed (or returned zero,
which is the same thing).

It does look like HPUX does have a broken mmap implementation


Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.

More information about the samba-technical mailing list