Changeset a238b790d5 (Call fasync()
functions without the BKL) introduced a race which could leave
file->f_flags in a state inconsistent with what the underlying
driver/filesystem believes. Revert that change, and also fix the same
races in ioctl_fioasync() and ioctl_fionbio().
This is a minimal, short-term fix; the real fix will not involve the
BKL.
Reported-by: Oleg Nesterov <oleg@redhat.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: stable@kernel.org
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
There's no point in having too short SG_IO timeouts, since if the
command does end up timing out, we'll end up through the reset sequence
that is several seconds long in order to abort the command that timed
out.
As a result, shorter timeouts than a few seconds simply do not make
sense, as the recovery would be longer than the timeout itself.
Add a BLK_MIN_SG_TIMEOUT to match the existign BLK_DEFAULT_SG_TIMEOUT.
Suggested-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Acked-by: Tejun Heo <tj@kernel.org>
Acked-by: Jens Axboe <jens.axboe@oracle.com>
Cc: Jeff Garzik <jeff@garzik.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
no argument named @msg in i2o_msg_get_wait(), remove it.
Signed-off-by: Qinghuang Feng <qhfeng.kernel@gmail.com>
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fix incorrect use of loose in i2o_block.c
It should be 'lose', not 'loose'.
Signed-off-by: Nick Andrew <nick@nick-andrew.net>
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[Folded together as one diff from 3]
It should be 'lose', not 'loose'.
Signed-off-by: Nick Andrew <nick@nick-andrew.net>
Signed-off-by: Alan Cox <alan@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This reverts commit 558073dd56, along with
the failed try to fix the regression it caused ("ACPI: Fix ACPI battery
regression introduced by commit 558073"), which just made things worse.
Commit aaad077638 (that failed "Fix ACPI
battery regression") got the voltage conversion confused, and fixed the
problem with Rafael's battery monitor apparently just by mistake.
So revert them both, getting us back to the 2.6.27 state in this, and
let's revisit it when people understand what's going on.
Noted-by: Paul Martin <pm@debian.org>
Requested-by: Rafael J. Wysocki <rjw@sisk.pl>
Cc: Len Brown <len.brown@intel.com>
Cc: Alexey Starikovskiy <astarikovskiy@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The 440x5 core in the Virtex5 uses the 440A type machine check
(ie, they have MCSRR0/MCSRR1). They thus need to call the
appropriate fixup function to hook the right variant of the
exception.
Without this, all machine checks become fatal due to loss
of context when entering the exception handler.
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Under my 2.6.28-rc6 sparc64, when associating to an AP through my
zd1211rw device, I was seeing kernel log messages like (not exact output):
Kernel unaligned access at TPC[10129b68] zd_mac_rx+0x144/0x32c [zd1211rw]
For the zd1211rw module, on RX, the 80211 packet will be located after
the PLCP header in the skb data buffer. The PLCP header being 5 bytes
long, the 80211 header will start unaligned from an aligned skb
buffer.
As per Documentation/unaligned-memory-access.txt, we must replace the
not unaligned() safe compare_ether_addr() with memcmp() to protect
architectures that require alignment.
Signed-off-by: Shaddy Baddah <shaddy_baddah@hotmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
After fixing zd1211rw: use unaligned safe memcmp() in-place of
compare_ether_addr(), I started to see kernel log messages detailing
unaligned access:
Kernel unaligned access at TPC[100f7f44] sta_info_get+0x24/0x68 [mac80211]
As with the aforementioned patch, the unaligned access was eminating
from a compare_ether_addr() call. Concerned that whilst it was safe to
assume that unalignment was the norm for the zd1211rw, and take
preventative measures, it may not be the case or acceptable to use the
easy fix of changing the call to memcmp().
My research however indicated that it was OK to do this, as there are
a few instances where memcmp() is the preferred mechanism for doing
mac address comparisons throughout the module.
Signed-off-by: Shaddy Baddah <shaddy_baddah@hotmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
In "ipw2200: Call netif_*_queue() interfaces properly", netif_stop_queue()
and netif_wake_queue() were removed with the reason
"netif_carrier_{on,off}() handles starting and stopping packet flow into
the driver". The patch also removes a valid condition check that
ipw_tx_skb() cannot be called if device is not in STATUS_ASSOCIATED state.
But netif_carrier_off() doesn't guarantee netdev->hard_start_xmit won't
be called because linkwatch event is handled in a delayed workqueue. This
caused a kernel oops reported by Frank Seidel:
https://bugzilla.novell.com/show_bug.cgi?id=397390
This patch fixes the problem by moving the STATUS_ASSOCIATED check back
to ipw_tx_skb(). It also adds a missing netif_carrier_off() call to
ipw_disassociate().
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Signed-off-by: Chatre, Reinette <reinette.chatre@intel.com>
Tested-by: Frank Seidel <fseidel@suse.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
This patch cleans uCode key table bit map iwl_clear_stations_table
since all stations are cleared also the key table must be.
Since the keys are not removed properly on suspend by mac80211
this may result in exhausting key table on resume leading
to memory corruption during removal
This patch also fixes a memory corruption problem reported in
http://marc.info/?l=linux-wireless&m=122641417231586&w=2 and tracked in
http://bugzilla.kernel.org/show_bug.cgi?id=12040.
When the key is removed a second time the offset is set to 255 - this
index is not valid for the ucode_key_table and corrupts the eeprom pointer
(which is 255 bits from ucode_key_table).
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Zhu Yi <yi.zhu@intel.com>
Reported-by: Carlos R. Mafra <crmafra2@gmail.com>
Reported-by: Lukas Hejtmanek <xhejtman@ics.muni.cz>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/bdev:
[PATCH] fix bogus argument of blkdev_put() in pktcdvd
[PATCH 2/2] documnt FMODE_ constants
[PATCH 1/2] kill FMODE_NDELAY_NOW
[PATCH] clean up blkdev_get a little bit
[PATCH] Fix block dev compat ioctl handling
[PATCH] kill obsolete temporary comment in swsusp_close()
* 'drm-gem-update' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
drm/i915: Return error in i915_gem_set_to_gtt_domain if we're not in the GTT.
drm/i915: Retry execbuffer pinning after clearing the GTT
drm/i915: Move the execbuffer domain computations together
drm/i915: Rename object_set_domain to object_set_to_gpu_domain
drm/i915: Make a single set-to-cpu-domain path and use it wherever needed.
drm/i915: Make a single set-to-gtt-domain path.
drm/i915: If interrupted while setting object domains, still emit the flush.
drm/i915: Move flushing list cleanup from flush request retire to request emit.
drm/i915: Respect GM965/GM45 bit-17-instead-of-bit-11 option for swizzling.
Commit 558073dd56 ("ACPI: battery: Convert
discharge energy rate to current properly") caused the battery subsystem
to report wrong values of the remaining time on battery power and the
time until fully charged on Toshiba Portege R500 (and presumably on
other boxes too).
Fix the issue by correcting the conversion from mW to mA.
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'timers-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
time: catch xtime_nsec underflows and fix them
posix-cpu-timers: fix clock_gettime with CLOCK_PROCESS_CPUTIME_ID
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6:
sparc64: Sync FPU state in VIS emulation handler.
sparc64: Fix VIS emulation bugs
sparc: asm/bitops.h should define __fls
sparc64: Fix bug in PTRACE_SETFPREGS64 handling.
* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
x86: fix early panic with boot option "nosmp"
x86/oprofile: fix Intel cpu family 6 detection
oprofile: fix CPU unplug panic in ppro_stop()
AMD IOMMU: fix possible race while accessing iommu->need_sync
AMD IOMMU: set device table entry for aliased devices
AMD IOMMU: struct amd_iommu remove padding on 64 bit
x86: fix broken flushing in GART nofullflush path
x86: fix dma_mapping_error for 32bit x86
* 'core-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
check_hung_task(): unsigned sysctl_hung_task_warnings cannot be less than 0
documentation: local_ops fix on_each_cpu
* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus:
MIPS: Return ENOSYS from sys32_syscall on 64bit kernels like elsewhere.
MIPS: 64-bit: vmsplice needs to use the compat wrapper for o32 and N32.
MIPS: o32: Fix number of arguments to splice(2).
MIPS: Malta: Consolidate platform device code.
MIPS: IP22, Fulong, Malta: Update defconfigs.
MIPS: Malta: Add back RTC support
MIPS: Fix potential DOS by untrusted user app.
When project quota is active and is being used for directory tree
quota control, we disallow rename outside the current directory
tree. This requires a check to be made after all the inodes
involved in the rename are locked. We fail to unlock the inodes
correctly if we disallow the rename when the target is outside the
current directory tree. This results in a hang on the next access
to the inodes involved in failed rename.
Reported-by: Arkadiusz Miskiewicz <arekm@maven.pl>
Signed-off-by: Dave Chinner <david@fromorbit.com>
Tested-by: Arkadiusz Miskiewicz <arekm@maven.pl>
Signed-off-by: Lachlan McIlroy <lachlan@sgi.com>
This patch fixes a bug in tcp_vegas.c. At the moment this code leaves
ssthresh untouched. However, this means that the vegas congestion
control algorithm is effectively unable to reduce cwnd below the
ssthresh value (if the vegas update lowers the cwnd below ssthresh,
then slow start is activated to raise it back up). One example where
this matters is when during slow start cwnd overshoots the link
capacity and a flow then exits slow start with ssthresh set to a value
above where congestion avoidance would like to adjust it.
Signed-off-by: Doug Leith <doug.leith@nuim.ie>
Signed-off-by: David S. Miller <davem@davemloft.net>
This is needed so that Vitesse 7385 5-port switch could work on
MPC8349E-mITX boards.
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Acked-by: Timur Tabi <timur@freescale.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Since commit d253eee201 the single CAN
identifier filter lists handle only non-RTR CAN frames.
So we need to omit the check of these filter lists when receiving RTR
CAN frames.
Signed-off-by: Oliver Hartkopp <oliver@hartkopp.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
As reported by Hugo Dias that it is possible to cause a local denial
of service attack by calling the svc_listen function twice on the same
socket and reading /proc/net/atm/*vc
Signed-off-by: Chas Williams <chas@cmf.nrl.navy.mil>
Signed-off-by: David S. Miller <davem@davemloft.net>
When the o32 errno was changed to ENOSYS, we forgot to update the code
for 64bit kernels.
Signed-off-by: David Daney <ddaney@caviumnetworks.com>
Acked-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
The syscall code was assuming splice only takes 4 arguments so no stack
arguments were being copied from the userspace stack to the kernel stack.
As the result splice was likely to fail with EINVAL.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
These haven't seen much attention for too long but particularly important
enable RTC_CLASS and CONFIG_RTC_HCTOSYS so the wall clock time is set on
kernel startup.
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
With the conversion of MIPS to RTC_LIB the old RTC driver CONFIG_RTC became
unselectable. Fix by setting up a platform device. Also enable
RTC_CLASS so system time gets set from RTC on kernel initialization.
[Ralf: Original patch by Tiejun; polished nice and shiny by me]
Signed-off-by: Tiejun Chen <tiejun.chen@windriver.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
On a 64 bit kernel if an o32 syscall was made with a syscall number less
than 4000, we would read the function from outside of the bounds of the
syscall table. This led to non-deterministic behavior including system
crashes.
While we were at it we reworked the 32 bit version as well to use fewer
instructions. Both 32 and 64 bit versions are use the same code now.
Signed-off-by: Vlad Malov <Vlad.Malov@caviumnetworks.com>
Signed-off-by: David Daney <ddaney@caviumnetworks.com>
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Copy the FPU state to the task's thread_info->fpregs for the VIS emulation
functions to access.
Signed-off-by: Hong H. Pham <hong.pham@windriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Impact: fix boot crash with numcpus=0 on certain systems
Fix early exception in __get_smp_config with nosmp.
Bail out early when there is no MP table.
Reported-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Andi Kleen <ak@linux.intel.com>
Tested-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
final close of ->bdev should match the initial open, i.e.
get FMODE_READ | FMODE_NDELAY; FMODE_READ|FMODE_WRITE has
been a braino.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Make sure all FMODE_ constants are documents, and ensure a coherent
style for the already existing comments.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Update FMODE_NDELAY before each ioctl call so that we can kill the
magic FMODE_NDELAY_NOW. It would be even better to do this directly
in setfl(), but for that we'd need to have FMODE_NDELAY for all files,
not just block special files.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
The way the bd_claim for the FMODE_EXCL case is implemented is rather
confusing. Clean it up to the most logical style.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Commit 33c2dca495 (trim file propagation
in block/compat_ioctl.c) removed the handling of some ioctls from
compat_blkdev_driver_ioctl. That caused them to be rejected as unknown
by the compat layer.
Signed-off-by: Andreas Schwab <schwab@suse.de>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
it had been put there to mark the call of blkdev_put() that
needed proper argument propagated to it; later patch in the
same series had done just that.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Commit 0c65f459ce intended to fix truncation issues with fls() on
ARMv5+ by renaming it to __fls() and wrapping it into a C function.
However that didn't take into account the fact that __fls() already
already had different semantics in the kernel.
Let's move the __fls() code into fls() function directly, and redefine
__fls() with the appropriate semantics. While at it, bring a generic
__fls() definition for pre ARMv5 too.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Impact: fix time warp bug
Alex Shi, along with Yanmin Zhang have been noticing occasional time
inconsistencies recently. Through their great diagnosis, they found that
the xtime_nsec value used in update_wall_time was occasionally going
negative. After looking through the code for awhile, I realized we have
the possibility for an underflow when three conditions are met in
update_wall_time():
1) We have accumulated a second's worth of nanoseconds, so we
incremented xtime.tv_sec and appropriately decrement xtime_nsec.
(This doesn't cause xtime_nsec to go negative, but it can cause it
to be small).
2) The remaining offset value is large, but just slightly less then
cycle_interval.
3) clocksource_adjust() is speeding up the clock, causing a
corrective amount (compensating for the increase in the multiplier
being multiplied against the unaccumulated offset value) to be
subtracted from xtime_nsec.
This can cause xtime_nsec to underflow.
Unfortunately, since we notify the NTP subsystem via second_overflow()
whenever we accumulate a full second, and this effects the error
accumulation that has already occured, we cannot simply revert the
accumulated second from xtime nor move the second accumulation to after
the clocksource_adjust call without a change in behavior.
This leaves us with (at least) two options:
1) Simply return from clocksource_adjust() without making a change if we
notice the adjustment would cause xtime_nsec to go negative.
This would work, but I'm concerned that if a large adjustment was needed
(due to the error being large), it may be possible to get stuck with an
ever increasing error that becomes too large to correct (since it may
always force xtime_nsec negative). This may just be paranoia on my part.
2) Catch xtime_nsec if it is negative, then add back the amount its
negative to both xtime_nsec and the error.
This second method is consistent with how we've handled earlier rounding
issues, and also has the benefit that the error being added is always in
the oposite direction also always equal or smaller then the correction
being applied. So the risk of a corner case where things get out of
control is lessened.
This patch fixes bug 11970, as tested by Yanmin Zhang
http://bugzilla.kernel.org/show_bug.cgi?id=11970
Reported-by: alex.shi@intel.com
Signed-off-by: John Stultz <johnstul@us.ibm.com>
Acked-by: "Zhang, Yanmin" <yanmin_zhang@linux.intel.com>
Tested-by: "Zhang, Yanmin" <yanmin_zhang@linux.intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
The spinlock used in the netx-eth driver was never properly initialized.
This was noticed using CONFIG_DEBUG_SPINLOCK=y
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
I should have noticed this earlier... :-) The previous solution
to URG+GSO/TSO will cause SACK block tcp_fragment to do zig-zig
patterns, or even worse, a steep downward slope into packet
counting because each skb pcount would be truncated to pcount
of 2 and then the following fragments of the later portion would
restore the window again.
Basically this reverts "tcp: Do not use TSO/GSO when there is
urgent data" (33cf71cee1). It also removes some unnecessary code
from tcp_current_mss that didn't work as intented either (could
be that something was changed down the road, or it might have
been broken since the dawn of time) because it only works once
urg is already written while this bug shows up starting from
~64k before the urg point.
The retransmissions already are split to mss sized chunks, so
only new data sending paths need splitting in case they have
a segment otherwise suitable for gso/tso. The actually check
can be improved to be more narrow but since this is late -rc
already, I'll postpone thinking the more fine-grained things.
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi>
Signed-off-by: David S. Miller <davem@davemloft.net>
Packet data read from the RX buffer the when the RSV is at the end of the RX
buffer does not warp around. This causes packet loss, as the actual data is
never read. Fix this by calculating the right packet data location.
Thanks to Shachar Shemesh for suggesting the fix.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Acked-by: Claudio Lanconelli <lanconelli.claudio@eptar.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
ifa_local is assumed to be unsigned long which lead to writing the address
at dev->dev_addr-2 instead of +2
noticed thanks to gcc:
drivers/isdn/hysdn/hysdn_net.c: In function `net_open':
drivers/isdn/hysdn/hysdn_net.c:91: warning: array subscript is below array bounds
Signed-off-by: Pascal Terjan <pterjan@mandriva.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
