All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Jakob Koschel <jakobkoschel@gmail.com>,
	Linus Torvalds <torvalds@linux-foundation.org>
Cc: alsa-devel@alsa-project.org, linux-aspeed@lists.ozlabs.org,
	"Gustavo A. R. Silva" <gustavo@embeddedor.com>,
	linux-iio@vger.kernel.org, nouveau@lists.freedesktop.org,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	dri-devel@lists.freedesktop.org,
	Cristiano Giuffrida <c.giuffrida@vu.nl>,
	amd-gfx@lists.freedesktop.org, samba-technical@lists.samba.org,
	linux1394-devel@lists.sourceforge.net, drbd-dev@lists.linbit.com,
	linux-arch <linux-arch@vger.kernel.org>,
	linux-cifs@vger.kernel.org, kvm@vger.kernel.org,
	linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org,
	linux-staging@lists.linux.dev, "Bos, H.J." <h.j.bos@vu.nl>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	intel-wired-lan@lists.osuosl.org,
	kgdb-bugreport@lists.sourceforge.net,
	bcm-kernel-feedback-list@broadcom.com,
	Dan Carpenter <dan.carpenter@oracle.com>,
	linux-media@vger.kernel.org, Kees Cook <keescook@chromium.org>,
	Arnd Bergman <arnd@arndb.de>,
	linux-pm@vger.kernel.org, intel-gfx@lists.freedesktop.org,
	Brian Johannesmeyer <bjohannesmeyer@gmail.com>,
	Nathan Chancellor <nathan@kernel.org>,
	linux-fsdevel@vger.kernel.org,
	Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
	v9fs-developer@lists.sourceforge.net,
	linux-tegra@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	linux-arm-kernel@lists.infradead.org, linux-sgx@vger.kernel.org,
	linux-block@vger.kernel.org, netdev@vger.kernel.org,
	linux-usb@vger.kernel.org, linux-wireless@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	tipc-discussion@lists.sourceforge.net,
	linux-crypto@vger.kernel.org, dmaengine@vger.kernel.org,
	linux-mediatek@lists.infradead.org,
	Andrew Morton <akpm@linux-foundation.org>,
	linuxppc-dev@lists.ozlabs.org, Mike Rapoport <rppt@kernel.org>
Subject: Re: [Intel-gfx] [PATCH 6/6] treewide: remove check of list iterator against head past the loop body
Date: Wed, 2 Mar 2022 17:14:50 +0000	[thread overview]
Message-ID: <ed52ce3c-0f4a-a1e8-4176-543657d6228d@linux.intel.com> (raw)
In-Reply-To: <20220228110822.491923-7-jakobkoschel@gmail.com>


On 28/02/2022 11:08, Jakob Koschel wrote:
> When list_for_each_entry() completes the iteration over the whole list
> without breaking the loop, the iterator value will be a bogus pointer
> computed based on the head element.
> 
> While it is safe to use the pointer to determine if it was computed
> based on the head element, either with list_entry_is_head() or
> &pos->member == head, using the iterator variable after the loop should
> be avoided.
> 
> In preparation to limiting the scope of a list iterator to the list
> traversal loop, use a dedicated pointer to point to the found element.
> 
> Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com>

[snip until i915 parts]

>   drivers/gpu/drm/i915/gem/i915_gem_context.c   | 14 +++---
>   .../gpu/drm/i915/gem/i915_gem_execbuffer.c    | 15 ++++---
>   drivers/gpu/drm/i915/gt/intel_ring.c          | 15 ++++---

[snip]

> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 00327b750fbb..80c79028901a 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -107,25 +107,27 @@ static void lut_close(struct i915_gem_context *ctx)
>   	radix_tree_for_each_slot(slot, &ctx->handles_vma, &iter, 0) {
>   		struct i915_vma *vma = rcu_dereference_raw(*slot);
>   		struct drm_i915_gem_object *obj = vma->obj;
> -		struct i915_lut_handle *lut;
> +		struct i915_lut_handle *lut = NULL;
> +		struct i915_lut_handle *tmp;
> 
>   		if (!kref_get_unless_zero(&obj->base.refcount))
>   			continue;
> 
>   		spin_lock(&obj->lut_lock);
> -		list_for_each_entry(lut, &obj->lut_list, obj_link) {
> -			if (lut->ctx != ctx)
> +		list_for_each_entry(tmp, &obj->lut_list, obj_link) {
> +			if (tmp->ctx != ctx)
>   				continue;
> 
> -			if (lut->handle != iter.index)
> +			if (tmp->handle != iter.index)
>   				continue;
> 
> -			list_del(&lut->obj_link);
> +			list_del(&tmp->obj_link);
> +			lut = tmp;
>   			break;
>   		}
>   		spin_unlock(&obj->lut_lock);
> 
> -		if (&lut->obj_link != &obj->lut_list) {
> +		if (lut) {
>   			i915_lut_handle_free(lut);
>   			radix_tree_iter_delete(&ctx->handles_vma, &iter, slot);

Looks okay although personally I would have left lut as is for a smaller 
diff and introduced a new local like 'found' or 'unlinked'.

>   			i915_vma_close(vma);
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 1736efa43339..fda9e3685ad2 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -2444,7 +2444,8 @@ static struct i915_request *eb_throttle(struct i915_execbuffer *eb, struct intel
>   {
>   	struct intel_ring *ring = ce->ring;
>   	struct intel_timeline *tl = ce->timeline;
> -	struct i915_request *rq;
> +	struct i915_request *rq = NULL;
> +	struct i915_request *tmp;
> 
>   	/*
>   	 * Completely unscientific finger-in-the-air estimates for suitable
> @@ -2460,15 +2461,17 @@ static struct i915_request *eb_throttle(struct i915_execbuffer *eb, struct intel
>   	 * claiming our resources, but not so long that the ring completely
>   	 * drains before we can submit our next request.
>   	 */
> -	list_for_each_entry(rq, &tl->requests, link) {
> -		if (rq->ring != ring)
> +	list_for_each_entry(tmp, &tl->requests, link) {
> +		if (tmp->ring != ring)
>   			continue;
> 
> -		if (__intel_ring_space(rq->postfix,
> -				       ring->emit, ring->size) > ring->size / 2)
> +		if (__intel_ring_space(tmp->postfix,
> +				       ring->emit, ring->size) > ring->size / 2) {
> +			rq = tmp;
>   			break;
> +		}
>   	}
> -	if (&rq->link == &tl->requests)
> +	if (!rq)
>   		return NULL; /* weird, we will check again later for real */

Alternatively, instead of break could simply do "return 
i915_request_get(rq);" and replace the end of the function after the 
loop with "return NULL;". A bit smaller diff, or at least less "spread 
out" over the function, so might be easier to backport stuff touching 
this area in the future. But looks correct as is.

> 
>   	return i915_request_get(rq);
> diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c b/drivers/gpu/drm/i915/gt/intel_ring.c
> index 2fdd52b62092..4881c4e0c407 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ring.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ring.c
> @@ -191,24 +191,27 @@ wait_for_space(struct intel_ring *ring,
>   	       struct intel_timeline *tl,
>   	       unsigned int bytes)
>   {
> -	struct i915_request *target;
> +	struct i915_request *target = NULL;
> +	struct i915_request *tmp;
>   	long timeout;
> 
>   	if (intel_ring_update_space(ring) >= bytes)
>   		return 0;
> 
>   	GEM_BUG_ON(list_empty(&tl->requests));
> -	list_for_each_entry(target, &tl->requests, link) {
> -		if (target->ring != ring)
> +	list_for_each_entry(tmp, &tl->requests, link) {
> +		if (tmp->ring != ring)
>   			continue;
> 
>   		/* Would completion of this request free enough space? */
> -		if (bytes <= __intel_ring_space(target->postfix,
> -						ring->emit, ring->size))
> +		if (bytes <= __intel_ring_space(tmp->postfix,
> +						ring->emit, ring->size)) {
> +			target = tmp;
>   			break;
> +		}
>   	}
> 
> -	if (GEM_WARN_ON(&target->link == &tl->requests))
> +	if (GEM_WARN_ON(!target))
>   		return -ENOSPC;
> 
>   	timeout = i915_request_wait(target,

Looks okay as well. Less clear here if there is a clean solution to make 
the diff smaller so no suggestions. I mean do I dare mention "goto 
found;" from inside the loop, where the break is, instead of the 
variable renames.. risky.. :) (And ofc "return -ENOSPC" immediately 
after the loop.)

As a summary changes looks okay, up to you if you want to try to make 
the diffs smaller or not. It doesn't matter hugely really, all I have is 
a vague and uncertain "maybe it makes backporting of something, someday 
easier". So for i915 it is good either way.

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> # i915 bits only

Regards,

Tvrtko

WARNING: multiple messages have this Message-ID (diff)
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Jakob Koschel <jakobkoschel@gmail.com>,
	Linus Torvalds <torvalds@linux-foundation.org>
Cc: alsa-devel@alsa-project.org, linux-aspeed@lists.ozlabs.org,
	"Gustavo A. R. Silva" <gustavo@embeddedor.com>,
	linux-iio@vger.kernel.org, nouveau@lists.freedesktop.org,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	dri-devel@lists.freedesktop.org,
	Cristiano Giuffrida <c.giuffrida@vu.nl>,
	amd-gfx@lists.freedesktop.org, samba-technical@lists.samba.org,
	linux1394-devel@lists.sourceforge.net, drbd-dev@lists.linbit.com,
	linux-arch <linux-arch@vger.kernel.org>,
	linux-cifs@vger.kernel.org, kvm@vger.kernel.org,
	linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org,
	linux-staging@lists.linux.dev, "Bos, H.J." <h.j.bos@vu.nl>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	intel-wired-lan@lists.osuosl.org,
	kgdb-bugreport@lists.sourceforge.net,
	bcm-kernel-feedback-list@broadcom.com,
	Dan Carpenter <dan.carpenter@oracle.com>,
	linux-media@vger.kernel.org, Kees Cook <keescook@chromium.org>,
	Arnd Bergman <arnd@arndb.de>,
	linux-pm@vger.kernel.org, intel-gfx@lists.freedesktop.org,
	Brian Johannesmeyer <bjohannesmeyer@gmail.com>,
	Nathan Chancellor <nathan@kernel.org>,
	linux-fsdevel@vger.kernel.org,
	Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
	v9fs-developer@lists.sourceforge.net,
	linux-tegra@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	linux-arm-kernel@lists.infradead.org, linux-sgx@vger.kernel.org,
	linux-block@vger.kernel.org, netdev@vger.kernel.org,
	linux-usb@vger.kernel.org, linux-wireless@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	tipc-discussion@lists.sourceforge.net,
	linux-crypto@vger.kernel.org, dmaengine@vger.kernel.org,
	linux-mediatek@lists.infradead.org,
	Andrew Morton <akpm@linux-foundation.org>,
	linuxppc-dev@lists.ozlabs.org, Mike Rapoport <rppt@kernel.org>
Subject: Re: [Intel-gfx] [PATCH 6/6] treewide: remove check of list iterator against head past the loop body
Date: Wed, 2 Mar 2022 17:14:50 +0000	[thread overview]
Message-ID: <ed52ce3c-0f4a-a1e8-4176-543657d6228d@linux.intel.com> (raw)
In-Reply-To: <20220228110822.491923-7-jakobkoschel@gmail.com>


On 28/02/2022 11:08, Jakob Koschel wrote:
> When list_for_each_entry() completes the iteration over the whole list
> without breaking the loop, the iterator value will be a bogus pointer
> computed based on the head element.
> 
> While it is safe to use the pointer to determine if it was computed
> based on the head element, either with list_entry_is_head() or
> &pos->member == head, using the iterator variable after the loop should
> be avoided.
> 
> In preparation to limiting the scope of a list iterator to the list
> traversal loop, use a dedicated pointer to point to the found element.
> 
> Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com>

[snip until i915 parts]

>   drivers/gpu/drm/i915/gem/i915_gem_context.c   | 14 +++---
>   .../gpu/drm/i915/gem/i915_gem_execbuffer.c    | 15 ++++---
>   drivers/gpu/drm/i915/gt/intel_ring.c          | 15 ++++---

[snip]

> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 00327b750fbb..80c79028901a 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -107,25 +107,27 @@ static void lut_close(struct i915_gem_context *ctx)
>   	radix_tree_for_each_slot(slot, &ctx->handles_vma, &iter, 0) {
>   		struct i915_vma *vma = rcu_dereference_raw(*slot);
>   		struct drm_i915_gem_object *obj = vma->obj;
> -		struct i915_lut_handle *lut;
> +		struct i915_lut_handle *lut = NULL;
> +		struct i915_lut_handle *tmp;
> 
>   		if (!kref_get_unless_zero(&obj->base.refcount))
>   			continue;
> 
>   		spin_lock(&obj->lut_lock);
> -		list_for_each_entry(lut, &obj->lut_list, obj_link) {
> -			if (lut->ctx != ctx)
> +		list_for_each_entry(tmp, &obj->lut_list, obj_link) {
> +			if (tmp->ctx != ctx)
>   				continue;
> 
> -			if (lut->handle != iter.index)
> +			if (tmp->handle != iter.index)
>   				continue;
> 
> -			list_del(&lut->obj_link);
> +			list_del(&tmp->obj_link);
> +			lut = tmp;
>   			break;
>   		}
>   		spin_unlock(&obj->lut_lock);
> 
> -		if (&lut->obj_link != &obj->lut_list) {
> +		if (lut) {
>   			i915_lut_handle_free(lut);
>   			radix_tree_iter_delete(&ctx->handles_vma, &iter, slot);

Looks okay although personally I would have left lut as is for a smaller 
diff and introduced a new local like 'found' or 'unlinked'.

>   			i915_vma_close(vma);
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 1736efa43339..fda9e3685ad2 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -2444,7 +2444,8 @@ static struct i915_request *eb_throttle(struct i915_execbuffer *eb, struct intel
>   {
>   	struct intel_ring *ring = ce->ring;
>   	struct intel_timeline *tl = ce->timeline;
> -	struct i915_request *rq;
> +	struct i915_request *rq = NULL;
> +	struct i915_request *tmp;
> 
>   	/*
>   	 * Completely unscientific finger-in-the-air estimates for suitable
> @@ -2460,15 +2461,17 @@ static struct i915_request *eb_throttle(struct i915_execbuffer *eb, struct intel
>   	 * claiming our resources, but not so long that the ring completely
>   	 * drains before we can submit our next request.
>   	 */
> -	list_for_each_entry(rq, &tl->requests, link) {
> -		if (rq->ring != ring)
> +	list_for_each_entry(tmp, &tl->requests, link) {
> +		if (tmp->ring != ring)
>   			continue;
> 
> -		if (__intel_ring_space(rq->postfix,
> -				       ring->emit, ring->size) > ring->size / 2)
> +		if (__intel_ring_space(tmp->postfix,
> +				       ring->emit, ring->size) > ring->size / 2) {
> +			rq = tmp;
>   			break;
> +		}
>   	}
> -	if (&rq->link == &tl->requests)
> +	if (!rq)
>   		return NULL; /* weird, we will check again later for real */

Alternatively, instead of break could simply do "return 
i915_request_get(rq);" and replace the end of the function after the 
loop with "return NULL;". A bit smaller diff, or at least less "spread 
out" over the function, so might be easier to backport stuff touching 
this area in the future. But looks correct as is.

> 
>   	return i915_request_get(rq);
> diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c b/drivers/gpu/drm/i915/gt/intel_ring.c
> index 2fdd52b62092..4881c4e0c407 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ring.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ring.c
> @@ -191,24 +191,27 @@ wait_for_space(struct intel_ring *ring,
>   	       struct intel_timeline *tl,
>   	       unsigned int bytes)
>   {
> -	struct i915_request *target;
> +	struct i915_request *target = NULL;
> +	struct i915_request *tmp;
>   	long timeout;
> 
>   	if (intel_ring_update_space(ring) >= bytes)
>   		return 0;
> 
>   	GEM_BUG_ON(list_empty(&tl->requests));
> -	list_for_each_entry(target, &tl->requests, link) {
> -		if (target->ring != ring)
> +	list_for_each_entry(tmp, &tl->requests, link) {
> +		if (tmp->ring != ring)
>   			continue;
> 
>   		/* Would completion of this request free enough space? */
> -		if (bytes <= __intel_ring_space(target->postfix,
> -						ring->emit, ring->size))
> +		if (bytes <= __intel_ring_space(tmp->postfix,
> +						ring->emit, ring->size)) {
> +			target = tmp;
>   			break;
> +		}
>   	}
> 
> -	if (GEM_WARN_ON(&target->link == &tl->requests))
> +	if (GEM_WARN_ON(!target))
>   		return -ENOSPC;
> 
>   	timeout = i915_request_wait(target,

Looks okay as well. Less clear here if there is a clean solution to make 
the diff smaller so no suggestions. I mean do I dare mention "goto 
found;" from inside the loop, where the break is, instead of the 
variable renames.. risky.. :) (And ofc "return -ENOSPC" immediately 
after the loop.)

As a summary changes looks okay, up to you if you want to try to make 
the diffs smaller or not. It doesn't matter hugely really, all I have is 
a vague and uncertain "maybe it makes backporting of something, someday 
easier". So for i915 it is good either way.

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> # i915 bits only

Regards,

Tvrtko

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

WARNING: multiple messages have this Message-ID (diff)
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Jakob Koschel <jakobkoschel@gmail.com>,
	Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-wireless@vger.kernel.org, alsa-devel@alsa-project.org,
	kvm@vger.kernel.org,
	"Gustavo A. R. Silva" <gustavo@embeddedor.com>,
	linux-iio@vger.kernel.org, nouveau@lists.freedesktop.org,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	dri-devel@lists.freedesktop.org,
	Cristiano Giuffrida <c.giuffrida@vu.nl>,
	amd-gfx@lists.freedesktop.org,
	linux1394-devel@lists.sourceforge.net, drbd-dev@lists.linbit.com,
	linux-arch <linux-arch@vger.kernel.org>,
	linux-cifs@vger.kernel.org, linux-aspeed@lists.ozlabs.org,
	linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org,
	linux-staging@lists.linux.dev, "Bos, H.J." <h.j.bos@vu.nl>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	intel-wired-lan@lists.osuosl.org,
	kgdb-bugreport@lists.sourceforge.net,
	bcm-kernel-feedback-list@broadcom.com,
	Dan Carpenter <dan.carpenter@oracle.com>,
	linux-media@vger.kernel.org, Kees Cook <keescook@chromium.org>,
	Arnd Bergman <arnd@arndb.de>,
	linux-pm@vger.kernel.org, intel-gfx@lists.freedesktop.org,
	Brian Johannesmeyer <bjohannesmeyer@gmail.com>,
	Nathan Chancellor <nathan@kernel.org>,
	dmaengine@vger.kernel.org,
	Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
	v9fs-developer@lists.sourceforge.net,
	linux-tegra@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	linux-arm-kernel@lists.infradead.org, linux-sgx@vger.kernel.org,
	linux-block@vger.kernel.org, netdev@vger.kernel.org,
	linux-usb@vger.kernel.org, samba-technical@lists.samba.org,
	linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	tipc-discussion@lists.sourceforge.net,
	linux-crypto@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-mediatek@lists.infradead.org,
	Andrew Morton <akpm@linux-foundation.org>,
	linuxppc-dev@lists.ozlabs.org, Mike Rapoport <rppt@kernel.org>
Subject: Re: [Intel-gfx] [PATCH 6/6] treewide: remove check of list iterator against head past the loop body
Date: Wed, 2 Mar 2022 17:14:50 +0000	[thread overview]
Message-ID: <ed52ce3c-0f4a-a1e8-4176-543657d6228d@linux.intel.com> (raw)
In-Reply-To: <20220228110822.491923-7-jakobkoschel@gmail.com>


On 28/02/2022 11:08, Jakob Koschel wrote:
> When list_for_each_entry() completes the iteration over the whole list
> without breaking the loop, the iterator value will be a bogus pointer
> computed based on the head element.
> 
> While it is safe to use the pointer to determine if it was computed
> based on the head element, either with list_entry_is_head() or
> &pos->member == head, using the iterator variable after the loop should
> be avoided.
> 
> In preparation to limiting the scope of a list iterator to the list
> traversal loop, use a dedicated pointer to point to the found element.
> 
> Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com>

[snip until i915 parts]

>   drivers/gpu/drm/i915/gem/i915_gem_context.c   | 14 +++---
>   .../gpu/drm/i915/gem/i915_gem_execbuffer.c    | 15 ++++---
>   drivers/gpu/drm/i915/gt/intel_ring.c          | 15 ++++---

[snip]

> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 00327b750fbb..80c79028901a 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -107,25 +107,27 @@ static void lut_close(struct i915_gem_context *ctx)
>   	radix_tree_for_each_slot(slot, &ctx->handles_vma, &iter, 0) {
>   		struct i915_vma *vma = rcu_dereference_raw(*slot);
>   		struct drm_i915_gem_object *obj = vma->obj;
> -		struct i915_lut_handle *lut;
> +		struct i915_lut_handle *lut = NULL;
> +		struct i915_lut_handle *tmp;
> 
>   		if (!kref_get_unless_zero(&obj->base.refcount))
>   			continue;
> 
>   		spin_lock(&obj->lut_lock);
> -		list_for_each_entry(lut, &obj->lut_list, obj_link) {
> -			if (lut->ctx != ctx)
> +		list_for_each_entry(tmp, &obj->lut_list, obj_link) {
> +			if (tmp->ctx != ctx)
>   				continue;
> 
> -			if (lut->handle != iter.index)
> +			if (tmp->handle != iter.index)
>   				continue;
> 
> -			list_del(&lut->obj_link);
> +			list_del(&tmp->obj_link);
> +			lut = tmp;
>   			break;
>   		}
>   		spin_unlock(&obj->lut_lock);
> 
> -		if (&lut->obj_link != &obj->lut_list) {
> +		if (lut) {
>   			i915_lut_handle_free(lut);
>   			radix_tree_iter_delete(&ctx->handles_vma, &iter, slot);

Looks okay although personally I would have left lut as is for a smaller 
diff and introduced a new local like 'found' or 'unlinked'.

>   			i915_vma_close(vma);
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 1736efa43339..fda9e3685ad2 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -2444,7 +2444,8 @@ static struct i915_request *eb_throttle(struct i915_execbuffer *eb, struct intel
>   {
>   	struct intel_ring *ring = ce->ring;
>   	struct intel_timeline *tl = ce->timeline;
> -	struct i915_request *rq;
> +	struct i915_request *rq = NULL;
> +	struct i915_request *tmp;
> 
>   	/*
>   	 * Completely unscientific finger-in-the-air estimates for suitable
> @@ -2460,15 +2461,17 @@ static struct i915_request *eb_throttle(struct i915_execbuffer *eb, struct intel
>   	 * claiming our resources, but not so long that the ring completely
>   	 * drains before we can submit our next request.
>   	 */
> -	list_for_each_entry(rq, &tl->requests, link) {
> -		if (rq->ring != ring)
> +	list_for_each_entry(tmp, &tl->requests, link) {
> +		if (tmp->ring != ring)
>   			continue;
> 
> -		if (__intel_ring_space(rq->postfix,
> -				       ring->emit, ring->size) > ring->size / 2)
> +		if (__intel_ring_space(tmp->postfix,
> +				       ring->emit, ring->size) > ring->size / 2) {
> +			rq = tmp;
>   			break;
> +		}
>   	}
> -	if (&rq->link == &tl->requests)
> +	if (!rq)
>   		return NULL; /* weird, we will check again later for real */

Alternatively, instead of break could simply do "return 
i915_request_get(rq);" and replace the end of the function after the 
loop with "return NULL;". A bit smaller diff, or at least less "spread 
out" over the function, so might be easier to backport stuff touching 
this area in the future. But looks correct as is.

> 
>   	return i915_request_get(rq);
> diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c b/drivers/gpu/drm/i915/gt/intel_ring.c
> index 2fdd52b62092..4881c4e0c407 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ring.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ring.c
> @@ -191,24 +191,27 @@ wait_for_space(struct intel_ring *ring,
>   	       struct intel_timeline *tl,
>   	       unsigned int bytes)
>   {
> -	struct i915_request *target;
> +	struct i915_request *target = NULL;
> +	struct i915_request *tmp;
>   	long timeout;
> 
>   	if (intel_ring_update_space(ring) >= bytes)
>   		return 0;
> 
>   	GEM_BUG_ON(list_empty(&tl->requests));
> -	list_for_each_entry(target, &tl->requests, link) {
> -		if (target->ring != ring)
> +	list_for_each_entry(tmp, &tl->requests, link) {
> +		if (tmp->ring != ring)
>   			continue;
> 
>   		/* Would completion of this request free enough space? */
> -		if (bytes <= __intel_ring_space(target->postfix,
> -						ring->emit, ring->size))
> +		if (bytes <= __intel_ring_space(tmp->postfix,
> +						ring->emit, ring->size)) {
> +			target = tmp;
>   			break;
> +		}
>   	}
> 
> -	if (GEM_WARN_ON(&target->link == &tl->requests))
> +	if (GEM_WARN_ON(!target))
>   		return -ENOSPC;
> 
>   	timeout = i915_request_wait(target,

Looks okay as well. Less clear here if there is a clean solution to make 
the diff smaller so no suggestions. I mean do I dare mention "goto 
found;" from inside the loop, where the break is, instead of the 
variable renames.. risky.. :) (And ofc "return -ENOSPC" immediately 
after the loop.)

As a summary changes looks okay, up to you if you want to try to make 
the diffs smaller or not. It doesn't matter hugely really, all I have is 
a vague and uncertain "maybe it makes backporting of something, someday 
easier". So for i915 it is good either way.

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> # i915 bits only

Regards,

Tvrtko

WARNING: multiple messages have this Message-ID (diff)
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Jakob Koschel <jakobkoschel@gmail.com>,
	Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-wireless@vger.kernel.org, alsa-devel@alsa-project.org,
	kvm@vger.kernel.org,
	"Gustavo A. R. Silva" <gustavo@embeddedor.com>,
	linux-iio@vger.kernel.org, nouveau@lists.freedesktop.org,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	dri-devel@lists.freedesktop.org,
	Cristiano Giuffrida <c.giuffrida@vu.nl>,
	amd-gfx@lists.freedesktop.org,
	linux1394-devel@lists.sourceforge.net, drbd-dev@lists.linbit.com,
	linux-arch <linux-arch@vger.kernel.org>,
	linux-cifs@vger.kernel.org, linux-aspeed@lists.ozlabs.org,
	linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org,
	linux-staging@lists.linux.dev, "Bos, H.J." <h.j.bos@vu.nl>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	intel-wired-lan@lists.osuosl.org,
	kgdb-bugreport@lists.sourceforge.net,
	bcm-kernel-feedback-list@broadcom.com,
	Dan Carpenter <dan.carpenter@oracle.com>,
	linux-media@vger.kernel.org, Kees Cook <keescook@chromium.org>,
	Arnd Bergman <arnd@arndb.de>,
	linux-pm@vger.kernel.org, intel-gfx@lists.freedesktop.org,
	Brian Johannesmeyer <bjohannesmeyer@gmail.com>,
	Nathan Chancellor <nathan@kernel.org>,
	dmaengine@vger.kernel.org,
	Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
	v9fs-developer@lists.sourceforge.net,
	linux-tegra@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	linux-arm-kernel@lists.infradead.org, linux-sgx@vger.kernel.org,
	linux-block@vger.kernel.org, netdev@vger.kernel.org,
	linux-usb@vger.kernel.org, samba-technical@lists.samba.org,
	linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	tipc-discussion@lists.sourceforge.net,
	linux-crypto@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-mediatek@lists.infradead.org,
	Andrew Morton <akpm@linux-foundation.org>,
	linuxppc-dev@lists.ozlabs.org, Mike Rapoport <rppt@kernel.org>
Subject: Re: [f2fs-dev] [Intel-gfx] [PATCH 6/6] treewide: remove check of list iterator against head past the loop body
Date: Wed, 2 Mar 2022 17:14:50 +0000	[thread overview]
Message-ID: <ed52ce3c-0f4a-a1e8-4176-543657d6228d@linux.intel.com> (raw)
In-Reply-To: <20220228110822.491923-7-jakobkoschel@gmail.com>


On 28/02/2022 11:08, Jakob Koschel wrote:
> When list_for_each_entry() completes the iteration over the whole list
> without breaking the loop, the iterator value will be a bogus pointer
> computed based on the head element.
> 
> While it is safe to use the pointer to determine if it was computed
> based on the head element, either with list_entry_is_head() or
> &pos->member == head, using the iterator variable after the loop should
> be avoided.
> 
> In preparation to limiting the scope of a list iterator to the list
> traversal loop, use a dedicated pointer to point to the found element.
> 
> Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com>

[snip until i915 parts]

>   drivers/gpu/drm/i915/gem/i915_gem_context.c   | 14 +++---
>   .../gpu/drm/i915/gem/i915_gem_execbuffer.c    | 15 ++++---
>   drivers/gpu/drm/i915/gt/intel_ring.c          | 15 ++++---

[snip]

> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 00327b750fbb..80c79028901a 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -107,25 +107,27 @@ static void lut_close(struct i915_gem_context *ctx)
>   	radix_tree_for_each_slot(slot, &ctx->handles_vma, &iter, 0) {
>   		struct i915_vma *vma = rcu_dereference_raw(*slot);
>   		struct drm_i915_gem_object *obj = vma->obj;
> -		struct i915_lut_handle *lut;
> +		struct i915_lut_handle *lut = NULL;
> +		struct i915_lut_handle *tmp;
> 
>   		if (!kref_get_unless_zero(&obj->base.refcount))
>   			continue;
> 
>   		spin_lock(&obj->lut_lock);
> -		list_for_each_entry(lut, &obj->lut_list, obj_link) {
> -			if (lut->ctx != ctx)
> +		list_for_each_entry(tmp, &obj->lut_list, obj_link) {
> +			if (tmp->ctx != ctx)
>   				continue;
> 
> -			if (lut->handle != iter.index)
> +			if (tmp->handle != iter.index)
>   				continue;
> 
> -			list_del(&lut->obj_link);
> +			list_del(&tmp->obj_link);
> +			lut = tmp;
>   			break;
>   		}
>   		spin_unlock(&obj->lut_lock);
> 
> -		if (&lut->obj_link != &obj->lut_list) {
> +		if (lut) {
>   			i915_lut_handle_free(lut);
>   			radix_tree_iter_delete(&ctx->handles_vma, &iter, slot);

Looks okay although personally I would have left lut as is for a smaller 
diff and introduced a new local like 'found' or 'unlinked'.

>   			i915_vma_close(vma);
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 1736efa43339..fda9e3685ad2 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -2444,7 +2444,8 @@ static struct i915_request *eb_throttle(struct i915_execbuffer *eb, struct intel
>   {
>   	struct intel_ring *ring = ce->ring;
>   	struct intel_timeline *tl = ce->timeline;
> -	struct i915_request *rq;
> +	struct i915_request *rq = NULL;
> +	struct i915_request *tmp;
> 
>   	/*
>   	 * Completely unscientific finger-in-the-air estimates for suitable
> @@ -2460,15 +2461,17 @@ static struct i915_request *eb_throttle(struct i915_execbuffer *eb, struct intel
>   	 * claiming our resources, but not so long that the ring completely
>   	 * drains before we can submit our next request.
>   	 */
> -	list_for_each_entry(rq, &tl->requests, link) {
> -		if (rq->ring != ring)
> +	list_for_each_entry(tmp, &tl->requests, link) {
> +		if (tmp->ring != ring)
>   			continue;
> 
> -		if (__intel_ring_space(rq->postfix,
> -				       ring->emit, ring->size) > ring->size / 2)
> +		if (__intel_ring_space(tmp->postfix,
> +				       ring->emit, ring->size) > ring->size / 2) {
> +			rq = tmp;
>   			break;
> +		}
>   	}
> -	if (&rq->link == &tl->requests)
> +	if (!rq)
>   		return NULL; /* weird, we will check again later for real */

Alternatively, instead of break could simply do "return 
i915_request_get(rq);" and replace the end of the function after the 
loop with "return NULL;". A bit smaller diff, or at least less "spread 
out" over the function, so might be easier to backport stuff touching 
this area in the future. But looks correct as is.

> 
>   	return i915_request_get(rq);
> diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c b/drivers/gpu/drm/i915/gt/intel_ring.c
> index 2fdd52b62092..4881c4e0c407 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ring.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ring.c
> @@ -191,24 +191,27 @@ wait_for_space(struct intel_ring *ring,
>   	       struct intel_timeline *tl,
>   	       unsigned int bytes)
>   {
> -	struct i915_request *target;
> +	struct i915_request *target = NULL;
> +	struct i915_request *tmp;
>   	long timeout;
> 
>   	if (intel_ring_update_space(ring) >= bytes)
>   		return 0;
> 
>   	GEM_BUG_ON(list_empty(&tl->requests));
> -	list_for_each_entry(target, &tl->requests, link) {
> -		if (target->ring != ring)
> +	list_for_each_entry(tmp, &tl->requests, link) {
> +		if (tmp->ring != ring)
>   			continue;
> 
>   		/* Would completion of this request free enough space? */
> -		if (bytes <= __intel_ring_space(target->postfix,
> -						ring->emit, ring->size))
> +		if (bytes <= __intel_ring_space(tmp->postfix,
> +						ring->emit, ring->size)) {
> +			target = tmp;
>   			break;
> +		}
>   	}
> 
> -	if (GEM_WARN_ON(&target->link == &tl->requests))
> +	if (GEM_WARN_ON(!target))
>   		return -ENOSPC;
> 
>   	timeout = i915_request_wait(target,

Looks okay as well. Less clear here if there is a clean solution to make 
the diff smaller so no suggestions. I mean do I dare mention "goto 
found;" from inside the loop, where the break is, instead of the 
variable renames.. risky.. :) (And ofc "return -ENOSPC" immediately 
after the loop.)

As a summary changes looks okay, up to you if you want to try to make 
the diffs smaller or not. It doesn't matter hugely really, all I have is 
a vague and uncertain "maybe it makes backporting of something, someday 
easier". So for i915 it is good either way.

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> # i915 bits only

Regards,

Tvrtko


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

WARNING: multiple messages have this Message-ID (diff)
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Jakob Koschel <jakobkoschel@gmail.com>,
	Linus Torvalds <torvalds@linux-foundation.org>
Cc: linux-wireless@vger.kernel.org, alsa-devel@alsa-project.org,
	kvm@vger.kernel.org,
	"Gustavo A. R. Silva" <gustavo@embeddedor.com>,
	linux-iio@vger.kernel.org, nouveau@lists.freedesktop.org,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	dri-devel@lists.freedesktop.org,
	Cristiano Giuffrida <c.giuffrida@vu.nl>,
	amd-gfx@lists.freedesktop.org,
	linux1394-devel@lists.sourceforge.net, drbd-dev@lists.linbit.com,
	linux-arch <linux-arch@vger.kernel.org>,
	linux-cifs@vger.kernel.org, linux-aspeed@lists.ozlabs.org,
	linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org,
	linux-staging@lists.linux.dev, "Bos, H.J." <h.j.bos@vu.nl>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	intel-wired-lan@lists.osuosl.org,
	kgdb-bugreport@lists.sourceforge.net,
	bcm-kernel-feedback-list@broadcom.com,
	Dan Carpenter <dan.carpenter@oracle.com>,
	linux-media@vger.kernel.org, Kees Cook <keescook@chromium.org>,
	Arnd Bergman <arnd@arndb.de>,
	linux-pm@vger.kernel.org, intel-gfx@lists.freedesktop.org,
	Brian Johannesmeyer <bjohannesmeyer@gmail.com>,
	Nathan Chancellor <nathan@kernel.org>,
	dmaengine@vger.kernel.org,
	Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
	v9fs-developer@lists.sourceforge.net,
	linux-tegra@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	linux-arm-kernel@lists.infradead.org, linux-sgx@vger.kernel.org,
	linux-block@vger.kernel.org, netdev@vger.kernel.org,
	linux-usb@vger.kernel.org, samba-technical@lists.samba.org,
	linux-kernel@vger.kernel.org,
	linux-f2fs-devel@lists.sourceforge.net,
	tipc-discussion@lists.sourceforge.net,
	linux-crypto@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-mediatek@lists.infradead.org,
	Andrew Morton <akpm@linux-foundation.org>,
	linuxppc-dev@lists.ozlabs.org, Mike Rapoport <rppt@kernel.org>
Subject: Re: [Nouveau] [Intel-gfx] [PATCH 6/6] treewide: remove check of list iterator against head past the loop body
Date: Wed, 2 Mar 2022 17:14:50 +0000	[thread overview]
Message-ID: <ed52ce3c-0f4a-a1e8-4176-543657d6228d@linux.intel.com> (raw)
In-Reply-To: <20220228110822.491923-7-jakobkoschel@gmail.com>


On 28/02/2022 11:08, Jakob Koschel wrote:
> When list_for_each_entry() completes the iteration over the whole list
> without breaking the loop, the iterator value will be a bogus pointer
> computed based on the head element.
> 
> While it is safe to use the pointer to determine if it was computed
> based on the head element, either with list_entry_is_head() or
> &pos->member == head, using the iterator variable after the loop should
> be avoided.
> 
> In preparation to limiting the scope of a list iterator to the list
> traversal loop, use a dedicated pointer to point to the found element.
> 
> Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com>

[snip until i915 parts]

>   drivers/gpu/drm/i915/gem/i915_gem_context.c   | 14 +++---
>   .../gpu/drm/i915/gem/i915_gem_execbuffer.c    | 15 ++++---
>   drivers/gpu/drm/i915/gt/intel_ring.c          | 15 ++++---

[snip]

> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 00327b750fbb..80c79028901a 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -107,25 +107,27 @@ static void lut_close(struct i915_gem_context *ctx)
>   	radix_tree_for_each_slot(slot, &ctx->handles_vma, &iter, 0) {
>   		struct i915_vma *vma = rcu_dereference_raw(*slot);
>   		struct drm_i915_gem_object *obj = vma->obj;
> -		struct i915_lut_handle *lut;
> +		struct i915_lut_handle *lut = NULL;
> +		struct i915_lut_handle *tmp;
> 
>   		if (!kref_get_unless_zero(&obj->base.refcount))
>   			continue;
> 
>   		spin_lock(&obj->lut_lock);
> -		list_for_each_entry(lut, &obj->lut_list, obj_link) {
> -			if (lut->ctx != ctx)
> +		list_for_each_entry(tmp, &obj->lut_list, obj_link) {
> +			if (tmp->ctx != ctx)
>   				continue;
> 
> -			if (lut->handle != iter.index)
> +			if (tmp->handle != iter.index)
>   				continue;
> 
> -			list_del(&lut->obj_link);
> +			list_del(&tmp->obj_link);
> +			lut = tmp;
>   			break;
>   		}
>   		spin_unlock(&obj->lut_lock);
> 
> -		if (&lut->obj_link != &obj->lut_list) {
> +		if (lut) {
>   			i915_lut_handle_free(lut);
>   			radix_tree_iter_delete(&ctx->handles_vma, &iter, slot);

Looks okay although personally I would have left lut as is for a smaller 
diff and introduced a new local like 'found' or 'unlinked'.

>   			i915_vma_close(vma);
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 1736efa43339..fda9e3685ad2 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -2444,7 +2444,8 @@ static struct i915_request *eb_throttle(struct i915_execbuffer *eb, struct intel
>   {
>   	struct intel_ring *ring = ce->ring;
>   	struct intel_timeline *tl = ce->timeline;
> -	struct i915_request *rq;
> +	struct i915_request *rq = NULL;
> +	struct i915_request *tmp;
> 
>   	/*
>   	 * Completely unscientific finger-in-the-air estimates for suitable
> @@ -2460,15 +2461,17 @@ static struct i915_request *eb_throttle(struct i915_execbuffer *eb, struct intel
>   	 * claiming our resources, but not so long that the ring completely
>   	 * drains before we can submit our next request.
>   	 */
> -	list_for_each_entry(rq, &tl->requests, link) {
> -		if (rq->ring != ring)
> +	list_for_each_entry(tmp, &tl->requests, link) {
> +		if (tmp->ring != ring)
>   			continue;
> 
> -		if (__intel_ring_space(rq->postfix,
> -				       ring->emit, ring->size) > ring->size / 2)
> +		if (__intel_ring_space(tmp->postfix,
> +				       ring->emit, ring->size) > ring->size / 2) {
> +			rq = tmp;
>   			break;
> +		}
>   	}
> -	if (&rq->link == &tl->requests)
> +	if (!rq)
>   		return NULL; /* weird, we will check again later for real */

Alternatively, instead of break could simply do "return 
i915_request_get(rq);" and replace the end of the function after the 
loop with "return NULL;". A bit smaller diff, or at least less "spread 
out" over the function, so might be easier to backport stuff touching 
this area in the future. But looks correct as is.

> 
>   	return i915_request_get(rq);
> diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c b/drivers/gpu/drm/i915/gt/intel_ring.c
> index 2fdd52b62092..4881c4e0c407 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ring.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ring.c
> @@ -191,24 +191,27 @@ wait_for_space(struct intel_ring *ring,
>   	       struct intel_timeline *tl,
>   	       unsigned int bytes)
>   {
> -	struct i915_request *target;
> +	struct i915_request *target = NULL;
> +	struct i915_request *tmp;
>   	long timeout;
> 
>   	if (intel_ring_update_space(ring) >= bytes)
>   		return 0;
> 
>   	GEM_BUG_ON(list_empty(&tl->requests));
> -	list_for_each_entry(target, &tl->requests, link) {
> -		if (target->ring != ring)
> +	list_for_each_entry(tmp, &tl->requests, link) {
> +		if (tmp->ring != ring)
>   			continue;
> 
>   		/* Would completion of this request free enough space? */
> -		if (bytes <= __intel_ring_space(target->postfix,
> -						ring->emit, ring->size))
> +		if (bytes <= __intel_ring_space(tmp->postfix,
> +						ring->emit, ring->size)) {
> +			target = tmp;
>   			break;
> +		}
>   	}
> 
> -	if (GEM_WARN_ON(&target->link == &tl->requests))
> +	if (GEM_WARN_ON(!target))
>   		return -ENOSPC;
> 
>   	timeout = i915_request_wait(target,

Looks okay as well. Less clear here if there is a clean solution to make 
the diff smaller so no suggestions. I mean do I dare mention "goto 
found;" from inside the loop, where the break is, instead of the 
variable renames.. risky.. :) (And ofc "return -ENOSPC" immediately 
after the loop.)

As a summary changes looks okay, up to you if you want to try to make 
the diffs smaller or not. It doesn't matter hugely really, all I have is 
a vague and uncertain "maybe it makes backporting of something, someday 
easier". So for i915 it is good either way.

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> # i915 bits only

Regards,

Tvrtko

WARNING: multiple messages have this Message-ID (diff)
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: intel-wired-lan@osuosl.org
Subject: [Intel-wired-lan] [Intel-gfx] [PATCH 6/6] treewide: remove check of list iterator against head past the loop body
Date: Wed, 2 Mar 2022 17:14:50 +0000	[thread overview]
Message-ID: <ed52ce3c-0f4a-a1e8-4176-543657d6228d@linux.intel.com> (raw)
In-Reply-To: <20220228110822.491923-7-jakobkoschel@gmail.com>


On 28/02/2022 11:08, Jakob Koschel wrote:
> When list_for_each_entry() completes the iteration over the whole list
> without breaking the loop, the iterator value will be a bogus pointer
> computed based on the head element.
> 
> While it is safe to use the pointer to determine if it was computed
> based on the head element, either with list_entry_is_head() or
> &pos->member == head, using the iterator variable after the loop should
> be avoided.
> 
> In preparation to limiting the scope of a list iterator to the list
> traversal loop, use a dedicated pointer to point to the found element.
> 
> Signed-off-by: Jakob Koschel <jakobkoschel@gmail.com>

[snip until i915 parts]

>   drivers/gpu/drm/i915/gem/i915_gem_context.c   | 14 +++---
>   .../gpu/drm/i915/gem/i915_gem_execbuffer.c    | 15 ++++---
>   drivers/gpu/drm/i915/gt/intel_ring.c          | 15 ++++---

[snip]

> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 00327b750fbb..80c79028901a 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -107,25 +107,27 @@ static void lut_close(struct i915_gem_context *ctx)
>   	radix_tree_for_each_slot(slot, &ctx->handles_vma, &iter, 0) {
>   		struct i915_vma *vma = rcu_dereference_raw(*slot);
>   		struct drm_i915_gem_object *obj = vma->obj;
> -		struct i915_lut_handle *lut;
> +		struct i915_lut_handle *lut = NULL;
> +		struct i915_lut_handle *tmp;
> 
>   		if (!kref_get_unless_zero(&obj->base.refcount))
>   			continue;
> 
>   		spin_lock(&obj->lut_lock);
> -		list_for_each_entry(lut, &obj->lut_list, obj_link) {
> -			if (lut->ctx != ctx)
> +		list_for_each_entry(tmp, &obj->lut_list, obj_link) {
> +			if (tmp->ctx != ctx)
>   				continue;
> 
> -			if (lut->handle != iter.index)
> +			if (tmp->handle != iter.index)
>   				continue;
> 
> -			list_del(&lut->obj_link);
> +			list_del(&tmp->obj_link);
> +			lut = tmp;
>   			break;
>   		}
>   		spin_unlock(&obj->lut_lock);
> 
> -		if (&lut->obj_link != &obj->lut_list) {
> +		if (lut) {
>   			i915_lut_handle_free(lut);
>   			radix_tree_iter_delete(&ctx->handles_vma, &iter, slot);

Looks okay although personally I would have left lut as is for a smaller 
diff and introduced a new local like 'found' or 'unlinked'.

>   			i915_vma_close(vma);
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 1736efa43339..fda9e3685ad2 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -2444,7 +2444,8 @@ static struct i915_request *eb_throttle(struct i915_execbuffer *eb, struct intel
>   {
>   	struct intel_ring *ring = ce->ring;
>   	struct intel_timeline *tl = ce->timeline;
> -	struct i915_request *rq;
> +	struct i915_request *rq = NULL;
> +	struct i915_request *tmp;
> 
>   	/*
>   	 * Completely unscientific finger-in-the-air estimates for suitable
> @@ -2460,15 +2461,17 @@ static struct i915_request *eb_throttle(struct i915_execbuffer *eb, struct intel
>   	 * claiming our resources, but not so long that the ring completely
>   	 * drains before we can submit our next request.
>   	 */
> -	list_for_each_entry(rq, &tl->requests, link) {
> -		if (rq->ring != ring)
> +	list_for_each_entry(tmp, &tl->requests, link) {
> +		if (tmp->ring != ring)
>   			continue;
> 
> -		if (__intel_ring_space(rq->postfix,
> -				       ring->emit, ring->size) > ring->size / 2)
> +		if (__intel_ring_space(tmp->postfix,
> +				       ring->emit, ring->size) > ring->size / 2) {
> +			rq = tmp;
>   			break;
> +		}
>   	}
> -	if (&rq->link == &tl->requests)
> +	if (!rq)
>   		return NULL; /* weird, we will check again later for real */

Alternatively, instead of break could simply do "return 
i915_request_get(rq);" and replace the end of the function after the 
loop with "return NULL;". A bit smaller diff, or at least less "spread 
out" over the function, so might be easier to backport stuff touching 
this area in the future. But looks correct as is.

> 
>   	return i915_request_get(rq);
> diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c b/drivers/gpu/drm/i915/gt/intel_ring.c
> index 2fdd52b62092..4881c4e0c407 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ring.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ring.c
> @@ -191,24 +191,27 @@ wait_for_space(struct intel_ring *ring,
>   	       struct intel_timeline *tl,
>   	       unsigned int bytes)
>   {
> -	struct i915_request *target;
> +	struct i915_request *target = NULL;
> +	struct i915_request *tmp;
>   	long timeout;
> 
>   	if (intel_ring_update_space(ring) >= bytes)
>   		return 0;
> 
>   	GEM_BUG_ON(list_empty(&tl->requests));
> -	list_for_each_entry(target, &tl->requests, link) {
> -		if (target->ring != ring)
> +	list_for_each_entry(tmp, &tl->requests, link) {
> +		if (tmp->ring != ring)
>   			continue;
> 
>   		/* Would completion of this request free enough space? */
> -		if (bytes <= __intel_ring_space(target->postfix,
> -						ring->emit, ring->size))
> +		if (bytes <= __intel_ring_space(tmp->postfix,
> +						ring->emit, ring->size)) {
> +			target = tmp;
>   			break;
> +		}
>   	}
> 
> -	if (GEM_WARN_ON(&target->link == &tl->requests))
> +	if (GEM_WARN_ON(!target))
>   		return -ENOSPC;
> 
>   	timeout = i915_request_wait(target,

Looks okay as well. Less clear here if there is a clean solution to make 
the diff smaller so no suggestions. I mean do I dare mention "goto 
found;" from inside the loop, where the break is, instead of the 
variable renames.. risky.. :) (And ofc "return -ENOSPC" immediately 
after the loop.)

As a summary changes looks okay, up to you if you want to try to make 
the diffs smaller or not. It doesn't matter hugely really, all I have is 
a vague and uncertain "maybe it makes backporting of something, someday 
easier". So for i915 it is good either way.

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> # i915 bits only

Regards,

Tvrtko

  parent reply	other threads:[~2022-03-02 17:15 UTC|newest]

Thread overview: 596+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-28 11:08 [PATCH 0/6] Remove usage of list iterator past the loop body Jakob Koschel
2022-02-28 11:08 ` [Intel-wired-lan] " Jakob Koschel
2022-02-28 11:08 ` [Nouveau] " Jakob Koschel
2022-02-28 11:08 ` [Intel-gfx] " Jakob Koschel
2022-02-28 11:08 ` Jakob Koschel
2022-02-28 11:08 ` Jakob Koschel
2022-02-28 11:08 ` [f2fs-dev] " Jakob Koschel
2022-02-28 11:08 ` [PATCH 1/6] drivers: usb: remove " Jakob Koschel
2022-02-28 11:08   ` [Intel-wired-lan] " Jakob Koschel
2022-02-28 11:08   ` [Nouveau] " Jakob Koschel
2022-02-28 11:08   ` [Intel-gfx] " Jakob Koschel
2022-02-28 11:08   ` Jakob Koschel
2022-02-28 11:08   ` Jakob Koschel
2022-02-28 11:08   ` [f2fs-dev] " Jakob Koschel
2022-02-28 11:24   ` Dan Carpenter
2022-02-28 11:24     ` [Intel-wired-lan] " Dan Carpenter
2022-02-28 11:24     ` [Nouveau] " Dan Carpenter
2022-02-28 11:24     ` Dan Carpenter
2022-02-28 11:24     ` [f2fs-dev] " Dan Carpenter
2022-02-28 11:24     ` [Intel-gfx] " Dan Carpenter
2022-02-28 11:24     ` Dan Carpenter
2022-02-28 12:03     ` Jakob Koschel
2022-02-28 12:03       ` [Intel-wired-lan] " Jakob Koschel
2022-02-28 12:03       ` [Nouveau] " Jakob Koschel
2022-02-28 12:03       ` [Intel-gfx] " Jakob Koschel
2022-02-28 12:03       ` Jakob Koschel
2022-02-28 12:03       ` Jakob Koschel
2022-02-28 12:03       ` [f2fs-dev] " Jakob Koschel
2022-02-28 13:18       ` Dan Carpenter
2022-02-28 13:18         ` [Nouveau] " Dan Carpenter
2022-02-28 13:18         ` Dan Carpenter
2022-02-28 13:18         ` [f2fs-dev] " Dan Carpenter
2022-02-28 13:18         ` [Intel-gfx] " Dan Carpenter
2022-02-28 13:18         ` Dan Carpenter
2022-02-28 18:20     ` [f2fs-dev] " Joe Perches
2022-02-28 18:20       ` [Intel-wired-lan] " Joe Perches
2022-02-28 18:20       ` [Nouveau] " Joe Perches
2022-02-28 18:20       ` Joe Perches
2022-02-28 18:20       ` [Intel-gfx] " Joe Perches
2022-02-28 18:20       ` Joe Perches
2022-02-28 18:20       ` Joe Perches
2022-03-01  5:52       ` Dan Carpenter
2022-03-01  5:52         ` [Intel-wired-lan] " Dan Carpenter
2022-03-01  5:52         ` [Nouveau] " Dan Carpenter
2022-03-01  5:52         ` [f2fs-dev] " Dan Carpenter
2022-03-01  5:52         ` [Intel-gfx] " Dan Carpenter
2022-03-01  5:52         ` Dan Carpenter
2022-03-01  5:52         ` Dan Carpenter
2022-02-28 11:08 ` [PATCH 2/6] treewide: remove using list iterator after loop body as a ptr Jakob Koschel
2022-02-28 11:08   ` [Intel-wired-lan] " Jakob Koschel
2022-02-28 11:08   ` [Nouveau] " Jakob Koschel
2022-02-28 11:08   ` [Intel-gfx] " Jakob Koschel
2022-02-28 11:08   ` Jakob Koschel
2022-02-28 11:08   ` Jakob Koschel
2022-02-28 11:08   ` [f2fs-dev] " Jakob Koschel
2022-02-28 11:20   ` Greg KH
2022-02-28 11:20     ` [Intel-wired-lan] " Greg KH
2022-02-28 11:20     ` [Nouveau] " Greg KH
2022-02-28 11:20     ` Greg KH
2022-02-28 11:20     ` [Intel-gfx] " Greg KH
2022-02-28 11:20     ` Greg KH
2022-02-28 11:20     ` [f2fs-dev] " Greg KH
2022-02-28 12:06     ` Jakob Koschel
2022-02-28 12:06       ` [Intel-wired-lan] " Jakob Koschel
2022-02-28 12:06       ` [Nouveau] " Jakob Koschel
2022-02-28 12:06       ` [Intel-gfx] " Jakob Koschel
2022-02-28 12:06       ` Jakob Koschel
2022-02-28 12:06       ` Jakob Koschel
2022-02-28 12:06       ` [f2fs-dev] " Jakob Koschel
2022-03-01 17:37       ` Greg KH
2022-03-01 17:37         ` [Intel-wired-lan] " Greg KH
2022-03-01 17:37         ` [Nouveau] " Greg KH
2022-03-01 17:37         ` [f2fs-dev] " Greg KH
2022-03-01 17:37         ` Greg KH
2022-03-01 17:37         ` [Intel-gfx] " Greg KH
2022-03-01 17:37         ` Greg KH
2022-02-28 12:19   ` Christian König
2022-02-28 12:19     ` [Intel-wired-lan] " Christian =?unknown-8bit?q?K=C3=B6nig?=
2022-02-28 12:19     ` [Nouveau] " Christian König
2022-02-28 12:19     ` [f2fs-dev] " Christian König via Linux-f2fs-devel
2022-02-28 12:19     ` Christian König
2022-02-28 12:19     ` [Intel-gfx] " Christian König
2022-02-28 12:19     ` Christian König
2022-02-28 19:56     ` Linus Torvalds
2022-02-28 19:56       ` [Intel-wired-lan] " Linus Torvalds
2022-02-28 19:56       ` [Nouveau] " Linus Torvalds
2022-02-28 19:56       ` Linus Torvalds
2022-02-28 19:56       ` [Intel-gfx] " Linus Torvalds
2022-02-28 19:56       ` Linus Torvalds
2022-02-28 20:03       ` Linus Torvalds
2022-02-28 20:03         ` [Intel-wired-lan] " Linus Torvalds
2022-02-28 20:03         ` [Nouveau] " Linus Torvalds
2022-02-28 20:03         ` Linus Torvalds
2022-02-28 20:03         ` [f2fs-dev] " Linus Torvalds
2022-02-28 20:03         ` [Intel-gfx] " Linus Torvalds
2022-02-28 20:03         ` Linus Torvalds
2022-02-28 20:10         ` Linus Torvalds
2022-02-28 20:10           ` [Intel-wired-lan] " Linus Torvalds
2022-02-28 20:10           ` [Nouveau] " Linus Torvalds
2022-02-28 20:10           ` [Intel-gfx] " Linus Torvalds
2022-02-28 20:10           ` Linus Torvalds
2022-02-28 20:10           ` Linus Torvalds
2022-02-28 20:14           ` Linus Torvalds
2022-02-28 20:14             ` [Intel-wired-lan] " Linus Torvalds
2022-02-28 20:14             ` [Nouveau] " Linus Torvalds
2022-02-28 20:14             ` Linus Torvalds
2022-02-28 20:14             ` [f2fs-dev] " Linus Torvalds
2022-02-28 20:14             ` Linus Torvalds
2022-02-28 20:14             ` [Intel-gfx] " Linus Torvalds
2022-02-28 20:53             ` Segher Boessenkool
2022-02-28 20:53               ` [Intel-wired-lan] " Segher Boessenkool
2022-02-28 20:53               ` [Intel-gfx] " Segher Boessenkool
2022-02-28 20:53               ` [Nouveau] " Segher Boessenkool
2022-02-28 20:53               ` [f2fs-dev] " Segher Boessenkool
2022-02-28 20:53               ` Segher Boessenkool
2022-02-28 20:53               ` Segher Boessenkool
2022-02-28 20:16           ` Matthew Wilcox
2022-02-28 20:16             ` [Intel-wired-lan] " Matthew Wilcox
2022-02-28 20:16             ` [Nouveau] " Matthew Wilcox
2022-02-28 20:16             ` [Intel-gfx] " Matthew Wilcox
2022-02-28 20:16             ` Matthew Wilcox
2022-02-28 20:16             ` Matthew Wilcox
2022-02-28 20:16             ` [f2fs-dev] " Matthew Wilcox
2022-02-28 20:27             ` Johannes Berg
2022-02-28 20:27               ` [Intel-wired-lan] " Johannes Berg
2022-02-28 20:27               ` [Nouveau] " Johannes Berg
2022-02-28 20:27               ` [f2fs-dev] " Johannes Berg
2022-02-28 20:27               ` [Intel-gfx] " Johannes Berg
2022-02-28 20:27               ` Johannes Berg
2022-02-28 20:27               ` Johannes Berg
2022-02-28 20:41               ` Linus Torvalds
2022-02-28 20:41                 ` [Intel-wired-lan] " Linus Torvalds
2022-02-28 20:41                 ` [Nouveau] " Linus Torvalds
2022-02-28 20:41                 ` [Intel-gfx] " Linus Torvalds
2022-02-28 20:41                 ` Linus Torvalds
2022-02-28 20:41                 ` Linus Torvalds
2022-02-28 20:41                 ` [f2fs-dev] " Linus Torvalds
2022-02-28 20:37             ` Linus Torvalds
2022-02-28 20:37               ` [Intel-wired-lan] " Linus Torvalds
2022-02-28 20:37               ` [Nouveau] " Linus Torvalds
2022-02-28 20:37               ` [Intel-gfx] " Linus Torvalds
2022-02-28 20:37               ` [f2fs-dev] " Linus Torvalds
2022-02-28 20:37               ` Linus Torvalds
2022-02-28 20:37               ` Linus Torvalds
2022-02-28 23:26               ` Matthew Wilcox
2022-02-28 23:26                 ` [Intel-wired-lan] " Matthew Wilcox
2022-02-28 23:26                 ` [Nouveau] " Matthew Wilcox
2022-02-28 23:26                 ` [f2fs-dev] " Matthew Wilcox
2022-02-28 23:26                 ` [Intel-gfx] " Matthew Wilcox
2022-02-28 23:26                 ` Matthew Wilcox
2022-02-28 23:26                 ` Matthew Wilcox
2022-03-01  0:45                 ` Linus Torvalds
2022-03-01  0:45                   ` [Intel-wired-lan] " Linus Torvalds
2022-03-01  0:45                   ` [Nouveau] " Linus Torvalds
2022-03-01  0:45                   ` Linus Torvalds
2022-03-01  0:45                   ` Linus Torvalds
2022-03-01  0:45                   ` [Intel-gfx] " Linus Torvalds
2022-03-01  0:45                   ` [f2fs-dev] " Linus Torvalds
2022-03-01  0:57                   ` Linus Torvalds
2022-03-01  0:57                     ` [Intel-wired-lan] " Linus Torvalds
2022-03-01  0:57                     ` [Nouveau] " Linus Torvalds
2022-03-01  0:57                     ` [Intel-gfx] " Linus Torvalds
2022-03-01  0:57                     ` Linus Torvalds
2022-03-01  0:57                     ` [f2fs-dev] " Linus Torvalds
2022-03-01  0:57                     ` Linus Torvalds
2022-03-01 18:14                   ` Kees Cook
2022-03-01 18:14                     ` [Intel-wired-lan] " Kees Cook
2022-03-01 18:14                     ` [Nouveau] " Kees Cook
2022-03-01 18:14                     ` [f2fs-dev] " Kees Cook
2022-03-01 18:14                     ` [Intel-gfx] " Kees Cook
2022-03-01 18:14                     ` Kees Cook
2022-03-01 18:14                     ` Kees Cook
2022-03-01 18:47                     ` Linus Torvalds
2022-03-01 18:47                       ` [Intel-wired-lan] " Linus Torvalds
2022-03-01 18:47                       ` [Nouveau] " Linus Torvalds
2022-03-01 18:47                       ` [f2fs-dev] " Linus Torvalds
2022-03-01 18:47                       ` [Intel-gfx] " Linus Torvalds
2022-03-01 18:47                       ` Linus Torvalds
2022-03-01 18:47                       ` Linus Torvalds
2022-03-01 19:01                     ` Matthew Wilcox
2022-03-01 19:01                       ` [Intel-wired-lan] " Matthew Wilcox
2022-03-01 19:01                       ` [Nouveau] " Matthew Wilcox
2022-03-01 19:01                       ` [Intel-gfx] " Matthew Wilcox
2022-03-01 19:01                       ` [f2fs-dev] " Matthew Wilcox
2022-03-01 19:01                       ` Matthew Wilcox
2022-03-01 19:01                       ` Matthew Wilcox
2022-03-01  3:03             ` David Laight
2022-03-01  3:03               ` [Intel-wired-lan] " David Laight
2022-03-01  3:03               ` [Nouveau] " David Laight
2022-03-01  3:03               ` [Intel-gfx] " David Laight
2022-03-01  3:03               ` David Laight
2022-03-01  3:03               ` David Laight
2022-03-01  3:03               ` [f2fs-dev] " David Laight
2022-02-28 21:47           ` Jakob Koschel
2022-02-28 21:47             ` [Intel-wired-lan] " Jakob Koschel
2022-02-28 21:47             ` [Intel-gfx] " Jakob Koschel
2022-02-28 21:47             ` [Nouveau] " Jakob Koschel
2022-02-28 21:47             ` Jakob Koschel
2022-02-28 21:47             ` [f2fs-dev] " Jakob Koschel
2022-02-28 21:47             ` Jakob Koschel
2022-03-01  0:41             ` Linus Torvalds
2022-03-01  0:41               ` [Intel-wired-lan] " Linus Torvalds
2022-03-01  0:41               ` [Nouveau] " Linus Torvalds
2022-03-01  0:41               ` Linus Torvalds
2022-03-01  0:41               ` [Intel-gfx] " Linus Torvalds
2022-03-01  0:41               ` Linus Torvalds
2022-03-01  0:41               ` [f2fs-dev] " Linus Torvalds
2022-03-01  6:32               ` Jakub Kicinski
2022-03-01  6:32                 ` [Intel-wired-lan] " Jakub Kicinski
2022-03-01  6:32                 ` [Nouveau] " Jakub Kicinski
2022-03-01  6:32                 ` [Intel-gfx] " Jakub Kicinski
2022-03-01  6:32                 ` Jakub Kicinski
2022-03-01  6:32                 ` Jakub Kicinski
2022-03-01  6:32                 ` [f2fs-dev] " Jakub Kicinski
2022-03-01 11:28               ` Jakob Koschel
2022-03-01 11:28                 ` [Intel-wired-lan] " Jakob Koschel
2022-03-01 11:28                 ` [Nouveau] " Jakob Koschel
2022-03-01 11:28                 ` [Intel-gfx] " Jakob Koschel
2022-03-01 11:28                 ` [f2fs-dev] " Jakob Koschel
2022-03-01 11:28                 ` Jakob Koschel
2022-03-01 11:28                 ` Jakob Koschel
2022-03-01 17:36                 ` Greg KH
2022-03-01 17:36                   ` [Intel-wired-lan] " Greg KH
2022-03-01 17:36                   ` [Nouveau] " Greg KH
2022-03-01 17:36                   ` [f2fs-dev] " Greg KH
2022-03-01 17:36                   ` [Intel-gfx] " Greg KH
2022-03-01 17:36                   ` Greg KH
2022-03-01 17:36                   ` Greg KH
2022-03-01 17:40                   ` [f2fs-dev] " Jakob Koschel
2022-03-01 17:40                     ` [Intel-wired-lan] " Jakob Koschel
2022-03-01 17:40                     ` [Nouveau] " Jakob Koschel
2022-03-01 17:40                     ` [Intel-gfx] " Jakob Koschel
2022-03-01 17:40                     ` Jakob Koschel
2022-03-01 17:40                     ` Jakob Koschel
2022-03-01 17:40                     ` Jakob Koschel
2022-03-01 17:58                     ` Greg KH
2022-03-01 17:58                       ` [Intel-wired-lan] " Greg KH
2022-03-01 17:58                       ` [Nouveau] " Greg KH
2022-03-01 17:58                       ` [Intel-gfx] " Greg KH
2022-03-01 17:58                       ` Greg KH
2022-03-01 17:58                       ` Greg KH
2022-03-01 17:58                       ` [f2fs-dev] " Greg KH
2022-03-01 18:21                 ` Kees Cook
2022-03-01 18:21                   ` [Intel-wired-lan] " Kees Cook
2022-03-01 18:21                   ` [Nouveau] " Kees Cook
2022-03-01 18:21                   ` [f2fs-dev] " Kees Cook
2022-03-01 18:21                   ` [Intel-gfx] " Kees Cook
2022-03-01 18:21                   ` Kees Cook
2022-03-01 18:21                   ` Kees Cook
2022-03-02  9:31               ` Xiaomeng Tong
2022-03-02  9:31                 ` [Intel-wired-lan] " Xiaomeng Tong
2022-03-02  9:31                 ` [Nouveau] " Xiaomeng Tong
2022-03-02  9:31                 ` [Intel-gfx] " Xiaomeng Tong
2022-03-02  9:31                 ` Xiaomeng Tong
2022-03-02  9:31                 ` Xiaomeng Tong
2022-03-02  9:31                 ` [f2fs-dev] " Xiaomeng Tong
2022-03-02 14:04                 ` David Laight
2022-03-02 14:04                   ` [Intel-wired-lan] " David Laight
2022-03-02 14:04                   ` [Nouveau] " David Laight
2022-03-02 14:04                   ` [Intel-gfx] " David Laight
2022-03-02 14:04                   ` David Laight
2022-03-02 14:04                   ` David Laight
2022-03-02 14:04                   ` [f2fs-dev] " David Laight
2022-03-03  2:27                   ` Xiaomeng Tong
2022-03-03  2:27                     ` [Intel-wired-lan] " Xiaomeng Tong
2022-03-03  2:27                     ` [Nouveau] " Xiaomeng Tong
2022-03-03  2:27                     ` [Intel-gfx] " Xiaomeng Tong
2022-03-03  2:27                     ` Xiaomeng Tong
2022-03-03  2:27                     ` Xiaomeng Tong
2022-03-03  2:27                     ` [f2fs-dev] " Xiaomeng Tong
2022-03-03  4:58                     ` David Laight
2022-03-03  4:58                       ` [Intel-wired-lan] " David Laight
2022-03-03  4:58                       ` [Nouveau] " David Laight
2022-03-03  4:58                       ` David Laight
2022-03-03  4:58                       ` [Intel-gfx] " David Laight
2022-03-03  4:58                       ` David Laight
2022-03-03  4:58                       ` [f2fs-dev] " David Laight
2022-03-03  7:26                       ` Xiaomeng Tong
2022-03-03  7:26                         ` [Intel-wired-lan] " Xiaomeng Tong
2022-03-03  7:26                         ` [Nouveau] " Xiaomeng Tong
2022-03-03  7:26                         ` [Intel-gfx] " Xiaomeng Tong
2022-03-03  7:26                         ` Xiaomeng Tong
2022-03-03  7:26                         ` Xiaomeng Tong
2022-03-03  7:26                         ` [f2fs-dev] " Xiaomeng Tong
2022-03-03  9:30                         ` David Laight
2022-03-03  9:30                           ` [Intel-wired-lan] " David Laight
2022-03-03  9:30                           ` [Nouveau] " David Laight
2022-03-03  9:30                           ` [Intel-gfx] " David Laight
2022-03-03  9:30                           ` David Laight
2022-03-03  9:30                           ` David Laight
2022-03-03  9:30                           ` [f2fs-dev] " David Laight
2022-03-03 12:37                           ` Xiaomeng Tong
2022-03-03 12:37                             ` [Intel-wired-lan] " Xiaomeng Tong
2022-03-03 12:37                             ` [Nouveau] " Xiaomeng Tong
2022-03-03 12:37                             ` [Intel-gfx] " Xiaomeng Tong
2022-03-03 12:37                             ` Xiaomeng Tong
2022-03-03 12:37                             ` Xiaomeng Tong
2022-03-03 12:37                             ` [f2fs-dev] " Xiaomeng Tong
2022-03-03 12:18                         ` [Kgdb-bugreport] " Daniel Thompson
2022-03-03 12:18                           ` [Intel-wired-lan] " Daniel Thompson
2022-03-03 12:18                           ` [Nouveau] " Daniel Thompson
2022-03-03 12:18                           ` [f2fs-dev] " Daniel Thompson
2022-03-03 12:18                           ` Daniel Thompson
2022-03-03 12:18                           ` [Intel-gfx] " Daniel Thompson
2022-03-03 12:18                           ` Daniel Thompson
2022-03-04  6:59                           ` Xiaomeng Tong
2022-03-04  6:59                             ` [Intel-wired-lan] " Xiaomeng Tong
2022-03-04  6:59                             ` [Nouveau] " Xiaomeng Tong
2022-03-04  6:59                             ` [Intel-gfx] " Xiaomeng Tong
2022-03-04  6:59                             ` Xiaomeng Tong
2022-03-04  6:59                             ` Xiaomeng Tong
2022-03-04  6:59                             ` [f2fs-dev] " Xiaomeng Tong
2022-03-03  7:32                       ` Jakob Koschel
2022-03-03  7:32                         ` [Intel-wired-lan] " Jakob Koschel
2022-03-03  7:32                         ` [Nouveau] " Jakob Koschel
2022-03-03  7:32                         ` [Intel-gfx] " Jakob Koschel
2022-03-03  7:32                         ` Jakob Koschel
2022-03-03  7:32                         ` Jakob Koschel
2022-03-03  7:32                         ` [f2fs-dev] " Jakob Koschel
2022-03-03  8:30                         ` Xiaomeng Tong
2022-03-03  8:30                           ` [Intel-wired-lan] " Xiaomeng Tong
2022-03-03  8:30                           ` [Nouveau] " Xiaomeng Tong
2022-03-03  8:30                           ` [Intel-gfx] " Xiaomeng Tong
2022-03-03  8:30                           ` Xiaomeng Tong
2022-03-03  8:30                           ` Xiaomeng Tong
2022-03-03  8:30                           ` [f2fs-dev] " Xiaomeng Tong
2022-03-03  8:38                           ` Xiaomeng Tong
2022-03-03  8:38                             ` [Intel-wired-lan] " Xiaomeng Tong
2022-03-03  8:38                             ` [Nouveau] " Xiaomeng Tong
2022-03-03  8:38                             ` [Intel-gfx] " Xiaomeng Tong
2022-03-03  8:38                             ` Xiaomeng Tong
2022-03-03  8:38                             ` Xiaomeng Tong
2022-03-03  8:38                             ` [f2fs-dev] " Xiaomeng Tong
2022-02-28 20:07       ` Christian König
2022-02-28 20:07         ` [Intel-wired-lan] " Christian =?unknown-8bit?q?K=C3=B6nig?=
2022-02-28 20:07         ` [Nouveau] " Christian König
2022-02-28 20:07         ` [f2fs-dev] " Christian König via Linux-f2fs-devel
2022-02-28 20:07         ` [Intel-gfx] " Christian König
2022-02-28 20:07         ` Christian König
2022-02-28 20:07         ` Christian König
2022-02-28 20:42         ` James Bottomley
2022-02-28 20:42           ` [Intel-wired-lan] " James Bottomley
2022-02-28 20:42           ` [Nouveau] " James Bottomley
2022-02-28 20:42           ` [f2fs-dev] " James Bottomley
2022-02-28 20:42           ` [Intel-gfx] " James Bottomley
2022-02-28 20:42           ` James Bottomley
2022-02-28 20:42           ` James Bottomley
2022-02-28 20:56           ` Christian König
2022-02-28 20:56             ` [Intel-wired-lan] " Christian =?unknown-8bit?q?K=C3=B6nig?=
2022-02-28 20:56             ` [Nouveau] " Christian König
2022-02-28 20:56             ` [f2fs-dev] " Christian König via Linux-f2fs-devel
2022-02-28 20:56             ` [Intel-gfx] " Christian König
2022-02-28 20:56             ` Christian König
2022-02-28 20:56             ` Christian König
2022-02-28 21:13             ` James Bottomley
2022-02-28 21:13               ` [Intel-wired-lan] " James Bottomley
2022-02-28 21:13               ` [Nouveau] " James Bottomley
2022-02-28 21:13               ` [Intel-gfx] " James Bottomley
2022-02-28 21:13               ` James Bottomley
2022-02-28 21:13               ` James Bottomley
2022-02-28 21:13               ` [f2fs-dev] " James Bottomley
2022-03-01  7:03               ` Christian König
2022-03-01  7:03                 ` [Intel-wired-lan] " Christian =?unknown-8bit?q?K=C3=B6nig?=
2022-03-01  7:03                 ` [Nouveau] " Christian König
2022-03-01  7:03                 ` [Intel-gfx] " Christian König
2022-03-01  7:03                 ` Christian König
2022-03-01  7:03                 ` Christian König
2022-03-01  7:03                 ` [f2fs-dev] " Christian König via Linux-f2fs-devel
2022-02-28 22:05             ` Jakob Koschel
2022-02-28 22:05               ` [Intel-wired-lan] " Jakob Koschel
2022-02-28 22:05               ` [Intel-gfx] " Jakob Koschel
2022-02-28 22:05               ` [Nouveau] " Jakob Koschel
2022-02-28 22:05               ` Jakob Koschel
2022-02-28 22:05               ` Jakob Koschel
2022-02-28 22:05               ` [f2fs-dev] " Jakob Koschel
2022-02-28 21:18           ` Jeffrey Walton
2022-02-28 21:18             ` [Intel-wired-lan] " Jeffrey Walton
2022-02-28 21:18             ` [Intel-gfx] " Jeffrey Walton
2022-02-28 21:18             ` [Nouveau] " Jeffrey Walton
2022-02-28 21:18             ` Jeffrey Walton
2022-02-28 21:18             ` Jeffrey Walton
2022-02-28 21:18             ` [f2fs-dev] " Jeffrey Walton
2022-02-28 21:59           ` Mike Rapoport
2022-02-28 21:59             ` [Intel-wired-lan] " Mike Rapoport
2022-02-28 21:59             ` [Intel-gfx] " Mike Rapoport
2022-02-28 21:59             ` [Nouveau] " Mike Rapoport
2022-02-28 21:59             ` Mike Rapoport
2022-02-28 21:59             ` Mike Rapoport
2022-02-28 21:59             ` [f2fs-dev] " Mike Rapoport
2022-02-28 22:28             ` James Bottomley
2022-02-28 22:28               ` [Intel-wired-lan] " James Bottomley
2022-02-28 22:28               ` [Nouveau] " James Bottomley
2022-02-28 22:28               ` [Intel-gfx] " James Bottomley
2022-02-28 22:28               ` James Bottomley
2022-02-28 22:28               ` James Bottomley
2022-02-28 22:28               ` [f2fs-dev] " James Bottomley
2022-02-28 22:50               ` Barnabás Pőcze
2022-02-28 22:50                 ` [Intel-wired-lan] " =?unknown-8bit?q?Barnab=C3=A1s_P=C5=91cze?=
2022-02-28 22:50                 ` [Intel-gfx] " Barnabás Pőcze
2022-02-28 22:50                 ` [Nouveau] " Barnabás Pőcze
2022-02-28 22:50                 ` Barnabás Pőcze
2022-02-28 22:50                 ` Barnabás Pőcze
2022-02-28 22:50                 ` [f2fs-dev] " Barnabás Pőcze via Linux-f2fs-devel
2022-03-01  0:30               ` Segher Boessenkool
2022-03-01  0:30                 ` [Intel-wired-lan] " Segher Boessenkool
2022-03-01  0:30                 ` [Intel-gfx] " Segher Boessenkool
2022-03-01  0:30                 ` [Nouveau] " Segher Boessenkool
2022-03-01  0:30                 ` [f2fs-dev] " Segher Boessenkool
2022-03-01  0:30                 ` Segher Boessenkool
2022-03-01  0:30                 ` Segher Boessenkool
2022-03-01  0:54                 ` Linus Torvalds
2022-03-01  0:54                   ` [Intel-wired-lan] " Linus Torvalds
2022-03-01  0:54                   ` [Nouveau] " Linus Torvalds
2022-03-01  0:54                   ` [f2fs-dev] " Linus Torvalds
2022-03-01  0:54                   ` Linus Torvalds
2022-03-01  0:54                   ` Linus Torvalds
2022-03-01  0:54                   ` [Intel-gfx] " Linus Torvalds
2022-03-01 19:06               ` Linus Torvalds
2022-03-01 19:06                 ` [Intel-wired-lan] " Linus Torvalds
2022-03-01 19:06                 ` [Nouveau] " Linus Torvalds
2022-03-01 19:06                 ` Linus Torvalds
2022-03-01 19:06                 ` Linus Torvalds
2022-03-01 19:06                 ` [f2fs-dev] " Linus Torvalds
2022-03-01 19:06                 ` [Intel-gfx] " Linus Torvalds
2022-03-01 19:42                 ` Linus Torvalds
2022-03-01 19:42                   ` [Intel-wired-lan] " Linus Torvalds
2022-03-01 19:42                   ` [Nouveau] " Linus Torvalds
2022-03-01 19:42                   ` [Intel-gfx] " Linus Torvalds
2022-03-01 19:42                   ` [f2fs-dev] " Linus Torvalds
2022-03-01 19:42                   ` Linus Torvalds
2022-03-01 19:42                   ` Linus Torvalds
2022-03-01 22:58                 ` David Laight
2022-03-01 22:58                   ` [Intel-wired-lan] " David Laight
2022-03-01 22:58                   ` [Nouveau] " David Laight
2022-03-01 22:58                   ` David Laight
2022-03-01 22:58                   ` [f2fs-dev] " David Laight
2022-03-01 22:58                   ` [Intel-gfx] " David Laight
2022-03-01 22:58                   ` David Laight
2022-03-01 23:03                   ` Linus Torvalds
2022-03-01 23:03                     ` [Intel-wired-lan] " Linus Torvalds
2022-03-01 23:03                     ` [Nouveau] " Linus Torvalds
2022-03-01 23:03                     ` Linus Torvalds
2022-03-01 23:03                     ` Linus Torvalds
2022-03-01 23:03                     ` [Intel-gfx] " Linus Torvalds
2022-03-01 23:03                     ` [f2fs-dev] " Linus Torvalds
2022-03-01 23:19                     ` David Laight
2022-03-01 23:19                       ` [Intel-wired-lan] " David Laight
2022-03-01 23:19                       ` [Nouveau] " David Laight
2022-03-01 23:19                       ` [f2fs-dev] " David Laight
2022-03-01 23:19                       ` [Intel-gfx] " David Laight
2022-03-01 23:19                       ` David Laight
2022-03-01 23:19                       ` David Laight
2022-03-01 23:55                       ` Linus Torvalds
2022-03-01 23:55                         ` [Intel-wired-lan] " Linus Torvalds
2022-03-01 23:55                         ` [Nouveau] " Linus Torvalds
2022-03-01 23:55                         ` Linus Torvalds
2022-03-01 23:55                         ` [f2fs-dev] " Linus Torvalds
2022-03-01 23:55                         ` [Intel-gfx] " Linus Torvalds
2022-03-01 23:55                         ` Linus Torvalds
2022-03-02  9:29                         ` Rasmus Villemoes
2022-03-02  9:29                           ` [Intel-wired-lan] " Rasmus Villemoes
2022-03-02  9:29                           ` [Nouveau] " Rasmus Villemoes
2022-03-02  9:29                           ` [f2fs-dev] " Rasmus Villemoes
2022-03-02  9:29                           ` [Intel-gfx] " Rasmus Villemoes
2022-03-02  9:29                           ` Rasmus Villemoes
2022-03-02  9:29                           ` Rasmus Villemoes
2022-03-02 20:07                           ` Kees Cook
2022-03-02 20:07                             ` [Intel-wired-lan] " Kees Cook
2022-03-02 20:07                             ` [Nouveau] " Kees Cook
2022-03-02 20:07                             ` [Intel-gfx] " Kees Cook
2022-03-02 20:07                             ` Kees Cook
2022-03-02 20:07                             ` Kees Cook
2022-03-02 20:07                             ` [f2fs-dev] " Kees Cook
2022-03-02 20:18                             ` Linus Torvalds
2022-03-02 20:18                               ` [Intel-wired-lan] " Linus Torvalds
2022-03-02 20:18                               ` [Nouveau] " Linus Torvalds
2022-03-02 20:18                               ` Linus Torvalds
2022-03-02 20:18                               ` [Intel-gfx] " Linus Torvalds
2022-03-02 20:18                               ` Linus Torvalds
2022-03-02 20:18                               ` [f2fs-dev] " Linus Torvalds
2022-03-02 20:59                               ` Kees Cook
2022-03-02 20:59                                 ` [Intel-wired-lan] " Kees Cook
2022-03-02 20:59                                 ` [Nouveau] " Kees Cook
2022-03-02 20:59                                 ` [Intel-gfx] " Kees Cook
2022-03-02 20:59                                 ` Kees Cook
2022-03-02 20:59                                 ` Kees Cook
2022-03-02 20:59                                 ` [f2fs-dev] " Kees Cook
2022-03-03  8:37                             ` Dan Carpenter
2022-03-03  8:37                               ` [Intel-wired-lan] " Dan Carpenter
2022-03-03  8:37                               ` [Nouveau] " Dan Carpenter
2022-03-03  8:37                               ` [f2fs-dev] " Dan Carpenter
2022-03-03  8:37                               ` Dan Carpenter
2022-03-03  8:37                               ` [Intel-gfx] " Dan Carpenter
2022-03-03  8:37                               ` Dan Carpenter
2022-03-03 10:56                           ` Dan Carpenter
2022-03-03 10:56                             ` [Intel-wired-lan] " Dan Carpenter
2022-03-03 10:56                             ` [Nouveau] " Dan Carpenter
2022-03-03 10:56                             ` Dan Carpenter
2022-03-03 10:56                             ` [f2fs-dev] " Dan Carpenter
2022-03-03 10:56                             ` [Intel-gfx] " Dan Carpenter
2022-03-03 10:56                             ` Dan Carpenter
2022-03-01  2:15       ` David Laight
2022-03-01  2:15         ` [Intel-wired-lan] " David Laight
2022-03-01  2:15         ` [Nouveau] " David Laight
2022-03-01  2:15         ` [f2fs-dev] " David Laight
2022-03-01  2:15         ` [Intel-gfx] " David Laight
2022-03-01  2:15         ` David Laight
2022-03-01  2:15         ` David Laight
2022-02-28 13:13   ` Dan Carpenter
2022-02-28 13:13     ` [Nouveau] " Dan Carpenter
2022-02-28 13:13     ` Dan Carpenter
2022-02-28 13:13     ` [Intel-gfx] " Dan Carpenter
2022-02-28 13:13     ` Dan Carpenter
2022-02-28 13:13     ` [f2fs-dev] " Dan Carpenter
2022-02-28 11:08 ` [PATCH 3/6] treewide: fix incorrect use to determine if list is empty Jakob Koschel
2022-02-28 11:08   ` [Intel-wired-lan] " Jakob Koschel
2022-02-28 11:08   ` [Nouveau] " Jakob Koschel
2022-02-28 11:08   ` [Intel-gfx] " Jakob Koschel
2022-02-28 11:08   ` Jakob Koschel
2022-02-28 11:08   ` Jakob Koschel
2022-02-28 11:08   ` [f2fs-dev] " Jakob Koschel
2022-02-28 11:38   ` Dan Carpenter
2022-02-28 11:38     ` [Intel-wired-lan] " Dan Carpenter
2022-02-28 11:38     ` [Nouveau] " Dan Carpenter
2022-02-28 11:38     ` Dan Carpenter
2022-02-28 11:38     ` [f2fs-dev] " Dan Carpenter
2022-02-28 11:38     ` [Intel-gfx] " Dan Carpenter
2022-02-28 11:38     ` Dan Carpenter
2022-02-28 11:08 ` [PATCH 4/6] drivers: remove unnecessary use of list iterator variable Jakob Koschel
2022-02-28 11:08   ` [Intel-wired-lan] " Jakob Koschel
2022-02-28 11:08   ` [Nouveau] " Jakob Koschel
2022-02-28 11:08   ` [Intel-gfx] " Jakob Koschel
2022-02-28 11:08   ` Jakob Koschel
2022-02-28 11:08   ` Jakob Koschel
2022-02-28 11:08   ` [f2fs-dev] " Jakob Koschel
2022-02-28 11:08 ` [PATCH 5/6] treewide: remove dereference of list iterator after loop body Jakob Koschel
2022-02-28 11:08   ` [Intel-wired-lan] " Jakob Koschel
2022-02-28 11:08   ` [Nouveau] " Jakob Koschel
2022-02-28 11:08   ` [Intel-gfx] " Jakob Koschel
2022-02-28 11:08   ` Jakob Koschel
2022-02-28 11:08   ` Jakob Koschel
2022-02-28 11:08   ` [f2fs-dev] " Jakob Koschel
2022-02-28 11:08 ` [PATCH 6/6] treewide: remove check of list iterator against head past the " Jakob Koschel
2022-02-28 11:08   ` [Intel-wired-lan] " Jakob Koschel
2022-02-28 11:08   ` [Nouveau] " Jakob Koschel
2022-02-28 11:08   ` [Intel-gfx] " Jakob Koschel
2022-02-28 11:08   ` Jakob Koschel
2022-02-28 11:08   ` Jakob Koschel
2022-02-28 11:08   ` [f2fs-dev] " Jakob Koschel
2022-02-28 11:22   ` Dominique Martinet
2022-02-28 11:22     ` [Intel-wired-lan] " Dominique Martinet
2022-02-28 11:22     ` [Nouveau] " Dominique Martinet
2022-02-28 11:22     ` [Intel-gfx] " Dominique Martinet
2022-02-28 11:22     ` Dominique Martinet
2022-02-28 11:22     ` Dominique Martinet
2022-02-28 11:22     ` Dominique Martinet
2022-02-28 13:12   ` Dan Carpenter
2022-02-28 13:12     ` [Nouveau] " Dan Carpenter
2022-02-28 13:12     ` Dan Carpenter
2022-02-28 13:12     ` [f2fs-dev] " Dan Carpenter
2022-02-28 13:12     ` [Intel-gfx] " Dan Carpenter
2022-02-28 13:12     ` Dan Carpenter
2022-03-01 20:36   ` Linus Torvalds
2022-03-01 20:36     ` [Intel-wired-lan] " Linus Torvalds
2022-03-01 20:36     ` [Nouveau] " Linus Torvalds
2022-03-01 20:36     ` [f2fs-dev] " Linus Torvalds
2022-03-01 20:36     ` Linus Torvalds
2022-03-01 20:36     ` Linus Torvalds
2022-03-01 20:36     ` [Intel-gfx] " Linus Torvalds
2022-03-02 17:14   ` Tvrtko Ursulin [this message]
2022-03-02 17:14     ` [Intel-wired-lan] " Tvrtko Ursulin
2022-03-02 17:14     ` [Nouveau] " Tvrtko Ursulin
2022-03-02 17:14     ` [f2fs-dev] " Tvrtko Ursulin
2022-03-02 17:14     ` Tvrtko Ursulin
2022-03-02 17:14     ` Tvrtko Ursulin
2022-03-01  0:27 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for Remove usage of list iterator past the loop body (rev2) Patchwork
2022-03-01  2:38 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for Remove usage of list iterator past the loop body (rev3) Patchwork
2022-03-01 22:57 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for Remove usage of list iterator past the loop body (rev4) Patchwork
2022-03-03 11:27 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Remove usage of list iterator past the loop body (rev5) Patchwork
2022-03-03 11:59 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2022-03-03 16:59 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2022-03-07 15:00 ` [PATCH 0/6] Remove usage of list iterator past the loop body Dan Carpenter
2022-03-07 15:00   ` [Intel-wired-lan] " Dan Carpenter
2022-03-07 15:00   ` [Nouveau] " Dan Carpenter
2022-03-07 15:00   ` Dan Carpenter
2022-03-07 15:00   ` [f2fs-dev] " Dan Carpenter
2022-03-07 15:00   ` [Intel-gfx] " Dan Carpenter
2022-03-07 15:00   ` Dan Carpenter
2022-03-07 15:26   ` David Laight
2022-03-07 15:26     ` [Intel-wired-lan] " David Laight
2022-03-07 15:26     ` [Nouveau] " David Laight
2022-03-07 15:26     ` [Intel-gfx] " David Laight
2022-03-07 15:26     ` David Laight
2022-03-07 15:26     ` David Laight
2022-03-07 15:26     ` [f2fs-dev] " David Laight
2022-03-07 19:15     ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ed52ce3c-0f4a-a1e8-4176-543657d6228d@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=arnd@arndb.de \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=bjohannesmeyer@gmail.com \
    --cc=c.giuffrida@vu.nl \
    --cc=christophe.jaillet@wanadoo.fr \
    --cc=dan.carpenter@oracle.com \
    --cc=dmaengine@vger.kernel.org \
    --cc=drbd-dev@lists.linbit.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gustavo@embeddedor.com \
    --cc=h.j.bos@vu.nl \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=jakobkoschel@gmail.com \
    --cc=jgg@ziepe.ca \
    --cc=keescook@chromium.org \
    --cc=kgdb-bugreport@lists.sourceforge.net \
    --cc=kvm@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-aspeed@lists.ozlabs.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-cifs@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linux-sgx@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=linux-tegra@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linux1394-devel@lists.sourceforge.net \
    --cc=linux@rasmusvillemoes.dk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=nathan@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=rppt@kernel.org \
    --cc=samba-technical@lists.samba.org \
    --cc=tglx@linutronix.de \
    --cc=tipc-discussion@lists.sourceforge.net \
    --cc=torvalds@linux-foundation.org \
    --cc=v9fs-developer@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.