in inotify code (source/smbd/notify_inotify.c) there's this code fragment (simplified):

        ioctl(in->fd, FIONREAD, &bufsize);
        e0 = (struct inotify_event *)TALLOC_SIZE(in, bufsize);

        if (sys_read(in->fd, e0, bufsize) != bufsize) {
                DEBUG(0,("Failed to read all inotify data\n"));
                talloc_free(e0);
                return;
        }

This code assumes that read(2) returns all available data in single step.  There's no such guarantee in POSIX, and it seems that at least with linux kernel 2.6.31-rc8 this assumption in this very place is not true anymore.

In my case FIONREAD returns more than read actually reads (read returned some value rounded to 4096, but FIONREAD had several bytes more).  This results in the above message printed in the log, which is harmless by its own.

But the thing is that we now out of sync with the structures coming from kernel, so the next read on this inotify fd will start from some middle of the structure.  And smbd happily crash here tryin to interpret the garbage.

[2009/09/05 14:16:09,  0] smbd/notify_inotify.c:inotify_handler(247)
  Failed to read all inotify data
*** glibc detected *** /usr/sbin/smbd: free(): invalid next size (fast): 0x08636618 ***
======= Backtrace: =========
/lib/i686/cmov/libc.so.6[0xf7d91624]
/lib/i686/cmov/libc.so.6(cfree+0x96)[0xf7d93826]
/usr/lib/libtalloc.so.1(talloc_free+0x153)[0xf7e8c443]
/usr/sbin/smbd[0x821661e]
/usr/sbin/smbd(run_events+0x1c2)[0x81f3947]
/usr/sbin/smbd[0x80d781c]
/usr/sbin/smbd(smbd_process+0xf8)[0x80d9ed0]
/usr/sbin/smbd(main+0xfa2)[0x80a1d1f]
/lib/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xf7d39455]
/usr/sbin/smbd[0x809edb1]
...

This happens with several 3.3.x and 3.4.0 versions (I didn't try 3.2.x).
Reverting to kernel 2.6.30 fixes it again.

But note that I'd not say it's a kernel issue - the whole logic is wrong in samba.

See also http://forums.gentoo.org/viewtopic-t-790838.html with exactly the same problem.