On Wed, Sep 04, 2013 at 04:35:50PM -0700, kernel neophyte wrote:
> On Fri, Aug 30, 2013 at 2:15 PM, Kent Overstreet wrote:
> > GFP_NOIO means we could be getting called recursively - mca_alloc() ->
> > mca_data_alloc() - definitely can't use mutex_lock(bucket_lock) then.
> > Whoops.
> >
> >
On Fri, Aug 30, 2013 at 2:15 PM, Kent Overstreet wrote:
> GFP_NOIO means we could be getting called recursively - mca_alloc() ->
> mca_data_alloc() - definitely can't use mutex_lock(bucket_lock) then.
> Whoops.
>
> Signed-off-by: Kent Overstreet
Awesome! I tested the fix... no crashes/deadlock.
On Fri, Aug 30, 2013 at 2:15 PM, Kent Overstreet k...@daterainc.com wrote:
GFP_NOIO means we could be getting called recursively - mca_alloc() -
mca_data_alloc() - definitely can't use mutex_lock(bucket_lock) then.
Whoops.
Signed-off-by: Kent Overstreet k...@daterainc.com
Awesome! I tested
On Wed, Sep 04, 2013 at 04:35:50PM -0700, kernel neophyte wrote:
On Fri, Aug 30, 2013 at 2:15 PM, Kent Overstreet k...@daterainc.com wrote:
GFP_NOIO means we could be getting called recursively - mca_alloc() -
mca_data_alloc() - definitely can't use mutex_lock(bucket_lock) then.
Whoops.
Thanks! No crashes since your fix.
Stefan
This mail was sent with my iPhone.
Am 30.08.2013 um 23:15 schrieb Kent Overstreet :
> GFP_NOIO means we could be getting called recursively - mca_alloc() ->
> mca_data_alloc() - definitely can't use mutex_lock(bucket_lock) then.
> Whoops.
>
>
Thanks! No crashes since your fix.
Stefan
This mail was sent with my iPhone.
Am 30.08.2013 um 23:15 schrieb Kent Overstreet k...@daterainc.com:
GFP_NOIO means we could be getting called recursively - mca_alloc() -
mca_data_alloc() - definitely can't use mutex_lock(bucket_lock) then.
Whoops.
thanks applied to my local kernel git
Stefan
Am 30.08.2013 23:15, schrieb Kent Overstreet:
GFP_NOIO means we could be getting called recursively - mca_alloc() ->
mca_data_alloc() - definitely can't use mutex_lock(bucket_lock) then.
Whoops.
Signed-off-by: Kent Overstreet
---
On Thu, Aug 29,
thanks applied to my local kernel git
Stefan
Am 30.08.2013 23:15, schrieb Kent Overstreet:
GFP_NOIO means we could be getting called recursively - mca_alloc() -
mca_data_alloc() - definitely can't use mutex_lock(bucket_lock) then.
Whoops.
Signed-off-by: Kent Overstreet k...@daterainc.com
---
On Fri, Aug 30 2013, Kent Overstreet wrote:
> GFP_NOIO means we could be getting called recursively - mca_alloc() ->
> mca_data_alloc() - definitely can't use mutex_lock(bucket_lock) then.
> Whoops.
Kent, can you provide and updated repo with the pending patches? There's
been some churn here
GFP_NOIO means we could be getting called recursively - mca_alloc() ->
mca_data_alloc() - definitely can't use mutex_lock(bucket_lock) then.
Whoops.
Signed-off-by: Kent Overstreet
---
On Thu, Aug 29, 2013 at 05:29:54PM -0700, kernel neophyte wrote:
> We are evaluating to use bcache on our
GFP_NOIO means we could be getting called recursively - mca_alloc() -
mca_data_alloc() - definitely can't use mutex_lock(bucket_lock) then.
Whoops.
Signed-off-by: Kent Overstreet k...@daterainc.com
---
On Thu, Aug 29, 2013 at 05:29:54PM -0700, kernel neophyte wrote:
We are evaluating to use
On Fri, Aug 30 2013, Kent Overstreet wrote:
GFP_NOIO means we could be getting called recursively - mca_alloc() -
mca_data_alloc() - definitely can't use mutex_lock(bucket_lock) then.
Whoops.
Kent, can you provide and updated repo with the pending patches? There's
been some churn here lately
12 matches
Mail list logo