Exploit rcu_needs_cpu() interface to keep the cpu 'ticking' if necessary.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
With "Paul E. McKenney" <paulmck@us.ibm.com>
Introduce rcu_needs_cpu() interface. This can be used to tell if there
will be a new rcu batch on a cpu soon by looking at the curlist pointer.
This can be used to avoid to enter a tickless idle state where the cpu
would miss that a new batch is ready when rcu_start_batch would be called
on a different cpu.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: "Paul E. McKenney" <paulmck@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Mark Moseley reported that a chroot environment on a SMB share can be left
via "cd ..\\". Similar to CVE-2006-1863 issue with cifs, this fix is for
smbfs.
Steven French <sfrench@us.ibm.com> wrote:
Looks fine to me. This should catch the slash on lookup or equivalent,
which will be all obvious paths of interest.
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
An earlier commit (75cf7456dd) changed an
overly-zealous PCI quirk to only poke those VIA devices that need it.
However, some PCI devices were not included in what I hope is now the full
list. Consequently we're failing to run the quirk on all machines which need
it, causing IRQ routing failures.
This should I hope correct this.
Thanks to Masoud Sharbiani <masouds@masoud.ir> for pointing this out
and testing the fix.
Signed-off-by: Chris Wedgwood <cw@f00f.org>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Fix some NULL dereferences in the pcmcia code when using old userland
tools.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Acked-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
The TIS driver is dependent upon information from the ACPI table for device
discovery thus it compiles but does no actual work without this dependency.
Signed-off-by: Kylene Hall <kjhall@us.ibm.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
I am having the bug FATAL: Error inserting capi ([..]/capi.ko): Device or
resource busy when I try to reload capi after loading it. in dmesg:
capi20: unable to get major 68
Fix the issue which is caused by setting the major to zero when registering
the chrdev succeeded.
(akpm: this means that we can again not use `major=0' (dynamic major
allocation) for this driver).
Cc: Karsten Keil <kkeil@suse.de>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This patch fixes two problems.
First, the comparison of entries in the waitq.c was incorrect.
Second, the NFY_NONE check was incorrect. The test of whether the dentry
is mounted if ineffective, for example, if an expire fails then we could
wait forever on a non existant expire. The bug was identified by Jeff
Moyer.
The patch changes autofs4 to wait on expires only as this is all that's
needed. If there is no existing wait when autofs4_wait is call with a type
of NFY_NONE it delays until either a wait appears or the the expire flag is
cleared.
Signed-off-by: Ian Kent <raven@themaw.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Check for NULL kmalloc return value before writing to it.
Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
Acked-by: James Morris <jmorris@namei.org>
Cc: Stephen Smalley <sds@tycho.nsa.gov>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This reverts commit 10dbe196a8.
The resource struct is still 32-bit, so trying to save a 64-bit memory
size there obviously won't work.
When we merge the 64-bit resource series, we can re-enable this.
Thanks to Sachin Sant and Maneesh Soni for debugging
Cc: Maneesh Soni <maneesh@in.ibm.com>
Cc: Sachin Sant <sachinp@in.ibm.com>
Cc: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: Sharyathi Nagesh <sharyath@in.ibm.com>
Cc: Arjan van de Ven <arjan@infradead.org>
Cc: Vivek Goyal <vgoyal@in.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Make sure to clear the driverfs_dev pointer when we do del_gendisk() (on
disk removal), so that other users that may still have a ref to the disk
won't try to use the stale pointer.
Also move the KOBJ_REMOVE uevent handler up, so that the uevent still
has access to the driverfs_dev data.
This all should hopefully fix the problems with MMC umounts after device
removals that caused commit 56cf6504fc and
its reversal (1a2acc9e92).
Original problem reported by Todd Blumer and others.
Acked-by: Greg KH <gregkh@suse.de>
Cc: Russell King <rmk+lkml@arm.linux.org.uk>
Cc: James Bottomley <James.Bottomley@SteelEye.com>
Cc: Erik Mouw <erik@harddisk-recovery.com>
Cc: Andrew Vasquez <andrew.vasquez@qlogic.com>
Cc: Todd Blumer <todd@sdgsystems.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6:
[SPARC]: Fix warning on prom_getproperty in openprom.c
[SPARC]: Handle UNWIND_INFO properly.
[SPARC64]: Update defconfig.
[SPARC]: show device name in /proc/dvma_map
[SPARC]: Remove duplicate symbol exports
Fix race condition during destruction calls to avoid possibility of
accessing object after it has been freed. Instead of waking up a wait
queue directly, which is susceptible to a race where the object is
freed between the reference count going to 0 and the wake_up(), use a
completion to wait in the function doing the freeing.
Signed-off-by: Sean Hefty <sean.hefty@intel.com>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
The ipath driver's table of PCI IDs needs a { 0, } entry at the end.
This makes all of the device aliases visible to userspace so hotplug
loads the module for all supported devices. Without the patch,
modinfo ipath_core only shows:
alias: pci:v00001FC1d0000000Dsv*sd*bc*sc*i*
instead of the correct:
alias: pci:v00001FC1d00000010sv*sd*bc*sc*i*
alias: pci:v00001FC1d0000000Dsv*sd*bc*sc*i*
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Signed-off-by: Bryan O'Sullivan <bos@pathscale.com>
The classical IP over ATM code maintains its own IPv4 <-> <ATM stuff>
ARP table, using the standard neighbour-table code. The
neigh_table_init function adds this neighbour table to a linked list
of all neighbor tables which is used by the functions neigh_delete()
neigh_add() and neightbl_set(), all called by the netlink code.
Once the ATM neighbour table is added to the list, there are two
tables with family == AF_INET there, and ARP entries sent via netlink
go into the first table with matching family. This is indeterminate
and often wrong.
To see the bug, on a kernel with CLIP enabled, create a standard IPv4
ARP entry by pinging an unused address on a local subnet. Then attempt
to complete that entry by doing
ip neigh replace <ip address> lladdr <some mac address> nud reachable
Looking at the ARP tables by using
ip neigh show
will reveal two ARP entries for the same address. One of these can be
found in /proc/net/arp, and the other in /proc/net/atm/arp.
This patch adds a new function, neigh_table_init_no_netlink() which
does everything the neigh_table_init() does, except add the table to
the netlink all-arp-tables chain. In addition neigh_table_init() has a
check that all tables on the chain have a distinct address family.
The init call in clip.c is changed to call
neigh_table_init_no_netlink().
Since ATM ARP tables are rather more complicated than can currently be
handled by the available rtattrs in the netlink protocol, no
functionality is lost by this patch, and non-ATM ARP manipulation via
netlink is rescued. A more complete solution would involve a rtattr
for ATM ARP entries and some way for the netlink code to give
neigh_add and friends more information than just address family with
which to find the correct ARP table.
[ I've changed the assertion checking in neigh_table_init() to not
use BUG_ON() while holding neigh_tbl_lock. Instead we remember that
we found an existing tbl with the same family, and after dropping
the lock we'll give a diagnostic kernel log message and a stack dump.
-DaveM ]
Signed-off-by: Simon Kelley <simon@thekelleys.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Even with fiber cards ethtool reports that the connected port is TP,
the patch fix this.
Signed-off-by: Karsten Keil <kkeil@suse.de>
Acked-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
For sparc32 we need R_SPARC_UA32 relocation support, for
sparc64 we need the handle R_SPARC_DISP32 relocations.
Based upon reports and initial patch by Martin Habets.
Signed-off-by: David S. Miller <davem@davemloft.net>
* master.kernel.org:/pub/scm/linux/kernel/git/gregkh/i2c-2.6:
[PATCH] scx200_acb: Fix for the CS5535 errata
[PATCH] scx200_acb: Fix resource name use after free
[PATCH] scx200_acb: Fix return on init error
This reverts commit 56cf6504fc.
Both Erik Mouw and Andrew Vasquez independently pinpointed this commit
as causing problems, where the slab cache for a driver is never released
(most obviously causing problems when immediately re-loading that
driver, resulting in a "kmem_cache_create: duplicate cache <xyz>"
message, but it can also cause other trouble).
James Bottomley dug into it, and reports:
"OK, here's the scoop. The problem patch adds a get of driverfs_dev in
add_disk(), but doesn't put it again until disk_release() (which occurs
on final put_disk() of the gendisk).
However, in SCSI, the driverfs_dev is the sdev_gendev. That means
there's a reference held on sdev_gendev until final disk put.
Unfortunately, we use the driver model driver_remove to trigger
del_gendisk (which removes the gendisk from visibility and decrements
the refcount), so we've introduced an unbreakable deadlock in the
reference counting with this.
I suggest simply reversing this patch at the moment. If Russell and
Jens can tell me what they're trying to do I'll see if there's another
way to do it."
so hereby the patch gets reverted, waiting for a better fix.
Cc: Jens Axboe <axboe@suse.de>
Cc: Russell King <rmk@arm.linux.org.uk>
Cc: James Bottomley <James.Bottomley@SteelEye.com>
Cc: Erik Mouw <erik@harddisk-recovery.com>
Cc: Andrew Vasquez <andrew.vasquez@qlogic.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
I introduced this way back in 2.6.13 when adding the port lock logic.
This device talks out through different "ports" all at the same time, so
the lock logic was wrong, preventing any data from ever being sent
properly.
Thanks a lot to Bernhard Reiter <bernhard@intevation.de> for being
patient and helping with debugging this.
Cc: Bernhard Reiter <bernhard@intevation.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Based on Simon's original driver, with some minor code cleanups and
tidying by me.
Cc: Simon Schulz <simon@auctionant.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
If serial_open() fails at the port assignment or mutex_lock_interruptible()
is interrupted, the 'serial' object will never be freed.
We should call kref_put() when those errors happens.
Signed-off-by: Luiz Fernando N. Capitulino <lcapitulino@mandriva.com.br>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
If the device is disconnected while serial_open() is executing and
either try_module_get() or the device specific open function fails, the
kref_put() call in the 'bailout_kref_put' label will free the memory
pointed out by 'port'.
The subsequent dereferences in the 'bailout_kref_put' label will be
invalid.
The fix is just to assure kref_put() is called after any 'port' usage.
Signed-off-by: Luiz Fernando N. Capitulino <lcapitulino@mandriva.com.br>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
It's become apparent as machines get faster that the emagic kernel firmware
loaders (based on the ezusb loader) have a reset race. a 400MHz TiBook
never tripped it, but a 2GHz Pentium M seems to hit it about 30% of the
time. The bug is seen as a hung USB box and the kernel error:
drivers/usb/misc/emi62.c: emi62_load_firmware - error loading firmware:
error = -110
The patch below inserts a delay after deasserting reset to allow the box to
settle before a new command is issued. This affects only device startup.
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
After recent changes, the USB keyboard as shipped with IBM pSeries systems
does not work anymore, unless the keyboard is replugged after reboot.
Adding this model to the blacklist fixes it.
Signed-off-by: Olaf Hering <olh@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This adds the Sierra Wireless card to airprime.c.
I tested this on my laptop.
Signed-off-by: Ken Brush <ken@cgi101.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
* master.kernel.org:/home/rmk/linux-2.6-serial:
[SERIAL] 8250: add locking to console write function
[SERIAL] Remove unconditional enable of TX irq for console
[SERIAL] 8250: set divisor register correctly for AMD Alchemy SoC uart
[SERIAL] AMD Alchemy UART: claim memory range
[SERIAL] Clean up serial locking when obtaining a reference to a port
* master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6:
[NET_SCHED]: HFSC: fix thinko in hfsc_adjust_levels()
[IPV6]: skb leakage in inet6_csk_xmit
[BRIDGE]: Do sysfs registration inside rtnl.
[NET]: Do sysfs registration as part of register_netdevice.
[TG3]: Fix possible NULL deref in tg3_run_loopback().
[NET] linkwatch: Handle jiffies wrap-around
[IRDA]: Switching to a workqueue for the SIR work
[IRDA]: smsc-ircc: Minimal hotplug support.
[IRDA]: Removing unused EXPORT_SYMBOLs
[IRDA]: New maintainer.
[NET]: Make netdev_chain a raw notifier.
[IPV4]: ip_options_fragment() has no effect on fragmentation
[NET]: Add missing operstates documentation.
Don't recurse back into the driver even if the unplug threshold is met,
when the driver asks for a requeue. This is both silly from a logical
point of view (requeues typically happen due to driver/hardware
shortage), and also dangerous since we could hit an endless request_fn
-> requeue -> unplug -> request_fn loop and crash on stack overrun.
Also limit blk_run_queue() to one level of recursion, similar to how
blk_start_queue() works.
This patch fixed a real problem with SLES10 and lpfc, and it could hit
any SCSI lld that returns non-zero from it's ->queuecommand() handler.
Signed-off-by: Jens Axboe <axboe@suse.de>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
When deleting the last child the level of a class should drop to zero.
Noticed by Andreas Mueller <andreas@stapelspeicher.org>
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
Eric Biederman points out that we can't take the task_lock while holding
tasklist_lock for writing, because another CPU that holds the task lock
might take an interrupt that then tries to take tasklist_lock for writing.
Which would be a nasty deadlock, with one CPU spinning forever in an
interrupt handler (although admittedly you need to really work at
triggering it ;)
Since the ptrace_attach() code is special and very unusual, just make it
be extra careful, and use trylock+repeat to avoid the possible deadlock.
Cc: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Roland McGrath <roland@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Addresses for ioremap must be calculated off of pci_resource_start;
we can't directly use the bus address as seen by the HCA. Fix the
code that remaps device memory for FMR access.
Based on patch by Klaus Smolin.
Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>
Signed-off-by: Roland Dreier <rolandd@cisco.com>
661FX7MI-S motherboard which uses the SiS 661FX chipset. The patch adds
an entry to mii_chip_info for the transceiver.
The PHY ids were found using the sis900_c_122.diff patch from
http://brownhat.org/sis900.html but that patch didn't solve the problem,
because the PHY at address 1 was already being chosen.
Without my patch, when bursts of packets arrive from other hosts on a
LAN, the interface dropped one roughly 10% of the time, causing
retransmits. There were fifth second pauses in refresh of large xterms,
and it made Netrek suck. I can provide further test data.
Workaround in lieu of patch is to use mii-tool to advertise
100baseTx-HD, then force renegotiation.
I wasn't able to identify the actual transceiver, so the description
field is a guess.
This patch is similar to Artur Skawina's patch:
http://marc.theaimsgroup.com/?l=linux-netdev&m=114297516729079&w=2
I'm not sure, but I wonder if it means the default behaviour should be
changed, so as to better handle future transceivers.
Diff is against 2.6.16.13.
Signed-off-by: James Cameron <james.cameron@hp.com>
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
make sure phy_map entries whose PHY address is masked are initialized
to NULL, given that other code (such as mdiobus_unregister for
instance) assumes that non-NULL phy_map entries are allocated
phy_devices
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Bringing down a port also masks off the status and other IRQ's
needed for device to function due to missing paren's.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
This patch corrects the order of the calls to register_chrdev() and
pcmcia_register_driver(). Now udev correctly creates userspace device
files /dev/cmmN and /dev/cmxN respectively.
Based on an earlier patch by Jan Niehusmann <jan@gondor.com>.
Signed-off-by: Harald Welte <laforge@netfilter.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
inet6_csk_xit does not free skb when routing fails.
Signed-off-by: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Signed-off-by: David S. Miller <davem@davemloft.net>
Now that netdevice sysfs registration is done as part of
register_netdevice; bridge code no longer has to be tricky when adding
it's kobjects to bridges.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
The last step of netdevice registration was being done by a delayed
call, but because it was delayed, it was impossible to return any error
code if the class_device registration failed.
Side effects:
* one state in registration process is unnecessary.
* register_netdevice can sleep inside class_device registration/hotplug
* code in netdev_run_todo only does unregistration so it is simpler.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
A race condition exists in mptfc between the thread registering a device
with the fc transport and the scan work generated by the transport.
This race existed prior to the application of the mptfc bug fix patch.
mptfc_register_dev() calls fc_remote_port_add() with the FC_RPORT_ROLE_TARGET
bit set in the rport ids passed to the function. Having this bit set causes
fc_remote_port_add() to schedule a scan of the device.
This scan can execute before mptfc_register_dev() can fill in the dd_data
in the rport structure. When this happens, mptfc_target_alloc() will fail
because dd_data is null.
Attached is a patch which fixes the problem. The patch changes the rport ids
passed to fc_remote_port_add() to not have the TARGET bit set. This prevents
the scan from being scheduled. After mptfc_register_dev() fills in the rport
dd_data field, fc_remote_port_rolechg() is called, changing the role of the
rport to TARGET. Thus, the scan is scheduled after dd_data is filled
in which prevents the failure in mptfc_target_alloc().
Signed-off-by: Michael Reed <mdr@sgi.com>
Signed-off-by: Eric Moore <Eric.Moore@lsil.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
