[PATCH] mac80211: refactor skb copy to failq in mesh_path_move_to_queue

[PATCH] mac80211: refactor skb copy to failq in mesh_path_move_to_queue

[John W. Linville]

This seems a bit less awkward, and avoids the following warning:

  CC [M]  net/mac80211/mesh_pathtbl.o
net/mac80211/mesh_pathtbl.c: In function ‘mesh_path_move_to_queue’:
net/mac80211/mesh_pathtbl.c:291:24: warning: ‘cp_skb’ may be used uninitialized in this function

Signed-off-by: John W. Linville <linville@tuxdriver.com>
---
Does it matter if the copy ends-up on the failq before the original goes
to the gateq?

 net/mac80211/mesh_pathtbl.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/mac80211/mesh_pathtbl.c b/net/mac80211/mesh_pathtbl.c
index 75e4b60..b5caf5b 100644
--- a/net/mac80211/mesh_pathtbl.c
+++ b/net/mac80211/mesh_pathtbl.c
@@ -307,14 +307,14 @@ static void mesh_path_move_to_queue(struct mesh_path *gate_mpath,
 
 	while (num_skbs--) {
 		skb = __skb_dequeue(&failq);
-		if (copy)
+		if (copy) {
 			cp_skb = skb_copy(skb, GFP_ATOMIC);
+			if (cp_skb)
+				__skb_queue_tail(&failq, cp_skb);
+		}
 
 		prepare_for_gate(skb, gate_mpath->dst, gate_mpath);
 		__skb_queue_tail(&gateq, skb);
-
-		if (copy && cp_skb)
-			__skb_queue_tail(&failq, cp_skb);
 	}
 
 	spin_lock_irqsave(&gate_mpath->frame_queue.lock, flags);
-- 
1.7.4.4

Re: [PATCH] mac80211: refactor skb copy to failq in mesh_path_move_to_queue

[Thomas Pedersen]

On Wed, Aug 24, 2011 at 12:12 PM, John W. Linville
<linville@tuxdriver.com> wrote:
> This seems a bit less awkward, and avoids the following warning:
>
>  CC [M]  net/mac80211/mesh_pathtbl.o
> net/mac80211/mesh_pathtbl.c: In function ‘mesh_path_move_to_queue’:
> net/mac80211/mesh_pathtbl.c:291:24: warning: ‘cp_skb’ may be used uninitialized in this function

cp_skb was initialized to NULL in v2 of "mac80211:  mesh gate implementation'

>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
> Does it matter if the copy ends-up on the failq before the original goes
> to the gateq?
>
>  net/mac80211/mesh_pathtbl.c |    8 ++++----
>  1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/net/mac80211/mesh_pathtbl.c b/net/mac80211/mesh_pathtbl.c
> index 75e4b60..b5caf5b 100644
> --- a/net/mac80211/mesh_pathtbl.c
> +++ b/net/mac80211/mesh_pathtbl.c
> @@ -307,14 +307,14 @@ static void mesh_path_move_to_queue(struct mesh_path *gate_mpath,
>
>        while (num_skbs--) {
>                skb = __skb_dequeue(&failq);
> -               if (copy)
> +               if (copy) {
>                        cp_skb = skb_copy(skb, GFP_ATOMIC);
> +                       if (cp_skb)
> +                               __skb_queue_tail(&failq, cp_skb);
> +               }
>
>                prepare_for_gate(skb, gate_mpath->dst, gate_mpath);
>                __skb_queue_tail(&gateq, skb);
> -
> -               if (copy && cp_skb)
> -                       __skb_queue_tail(&failq, cp_skb);
>        }

However, this does look nicer. Please be sure to apply the version
submitted on 11 August.

Thomas

Re: [PATCH] mac80211: refactor skb copy to failq in mesh_path_move_to_queue

[John W. Linville]

On Wed, Aug 24, 2011 at 12:27:29PM -0700, Thomas Pedersen wrote:
> On Wed, Aug 24, 2011 at 12:12 PM, John W. Linville
> <linville@tuxdriver.com> wrote:
> > This seems a bit less awkward, and avoids the following warning:
> >
> >  CC [M]  net/mac80211/mesh_pathtbl.o
> > net/mac80211/mesh_pathtbl.c: In function ‘mesh_path_move_to_queue’:
> > net/mac80211/mesh_pathtbl.c:291:24: warning: ‘cp_skb’ may be used uninitialized in this function
> 
> cp_skb was initialized to NULL in v2 of "mac80211:  mesh gate implementation'
> 
> >
> > Signed-off-by: John W. Linville <linville@tuxdriver.com>
> > ---
> > Does it matter if the copy ends-up on the failq before the original goes
> > to the gateq?
> >
> >  net/mac80211/mesh_pathtbl.c |    8 ++++----
> >  1 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/net/mac80211/mesh_pathtbl.c b/net/mac80211/mesh_pathtbl.c
> > index 75e4b60..b5caf5b 100644
> > --- a/net/mac80211/mesh_pathtbl.c
> > +++ b/net/mac80211/mesh_pathtbl.c
> > @@ -307,14 +307,14 @@ static void mesh_path_move_to_queue(struct mesh_path *gate_mpath,
> >
> >        while (num_skbs--) {
> >                skb = __skb_dequeue(&failq);
> > -               if (copy)
> > +               if (copy) {
> >                        cp_skb = skb_copy(skb, GFP_ATOMIC);
> > +                       if (cp_skb)
> > +                               __skb_queue_tail(&failq, cp_skb);
> > +               }
> >
> >                prepare_for_gate(skb, gate_mpath->dst, gate_mpath);
> >                __skb_queue_tail(&gateq, skb);
> > -
> > -               if (copy && cp_skb)
> > -                       __skb_queue_tail(&failq, cp_skb);
> >        }
> 
> However, this does look nicer. Please be sure to apply the version
> submitted on 11 August.

You just told me yesterday to apply the 9 August version???

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: [PATCH] mac80211: refactor skb copy to failq in mesh_path_move_to_queue

[Thomas Pedersen]

On Wed, Aug 24, 2011 at 12:32 PM, John W. Linville
<linville@tuxdriver.com> wrote:
> On Wed, Aug 24, 2011 at 12:27:29PM -0700, Thomas Pedersen wrote:
>> On Wed, Aug 24, 2011 at 12:12 PM, John W. Linville
>> <linville@tuxdriver.com> wrote:
>> > This seems a bit less awkward, and avoids the following warning:
>> >
>> >  CC [M]  net/mac80211/mesh_pathtbl.o
>> > net/mac80211/mesh_pathtbl.c: In function ‘mesh_path_move_to_queue’:
>> > net/mac80211/mesh_pathtbl.c:291:24: warning: ‘cp_skb’ may be used uninitialized in this function
>>
>> cp_skb was initialized to NULL in v2 of "mac80211:  mesh gate implementation'
>>
>> >
>> > Signed-off-by: John W. Linville <linville@tuxdriver.com>
>> > ---
>> > Does it matter if the copy ends-up on the failq before the original goes
>> > to the gateq?
>> >
>> >  net/mac80211/mesh_pathtbl.c |    8 ++++----
>> >  1 files changed, 4 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/net/mac80211/mesh_pathtbl.c b/net/mac80211/mesh_pathtbl.c
>> > index 75e4b60..b5caf5b 100644
>> > --- a/net/mac80211/mesh_pathtbl.c
>> > +++ b/net/mac80211/mesh_pathtbl.c
>> > @@ -307,14 +307,14 @@ static void mesh_path_move_to_queue(struct mesh_path *gate_mpath,
>> >
>> >        while (num_skbs--) {
>> >                skb = __skb_dequeue(&failq);
>> > -               if (copy)
>> > +               if (copy) {
>> >                        cp_skb = skb_copy(skb, GFP_ATOMIC);
>> > +                       if (cp_skb)
>> > +                               __skb_queue_tail(&failq, cp_skb);
>> > +               }
>> >
>> >                prepare_for_gate(skb, gate_mpath->dst, gate_mpath);
>> >                __skb_queue_tail(&gateq, skb);
>> > -
>> > -               if (copy && cp_skb)
>> > -                       __skb_queue_tail(&failq, cp_skb);
>> >        }
>>
>> However, this does look nicer. Please be sure to apply the version
>> submitted on 11 August.
>
> You just told me yesterday to apply the 9 August version???
>

OK that is confusing. I meant 9 August version of patch 1/8 only, the
rest should be 11 August.

> John
> --
> John W. Linville                Someday the world will need a hero, and you
> linville@tuxdriver.com                  might be all we have.  Be ready.
>

Re: [PATCH] mac80211: refactor skb copy to failq in mesh_path_move_to_queue

[Kalle Valo]

Thomas Pedersen <thomas@cozybit.com> writes:

>>> However, this does look nicer. Please be sure to apply the version
>>> submitted on 11 August.
>>
>> You just told me yesterday to apply the 9 August version???
>>
>
> OK that is confusing. I meant 9 August version of patch 1/8 only, the
> rest should be 11 August.

WTF, this is the second time I'm reading something like this in 24 hours?

John has loads of things to do already. If something changes in the
series series, ask John to drop that version and RESUBMIT IT! Don't
force John to waste time by trying to find the correct versions of
your patch from the past.

I want to John to focus on more important things than doing the work
of the people who don't bother to resubmit their patches. Resubmitting
a patch series takes maximum of 10 minutes, even when being extra
careful.

-- 
Kalle Valo

Re: [PATCH] mac80211: refactor skb copy to failq in mesh_path_move_to_queue

[Thomas Pedersen]

On Thu, Aug 25, 2011 at 2:11 AM, Kalle Valo <kvalo@adurom.com> wrote:
> Thomas Pedersen <thomas@cozybit.com> writes:
>
>>>> However, this does look nicer. Please be sure to apply the version
>>>> submitted on 11 August.
>>>
>>> You just told me yesterday to apply the 9 August version???
>>>
>>
>> OK that is confusing. I meant 9 August version of patch 1/8 only, the
>> rest should be 11 August.
>
> WTF, this is the second time I'm reading something like this in 24 hours?
>
> John has loads of things to do already. If something changes in the
> series series, ask John to drop that version and RESUBMIT IT! Don't
> force John to waste time by trying to find the correct versions of
> your patch from the past.
>
> I want to John to focus on more important things than doing the work
> of the people who don't bother to resubmit their patches. Resubmitting
> a patch series takes maximum of 10 minutes, even when being extra
> careful.
>

Sorry. In the future I'll make sure John doesn't have to pull from two
different versions of the same patchset.

> --
> Kalle Valo
>

Re: [PATCH] mac80211: refactor skb copy to failq in mesh_path_move_to_queue

[John W. Linville]

On Wed, Aug 24, 2011 at 03:32:24PM -0400, John W. Linville wrote:
> On Wed, Aug 24, 2011 at 12:27:29PM -0700, Thomas Pedersen wrote:

> > However, this does look nicer. Please be sure to apply the version
> > submitted on 11 August.
> 
> You just told me yesterday to apply the 9 August version???

In any case, that is what I applied.  Please review it and submit
fixup patches for anything that needs to be different.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.