30 Aug, 2011
36 commits
-
commit be27425dcc516fd08245b047ea57f83b8f6f0903 upstream.
I ran into a couple of programs which broke with the new Linux 3.0
version. Some of those were binary only. I tried to use LD_PRELOAD to
work around it, but it was quite difficult and in one case impossible
because of a mix of 32bit and 64bit executables.For example, all kind of management software from HP doesnt work, unless
we pretend to run a 2.6 kernel.$ uname -a
Linux svivoipvnx001 3.0.0-08107-g97cd98f #1062 SMP Fri Aug 12 18:11:45 CEST 2011 i686 i686 i386 GNU/Linux$ hpacucli ctrl all show
Error: No controllers detected.
$ rpm -qf /usr/sbin/hpacucli
hpacucli-8.75-12.0Another notable case is that Python now reports "linux3" from
sys.platform(); which in turn can break things that were checking
sys.platform() == "linux2":https://bugzilla.mozilla.org/show_bug.cgi?id=664564
It seems pretty clear to me though it's a bug in the apps that are using
'==' instead of .startswith(), but this allows us to unbreak broken
programs.This patch adds a UNAME26 personality that makes the kernel report a
2.6.40+x version number instead. The x is the x in 3.x.I know this is somewhat ugly, but I didn't find a better workaround, and
compatibility to existing programs is important.Some programs also read /proc/sys/kernel/osrelease. This can be worked
around in user space with mount --bind (and a mount namespace)To use:
wget ftp://ftp.kernel.org/pub/linux/kernel/people/ak/uname26/uname26.c
gcc -o uname26 uname26.c
./uname26 programSigned-off-by: Andi Kleen
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 064b43304ed8ede8e13ff7b4338d09fd37bcffb1 upstream.
Register writes followed by a delay are required to have a flush
before the delay in order to commit the values to the register. Without
the flush, the code following the delay may not function correctly.Reported-by: Tong Ho
Reported-by: Guenter Roeck
Signed-off-by: Carolyn Wyborny
Tested-by: Aaron Brown
Signed-off-by: Jeff Kirsher
Signed-off-by: Greg Kroah-Hartman -
commit 78869618a886d33d8cdfcb78cf9b245b5250e465 upstream.
Currently, the retuning timer for retuning mode 1 will be deleted in
function sdhci_tasklet_finish after a mmc request done, which will make
retuning timing never trigger again. This patch fixed this problem.Signed-off-by: Aaron Lu
Reviewed-by: Philip Rakity
Signed-off-by: Chris Ball
Signed-off-by: Greg Kroah-Hartman -
commit df71c9cfceea801e7e26e2c74241758ef9c042e5 upstream.
In rt2800usb_work_txdone we check flags in order:
- ENTRY_OWNER_DEVICE_DATA
- ENTRY_DATA_STATUS_PENDING
- ENTRY_DATA_IO_FAILEDModify flags in separate order in rt2x00usb_interrupt_txdone, to avoid
processing entries in _txdone with wrong flags or skip processing
ready entries.Reported-by: Justin Piszcz
Signed-off-by: Stanislaw Gruszka
Acked-by: Ivo van Doorn
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit c2183d1e9b3f313dd8ba2b1b0197c8d9fb86a7ae upstream.
FUSE_NOTIFY_INVAL_ENTRY didn't check the length of the write so the
message processing could overrun and result in a "kernel BUG at
fs/fuse/dev.c:629!"Reported-by: Han-Wen Nienhuys
Signed-off-by: Miklos Szeredi
Signed-off-by: Greg Kroah-Hartman -
commit f2b60717e692550bf753a5d64a5b69ea430fc832 upstream.
Toshiba Satellite L300D with ATI Mobility Radeon X1100 sends data
to i2c bus for a HDMI connector that is not implemented/existent
on the notebook's board.Fix by applying extented DDC probing for this connector.
Requires [PATCH] drm/radeon: Extended DDC Probing for Connectors
with Improperly Wired DDC LinesTested for kernel 2.6.38 on Toshiba Satellite L300D notebook
BugLink: http://bugs.launchpad.net/bugs/826677
Signed-off-by: Thomas Reim
Acked-by: Chris Routh
Reviewed-by: Alex Deucher
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
commit 7c4c3960dff109bc5db4c35da481c212dadb5eb5 upstream.
ttm_tt_destroy kfrees passed object, so we need to nullify
a reference to it.Signed-off-by: Marcin Slusarz
Reviewed-by: Thomas Hellstrom
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
commit 05e33fc20ea5e493a2a1e7f1d04f43cdf89f83ed upstream.
Delete the 10 msec delay between the INIT and SIPI when starting
slave cpus. I can find no requirement for this delay. BIOS also
has similar code sequences without the delay.Removing the delay reduces boot time by 40 sec. Every bit helps.
Signed-off-by: Jack Steiner
Link: http://lkml.kernel.org/r/20110805140900.GA6774@sgi.com
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit 7ca0758cdb7c241cb4e0490a8d95f0eb5b861daf upstream.
When we enter a 32-bit system call via SYSENTER or SYSCALL, we shuffle
the arguments to match the int $0x80 calling convention. This was
probably a design mistake, but it's what it is now. This causes
errors if the system call as to be restarted.For SYSENTER, we have to invoke the instruction from the vdso as the
return address is hardcoded. Accordingly, we can simply replace the
jump in the vdso with an int $0x80 instruction and use the slower
entry point for a post-restart.Suggested-by: Linus Torvalds
Signed-off-by: H. Peter Anvin
Link: http://lkml.kernel.org/r/CA%2B55aFztZ=r5wa0x26KJQxvZOaQq8s2v3u50wCyJcA-Sc4g8gQ@mail.gmail.com
Signed-off-by: Greg Kroah-Hartman -
commit a3ea14df0e383f44dcb2e61badb71180dbffe526 upstream.
When executing EC commands, only waiting when there are still
more bytes to write is usually fine. However, if the system
suspends very quickly after a call to olpc_ec_cmd(), the last
data byte may not yet be transferred to the EC, and the command
will not complete.This solves a bug where the SCI wakeup mask was not correctly
written when going into suspend.It means that sometimes, on XO-1.5 (but not XO-1), the
devices that were marked as wakeup sources can't wake up
the system. e.g. you ask for wifi wakeups, suspend, but then
incoming wifi frames don't wake up the system as they should.Signed-off-by: Paul Fox
Signed-off-by: Daniel Drake
Acked-by: Andres Salomon
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit 3c05c4bed4ccce3f22f6d7899b308faae24ad198 upstream.
Fix regression for HVM case on older (
Date: Thu Dec 2 17:55:10 2010 +0000xen: PV on HVM: support PV spinlocks and IPIs
This change replaced the SMP operations with event based handlers without
taking into account that this only works when the hypervisor supports
callback vectors. This causes unexplainable hangs early on boot for
HVM guests with more than one CPU.BugLink: http://bugs.launchpad.net/bugs/791850
Signed-off-by: Stefan Bader
Signed-off-by: Stefano Stabellini
Tested-and-Reported-by: Stefan Bader
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Greg Kroah-Hartman -
commit ccbcdf7cf1b5f6c6db30d84095b9c6c53043af55 upstream.
The order-based approach is not only less efficient (requiring a shift
and a compare, typical generated code looking like thismov eax, [machine_to_phys_order]
mov ecx, eax
shr ebx, cl
test ebx, ebx
jnz ...whereas a direct check requires just a compare, like in
cmp ebx, [machine_to_phys_nr]
jae ...), but also slightly dangerous in the 32-on-64 case - the element
address calculation can wrap if the next power of two boundary is
sufficiently far away from the actual upper limit of the table, and
hence can result in user space addresses being accessed (with it being
unknown what may actually be mapped there).Additionally, the elimination of the mistaken use of fls() here (should
have been __fls()) fixes a latent issue on x86-64 that would trigger
if the code was run on a system with memory extending beyond the 44-bit
boundary.Signed-off-by: Jan Beulich
[v1: Based on Jeremy's feedback]
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Greg Kroah-Hartman -
commit 89153b5cae9f40c224a5d321665a97bf14220c2c upstream.
Avoid telling users to use xvde and onwards when using xvde.
Acked-by: Stefano Stabellini
Signed-off-by: Stefan Bader
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Greg Kroah-Hartman -
commit 196cfe2ae8fcdc03b3c7d627e7dfe8c0ce7229f9 upstream.
These were intended to avoid the namespace clash when representing
emulated IDE and SCSI devices. However that seems to confuse users
more than expected (a disk defined as sda becomes xvde).
So for now go back to the scheme which does no adjustments. This
will break when mixing IDE and SCSI names in the configuration of
guests but should be by now expected.Acked-by: Stefano Stabellini
Signed-off-by: Stefan Bader
Signed-off-by: Konrad Rzeszutek Wilk
Signed-off-by: Greg Kroah-Hartman -
commit 9dd75f1f1a02d656a11a7b9b9e6c2759b9c1e946 upstream.
Bug discovered by Jan Kara:
Finally, commit 1449032be17abb69116dbc393f67ceb8bd034f92 returned back
the old IO submission code but apparently it forgot to return the old
handling of uninitialized buffers so we unconditionnaly call
block_write_full_page() without specifying end_io function. So AFAICS
we never convert unwritten extents to written in some cases. For
example when I mount the fs as: mount -t ext4 -o
nomblk_io_submit,dioread_nolock /dev/ubdb /mnt and do
int fd = open(argv[1], O_RDWR | O_CREAT | O_TRUNC, 0600);
char buf[1024];
memset(buf, 'a', sizeof(buf));
fallocate(fd, 0, 0, 16384);
write(fd, buf, sizeof(buf));I get a file full of zeros (after remounting the filesystem so that
pagecache is dropped) instead of seeing the first KB contain 'a's.Signed-off-by: "Theodore Ts'o"
Signed-off-by: Greg Kroah-Hartman -
commit 32c80b32c053dc52712dedac5e4d0aa7c93fc353 upstream.
EXT4_IO_END_UNWRITTEN flag set and the increase of i_aiodio_unwritten
should be done simultaneously since ext4_end_io_nolock always clear
the flag and decrease the counter in the same time.We don't increase i_aiodio_unwritten when setting
EXT4_IO_END_UNWRITTEN so it will go nagative and causes some process
to wait forever.Part of the patch came from Eric in his e-mail, but it doesn't fix the
problem met by Michael actually.http://marc.info/?l=linux-ext4&m=131316851417460&w=2
Reported-and-Tested-by: Michael Tokarev
Signed-off-by: Eric Sandeen
Signed-off-by: Tao Ma
Signed-off-by: "Theodore Ts'o"
Signed-off-by: Greg Kroah-Hartman -
commit 2581fdc810889fdea97689cb62481201d579c796 upstream.
Flush inode's i_completed_io_list before calling ext4_io_wait to
prevent the following deadlock scenario: A page fault happens while
some process is writing inode A. During page fault,
shrink_icache_memory is called that in turn evicts another inode
B. Inode B has some pending io_end work so it calls ext4_ioend_wait()
that waits for inode B's i_ioend_count to become zero. However, inode
B's ioend work was queued behind some of inode A's ioend work on the
same cpu's ext4-dio-unwritten workqueue. As the ext4-dio-unwritten
thread on that cpu is processing inode A's ioend work, it tries to
grab inode A's i_mutex lock. Since the i_mutex lock of inode A is
still hold before the page fault happened, we enter a deadlock.Also moves ext4_flush_completed_IO and ext4_ioend_wait from
ext4_destroy_inode() to ext4_evict_inode(). During inode deleteion,
ext4_evict_inode() is called before ext4_destroy_inode() and in
ext4_evict_inode(), we may call ext4_truncate() without holding
i_mutex lock. As a result, there is a race between flush_completed_IO
that is called from ext4_ext_truncate() and ext4_end_io_work, which
may cause corruption on an io_end structure. This change moves
ext4_flush_completed_IO and ext4_ioend_wait from ext4_destroy_inode()
to ext4_evict_inode() to resolve the race between ext4_truncate() and
ext4_end_io_work during inode deletion.Signed-off-by: Jiaying Zhang
Signed-off-by: "Theodore Ts'o"
Signed-off-by: Greg Kroah-Hartman -
commit 441c850857148935babe000fc2ba1455fe54a6a9 upstream.
ext4_should_writeback_data() had an incorrect sequence of
tests to determine if it should return 0 or 1: in
particular, even in no-journal mode, 0 was being returned
for a non-regular-file inode.This meant that, in non-journal mode, we would use
ext4_journalled_aops for directories, symlinks, and other
non-regular files. However, calling journalled aop
callbacks when there is no valid handle, can cause problems.This would cause a kernel crash with Jan Kara's commit
2d859db3e4 ("ext4: fix data corruption in inodes with
journalled data"), because we now dereference 'handle' in
ext4_journalled_write_end().I also added BUG_ONs to check for a valid handle in the
obviously journal-only aops callbacks.I tested this running xfstests with a scratch device in
these modes:- no-journal
- data=ordered
- data=writeback
- data=journalAll work fine; the data=journal run has many failures and a
crash in xfstests 074, but this is no different from a
vanilla kernel.Signed-off-by: Curt Wohlgemuth
Signed-off-by: "Theodore Ts'o"
Signed-off-by: Greg Kroah-Hartman -
commit eade7b281c9fc18401b989c77d5e5e660b25a3b7 upstream.
BugLink: https://bugs.launchpad.net/bugs/826081
The original reporter needs 'Headphone Jack Sense' enabled to have
audible audio, so add his PCI SSID to the whitelist.Reported-and-tested-by: Muhammad Khurram Khan
Signed-off-by: Daniel T Chen
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit da6094ea7d3c2295473d8f5134279307255d6ebf upstream.
The snd_usb_caiaq driver currently assumes that output urbs are serviced
in time and doesn't track when and whether they are given back by the
USB core. That usually works fine, but due to temporary limitations of
the XHCI stack, we faced that urbs were submitted more than once with
this approach.As it's no good practice to fire and forget urbs anyway, this patch
introduces a proper bit mask to track which requests have been submitted
and given back.That alone however doesn't make the driver work in case the host
controller is broken and doesn't give back urbs at all, and the output
stream will stop once all pre-allocated output urbs are consumed. But
it does prevent crashes of the controller stack in such cases.See http://bugzilla.kernel.org/show_bug.cgi?id=40702 for more details.
Signed-off-by: Daniel Mack
Reported-and-tested-by: Matej Laitl
Cc: Sarah Sharp
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 38b65190c6ab0be8ce7cff69e734ca5b5e7fa309 upstream.
The recent fix for testing dB range at the mixer creation time seems
to cause regressions in some devices. In such devices, reading the dB
info at probing time gives an error, thus both dBmin and dBmax are still
zero, and TLV flag isn't set although the later read of dB info succeeds.This patch adds a workaround for such a case by assuming that the later
read will succeed. In future, a similar test should be performed in a
case where a wrong dB range is seen even in the later read.Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 34f3e4f23ca3d259fe078f62a128d97ca83508ef upstream.
When btrfs recovers from a crash, it may hit the oops below:
------------[ cut here ]------------
kernel BUG at fs/btrfs/inode.c:4580!
[...]
RIP: 0010:[] [] btrfs_add_link+0x161/0x1c0 [btrfs]
[...]
Call Trace:
[] ? btrfs_inode_ref_index+0x31/0x80 [btrfs]
[] add_inode_ref+0x319/0x3f0 [btrfs]
[] replay_one_buffer+0x2c7/0x390 [btrfs]
[] walk_down_log_tree+0x32a/0x480 [btrfs]
[] walk_log_tree+0xf5/0x240 [btrfs]
[] btrfs_recover_log_trees+0x250/0x350 [btrfs]
[] ? btrfs_recover_log_trees+0x350/0x350 [btrfs]
[] open_ctree+0x1442/0x17d0 [btrfs]
[...]This comes from that while replaying an inode ref item, we forget to
check those old conflicting DIR_ITEM and DIR_INDEX items in fs/file tree,
then we will come to conflict corners which lead to BUG_ON().Signed-off-by: Liu Bo
Tested-by: Andy Lutomirski
Signed-off-by: Chris Mason
Signed-off-by: Greg Kroah-Hartman -
commit 05eb0f252b04aa94ace0794f73d56c6a02351d80 upstream.
LOOP_CLR_FD takes lo->lo_ctl_mutex and tries to remove the loop sysfs
files. Sysfs calls show() and waits for lo->lo_ctl_mutex. LOOP_CLR_FD
waits for show() to finish to remove the sysfs file.cat /sys/class/block/loop0/loop/backing_file
mutex_lock_nested+0x176/0x350
? loop_attr_do_show_backing_file+0x2f/0xd0 [loop]
? loop_attr_do_show_backing_file+0x2f/0xd0 [loop]
loop_attr_do_show_backing_file+0x2f/0xd0 [loop]
dev_attr_show+0x1b/0x60
? sysfs_read_file+0x86/0x1a0
? __get_free_pages+0x12/0x50
sysfs_read_file+0xaf/0x1a0ioctl(LOOP_CLR_FD):
wait_for_common+0x12c/0x180
? try_to_wake_up+0x2a0/0x2a0
wait_for_completion+0x18/0x20
sysfs_deactivate+0x178/0x180
? sysfs_addrm_finish+0x43/0x70
? sysfs_addrm_start+0x1d/0x20
sysfs_addrm_finish+0x43/0x70
sysfs_hash_and_remove+0x85/0xa0
sysfs_remove_group+0x59/0x100
loop_clr_fd+0x1dc/0x3f0 [loop]
lo_ioctl+0x223/0x7a0 [loop]Instead of taking the lo_ctl_mutex from sysfs code, take the inner
lo->lo_lock, to protect the access to the backing_file data.Thanks to Tejun for help debugging and finding a solution.
Cc: Milan Broz
Cc: Tejun Heo
Signed-off-by: Kay Sievers
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit d5e2003c2bcda93a8f2e668eb4642d70c9c38301 upstream.
We have a problem where if a user specifies discard but doesn't actually support
it we will return EOPNOTSUPP from btrfs_discard_extent. This is a problem
because this gets called (in a fashion) from the tree log recovery code, which
has a nice little BUG_ON(ret) after it, which causes us to fail the tree log
replay. So instead detect wether our devices support discard when we're adding
them and then don't issue discards if we know that the device doesn't support
it. And just for good measure set ret = 0 in btrfs_issue_discard just in case
we still get EOPNOTSUPP so we don't screw anybody up like this again. Thanks,Signed-off-by: Josef Bacik
Signed-off-by: Chris Mason
Signed-off-by: Greg Kroah-Hartman -
commit 6d3321e8e2b3bf6a5892e2ef673c7bf536e3f904 upstream.
MTRR rendezvous sequence using stop_one_cpu_nowait() can potentially
happen in parallel with another system wide rendezvous using
stop_machine(). This can lead to deadlock (The order in which
works are queued can be different on different cpu's. Some cpu's
will be running the first rendezvous handler and others will be running
the second rendezvous handler. Each set waiting for the other set to join
for the system wide rendezvous, leading to a deadlock).MTRR rendezvous sequence is not implemented using stop_machine() as this
gets called both from the process context aswell as the cpu online paths
(where the cpu has not come online and the interrupts are disabled etc).
stop_machine() works with only online cpus.For now, take the stop_machine mutex in the MTRR rendezvous sequence that
gets called from an online cpu (here we are in the process context
and can potentially sleep while taking the mutex). And the MTRR rendezvous
that gets triggered during cpu online doesn't need to take this stop_machine
lock (as the stop_machine() already ensures that there is no cpu hotplug
going on in parallel by doing get_online_cpus())TBD: Pursue a cleaner solution of extending the stop_machine()
infrastructure to handle the case where the calling cpu is
still not online and use this for MTRR rendezvous sequence.fixes: https://bugzilla.novell.com/show_bug.cgi?id=672008
Reported-by: Vadim Kotelnikov
Signed-off-by: Suresh Siddha
Link: http://lkml.kernel.org/r/20110623182056.807230326@sbsiddha-MOBL3.sc.intel.com
Signed-off-by: H. Peter Anvin
Signed-off-by: Greg Kroah-Hartman -
commit 910ac68a2b80c7de95bc8488734067b1bb15d583 upstream.
If the client is in the process of resetting the session when it receives
a callback, then returning NFS4ERR_DELAY may cause a deadlock with the
DESTROY_SESSION call.Basically, if the client returns NFS4ERR_DELAY in response to the
CB_SEQUENCE call, then the server is entitled to believe that the
client is busy because it is already processing that call. In that
case, the server is perfectly entitled to respond with a
NFS4ERR_BACK_CHAN_BUSY to any DESTROY_SESSION call.Fix this by having the client reply with a NFS4ERR_BADSESSION in
response to the callback if it is resetting the session.Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit 55a673990ec04cf63005318bcf08c2b0046e5778 upstream.
Currently, there is no guarantee that we will call nfs4_cb_take_slot() even
though nfs4_callback_compound() will consistently call
nfs4_cb_free_slot() provided the cb_process_state has set the 'clp' field.
The result is that we can trigger the BUG_ON() upon the next call to
nfs4_cb_take_slot().This patch fixes the above problem by using the slot id that was taken in
the CB_SEQUENCE operation as a flag for whether or not we need to call
nfs4_cb_free_slot().
It also fixes an atomicity problem: we need to set tbl->highest_used_slotid
atomically with the check for NFS4_SESSION_DRAINING, otherwise we end up
racing with the various tests in nfs4_begin_drain_session().Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit 20618b21da0796115e81906d24ff1601552701b7 upstream.
When we have a situation that the number of pages we want
to encode is bigger then the size of the bio. (Which can
currently happen only when all IO is going to a single device
.e.g group_width==1) then the IO is submitted short and we
report back only the amount of bytes we actually wrote/read
and all is fine. BUT ...There was a bug that the current length counter was advanced
before the fail to add the extra page, and we come to a situation
that the CDB length was one-page longer then the actual bio size,
which is of course rejected by the osd-target.While here also fix the bio size calculation, in the case
that we received more then one group of devices.Signed-off-by: Boaz Harrosh
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit 9af7db3228acc286c50e3a0f054ec982efdbc6c6 upstream.
There were bugs in the case of partial layout where olo_comp_index
is not zero. This used to work and was tested but one of the later
cleanup SQUASHMEs broke it and was not tested since.Also add a dprint that specify those received layout parameters.
Everything else was already printed.Signed-off-by: Boaz Harrosh
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit 17edf2d79f1ea6dfdb4c444801d928953b9f98d6 upstream.
Fix the printk_once() so that it actually prints (didn't print before
due to a stray comma.)[ hpa: changed to an incremental patch and adjusted the description
accordingly. ]Signed-off-by: Len Brown
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1107151732480.18606@x980
Signed-off-by: H. Peter Anvin
Signed-off-by: Greg Kroah-Hartman -
commit 13589c437daf4c8e429b3236c0b923de1c9420d8 upstream.
CIFS cleanup_volume_info_contents() looks like having a memory
corruption problem.
When UNCip is set to "&vol->UNC[2]" in cifs_parse_mount_options(), it
should not be kfree()-ed in cleanup_volume_info_contents().Introduced in commit b946845a9dc523c759cae2b6a0f6827486c3221a
Signed-off-by: J.R. Okajima
Reviewed-by: Jeff Layton
Signed-off-by: Steve French
Signed-off-by: Greg Kroah-Hartman -
commit 8cf2d2399ab60842f55598bc1b00fd15503b9950 upstream.
Based on a patch from the PaX Team, found during a clang analysis pass.
Signed-off-by: Mathias Krause
Acked-by: Mauro Carvalho Chehab
Cc: PaX Team
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 338d0f0a6fbc82407864606f5b64b75aeb3c70f2 upstream.
Signed-off-by: Timo Warns
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit fa71f447065f676157ba6a2c121ba419818fc559 upstream.
Running the cthon tests on a recent kernel caused this message to pop
occasionally:CIFS VFS: did not end path lookup where expected namelen is 0
Some added debugging showed that namelen and dfsplen were both 0 when
this occurred. That means that the read_seqretry returned true.Assuming that the comment inside the if statement is true, this should
be harmless and just means that we raced with a rename. If that is the
case, then there's no need for alarm and we can demote this to cFYI.While we're at it, print the dfsplen too so that we can see what
happened here if the message pops during debugging.Cc: Al Viro
Signed-off-by: Jeff Layton
Signed-off-by: Steve French
Signed-off-by: Greg Kroah-Hartman -
commit 1dd75f91ae713049eb6baaa640078f3a6549e522 upstream.
(!msk & 0x01) should be !(msk & 0x01)
Signed-off-by: Jonghwan Choi
Link: http://lkml.kernel.org/r/1311229754-6003-1-git-send-email-jhbird.choi@samsung.com
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman
18 Aug, 2011
4 commits
-
commit aba8d056078e47350d85b06a9cabd5afcc4b72ea upstream.
In addition to /etc/perfconfig and $HOME/.perfconfig, perf looks for
configuration in the file ./config, imitating git which looks at
$GIT_DIR/config. If ./config is not a perf configuration file, it
fails, or worse, treats it as a configuration file and changes behavior
in some unexpected way."config" is not an unusual name for a file to be lying around and perf
does not have a private directory dedicated for its own use, so let's
just stop looking for configuration in the cwd. Callers needing
context-sensitive configuration can use the PERF_CONFIG environment
variable.Requested-by: Christian Ohm
Cc: 632923@bugs.debian.org
Cc: Ben Hutchings
Cc: Christian Ohm
Cc: Ingo Molnar
Cc: Paul Mackerras
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/20110805165838.GA7237@elie.gateway.2wire.net
Signed-off-by: Jonathan Nieder
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Greg Kroah-Hartman -
commit d5811e8731213f80c80d89e980505052f16aca1c upstream.
Attempting to try and turn off disconnected display hw in the
hotput handler lead to more problems than it helped. For
now just register an event and only attempt the do something
interesting with DP. Other connectors are just too problematic:
- Some systems have an HPD pin assigned to LVDS, but it's rarely
if ever connected properly and we don't really care about hpd
events on LVDS anyway since it's always connected.
- The HPD pin is wired up correctly for eDP, but we don't really
have to do anything since the events since it's always connected.
- Some HPD pins fire more than once when you connect/disconnect
- etc.Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=39882Signed-off-by: Alex Deucher
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman -
commit 33ae1827d6c3c79c5957536ec29d5a8780623147 upstream.
Need to add support for 4 crtcs when setting the possible crtcs
for the encoders.Signed-off-by: Alex Deucher
Signed-off-by: Dave Airlie
Signed-off-by: Greg Kroah-Hartman
