lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 19 Mar 2015 18:04:17 -0700 From: Eric Dumazet <eric.dumazet@...il.com> To: Jonathan Toppins <jtoppins@...ulusnetworks.com> Cc: "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org, Curt Brune <curt@...ulusnetworks.com> Subject: Re: [PATCH v1 net-next] tuntap: convert to 64-bit interface statistics On Thu, 2015-03-19 at 19:52 -0400, Jonathan Toppins wrote: > On 3/19/15 6:56 PM, Eric Dumazet wrote: > > On Thu, 2015-03-19 at 17:56 -0400, Jonathan Toppins wrote: > > > > > >> Or are you suggesting per-cpu counters would be preferred which would > >> possibly eliminate the need for this lock? > > > > Might be overkill for a device that is probably used by one cpu, > > considering you defined a full struct rtnl_link_stats64, instead of the > > fields that are really handled. > > > > Ok. So summarizing for v2, so far; eliminating the back-to-back lock -> > release -> lock -> release is preferred (I agree with this). > > It still seems like you are not a huge fan of the additional lock, > should I hold off on sending v2 for a day, so we can ponder alternatives? It seems you need a lock only in RX, for 2 vars only. (rx_packets & rx_bytes) error counters are generally OK with unsigned long, nobody will complain of possible concurrent non atomic updates. So maybe percpu var for these 16 bytes would be OK. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists