1. 24 Nov, 2015 2 commits
    • Mike Frysinger's avatar
      use sockaddr_storage everywhere · 5c9e1e76
      Mike Frysinger authored
      Not all sockaddr structs have the same alignment.  Instead, it depends
      on the fields contained in it.  The way net-tools has written things
      though, it accepts sockaddr* everywhere which has 16bit alignment, even
      though it will cast it to other sockaddr types that have higher alignment.
      For example, `route` can crash on alpha because it declares sockaddr on
      the stack, but then casts it up to sockaddr_in6 (which has 32bits).
      
      It's also bad storage wise as we might try to cast the sockaddr to a type
      that is larger than sockaddr which means clobbering the stack.
      
      Instead, lets rewrite all the APIs to take a sockaddr_storage.  This is
      guaranteed to have both the maximum alignment and size requirements for
      all other sockaddr types.  Now we can safely cast that pointer to any
      other sockaddr type and not worry about it.  It also has the nice effect
      of deleting a lot of casts in a lot of places when we only need the type
      of family.
      
      The vast majority of changes here are mechanical.  There are a few places
      where we have to memcpy between a dedicated sockaddr_storage and a smaller
      struct because we're using an external embedded type (like arpreq).
      
      URL: https://bugs.gentoo.org/558436
      5c9e1e76
    • Mike Frysinger's avatar
      netstat: convert to sockaddr_storage · 27e4308d
      Mike Frysinger authored
      Rather than use different sockaddr base types for storage, always
      start with sockaddr_storage on the stack and set up pointers to
      more limited versions to that.  This way we always get the correct
      alignment and storage when we pass it down to lower layers.
      
      This is really just a set up for a follow up change to convert the
      codebase entirely to sockaddr_storage.  This is just a fairly self
      contained change.
      27e4308d
  2. 24 Oct, 2015 1 commit
  3. 29 Aug, 2015 10 commits
  4. 26 Aug, 2015 6 commits
  5. 25 Aug, 2015 10 commits
  6. 23 Jul, 2015 1 commit
  7. 15 Jul, 2015 1 commit
  8. 13 Jul, 2015 1 commit
  9. 26 May, 2015 1 commit
    • Mike Frysinger's avatar
      build: turn on transparent LFS support · 9bdfd2cc
      Mike Frysinger authored
      Make sure we use 64-bit filesystem functions everywhere.  This applies not
      only to being able to read large files (which generally doesn't apply to
      us), but also being able to simply stat them (as they might be using large
      inodes).
      9bdfd2cc
  10. 18 May, 2015 2 commits
  11. 05 Apr, 2015 2 commits
  12. 07 Jan, 2015 1 commit
    • Jiri Popelka's avatar
      ifconfig can incorrectly round PiB · e5f1be13
      Jiri Popelka authored
      When an interface has transferred exbibytes
      (> 0.8 EiB, i.e. > 819 PiB) of traffic,
      the short display is rounded incorrectly.
      
      For example:
      bytes 2154408931384050514 (275.0 PiB)
      while correct is (1913.4 PiB)
      
      This happens because we times the rx/tx bytes values by 10,
      then calculate the short version from that result:
      
      lib/interface.c:ife_print_long()
      
      tx = ptr->stats.tx_bytes;
      short_tx = tx * 10;
      if (tx > 1125899906842624ull) {
        short_tx /= 1125899906842624ull;
        Text = "PiB";
      }
      
      But multiplying anything more than 819 PiB by 10 overflows a ull
      which is a uint64_t (max value of 9223372036854775807).
      
      We'll never get accuracy over 8192 PiB (2^64) when using ull,
      but we can at least correctly handle values between 819 - 8192 PiB.
      e5f1be13
  13. 11 Nov, 2014 1 commit
  14. 19 Oct, 2014 1 commit