- 26 Jan, 2012 40 commits
-
-
Lin Ming authored
commit d640113f upstream. For UP processor, it is likely that no _MAT method or MADT table defined. So currently acpi_get_cpuid(...) always return -1 for UP processor. This is wrong. It should return valid value for CPU0. In the other hand, BIOS may define multiple CPU handles even for UP processor, for example Scope (_PR) { Processor (CPU0, 0x00, 0x00000410, 0x06) {} Processor (CPU1, 0x01, 0x00000410, 0x06) {} Processor (CPU2, 0x02, 0x00000410, 0x06) {} Processor (CPU3, 0x03, 0x00000410, 0x06) {} } We should only return valid value for CPU0's acpi handle. And return invalid value for others. http://marc.info/?t=132329819900003&r=1&w=2 Reported-and-tested-by: wallak@free.fr Signed-off-by:
Lin Ming <ming.m.lin@intel.com> Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Lin Ming authored
commit da4d8b28 upstream. The call to acpi_os_validate_address in acpi_ds_get_region_arguments was removed by mistake in commit 9ad19ac(ACPICA: Split large dsopcode and dsload.c files). Put it back. Reported-and-bisected-by:
Luca Tettamanti <kronos.it@gmail.com> Signed-off-by:
-
Kurt Garloff authored
commit 9f10f6a5 upstream. In SRAT v1, we had 8bit proximity domain (PXM) fields; SRAT v2 provides 32bits for these. The new fields were reserved before. According to the ACPI spec, the OS must disregrard reserved fields. ia64 did handle the PXM fields almost consistently, but depending on sgi's sn2 platform. This patch leaves the sn2 logic in, but does also use 16/32 bits for PXM if the SRAT has rev 2 or higher. The patch also adds __init to the two pxm accessor functions, as they access __initdata now and are called from an __init function only anyway. Note that the code only uses 16 bits for the PXM field in the processor proximity field; the patch does not address this as 16 bits are more than enough. Signed-off-by:
Kurt Garloff <kurt@garloff.de> Signed-off-by:
-
Kurt Garloff authored
commit cd298f60 upstream. In SRAT v1, we had 8bit proximity domain (PXM) fields; SRAT v2 provides 32bits for these. The new fields were reserved before. According to the ACPI spec, the OS must disregrard reserved fields. x86/x86-64 was rather inconsistent prior to this patch; it used 8 bits for the pxm field in cpu_affinity, but 32 bits in mem_affinity. This patch makes it consistent: Either use 8 bits consistently (SRAT rev 1 or lower) or 32 bits (SRAT rev 2 or higher). cc: x86@kernel.org Signed-off-by:
-
Kurt Garloff authored
commit 8df0eb7c upstream. In SRAT v1, we had 8bit proximity domain (PXM) fields; SRAT v2 provides 32bits for these. The new fields were reserved before. According to the ACPI spec, the OS must disregrard reserved fields. In order to know whether or not, we must know what version the SRAT table has. This patch stores the SRAT table revision for later consumption by arch specific __init functions. Signed-off-by:
-
Shaohua Li authored
commit 39a74fde upstream. smp_call_function() only lets all other CPUs execute a specific function, while we expect all CPUs do in intel_idle. Without the fix, we could have one cpu which has auto_demotion enabled or has no broadcast timer setup. Usually we don't see impact because auto demotion just harms power and the intel_idle init is called in CPU 0, where boradcast timer delivers interrupt, but this still could be a problem. Signed-off-by:
Shaohua Li <shaohua.li@intel.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Thomas Renninger authored
commit 5c2a9f06 upstream. kvm -cpu host passes the original cpuid info to the guest. Latest kvm version seem to return true for mwait_leaf cpuid function on recent Intel CPUs. But it does not return mwait C-states (mwait_substates), instead zero is returned. While real CPUs seem to always return non-zero values, the intel idle driver should not get active in kvm (mwait_substates == 0) case and bail out. Otherwise a Null pointer exception will happen later when the cpuidle subsystem tries to get active: [0.984807] BUG: unable to handle kernel NULL pointer dereference at (null) [0.984807] IP: [<(null)>] (null) ... [0.984807][<ffffffff8143cf34>] ? cpuidle_idle_call+0xb4/0x340 [0.984807][<ffffffff8159e7bc>] ? __atomic_notifier_call_chain+0x4c/0x70 [0.984807][<ffffffff81001198>] ? cpu_idle+0x78/0xd0 Reference: https://bugzilla.novell.com/show_bug.cgi?id=726296Signed-off-by:
Thomas Renninger <trenn@suse.de> CC: Bruno Friedmann <bruno@ioda-net.ch> Signed-off-by:
-
Tetsuo Handa authored
commit 25add8cf upstream. TOMOYO 2.5 in Linux 3.2 and later handles Unix domain socket's address. Thus, tomoyo_correct_word2() needs to accept \000 as a valid character, or TOMOYO 2.5 cannot handle Unix domain's abstract socket address. Reported-by:
Steven Allen <steven@stebalien.com> Signed-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by:
James Morris <jmorris@namei.org> Signed-off-by:
-
David Henningsson authored
commit ffe535ed upstream. More than one user reports that changing the model from "both" to "dmic" makes their Internal Mic work. Tested-by:
Martin Ling <martin-launchpad@earth.li> BugLink: https://bugs.launchpad.net/bugs/795823Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Clemens Ladisch authored
commit f0e48b6b upstream. The two DACs for the front output and the surround/center/LFE/back outputs are wired up out of phase, so when channels are duplicated, their sound can cancel out each other and result in a weaker bass response. To fix this, reverse the polarity of the neutron flow to the front output. Reported-any-tested-by:
Daniel Hill <daniel@enemyplanet.geek.nz> Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
-
David Henningsson authored
commit b01de4fb upstream. Several users have reported "choppy" audio under the 3.2 kernel, and that changing position_fix to 1 has resolved their problem. The chip is an nVidia Corporation MCP89 High Definition Audio, [10de:0d94] (rev a2). BugLink: https://bugs.launchpad.net/bugs/909419Signed-off-by:
-
Linus Torvalds authored
commit e268337d upstream. Jüri Aedla reported that the /proc/<pid>/mem handling really isn't very robust, and it also doesn't match the permission checking of any of the other related files. This changes it to do the permission checks at open time, and instead of tracking the process, it tracks the VM at the time of the open. That simplifies the code a lot, but does mean that if you hold the file descriptor open over an execve(), you'll continue to read from the _old_ VM. That is different from our previous behavior, but much simpler. If somebody actually finds a load where this matters, we'll need to revert this commit. I suspect that nobody will ever notice - because the process mapping addresses will also have changed as part of the execve. So you cannot actually usefully access the fd across a VM change simply because all the offsets for IO would have changed too. Reported-by:
Jüri Aedla <asd@ut.ee> Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Paolo Bonzini authored
commit ec8013be upstream. A logical volume can map to just part of underlying physical volume. In this case, it must be treated like a partition. Based on a patch from Alasdair G Kergon. Cc: Alasdair G Kergon <agk@redhat.com> Cc: dm-devel@redhat.com Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Paolo Bonzini authored
commit 0bfc96cb upstream. [ Changes with respect to 3.3: return -ENOTTY from scsi_verify_blk_ioctl and -ENOIOCTLCMD from sd_compat_ioctl. ] Linux allows executing the SG_IO ioctl on a partition or LVM volume, and will pass the command to the underlying block device. This is well-known, but it is also a large security problem when (via Unix permissions, ACLs, SELinux or a combination thereof) a program or user needs to be granted access only to part of the disk. This patch lets partitions forward a small set of harmless ioctls; others are logged with printk so that we can see which ioctls are actually sent. In my tests only CDROM_GET_CAPABILITY actually occurred. Of course it was being sent to a (partition on a) hard disk, so it would have failed with ENOTTY and the patch isn't changing anything in practice. Still, I'm treating it specially to avoid spamming the logs. In principle, this restriction should include programs running with CAP_SYS_RAWIO. If for example I let a program access /dev/sda2 and /dev/sdb, it still should not be able to read/write outside the boundaries of /dev/sda2 independent of the capabilities. However, for now programs with CAP_SYS_RAWIO will still be allowed to send the ioctls. Their actions will still be logged. This patch does not affect the non-libata IDE driver. That driver however already tests for bd != bd->bd_contains before issuing some ioctl; it could be restricted further to forbid these ioctls even for programs running with CAP_SYS_ADMIN/CAP_SYS_RAWIO. Cc: linux-scsi@vger.kernel.org Cc: Jens Axboe <axboe@kernel.dk> Cc: James Bottomley <JBottomley@parallels.com> Signed-off-by:
-
Paolo Bonzini authored
commit 577ebb37 upstream. Introduce a wrapper around scsi_cmd_ioctl that takes a block device. The function will then be enhanced to detect partition block devices and, in that case, subject the ioctls to whitelisting. Cc: linux-scsi@vger.kernel.org Cc: Jens Axboe <axboe@kernel.dk> Cc: James Bottomley <JBottomley@parallels.com> Signed-off-by:
-
Martin Schwidefsky authored
commit c3e0ef9a upstream. For 32-bit architectures using standard jiffies the idletime calculation in uptime_proc_show will quickly overflow. It takes (2^32 / HZ) seconds of idle-time, or e.g. 12.45 days with no load on a quad-core with HZ=1000. Switch to 64-bit calculations. Cc: Michael Abbott <michael.abbott@diamond.ac.uk> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Masatoshi Hoshikawa authored
commit 11576c61 upstream. This patch adds support for the Xiroku Inc. panels (SPX/MPX/CSR/etc.). Signed-off-by:
Masatoshi Hoshikawa <hoshikawa@xiroku.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Benjamin Tissoires authored
commit c4fad877 upstream. Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@gmail.com> Acked-by:
Henrik Rydberg <rydberg@euromail.se> Signed-off-by:
-
Benjamin Tissoires authored
commit b1057124 upstream. Signed-off-by:
-
Benjamin Tissoires authored
commit 54580365 upstream. Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@enac.fr> Acked-by:
-
Benjamin Tissoires authored
commit 66f06127 upstream. Just another eGalax device. Please note that adding this device to have_special_driver in hid-core.c is not required anymore. Signed-off-by:
-
Marek Vasut authored
commit bb9ff210 upstream. This patch adds USB ID for the touchpanel in Acer Iconia W500. The panel supports up to five fingers, therefore the need for a new addition of panel types. Signed-off-by:
Marek Vasut <marek.vasut@gmail.com> Signed-off-by:
-
Benjamin Tissoires authored
commit e36f690b upstream. This is just a renaming of USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH{N} to USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_{PID} to handle more eGalax devices. Signed-off-by:
-
Chris Bagwell authored
commit 1fd8f047 upstream. This allows ASUS Eee Slate touchscreens to work. Signed-off-by:
Chris Bagwell <chris@cnpbagwell.com> Reviewed-by:
-
Johannes Berg authored
commit e76aadc5 upstream. Backport note: This patch it's a full revert of commit b23b025f "mac80211: Optimize scans on current operating channel.". On upstrem revert e76aadc5 we keep some bits from that commit, which are needed for upstream version of mac80211. The on-channel work optimisations have caused a number of issues, and the code is unfortunately very complex and almost impossible to follow. Instead of attempting to put in more workarounds let's just remove those optimisations, we can work on them again later, after we change the whole auth/assoc design. This should fix rate_control_send_low() warnings, see RH bug 731365. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
Peng Tao authored
commit 74a6eeb4 upstream. One bio can have at most BIO_MAX_PAGES pages. We should limit it bec otherwise bio_alloc will fail when there are many pages in one read/write_pagelist. Signed-off-by:
Peng Tao <peng_tao@emc.com> Signed-off-by:
Benny Halevy <bhalevy@tonian.com> Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Peng Tao authored
commit 93a3844e upstream. bl_free_block_dev() may sleep. We can not call it with spinlock held. Besides, there is no need to take bm_lock as we are last user freeing bm_devlist. Signed-off-by:
-
Peng Tao authored
commit 39e567ae upstream. When calling _add_entry, we should take the im_lock to protect agains other modifiers. Signed-off-by:
-
Miklos Szeredi authored
commit eaf5f907 upstream. Two (or more) concurrent calls of shrink_dcache_parent() on the same dentry may cause shrink_dcache_parent() to loop forever. Here's what appears to happen: 1 - CPU0: select_parent(P) finds C and puts it on dispose list, returns 1 2 - CPU1: select_parent(P) locks P->d_lock 3 - CPU0: shrink_dentry_list() locks C->d_lock dentry_kill(C) tries to lock P->d_lock but fails, unlocks C->d_lock 4 - CPU1: select_parent(P) locks C->d_lock, moves C from dispose list being processed on CPU0 to the new dispose list, returns 1 5 - CPU0: shrink_dentry_list() finds dispose list empty, returns 6 - Goto 2 with CPU0 and CPU1 switched Basically select_parent() steals the dentry from shrink_dentry_list() and thinks it found a new one, causing shrink_dentry_list() to think it's making progress and loop over and over. One way to trigger this is to make udev calls stat() on the sysfs file while it is going away. Having a file in /lib/udev/rules.d/ with only this one rule seems to the trick: ATTR{vendor}=="0x8086", ATTR{device}=="0x10ca", ENV{PCI_SLOT_NAME}="%k", ENV{MATCHADDR}="$attr{address}", RUN+="/bin/true" Then execute the following loop: while true; do echo -bond0 > /sys/class/net/bonding_masters echo +bond0 > /sys/class/net/bonding_masters echo -bond1 > /sys/class/net/bonding_masters echo +bond1 > /sys/class/net/bonding_masters done One fix would be to check all callers and prevent concurrent calls to shrink_dcache_parent(). But I think a better solution is to stop the stealing behavior. This patch adds a new dentry flag that is set when the dentry is added to the dispose list. The flag is cleared in dentry_lru_del() in case the dentry gets a new reference just before being pruned. If the dentry has this flag, select_parent() will skip it and let shrink_dentry_list() retry pruning it. With select_parent() skipping those dentries there will not be the appearance of progress (new dentries found) when there is none, hence shrink_dcache_parent() will not loop forever. Set the flag is also set in prune_dcache_sb() for consistency as suggested by Linus. Signed-off-by:
Miklos Szeredi <mszeredi@suse.cz> Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Dave Chinner authored
commit b48f03b3 upstream. select_parent currently abuses the dentry cache LRU to provide cleanup features for child dentries that need to be freed. It moves them to the tail of the LRU, then tells shrink_dcache_parent() to calls __shrink_dcache_sb to unconditionally move them to a dispose list (as DCACHE_REFERENCED is ignored). __shrink_dcache_sb() has to relock the dentries to move them off the LRU onto the dispose list, but otherwise does not touch the dentries that select_parent() moved to the tail of the LRU. It then passses the dispose list to shrink_dentry_list() which tries to free the dentries. IOWs, the use of __shrink_dcache_sb() is superfluous - we can build exactly the same list of dentries for disposal directly in select_parent() and call shrink_dentry_list() instead of calling __shrink_dcache_sb() to do that. This means that we avoid long holds on the lru lock walking the LRU moving dentries to the dispose list We also avoid the need to relock each dentry just to move it off the LRU, reducing the numebr of times we lock each dentry to dispose of them in shrink_dcache_parent() from 3 to 2 times. Further, we remove one of the two callers of __shrink_dcache_sb(). This also means that __shrink_dcache_sb can be moved into back into prune_dcache_sb() and we no longer have to handle referenced dentries conditionally, simplifying the code. Signed-off-by:
Dave Chinner <dchinner@redhat.com> Signed-off-by:
-
Haogang Chen authored
commit 806e23e9 upstream. There is a potential integer overflow in uvc_ioctl_ctrl_map(). When a large xmap->menu_count is passed from the userspace, the subsequent call to kmalloc() will allocate a buffer smaller than expected. map->menu_count and map->menu_info would later be used in a loop (e.g. in uvc_query_v4l2_ctrl), which leads to out-of-bound access. The patch checks the ioctl argument and returns -EINVAL for zero or too large values in xmap->menu_count. Signed-off-by:
Haogang Chen <haogangchen@gmail.com> [laurent.pinchart@ideasonboard.com Prevent excessive memory consumption] Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
-
David Daney authored
commit 2e885057 upstream. In ELF64, the sh_flags field is 64-bits wide. recordmcount was erroneously treating it as a 32-bit wide field. For little endian objects this works because the flags of interest (SHF_EXECINSTR) reside in the lower 32 bits of the word, and you get the same result with either a 32-bit or 64-bit read. Big endian objects on the other hand do not work at all with this error. The fix: Correctly treat sh_flags as 64-bits wide in elf64 objects. The symptom I observed was that my __start_mcount_loc..__stop_mcount_loc was empty even though ftrace function tracing was enabled. Link: http://lkml.kernel.org/r/1324345362-12230-1-git-send-email-ddaney.cavm@gmail.comSigned-off-by:
David Daney <david.daney@cavium.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Jack Steiner authored
commit da517a08 upstream. SGI UV systems print a message during boot: UV: Found <num> blades Due to packaging changes, the blade count is not accurate for on the next generation of the platform. This patch corrects the count. Signed-off-by:
Jack Steiner <steiner@sgi.com> Link: http://lkml.kernel.org/r/20120106191900.GA19772@sgi.comSigned-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Miklos Szeredi authored
commit fed47485 upstream. Removing the parent of a watched file results in "kernel BUG at fs/notify/mark.c:139". To reproduce add "-w /tmp/audit/dir/watched_file" to audit.rules rm -rf /tmp/audit/dir This is caused by fsnotify_destroy_mark() being called without an extra reference taken by the caller. Reported by Francesco Cosoleto here: https://bugzilla.novell.com/show_bug.cgi?id=689860 Fix by removing the BUG_ON and adding a comment about not accessing mark after the iput. Signed-off-by:
-
Sasha Levin authored
commit b2ea70af upstream. expkey_parse() oopses when handling a 0 length export. This is easily triggerable from usermode by writing 0 bytes into '/proc/[proc id]/net/rpc/nfsd.fh/channel'. Below is the log: [ 1402.286893] BUG: unable to handle kernel paging request at ffff880077c49fff [ 1402.287632] IP: [<ffffffff812b4b99>] expkey_parse+0x28/0x2e1 [ 1402.287632] PGD 2206063 PUD 1fdfd067 PMD 1ffbc067 PTE 8000000077c49160 [ 1402.287632] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC [ 1402.287632] CPU 1 [ 1402.287632] Pid: 20198, comm: trinity Not tainted 3.2.0-rc2-sasha-00058-gc65cd37 #6 [ 1402.287632] RIP: 0010:[<ffffffff812b4b99>] [<ffffffff812b4b99>] expkey_parse+0x28/0x2e1 [ 1402.287632] RSP: 0018:ffff880077f0fd68 EFLAGS: 00010292 [ 1402.287632] RAX: ffff880077c49fff RBX: 00000000ffffffea RCX: 0000000001043400 [ 1402.287632] RDX: 0000000000000000 RSI: ffff880077c4a000 RDI: ffffffff82283de0 [ 1402.287632] RBP: ffff880077f0fe18 R08: 0000000000000001 R09: ffff880000000000 [ 1402.287632] R10: 0000000000000000 R11: 0000000000000001 R12: ffff880077c4a000 [ 1402.287632] R13: ffffffff82283de0 R14: 0000000001043400 R15: ffffffff82283de0 [ 1402.287632] FS: 00007f25fec3f700(0000) GS:ffff88007d400000(0000) knlGS:0000000000000000 [ 1402.287632] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 1402.287632] CR2: ffff880077c49fff CR3: 0000000077e1d000 CR4: 00000000000406e0 [ 1402.287632] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1402.287632] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 1402.287632] Process trinity (pid: 20198, threadinfo ffff880077f0e000, task ffff880077db17b0) [ 1402.287632] Stack: [ 1402.287632] ffff880077db17b0 ffff880077c4a000 ffff880077f0fdb8 ffffffff810b411e [ 1402.287632] ffff880000000000 ffff880077db17b0 ffff880077c4a000 ffffffff82283de0 [ 1402.287632] 0000000001043400 ffffffff82283de0 ffff880077f0fde8 ffffffff81111f63 [ 1402.287632] Call Trace: [ 1402.287632] [<ffffffff810b411e>] ? lock_release+0x1af/0x1bc [ 1402.287632] [<ffffffff81111f63>] ? might_fault+0x97/0x9e [ 1402.287632] [<ffffffff81111f1a>] ? might_fault+0x4e/0x9e [ 1402.287632] [<ffffffff81a8bcf2>] cache_do_downcall+0x3e/0x4f [ 1402.287632] [<ffffffff81a8c950>] cache_write.clone.16+0xbb/0x130 [ 1402.287632] [<ffffffff81a8c9df>] ? cache_write_pipefs+0x1a/0x1a [ 1402.287632] [<ffffffff81a8c9f8>] cache_write_procfs+0x19/0x1b [ 1402.287632] [<ffffffff8118dc54>] proc_reg_write+0x8e/0xad [ 1402.287632] [<ffffffff8113fe81>] vfs_write+0xaa/0xfd [ 1402.287632] [<ffffffff8114142d>] ? fget_light+0x35/0x9e [ 1402.287632] [<ffffffff8113ff8b>] sys_write+0x48/0x6f [ 1402.287632] [<ffffffff81bbdb92>] system_call_fastpath+0x16/0x1b [ 1402.287632] Code: c0 c9 c3 55 48 63 d2 48 89 e5 48 8d 44 32 ff 41 57 41 56 41 55 41 54 53 bb ea ff ff ff 48 81 ec 88 00 00 00 48 89 b5 58 ff ff ff [ 1402.287632] 38 0a 0f 85 89 02 00 00 c6 00 00 48 8b 3d 44 4a e5 01 48 85 [ 1402.287632] RIP [<ffffffff812b4b99>] expkey_parse+0x28/0x2e1 [ 1402.287632] RSP <ffff880077f0fd68> [ 1402.287632] CR2: ffff880077c49fff [ 1402.287632] ---[ end trace 368ef53ff773a5e3 ]--- Cc: "J. Bruce Fields" <bfields@fieldses.org> Cc: Neil Brown <neilb@suse.de> Cc: linux-nfs@vger.kernel.org Signed-off-by:
Sasha Levin <levinsasha928@gmail.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
J. Bruce Fields authored
commit b93d87c1 upstream. Lockowners are looked up by file as well as by owner, but we were forgetting to do a comparison on the file. This could cause an incorrect result from lockt. (Note looking up the inode from the lockowner is pretty awkward here. The data structures need fixing.) Signed-off-by:
-
J. Bruce Fields authored
commit b4f36f88 upstream. Socket callbacks use svc_xprt_enqueue() to add an xprt to a pool->sp_sockets list. In normal operation a server thread will later come along and take the xprt off that list. On shutdown, after all the threads have exited, we instead manually walk the sv_tempsocks and sv_permsocks lists to find all the xprt's and delete them. So the sp_sockets lists don't really matter any more. As a result, we've mostly just ignored them and hoped they would go away. Which has gotten us into trouble; witness for example ebc63e53 "svcrpc: fix list-corrupting race on nfsd shutdown", the result of Ben Greear noticing that a still-running svc_xprt_enqueue() could re-add an xprt to an sp_sockets list just before it was deleted. The fix was to remove it from the list at the end of svc_delete_xprt(). But that only made corruption less likely--I can see nothing that prevents a svc_xprt_enqueue() from adding another xprt to the list at the same moment that we're removing this xprt from the list. In fact, despite the earlier xpo_detach(), I don't even see what guarantees that svc_xprt_enqueue() couldn't still be running on this xprt. So, instead, note that svc_xprt_enqueue() essentially does: lock sp_lock if XPT_BUSY unset add to sp_sockets unlock sp_lock So, if we do: set XPT_BUSY on every xprt. Empty every sp_sockets list, under the sp_socks locks. Then we're left knowing that the sp_sockets lists are all empty and will stay that way, since any svc_xprt_enqueue() will check XPT_BUSY under the sp_lock and see it set. And *then* we can continue deleting the xprt's. (Thanks to Jeff Layton for being correctly suspicious of this code....) Cc: Ben Greear <greearb@candelatech.com> Cc: Jeff Layton <jlayton@redhat.com> Signed-off-by:
-
J. Bruce Fields authored
commit 2fefb8a0 upstream. There's no reason I can see that we need to call sv_shutdown between closing the two lists of sockets. Signed-off-by:
-
J. Bruce Fields authored
commit 61c8504c upstream. The pool_to and to_pool fields of the global svc_pool_map are freed on shutdown, but are initialized in nfsd startup only in the SVC_POOL_PERCPU and SVC_POOL_PERNODE cases. They *are* initialized to zero on kernel startup. So as long as you use only SVC_POOL_GLOBAL (the default), this will never be a problem. You're also OK if you only ever use SVC_POOL_PERCPU or SVC_POOL_PERNODE. However, the following sequence events leads to a double-free: 1. set SVC_POOL_PERCPU or SVC_POOL_PERNODE 2. start nfsd: both fields are initialized. 3. shutdown nfsd: both fields are freed. 4. set SVC_POOL_GLOBAL 5. start nfsd: the fields are left untouched. 6. shutdown nfsd: now we try to free them again. Step 4 is actually unnecessary, since (for some bizarre reason), nfsd automatically resets the pool mode to SVC_POOL_GLOBAL on shutdown. Signed-off-by:
-
Steven Rostedt authored
commit 364212fd upstream. Thomas Lange reported that when he did a 'make localmodconfig', his config was missing the brcmsmac driver, even though he had the module loaded. Looking into this, I found the file: drivers/net/wireless/brcm80211/brcmsmac/Makefile had the following in the Makefile: MODULEPFX := brcmsmac obj-$(CONFIG_BRCMSMAC) += $(MODULEPFX).o The way streamline-config.pl works, is parsing all the obj-$(CONFIG_FOO) += foo.o lines to find that CONFIG_FOO belongs to the module foo.ko. But in this case, the brcmsmac.o was not used, but a variable in its place. By changing streamline-config.pl to remember defined variables in Makefiles and substituting them when they are used in the obj-X lines, allows Thomas (and others) to have their brcmsmac module stay configured when it is loaded and running "make localmodconfig". Reported-by:
Thomas Lange <thomas-lange2@gmx.de> Tested-by:
-
