Re: [PATCH 5/6] Extend buf size to avoid format truncation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 25, 2018 at 08:18:41AM -0400, Hal Rosenstock wrote:
> On 7/19/2018 10:50 PM, Honggang LI wrote:
> > From: Honggang Li <honli@xxxxxxxxxx>
> > 
> > make[2]: Entering directory '/home/honli/upstream-repos/opensm/opensm'
> > depbase=`echo osm_sm_mad_ctrl.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
> > gcc -DHAVE_CONFIG_H -I. -I../include -I../include/opensm  -I./../include -I./../../libibumad/include -I/usr/local/include   -Werror -Wall -Wwrite-strings -g -D_XOPEN_SOURCE=600 -D_DEFAULT_SOURCE=1 -g -O2 -MT osm_sm_mad_ctrl.o -MD -MP -MF $depbase.Tpo -c -o osm_sm_mad_ctrl.o osm_sm_mad_ctrl.c &&\
> > mv -f $depbase.Tpo $depbase.Po
> > osm_sm_mad_ctrl.c: In function ‘log_rcv_cb_error’:
> > osm_sm_mad_ctrl.c:571:28: error: ‘%s’ directive output may be truncated writing up to 4095 bytes into a region of size 4078 [-Werror=format-truncation=]
> >      "\n\t\t\tInitial path: %s Return path: %s",
> >                             ^~
> >      ipath, rpath);
> >      ~~~~~
> > osm_sm_mad_ctrl.c:570:3: note: ‘snprintf’ output between 33 and 8223 bytes into a destination of size 4096
> >    snprintf(buf, sizeof(buf),
> >    ^~~~~~~~~~~~~~~~~~~~~~~~~~
> >      "\n\t\t\tInitial path: %s Return path: %s",
> >      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >      ipath, rpath);
> >      ~~~~~~~~~~~~~
> > cc1: all warnings being treated as errors
> > 
> > Signed-off-by: Honggang Li <honli@xxxxxxxxxx>
> > ---
> >  opensm/osm_sm_mad_ctrl.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/opensm/osm_sm_mad_ctrl.c b/opensm/osm_sm_mad_ctrl.c
> > index ebac55877f76..1f548a9faa77 100644
> > --- a/opensm/osm_sm_mad_ctrl.c
> > +++ b/opensm/osm_sm_mad_ctrl.c
> > @@ -556,7 +556,7 @@ static void sm_mad_ctrl_process_trap_repress(IN osm_sm_mad_ctrl_t * p_ctrl,
> >  
> >  static void log_rcv_cb_error(osm_log_t *p_log, ib_smp_t *p_smp, ib_net16_t status)
> >  {
> > -	char buf[BUF_SIZE];
> > +	char buf[BUF_SIZE*3];
> 
> This is purely theoretical problem but rather than tripling the buffer
> size, a better solution is to reduce ipath and rpath to what's really
> needed. Do you want to take a crack at this approach or should I do this ?

Please send your patch for review.

> 
> -- Hal
> 
> >  	uint32_t i;
> >  
> >  	if (p_smp->mgmt_class == IB_MCLASS_SUBN_DIR) {
> > 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux