| 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
| ||
|
Message-ID: <1413722356.2991.8.camel@localhost.localdomain> Date: Sun, 19 Oct 2014 14:39:16 +0200 From: Thomas Meyer <thomas@...3r.de> To: user-mode-linux-devel <user-mode-linux-devel@...ts.sourceforge.net>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: [UM] Long loop in __getnsdayoftime() after resume from ram Hello, in UML kernel I get a long cpu using loop in __getnstimeofday() (kernel/time/timekeeping.c:315) in the call of timespec_add_ns(), when I left the host kernel suspended to ram for a few hours and resume again. this is because it seems like the tk->xtime_sec wasn't updated yet, but the nsecs were. nsecs can be as high as 8111000111000111000l the function timespec_add_ns() (include/linux/time.h:266) will call __iter_div_u64_rem() which has an optimized loop for the case that the dividend is not much bigger as the divisior. but this isn't the case for resume from ram on the host kernel. any ideas how to fix this? is it possible to intercept the resume from ram and update the timekeeper->xtime_sec somehow? or can the um arch somehow overwrite timespec_add_ns() to always use div_u64_rem() instead? with kind regards PS: repost on these lists, because nobody did respond to my original email. -- 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