I still think using BUILD_BUG_ON() is unacceptable, especially given how
vague the error message was.
Signed-off-by: NKyle McMartin <kyle@parisc-linux.org>
[ And I already removed gthe BUILD_BUG_ON() in the previous commit ]
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This reverts commit ee3ce191, since it
broke on at least ARM, MIPS and PA-RISC due to complicated header file
dependencies.

Conflicts in include/linux/spinlock.h (due to the "nested" variety
fixes) fixed up by hand.

Cc: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Kyle McMartin <kyle@parisc-linux.org>
Cc: Russell King <rmk+lkml@arm.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

* master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6:
  [XFRM] STATE: Fix to respond error to get operation if no matching entry exists.
  [NET]: Re-fix of doc-comment in sock.h
  [6PACK]: Masking bug in 6pack driver.
  [NET]: Fix kfifo_alloc() error check.
  [UDP]: Make udp_encap_rcv use pskb_may_pull
  [NETFILTER]: H.323 conntrack: fix crash with CONFIG_IP_NF_CT_ACCT

The tda10086 causes an oops (divide by zero) if a zero symbol rate is used;
this prevents this.
Signed-off-by: NAndrew de Quincey <adq_dvb@lidskialf.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

The old code would accept any device on the same i2c address as the
saa711x chips as an saa711x. However, this fails with saa717x chips,
which use that same address and so are misdetected as a saa7111. Now
check whether the chip is really a saa711x model.
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

The patch fix bug 5748.
Signed-off-by: NLuca Risolia <luca.risolia@studio.unibo.it>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Sparse noticed a lock imbalance in read_from_buf(). Further inspection shows
that the lock should not be held when the function exits.
This adds a spin_unlock_irqrestore(), so that every exit path of the
read_from_buf() function is consistent. The unlock was missing on an error
path.
Signed-off-by: NIra W. Snyder <devel@irasnyder.com>
Signed-off-by: NHans J. Koch <koch@hjk-az.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Spotted by coverity/Adrian Bunk.
Signed-off-by: NAndrew de Quincey <adq_dvb@lidskialf.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

New module parameter diseqc_method for cards with subsystem-id 13c2:1003.
- 0: unreliable method, can be used by all board revisions (default)
- 1: reliable method, works for newer board layouts only
The parameter has no effect for cards with other subsystem-ids.
Signed-off-by: NOliver Endriss <o.endriss@gmx.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

Fixes to DISEQC on these cards inadvertently broke normal tone/voltage
signalling. This restores the necessary function.
Signed-off-by: NAndrew de Quincey <adq_dvb@lidskialf.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>

When application uses XFRM_MSG_GETSA to get state entry through
netlink socket and kernel has no matching one, the application expects
reply message with error status by kernel.

Kernel doesn't send the message back in the case of Mobile IPv6 route
optimization protocols (i.e. routing header or destination options
header). This is caused by incorrect return code "0" from
net/xfrm/xfrm_user.c(xfrm_user_state_lookup) and it makes kernel skip
to acknowledge at net/netlink/af_netlink.c(netlink_rcv_skb).

This patch fix to reply ESRCH to application.
Signed-off-by: NMasahide NAKAMURA <nakam@linux-ipv6.org>
Signed-off-by: NTAKAMIYA Noriaki <takamiya@po.ntts.co.jp>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Restoring old, correct comment for sk_filter_release, moving it to
where it should actually be, and changing new comment into proper
comment for sk_filter_rcu_free, where it actually makes sense.

The original fix submitted for this on Oct 23 mistakenly documented
the wrong function.
Signed-off-by: NPaul Bonser <misterpib@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Looks like a broken masking to me, binary not is used where bitwise
not was intended.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The return value of kfifo_alloc() should be checked by IS_ERR().
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Make udp_encap_rcv use pskb_may_pull

IPsec with NAT-T breaks on some notebooks using the latest e1000 chipset,
when header split is enabled. When receiving sufficiently large packets, the
driver puts everything up to and including the UDP header into the header
portion of the skb, and the rest goes into the paged part. udp_encap_rcv
forgets to use pskb_may_pull, and fails to decapsulate it. Instead, it
passes it up it to the IKE daemon.
Signed-off-by: NOlaf Kirch <okir@suse.de>
Signed-off-by: NJean Delvare <jdelvare@suse.de>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

H.323 connection tracking code calls ip_ct_refresh_acct() when
processing RCFs and URQs but passes NULL as the skb.
When CONFIG_IP_NF_CT_ACCT is enabled, the connection tracking core tries
to derefence the skb, which results in an obvious panic.
A similar fix was applied on the SIP connection tracking code some time
ago.
Signed-off-by: NFaidon Liambotis <paravoid@debian.org>
Signed-off-by: NPatrick McHardy <kaber@trash.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Reimplement execvp for our purposes - after we call fork() it is fundamentally
unsafe to use the kernel allocator - current is not valid there.  So we simply
pass to our modified execvp() a preallocated buffer.  This fixes a real bug
and works very well in testing (I've seen indirectly warning messages from the
forked thread - they went on the pipe connected to its stdout and where read
as a number by UML, when calling read_output().  I verified the obtained
number corresponded to "BUG:").

The added use of __cant_sleep() is not a new bug since __cant_sleep() is
already used in the same function - passing an atomicity parameter would be
better but it would require huge change, stating that this function must not
be called in atomic context and can sleep is a better idea (will make sure of
this gradually).
Signed-off-by: NPaolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Acked-by: NJeff Dike <jdike@addtoit.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This is a bug.  When checking for ati_remote->outbuf we free freeing
ati_remote->inbuf so we end up freeing ati_remote->inbuf twice.

Also the checks for 'ati_remote->inbuf != NULL' and 'ati_remote->outbuf !=
NULL' are redundant as usb_buffer_free() does this.
Signed-off-by: NMariusz Kozlowski <m.kozlowski@tuxland.pl>
Acked-by: NGreg KH <greg@kroah.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Introduce spin_lock_irqsave_nested(); implementation from:
 http://lkml.org/lkml/2006/6/1/122
Patch from:
 http://lkml.org/lkml/2006/9/13/258

[akpm@osdl.org: two compile fixes]
Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NJiri Kosina <jikos@jikos.cz>
Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
Acked-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Make it break or warn if you pass to spin_lock_irqsave() and friends
something different from "unsigned long flags;".  Suprisingly large amount
of these was caught by recent commit
c53421b1 and others.

Idea is largely from FRV typechecking. Suggestions from Andrew Morton.
All stupid typos in first version fixed.

Passes allmodconfig on i386, x86_64, alpha, arm as well as my usual config.

Note #1: checking with sparse is still needed, because a driver can save
	 and pass around flags or something. So far patch is very intrusive.
Note #2: techically, we should break only if
		sizeof(flags) < sizeof(unsigned long),
	 however, the more pain for getting suspicious code into kernel,
	 the better.
Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The return value of platform_device_register_simple() should be checked by
IS_ERR().

This patch also fix misc_register() error case.  Because misc_register()
returns error code.

Cc: Sebastien Bouchard <sebastien.bouchard@ca.kontron.com>
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The return value of copy_process() should be checked by IS_ERR().
Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This patch removes a module_exit function that sgiioc4 should not have had.

It seems that the IDE layer doesn't support submodule unloading.  sgiioc4 was
the only driver in drivers/ide/pci that had an exit function.  After an
unload, the devices would stay around and the next attempt to reference would
crash...
Signed-off-by: NJeremy Higdon <jeremy@sgi.com>
Acked-by: N"Bartlomiej Zolnierkiewicz" <bzolnier@gmail.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

On Mon, 13 Nov 2006, Phil Oester wrote:
> In commit 350b5b76, the default menuconfig
> color scheme was changed to bluetitle.  This breaks the highlighting
> of the selected item for me with TERM=vt100.  The only way I can see
> which item is selected is via:
>
>     make MENUCONFIG_COLOR=mono menuconfig
>
> Which restores the pre-2.6.19 white on black highlighting.

Fix.

Cc: Phil Oester <kernel@linuxace.com>
Signed-off-by: NRoman Zippel <zippel@linux-m68k.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Fixes a segfault reported by Randy.

Cc: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NRoman Zippel <zippel@linux-m68k.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

dev->devt_attr is allocated in device_add() but it is never freed in
device_del() in the drivers/base/core.c file (reported by kmemleak).
Signed-off-by: NCatalin Marinas <catalin.marinas@gmail.com>
Acked-by: NGreg KH <greg@kroah.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

One reiserfs_warning() call uses %lu, but doesn't supply what to print.
Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The correct order is: NULL check before dereference

This was a guaranteed NULL dereference with debugging enabled since
rs5c372_sysfs_show_osc() does actually pass NULL...

Spotted by the Coverity checker.
Signed-off-by: NAdrian Bunk <bunk@stusta.de>
Acked-by: NAlessandro Zummo <a.zummo@towertech.it>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

I got a lockdep warning when running "rtctest" so I though it'd be good
to see what was up.

 - The warning was for rtc->irq_task_lock, gotten from rtc_update_irq()
   by irq handlerss ... but in a handful of other cases, grabbed without
   blocking IRQs.

 - Some callers to rtc_update_irq() were not ensuring IRQs were blocked,
   yet the routine expects that; make sure all callers block IRQs.

It would appear that RTC API tests haven't been part of anyone's kernel
regression test suite recently, at least not with lockdep running.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Acked-by: NAlessandro Zummo <a.zummo@towertech.it>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

The RTC framework has an irq_set_freq() method that should be used to manage
the periodic IRQ frequency, but the current ioctl logic doesn't know how to do
that.  This patch teaches it how.

This means that drivers implementing irq_set_freq() will automatically support
RTC_IRQP_{READ,SET} ioctls; that logic doesn't need duplication within the
driver.

[akpm@osdl.org: export rtc_irq_set_freq]
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Acked-by: NAlessandro Zummo <a.zummo@towertech.it>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

This updates the RTC documentation to summarize the two APIs now available:
the old PC/AT one, and the new RTC class drivers.  It also updates the
included "rtctest.c" file to better meet Linux style guidelines, and to work
with the new RTC drivers.
Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
Acked-by: NAlessandro Zummo <a.zummo@towertech.it>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

debugfs needs include/linux/kobject.h for <kernel_subsys>.
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

OpenVZ developers team has encountered the following problem in 2.6.19-rc6
kernel. After some seconds of running script

while [[ 1 ]]
do
	find  /proc -name mountstats | xargs cat
done

this Oops appears:

BUG: unable to handle kernel NULL pointer dereference at virtual address
00000010
 printing eip:
c01a6b70
*pde = 00000000
Oops: 0000 [#1]
SMP
Modules linked in: xt_length ipt_ttl xt_tcpmss ipt_TCPMSS iptable_mangle
iptable_filter xt_multiport xt_limit ipt_tos ipt_REJECT ip_tables x_tables
parport_pc lp parport sunrpc af_packet thermal processor fan button battery
asus_acpi ac ohci_hcd ehci_hcd usbcore i2c_nforce2 i2c_core tg3 floppy
pata_amd
ide_cd cdrom sata_nv libata
CPU:    1
EIP:    0060:[<c01a6b70>]    Not tainted VLI
EFLAGS: 00010246   (2.6.19-rc6 #2)
EIP is at mountstats_open+0x70/0xf0
eax: 00000000   ebx: e6247030   ecx: e62470f8   edx: 00000000
esi: 00000000   edi: c01a6b00   ebp: c33b83c0   esp: f4105eb4
ds: 007b   es: 007b   ss: 0068
Process cat (pid: 6044, ti=f4105000 task=f4104a70 task.ti=f4105000)
Stack: c33b83c0 c04ee940 f46a4a80 c33b83c0 e4df31b4 c01a6b00 f4105000 c0169231
       e4df31b4 c33b83c0 c33b83c0 f4105f20 00000003 f4105000 c0169445 f2503cf0
       f7f8c4c0 00008000 c33b83c0 00000000 00008000 c0169350 f4105f20 00008000
Call Trace:
 [<c01a6b00>] mountstats_open+0x0/0xf0
 [<c0169231>] __dentry_open+0x181/0x250
 [<c0169445>] nameidata_to_filp+0x35/0x50
 [<c0169350>] do_filp_open+0x50/0x60
 [<c01873d6>] seq_read+0xc6/0x300
 [<c0169511>] get_unused_fd+0x31/0xc0
 [<c01696d3>] do_sys_open+0x63/0x110
 [<c01697a7>] sys_open+0x27/0x30
 [<c01030bd>] sysenter_past_esp+0x56/0x79
 =======================
Code: 45 74 8b 54 24 20 89 44 24 08 8b 42 f0 31 d2 e8 47 cb f8 ff 85 c0 89 c3
74 51 8d 80 a0 04 00 00 e8 46 06 2c 00 8b 83 48 04 00 00 <8b> 78 10 85 ff 74
03
f0 ff 07 b0 01 86 83 a0 04 00 00 f0 ff 4b
EIP: [<c01a6b70>] mountstats_open+0x70/0xf0 SS:ESP 0068:f4105eb4

The problem is that task->nsproxy can be equal NULL for some time during
task exit. This patch fixes the BUG.
Signed-off-by: NVasily Tarasov <vtaras@openvz.org>
Cc: Herbert Poetzl <herbert@13thfloor.at>
Cc: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Fix bug in certain error paths of lookup routines.  The request object was
reused for sending FORGET, which is illegal.  This bug could cause an Oops
in 2.6.18.  In earlier versions it might silently corrupt memory, but this
is very unlikely.

These error paths are never triggered by libfuse, so this wasn't noticed
even with the 2.6.18 kernel, only with a filesystem using the raw kernel
interface.

Thanks to Russ Cox for the bug report and test filesystem.
Signed-off-by: NMiklos Szeredi <miklos@szeredi.hu>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Fix bug 7401.

Handle more than one source dir or file list to the initramfs gen scripts.

The Kconfig help for INITRAMFS_SOURCE claims that you can specify multiple
space-separated sources in order to allow unprivileged users to build an
image.  There are two bugs in the current implementation that prevent this
from working.

First, we pass "file1 dir2" to the gen_initramfs_list.sh script, which it
obviously can't open.

Second, gen_initramfs_list.sh -l outputs multiple definitions for
deps_initramfs -- one for each argument.
Signed-off-by: NThomas Chou <thomas@wytron.com.tw>
Cc: Sam Ravnborg <sam@ravnborg.org>
Acked-by: NMatthew Wilcox <matthew@wil.cx>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Add required locking to dfbc9e9dSigned-off-by: NDaniel Ritz <daniel.ritz@gmx.ch>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Cc: Pavol Gono <Palo.Gono@gmail.com>
Cc: <stable@kernel.org>
Signed-off-by: NAndrew Morton <akpm@osdl.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

find_min_pfn_for_node() and find_min_pfn_with_active_regions() both
depend on a sorted early_node_map[].  However, sort_node_map() is being
called after fin_min_pfn_with_active_regions() in
free_area_init_nodes().

In most cases, this is ok, but on at least one x86_64, the SRAT table
caused the E820 ranges to be registered out of order.  This gave the
wrong values for the min PFN range resulting in some pages not being
initialised.

This patch sorts the early_node_map in find_min_pfn_for_node().  It has
been boot tested on x86, x86_64, ppc64 and ia64.
Signed-off-by: NMel Gorman <mel@csn.ul.ie>
Acked-by: NAndre Noll <maan@systemlinux.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Fix recent i2c-ixp4xx compilation breakage. Sorry for overlooking it.
Signed-off-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

processor_perflib.c::acpi_processor_ppc_notifier() check if the value
returned by the processor's _PPC method is 0 and return failed if so.
This is wrong since 0 indicate that the bios think the processor can go
to the highest frequency.  This patch for example fix the HP NX 6125 to
allow its highest frequency to be available.
Signed-off-by: NBruno Ducrot <ducrot@poupinou.org>
Cc: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
Signed-off-by: NDave Jones <davej@redhat.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

* 'for-linus' of master.kernel.org:/home/rmk/linux-2.6-arm:
  [ARM] 3941/1: [Jornada7xx] - Addition to MAINTAINERS
  [ARM] 3942/1: ARM: comment: consistent_sync should not be called directly
  [ARM] ebsa110: fix warnings generated by asm/arch/io.h
  [ARM] 3933/1: Source drivers/ata/Kconfig