1. 03 Oct, 2005 5 commits
    • Paolo 'Blaisorblade' Giarrusso's avatar
      [PATCH] uml - Fix x86_64 page leak · 38e00d34
      Paolo 'Blaisorblade' Giarrusso authored
      We were leaking pmd pages when 3_LEVEL_PGTABLES was enabled. This fixes that,
      has been well tested and is included in mainline tree. Please include in -stable
      as well.
      Signed-off-by: default avatarJeff Dike <jdike@addtoit.com>
      Signed-off-by: default avatarPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
      Signed-off-by: default avatarChris Wright <chrisw@osdl.org>
      38e00d34
    • Julian Anastasov's avatar
      [PATCH] ipvs: ip_vs_ftp breaks connections using persistence · 17d6b7c8
      Julian Anastasov authored
      	ip_vs_ftp when loaded can create NAT connections with unknown
      client port for passive FTP. For such expectations we lookup with
      cport=0 on incoming packet but it matches the format of the persistence
      templates causing packets to other persistent virtual servers to be
      forwarded to real server without creating connection. Later the
      reply packets are treated as foreign and not SNAT-ed.
      
      	If the IPVS box serves both FTP and other services (eg. HTTP)
      for the time we wait for first packet for the FTP data connections with
      unknown client port (there can be many), other HTTP connections
      that have nothing common to the FTP conn break, i.e. HTTP client
      sends SYN to the virtual IP but the SYN+ACK is not NAT-ed properly
      in IPVS box and the client box returns RST to real server IP. I.e.
      the result can be 10% broken HTTP traffic if 10% of the time
      there are passive FTP connections in connecting state. It hurts
      only IPVS connections.
      
      	This patch changes the connection lookup for packets from
      clients:
      
      * introduce IP_VS_CONN_F_TEMPLATE connection flag to mark the
      connection as template
      * create new connection lookup function just for templates - ip_vs_ct_in_get
      * make sure ip_vs_conn_in_get hits only connections with
      IP_VS_CONN_F_NO_CPORT flag set when s_port is 0. By this way
      we avoid returning template when looking for cport=0 (ftp)
      Signed-off-by: default avatarJulian Anastasov <ja@ssi.bg>
      Signed-off-by: default avatarChris Wright <chrisw@osdl.org>
      17d6b7c8
    • David Stevens's avatar
      [PATCH] fix IPv6 per-socket multicast filtering in exact-match case · 6ce0c8df
      David Stevens authored
      per-socket multicast filters were not being applied to all sockets
      in the case of an exact-match bound address, due to an over-exuberant
      "return" in the look-up code. Fix below. IPv4 does not have this problem.
      
      Thanks to Hoerdt Mickael for reporting the bug.
      Signed-off-by: default avatarDavid L Stevens <dlstevens@us.ibm.com>
      Signed-off-by: default avatarChris Wright <chrisw@osdl.org>
      6ce0c8df
    • Alexander Nyberg's avatar
      [PATCH] Fix fs/exec.c:788 (de_thread()) BUG_ON · 99e56fc6
      Alexander Nyberg authored
      It turns out that the BUG_ON() in fs/exec.c: de_thread() is unreliable
      and can trigger due to the test itself being racy.
      
      de_thread() does
       	while (atomic_read(&sig->count) > count) {
      	}
      	.....
      	.....
      	BUG_ON(!thread_group_empty(current));
      
      but release_task does
      	write_lock_irq(&tasklist_lock)
      	__exit_signal
      		(this is where atomic_dec(&sig->count) is run)
      	__exit_sighand
      	__unhash_process
      		takes write lock on tasklist_lock
      		remove itself out of PIDTYPE_TGID list
      	write_unlock_irq(&tasklist_lock)
      
      so there's a clear (although small) window between the
      atomic_dec(&sig->count) and the actual PIDTYPE_TGID unhashing of the
      thread.
      
      And actually there is no need for all threads to have exited at this
      point, so we simply kill the BUG_ON.
      
      Big thanks to Marc Lehmann who provided the test-case.
      
      Fixes Bug 5170 (http://bugme.osdl.org/show_bug.cgi?id=5170)
      Signed-off-by: default avatarAlexander Nyberg <alexn@telia.com>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Andrew Morton <akpm@osdl.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Acked-by: default avatarAndi Kleen <ak@suse.de>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      Signed-off-by: default avatarChris Wright <chrisw@osdl.org>
      99e56fc6
    • Ivan Kokshaysky's avatar
      [PATCH] yenta oops fix · ef1b2a3b
      Ivan Kokshaysky authored
      In some cases, especially on modern laptops with a lot of PCI and
      cardbus bridges, we're unable to assign correct secondary/subordinate
      bus numbers to all cardbus bridges due to BIOS limitations unless
      we are using "pci=assign-busses" boot option.
      So some cardbus controllers may not have attached subordinate pci_bus
      structure, and yenta driver must cope with it - just ignore such cardbus
      bridges.
      
      For example, see https://bugzilla.novell.com/show_bug.cgi?id=113778Signed-off-by: default avatarIvan Kokshaysky <ink@jurassic.park.msu.ru>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      Signed-off-by: default avatarChris Wright <chrisw@osdl.org>
      ef1b2a3b
  2. 17 Sep, 2005 12 commits
  3. 10 Sep, 2005 11 commits
  4. 28 Aug, 2005 5 commits
  5. 27 Aug, 2005 7 commits