diff mbox

arch/sparc: additional len check in loop for prom_getbootargs

Message ID 509B29F3.2040006@asianux.com
State Changes Requested
Delegated to: David Miller
Headers show

Commit Message

Chen Gang Nov. 8, 2012, 3:41 a.m. UTC
when cp >= barg_buf + BARG_LEN-2, it only break internel loop (while)
  but outside loop (for) still has effect, and "*cp++ = ' '" repeating
  so need additional checking for it.


Signed-off-by: Chen Gang <gang.chen@asianux.com>
---
 arch/sparc/prom/bootstr_32.c |    4 ++++
 1 file changed, 4 insertions(+)

Comments

Chen Gang Nov. 9, 2012, 3:15 a.m. UTC | #1
Hell David Miller:

1) Is this patch applied ?  or need some discussion ?  or suspended ?

2) If possible: 
   A) can you tell me about our patch processing work flow "
   B) or some reference links (or document location) ?

thanks.


于 2012年11月08日 11:41, Chen Gang 写道:
> 
>   when cp >= barg_buf + BARG_LEN-2, it only break internel loop (while)
>   but outside loop (for) still has effect, and "*cp++ = ' '" repeating
>   so need additional checking for it.
> 
> 
> Signed-off-by: Chen Gang <gang.chen@asianux.com>
> ---
>  arch/sparc/prom/bootstr_32.c |    4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/sparc/prom/bootstr_32.c b/arch/sparc/prom/bootstr_32.c
> index f5ec32e..25cda1c 100644
> --- a/arch/sparc/prom/bootstr_32.c
> +++ b/arch/sparc/prom/bootstr_32.c
> @@ -40,6 +40,10 @@ prom_getbootargs(void)
>  				*cp++ = *arg++;
>  			}
>  			*cp++ = ' ';
> +			if(cp >= barg_buf + BARG_LEN-1){
> +				/* We might issue a warning here. */
> +				break;
> +			}
>  		}
>  		*cp = 0;
>  		break;
>
David Miller Nov. 9, 2012, 3:16 a.m. UTC | #2
I'm backlogged and often without internet access, and therefore
concentrating my limited time on kernel networking and much more
important sparc changes such as bug fixes for problems people will
actually hit.

So you'll just need to be very patient.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Chen Gang Nov. 9, 2012, 3:25 a.m. UTC | #3
于 2012年11月09日 11:16, David Miller 写道:
> 
> I'm backlogged and often without internet access, and therefore
> concentrating my limited time on kernel networking and much more
> important sparc changes such as bug fixes for problems people will
> actually hit.
> 
> So you'll just need to be very patient.
> 
> 

ok, thanks, that is truly what I shall be.

and I suggest:

1) can write a document for patch work flow and time waiting document

2) put it in a suitable location (can be easily found by new members).

3) I think this document is useful for the new members.


thanks
Julian Calaby Nov. 9, 2012, 5:06 a.m. UTC | #4
Hi Chen,

On Fri, Nov 9, 2012 at 2:15 PM, Chen Gang <gang.chen@asianux.com> wrote:
> Hell David Miller:
>
> 1) Is this patch applied ?  or need some discussion ?  or suspended ?
>
> 2) If possible:
>    A) can you tell me about our patch processing work flow "
>    B) or some reference links (or document location) ?

In regards to patches, you should assume that maintainers are:
1. grumpy
2. overworked
3. looking at your patch as you email them about it.

(Note that only #2 is true, but it saves everyone time and aggravation
if you assume the rest)

11 hours is not long enough for David to get to your patch, review it
and apply it. I don't believe that there are any maintainers which
would get to a patch that quickly.

If David hadn't applied the patch within a few days of it being
posted, then you might want to gently ask what's up. However, as Sam
reviewed the patch and had some comments about it, it's unlikely that
David will even look at it until you've addressed Sam's feedback.

The best way to get a patch into the kernel is to follow the rules in
Documentation/SubmittingPatches which you have, respond quickly to any
feedback, be patient, be prepared to explain why you're doing what
you're doing, and be prepared to change and resubmit your patch many
times until everyone is happy with it.

I'm sure that this is all written down in a document somewhere, but I
can't recall what or where it is.

Thanks,
Chen Gang Nov. 9, 2012, 5:29 a.m. UTC | #5
Hi Julian Calaby:


thank you for your reply, firstly.

1) I think what you reply are valuable (at least, for me, it is true).

2) I have read Documents/SubmittingPatches (which Eric Dumazet suggested)

3) I also think, it will be better, if put part contents of your reply into Documents/SubmittingPatches as completion. 

thanks.

gchen.


于 2012年11月09日 13:06, Julian Calaby 写道:
> Hi Chen,
> 
> On Fri, Nov 9, 2012 at 2:15 PM, Chen Gang <gang.chen@asianux.com> wrote:
>> Hell David Miller:
>>
>> 1) Is this patch applied ?  or need some discussion ?  or suspended ?
>>
>> 2) If possible:
>>    A) can you tell me about our patch processing work flow "
>>    B) or some reference links (or document location) ?
> 
> In regards to patches, you should assume that maintainers are:
> 1. grumpy
> 2. overworked
> 3. looking at your patch as you email them about it.
> 
> (Note that only #2 is true, but it saves everyone time and aggravation
> if you assume the rest)
> 
> 11 hours is not long enough for David to get to your patch, review it
> and apply it. I don't believe that there are any maintainers which
> would get to a patch that quickly.
> 
> If David hadn't applied the patch within a few days of it being
> posted, then you might want to gently ask what's up. However, as Sam
> reviewed the patch and had some comments about it, it's unlikely that
> David will even look at it until you've addressed Sam's feedback.
> 
> The best way to get a patch into the kernel is to follow the rules in
> Documentation/SubmittingPatches which you have, respond quickly to any
> feedback, be patient, be prepared to explain why you're doing what
> you're doing, and be prepared to change and resubmit your patch many
> times until everyone is happy with it.
> 
> I'm sure that this is all written down in a document somewhere, but I
> can't recall what or where it is.
> 
> Thanks,
>
Chen Gang Nov. 13, 2012, 3:06 a.m. UTC | #6
Hello David Miller, Julian Calaby:


1) I am sorry for original mails to you:

   A) at 2012-11-09 00:33 Sam Ravnborg has already replied to me (need
additional discussion)
   B) but I did not see it, it is my fault.
   C) at 2012-11-09 11:15 I sent mail to want to get reply, and you
replied immediately.

   (the Time Location is at Beijing China)


2) sorry again, for bothering you,  and also thank Sam Ravnborg's reply.


3) next time, I shall notice, and check my own mail carefully.



Chen Gang


--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/arch/sparc/prom/bootstr_32.c b/arch/sparc/prom/bootstr_32.c
index f5ec32e..25cda1c 100644
--- a/arch/sparc/prom/bootstr_32.c
+++ b/arch/sparc/prom/bootstr_32.c
@@ -40,6 +40,10 @@  prom_getbootargs(void)
 				*cp++ = *arg++;
 			}
 			*cp++ = ' ';
+			if(cp >= barg_buf + BARG_LEN-1){
+				/* We might issue a warning here. */
+				break;
+			}
 		}
 		*cp = 0;
 		break;