Re: wapbl panic on new system with too much memory!

[mlelstv%serpens.de@localhost (Michael van Elst)]

paul%whooppee.com@localhost (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 
>wapbl_write_blocks().

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:

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

remove_buf:
	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
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."