search for: list_next_entri

This patch replace list_entry with list_{next/prev}_entry as it makes the code more clear to read. Done using coccinelle: @@ expression e1; identifier e3; type t; @@ ( - list_entry(e1->e3.next,t,e3) + list_next_entry(e1,e3) | - list_entry(e1->e3.prev,t,e3) + list_prev_entry(e1,e3) ) Signed-off-by: Arushi Singhal <arushisinghal19971997 at gmail.com> --- drivers/gpu/drm/drm_lease.c

On Mon, Mar 19, 2018 at 12:44 PM, Julia Lawall <julia.lawall at lip6.fr> wrote: > > > On Mon, 19 Mar 2018, Arushi Singhal wrote: > > > This patch replace list_entry with list_{next/prev}_entry as it makes > > the code more clear to read. > > Done using coccinelle: > > > > @@ > > expression e1; > > identifier e3; > > type t; >

On 7/7/23 13:00, Boris Brezillon wrote: > On Fri, 30 Jun 2023 00:25:18 +0200 > Danilo Krummrich <dakr at redhat.com> wrote: > >> +/** >> + * drm_gpuva_for_each_va_range - iternator to walk over a range of &drm_gpuvas >> + * @va__: &drm_gpuva structure to assign to in each iteration step >> + * @mgr__: &drm_gpuva_manager to walk over >> + *

On Mon, 19 Mar 2018, Arushi Singhal wrote: > This patch replace list_entry with list_{next/prev}_entry as it makes > the code more clear to read. > Done using coccinelle: > > @@ > expression e1; > identifier e3; > type t; > @@ > ( > - list_entry(e1->e3.next,t,e3) > + list_next_entry(e1,e3) > | > - list_entry(e1->e3.prev,t,e3) > +

On Mon, Mar 19, 2018 at 10:35:30AM +0530, Arushi Singhal wrote: > This patch replace list_entry with list_{next/prev}_entry as it makes > the code more clear to read. > Done using coccinelle: > > @@ > expression e1; > identifier e3; > type t; > @@ > ( > - list_entry(e1->e3.next,t,e3) > + list_next_entry(e1,e3) > | > - list_entry(e1->e3.prev,t,e3)

Replace list_entry with list_{next/prev}_entry. Arushi Singhal (2): gpu: drm/lease:: Use list_{next/prev}_entry instead of list_entry gpu: drm: nouveau: Use list_{next/prev}_entry instead of list_entry drivers/gpu/drm/drm_lease.c | 2 +- drivers/gpu/drm/nouveau/nvkm/subdev/clk/base.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- changes in v2 *All the

Hi Matias, thanks for this patch! Since this patch only concerns virtio_transport, I'd use the 'vsock/virtio' prefix in the commit title: "vsock/virtio: add support for MSG_PEEK" Some comments below: On Sun, Sep 22, 2019 at 05:48:27PM +0000, Matias Ezequiel Vara Larsen wrote: > This patch adds support for MSG_PEEK. In such a case, packets are not > removed from the

On Wed 12-07-17 20:40:19, Wei Wang wrote: > This patch adds support for reporting blocks of pages on the free list > specified by the caller. > > As pages can leave the free list during this call or immediately > afterwards, they are not guaranteed to be free after the function > returns. The only guarantee this makes is that the page was on the free > list at some point in

On Wed 12-07-17 20:40:19, Wei Wang wrote: > This patch adds support for reporting blocks of pages on the free list > specified by the caller. > > As pages can leave the free list during this call or immediately > afterwards, they are not guaranteed to be free after the function > returns. The only guarantee this makes is that the page was on the free > list at some point in

It's better to use list_entry instead of list_{next/prev}_entry as it makes the code more clear to read. This patch replace list_entry with list_{next/prev}_entry. Signed-off-by: Arushi Singhal <arushisinghal19971997 at gmail.com> --- drivers/gpu/drm/drm_lease.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c

On 19/02/18 12:23, Tomasz Nowicki wrote: [...] >> +static int viommu_receive_resp(struct viommu_dev *viommu, int nr_sent, >> + struct list_head *sent) >> +{ >> + >> + unsigned int len; >> + int nr_received = 0; >> + struct viommu_request *req, *pending; >> + >> + pending = list_first_entry_or_null(sent, struct viommu_request, list);

Add a function to find a page block on the free list specified by the caller. Pages from the page block may be used immediately after the function returns. The caller is responsible for detecting or preventing the use of such pages. Signed-off-by: Wei Wang <wei.w.wang at intel.com> Signed-off-by: Liang Li <liang.z.li at intel.com> --- include/linux/mm.h | 3 ++ mm/page_alloc.c |

Add a function to find a page block on the free list specified by the caller. Pages from the page block may be used immediately after the function returns. The caller is responsible for detecting or preventing the use of such pages. Signed-off-by: Wei Wang <wei.w.wang at intel.com> Signed-off-by: Liang Li <liang.z.li at intel.com> --- include/linux/mm.h | 5 +++ mm/page_alloc.c |

Add a function to find a page block on the free list specified by the caller. Pages from the page block may be used immediately after the function returns. The caller is responsible for detecting or preventing the use of such pages. Signed-off-by: Wei Wang <wei.w.wang at intel.com> Signed-off-by: Liang Li <liang.z.li at intel.com> --- include/linux/mm.h | 5 +++ mm/page_alloc.c |

This patch adds support for reporting blocks of pages on the free list specified by the caller. As pages can leave the free list during this call or immediately afterwards, they are not guaranteed to be free after the function returns. The only guarantee this makes is that the page was on the free list at some point in time after the function has been invoked. Therefore, it is not safe for

This patch adds support to walk through the free page blocks in the system and report them via a callback function. Some page blocks may leave the free list after the report function returns, so it is the caller's responsibility to either detect or prevent the use of such pages. Signed-off-by: Wei Wang <wei.w.wang at intel.com> Signed-off-by: Liang Li <liang.z.li at intel.com> Cc:

This patch adds support to get free page blocks from a free page list. The physical addresses of the blocks are stored to a list of buffers passed from the caller. The obtained free page blocks are hints about free pages, because there is no guarantee that they are still on the free page list after the function returns. One use example of this patch is to accelerate live migration by skipping the

On Fri 14-07-17 14:30:23, Michal Hocko wrote: > On Wed 12-07-17 20:40:19, Wei Wang wrote: > > This patch adds support for reporting blocks of pages on the free list > > specified by the caller. > > > > As pages can leave the free list during this call or immediately > > afterwards, they are not guaranteed to be free after the function > > returns. The only

On Fri, Jul 14, 2017 at 02:30:23PM +0200, Michal Hocko wrote: > On Wed 12-07-17 20:40:19, Wei Wang wrote: > > This patch adds support for reporting blocks of pages on the free list > > specified by the caller. > > > > As pages can leave the free list during this call or immediately > > afterwards, they are not guaranteed to be free after the function > >

On Wed, Jul 12, 2017 at 08:40:19PM +0800, Wei Wang wrote: > This patch adds support for reporting blocks of pages on the free list > specified by the caller. > > As pages can leave the free list during this call or immediately > afterwards, they are not guaranteed to be free after the function > returns. The only guarantee this makes is that the page was on the free > list at