All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Carlos R. Mafra" <crmafra@gmail.com>
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Hauke Mehrtens <hauke@hauke-m.de>,
	"John W. Linville" <linville@tuxdriver.com>,
	netdev@vger.kernel.org
Subject: Re: /proc/net/dev regression
Date: Sun, 11 Jan 2015 13:40:12 +0000	[thread overview]
Message-ID: <20150111134012.GA2079@linux-g29b.site> (raw)
In-Reply-To: <20150111013913.GE22149@ZenIV.linux.org.uk>

On Sun, 11 Jan 2015 at  1:39:13 +0000, Al Viro wrote:
> On Sun, Jan 11, 2015 at 01:33:35AM +0000, Carlos R. Mafra wrote:
> 
> > I think the problem with wmnet is not that it was expecting the fields
> > to be aligned because it never had problems before (when definitely more
> > than 10 megabytes were received, wmnet is crappy but not _that_ crappy).
> > 
> > I think the problem really was here,
> > 
> > 	totalbytes_in = strtoul(&buffer[7], NULL, 10);
> > 
> > After the patch the device name is 8 characters long and &buffer[7]
> > overlaps with the name instead of reading the bytes. Before the
> > patch is was fine because the call to strtoul() seems correct in the
> > sense that it would read everything until the NULL. So more than 10
> > megabytes was still ok.
> > 
> > So I guess I was wrong when suggesting that the problem was the
> > alignment.
> 
> Several lines below there's this:
>                         totalpackets_out = strtoul(&buffer[74], NULL, 10);
>                         if (totalpackets_out != lastpackets_out) {
>                                 totalbytes_out = strtoul(&buffer[66], NULL, 10);
>                                 diffpackets_out += totalpackets_out - lastpackets_out;
>                                 diffbytes_out += totalbytes_out - lastbytes_out;
>                                 lastpackets_out = totalpackets_out;
>                                 lastbytes_out = totalbytes_out;
>                                 tx = True;
>                         }
> 
> So I'm afraid it *is* that crappy.  This function really should use scanf();
> note that updateStats_ipchains() in the same file does just that (well,
> fgets()+sscanf() for fsck knows what reason).  And I'd be careful with all
> those %d, actually - it's not _that_ hard to get more than 4Gb sent.
> scanf formats really ought to match the kernel-side (seq_)printf one...

Ok, I fixed wmnet using Al's suggestion.

As far as I'm concerned, my regression complaint can be dismissed. It's
all working fine again.

Thanks!

  reply	other threads:[~2015-01-11 13:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-10 23:25 /proc/net/dev regression Carlos R. Mafra
2015-01-11  0:27 ` Al Viro
2015-01-11  0:58   ` Carlos R. Mafra
2015-01-11  1:00   ` Al Viro
2015-01-11  1:33     ` Carlos R. Mafra
2015-01-11  1:39       ` Al Viro
2015-01-11 13:40         ` Carlos R. Mafra [this message]
2015-01-12 11:47         ` David Laight

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=20150111134012.GA2079@linux-g29b.site \
    --to=crmafra@gmail.com \
    --cc=hauke@hauke-m.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=netdev@vger.kernel.org \
    --cc=viro@ZenIV.linux.org.uk \
    /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.