Re: [Suggestion] drivers/tty: drivers/char/: for MAX_ASYNC_BUFFER_SIZE

[Chen Gang]

ä 2012å11æ30æ 10:27, Chen Gang åé:
> ä 2012å11æ29æ 21:41, Alan Cox åé:
>> On Thu, 29 Nov 2012 13:07:28 +0800
>> Chen Gang <gang.chen@xxxxxxxxxxx> wrote:
>>
>>> Hello Greg Kroah-Hartman:
>>>
>>> for MAX_ASYNC_BUFFER_SIZE:
>>>   it is defined as 4096;
>>>   but for the max buffer size which it processes, is 65535.
>>>   so suggest to #define MAX_ASYNC_BUFFER_SIZE 0x10000  (better than 0xffff)
>>
>> I don't see the need to change this. Possibly some of the old synclink
>> drivers need to check more carefully for overflows if configured for very
>> large frame sizes ?
>>
> 

  sorry forget to reply "I don't see the need to change this"

  I think what Alan Cox said is:
    if it was necessary (surely overflows by testing):
      not touch MAX_ASYNC_BUFFER_SIZE,
      can judge the buffer whether larger than MAX_ASYNC_BUFFER_SIZE.
        if larger, we can skip it.

  I think we also have another 4 ways: (if surely overflows by testing)
    I prefer:
      use flag_buf[HDLC_MAX_FRAME_SIZE] instead of flag_buf[MAX_ASYNC_BUFFER_SIZE]
      it is the simplest and clearest way.
      it will consume a little more memory, but it seems minor negative effect with global.
    2nd way:
      dynamically allocate relative buffer to fit the current max frame size (4096..65535).
      it is not complex, but can save a little memory
    3rd way:
      we have to make a loop to receive one frame.
      it will be complex, need reconstruction current source code (and more testing).
    4th way:
      #define MAX_ASYNC_BUFFER_SIZE  0x10000
      it is my original suggestion, but it seems not quite suitable.


  welcome to giving your choice (or provide your new choice), thanks.

  thanks.

gchen.
> I am just through code review (so it is only a suggestion), I will try to perform test.
> also welcome another members to help testing.
> 
> this issue has effect with 4 synclink drivers (most of source code are the same).
>   drivers/char/pcmcia/synclink_cs.c:213:	char flag_buf[MAX_ASYNC_BUFFER_SIZE];
>   drivers/tty/synclink_gt.c:320:	char flag_buf[MAX_ASYNC_BUFFER_SIZE];
>   drivers/tty/synclink.c:294:	char flag_buf[MAX_ASYNC_BUFFER_SIZE];
>   drivers/tty/synclinkmp.c:265:	char flag_buf[MAX_ASYNC_BUFFER_SIZE];
> 
> for the char_buf, has already useless (can be removed)
>   drivers/tty/synclink_gt.c:321:	char char_buf[MAX_ASYNC_BUFFER_SIZE];
>   drivers/tty/synclink.c:295:	char char_buf[MAX_ASYNC_BUFFER_SIZE];	
>   drivers/tty/synclinkmp.c:266:	char char_buf[MAX_ASYNC_BUFFER_SIZE];
> 
> 
>>>
>>> ---------------------------------------------------------------------------------
>>> Step 3:
>>>
>>> one sample in drivers/tty/n_gsm.c  (same for another implementation)
>>>
>>>   receive_buf is a function ptr which may be gsmld_receive_buf at line 2819. 
>>>   it does not check the length of count whether larger than MAX_ASYNC_BUFFER_SIZE.
>>>   if count is larger than MAX_ASYNC_BUFFER_SIZE, will cause issue.
>>
>> Why should it - MAX_ASYNC_BUFFER_SIZE is an internal detail of the
>> synclink drivers. 
>>
>> Alan
>>
>>
> 
>   no, not need.  (excuse me, my English is not quite well, maybe you misunderstand what I said)
> 
>   at least, currently:
>     the caller should be sure that the buffer length is enough (it seems not, I need test it).
>     the internal has no duty to check it.
> 
> 


-- 
Chen Gang

Asianux Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/