On Sun, Mar 3, 2013 at 2:51 PM, Al Viro wrote:
>
> +struct vfree_deferred {
> + spinlock_t lock;
> + void *list;
> + struct work_struct wq;
> +};
Looking more at this, just get rid of the spinlock entirely, and use
for the list.
IRQ-safety without the locking. Because you got
On Sun, Mar 03, 2013 at 02:34:00PM -0800, Linus Torvalds wrote:
> On Sun, Mar 3, 2013 at 10:47 AM, Al Viro wrote:
> > To bring back the thing discussed back in, IIRC, December: we have
> > a bunch of places where inability to do vfree() from interrupt contexts
> > (the most common case is
On Sun, Mar 3, 2013 at 10:47 AM, Al Viro wrote:
> To bring back the thing discussed back in, IIRC, December: we have
> a bunch of places where inability to do vfree() from interrupt contexts
> (the most common case is doing that from RCU callback) leads to very
> ugly open-coded schemes th
On Sun, Mar 03, 2013 at 06:47:36PM +, Al Viro wrote:
> To bring back the thing discussed back in, IIRC, December: we have
> a bunch of places where inability to do vfree() from interrupt contexts
> (the most common case is doing that from RCU callback) leads to very
> ugly open-coded sche
To bring back the thing discussed back in, IIRC, December: we have
a bunch of places where inability to do vfree() from interrupt contexts
(the most common case is doing that from RCU callback) leads to very
ugly open-coded schemes that delay it one way or another. We can let vfree()
itsel
5 matches
Mail list logo
