[TEXTSEARCH]: Do not allow zero length patterns in the textsearch infrastructure

If a zero length pattern is passed then return EINVAL.
Avoids infinite loops (bm) or invalid memory accesses (kmp).

Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

[NETFILTER]: fix forgotten module release in xt_CONNMARK and xt_CONNSECMARK

Fix forgotten module release in xt_CONNMARK and xt_CONNSECMARK

When xt_CONNMARK is used outside the mangle table and the user specified
"--restore-mark", the connmark_tg_check() function will (correctly)
error out, but (incorrectly) forgets to release the L3 conntrack module.
Same for xt_CONNSECMARK.

Fix is to move the call to acquire the L3 module after the basic
constraint checks.

Signed-off-by: Jan Engelhardt <jengelh@computergmbh.de>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

[NETFILTER]: xt_TCPMSS: remove network triggerable WARN_ON

ipv6_skip_exthdr() returns -1 for invalid packets. don't WARN_ON
that.

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

[DECNET]: dn_nl_deladdr() almost always returns no error

As far as I see from the err variable initialization
the dn_nl_deladdr() routine was designed to report errors
like "EADDRNOTAVAIL" and probaby "ENODEV".

But the code sets this err to 0 after the first nlmsg_parse
and goes on, returning this 0 in any case.

Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Acked-by: Steven Whitehouse <swhiteho@redhat.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

[IPV6]: Restore IPv6 when MTU is big enough

Avaid provided test application, so bug got fixed.

IPv6 addrconf removes ipv6 inner device from netdev each time cmu
changes and new value is less than IPV6_MIN_MTU (1280 bytes).
When mtu is changed and new value is greater than IPV6_MIN_MTU,
it does not add ipv6 addresses and inner device bac.

This patch fixes that.

Tested with Avaid's application, which works ok now.

Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

[RXRPC]: Add missing select on CRYPTO

AF_RXRPC uses the crypto services, so should depend on or select CRYPTO.

Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

Merge branch 'fixes-davem' of git://git./linux/kernel/git/linville/wireless-2.6

mac80211: rate limit wep decrypt failed messages

The attached patch rate limits "WEP decrypt failed (ICV)" to avoid
flooding the logfiles.

Signed-off-by: Adel Gadllah <adel.gadllah@gmx.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

rfkill: fix double-mutex-locking

rfkill_toggle_radio is called from functions where
rfkill->mutex is already aquired.

Remove the lock from rfkill_toggle_radio() and add it to
the only calling function that calls it without the lock held.

Signed-off-by: Michael Buesch <mb@bu3sch.de>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: drop unencrypted frames if encryption is expected

This patch fixes a regression I (most likely) introduced, namely that
unencrypted frames are right now accepted even if we have a key for that
specific sender. That has very bad security implications.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: Fix behavior of ieee80211_open and ieee80211_close

This patch fixes:
- Incorrect calls to ieee80211_hw_config when the radiotap flag is set.
- Failure to actually unset the radiotap flag when all monitors are down.
- Failure to call ieee80211_hw_config after successful interface start.

Signed-off-by: Michael Wu <flamingice@sourmilk.net>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

ieee80211: fix unaligned access in ieee80211_copy_snap

There is no guarantee that data+SNAP_SIZE will reside on an even numbered
address, so doing a 16 bit read will cause an unaligned access in some
situations. Based on a patch from Jun Sun.

Signed-off-by: Daniel Drake <dsd@gentoo.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: free ifsta->extra_ie and clear IEEE80211_STA_PRIVACY_INVOKED

I'm not sure if this is best choice, someone might have better
solutions. But this patch fixed the connection problem when switching
from a WPA enabled AP (using wpa_supplicant) to an open AP (using
iwconfig). The root cause is when we connect to a WPA enabled AP,
wpa_supplicant sets the ifsta->extra_ie thru SIOCSIWGENIE. But if we
stop wpa_supplicant and connect to an open AP with iwconfig, there is
no way to clear the extra_ie so that mac80211 keeps connecting with that.

Someone could argue wpa_supplicant should clear the extra_ie during
its shutdown. But mac80211 should also handle the unexpected shutdown
case (ie. killall -9 wpa_supplicant).

On Wed, 2007-11-21 at 16:19 +0100, Johannes Berg wrote:
> Yeah. Can you amend the patch to also clear the
> IEEE80211_STA_PRIVACY_INVOKED flag?

Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

SCTP: Fix build issues with SCTP AUTH.

SCTP-AUTH requires selection of CRYPTO, HMAC and SHA1 since
SHA1 is a MUST requirement for AUTH.  We also support SHA256,
but that's optional, so fix the code to treat it as such.

Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>

SCTP: Fix chunk acceptance when no authenticated chunks were listed.

In the case where no autheticated chunks were specified, we were still
trying to verify that a given chunk needs authentication and doing so
incorrectly.  Add a check for parameter length to make sure we don't
try to use an empty auth_chunks parameter to verify against.

Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>

SCTP: Fix the supported extensions paramter

Supported extensions parameter was not coded right and ended up
over-writing memory or causing skb overflows.  First, remove
the FWD_TSN support from as it shouldn't be there and also fix
the paramter encoding.

Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>

SCTP: Fix SCTP-AUTH to correctly add HMACS paramter.

There was a typo that cleared the HMACS parameters when no
authenticated chunks were specified.  We whould be clearing
the chunks pointer instead of the hmacs.

Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>

SCTP: Fix the number of HB transmissions.

Our treatment of Heartbeats is special in that the inital HB chunk
counts against the error count for the association, where as for
other chunks, only retransmissions or timeouts count against us.
As a result, we had an off-by-1 situation with a number of
Heartbeats we could send.

Signed-off-by: Vlad Yasevich <vladislav.yasevich@hp.com>

[TCP] illinois: Incorrect beta usage

Lachlan Andrew observed that my TCP-Illinois implementation uses the
beta value incorrectly:
  The parameter  beta  in the paper specifies the amount to decrease
  *by*:  that is, on loss,
     W <-  W -  beta*W
  but in   tcp_illinois_ssthresh() uses  beta  as the amount
  to decrease  *to*: W <- beta*W

This bug makes the Linux TCP-Illinois get less-aggressive on uncongested network,
hurting performance. Note: since the base beta value is .5, it has no
impact on a congested network.

Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

[IPSEC]: Fix uninitialised dst warning in __xfrm_lookup

Andrew Morton reported that __xfrm_lookup generates this warning:

net/xfrm/xfrm_policy.c: In function '__xfrm_lookup':
net/xfrm/xfrm_policy.c:1449: warning: 'dst' may be used uninitialized in this function

This is because if policy->action is of an unexpected value then dst will
not be initialised.  Of course, in practice this should never happen since
the input layer xfrm_user/af_key will filter out all illegal values.  But
the compiler doesn't know that of course.

So this patch fixes this by taking the conservative approach and treat all
unknown actions the same as a blocking action.

Thanks to Andrew for finding this and providing an initial fix.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

[INET]: Fix inet_diag register vs rcv race

The following race is possible when one cpu unregisters the handler
while other one is trying to receive a message and call this one:

CPU1:                                                 CPU2:
inet_diag_rcv()                                       inet_diag_unregister()
  mutex_lock(&inet_diag_mutex);
  netlink_rcv_skb(skb, &inet_diag_rcv_msg);
    if (inet_diag_table[nlh->nlmsg_type] ==
                               NULL) /* false handler is still registered */
    ...
    netlink_dump_start(idiagnl, skb, nlh,
                           inet_diag_dump, NULL);
           cb = kzalloc(sizeof(*cb), GFP_KERNEL);
                   /* sleep here freeing memory
                    * or preempt
                    * or sleep later on nlk->cb_mutex
                    */
                                                         spin_lock(&inet_diag_register_lock);
                                                         inet_diag_table[type] = NULL;
    ...                                                  spin_unlock(&inet_diag_register_lock);
                                                         synchronize_rcu();
                                                         /* CPU1 is sleeping - RCU quiescent
                                                          * state is passed
                                                          */
                                                         return;
    /* inet_diag_dump is finally called: */
    inet_diag_dump()
      handler = inet_diag_table[cb->nlh->nlmsg_type];
      BUG_ON(handler == NULL);
      /* OOPS! While we slept the unregister has set
       * handler to NULL :(
       */

Grep showed, that the register/unregister functions are called
from init/fini module callbacks for tcp_/dccp_diag, so it's OK
to use the inet_diag_mutex to synchronize manipulations with the
inet_diag_table and the access to it.

Besides, as Herbert pointed out, asynchronous dumps should hold
this mutex as well, and thus, we provide the mutex as cb_mutex one.

Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

[BRIDGE]: Properly dereference the br_should_route_hook

This hook is protected with the RCU, so simple

if (br_should_route_hook)
br_should_route_hook(...)

is not enough on some architectures.

Use the rcu_dereference/rcu_assign_pointer in this case.

Fixed Stephen's comment concerning using the typeof().

Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

[BRIDGE]: Lost call to br_fdb_fini() in br_init() error path

In case the br_netfilter_init() (or any subsequent call)
fails, the br_fdb_fini() must be called to free the allocated
in br_fdb_init() br_fdb_cache kmem cache.

Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

[UNIX]: EOF on non-blocking SOCK_SEQPACKET

I am not absolutely sure whether this actually is a bug (as in: I've got
no clue what the standards say or what other implementations do), but at
least I was pretty surprised when I noticed that a recv() on a
non-blocking unix domain socket of type SOCK_SEQPACKET (which is connection
oriented, after all) where the remote end has closed the connection
returned -1 (EAGAIN) rather than 0 to indicate end of file.

This is a test case:

| #include <sys/types.h>
| #include <unistd.h>
| #include <sys/socket.h>
| #include <sys/un.h>
| #include <fcntl.h>
| #include <string.h>
| #include <stdlib.h>
|
| int main(){
|  int sock;
|  struct sockaddr_un addr;
|  char buf[4096];
|  int pfds[2];
|
|  pipe(pfds);
|  sock=socket(PF_UNIX,SOCK_SEQPACKET,0);
|  addr.sun_family=AF_UNIX;
|  strcpy(addr.sun_path,"/tmp/foobar_testsock");
|  bind(sock,(struct sockaddr *)&addr,sizeof(addr));
|  listen(sock,1);
|  if(fork()){
|  close(sock);
|  sock=socket(PF_UNIX,SOCK_SEQPACKET,0);
|  connect(sock,(struct sockaddr *)&addr,sizeof(addr));
|  fcntl(sock,F_SETFL,fcntl(sock,F_GETFL)|O_NONBLOCK);
|  close(pfds[1]);
|  read(pfds[0],buf,sizeof(buf));
|  recv(sock,buf,sizeof(buf),0); // <-- this one
|  }else accept(sock,NULL,NULL);
|  exit(0);
| }

If you try it, make sure /tmp/foobar_testsock doesn't exist.

The marked recv() returns -1 (EAGAIN) on 2.6.23.9. Below you find a
patch that fixes that.

Signed-off-by: Florian Zumbiehl <florz@florz.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

[VLAN]: Fix nested VLAN transmit bug

Fix misbehavior of vlan_dev_hard_start_xmit() for recursive encapsulations.

Signed-off-by: Joonwoo Park <joonwpark81@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

[SUNGEM]: Fix NAPI regression with reset work

sungem's gem_reset_task() will unconditionally try to disable NAPI even
when it's called while the interface is not operating and hence the NAPI
struct isn't enabled. Make napi_disable() depend on gp->running.

Also removes a superfluous test of gp->running in the same function.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

[XFRM]: Fix leak of expired xfrm_states

The xfrm_timer calls __xfrm_state_delete, which drops the final reference
manually without triggering destruction of the state. Change it to use
xfrm_state_put to add the state to the gc list when we're dropping the
last reference. The timer function may still continue to use the state
safely since the final destruction does a del_timer_sync().

Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

[ATM]: [he] initialize lock and tasklet earlier

if you are lucky (unlucky?) enough to have shared interrupts, the
interrupt handler can be called before the tasklet and lock are ready
for use.

Signed-off-by: chas williams <chas@cmf.nrl.navy.mil>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

[IPV4]: Remove bogus ifdef mess in arp_process

The #ifdef's in arp_process() were not only a mess, they were also wrong
in the CONFIG_NET_ETHERNET=n and (CONFIG_NETDEV_1000=y or
CONFIG_NETDEV_10000=y) cases.

Since they are not required this patch removes them.

Also removed are some #ifdef's around #include's that caused compile
errors after this change.

Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

[SKBUFF]: Free old skb properly in skb_morph

The skb_morph function only freed the data part of the dst skb, but leaked
the auxiliary data such as the netfilter fields.  This patch fixes this by
moving the relevant parts from __kfree_skb to skb_release_all and calling
it in skb_morph.

It also makes kfree_skbmem static since it's no longer called anywhere else
and it now no longer does skb_release_data.

Thanks to Yasuyuki KOZAKAI for finding this problem and posting a patch for
it.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

[IPV4]: Fix memory leak in inet_hashtables.h when NUMA is on

The inet_ehash_locks_alloc() looks like this:

#ifdef CONFIG_NUMA
if (size > PAGE_SIZE)
x = vmalloc(...);
else
#endif
x = kmalloc(...);

Unlike it, the inet_ehash_locks_alloc() looks like this:

#ifdef CONFIG_NUMA
if (size > PAGE_SIZE)
vfree(x);
else
#else
kfree(x);
#endif

The error is obvious - if the NUMA is on and the size
is less than the PAGE_SIZE we leak the pointer (kfree is
inside the #else branch).

Compiler doesn't warn us because after the kfree(x) there's
a "x = NULL" assignment, so here's another (minor?) bug: we
don't set x to NULL under certain circumstances.

Boring explanation, I know... Patch explains it better.

Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

[IPSEC]: Temporarily remove locks around copying of non-atomic fields

The change 050f009e16f908932070313c1745d09dc69fd62b

[IPSEC]: Lock state when copying non-atomic fields to user-space

caused a regression.

Ingo Molnar reports that it causes a potential dead-lock found by the
lock validator as it tries to take x->lock within xfrm_state_lock while
numerous other sites take the locks in opposite order.

For 2.6.24, the best fix is to simply remove the added locks as that puts
us back in the same state as we've been in for years.  For later kernels
a proper fix would be to reverse the locking order for every xfrm state
user such that if x->lock is taken together with xfrm_state_lock then
it is to be taken within it.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

[TCP] MTUprobe: Cleanup send queue check (no need to loop)

The original code has striking complexity to perform a query
which can be reduced to a very simple compare.

FIN seqno may be included to write_seq but it should not make
any significant difference here compared to skb->len which was
used previously. One won't end up there with SYN still queued.

Use of write_seq check guarantees that there's a valid skb in
send_head so I removed the extra check.

Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Acked-by: John Heffner <jheffner@psc.edu>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

[TCP]: MTUprobe: receiver window & data available checks fixed

It seems that the checked range for receiver window check should
begin from the first rather than from the last skb that is going
to be included to the probe. And that can be achieved without
reference to skbs at all, snd_nxt and write_seq provides the
correct seqno already. Plus, it SHOULD account packets that are
necessary to trigger fast retransmit [RFC4821].

Location of snd_wnd < probe_size/size_needed check is bogus
because it will cause the other if() match as well (due to
snd_nxt >= snd_una invariant).

Removed dead obvious comment.

Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

[MAINTAINERS]: tlan list is subscribers-only

Your mail to 'Tlan-devel' with the subject

    drivers/net/tlan question

Is being held until the list moderator can review it for approval.

The reason it is being held:

    Post by non-member to a members-only list

Signed-off-by: Gabriel Craciunescu <nix.or.die@googlemail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

[SUNRPC]: Remove SPIN_LOCK_UNLOCKED

SPIN_LOCK_UNLOCKED is deprecated, use DEFINE_SPINLOCK instead

Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

[SUNRPC]: Make xprtsock.c:xs_setup_{udp,tcp}() static

xs_setup_{udp,tcp}() can now become static.

Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

[PFKEY]: Sending an SADB_GET responds with an SADB_GET

From: Charles Hardin <chardin@2wire.com>

Kernel needs to respond to an SADB_GET with the same message type to
conform to the RFC 2367 Section 3.1.5

Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

[IRDA]: Compilation for CONFIG_INET=n case

Found this occasionally.

The CONFIG_INET=n is hardly ever set, but if it is the
irlan_eth_send_gratuitous_arp() compilation should produce a
warning about unused variable in_dev.

Too pedantic? :)

Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

[IPVS]: Fix compiler warning about unused register_ip_vs_protocol

This is silly, but I have turned the CONFIG_IP_VS to m,
to check the compilation of one (recently sent) fix
and set all the CONFIG_IP_VS_PROTO_XXX options to n to
speed up the compilation.

In this configuration the compiler warns me about

  CC [M]  net/ipv4/ipvs/ip_vs_proto.o
net/ipv4/ipvs/ip_vs_proto.c:49: warning: 'register_ip_vs_protocol' defined but not used

Indeed. With no protocols selected there are no
calls to this function - all are compiled out with
ifdefs.

Maybe the best fix would be to surround this call with
ifdef-s or tune the Kconfig dependences, but I think that
marking this register function as __used is enough. No?

Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Acked-by: Simon Horman <horms@verge.net.au>
Signed-off-by: David S. Miller <davem@davemloft.net>

[ARP]: Fix arp reply when sender ip 0

Fix arp reply when received arp probe with sender ip 0.

Send arp reply with target ip address 0.0.0.0 and target hardware
address set to hardware address of requester. Previously sent reply
with target ip address and target hardware address set to same as
source fields.

Signed-off-by: Jonas Danielsson <the.sator@gmail.com>
Acked-by: Alexey Kuznetov <kuznet@ms2.inr.ac.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>

[IPV6] TCPMD5: Fix deleting key operation.

Due to the bug, refcnt for md5sig pool was leaked when
an user try to delete a key if we have more than one key.
In addition to the leakage, we returned incorrect return
result value for userspace.

This fix should close Bug #9418, reported by <ming-baini@163.com>.

Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

[IPV6] TCPMD5: Check return value of tcp_alloc_md5sig_pool().

Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

[IPV4] TCPMD5: Use memmove() instead of memcpy() because we have overlaps.

Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

[IPV4] TCPMD5: Omit redundant NULL check for kfree() argument.

Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

Merge branch 'fixes-davem' of git://git./linux/kernel/git/linville/wireless-2.6

ieee80211: Stop net_ratelimit/IEEE80211_DEBUG_DROP log pollution

if (net_ratelimit())
IEEE80211_DEBUG_DROP(...)

can pollute the logs with messages like:

printk: 1 messages suppressed.
printk: 2 messages suppressed.
printk: 7 messages suppressed.

if debugging information is disabled. These messages are printed by
net_ratelimit(). Add a wrapper to net_ratelimit() that takes into account
the log level, so that net_ratelimit() is called only when we really want
to print something.

Signed-off-by: Guillaume Chazarain <guichaz@yahoo.fr>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: add missing space in error message

Signed-off-by: Bruno Randolf <bruno@thinktube.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: fix allmulti/promisc behaviour

When an interface with promisc/allmulti bit is taken down,
the mac80211 state can become confused. This fixes it by
making mac80211 keep track of all *active* interfaces that
have the promisc/allmulti bit set in the sdata, we sync
the interface bit into sdata at set_multicast_list() time
so this works.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

mac80211: fix ieee80211_set_multicast_list

I recently experienced unexplainable behaviour with the b43
driver when I had broken firmware uploaded. The cause may have
been that promisc mode was not correctly enabled or disabled
and this bug may have been the cause.

Note how the values are compared later in the function so
just doing the & will result in the wrong thing being
compared and the test being false almost always.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

[NETFILTER]: Fix kernel panic with REDIRECT target.

When connection tracking entry (nf_conn) is about to copy itself it can
have some of its extension users (like nat) as being already freed and
thus not required to be copied.

Actually looking at this function I suspect it was copied from
nf_nat_setup_info() and thus bug was introduced.

Report and testing from David <david@unsolicited.net>.

[ Patrick McHardy states:

I now understand whats happening:

- new connection is allocated without helper
- connection is REDIRECTed to localhost
- nf_nat_setup_info adds NAT extension, but doesn't initialize it yet
- nf_conntrack_alter_reply performs a helper lookup based on the
   new tuple, finds the SIP helper and allocates a helper extension,
   causing reallocation because of too little space
- nf_nat_move_storage is called with the uninitialized nat extension

So your fix is entirely correct, thanks a lot :)  ]

Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Acked-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

[WIRELESS] WEXT: Fix userspace corruption on 64-bit.

On 64-bit systems sizeof(struct ifreq) is 8 bytes larger than
sizeof(struct iwreq).

For GET calls, the wireless extension code copies back into userspace
using sizeof(struct ifreq) but userspace and elsewhere only allocates
a "struct iwreq".  Thus, this copy writes past the end of the iwreq
object and corrupts whatever sits after it in memory.

Fix the copy_to_user() length.

This particularly hurts the compat case because the wireless compat
code uses compat_alloc_userspace() and right after this allocated
buffer is the current bottom of the user stack, and that's what gets
overwritten by the copy_to_user() call.

Signed-off-by: David S. Miller <davem@davemloft.net>

[IRDA]: Add missing "space"

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

[SUNRPC]: Add missing "space"

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

[SCTP]: Add missing "space"

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

[IPV6]: Add missing "space"

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

[BRIDGE]: Add missing "space"

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

[IPV4]: Add missing "space"

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

[DCCP]: Add missing "space"

Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

[TCP]: Problem bug with sysctl_tcp_congestion_control function

From: "Sam Jansen" <sjansen@google.com>

sysctl_tcp_congestion_control seems to have a bug that prevents it
from actually calling the tcp_set_default_congestion_control
function. This is not so apparent because it does not return an error
and generally the /proc interface is used to configure the default TCP
congestion control algorithm.  This is present in 2.6.18 onwards and
probably earlier, though I have not inspected 2.6.15--2.6.17.

sysctl_tcp_congestion_control calls sysctl_string and expects a successful
return code of 0. In such a case it actually sets the congestion control
algorithm with tcp_set_default_congestion_control. Otherwise, it returns the
value returned by sysctl_string. This was correct in 2.6.14, as sysctl_string
returned 0 on success. However, sysctl_string was updated to return 1 on
success around about 2.6.15 and sysctl_tcp_congestion_control was not updated.
Even though sysctl_tcp_congestion_control returns 1, do_sysctl_strategy
converts this return code to '0', so the caller never notices the error.

Signed-off-by: David S. Miller <davem@davemloft.net>

[TCP] MTUprobe: fix potential sk_send_head corruption

When the abstraction functions got added, conversion here was
made incorrectly. As a result, the skb may end up pointing
to skb which got included to the probe skb and then was freed.
For it to trigger, however, skb_transmit must fail sending as
well.

Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Signed-off-by: David S. Miller <davem@davemloft.net>

[PKTGEN]: Fix double unlock of xfrm_state->lock

The pktgen_output_ipsec() function can unlock this lock twice
due to merged error and plain paths. Remove one of the calls
to spin_unlock.

Other possible solution would be to place "return 0" right
after the first unlock, but at this place the err is known
to be 0, so these solutions are the same except for this one
makes the code shorter.

Signed-off-by: Pavel Emelyanov <xemul@openvz.org>
Signed-off-by: David S. Miller <davem@davemloft.net>

[IPVS]: Move remaining sysctl handlers over to CTL_UNNUMBERED

Switch the remaining IPVS sysctl entries over to to use CTL_UNNUMBERED,
I stronly doubt that anyone is using the sys_sysctl interface to
these variables.

Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: David S. Miller <davem@davemloft.net>

[IPVS]: Fix sysctl warnings about missing strategy in schedulers

sysctl table check failed: /net/ipv4/vs/lblc_expiration .3.5.21.19 Missing strategy
[...]
sysctl table check failed: /net/ipv4/vs/lblcr_expiration .3.5.21.20 Missing strategy

Switch these entried over to use CTL_UNNUMBERED as clearly
the sys_syscal portion wasn't working.

This is along the same lines as Christian Borntraeger's patch that fixes
up entries with no stratergy in net/ipv4/ipvs/ip_vs_ctl.c

Signed-off-by: Simon Horman <horms@verge.net.au>
Signed-off-by: David S. Miller <davem@davemloft.net>

[IPVS]: Fix sysctl warnings about missing strategy

Running the latest git code I get the following messages during boot:
sysctl table check failed: /net/ipv4/vs/drop_entry .3.5.21.4 Missing strategy
[...]
sysctl table check failed: /net/ipv4/vs/drop_packet .3.5.21.5 Missing strategy
[...]
sysctl table check failed: /net/ipv4/vs/secure_tcp .3.5.21.6 Missing strategy
[...]
sysctl table check failed: /net/ipv4/vs/sync_threshold .3.5.21.24 Missing strategy

I removed the binary sysctl handler for those messages and also removed
the definitions in ip_vs.h. The alternative would be to implement a
proper strategy handler, but syscall sysctl is deprecated.

There are other sysctl definitions that are commented out or work with
the default sysctl_data strategy. I did not touch these.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Acked-by: Simon Horman <horms@verge.net.au>
Signed-off-by: David S. Miller <davem@davemloft.net>

[TCP]: Fix TCP header misalignment

Indeed my previous change to alloc_pskb has made it possible
for the TCP header to be misaligned iff the MTU is not a multiple
of 4 (and less than a page).  So I suspect the optimised IPsec
MTU calculation is giving you just such an MTU :)

This patch fixes it by changing alloc_pskb to make sure that
the size is at least 32-bit aligned.  This does not cause the
problem fixed by the previous patch because max_header is always
32-bit aligned which means that in the SG/NOTSO case this will
be a no-op.

I thought about putting this in the callers but all the current
callers are from TCP.  If and when we get a non-TCP caller we
can always create a TCP wrapper for this function and move the
alignment over there.

Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>

[NET]: Corrects a bug in ip_rt_acct_read()

It seems that stats of cpu 0 are counted twice, since
for_each_possible_cpu() is looping on all possible cpus, including 0

Before percpu conversion of ip_rt_acct, we should also remove the
assumption that CPU 0 is online (or even possible)

Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

rt2x00: Request usb_maxpacket() once

The usb max packet size won't change during the
device's presence. We should store it in a
variable inside rt2x00dev and use that.
This should also fix a division error when the
device is being hot-unplugged while a frame is
being send out.

Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

Merge branch 'master' of git://git./linux/kernel/git/x86/linux-2.6-x86

* 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86:
  x86: simplify "make ARCH=x86" and fix kconfig all.config
  x86: reboot fixup for wrap2c board
  x86: check boundary in count setup resource
  x86: fix reboot with no keyboard attached
  x86: add hpet sanity checks
  x86: on x86_64, correct reading of PC RTC when update in progress in time_64.c
  x86: fix freeze in x86_64 RTC update code in time_64.c
  ntp: fix typo that makes sync_cmos_clock erratic
  Remove x86 merge artifact from top Makefile
  x86: fixup cpu_info array conversion
  x86: show cpuinfo only for online CPUs
  x86: fix cpu-hotplug regression
  x86: ignore the sys_getcpu() tcache parameter
  x86: voyager use correct header file name
  x86: fix smp init sections
  x86: fix voyager_cat_init section
  x86: fix bogus memcpy in es7000_check_dsdt()

x86: simplify "make ARCH=x86" and fix kconfig all.config

Simplify "make ARCH=x86" and fix kconfig so we again can set 64BIT in
all.config.

For a fix the diffstat is nice:
 6 files changed, 3 insertions(+), 36 deletions(-)

The patch reverts these commits:
 - 0f855aa64b3f63d35a891510cf7db932a435c116 ("kconfig: add helper to set
   config symbol from environment variable")
 - 2a113281f5cd2febbab21a93c8943f8d3eece4d3 ("kconfig: use $K64BIT to
   set 64BIT with all*config targets")

Roman Zippel pointed out that kconfig supported string compares so
the additional complexity introduced by the above two patches were
not needed.

With this patch we have following behaviour:

  # make {allno,allyes,allmod,rand}config [ARCH=...]
  option \ host arch      | 32bit         | 64bit
  =====================================================
  ./.                     | 32bit         | 64bit
  ARCH=x86                | 32bit         | 32bit
  ARCH=i386               | 32bit         | 32bit
  ARCH=x86_64             | 64bit         | 64bit

The general rule are that ARCH= and native architecture takes
precedence over the configuration.

So make ARCH=i386 [whatever] will always build a 32-bit kernel
no matter what the configuration says.  The configuration will
be updated to 32-bit if it was configured to 64-bit and the
other way around.

This behaviour is consistent with previous behaviour so no
suprises here.

make ARCH=x86 will per default result in a 32-bit kernel but as
the only ARCH= value x86 allow the user to select between 32-bit
and 64-bit using menuconfig.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Roman Zippel <zippel@linux-m68k.org>
Cc: Andreas Herrmann <aherrman@arcor.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

x86: simplify "make ARCH=x86" and fix kconfig all.config

Simplify "make ARCH=x86" and fix kconfig so we again
can set 64BIT in all.config.

For a fix the diffstat is nice:
 6 files changed, 3 insertions(+), 36 deletions(-)

The patch reverts these commits:
0f855aa64b3f63d35a891510cf7db932a435c116
-> kconfig: add helper to set config symbol from environment variable

2a113281f5cd2febbab21a93c8943f8d3eece4d3
-> kconfig: use $K64BIT to set 64BIT with all*config targets

Roman Zippel pointed out that kconfig supported string
compares so the additional complexity introduced by the
above two patches were not needed.

With this patch we have following behaviour:

# make {allno,allyes,allmod,rand}config [ARCH=...]
option \ host arch      | 32bit         | 64bit
=====================================================
./.                     | 32bit         | 64bit
ARCH=x86                | 32bit         | 32bit
ARCH=i386               | 32bit         | 32bit
ARCH=x86_64             | 64bit         | 64bit

The general rule are that ARCH= and native architecture
takes precedence over the configuration.
So make ARCH=i386 [whatever] will always build a 32-bit
kernel no matter what the configuration says.
The configuration will be updated to 32-bit if it was
configured to 64-bit and the other way around.

This behaviour is consistent with previous behaviour so
no suprises here.

make ARCH=x86 will per default result in a 32-bit kernel
but as the only ARCH= value x86 allow the user to select
between 32-bit and 64-bit using menuconfig.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Roman Zippel <zippel@linux-m68k.org>
Cc: Andreas Herrmann <aherrman@arcor.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>

x86: reboot fixup for wrap2c board

Needed to make the wireless board, WRAP2C reboot.

Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

x86: check boundary in count setup resource

need to check info->res_num less than PCI_BUS_NUM_RESOURCES, so
info->bus->resource[info->res_num] = res will not beyond of bus resource
array when acpi returns too many resource entries.

Signed-off-by: Yinghai Lu <yinghai.lu@sun.com>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Cc: Gary Hade <gary.hade@us.ibm.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

x86: fix reboot with no keyboard attached

Attempt to fix http://bugzilla.kernel.org/show_bug.cgi?id=8378

Hiroto Shibuya wrote to tell me that he has a VIA EPIA-EK10000 which
suffers from the reboot problem when no keyboard is attached.  My first
patch works for him:

  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=59f4e7d572980a521b7bdba74ab71b21f5995538

But the latest patch does not work for him :

  http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8b93789808756bcc1e5c90c99f1b1ef52f839a51

We found that it was necessary to also set the "disable keyboard" flag in
the command byte, as the first patch was doing.  The second patch tries to
minimally modify the command byte, but it is not enough.

Please consider this simple one-line patch to help people with low end VIA
motherboards reboot when no keyboard is attached.  Hiroto Shibuya has
verified that this works for him (as I no longer have an afflicted
machine).

Additional discussion:

Note that original patch from Truxton DOES
disable keyboard and this has been in main tree since 2.6.14, thus it must have
quite a bit of air time already.

http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.14.y.git;a=commit;h=59f4e7d572980a521b7bdba74ab71b21f5995538

Note that he only mention "System flag" in the description and comment, but
in the code, "disable keyboard" flag is set.

  outb(0x14, 0x60);       /* set "System flag" */

In 2.6.23, he made a change to read the current byte and then mask the flags,
but along this change,  he only set the "System flag" and dropped the setting
of "disable keyboard" flag.

http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=commit;h=8b93789808756bcc1e5c90c99f1b1ef52f839a51

   outb(cmd | 0x04, 0x60); /* set "System flag" */

So my request is to restore the setting of disable keyboard flag which has been
there since 2.6.14 but disappeared in 2.6.23.

Cc: Lee Garrett <lee-in-berlin@web.de>
Cc: "Hiroto Shibuya" <hiroto.shibuya@gmail.com>
Cc: Natalie Protasevich <protasnb@gmail.com>
Cc: Dmitry Torokhov <dtor@mail.ru>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Aristeu Rozanski <aris@ruivo.org>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

x86: add hpet sanity checks

Some BIOSes advertise HPET at 0x0. We really do no want to
allocate a resource there. Check for it and leave early.

Other BIOSes tell us the HPET is at 0xfed0000000000000
instead of 0xfed00000. Add a check and fix it up with a warning
on user request.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

x86: on x86_64, correct reading of PC RTC when update in progress in time_64.c

Correct potentially unstable PC RTC time register reading in time_64.c

Stop the use of an incorrect technique for reading the standard PC RTC
timer, which is documented to "disconnect" time registers from the bus
while updates are in progress.  The use of UIP flag while interrupts
are disabled to protect a 244 microsecond window is one of the
Motorola spec sheet's documented ways to read the RTC time registers
reliably.

tglx: removed locking changes from original patch, as they gain nothing
(read_persistent_clock is only called during boot, suspend, resume - so
no hot path affected) and conflict with the paravirt locking scheme
(see 32bit code), which we do not want to complicate for no benefit.

Signed-off-by: David P. Reed <dpreed@reed.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

x86: fix freeze in x86_64 RTC update code in time_64.c

Fix hard freeze on x86_64 when the ntpd service calls
update_persistent_clock()

A repeatable but randomly timed freeze has been happening in Fedora 6
and 7 for the last year, whenever I run the ntpd service on my AMD64x2
HP Pavilion dv9000z laptop.  This freeze is due to the use of
spin_lock(&rtc_lock) under the assumption (per a bad comment) that
set_rtc_mmss is called only with interrupts disabled.  The call from
ntp.c to update_persistent_clock is made with interrupts enabled.

Signed-off-by: David P. Reed <dpreed@reed.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

ntp: fix typo that makes sync_cmos_clock erratic

Fix a typo in ntp.c that has caused updating of the persistent (RTC)
clock when synced to NTP to behave erratically.

When debugging a freeze that arises on my AMD64 machines when I
run the ntpd service, I added a number of printk's to monitor the
sync_cmos_clock procedure.  I discovered that it was not syncing to
cmos RTC every 11 minutes as documented, but instead would keep trying
every second for hours at a time.  The reason turned out to be a typo
in sync_cmos_clock, where it attempts to ensure that
update_persistent_clock is called very close to 500 msec. after a 1
second boundary (required by the PC RTC's spec). That typo referred to
"xtime" in one spot, rather than "now", which is derived from "xtime"
but not equal to it.  This makes the test erratic, creating a
"coin-flip" that decides when update_persistent_clock is called - when
it is called, which is rarely, it may be at any time during the one
second period, rather than close to 500 msec, so the value written is
needlessly incorrect, too.

Signed-off-by: David P. Reed
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

Remove x86 merge artifact from top Makefile

The x86 merge modified the tags target to handle the two separate
source directories. Remove it now that i386/x86_64 are gone completely.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

x86: fixup cpu_info array conversion

92cb7612aee39642d109b8d935ad265e602c0563 sets cpu_info->cpu_index to zero
for no reason. Referencing cpu_info->cpu_index now points always to CPU#0,
which is apparently not what we want.

Remove it.

Spotted-by: Zou Nan hai <nanhai.zou@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

x86: show cpuinfo only for online CPUs

Fix regressions introduced with 92cb7612aee39642d109b8d935ad265e602c0563.

It can happen that cpuinfo is displayed for CPUs that are not online or
even worse for CPUs not present at all. As an example, following was
shown for a "second" CPU of a single core K8 variant:

    processor       : 0
    vendor_id       : unknown
    cpu family      : 0
    model           : 0
    model name      : unknown
    stepping        : 0
    cache size      : 0 KB
    fpu             : yes
    fpu_exception   : yes
    cpuid level     : 0
    wp              : yes
    flags           :
    bogomips        : 0.00
    clflush size    : 0
    cache_alignment : 0
    address sizes   : 0 bits physical, 0 bits virtual
    power management:

Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

x86: fix cpu-hotplug regression

Commit d435d862baca3e25e5eec236762a43251b1e7ffc
("cpu hotplug: mce: fix cpu hotplug error handling")
changed the error handling in mce_cpu_callback.

In cases where not all CPUs are brought up during
boot (e.g. using maxcpus and additional_cpus parameters)
mce_cpu_callback now returns NOTFIY_BAD because
for such CPUs cpu_data is not completely filled when
the notifier is called. Thus mce_create_device fails right
at its beginning:

        if (!mce_available(&cpu_data[cpu]))
                return -EIO;

As a quick fix I suggest to check boot_cpu_data for MCE.

To reproduce this regression:

(1) boot with maxcpus=2 addtional_cpus=2 on a 4 CPU x86-64 system
(2) # echo 1 >/sys/devices/system/cpu/cpu2/online
  -bash: echo: write error: Invalid argument

dmesg shows:

_cpu_up: attempt to bring up CPU 2 failed

Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

x86: ignore the sys_getcpu() tcache parameter

dont use the vgetcpu tcache - it's causing problems with tasks
migrating, they'll see the old cache up to a jiffy after the
migration, further increasing the costs of the migration.

In the worst case they see a complete bogus information from
the tcache, when a sys_getcpu() call "invalidated" the cache
info by incrementing the jiffies _and_ the cpuid info in the
cache and the following vdso_getcpu() call happens after
vdso_jiffies have been incremented.

Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Ulrich Drepper <drepper@redhat.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

x86: voyager use correct header file name

Fix header file name for Voyager build.

In file included from arch/x86/kernel/setup_32.c:61:
include/asm-x86/mach-voyager/setup_arch.h:2:26: error: asm/setup_32.h: No such file or directory
make[1]: *** [arch/x86/kernel/setup_32.o] Error 1

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

x86: fix smp init sections

Fix Voyager section mismatch due to using __devinit instead of __cpuinit.

WARNING: vmlinux.o(.text+0xd943): Section mismatch: reference to .init.text:init_gdt (between 'voyager_smp_prepare_boot_cpu' and 'smp_vic_cmn_interrupt')

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

x86: fix voyager_cat_init section

Fix Voyager section mismatches:  voyager_cat_init() should be __init.

WARNING: vmlinux.o(.text+0xee83): Section mismatch: reference to .init.data:eprom_buf (between 'voyager_cat_init' and 'aes_enc_blk')
WARNING: vmlinux.o(.text+0xeea6): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk')
WARNING: vmlinux.o(.text+0xeeac): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk')
WARNING: vmlinux.o(.text+0xeeb2): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk')
WARNING: vmlinux.o(.text+0xef4c): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk')
WARNING: vmlinux.o(.text+0xef56): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk')
WARNING: vmlinux.o(.text+0xf10f): Section mismatch: reference to .init.data:eprom_buf (between 'voyager_cat_init' and 'aes_enc_blk')
WARNING: vmlinux.o(.text+0xf13b): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk')
WARNING: vmlinux.o(.text+0xf14b): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk')
WARNING: vmlinux.o(.text+0xf159): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk')
WARNING: vmlinux.o(.text+0xf1b1): Section mismatch: reference to .init.data:eprom_buf (between 'voyager_cat_init' and 'aes_enc_blk')
WARNING: vmlinux.o(.text+0xf1bb): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk')
WARNING: vmlinux.o(.text+0xf1c1): Section mismatch: reference to .init.data:eprom_buf (between 'voyager_cat_init' and 'aes_enc_blk')
WARNING: vmlinux.o(.text+0xf1c7): Section mismatch: reference to .init.data:eprom_buf (between 'voyager_cat_init' and 'aes_enc_blk')
WARNING: vmlinux.o(.text+0xf1e6): Section mismatch: reference to .init.data: (between 'voyager_cat_init' and 'aes_enc_blk')

Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

x86: fix bogus memcpy in es7000_check_dsdt()

es7000_check_dst() contains a memcpy from 0, which probably should have been
a memset. Remove it and check the retunr value from acpi_get_table_header.

Noticed by: Joe Perches <joe@perches.com>

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

Linux 2.6.24-rc3

Merge branch 'for-linus' of git://git./linux/kernel/git/jmorris/selinux-2.6

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/selinux-2.6:
  SELinux: return EOPNOTSUPP not ENOTSUPP

Merge branch 'for-linus' of /home/rmk/linux-2.6-arm

* 'for-linus' of master.kernel.org:/home/rmk/linux-2.6-arm:
  [ARM] 4638/1: pxa: use PXA3xx specific macros to define clks
  [ARM] remove useless setting of VM_RESERVED

Merge /pub/scm/linux/kernel/git/davej/cpufreq

* master.kernel.org:/pub/scm/linux/kernel/git/davej/cpufreq:
  [CPUFREQ] Fix up whitespace in conservative governor.
  [CPUFREQ] Make cpufreq_conservative handle out-of-sync events properly
  [CPUFREQ] architectural pstate driver for powernow-k8

SELinux: return EOPNOTSUPP not ENOTSUPP

ENOTSUPP is not a valid error code in the kernel (it is defined in some
NFS internal error codes and has been improperly used other places).  In
the !CONFIG_SECURITY_SELINUX case though it is possible that we could
return this from selinux_audit_rule_init().  This patch just returns the
userspace valid EOPNOTSUPP.

Signed-off-by: Eric Paris <eparis@redhat.com>
Signed-off-by: James Morris <jmorris@namei.org>

[ARM] 4638/1: pxa: use PXA3xx specific macros to define clks

PXA3xx uses its own clk_pxa3xx_cken_ops, modify the code to use the
PXA3xx specific macros to define its clocks

Signed-off-by: eric miao <eric.miao@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

dirty page balancing: Get rid of broken unmapped_ratio logic

This code harks back to the days when we didn't count dirty mapped
pages, which led us to try to balance the number of dirty unmapped pages
by how much unmapped memory there was in the system.

That makes no sense any more, since now the dirty counts include the
mapped pages.  Not to mention that the math doesn't work with HIGHMEM
machines anyway, and causes the unmapped_ratio to potentially turn
negative (which we do catch thanks to clamping it at a minimum value,
but I mention that as an indication of how broken the code is).

The code also was written at a time when the default dirty ratio was
much larger, and the unmapped_ratio logic effectively capped that large
dirty ratio a bit.  Again, we've since lowered the dirty ratio rather
aggressively, further lessening the point of that code.

Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Merge branch 'master' of /linux/kernel/git/davem/net-2.6

* 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6:
  [NETFILTER]: Fix NULL pointer dereference in nf_nat_move_storage()
  [SUNHME]: VLAN support for sunhme
  [CHELSIO]: Fix skb->dev setting.
  [NETFILTER]: fix compat_nf_sockopt typo
  [INET]: Fix potential kfree on vmalloc-ed area of request_sock_queue
  [VIA_VELOCITY]: Don't oops on MTU change.
  iwl4965: fix not correctly dealing with hotunplug
  rt2x00: Fix chipset revision validation
  iwl3945: place CCK rates in front of OFDM for supported rates
  mac80211: Fix queuing of scan containing a SSID

Merge branch 'upstream' of git://ftp.linux-mips.org/upstream-linus

* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus:
  [MIPS] N32 needs to use the compat version of sys_nfsservctl.
  [MIPS] irq_cpu: use handle_percpu_irq handler to avoid dropping interrupts.
  [MIPS] Sibyte: Fix name of clocksource.
  [MIPS] SNI: s/achknowledge/acknowledge/
  [MIPS] Makefile: Fix canonical system names
  [MIPS] vpe: handle halting TCs in an errata safe way.
  [MIPS] Sibyte: Stop timers before programming next even.
  [MIPS] Sibyte: Increase minimum oneshot timer interval to two ticks.
  [MIPS] Lasat: Fix overlap of interrupt number ranges.
  [MIPS] SNI PCIT CPLUS: workaround for b0rked irq wiring of onboard PCI bus 1
  [MIPS] Fix shadow register support.
  [MIPS] Change get_cycles to always return 0.
  [MIPS] Fix typo in R3000 TRACE_IRQFLAGS code
  [MIPS] Sibyte: Replace use of removed IO_SPACE_BASE with IOADDR.
  [MIPS] iounmap if in vr41xx_pciu_init() pci clock is over 33MHz
  [MIPS] BCM1480: Remove duplicate acknowledge of timer interrupt.
  [MIPS] Sibyte: pin timer interrupt to their cores.
  [MIPS] Qemu: Add early printk, your friend in a cold night.
  [MIPS] Convert reference to mem_map to pfn_to_page().
  [MIPS] Sibyte: resurrect old cache hack.

[NETFILTER]: Fix NULL pointer dereference in nf_nat_move_storage()

Reported by Chuck Ebbert as:

https://bugzilla.redhat.com/show_bug.cgi?id=259501#c14

This routine is called each time hash should be replaced, nf_conn has
extension list which contains pointers to connection tracking users
(like nat, which is right now the only such user), so when replace takes
place it should copy own extensions. Loop above checks for own
extension, but tries to move higer-layer one, which can lead to above
oops.

Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>

[SUNHME]: VLAN support for sunhme

This patch enables VLAN support on sunhme by increasing BMAC_TXMAX/BMAC_RXMAX
and allocating extra space via skb_put for the VLAN header.

Signed-off-by: Chris Poon <dev-null@telus.net>
Signed-off-by: David S. Miller <davem@davemloft.net>

[MIPS] N32 needs to use the compat version of sys_nfsservctl.

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

[MIPS] irq_cpu: use handle_percpu_irq handler to avoid dropping interrupts.

This matters to any sort of device that is wired to one of the CPU
interrupt pins on an SMP system.  Typically the scenario is most easily
triggered with the count/compare timer interrupt where the same interrupt
number and thus irq_desc is used on each processor.

   CPU A CPU B

   do_IRQ()
   generic_handle_irq()
   handle_level_irq()
   spin_lock(desc_lock)
   set IRQ_INPROGRESS
   spin_unlock(desc_lock)
do_IRQ()
generic_handle_irq()
handle_level_irq()
spin_lock(desc_lock)
IRQ_INPROGRESS set => bail out
   spin_lock(desc_lock)
   clear IRQ_INPROGRESS
   spin_unlock(desc_lock)

In case of the cp0 compare interrupt this means the interrupt will be
acked and not handled or re-armed on CPU b, so there won't be any timer
interrupt until the count register wraps around.

With kernels 2.6.20 ... 2.6.23 we usually were lucky that things were just
working right on VSMP because the count registers are synchronized on
bootup so it takes something that disables interrupts for a long time on
one processor to trigger this one.

For scenarios where an interrupt is multicasted or broadcasted over several
CPUs the existing code was safe and the fix will break it.  There is no
way to know in the interrupt controller code because it is abstracted from
the platform code.  I think we do not have such a setup currently, so this
should be ok.

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>