aboutsummaryrefslogtreecommitdiffstats
path: root/net (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2011-02-14drm/radeon/kms: use linear aligned for evergreen/ni bo blitsAlex Deucher1-2/+2
Not only is linear aligned supposedly more performant, linear general is only supported by the CB in single slice mode. The texture hardware doesn't support linear general, but I think the hw automatically upgrades it to linear aligned. Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-02-14drm/radeon/kms: use linear aligned for 6xx/7xx bo blitsAlex Deucher1-2/+2
Not only is linear aligned supposedly more performant, linear general is only supported by the CB in single slice mode. The texture hardware doesn't support linear general, but I think the hw automatically upgrades it to linear aligned. Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-02-14drm/radeon: fix race between GPU reset and TTM delayed delete thread.Dave Airlie1-0/+4
My evergreen has been in a remote PC for week and reset has never once saved me from certain doom, I finally relocated to the box with a serial cable and noticed an oops when the GPU resets, and the TTM delayed delete thread tries to remove something from the GTT. This stops the delayed delete thread from executing across the GPU reset handler, and woot I can GPU reset now. Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-02-14drm/radeon/kms: evergreen/ni big endian fixes (v2)Alex Deucher4-10/+40
Based on 6xx/7xx endian fixes from Cédric Cano. v2: fix typo in shader Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-02-14drm/radeon/kms: 6xx/7xx big endian fixesCédric Cano6-20/+54
agd5f: minor cleanups Signed-off-by: Cédric Cano <ccano@interfaceconcept.com> Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-02-14drm/radeon/kms: atombios big endian fixesCédric Cano3-52/+52
agd5f: additional cleanups/fixes Signed-off-by: Cédric Cano <ccano@interfaceconcept.com> Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-02-14drm/radeon: 6xx/7xx non-kms endian fixesCédric Cano3-9/+34
agd5f: minor cleanups Signed-off-by: Cédric Cano <ccano@interfaceconcept.com> Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-02-14drm/radeon/kms: optimize CS state checking for r100->r500Marek Olšák4-12/+77
The colorbuffer, zbuffer, and texture states are checked only once when they get changed. This improves performance in the apps which emit lots of draw packets and few state changes. This drops performance in glxgears by a 1% or so, but glxgears is not a benchmark we care about. The time spent in the kernel when running Torcs dropped from 33% to 23% and the frame rate is higher, which is a good thing. r600 might need something like this as well. Signed-off-by: Marek Olšák <maraeo@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-02-14drm: do not leak kernel addresses via /proc/dri/*/vmaKees Cook1-4/+5
In the continuing effort to avoid kernel addresses leaking to unprivileged users, this patch switches to %pK for /proc/dri/*/vma. Signed-off-by: Kees Cook <kees.cook@canonical.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-02-14drm/radeon/kms: add connector table for mac g5 9600Alex Deucher2-0/+48
PPC Mac cards do not provide connector tables in their vbios. Their connector/encoder configurations must be hardcoded in the driver. verified by nyef on #radeon Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Cc: stable@kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-02-14radeon mkregtable: Add missing fclose() callsJesper Juhl1-1/+4
drivers/gpu/drm/radeon/mkregtable.c:parser_auth() almost always remembers to fclose(file) before returning, but it misses two spots. This is not really important since the process will exit shortly after and thus close the file for us, but being explicit prevents static analysis tools from complaining about leaked memory and missing fclose() calls and it also seems to be the prefered style of the existing code to explicitly close the file. So, here's a patch to add the two missing fclose() calls. Signed-off-by: Jesper Juhl <jj@chaosbits.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-02-14drm/radeon/kms: fix interlaced modes on dce4+Alex Deucher2-22/+20
- set scaler table clears the interleave bit, need to reset it in encoder quirks, this was already done for pre-dce4. - remove the interleave settings from set_base() functions this is now handled in the encoder quirks functions, and isn't technically part of the display base setup. - rename evergreen_do_set_base() to dce4_do_set_base() since it's used on both evergreen and NI asics. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=28182 Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Cc: stable@kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-02-14drm/radeon: fix memory debugging since d961db75ce86a84f1f04e91ad1014653ed7d9f46Dave Airlie1-2/+2
The old code dereferenced a value, the new code just needs to pass the ptr. fixes an oops looking at files in debugfs. cc: stable@kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
2011-02-13USB Network driver infrastructure: Fix leak when usb_autopm_get_interface() returns less than zero in kevent().Jesper Juhl1-1/+3
We'll leak the memory allocated to 'urb' in drivers/net/usb/usbnet.c:kevent() when we 'goto fail_lowmem' and the 'urb' variable goes out of scope while still completely unused. Signed-off-by: Jesper Juhl <jj@chaosbits.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-02-13Don't potentially dereference NULL in net/dcb/dcbnl.c:dcbnl_getapp()Jesper Juhl1-0/+3
nla_nest_start() may return NULL. If it does then we'll blow up in nla_nest_end() when we dereference the pointer. Signed-off-by: Jesper Juhl <jj@chaosbits.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-02-13net: dcb: application priority is per net_deviceJohn Fastabend1-1/+5
The app_data priority may not be the same for all net devices. In order for stacks with application notifiers to identify the specific net device dcb_app_type should be passed in the ptr. This allows handlers to use dev_get_by_name() to pin priority to net devices. Signed-off-by: John Fastabend <john.r.fastabend@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-02-13Revert "pci: use security_capable() when checking capablities during config space read"Linus Torvalds1-2/+1
This reverts commit 47970b1b2aa64464bc0a9543e86361a622ae7c03. It turns out it breaks several distributions. Looks like the stricter selinux checks fail due to selinux policies not being set to allow the access - breaking X, but also lspci. So while the change was clearly the RightThing(tm) to do in theory, in practice we have backwards compatibility issues making it not work. Reported-by: Dave Young <hidave.darkstar@gmail.com> Acked-by: David Airlie <airlied@linux.ie> Acked-by: Alex Riesen <raa.lkml@gmail.com> Cc: Eric Paris <eparis@redhat.com> Cc: Chris Wright <chrisw@sous-sol.org> Cc: James Morris <jmorris@namei.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-02-12devicetree-discuss is moderated for non-subscribersPaul Bolle1-1/+1
Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2011-02-12[SCSI] mptfusion: Bump version 03.04.18Kashyap, Desai1-2/+2
Signed-off-by: Kashyap Desai <kashyap.desai@lsi.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2011-02-12[SCSI] mptfusion: Fix Incorrect return value in mptscsih_dev_resetKashyap, Desai1-3/+4
There's a branch at the end of this function that is supposed to normalize the return value with what the mid-layer expects. In this one case, we get it wrong. Also increase the verbosity of the INFO level printk at the end of mptscsih_abort to include the actual return value and the scmd->serial_number. The reason being success or failure is actually determined by the state of the internal tag list when a TMF is issued, and not the return value of the TMF cmd. The serial_number is also used in this decision, thus it's useful to know for debugging purposes. Cc: stable@kernel.org Reported-by: Peter M. Petrakis <peter.petrakis@canonical.com> Signed-off-by: Kashyap Desai <kashyap.desai@lsi.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2011-02-12[SCSI] mptfusion: mptctl_release is required in mptctl.cKashyap, Desai1-0/+8
Added missing release callback for file_operations mptctl_fops. Without release callback there will be never freed. It remains on mptctl's eent list even after the file is closed and released. Relavent RHEL bugzilla is 660871 Cc: stable@kernel.org Signed-off-by: Kashyap Desai <kashyap.desai@lsi.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2011-02-12[SCSI] target: fix use after free detected by SLUB poisonNicholas Bellinger3-73/+140
This patch moves a large number of memory release paths inside of the configfs callback target_core_hba_item_ops->release() called from within fs/configfs/item.c: config_item_cleanup() context. This patch resolves the SLUB 'Poison overwritten' warnings. Signed-off-by: Nicholas A. Bellinger <nab@linux-iscsi.org> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2011-02-12[SCSI] target: Remove procfs based target_core_mib.c codeNicholas Bellinger9-1148/+79
This patch removes the legacy procfs based target_core_mib.c code, and moves the necessary scsi_index_tables functions and defines into target_core_transport.c and target_core_base.h code to allow existing fabric independent statistics to function. This includes the removal of a handful of 'atomic_t mib_ref_count' counters used in struct se_node_acl, se_session and se_hba to prevent removal while using seq_list procfs walking logic. [jejb: fix up compile failures] Signed-off-by: Nicholas A. Bellinger <nab@linux-iscsi.org> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2011-02-12[SCSI] target: Fix SCF_SCSI_CONTROL_SG_IO_CDB breakageNicholas Bellinger1-1/+5
This patch fixes a bug introduced during the v4 control CDB emulation refactoring that broke SCF_SCSI_CONTROL_SG_IO_CDB operation within transport_map_control_cmd_to_task(). It moves the BUG_ON() into transport_do_se_mem_map() after the TRANSPORT(dev)->do_se_mem_map() RAMDISK_DR special case, and adds the proper struct se_mem assignment when !list_empty() for normal non RAMDISK_DR backend device cases. Reported-by: Kai-Thorsten Hambrecht <kai@hambrecht.org> Signed-off-by: Nicholas A. Bellinger <nab@linux-iscsi.org> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2011-02-12MAINTAINERS: Add entry for GPIO subsystemGrant Likely1-0/+9
I'll probably regret this.... Signed-off-by: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-02-12[SCSI] target: Fix top-level configfs_subsystem default_group shutdown breakageNicholas Bellinger1-9/+11
This patch fixes two bugs uncovered during testing with slub_debug=FPUZ during module_exit() -> target_core_exit_configfs() with release of configfs subsystem consumer default groups, namely how this should be working with fs/configfs/dir.c:configfs_unregister_subsystem() release logic for struct config_group->default_group. The first issue involves configfs_unregister_subsystem() expecting to walk+drain the top-level subsys->su_group.default_groups directly in unlink_group(), and not directly from the configfs subsystem consumer for the top level struct config_group->default_groups. This patch drops the walk+drain of subsys->su_group.default_groups from TCM configfs subsystem consumer code, and moves the top-level ->default_groups kfree() after configfs_unregister_subsystem() has been called. The second issue involves calling core_alua_free_lu_gp(se_global->default_lu_gp) to release the default_lu_gp->lu_gp_group before configfs_unregister_subsystem() has been called. This patches also moves the core_alua_free_lu_gp() call to release default_lu_group->lu_gp_group after the subsys has been unregistered. Finally, this patch explictly clears the [lu_gp,alua,hba]_cg->default_groups pointers after kfree() to ensure that no stale memory is picked up from child struct config_group->default_group[] while configfs_unregister_subsystem() is called. Reported-by: Fubo Chen <fubo.chen@gmail.com> Signed-off-by: Nicholas A. Bellinger <nab@linux-iscsi.org> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2011-02-12[SCSI] target: fixed missing lock drop in error pathFubo Chen1-0/+2
The struct se_node_acl->device_list_lock needs to be released if either sanity check for struct se_dev_entry->se_lun_acl or deve->se_lun fails. Signed-off-by: Fubo Chen <fubo.chen@gmail.com> Signed-off-by: Nicholas A. Bellinger <nab@linux-iscsi.org> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2011-02-12[SCSI] target: Fix demo-mode MappedLUN shutdown UA/PR breakageNicholas Bellinger1-4/+4
This patch fixes a bug in core_update_device_list_for_node() where individual demo-mode generated MappedLUN's UA + Persistent Reservations metadata where being leaked, instead of falling through and calling existing core_scsi3_ua_release_all() and core_scsi3_free_pr_reg_from_nacl() at the end of core_update_device_list_for_node(). This bug would manifest itself with the following OOPs w/ TPG demo-mode endpoints (tfo->tpg_check_demo_mode()=1), and PROUT REGISTER+RESERVE -> explict struct se_session logout -> struct se_device shutdown: [ 697.021139] LIO_iblock used greatest stack depth: 2704 bytes left [ 702.235017] general protection fault: 0000 [#1] SMP [ 702.235074] last sysfs file: /sys/devices/virtual/net/lo/operstate [ 704.372695] CPU 0 [ 704.372725] Modules linked in: crc32c target_core_stgt scsi_tgt target_core_pscsi target_core_file target_core_iblock target_core_mod configfs sr_mod cdrom sd_mod ata_piix mptspi mptscsih libata mptbase [last unloaded: iscsi_target_mod] [ 704.375442] [ 704.375563] Pid: 4964, comm: tcm_node Not tainted 2.6.37+ #1 440BX Desktop Reference Platform/VMware Virtual Platform [ 704.375912] RIP: 0010:[<ffffffffa00aaa16>] [<ffffffffa00aaa16>] __core_scsi3_complete_pro_release+0x31/0x133 [target_core_mod] [ 704.376017] RSP: 0018:ffff88001e5ffcb8 EFLAGS: 00010296 [ 704.376017] RAX: 6d32335b1b0a0d0a RBX: ffff88001d952cb0 RCX: 0000000000000015 [ 704.376017] RDX: ffff88001b428000 RSI: ffff88001da5a4c0 RDI: ffff88001e5ffcd8 [ 704.376017] RBP: ffff88001e5ffd28 R08: ffff88001e5ffcd8 R09: ffff88001d952080 [ 704.377116] R10: ffff88001dfc5480 R11: ffff88001df8abb0 R12: ffff88001d952cb0 [ 704.377319] R13: 0000000000000000 R14: ffff88001df8abb0 R15: ffff88001b428000 [ 704.377521] FS: 00007f033d15c6e0(0000) GS:ffff88001fa00000(0000) knlGS:0000000000000000 [ 704.377861] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 704.378043] CR2: 00007fff09281510 CR3: 000000001e5db000 CR4: 00000000000006f0 [ 704.378110] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 704.378110] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 704.378110] Process tcm_node (pid: 4964, threadinfo ffff88001e5fe000, task ffff88001d99c260) [ 704.378110] Stack: [ 704.378110] ffffea0000678980 ffff88001da5a4c0 ffffea0000678980 ffff88001f402b00 [ 704.378110] ffff88001e5ffd08 ffffffff810ea236 ffff88001e5ffd18 0000000000000282 [ 704.379772] ffff88001d952080 ffff88001d952cb0 ffff88001d952cb0 ffff88001dc79010 [ 704.380082] Call Trace: [ 704.380220] [<ffffffff810ea236>] ? __slab_free+0x89/0x11c [ 704.380403] [<ffffffffa00ab781>] core_scsi3_free_all_registrations+0x3e/0x157 [target_core_mod] [ 704.380479] [<ffffffffa00a752b>] se_release_device_for_hba+0xa6/0xd8 [target_core_mod] [ 704.380479] [<ffffffffa00a7598>] se_free_virtual_device+0x3b/0x45 [target_core_mod] [ 704.383750] [<ffffffffa00a3177>] target_core_drop_subdev+0x13a/0x18d [target_core_mod] [ 704.384068] [<ffffffffa00960db>] client_drop_item+0x25/0x31 [configfs] [ 704.384263] [<ffffffffa00967b5>] configfs_rmdir+0x1a1/0x223 [configfs] [ 704.384459] [<ffffffff810fa8cd>] vfs_rmdir+0x7e/0xd3 [ 704.384631] [<ffffffff810fc3be>] do_rmdir+0xa3/0xf4 [ 704.384895] [<ffffffff810eed15>] ? filp_close+0x67/0x72 [ 704.386485] [<ffffffff810fc446>] sys_rmdir+0x11/0x13 [ 704.387893] [<ffffffff81002a92>] system_call_fastpath+0x16/0x1b [ 704.388083] Code: 4c 8d 45 b0 41 56 49 89 d7 41 55 41 89 cd 41 54 b9 15 00 00 00 53 48 89 fb 48 83 ec 48 4c 89 c7 48 89 75 98 48 8b 86 28 01 00 00 <48> 8b 80 90 01 00 00 48 89 45 a0 31 c0 f3 aa c7 45 ac 00 00 00 [ 704.388763] RIP [<ffffffffa00aaa16>] __core_scsi3_complete_pro_release+0x31/0x133 [target_core_mod] [ 704.389142] RSP <ffff88001e5ffcb8> [ 704.389572] ---[ end trace 2a3614f3cd6261a5 ]--- Signed-off-by: Nicholas A. Bellinger <nab@linux-iscsi.org> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2011-02-12[SCSI] target/iblock: Fix failed bd claim NULL pointer dereferenceNicholas Bellinger1-2/+4
This patch adds an explict check for struct iblock_dev->ibd_bd in iblock_free_device() before calling blkdev_put(), which will otherwise hit the following NULL pointer dereference @ ib_dev->ibd_bd when iblock_create_virtdevice() fails to claim an already in-use struct block_device via blkdev_get_by_path(). [ 112.528578] Target_Core_ConfigFS: Allocated struct se_subsystem_dev: ffff88001e750000 se_dev_su_ptr: ffff88001dd05d70 [ 112.534681] Target_Core_ConfigFS: Calling t->free_device() for se_dev_su_ptr: ffff88001dd05d70 [ 112.535029] BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 [ 112.535029] IP: [<ffffffff814987a3>] mutex_lock+0x14/0x35 [ 112.535029] PGD 1e5d0067 PUD 1e274067 PMD 0 [ 112.535029] Oops: 0002 [#1] SMP [ 112.535029] last sysfs file: /sys/devices/pci0000:00/0000:00:07.1/host2/target2:0:0/2:0:0:0/type [ 112.535029] CPU 0 [ 112.535029] Modules linked in: iscsi_target_mod target_core_stgt scsi_tgt target_core_pscsi target_core_file target_core_iblock target_core_mod configfs sr_mod cdrom sd_mod ata_piix mptspi mptscsih libata mptbase [last unloaded: scsi_wait_scan] [ 112.535029] [ 112.535029] Pid: 3345, comm: python2.5 Not tainted 2.6.37+ #1 440BX Desktop Reference Platform/VMware Virtual Platform [ 112.535029] RIP: 0010:[<ffffffff814987a3>] [<ffffffff814987a3>] mutex_lock+0x14/0x35 [ 112.535029] RSP: 0018:ffff88001e6d7d58 EFLAGS: 00010246 [ 112.535029] RAX: 0000000000000000 RBX: 0000000000000020 RCX: 0000000000000082 [ 112.535029] RDX: ffff88001e6d7fd8 RSI: 0000000000000083 RDI: 0000000000000020 [ 112.535029] RBP: ffff88001e6d7d68 R08: 0000000000000000 R09: 0000000000000000 [ 112.535029] R10: ffff8800000be860 R11: ffff88001f420000 R12: 0000000000000020 [ 112.535029] R13: 0000000000000083 R14: ffff88001d809430 R15: ffff88001d8094f8 [ 112.535029] FS: 00007ff17ca7d6e0(0000) GS:ffff88001fa00000(0000) knlGS:0000000000000000 [ 112.535029] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 112.535029] CR2: 0000000000000020 CR3: 000000001e5d2000 CR4: 00000000000006f0 [ 112.535029] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 112.535029] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 112.535029] Process python2.5 (pid: 3345, threadinfo ffff88001e6d6000, task ffff88001e2d0760) [ 112.535029] Stack: [ 112.535029] ffff88001e6d7d88 0000000000000000 ffff88001e6d7d98 ffffffff811187fc [ 112.535029] ffff88001d809430 ffff88001dd05d70 ffff88001e750860 ffff88001e750000 [ 112.535029] ffff88001e6d7db8 ffffffffa00e3757 ffff88001e6d7db8 0000000000000004 [ 112.535029] Call Trace: [ 112.535029] [<ffffffff811187fc>] blkdev_put+0x28/0x107 [ 112.535029] [<ffffffffa00e3757>] iblock_free_device+0x1d/0x36 [target_core_iblock] [ 112.535029] [<ffffffffa00a319c>] target_core_drop_subdev+0x15f/0x18d [target_core_mod] [ 112.535029] [<ffffffffa00960db>] client_drop_item+0x25/0x31 [configfs] [ 112.535029] [<ffffffffa00967b5>] configfs_rmdir+0x1a1/0x223 [configfs] [ 112.535029] [<ffffffff810fa8cd>] vfs_rmdir+0x7e/0xd3 [ 112.535029] [<ffffffff810fc3be>] do_rmdir+0xa3/0xf4 [ 112.535029] [<ffffffff810fc446>] sys_rmdir+0x11/0x13 [ 112.535029] [<ffffffff81002a92>] system_call_fastpath+0x16/0x1b [ 112.535029] Code: 8b 04 25 88 b5 00 00 48 2d d8 1f 00 00 48 89 43 18 31 c0 5e 5b c9 c3 55 48 89 e5 53 48 89 fb 48 83 ec 08 e8 c4 f7 ff ff 48 89 df <3e> ff 0f 79 05 e8 1e ff ff ff 65 48 8b 04 25 88 b5 00 00 48 2d [ 112.535029] RIP [<ffffffff814987a3>] mutex_lock+0x14/0x35 [ 112.535029] RSP <ffff88001e6d7d58> [ 112.535029] CR2: 0000000000000020 [ 132.679636] ---[ end trace 05754bb48eb828f0 ]--- Note it also adds an second explict check for ib_dev->ibd_bio_set before calling bioset_free() to fix the same possible NULL pointer deference during an early iblock_create_virtdevice() failure. Signed-off-by: Nicholas A. Bellinger <nab@linux-iscsi.org> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2011-02-12[SCSI] target: iblock/pscsi claim checking for NULL instead of IS_ERRDan Carpenter2-3/+3
blkdev_get_by_path() returns an ERR_PTR() or error and it doesn't return a NULL. It looks like this bug would be easy to trigger by mistake. Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Nicholas A. Bellinger <nab@linux-iscsi.org> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2011-02-12[SCSI] scsi_debug: Fix 32-bit overflow in do_device_access causing memory corruptionDarrick J. Wong1-1/+1
If I create a scsi_debug device that is larger than 4GB, the multiplication of (block * scsi_debug_sector_size) can produce a 64-bit value. Unfortunately, the compiler sees two 32-bit quantities and performs a 32-bit multiplication, thus truncating the bits above 2^32. This causes the wrong memory location to be read or written. Change block and rest to be unsigned long long. Signed-off-by: Darrick J. Wong <djwong@us.ibm.com> Acked-by: Douglas Gilbert <dgilbert@interlog.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2011-02-12[SCSI] qla2xxx: Change from irq to irqsave with host_lockMadhuranath Iyengar3-8/+12
Make the driver safer by using irqsave/irqrestore with host_lock. Signed-off-by: Madhuranath Iyengar <Madhu.Iyengar@qlogic.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2011-02-12[SCSI] qla2xxx: Fix race that could hang kthread_stop()James Bottomley1-1/+3
There is a small race window in qla2x00_do_dpc() between checking for kthread_should_stop() and going to sleep after setting TASK_INTERRUPTIBLE. If qla2x00_free_device() is called in this window, kthread_stop will wait forever because there will be no one to wake up the process. Fix by making sure we only set TASK_INTERRUPTIBLE before checking kthread_stop(). Reported-by: Bandan Das <bandan.das@stratus.com> Acked-by: Madhuranath Iyengar <Madhu.Iyengar@qlogic.com> Signed-off-by: James Bottomley <James.Bottomley@suse.de>
2011-02-12jbd2: call __jbd2_log_start_commit with j_state_lock write lockedTheodore Ts'o2-9/+21
On an SMP ARM system running ext4, I've received a report that the first J_ASSERT in jbd2_journal_commit_transaction has been triggering: J_ASSERT(journal->j_running_transaction != NULL); While investigating possible causes for this problem, I noticed that __jbd2_log_start_commit() is getting called with j_state_lock only read-locked, in spite of the fact that it's possible for it might j_commit_request. Fix this by grabbing the necessary information so we can test to see if we need to start a new transaction before dropping the read lock, and then calling jbd2_log_start_commit() which will grab the write lock. Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2011-02-12ext4: serialize unaligned asynchronous DIOEric Sandeen5-18/+100
ext4 has a data corruption case when doing non-block-aligned asynchronous direct IO into a sparse file, as demonstrated by xfstest 240. The root cause is that while ext4 preallocates space in the hole, mappings of that space still look "new" and dio_zero_block() will zero out the unwritten portions. When more than one AIO thread is going, they both find this "new" block and race to zero out their portion; this is uncoordinated and causes data corruption. Dave Chinner fixed this for xfs by simply serializing all unaligned asynchronous direct IO. I've done the same here. The difference is that we only wait on conversions, not all IO. This is a very big hammer, and I'm not very pleased with stuffing this into ext4_file_write(). But since ext4 is DIO_LOCKING, we need to serialize it at this high level. I tried to move this into ext4_ext_direct_IO, but by then we have the i_mutex already, and we will wait on the work queue to do conversions - which must also take the i_mutex. So that won't work. This was originally exposed by qemu-kvm installing to a raw disk image with a normal sector-63 alignment. I've tested a backport of this patch with qemu, and it does avoid the corruption. It is also quite a lot slower (14 min for package installs, vs. 8 min for well-aligned) but I'll take slow correctness over fast corruption any day. Mingming suggested that we can track outstanding conversions, and wait on those so that non-sparse files won't be affected, and I've implemented that here; unaligned AIO to nonsparse files won't take a perf hit. [tytso@mit.edu: Keep the mutex as a hashed array instead of bloating the ext4 inode] [tytso@mit.edu: Fix up namespace issues so that global variables are protected with an "ext4_" prefix.] Signed-off-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2011-02-12ext4: make grpinfo slab cache names staticEric Sandeen1-40/+60
In 2.6.37 I was running into oopses with repeated module loads & unloads. I tracked this down to: fb1813f4 ext4: use dedicated slab caches for group_info structures (this was in addition to the features advert unload problem) The kstrdup & subsequent kfree of the cache name was causing a double free. In slub, at least, if I read it right it allocates & frees the name itself, slab seems to do something different... so in slub I think we were leaking -our- cachep->name, and double freeing the one allocated by slub. After getting lost in slab/slub/slob a bit, I just looked at other sized-caches that get allocated. jbd2, biovec, sgpool all do it more or less the way jbd2 does. Below patch follows the jbd2 method of dynamically allocating a cache at mount time from a list of static names. (This might also possibly fix a race creating the caches with parallel mounts running). [Folded in a fix from Dan Carpenter which fixed an off-by-one error in the original patch] Cc: stable@kernel.org Signed-off-by: Eric Sandeen <sandeen@redhat.com> Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
2011-02-12timer debug: Hide kernel addresses via %pK in /proc/timer_listKees Cook1-2/+2
In the continuing effort to avoid kernel addresses leaking to unprivileged users, this patch switches to %pK for /proc/timer_list reporting. Signed-off-by: Kees Cook <kees.cook@canonical.com> Cc: John Stultz <johnstul@us.ibm.com> Cc: Dan Rosenberg <drosenberg@vsecurity.com> Cc: Eugene Teo <eugeneteo@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> LKML-Reference: <20110212032125.GA23571@outflux.net> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2011-02-12x86: Readd missing irq_to_desc() in fixup_irq()Thomas Gleixner1-1/+2
commit a3c08e5d(x86: Convert irq_chip access to new functions) accidentally zapped desc = irq_to_desc(irq); in the vector loop. So we lock some random irq descriptor. Add it back. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: <stable@kernel.org> # .37
2011-02-12bridge: Replace mp->mglist hlist with a boolHerbert Xu3-12/+9
As it turns out we never need to walk through the list of multicast groups subscribed by the bridge interface itself (the only time we'd want to do that is when we shut down the bridge, in which case we simply walk through all multicast groups), we don't really need to keep an hlist for mp->mglist. This means that we can replace it with just a single bit to indicate whether the bridge interface is subscribed to a group. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-02-12MAINTAINERS: Add entry for GPIO subsystemGrant Likely1-0/+9
I'll probably regret this.... Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
2011-02-11bridge: Fix timer typo that may render snooping less effectiveHerbert Xu1-2/+2
In a couple of spots where we are supposed to modify the port group timer (p->timer) we instead modify the bridge interface group timer (mp->timer). The effect of this is mostly harmless. However, it can cause port subscriptions to be longer than they should be, thus making snooping less effective. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-02-11bridge: Fix mglist corruption that leads to memory corruptionHerbert Xu1-1/+2
The list mp->mglist is used to indicate whether a multicast group is active on the bridge interface itself as opposed to one of the constituent interfaces in the bridge. Unfortunately the operation that adds the mp->mglist node to the list neglected to check whether it has already been added. This leads to list corruption in the form of nodes pointing to itself. Normally this would be quite obvious as it would cause an infinite loop when walking the list. However, as this list is never actually walked (which means that we don't really need it, I'll get rid of it in a subsequent patch), this instead is hidden until we perform a delete operation on the affected nodes. As the same node may now be pointed to by more than one node, the delete operations can then cause modification of freed memory. This was observed in practice to cause corruption in 512-byte slabs, most commonly leading to crashes in jbd2. Thanks to Josef Bacik for pointing me in the right direction. Reported-by: Ian Page Hands <ihands@redhat.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
2011-02-12x86: Fix text_poke_smp_batch() deadlockPeter Zijlstra1-1/+1
Fix this deadlock - we are already holding the mutex: ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.38-rc4-test+ #1 ------------------------------------------------------- bash/1850 is trying to acquire lock: (text_mutex){+.+.+.}, at: [<ffffffff8100a9c1>] return_to_handler+0x0/0x2f but task is already holding lock: (smp_alt){+.+...}, at: [<ffffffff8100a9c1>] return_to_handler+0x0/0x2f which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (smp_alt){+.+...}: [<ffffffff81082d02>] lock_acquire+0xcd/0xf8 [<ffffffff8192e119>] __mutex_lock_common+0x4c/0x339 [<ffffffff8192e4ca>] mutex_lock_nested+0x3e/0x43 [<ffffffff8101050f>] alternatives_smp_switch+0x77/0x1d8 [<ffffffff81926a6f>] do_boot_cpu+0xd7/0x762 [<ffffffff819277dd>] native_cpu_up+0xe6/0x16a [<ffffffff81928e28>] _cpu_up+0x9d/0xee [<ffffffff81928f4c>] cpu_up+0xd3/0xe7 [<ffffffff82268d4b>] kernel_init+0xe8/0x20a [<ffffffff8100ba24>] kernel_thread_helper+0x4/0x10 -> #1 (cpu_hotplug.lock){+.+.+.}: [<ffffffff81082d02>] lock_acquire+0xcd/0xf8 [<ffffffff8192e119>] __mutex_lock_common+0x4c/0x339 [<ffffffff8192e4ca>] mutex_lock_nested+0x3e/0x43 [<ffffffff810568cc>] get_online_cpus+0x41/0x55 [<ffffffff810a1348>] stop_machine+0x1e/0x3e [<ffffffff819314c1>] text_poke_smp_batch+0x3a/0x3c [<ffffffff81932b6c>] arch_optimize_kprobes+0x10d/0x11c [<ffffffff81933a51>] kprobe_optimizer+0x152/0x222 [<ffffffff8106bb71>] process_one_work+0x1d3/0x335 [<ffffffff8106cfae>] worker_thread+0x104/0x1a4 [<ffffffff810707c4>] kthread+0x9d/0xa5 [<ffffffff8100ba24>] kernel_thread_helper+0x4/0x10 -> #0 (text_mutex){+.+.+.}: other info that might help us debug this: 6 locks held by bash/1850: #0: (&buffer->mutex){+.+.+.}, at: [<ffffffff8100a9c1>] return_to_handler+0x0/0x2f #1: (s_active#75){.+.+.+}, at: [<ffffffff8100a9c1>] return_to_handler+0x0/0x2f #2: (x86_cpu_hotplug_driver_mutex){+.+.+.}, at: [<ffffffff8100a9c1>] return_to_handler+0x0/0x2f #3: (cpu_add_remove_lock){+.+.+.}, at: [<ffffffff8100a9c1>] return_to_handler+0x0/0x2f #4: (cpu_hotplug.lock){+.+.+.}, at: [<ffffffff8100a9c1>] return_to_handler+0x0/0x2f #5: (smp_alt){+.+...}, at: [<ffffffff8100a9c1>] return_to_handler+0x0/0x2f stack backtrace: Pid: 1850, comm: bash Not tainted 2.6.38-rc4-test+ #1 Call Trace: [<ffffffff81080eb2>] print_circular_bug+0xa8/0xb7 [<ffffffff8192e4ca>] mutex_lock_nested+0x3e/0x43 [<ffffffff81010302>] alternatives_smp_unlock+0x3d/0x93 [<ffffffff81010630>] alternatives_smp_switch+0x198/0x1d8 [<ffffffff8102568a>] native_cpu_die+0x65/0x95 [<ffffffff818cc4ec>] _cpu_down+0x13e/0x202 [<ffffffff8117a619>] sysfs_write_file+0x108/0x144 [<ffffffff8111f5a2>] vfs_write+0xac/0xff [<ffffffff8111f7a9>] sys_write+0x4a/0x6e Reported-by: Steven Rostedt <rostedt@goodmis.org> Tested-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: mathieu.desnoyers@efficios.com Cc: rusty@rustcorp.com.au Cc: ananth@in.ibm.com Cc: masami.hiramatsu.pt@hitachi.com Cc: fweisbec@gmail.com Cc: jbeulich@novell.com Cc: jbaron@redhat.com Cc: mhiramat@redhat.com LKML-Reference: <1297458466.5226.93.camel@laptop> Signed-off-by: Ingo Molnar <mingo@elte.hu>
2011-02-12ACPI / Video: Probe for output switch method when searching video devices.Michael Karcher1-0/+5
This patch reverts one hunk of 677bd810eedce61edf15452491781ff046b92edc "ACPI video: remove output switching control", namely the removal of probing for _DOS/_DOD when searching for video devices. This is needed on some Fujitsu Laptops (at least S7110, P8010) for the ACPI backlight interface to work, as an these machines, neither ROM nor posting methods are available, and after removal of output switching, none of the caps triggers, which prevents the backlight search from being entered. Tested on a Fujitsu Lifebook S7110 and Fujitsu Lifebook P8010. This probably fixes https://bugzilla.kernel.org/show_bug.cgi?id=27312 for the people who have no entry in /sys/class/backlight. This is the complete list of public (starting with "_") methods implemented on the S7110, BIOS rev 1.34: \_SB_.PCI0.GFX0._ADR \_SB_.PCI0.GFX0._DOS \_SB_.PCI0.GFX0._DOD \_SB_.PCI0.GFX0.CRT._ADR \_SB_.PCI0.GFX0.CRT._DCS \_SB_.PCI0.GFX0.CRT._DGS \_SB_.PCI0.GFX0.CRT._DSS \_SB_.PCI0.GFX0.LCD._ADR \_SB_.PCI0.GFX0.LCD._BCL \_SB_.PCI0.GFX0.LCD._BCM \_SB_.PCI0.GFX0.LCD._BQC \_SB_.PCI0.GFX0.LCD._DCS \_SB_.PCI0.GFX0.LCD._DGS \_SB_.PCI0.GFX0.LCD._DSS \_SB_.PCI0.GFX0.LCD._PS0 \_SB_.PCI0.GFX0.LCD._PS3 \_SB_.PCI0.GFX0.TV._ADR \_SB_.PCI0.GFX0.TV._DCS \_SB_.PCI0.GFX0.TV._DGS \_SB_.PCI0.GFX0.TV._DSS \_SB_.PCI0.GFX0.DVI._ADR \_SB_.PCI0.GFX0.DVI._DCS \_SB_.PCI0.GFX0.DVI._DGS \_SB_.PCI0.GFX0.DVI._DSS Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de> Acked-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-02-12ACPI / Wakeup: Enable button GPEs unconditionally during initializationRafael J. Wysocki1-1/+5
Commit 9630bdd (ACPI: Use GPE reference counting to support shared GPEs) introduced a suspend regression where boxes resume immediately after being suspended due to the lid or sleep button wakeup status not being cleared properly. This happens if the GPEs corresponding to those devices are not enabled all the time, which apparently is expected by some BIOSes. To fix this problem, enable button and lid GPEs unconditionally during initialization and keep them enabled all the time, regardless of whether or not the ACPI button driver is used. References: https://bugzilla.kernel.org/show_bug.cgi?id=27372 Reported-and-tested-by: Ferenc Wágner <wferi@niif.hu> Cc: stable@kernel.org Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-02-12ACPI / ACPICA: Avoid crashing if _PRW is defined for the root objectRafael J. Wysocki1-23/+26
Some ACPI BIOSes define _PRW for the root object which causes acpi_setup_gpe_for_wake() to crash when trying to dereference the bogus device_node pointer. Avoid the crash by checking if wake_device is not the root object before attempting to set up the "implicit notify" mechanism for it. The problem was introduced by commit bba63a296ffab20e08d9e8252d2f0d99 (ACPICA: Implicit notify support) that added the wake_device argument to acpi_setup_gpe_for_wake(). Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
2011-02-11drivers/w1/masters/omap_hdq.c: add missing clk_putJulia Lawall1-14/+14
This code makes two calls to clk_get, then test both return values and fails if either failed. The problem is that in the first inner if, where the first call to clk_get has failed, it don't know if the second call has failed as well. So it don't know whether clk_get should be called on the result of the second call. Of course, it would be possible to test that value again. A simpler solution is just to test the result of calling clk_get directly after each call. The semantic match that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r@ position p1,p2; expression e; statement S; @@ e = clk_get@p1(...) ... if@p2 (IS_ERR(e)) S @@ expression e; statement S; identifier l; position r.p1, p2 != r.p2; @@ *e = clk_get@p1(...) ... when != clk_put(e) *if@p2 (...) { ... when != clk_put(e) * return ...; }// </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru> Acked-by: Tony Lindgren <tony@atomide.com> Acked-by: Amit Kucheria <amit.kucheria@canonical.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-02-11memcg: fix leak of accounting at failure path of hugepage collapsingKAMEZAWA Hiroyuki1-1/+1
mem_cgroup_uncharge_page() should be called in all failure cases after mem_cgroup_charge_newpage() is called in huge_memory.c::collapse_huge_page() [ 4209.076861] BUG: Bad page state in process khugepaged pfn:1e9800 [ 4209.077601] page:ffffea0006b14000 count:0 mapcount:0 mapping: (null) index:0x2800 [ 4209.078674] page flags: 0x40000000004000(head) [ 4209.079294] pc:ffff880214a30000 pc->flags:2146246697418756 pc->mem_cgroup:ffffc9000177a000 [ 4209.082177] (/A) [ 4209.082500] Pid: 31, comm: khugepaged Not tainted 2.6.38-rc3-mm1 #1 [ 4209.083412] Call Trace: [ 4209.083678] [<ffffffff810f4454>] ? bad_page+0xe4/0x140 [ 4209.084240] [<ffffffff810f53e6>] ? free_pages_prepare+0xd6/0x120 [ 4209.084837] [<ffffffff8155621d>] ? rwsem_down_failed_common+0xbd/0x150 [ 4209.085509] [<ffffffff810f5462>] ? __free_pages_ok+0x32/0xe0 [ 4209.086110] [<ffffffff810f552b>] ? free_compound_page+0x1b/0x20 [ 4209.086699] [<ffffffff810fad6c>] ? __put_compound_page+0x1c/0x30 [ 4209.087333] [<ffffffff810fae1d>] ? put_compound_page+0x4d/0x200 [ 4209.087935] [<ffffffff810fb015>] ? put_page+0x45/0x50 [ 4209.097361] [<ffffffff8113f779>] ? khugepaged+0x9e9/0x1430 [ 4209.098364] [<ffffffff8107c870>] ? autoremove_wake_function+0x0/0x40 [ 4209.099121] [<ffffffff8113ed90>] ? khugepaged+0x0/0x1430 [ 4209.099780] [<ffffffff8107c236>] ? kthread+0x96/0xa0 [ 4209.100452] [<ffffffff8100dda4>] ? kernel_thread_helper+0x4/0x10 [ 4209.101214] [<ffffffff8107c1a0>] ? kthread+0x0/0xa0 [ 4209.101842] [<ffffffff8100dda0>] ? kernel_thread_helper+0x0/0x10 Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Acked-by: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp> Reviewed-by: Johannes Weiner <hannes@cmpxchg.org> Cc: Andrea Arcangeli <aarcange@redhat.com> Reviewed-by: Minchan Kim <minchan.kim@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-02-11vmscan: fix zone shrinking exit when scan work is doneJohannes Weiner1-2/+2
Commit 3e7d34497067 ("mm: vmscan: reclaim order-0 and use compaction instead of lumpy reclaim") introduced an indefinite loop in shrink_zone(). It meant to break out of this loop when no pages had been reclaimed and not a single page was even scanned. The way it would detect the latter is by taking a snapshot of sc->nr_scanned at the beginning of the function and comparing it against the new sc->nr_scanned after the scan loop. But it would re-iterate without updating that snapshot, looping forever if sc->nr_scanned changed at least once since shrink_zone() was invoked. This is not the sole condition that would exit that loop, but it requires other processes to change the zone state, as the reclaimer that is stuck obviously can not anymore. This is only happening for higher-order allocations, where reclaim is run back to back with compaction. Signed-off-by: Johannes Weiner <hannes@cmpxchg.org> Reported-by: Michal Hocko <mhocko@suse.cz> Tested-by: Kent Overstreet<kent.overstreet@gmail.com> Reported-by: Kent Overstreet <kent.overstreet@gmail.com> Acked-by: Mel Gorman <mel@csn.ul.ie> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Rik van Riel <riel@redhat.com> Reviewed-by: Minchan Kim <minchan.kim@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2011-02-11mlock: do not munlock pages in __do_fault()Michel Lespinasse1-6/+0
If the page is going to be written to, __do_page needs to break COW. However, the old page (before breaking COW) was never mapped mapped into the current pte (__do_fault is only called when the pte is not present), so vmscan can't have marked the old page as PageMlocked due to being mapped in __do_fault's VMA. Therefore, __do_fault() does not need to worry about clearing PageMlocked() on the old page. Signed-off-by: Michel Lespinasse <walken@google.com> Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Acked-by: Hugh Dickins <hughd@google.com> Cc: Rik van Riel <riel@redhat.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>