////////////////////////////////////////////////////////////////////////////// netsniff-ng - the packet sniffing beast \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ . . netsniff-ng is a free, performant /( )\ Linux network analyzer and .' {______} '. networking toolkit. If you will, \ ^, ,^ / the Swiss army knife for network |'O\ /O'| _.<0101011>-- packets. > `' '` < / ) ,.==., ( | Web: http://netsniff-ng.org .-(|/--~~--\|)-' ( ___ The gain of performance is \__.=|___E reached by built-in zero-copy mechanisms, so that on packet reception and transmission the kernel does not need to copy packets from kernel space to user space, and vice versa. The netsniff-ng toolkit's primary usage goal is to facilitate a network developer's / hacker's daily Linux plumbing. It can be used for network development, debugging, analysis, auditing or network reconnaissance. It consists of the following fixed set of utilities: * netsniff-ng: a zero-copy packet analyzer, pcap capturing/replaying tool * trafgen: a multithreaded low-level zero-copy network packet generator * mausezahn: high-level packet generator for HW/SW appliances with Cisco-CLI * ifpps: a top-like kernel networking and system statistics tool * curvetun: a lightweight curve25519-based multiuser IP tunnel * astraceroute: an autonomous system trace route and DPI testing utility * flowtop: a top-like netfilter connection tracking tool * bpfc: a Berkeley Packet Filter compiler, Linux BPF JIT disassembler Each release can be verified with Git and GPG, here are the steps to do so: 1) Import the maintainers public keys: git show maint-tklauser-pgp-pub | gpg --import git show maint-dborkman-pgp-pub | gpg --import 2) Verify the Git tag: git tag -v Carefully read the INSTALL document for the next steps in building netsniff-ng. Note that the toolkit is still quite young and under heavy development, not yet feature complete and in a quality level where we're satisfied with (i.e. for mausezahn). However, we're on a good way towards tackling all these goals. The netsniff-ng toolkit is an open source project covered by the GNU General Public License, version 2.0. For any questions or feedback about netsniff-ng you are welcome to leave us a message at . netsniff-ng is non-profit and provided in the hope, that it is found useful. The current project status can be considered as "working". In general, all tools have been tested by us to a great extend including their command-line options. In fact, many of our tools are used in a lot of production systems. However, we give no guarantee that our tools are free of bugs! If you spot some issues, contact us as described in REPORTING-BUGS. Also, have a look at our online FAQ for answering your questions. This project has received support from companies and institutions listed in Sponsors. Thanks for contributing, we're thrilled to provide you with netsniff-ng! Happy packet hacking! '5'>5space:mode:
authorFrederic Weisbecker <fweisbec@gmail.com>2017-01-04 15:12:04 +0100
committerThomas Gleixner <tglx@linutronix.de>2017-01-11 10:41:33 +0100
commit24b91e360ef521a2808771633d76ebc68bd5604b (patch)
treebca05efec060a4efaf79c0260bebdb22fa3a0635
parenta121103c922847ba5010819a3f250f1f7fc84ab8 (diff)
nohz: Fix collision between tick and other hrtimers
When the tick is stopped and an interrupt occurs afterward, we check on that interrupt exit if the next tick needs to be rescheduled. If it doesn't need any update, we don't want to do anything. In order to check if the tick needs an update, we compare it against the clockevent device deadline. Now that's a problem because the clockevent device is at a lower level than the tick itself if it is implemented on top of hrtimer. Every hrtimer share this clockevent device. So comparing the next tick deadline against the clockevent device deadline is wrong because the device may be programmed for another hrtimer whose deadline collides with the tick. As a result we may end up not reprogramming the tick accidentally. In a worst case scenario under full dynticks mode, the tick stops firing as it is supposed to every 1hz, leaving /proc/stat stalled: Task in a full dynticks CPU ---------------------------- * hrtimer A is queued 2 seconds ahead * the tick is stopped, scheduled 1 second ahead * tick fires 1 second later * on tick exit, nohz schedules the tick 1 second ahead but sees the clockevent device is already programmed to that deadline, fooled by hrtimer A, the tick isn't rescheduled. * hrtimer A is cancelled before its deadline * tick never fires again until an interrupt happens... In order to fix this, store the next tick deadline to the tick_sched local structure and reuse that value later to check whether we need to reprogram the clock after an interrupt. On the other hand, ts->sleep_length still wants to know about the next clock event and not just the tick, so we want to improve the related comment to avoid confusion. Reported-by: James Hartsock <hartsjc@redhat.com> Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> Reviewed-by: Wanpeng Li <wanpeng.li@hotmail.com> Acked-by: Peter Zijlstra <peterz@infradead.org> Acked-by: Rik van Riel <riel@redhat.com> Link: http://lkml.kernel.org/r/1483539124-5693-1-git-send-email-fweisbec@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Diffstat