The CLUSTERIP target creates a procfs entry for all different cluster
IPs.  Although more than one rules can refer to a single cluster IP (and
thus a single config structure), removal of the procfs entry is done
unconditionally in destroy(). In more complicated situations involving
deferred dereferencing of the config structure by procfs and creating a
new rule with the same cluster IP it's also possible that no entry will
be created for the new rule.

This patch fixes the problem by counting the number of entries
referencing a given config structure and moving the config list
manipulation and procfs entry deletion parts to the
clusterip_config_entry_put() function.
Signed-off-by: NKOVACS Krisztian <hidden@balabit.hu>
Signed-off-by: NHarald Welte <laforge@netfilter.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Thanks to Andy Stewart for the report and testing
debug patches from Michael Chan.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

As discussed in the dccp@vger mailing list:

Now applications have to use setsockopt(DCCP_SOCKOPT_SERVICE, service[s]),
prior to calling listen() and connect().

An array of unsigned ints can be passed meaning that the listening sock accepts
connection requests for several services.

With this we can ditch struct sockaddr_dccp and use only sockaddr_in (and
sockaddr_in6 in the future).
Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Moving the setting of DCCP_SKB_CB(skb)->dccpd_reset_code to the places
where events happen that trigger sending a RESET packet.
Signed-off-by: NArnaldo Carvalho de Melo <acme@mandriva.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Noticed by Sridhar Samudrala.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

In the unlikely case of the new screen width much wider then the old,
use (old_row_size * new_rows) instead of new_screen_size to prevent a
buffer overrun during the copy.
Signed-off-by: NAntonino Daplas <adaplas@pol.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Reported by: walt <wa1ter@myrealbox.com>

"I routinely switch the console font during bootup to
8x8 so I can get 50 lines per screen.  Until 09 Sept,
just changing to the small font automatically gave me
all 50 lines -- but now I'm only getting 25 lines even
with the small font.  The bottom half of the screen
displays the text that already scrolled off the top."

This bug is due to an erroneous check in the recently added hook,
vgacon_resize(). It checks the new height against the original number of
rows of the console. Because the original number of rows depends on both
the scanline and the font height, check it instead against the
scanline/fontheight.
Signed-off-by: NAntonino Daplas <adaplas@pol.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

- The Twister chipsets are actually prosavages.  Reclassify them as
  such and remove the S3_SAVAGE_TWISTER id.
- Fix i2c code if fb_firmware_edid() returns NULL
Signed-off-by: NAntonino Daplas <adaplas@pol.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

As noted by Olof Johansson <olof@lixom.net>:

  "A recent patch changed the way the LPAR bit is checked during early
   boot.  This resulted in a polarity change in a conditional branch
   without changing the branch, causing at least some legacy machines to
   not boot."

This fixes it.
Signed-off-by: NJimi Xenidis <jimix@watson.ibm.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Several implementations were essentialy a common piece of C code using
the cmpxchg() macro.  Put the implementation in one spot that everyone
can share, and convert sparc64 over to using this.

Alpha is the lone arch-specific implementation, which codes up a
special fast path for the common case in order to avoid GP reloading
which a pure C version would require.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Missing acct_update_integrals() and update_mem_hiwater() calls
compared to it's native counterpart.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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: NDavid L Stevens <dlstevens@us.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

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.

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: NJulian Anastasov <ja@ssi.bg>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Agostino di Salle noticed that persistent templates are not
invalidated due to buggy optimization.
Signed-off-by: NJulian Anastasov <ja@ssi.bg>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Here's a slightly altered patch, originally from Mark Glines who
diagnosed and fixed the problem.
Signed-off-by: NBart De Schuymer <bdschuym@pandora.be>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This patch fixes line dupes at /ipv4/igmp.c and /ipv6/mcast.c in the  
2.6 kernel, where MCAST_EXCLUDE is mistakenly used instead of  
MCAST_INCLUDE.
Signed-off-by: NDenis Lukianov <denis@voxelsoft.com>
Signed-off-by: NDavid L Stevens <dlstevens@us.ibm.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

As requested by Jamal.
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The problem is that the SACK fragmenting code may incorrectly call
tcp_fragment() with a length larger than the skb->len.  This happens
when the skb on the transmit queue completely falls to the LHS of the
SACK.

And add a BUG() check to tcp_fragment() so we can spot this kind of
error more quickly in the future.
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Commit 66759a01 introduced the fix for
time ticking too fast on some boards by disabling one of the doubly
connected timer pins on ATI boards.

However, it ends up being _much_ too broad a brush, and that just makes
some other ATI boards not work at all since they now have no timer
source.

So disable the automatic ATI southbridge detection, and just rely on
people who see this problem disabling it by hand with the option
"disable_timer_pin_1" on the kernel command line.

Maybe somebody can figure out the proper tests at a later date.
Acked-by: NPeter Osterlund <petero2@telia.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Actually add the file this time.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This allows i2c-pxa to finally build.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Nicolas Pitre

This apparently fell in the crack somewhere.  Add it back.
Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Patch from Vincent Sanders

When building the ARM platforms several serial drivers fail to compile
with GCC 4.01 due to extern/static ambiguity.
Signed-off-by: NVincent Sanders <vince@arm.linux.org.uk>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Its possible that we can write to the hvc_console tty as soon it is
registered.  Recently this started happening due to (what looks like) a
change to the hotplug code.

Unfortunately at this stage we have not started the khvcd kernel thread and
oops.  The solution is to start the kernel thread before registering the
tty.
Signed-off-by: NAnton Blanchard <anton@samba.org>
Cc: Paul Mackerras <paulus@samba.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

While doing an allyesconfig build, I noticed that the commit

    commit 8cdfd251
    Author: Takashi Iwai <tiwai@suse.de>
    Date:   Wed Sep 7 14:08:11 2005 +0200

        [ALSA] Remove superfluous PCI ID definitions

broke the RME32 and RME96 drivers, since the PCI IDs they use seem to have
changed names.  Here's a patch to fix this -- compile tested only, since I
have no idea what the hardware even is.

Fix the build of the RME32 and RME96 drivers by having them use the
PCI_DEVICE_ID_RME_xxx names defined in <linux/pci_ids.h> instead of the
PCI_DEVICE_ID_xxx names that they used to define themselves.

Also fix the typo in the id PCI_DEVICE_IDRME__DIGI96_8_PAD_OR_PST so the
name is PCI_DEVICE_ID_RME_DIGI96_8_PAD_OR_PST.
Signed-off-by: NRoland Dreier <rolandd@cisco.com>
Acked-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The call to fb_firmware_edid may return NULL but this is not checked before
trying to memcpy using this pointer.
Signed-off-by: NAntonino Daplas <adaplas@pol.net>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

On 8xx flush_tlb_range() declaration is using a "struct mm_struct *"
pointer type while the function itself uses "struct vm_area_struct *".
Signed-off-by: NMarcelo Tosatti <marcelo.tosatti@cyclades.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

the 4th id field should be not used
Signed-off-by: NKarsten Keil <kkeil@suse.de>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

And mention 'pci=assign-busses' as a possible fix.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Noted by David Miller:

  "The bug is that free_fd_array() takes a "num" argument, but when
   calling it from __free_fdtable() we're instead passing in the size in
   bytes (ie.  "num * sizeof(struct file *)")."

Yes it is a bug. I think I messed it up while merging newer
changes with an older version where I was using size in bytes
to optimize.
Signed-off-by: NDipankar Sarma <dipankar@in.ibm.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

With the new changes that we made in the initialization of the slab
allocator, we first setup the cache from which array caches are allocated,
and then the cache, from which kmem_list3's are allocated.

Now if the array cache comes from a cache in which objsize > 32, (in this
instance size-64) then, first size-64 cache will be allocated and then the
size-128 (if this is the cache from which kmem_list3's are going to be
allocated).

So with these new changes, we are not guaranteed that we will be
initializing the malloc_sizes array in a serialized order. Thus there is
a bug in __find_general_cachep, as we are checking whether the first
cache_sizes ptr is NULL.

This is replaced by checking whether the array-cache cache is initialized.
Attached is a patch which does that.  Boots fine on a x86-64, with
DEBUG_SPIN, DEBUG_SLAB, and preempt.

Attached is a patch which does that.  Boots fine on a x86-64, with
DEBUG_SPIN, DEBUG_SLAB, and preempt.Thanks & Regards, Alok
Signed-off-by: NAlok N Kataria <alokk@calsoftinc.com>
Signed-off-by: Shobhit Dayal <shobhitdayal.com>
Cc: Manfred Spraul <manfred@colorfullife.com>
Cc: Christoph Lameter <christoph@lameter.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

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: NIvan Kokshaysky <ink@jurassic.park.msu.ru>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Pavel Emelianov and Kirill Korotaev observe that fs and arch users of
security_vm_enough_memory tend to forget to vm_unacct_memory when a
failure occurs further down (typically in setup_arg_pages variants).

These are all users of insert_vm_struct, and that reservation will only
be unaccounted on exit if the vma is marked VM_ACCOUNT: which in some
cases it is (hidden inside VM_STACK_FLAGS) and in some cases it isn't.

So x86_64 32-bit and ppc64 vDSO ELFs have been leaking memory into
Committed_AS each time they're run.  But don't add VM_ACCOUNT to them,
it's inappropriate to reserve against the very unlikely case that gdb
be used to COW a vDSO page - we ought to do something about that in
do_wp_page, but there are yet other inconsistencies to be resolved.

The safe and economical way to fix this is to let insert_vm_struct do
the security_vm_enough_memory check when it finds VM_ACCOUNT is set.

And the MIPS irix_brk has been calling security_vm_enough_memory before
calling do_brk which repeats it, doubly accounting and so also leaking.
Remove that, and all the fs and arch calls to security_vm_enough_memory:
give it a less misleading name later on.
Signed-off-by: NHugh Dickins <hugh@veritas.com>
Signed-Off-By: NKirill Korotaev <dev@sw.ru>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>