On Fri, Aug 16, 2013 at 01:37:45PM +0200, Stefan Behrens wrote:
> On Wed, 7 Aug 2013 17:11:49 -0400, Josef Bacik wrote:
> > There is no reason we can't just set the path to blocking and then do normal
> > GFP_NOFS allocations for these extent buffers. Thanks,
> >
> > Signed-off-by: Josef Bacik
>
On Wed, 7 Aug 2013 17:11:49 -0400, Josef Bacik wrote:
> There is no reason we can't just set the path to blocking and then do normal
> GFP_NOFS allocations for these extent buffers. Thanks,
>
> Signed-off-by: Josef Bacik
You've forgotten at least one place.
static inline struct extent_buffer *
On Thu, August 08, 2013 at 15:12 (+0200), Josef Bacik wrote:
> On Thu, Aug 08, 2013 at 09:23:06AM +0200, Jan Schmidt wrote:
>>
>> On Wed, August 07, 2013 at 23:11 (+0200), Josef Bacik wrote:
>>> There is no reason we can't just set the path to blocking and then do normal
>>> GFP_NOFS allocations
On Thu, Aug 08, 2013 at 09:23:06AM +0200, Jan Schmidt wrote:
>
> On Wed, August 07, 2013 at 23:11 (+0200), Josef Bacik wrote:
> > There is no reason we can't just set the path to blocking and then do normal
> > GFP_NOFS allocations for these extent buffers. Thanks,
> >
> > Signed-off-by: Josef
On Wed, August 07, 2013 at 23:11 (+0200), Josef Bacik wrote:
> There is no reason we can't just set the path to blocking and then do normal
> GFP_NOFS allocations for these extent buffers. Thanks,
>
> Signed-off-by: Josef Bacik
> ---
> fs/btrfs/ctree.c | 16 ++--
> fs/btrfs/
There is no reason we can't just set the path to blocking and then do normal
GFP_NOFS allocations for these extent buffers. Thanks,
Signed-off-by: Josef Bacik
---
fs/btrfs/ctree.c | 16 ++--
fs/btrfs/extent_io.c |8
2 files changed, 14 insertions(+), 10 deletions(
