Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: wapbl panic on new system with too much memory! (Paul Goyette) writes:

>In any case, if the bp->b_flags access needs to be protected by the 
>mutex, a cursory grep shows that there are some other places that might 
>need similar treatment, in wapbl_do_io(), wapbl_resize_buf(), and 

Not b_flags, just the B_LOCKED flag which is abused as a "is already
in wl_bufs list" marker.

These are the two operations that need to be protected:

	if (B_LOCKED) {
		remove from wl_bufs
	} else {
		do accounting for that buf
	add to wl_bufs

	remove from wl_bufs
	clear B_LOCKED

wapbl_resize_buf apparently assumes that it cannot be
called concurrently with wapbl_remove_buf. That should
be ok since add_buf/remove_buf/resize_buf are just
additions to vfs_bio functions.

bdwrite()  -> WAPBL_ADD_BUF
brelsel()  -> WAPBL_REMOVE_BUF
allocbuf() -> WAPBL_RESIZE_BUF

I doubt that allocbuf() and brelsel() run concurrently on
the same buffer.

wapbl_doio only initializes the flags in a new buffer. That's
not relevant.

wapbl_write_blocks iterates over the whole wl_bufs list
and uses wl_rwlock to protect it. But is that sufficient?

                                Michael van Elst
                                "A potential Snark may lurk in every tree."

Home | Main Index | Thread Index | Old Index