search for: __gfp_nofail

Clang warns: kernel/resource.c:1281:53: warning: operator '?:' has lower precedence than '|'; '|' will be evaluated first [-Wbitwise-conditional-parentheses] new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0); ~~~~~~~~~~~~~~~~~~~~~~~~~ ^ kernel/resource.c:1281:53: note: place parentheses around the '|' expression to silence this warning new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0); ~~~~~~~~~~...

...ct_chunk() will return null if the physical memory has run out. As a result, if we dereference src_pfns, dst_pfns or dma_addrs, the null pointer dereference bugs will happen. Moreover, the GPU is going away. If the kcalloc() fails, we could not evict all pages mapping a chunk. So this patch adds a __GFP_NOFAIL flag in kcalloc(). Finally, as there is no need to have physically contiguous memory, this patch switches kcalloc() to kvcalloc() in order to avoid failing allocations. Fixes: 249881232e14 ("nouveau/dmem: evict device private memory during release") Suggested-by: Danilo Krummrich <da...

...> the physical memory has run out. As a result, if we dereference > src_pfns, dst_pfns or dma_addrs, the null pointer dereference bugs > will happen. > > Moreover, the GPU is going away. If the kcalloc() fails, we could not > evict all pages mapping a chunk. So this patch adds a __GFP_NOFAIL > flag in kcalloc(). > > Finally, as there is no need to have physically contiguous memory, > this patch switches kcalloc() to kvcalloc() in order to avoid > failing allocations. > > Fixes: 249881232e14 ("nouveau/dmem: evict device private memory during release") &g...

...break statement a couple lines up; > if we were passed __GFP_WAIT we terminate iff we succesfully allocated a > tag. If we weren't passed __GFP_WAIT we never actually sleep. OK ;) Let me rephrase. What guarantees that a tag will become available? If what we have here is an open-coded __GFP_NOFAIL then that is potentially problematic.

...break statement a couple lines up; > if we were passed __GFP_WAIT we terminate iff we succesfully allocated a > tag. If we weren't passed __GFP_WAIT we never actually sleep. OK ;) Let me rephrase. What guarantees that a tag will become available? If what we have here is an open-coded __GFP_NOFAIL then that is potentially problematic.

...e passed __GFP_WAIT we terminate iff we succesfully allocated a > > > tag. If we weren't passed __GFP_WAIT we never actually sleep. > > > > OK ;) Let me rephrase. What guarantees that a tag will become available? > > > > If what we have here is an open-coded __GFP_NOFAIL then that is > > potentially problematic. > > It's the same semantics as a mempool, really - it'll succeed when a tag > gets freed. OK, that's reasonable if the code is being used to generate IO tags - we expect the in-flight tags to eventually be returned. But if a cl...

...e passed __GFP_WAIT we terminate iff we succesfully allocated a > > > tag. If we weren't passed __GFP_WAIT we never actually sleep. > > > > OK ;) Let me rephrase. What guarantees that a tag will become available? > > > > If what we have here is an open-coded __GFP_NOFAIL then that is > > potentially problematic. > > It's the same semantics as a mempool, really - it'll succeed when a tag > gets freed. OK, that's reasonable if the code is being used to generate IO tags - we expect the in-flight tags to eventually be returned. But if a cl...

Hi, I''ve discovered that some btrfs code doesn''t check whether kmalloc() call succeeded. I poorly understand what this code does and how it can be changed, maybe it would be happy with __GFP_NOFAIL. Also there are BUG_ON() after kmalloc()''s, if they could be changed not to panic it would be great. --- ./fs/btrfs/compression.c 2010-07-06 16:45:48.000000000 +0400 +++ /tmp/cocci-output-7773-0df3b6-compression.c 2010-07-28 18:43:07.000000000 +0400 @@ -350,7 +350,6 @@ int btrfs_submit_...

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

Some add_memory*() users add memory in small, contiguous memory blocks. Examples include virtio-mem, hyper-v balloon, and the XEN balloon. This can quickly result in a lot of memory resources, whereby the actual resource boundaries are not of interest (e.g., it might be relevant for DIMMs, exposed via /proc/iomem to user space). We really want to merge added resources in this scenario where

...fuse_forget_link *link; struct virtio_fs_forget *forget; + struct virtio_fs_forget_req *req; struct virtio_fs *fs; struct virtio_fs_vq *fsvq; u64 unique; @@ -743,14 +749,15 @@ __releases(fiq->lock) /* Allocate a buffer for the request */ forget = kmalloc(sizeof(*forget), GFP_NOFS | __GFP_NOFAIL); + req = &forget->req; - forget->ih = (struct fuse_in_header){ + req->ih = (struct fuse_in_header){ .opcode = FUSE_FORGET, .nodeid = link->forget_one.nodeid, .unique = unique, - .len = sizeof(*forget), + .len = sizeof(*req), }; - forget->arg = (struct fuse_forget_...

...tree.c b/fs/btrfs/extent-tree.c index a07d510..86b57c8 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -5263,6 +5263,8 @@ static int pin_down_extent(struct btrfs_root *root, set_extent_dirty(root->fs_info->pinned_extents, bytenr, bytenr + num_bytes - 1, GFP_NOFS | __GFP_NOFAIL); + if (reserved) + trace_btrfs_reserved_extent_free(root, bytenr, num_bytes); return 0; } @@ -5966,6 +5968,7 @@ void btrfs_free_tree_block(struct btrfs_trans_handle *trans, btrfs_add_free_space(cache, buf->start, buf->len); btrfs_update_reserved_bytes(cache, buf->len, RESERV...

...s up; > > if we were passed __GFP_WAIT we terminate iff we succesfully allocated a > > tag. If we weren't passed __GFP_WAIT we never actually sleep. > > OK ;) Let me rephrase. What guarantees that a tag will become available? > > If what we have here is an open-coded __GFP_NOFAIL then that is > potentially problematic. It's the same semantics as a mempool, really - it'll succeed when a tag gets freed. If we are sleeping then there isn't really anything else we can do, there isn't anything we're trying in the __GFP_WAIT case that we're not trying...

...rminate iff we succesfully allocated a > > > > tag. If we weren't passed __GFP_WAIT we never actually sleep. > > > > > > OK ;) Let me rephrase. What guarantees that a tag will become available? > > > > > > If what we have here is an open-coded __GFP_NOFAIL then that is > > > potentially problematic. > > > > It's the same semantics as a mempool, really - it'll succeed when a tag > > gets freed. > > OK, that's reasonable if the code is being used to generate IO tags - > we expect the in-flight tags to e...

...on probably is to query queue size in the beginning and make sure number of pages attached to a request are less then that. > > So my proposed solution is to turn fsvq->lock into a mutex; call > virtqueue_add_sgs() with whatever gfp flags are used to allocate the > request and add __GFP_NOFAIL for good measure. This means that the > request is guaranteed to use a single slot IF "indirect_desc" is on. > And there should be some way to verify from the virtiofs code that > this feature is indeed on, otherwise things can get messy (as noted > above). Sounds reasonable...

Hi all - The following 9 patches add more error handling to the btrfs code: - Add btrfs_panic - Catch locking failures in {set,clear}_extent_bit - Push up set_extent_bit errors to callers - Push up lock_extent errors to callers - Push up clear_extent_bit errors to callers - Push up unlock_extent errors to callers - Make pin_down_extent return void - Push up btrfs_pin_extent errors to

...* just before releasing the region. This is highly unlikely to + * fail - let's play save and make it never fail as the caller cannot + * perform any error handling (e.g., trying to re-add memory will fail + * similarly). + */ +retry: + new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0); p = &parent->child; write_lock(&resource_lock); @@ -1295,7 +1302,6 @@ int release_mem_region_adjustable(struct resource *parent, * so if we are dealing with them, let us just back off here. */ if (!(res->flags & IORESOURCE_SYSRAM)) { - ret = 0; break;...

...fuse_request_end(fc, req); - spin_lock(&fsvq->lock); - dec_in_flight_req(fsvq); - spin_unlock(&fsvq->lock); + /* blocking async request completes in a worker context */ + if (req->args->may_block) { + struct virtio_fs_req_work *w; + + w = kzalloc(sizeof(*w), GFP_NOFS | __GFP_NOFAIL); + INIT_WORK(&w->done_work, virtio_fs_complete_req_work); + w->fsvq = fsvq; + w->req = req; + schedule_work(&w->done_work); + } else { + virtio_fs_request_complete(req, fsvq); + } } } -- 2.25.1

...fuse_request_end(fc, req); - spin_lock(&fsvq->lock); - dec_in_flight_req(fsvq); - spin_unlock(&fsvq->lock); + /* blocking async request completes in a worker context */ + if (req->args->may_block) { + struct virtio_fs_req_work *w; + + w = kzalloc(sizeof(*w), GFP_NOFS | __GFP_NOFAIL); + INIT_WORK(&w->done_work, virtio_fs_complete_req_work); + w->fsvq = fsvq; + w->req = req; + schedule_work(&w->done_work); + } else { + virtio_fs_request_complete(req, fsvq); + } } } -- 2.25.1

...* just before releasing the region. This is highly unlikely to + * fail - let's play save and make it never fail as the caller cannot + * perform any error handling (e.g., trying to re-add memory will fail + * similarly). + */ +retry: + new_res = alloc_resource(GFP_KERNEL | alloc_nofail ? __GFP_NOFAIL : 0); p = &parent->child; write_lock(&resource_lock); @@ -1298,7 +1305,6 @@ int release_mem_region_adjustable(struct resource *parent, * so if we are dealing with them, let us just back off here. */ if (!(res->flags & IORESOURCE_SYSRAM)) { - ret = 0; break;...