| 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: Fri, 14 Jun 2013 01:03:41 +0200 From: Francois Romieu <romieu@...zoreil.com> To: Johannes Berg <johannes@...solutions.net> Cc: netdev@...r.kernel.org, mcgrof@...not-panic.com, kvalo@...rom.com, adrian.chadd@...il.com Subject: Re: [PATCH] alx: add a simple AR816x/AR817x device driver Johannes Berg <johannes@...solutions.net> : [...] > Yes, I suppose I could, but is it worth it? It's held only for a very > short amount of time to get the indirect register access correct. I > don't really see any reason to prefer a mutex here? Neither a spinlock nor a mutex should be needed but I have to sleep before figuring it. > Not sure what you mean by "push it in the common core methods"? I > actually suspect that this lock can't ever be contended because the > callers hold the RTNL anyway, but I don't really want to rely on just > that. Don't be shy :o) [...] > Hmm, yeah, I'll have to think about that. I don't really care about the > performance all that much ... just want the device to work :-) Ok. It's fine. > Would I really want to rely on NAPI for error interrupts and the like > though? I thought NAPI could potentially be deferred due to budget etc. It will have to wait for ksoftirqd once its budget is exhausted. If the irq and napi handlers don't share a lock, either they are racing or the napi handler will be kicked on irq return. I'll admit a bias towards some extra latency if it can buy user context comfort. -- Ueimor -- 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