Age | Commit message (Collapse) | Author |
|
This patch addresses a v3.5+ regression in iscsi-target where TX thread
process context -> handle_response_queue() execution is allowed to run
unbounded while servicing constant outgoing flow of ISTATE_SEND_DATAIN
response state.
This ends up preventing memory release of StatSN acknowledged commands
in a timely manner when under heavy large block streaming DATAIN
workloads.
The regression bug was initially introduced with:
commit 6f3c0e69a9c20441bdc6d3b2d18b83b244384ec6
Author: Andy Grover <agrover@redhat.com>
Date: Tue Apr 3 15:51:09 2012 -0700
target/iscsi: Refactor target_tx_thread immediate+response queue loops
Go ahead and follow original iscsi_target_tx_thread() logic and check
to break for immediate queue processing after each DataIN Sequence and/or
Response PDU has been sent.
Reported-by: Benjamin ESTRABAUD <be@mpstor.com>
Cc: Andy Grover <agrover@redhat.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
|
|
Benny Halevy reported the following oops when testing RHEL6:
<7>nfs_update_inode: inode 892950 mode changed, 0040755 to 0100644
<1>BUG: unable to handle kernel NULL pointer dereference at (null)
<1>IP: [<ffffffffa02a52c5>] nfs_closedir+0x15/0x30 [nfs]
<4>PGD 81448a067 PUD 831632067 PMD 0
<4>Oops: 0000 [#1] SMP
<4>last sysfs file: /sys/kernel/mm/redhat_transparent_hugepage/enabled
<4>CPU 6
<4>Modules linked in: fuse bonding 8021q garp ebtable_nat ebtables be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i cxgb4 cxgb3i libcxgbi cxgb3 mdio ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi softdog bridge stp llc xt_physdev ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 xt_multiport iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 dm_round_robin dm_multipath objlayoutdriver2(U) nfs(U) lockd fscache auth_rpcgss nfs_acl sunrpc vhost_net macvtap macvlan tun kvm_intel kvm be2net igb dca ptp pps_core microcode serio_raw sg iTCO_wdt iTCO_vendor_support i7core_edac edac_core shpchp ext4 mbcache jbd2 sd_mod crc_t10dif ahci dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_wait_scan]
<4>
<4>Pid: 6332, comm: dd Not tainted 2.6.32-358.el6.x86_64 #1 HP ProLiant DL170e G6 /ProLiant DL170e G6
<4>RIP: 0010:[<ffffffffa02a52c5>] [<ffffffffa02a52c5>] nfs_closedir+0x15/0x30 [nfs]
<4>RSP: 0018:ffff88081458bb98 EFLAGS: 00010292
<4>RAX: ffffffffa02a52b0 RBX: 0000000000000000 RCX: 0000000000000003
<4>RDX: ffffffffa02e45a0 RSI: ffff88081440b300 RDI: ffff88082d5f5760
<4>RBP: ffff88081458bba8 R08: 0000000000000000 R09: 0000000000000000
<4>R10: 0000000000000772 R11: 0000000000400004 R12: 0000000040000008
<4>R13: ffff88082d5f5760 R14: ffff88082d6e8800 R15: ffff88082f12d780
<4>FS: 00007f728f37e700(0000) GS:ffff8800456c0000(0000) knlGS:0000000000000000
<4>CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
<4>CR2: 0000000000000000 CR3: 0000000831279000 CR4: 00000000000007e0
<4>DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
<4>DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
<4>Process dd (pid: 6332, threadinfo ffff88081458a000, task ffff88082fa0e040)
<4>Stack:
<4> 0000000040000008 ffff88081440b300 ffff88081458bbf8 ffffffff81182745
<4><d> ffff88082d5f5760 ffff88082d6e8800 ffff88081458bbf8 ffffffffffffffea
<4><d> ffff88082f12d780 ffff88082d6e8800 ffffffffa02a50a0 ffff88082d5f5760
<4>Call Trace:
<4> [<ffffffff81182745>] __fput+0xf5/0x210
<4> [<ffffffffa02a50a0>] ? do_open+0x0/0x20 [nfs]
<4> [<ffffffff81182885>] fput+0x25/0x30
<4> [<ffffffff8117e23e>] __dentry_open+0x27e/0x360
<4> [<ffffffff811c397a>] ? inotify_d_instantiate+0x2a/0x60
<4> [<ffffffff8117e4b9>] lookup_instantiate_filp+0x69/0x90
<4> [<ffffffffa02a6679>] nfs_intent_set_file+0x59/0x90 [nfs]
<4> [<ffffffffa02a686b>] nfs_atomic_lookup+0x1bb/0x310 [nfs]
<4> [<ffffffff8118e0c2>] __lookup_hash+0x102/0x160
<4> [<ffffffff81225052>] ? selinux_inode_permission+0x72/0xb0
<4> [<ffffffff8118e76a>] lookup_hash+0x3a/0x50
<4> [<ffffffff81192a4b>] do_filp_open+0x2eb/0xdd0
<4> [<ffffffff8104757c>] ? __do_page_fault+0x1ec/0x480
<4> [<ffffffff8119f562>] ? alloc_fd+0x92/0x160
<4> [<ffffffff8117de79>] do_sys_open+0x69/0x140
<4> [<ffffffff811811f6>] ? sys_lseek+0x66/0x80
<4> [<ffffffff8117df90>] sys_open+0x20/0x30
<4> [<ffffffff8100b072>] system_call_fastpath+0x16/0x1b
<4>Code: 65 48 8b 04 25 c8 cb 00 00 83 a8 44 e0 ff ff 01 5b 41 5c c9 c3 90 55 48 89 e5 53 48 83 ec 08 0f 1f 44 00 00 48 8b 9e a0 00 00 00 <48> 8b 3b e8 13 0c f7 ff 48 89 df e8 ab 3d ec e0 48 83 c4 08 31
<1>RIP [<ffffffffa02a52c5>] nfs_closedir+0x15/0x30 [nfs]
<4> RSP <ffff88081458bb98>
<4>CR2: 0000000000000000
I think this is ultimately due to a bug on the server. The client had
previously found a directory dentry. It then later tried to do an atomic
open on a new (regular file) dentry. The attributes it got back had the
same filehandle as the previously found directory inode. It then tried
to put the filp because it failed the aops tests for O_DIRECT opens, and
oopsed here because the ctx was still NULL.
Obviously the root cause here is a server issue, but we can take steps
to mitigate this on the client. When nfs_fhget is called, we always know
what type of inode it is. In the event that there's a broken or
malicious server on the other end of the wire, the client can end up
crashing because the wrong ops are set on it.
Have nfs_find_actor check that the inode type is correct after checking
the fileid. The fileid check should rarely ever match, so it should only
rarely ever get to this check. In the case where we have a broken
server, we may see two different inodes with the same i_ino, but the
client should be able to cope with them without crashing.
This should fix the oops reported here:
https://bugzilla.redhat.com/show_bug.cgi?id=913660
Reported-by: Benny Halevy <bhalevy@tonian.com>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
|
|
If something has failed while the array was read-auto,
then when we switch to 'active' we need to update the metadata.
This will happen anyway but it is good to expedite it, and
also to ensure any failed device has been released by the
underlying device before we try to action the ioctl which
caused us to switch to 'active' mode.
Reported-by: Joe Lawrence <Joe.Lawrence@stratus.com>
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86/EFI changes from Peter Anvin:
- Improve the initrd handling in the EFI boot stub by allowing forward
slashes in the pathname - from Chun-Yi Lee.
- Cleanup code duplication in the EFI mixed kernel/firmware code - from
Satoru Takeuchi.
- efivarfs bug fixes for more strict filename validation, with lots of
input from Al Viro.
* 'x86-efi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86, efi: remove duplicate code in setup_arch() by using, efi_is_native()
efivarfs: guid part of filenames are case-insensitive
efivarfs: Validate filenames much more aggressively
efivarfs: Use sizeof() instead of magic number
x86, efi: Allow slash in file path of initrd
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull more x86 fixes from Peter Anvin:
"Additional x86 fixes. Three of these patches are pure documentation,
two are pretty trivial; the remaining one fixes boot problems on some
non-BIOS machines."
* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
x86: Make sure we can boot in the case the BDA contains pure garbage
x86, efi: Mark disable_runtime as __initdata
x86, doc: Fix incorrect comment about 64-bit code segment descriptors
doc, kernel-parameters: Document 'console=hvc<n>'
doc, xen: Mention 'earlyprintk=xen' in the documentation.
ACPI: Overriding ACPI tables via initrd only works with an initrd and on X86
|
|
Setting this secFlg allows usage of dfs where some servers require
signing and others don't.
Signed-off-by: Martijn de Gouw <martijn.de.gouw@prodrive.nl>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
|
|
Samba rejected libreoffice's attempt to open a file with illegal
O_EXCL (without O_CREAT). Mask this flag off (as the local
linux file system case does) for this case, so that we
don't have disable Unix Extensions unnecessarily due to
the Samba error (Samba server is also being fixed).
See https://bugzilla.samba.org/show_bug.cgi?id=9519
Reviewed-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <smfrench@gmail.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
|
|
Kjell Braden reported this oops:
[ 833.211970] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 833.212816] IP: [< (null)>] (null)
[ 833.213280] PGD 1b9b2067 PUD e9f7067 PMD 0
[ 833.213874] Oops: 0010 [#1] SMP
[ 833.214344] CPU 0
[ 833.214458] Modules linked in: des_generic md4 nls_utf8 cifs vboxvideo drm snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq bnep rfcomm snd_timer bluetooth snd_seq_device ppdev snd vboxguest parport_pc joydev mac_hid soundcore snd_page_alloc psmouse i2c_piix4 serio_raw lp parport usbhid hid e1000
[ 833.215629]
[ 833.215629] Pid: 1752, comm: mount.cifs Not tainted 3.0.0-rc7-bisectcifs-fec11dd9a0+ #18 innotek GmbH VirtualBox/VirtualBox
[ 833.215629] RIP: 0010:[<0000000000000000>] [< (null)>] (null)
[ 833.215629] RSP: 0018:ffff8800119c9c50 EFLAGS: 00010282
[ 833.215629] RAX: ffffffffa02186c0 RBX: ffff88000c427780 RCX: 0000000000000000
[ 833.215629] RDX: 0000000000000000 RSI: ffff88000c427780 RDI: ffff88000c4362e8
[ 833.215629] RBP: ffff8800119c9c88 R08: ffff88001fc15e30 R09: 00000000d69515c7
[ 833.215629] R10: ffffffffa0201972 R11: ffff88000e8f6a28 R12: ffff88000c4362e8
[ 833.215629] R13: 0000000000000000 R14: 0000000000000000 R15: ffff88001181aaa6
[ 833.215629] FS: 00007f2986171700(0000) GS:ffff88001fc00000(0000) knlGS:0000000000000000
[ 833.215629] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 833.215629] CR2: 0000000000000000 CR3: 000000001b982000 CR4: 00000000000006f0
[ 833.215629] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 833.215629] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 833.215629] Process mount.cifs (pid: 1752, threadinfo ffff8800119c8000, task ffff88001c1c16f0)
[ 833.215629] Stack:
[ 833.215629] ffffffff8116a9b5 ffff8800119c9c88 ffffffff81178075 0000000000000286
[ 833.215629] 0000000000000000 ffff88000c4276c0 ffff8800119c9ce8 ffff8800119c9cc8
[ 833.215629] ffffffff8116b06e ffff88001bc6fc00 ffff88000c4276c0 ffff88000c4276c0
[ 833.215629] Call Trace:
[ 833.215629] [<ffffffff8116a9b5>] ? d_alloc_and_lookup+0x45/0x90
[ 833.215629] [<ffffffff81178075>] ? d_lookup+0x35/0x60
[ 833.215629] [<ffffffff8116b06e>] __lookup_hash.part.14+0x9e/0xc0
[ 833.215629] [<ffffffff8116b1d6>] lookup_one_len+0x146/0x1e0
[ 833.215629] [<ffffffff815e4f7e>] ? _raw_spin_lock+0xe/0x20
[ 833.215629] [<ffffffffa01eef0d>] cifs_do_mount+0x26d/0x500 [cifs]
[ 833.215629] [<ffffffff81163bd3>] mount_fs+0x43/0x1b0
[ 833.215629] [<ffffffff8117d41a>] vfs_kern_mount+0x6a/0xd0
[ 833.215629] [<ffffffff8117e584>] do_kern_mount+0x54/0x110
[ 833.215629] [<ffffffff8117fdc2>] do_mount+0x262/0x840
[ 833.215629] [<ffffffff81108a0e>] ? __get_free_pages+0xe/0x50
[ 833.215629] [<ffffffff8117f9ca>] ? copy_mount_options+0x3a/0x180
[ 833.215629] [<ffffffff8118075d>] sys_mount+0x8d/0xe0
[ 833.215629] [<ffffffff815ece82>] system_call_fastpath+0x16/0x1b
[ 833.215629] Code: Bad RIP value.
[ 833.215629] RIP [< (null)>] (null)
[ 833.215629] RSP <ffff8800119c9c50>
[ 833.215629] CR2: 0000000000000000
[ 833.238525] ---[ end trace ec00758b8d44f529 ]---
When walking down the path on the server, it's possible to hit a
symlink. The path walking code assumes that the caller will handle that
situation properly, but cifs_get_root() isn't set up for it. This patch
prevents the oops by simply returning an error.
A better solution would be to try and chase the symlinks here, but that's
fairly complicated to handle.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=53221
Reported-and-tested-by: Kjell Braden <afflux@pentabarf.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Steve French <sfrench@us.ibm.com>
|
|
This doesn't seem to actually help and we have an alternate
multi-threading approach waiting in the wings, so just get
rid of this config option and associated code.
As a bonus, we remove one use of CONFIG_EXPERIMENTAL
Cc: Dan Williams <djbw@fb.com>
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: NeilBrown <neilb@suse.de>
|
|
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
On non-BIOS platforms it is possible that the BIOS data area contains
garbage instead of being zeroed or something equivalent (firmware
people: we are talking of 1.5K here, so please do the sane thing.)
We need on the order of 20-30K of low memory in order to boot, which
may grow up to < 64K in the future. We probably want to avoid the
lowest of the low memory. At the same time, it seems extremely
unlikely that a legitimate EBDA would ever reach down to the 128K
(which would require it to be over half a megabyte in size.) Thus,
pick 128K as the cutoff for "this is insane, ignore." We may still
end up reserving a bunch of extra memory on the low megabyte, but that
is not really a major issue these days. In the worst case we lose
512K of RAM.
This code really should be merged with trim_bios_range() in
arch/x86/kernel/setup.c, but that is a bigger patch for a later merge
window.
Reported-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: Matt Fleming <matt.fleming@intel.com>
Cc: <stable@vger.kernel.org>
Link: http://lkml.kernel.org/n/tip-oebml055yyfm8yxmria09rja@git.kernel.org
|
|
Building sctp may fail with:
In function ‘copy_from_user’,
inlined from ‘sctp_getsockopt_assoc_stats’ at
net/sctp/socket.c:5656:20:
arch/x86/include/asm/uaccess_32.h:211:26: error: call to
‘copy_from_user_overflow’ declared with attribute error: copy_from_user()
buffer size is not provably correct
if built with W=1 due to a missing parameter size validation
before the call to copy_from_user.
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild
Pull kconfig changes from Michal Marek:
"I forgot to send a pull request in time for the v3.8-rc1 merge window,
so the list is a bit longer this time:
- menuconfig enables extended colors in ncurses if the wide-character
version is used.
- CONFIG_ prefix can be specified in the environment to make life
easier for people using kconfig multiple times in a single tree (no
functional change in the kernel kconfig usage).
- kconfig aborts on OOM.
- inputboxes in menuconfig allow to move the cursor.
- menuconfig has Save/Load buttons now.
- xconfig build fix with new g++ and Qt3.
- nconfig color scheme fix and help text update.
- make oldconfig prints newlines when output is redirected.
- some other minor fixes."
* 'kconfig' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
kbuild: Fix missing '\n' for NEW symbols in yes "" | make oldconfig >conf.new
kconfig: nconf: rewrite labels of function keys line
kconfig: nconf: rewrite help texts
kconfig: fix a compiliation error when using make xconfig
nconf: function keys line, change background color for better readability
menuconfig: Get rid of the top-level entries for "Load an Alternate/Save an Alternate"
menuconfig: Add Save/Load buttons
kconfig:lxdialog: remove duplicate code
menuconfig:inputbox: support navigate input position
kconfig: document use of CONFIG_ environment variable
scripts/kconfig: ensure we use proper CONFIG_ prefix
merge_config.sh: Add option to specify output dir
Revert "kconfig-language: add to hints"
kconfig: Regenerate lexer
kconfig: Fix malloc handling in conf tools
kconfig: get CONFIG_ prefix from the environment
kconfig: add a function to get the CONFIG_ prefix
kconfig: remove CONFIG_ from string constants
menuconfig: fix extended colors ncurses support
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild
Pull misc non-critical kbuild changes from Michal Marek:
- Fix for make TAGS
- Fix for make rpm
- Some new coccinelle semantic patches
* 'misc' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
scripts/coccinelle: find constant additions that could be bit ors
coccicheck: Allow to show the executed command line
coccicheck: Allow the user to give a V= (verbose) argument
scripts/coccinelle/misc/memcpy-assign.cocci: Replace memcpy with struct assignment
kbuild: clear KBUILD_SRC when calling 'make' in RPM spec
scripts/coccinelle/misc/semicolon.cocci: Add unneeded semicolon test
scripts/tags.sh: Fix regex syntax for etags
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild
Pull kbuild changes from Michal Marek:
- Alias generation in modpost is cross-compile safe.
- kernel/timeconst.h is now generated using a bc script instead of
perl.
- scripts/link-vmlinux.sh now works with an alternative
$KCONFIG_CONFIG.
- destination-y for exported headers is supported in Kbuild files
again.
- depmod is called with -P $CONFIG_SYMBOL_PREFIX on architectures that
need it.
- CONFIG_DEBUG_INFO_REDUCED disables var-tracking
- scripts/setlocalversion works with too much translated locales ;)
* 'kbuild' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild:
kbuild: Fix reading of .config in link-vmlinux.sh
kbuild: Unset language specific variables in setlocalversion script
Kbuild: Disable var tracking with CONFIG_DEBUG_INFO_REDUCED
depmod: pass -P $CONFIG_SYMBOL_PREFIX
kbuild: Fix destination-y for installed headers
scripts/link-vmlinux.sh: source variables from KCONFIG_CONFIG
kernel: Replace timeconst.pl with a bc script
mod/file2alias: make modalias generation safe for cross compiling
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"Nothing serious but just a few regression fixes and quirk additions,
such as emu1010 firmware loading fixes, M-Audio AP192 SPDIF fix, and
HD-audio HDMI jack detection fix."
* tag 'sound-3.9' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: emu10k1: Allow to switch hardware sampe rate on EMU
ALSA: hda - Enable beep for ASUS EeeBox EBP1501P
ALSA: emu10k1: Load firmware when it was already cached
ALSA: ice1724: M-Audio Audiophile192: Fix SPDIF input
ALSA: bt87x: Make load_all parameter working again
ALSA: emu10k1: Fix regression in emu1010 firmware loading
ALSA: hda - hdmi: Make jacks phantom, if they're not detectable
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4
Pull ext4 regression fix from Theodore Ts'o:
"This fixes a real brown paper bag bug which causes ext4 to choke on
file systems larger than 512GB."
* tag 'ext4_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
ext4: fix extent status tree regression for file systems > 512GB
|
|
This fixes a regression introduced by commit f7fec032aa782. The
problem was that the extents status flags caused us to mask out block
numbers smaller than 2**28 blocks. Since we didn't test with file
systems smaller than 512GB, we didn't notice this during the
development cycle.
A typical failure looks like this:
EXT4-fs error (device sdb1): htree_dirblock_to_tree:919: inode #172235804: block
152052301: comm ls: bad entry in directory: rec_len is smaller than minimal -
offset=0(0), inode=0, rec_len=0, name_len=0
... where 'debugfs -R "stat <172235804>" /dev/sdb1' reports that the
inode has block number 688923213. When viewed in hex, block number
152052301 (from the syslog) is 0x910224D, while block number 688923213
is 0x2910224D. Note the missing "0x20000000" in the block number.
Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Verified-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Reported-by: Dave Jones <davej@redhat.com>
Verified-by: Dave Jones <davej@redhat.com>
Cc: Zheng Liu <gnehzuil.liu@gmail.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
|
|
It is sufficient to check the return code of
ecryptfs_find_daemon_by_euid(). If it returns 0, it always sets the
daemon pointer to point to a valid ecryptfs_daemon.
Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Reported-by: Kees Cook <keescook@chromium.org>
|
|
For SD8688, FUNC_INIT command is queued before fw_ready flag is
set. This causes the following crash as lbs_thread blocks any
command if fw_ready is not set.
[ 209.338953] [<c0502248>] (__schedule+0x610/0x764) from [<bf20ae24>] (__lbs_cmd+0xb8/0x130 [libertas])
[ 209.348340] [<bf20ae24>] (__lbs_cmd+0xb8/0x130 [libertas]) from [<bf222474>] (if_sdio_finish_power_on+0xec/0x1b0 [libertas_sdio])
[ 209.360136] [<bf222474>] (if_sdio_finish_power_on+0xec/0x1b0 [libertas_sdio]) from [<bf2226c4>] (if_sdio_power_on+0x18c/0x20c [libertas_sdio])
[ 209.373052] [<bf2226c4>] (if_sdio_power_on+0x18c/0x20c [libertas_sdio]) from [<bf222944>] (if_sdio_probe+0x200/0x31c [libertas_sdio])
[ 209.385316] [<bf222944>] (if_sdio_probe+0x200/0x31c [libertas_sdio]) from [<bf01d820>] (sdio_bus_probe+0x94/0xfc [mmc_core])
[ 209.396748] [<bf01d820>] (sdio_bus_probe+0x94/0xfc [mmc_core]) from [<c02e729c>] (driver_probe_device+0x12c/0x348)
[ 209.407214] [<c02e729c>] (driver_probe_device+0x12c/0x348) from [<c02e7530>] (__driver_attach+0x78/0x9c)
[ 209.416798] [<c02e7530>] (__driver_attach+0x78/0x9c) from [<c02e5658>] (bus_for_each_dev+0x50/0x88)
[ 209.425946] [<c02e5658>] (bus_for_each_dev+0x50/0x88) from [<c02e6810>] (bus_add_driver+0x108/0x268)
[ 209.435180] [<c02e6810>] (bus_add_driver+0x108/0x268) from [<c02e782c>] (driver_register+0xa4/0x134)
[ 209.444426] [<c02e782c>] (driver_register+0xa4/0x134) from [<bf22601c>] (if_sdio_init_module+0x1c/0x3c [libertas_sdio])
[ 209.455339] [<bf22601c>] (if_sdio_init_module+0x1c/0x3c [libertas_sdio]) from [<c00085b8>] (do_one_initcall+0x98/0x174)
[ 209.466236] [<c00085b8>] (do_one_initcall+0x98/0x174) from [<c0076504>] (load_module+0x1c5c/0x1f80)
[ 209.475390] [<c0076504>] (load_module+0x1c5c/0x1f80) from [<c007692c>] (sys_init_module+0x104/0x128)
[ 209.484632] [<c007692c>] (sys_init_module+0x104/0x128) from [<c0008c40>] (ret_fast_syscall+0x0/0x38)
Fix it by setting fw_ready flag prior to queuing FUNC_INIT command.
Cc: <stable@vger.kernel.org> # 3.5+
Reported-by: Lubomir Rintel <lkundrak@v3.sk>
Tested-by: Lubomir Rintel <lkundrak@v3.sk>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
If CONFIG_MAC80211_MESH is not set, cfg80211 will now allow advertising
interface combinations with NL80211_IFTYPE_MESH_POINT present.
Add appropriate ifdefs to avoid running into errors.
Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
Maximum delay for waking up card is 50 ms. Because of typo in
counter, this delay goes to 500ms. This patch fixes the bug.
Cc: <stable@vger.kernel.org> # 3.2+
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
On many different chips, important aspects of the MAC state are not
fully cleared by a warm reset. This can show up as tx/rx hangs, those
annoying "DMA failed to stop in 10 ms..." messages or other quirks.
On AR933x, the chip can occasionally get stuck in a way that only a
driver unload/reload or a reboot would bring it back to life.
With this patch, a full reset is issued when bringing the chip out of
FULL-SLEEP state (after idle), or if either Rx or Tx was not shut down
properly. This makes the DMA related error messages disappear completely
in my tests on AR933x, and the chip does not get stuck anymore.
Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
This spin lock was not initialized.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
The ath9k commit 2ef167557c0a26c88162ecffb017bfcc51eb7b29
(ath9k: fix signal strength reporting issues) fixed an issue where the
reported per-frame signal strength reported to mac80211 was being
overwritten with an internal average. The same issue is also present
in ath9k_htc.
In addition to preventing the driver from overwriting the value, this
commit also ensures that the internal average (which is used for ANI)
only tracks beacons of the AP that we're connected to.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
RSSI is being stored internally as s8 in several places. The indication
of an unset RSSI value, ATH_RSSI_DUMMY_MARKER, was supposed to have been
set to 127, but ended up being set to 0x127 because of a code cleanup
mistake. This could lead to invalid signal strength values in a few
places.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Cc: stable@vger.kernel.org
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes
|
|
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
Use the infrastructure for delivering VMBUS interrupts using a
special vector. With this patch, we can now properly handle
the VMBUS interrupts that can be delivered on any CPU. Also,
turn on interrupt load balancing as well.
This patch requires the infrastructure that was implemented in the patch:
X86: Handle Hyper-V vmbus interrupts as special hypervisor interrupts
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
This USB ethernet adapter was purchased in anodyne packaging
from the computer store adjacent to linux.conf.au 2013 in
Canberra (Australia). A web search shows other recent
purchasers in Lancaster (UK) and Seattle (USA). Just like an
emergent virus, our age of e-commerce and airmail allows
underdocumented hardware to spread around the world instantly
using the vector of ridiculously low prices.
Paige Thompson, infected via eBay, discovered that the HG20F9
is a copy of the Asix 88772B; many viruses copy the RNA of
other viruses. See Paige's work at
<https://github.com/paigeadele/HG20F9>.
This patch uses her discovery to update the restructured Asix
driver in the current kernel.
Just as some viruses inhabit seemingly-healthy cells, the
HG20F9 uses the Vendor ID 0x066b assigned to Linksys Inc.
For the present there is no clash of Product ID 0x20f9.
Signed-off-by: Glen Turner <gdt@gdt.id.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Tag all Huawei NCM devices as WWAN modems, as we don't know of any which
are not. This is necessary for userspace clients to know that the device
requires further setup on e.g. an AT-capable serial ports before
connectivity is available.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Since commit 86564c3f "bnx2x: Remove many sparse warnings" UDP
csum offload is broken for 57710/57711. Fix return value.
Signed-off-by: Dmitry Kravkov <dmitry@broadcom.com>
CC: Ariel Elior <ariele@broadcom.com>
CC: Yuval Mintz <yuvalmin@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
charset comes from skb->data. It's a number in the 0-255 range.
If we have debugging turned on then this could cause a read beyond
the end of the array.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
While PROC_CN_MCAST_LISTEN/IGNORE is entirely advisory, it was possible
for an unprivileged user to turn off notifications for all listeners by
sending PROC_CN_MCAST_IGNORE. Instead, require the same privileges as
required for a multicast bind.
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: Evgeniy Polyakov <zbr@ioremap.net>
Cc: Matt Helsley <matthltc@us.ibm.com>
Cc: stable@vger.kernel.org
Acked-by: Evgeniy Polyakov <zbr@ioremap.net>
Acked-by: Matt Helsley <matthltc@us.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
compares as NULL
When taking an address of an extern array, gcc quite naturally should be
able to say "an address of an object can never be NULL" and just
optimize away the test entirely.
However, the new alternate sysrq reset code (commit 154b7a489a5b:
"Input: sysrq - allow specifying alternate reset sequence") did exactly
that, and declared platform_sysrq_reset_seq[] as a weak array, and
expecting that testing the address of the array would show whether it
actually got linked against something or not.
And that doesn't work with all gcc versions. Clearly it works with
*some* versions of gcc, and maybe it's even supposed to work, but it
really is a very fragile concept.
So instead of testing the address of the weak variable, just create a
weak instance of that array that is empty. If some platform then has a
real platform_sysrq_reset_seq[] that overrides our weak one, the linker
will switch to that one, and it all works without any run-time
conditionals at all.
Reported-by: Dave Airlie <airlied@gmail.com>
Cc: David Howells <dhowells@redhat.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Adds a dma_request_slave_channel_compat() wrapper which accepts
both the arguments from dma_request_channel() and
dma_request_slave_channel(). Based on whether the driver is
instantiated via DT, the appropriate channel request call will be
made.
This allows for a much cleaner migration of drivers to the
dmaengine DT API as platforms continue to be mixed between those
that boot using DT and those that do not.
Suggested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Matt Porter <mporter@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
|
|
The stack vma is designed to grow automatically (marked with VM_GROWSUP
or VM_GROWSDOWN depending on architecture) when an access is made beyond
the existing boundary. However, particularly if you have not limited
your stack at all ("ulimit -s unlimited"), this can cause the stack to
grow even if the access was really just one past *another* segment.
And that's wrong, especially since we first grow the segment, but then
immediately later enforce the stack guard page on the last page of the
segment. So _despite_ first growing the stack segment as a result of
the access, the kernel will then make the access cause a SIGSEGV anyway!
So do the same logic as the guard page check does, and consider an
access to within one page of the next segment to be a bad access, rather
than growing the stack to abut the next segment.
Reported-and-tested-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
|
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
|
|
The upstream kernel ABI (v3) is different from current out-of-tree (v2):
* no-legacy-syscalls
* user_regs_struct layout has changed
So we rev up the ABI version
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
|
|
ptrace regset interface relies on ELF_NGREG for ceiling the size of user
request. So any larger request (even if legit) would be clipped.
The existing def of ELF_NGREG didn't use user_regs_struct and was
technically one placeholder short (stop_pc) - although the current code
would still work because pt_regs includes a bunch of extra fields,
making
ELF_NGREG >= sizeof(struct user_regs_struct)/sizeof(long)
But we need to remove this ambiguity, specially since pt_regs should NOT
be directly associated with with anything userspace-ish.
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
|
|
Selecting BACKLIGHT_CLASS_DEVICE doesn't guarantee that any of its
dependencies are enabled, and these are complicated. Depending isn't ideal
for configuration UI purposes, but is probably more appropriate here.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
|
|
I've got a report of build failure on ideapad-laptop, which shows
drivers/built-in.o: In function `ideapad_acpi_notify':
ideapad-laptop.c:(.text+0x63876a): undefined reference to `backlight_force_update'
drivers/built-in.o: In function `ideapad_acpi_remove':
ideapad-laptop.c:(.devexit.text+0x64a7): undefined reference to `backlight_device_unregister'
drivers/built-in.o: In function `ideapad_acpi_add':
ideapad-laptop.c:(.devinit.text+0x45e28): undefined reference to `backlight_device_register'
To select backlight subsystem can prevent this error from happening.
Also update comment for this driver.
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Ike Panhc <ike.pan@canonical.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
|
|
Add the two other i2c buses (vga and panel) from i915.
Chromebook Pixel has input and light sensor devices on these busses.
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
|
|
The Chromebook Pixel uses an isl29023 ambient light sensor on the PANEL
GMBus.
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
|
|
This will allow us to assign devices to buses by the type enum.
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
|
|
Instantiate the atmel mxt1664s touchscreen on this system.
The touchscreen may appear at two possible addresses:
0x4a in operational mode.
0x26 in bootloader mode.
Signed-off-by: Yufeng Shen <miletus@chromium.org>
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
|
|
This will allow support for devices that may appear at more than
one i2c address at boot time. The specific example is the atmel_mxt touch
devices, which may appear at a different address if it comes up
in bootloader mode.
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
|
|
Instantiate the atmel mxt224s trackpad on this system.
The trackpad may appear at two possible addresses:
0x4b in operational mode.
0x25 in bootloader mode.
Signed-off-by: Benson Leung <bleung@chromium.org>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
|
|
The driver will not quite work if someone unbinds the platform device
from the platform driver via sysfs (moreover it will bomb is the driver
built into the kernel as hp_wmi_bios_remove is marked as __exit and will
not be present in the kernel).
To fix it let's use platform_driver_probe() instead of
platform_driver_register(), which disables binding/unbinding via sysfs.
This also allows us to mark hp_wmi_bios_setup as __init and discard it
once module is initialized.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
|
|
We need to decrement "i" first because the current "i" was not allocated
succesfully. Also we should go free the way down to zero to avoid a
leak.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
|