[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1479221415.3426.3.camel@sandisk.com>
Date: Tue, 15 Nov 2016 14:50:17 +0000
From: Bart Van Assche <Bart.VanAssche@...disk.com>
To: "jthumshirn@...e.de" <jthumshirn@...e.de>
CC: "jejb@...ux.vnet.ibm.com" <jejb@...ux.vnet.ibm.com>,
"hch@...radead.org" <hch@...radead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"hare@...e.de" <hare@...e.de>,
"martin.petersen@...cle.com" <martin.petersen@...cle.com>,
"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
"arnd@...db.de" <arnd@...db.de>
Subject: Re: [PATCH] libfc: fix seconds_since_last_reset miscalculation
On Tue, 2016-11-15 at 10:18 +0100, Johannes Thumshirn wrote:
> On Tue, Nov 08, 2016 at 03:04:43PM +0000, Bart Van Assche wrote:
> > I think the above code will miscalculate seconds_since_last_reset
> > if
> > 'jiffies' wraps around after an lport has been created and before
> > seconds_since_last_reset is computed. Shouldn't
> > seconds_since_last_reset
> > be computed as follows?
> >
> > fc_stats->seconds_since_last_reset = (jiffies - boot_time) /
> > HZ;
>
> But what happens when jiffies - boot_time becomes negative? Then we
> reintroduce the bug again and have 'fcoeadm -s' show weird values.
Hello Johannes,
If your concern is about 'jiffies' wrapping around on 32-bit systems
then you should use get_jiffies_64(). get_jiffies_64() - boot_time
can't become negative. It namely takes several million years before a
64-bit HZ counter wraps around.
Bart.
Powered by blists - more mailing lists