[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1368220776.18714.30.camel@ideak-mobl>
Date: Sat, 11 May 2013 00:19:36 +0300
From: Imre Deak <imre.deak@...el.com>
To: Michal Kubecek <mkubecek@...e.cz>
Cc: linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Daniel Vetter <daniel.vetter@...ll.ch>,
Jay Vosburgh <fubar@...ibm.com>,
Andy Gospodarek <andy@...yhouse.net>, netdev@...r.kernel.org
Subject: Re: [PATCH 06/11] net/bonding: take msecs_to_jiffies_min into use
On Fri, 2013-05-10 at 15:58 +0200, Michal Kubecek wrote:
> On Fri, May 10, 2013 at 03:13:24PM +0300, Imre Deak wrote:
> > --- a/drivers/net/bonding/bond_main.c
> > +++ b/drivers/net/bonding/bond_main.c
> > @@ -1751,7 +1751,7 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
> > read_lock(&bond->lock);
> >
> > new_slave->last_arp_rx = jiffies -
> > - (msecs_to_jiffies(bond->params.arp_interval) + 1);
> > + (msecs_to_jiffies_min(bond->params.arp_interval));
> >
> > if (bond->params.miimon && !bond->params.use_carrier) {
> > link_reporting = bond_check_dev_link(bond, slave_dev, 1);
>
> This "+ 1" was actually meant as "plus one". We need to ensure that
>
> slave->last_arp_rx + msecs_to_jiffies(bond->params.arp_interval)
>
> is strictly less than current value of jiffies.
Ok, I see, the adjustment here is for a different reason and
msecs_to_jiffies_min wouldn't express this properly. So we should drop
this patch. Perhaps it'd be nice to add something like the above
explanation as a code comment, to make it clear that the adjustment is
not for guaranteeing a minimum duration as it is in many other places.
--Imre
> So with proposed
> definition of msecs_to_jiffies_min() it works correctly but if the
> implementation ever changes in such way that
>
> msecs_to_jiffies_min(x) >= msecs_to_jiffies(x)
>
> for some value of x, the code would be incorrect.
>
> Michal Kubeček
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists