netdev - Linx

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20070807153918.231ee1ed@oldman>
Date:	Tue, 7 Aug 2007 15:39:18 -0400
From:	Stephen Hemminger <shemminger@...ux-foundation.org>
To:	netdev@...r.kernel.org
Subject: Linx

After seeing this article on Linx
 http://www.linuxdevices.com/news/NS8613439087.html
I decided to give it a quick code review (long airline flight).
Overall, it isn't awful, it just looks like every other piece of code
that hasn't been managed for mainline kernel inclusion.
Nice way of saying, this turd needs a man year or more of polishing.

Gratiutious Code Review of Linx

0. Bugs.
   A. Device names can change in kernel at anytime, use pointers
      or ifindex. In fact any name change will crash kernel in
      BUG_ON in notifier
   B. Device's changing MTU will crash kernel in BUG_ON
   C. Calling del_timer_sync under RTNL

1. Coding Style
   A. Typedef's
      Don't use typedef's like LINX_SPID, ...
   B. Non-standard naming conventions
      I. Don't use uint32_t for kernel use u32 or __u32
      II. No MixedCaseNames
   C. Use std. macros
      I. BUG_ON vs. LINX_ASSERT, etc
   D. Code in macro's that should really be inline's
      (e.g. linx_check_linx_huntname)
   E. Indentation
   F. Excessive scope, much of the code could be local to one file
   G. Too many spelling errors
   H. OS Abstraction layer is unacceptable
   I. Use initializers when possible (e.g device_notifier)
   J. Quit with all the assert's for in_irq() in timer's etc...

2. Bogus wrappers
   A. Kmalloc
   B. Spinlocks

3. Unacceptable ABI
   A. ioctl's for special functions
   B. Heavy reliance on config parameters in /proc
   C. Looks dependent on Ethernet address format
   D. Code for non-standard adaptive coalesce
      and his code has protocol playing with drivers timers directly.
   E. Non-assigned number for Ethernet protocol

4. FYI
   A. No __init or __exit
   B. Kernel API documentation
      Only document API calls that matter not every pissant little function.
      Avoid stating the obvious.
      Why not use docbook format?
   C. Locking way to fine grained (lots of small locks)
      Should use RCU and avoid rwlocks
      Use existing linux network device API locks (ie dev_base_lock, RTNL)
      if possible.

Those who don't understand TCP/IP are doomed to reimplement it, badly.
-
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