- 05 Aug, 2011 40 commits
-
-
Steven Rostedt authored
commit 40ee4dff upstream. The "enable" file for the event system can be removed when a module is unloaded and the event system only has events from that module. As the event system nr_events count goes to zero, it may be freed if its ref_count is also set to zero. Like the "filter" file, the "enable" file may be opened by a task and referenced later, after a module has been unloaded and the events for that event system have been removed. Although the "filter" file referenced the event system structure, the "enable" file only references a pointer to the event system name. Since the name is freed when the event system is removed, it is possible that an access to the "enable" file may reference a freed pointer. Update the "enable" file to use the subsystem_open() routine that the "filter" file uses, to keep a reference to the event system structure while the "enable" file is opened. Reported-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Steven Rostedt authored
commit e9dbfae5 upstream. The event system is freed when its nr_events is set to zero. This happens when a module created an event system and then later the module is removed. Modules may share systems, so the system is allocated when it is created and freed when the modules are unloaded and all the events under the system are removed (nr_events set to zero). The problem arises when a task opened the "filter" file for the system. If the module is unloaded and it removed the last event for that system, the system structure is freed. If the task that opened the filter file accesses the "filter" file after the system has been freed, the system will access an invalid pointer. By adding a ref_count, and using it to keep track of what is using the event system, we can free it after all users are finished with the event system. Reported-by:
-
Peter Zijlstra authored
commit 0f933625 upstream. Commit e360adbe ("irq_work: Add generic hardirq context callbacks") fouled up the Alpha bit, not properly naming the arch specific function that raises the 'self-IPI'. Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Michael Cree <mcree@orcon.net.nz> Link: http://lkml.kernel.org/n/tip-gukh0txmql2l4thgrekzzbfy@git.kernel.orgSigned-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Michael Neuling authored
commit 63f21a56 upstream. The existing code it pretty ugly. How about we clean it up even more like this? From: Anton Blanchard <anton@samba.org> We check for timeout expiry in the outer loop, but we also need to check it in the inner loop or we can lock up forever waiting for a CPU to hit real mode. Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
Michael Neuling <mikey@neuling.org> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Robert Richter authored
commit a0e3e702 upstream. Current oprofile's x86 callgraph support may trigger page faults throwing the BUG_ON(in_nmi()) message below. This patch fixes this by using the same nmi-safe copy-from-user code as in perf. ------------[ cut here ]------------ kernel BUG at .../arch/x86/kernel/traps.c:436! invalid opcode: 0000 [#1] SMP last sysfs file: /sys/devices/pci0000:00/0000:00:0a.0/0000:07:00.0/0000:08:04.0/net/eth0/broadcast CPU 5 Modules linked in: Pid: 8611, comm: opcontrol Not tainted 2.6.39-00007-gfe47ae7f #1 Advanced Micro Device Anaheim/Anaheim RIP: 0010:[<ffffffff813e8e35>] [<ffffffff813e8e35>] do_nmi+0x22/0x1ee RSP: 0000:ffff88042fd47f28 EFLAGS: 00010002 RAX: ffff88042c0a7fd8 RBX: 0000000000000001 RCX: 00000000c0000101 RDX: 00000000ffff8804 RSI: ffffffffffffffff RDI: ffff88042fd47f58 RBP: ffff88042fd47f48 R08: 0000000000000004 R09: 0000000000001484 R10: 0000000000000001 R11: 0000000000000000 R12: ffff88042fd47f58 R13: 0000000000000000 R14: ffff88042fd47d98 R15: 0000000000000020 FS: 00007fca25e56700(0000) GS:ffff88042fd40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000074 CR3: 000000042d28b000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process opcontrol (pid: 8611, threadinfo ffff88042c0a6000, task ffff88042c532310) Stack: 0000000000000000 0000000000000001 ffff88042c0a7fd8 0000000000000000 ffff88042fd47de8 ffffffff813e897a 0000000000000020 ffff88042fd47d98 0000000000000000 ffff88042c0a7fd8 ffff88042fd47de8 0000000000000074 Call Trace: <NMI> [<ffffffff813e897a>] nmi+0x1a/0x20 [<ffffffff813f08ab>] ? bad_to_user+0x25/0x771 <<EOE>> Code: ff 59 5b 41 5c 41 5d c9 c3 55 65 48 8b 04 25 88 b5 00 00 48 89 e5 41 55 41 54 49 89 fc 53 48 83 ec 08 f6 80 47 e0 ff ff 04 74 04 <0f> 0b eb fe 81 80 44 e0 ff ff 00 00 01 04 65 ff 04 25 c4 0f 01 RIP [<ffffffff813e8e35>] do_nmi+0x22/0x1ee RSP <ffff88042fd47f28> ---[ end trace ed6752185092104b ]--- Kernel panic - not syncing: Fatal exception in interrupt Pid: 8611, comm: opcontrol Tainted: G D 2.6.39-00007-gfe47ae7f #1 Call Trace: <NMI> [<ffffffff813e5e0a>] panic+0x8c/0x188 [<ffffffff813e915c>] oops_end+0x81/0x8e [<ffffffff8100403d>] die+0x55/0x5e [<ffffffff813e8c45>] do_trap+0x11c/0x12b [<ffffffff810023c8>] do_invalid_op+0x91/0x9a [<ffffffff813e8e35>] ? do_nmi+0x22/0x1ee [<ffffffff8131e6fa>] ? oprofile_add_sample+0x83/0x95 [<ffffffff81321670>] ? op_amd_check_ctrs+0x4f/0x2cf [<ffffffff813ee4d5>] invalid_op+0x15/0x20 [<ffffffff813e8e35>] ? do_nmi+0x22/0x1ee [<ffffffff813e8e7a>] ? do_nmi+0x67/0x1ee [<ffffffff813e897a>] nmi+0x1a/0x20 [<ffffffff813f08ab>] ? bad_to_user+0x25/0x771 <<EOE>> Cc: John Lumby <johnlumby@hotmail.com> Cc: Maynard Johnson <maynardj@us.ibm.com> Signed-off-by:
Robert Richter <robert.richter@amd.com> Signed-off-by:
-
Huang Ying authored
commit 050438ed upstream. In kexec jump support, jump back address passed to the kexeced kernel via function calling ABI, that is, the function call return address is the jump back entry. Furthermore, jump back entry == 0 should be used to signal that the jump back or preserve context is not enabled in the original kernel. But in the current implementation the stack position used for function call return address is not cleared context preservation is disabled. The patch fixes this bug. Reported-and-tested-by:
Yin Kangkai <kangkai.yin@intel.com> Signed-off-by:
Huang Ying <ying.huang@intel.com> Cc: Eric W. Biederman <ebiederm@xmission.com> Cc: Vivek Goyal <vgoyal@redhat.com> Link: http://lkml.kernel.org/r/1310607277-25029-1-git-send-email-ying.huang@intel.comSigned-off-by:
-
Peng Tao authored
commit 3557c6c3 upstream. Using NFS4_MAX_UINT64 will break current protocol. [Needed in v3.0] Signed-off-by:
Peng Tao <peng_tao@emc.com> Signed-off-by:
Jim Rees <rees@umich.edu> Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Peng Tao authored
commit a9bae566 upstream. There can be multiple lseg per file, so layoutcommit should be able to handle it. [Needed in v3.0] Signed-off-by:
Boaz Harrosh <bharrosh@panasas.com> Signed-off-by:
-
Peng Tao authored
commit 9fa40758 upstream. No need to save it for every lseg. No need to save it at every pnfs_set_layoutcommit. [Needed in v3.0] Signed-off-by:
-
Peng Tao authored
commit acff5880 upstream. No need to save it for every lseg. [Needed in v3.0] Signed-off-by:
-
Takashi Iwai authored
commit c48a8fb0 upstream. Copying hp_pins and speaker_pins from line_out_pins may confuse the parser, and it can lead to duplicated initializations for the same pin with a wrong DAC assignment. The problem appears in 3.0 kernel code. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Clemens Ladisch authored
commit c81c6b35 upstream. Commit dd203fa9 (ALSA: virtuoso: remove non-working controls on Essence ST Deluxe) made it impossible to adjust the volume after the driver initialized it to muted. Ensure that those DACs that can be accessed with I2C are initialized to the same volume that is the reset default of the DAC without I2C. Signed-off-by:
Clemens Ladisch <clemens@ladisch.de> Signed-off-by:
-
Alex Deucher authored
commit 4639dd21 upstream. Need to add vddci setting to pm init as well as resume. Fixes hangs on load on some boards. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=38754Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Jerome Glisse authored
commit 5a96a899 upstream. DPEncoderService newer than 1.1 can't properly program the DP (display port) link training. When facing such version use the DIGxEncoderControl method instead. Fix DP link training on some R7XX. Signed-off-by:
Jerome Glisse <jglisse@redhat.com> Reviewed-by:
-
Alex Deucher authored
commit 6dd66633 upstream. Those chips have crt2_ddc bus. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=39672Signed-off-by:
-
Stephen M. Cameron authored
commit fec62c36 upstream. Most smartarrays tolerate it, but a few new ones don't. Without this change some newer Smart Arrays will lock up and i/o will grind to a halt. Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
Dan Rosenberg authored
commit b5b51544 upstream. There's a code path in pmcraid that can be reached via device ioctl that causes all sorts of ugliness, including heap corruption or triggering the OOM killer due to consecutive allocation of large numbers of pages. First, the user can call pmcraid_chr_ioctl(), with a type PMCRAID_PASSTHROUGH_IOCTL. This calls through to pmcraid_ioctl_passthrough(). Next, a pmcraid_passthrough_ioctl_buffer is copied in, and the request_size variable is set to buffer->ioarcb.data_transfer_length, which is an arbitrary 32-bit signed value provided by the user. If a negative value is provided here, bad things can happen. For example, pmcraid_build_passthrough_ioadls() is called with this request_size, which immediately calls pmcraid_alloc_sglist() with a negative size. The resulting math on allocating a scatter list can result in an overflow in the kzalloc() call (if num_elem is 0, the sglist will be smaller than expected), or if num_elem is unexpectedly large the subsequent loop will call alloc_pages() repeatedly, a high number of pages will be allocated and the OOM killer might be invoked. It looks like preventing this value from being negative in pmcraid_ioctl_passthrough() would be sufficient. Signed-off-by:
Dan Rosenberg <drosenberg@vsecurity.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
James Bottomley authored
commit bfe159a5 upstream. USB surprise removal of sr is triggering an oops in scsi_dispatch_command(). What seems to be happening is that USB is hanging on to a queue reference until the last close of the upper device, so the crash is caused by surprise remove of a mounted CD followed by attempted unmount. The problem is that USB doesn't issue its final commands as part of the SCSI teardown path, but on last close when the block queue is long gone. The long term fix is probably to make sr do the teardown in the same way as sd (so remove all the lower bits on ejection, but keep the upper disk alive until last close of user space). However, the current oops can be simply fixed by not allowing any commands to be sent to a dead queue. Signed-off-by:
-
Douglas Gilbert authored
commit 2a350cab upstream. Noticed that when the sysfs interface of the SCSI SES driver was used to request a fault indication the LED flashed but the buzzer didn't sound. So it was doing what REQUEST IDENT (locate) should do. Changelog: - fix the setting of REQUEST FAULT for the device slot and array device slot elements in the enclosure control diagnostic page - note the potentially defective code that reads the FAULT SENSED and FAULT REQUESTED bits from the enclosure status diagnostic page The attached patch is against git/scsi-misc-2.6 Signed-off-by:
Douglas Gilbert <dgilbert@interlog.com> Signed-off-by:
-
Kay Sievers authored
commit 79b9677d upstream. Some broken devices indicates that media has changed on every GET_EVENT_STATUS_NOTIFICATION. This translates into MEDIA_CHANGE uevent on every open() which lets udev run into a loop. Verify GET_EVENT result against TUR and if it generates spurious events for several times in a row, ignore the GET_EVENT events, and trust only the TUR status. This is the log of a USB stick with a (broken) fake CDROM drive: scsi 5:0:0:0: Direct-Access SanDisk U3 Cruzer Micro 8.02 PQ: 0 ANSI: 0 CCS sd 5:0:0:0: Attached scsi generic sg3 type 0 scsi 5:0:0:1: CD-ROM SanDisk U3 Cruzer Micro 8.02 PQ: 0 ANSI: 0 sd 5:0:0:0: [sdb] Attached SCSI removable disk sr2: scsi3-mmc drive: 48x/48x tray sr 5:0:0:1: Attached scsi CD-ROM sr2 sr 5:0:0:1: Attached scsi generic sg4 type 5 sr2: GET_EVENT and TUR disagree continuously, suppress GET_EVENT events sd 5:0:0:0: [sdb] 31777279 512-byte logical blocks: (16.2 GB/15.1 GiB) sd 5:0:0:0: [sdb] No Caching mode page present sd 5:0:0:0: [sdb] Assuming drive cache: write through sd 5:0:0:0: [sdb] No Caching mode page present sd 5:0:0:0: [sdb] Assuming drive cache: write through sdb: sdb1 -tj: Updated to consider only spurious GET_EVENT events among different types of disagreement and allow using TUR for kernel event polling after GET_EVENT is ignored. Reported-By: Markus Rathgeb maggu2810@googlemail.com Signed-off-by:
Kay Sievers <kay.sievers@vrfy.org> Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Werner Fink authored
commit 82103978 upstream. This patch resulted from the discussion at https://bugzilla.novell.com/show_bug.cgi?id=679277, https://bugzilla.novell.com/show_bug.cgi?id=681840 . Signed-off-by:
Werner Fink <werner@novell.com> Signed-off-by:
Ankit Jain <jankit@suse.de> Signed-off-by:
-
Peter Zijlstra authored
The below patch is for -stable only, upstream has a much larger patch that contains the below hunk in commit a8b0ca17 Vince found that under certain circumstances software event overflows go wrong and deadlock. Avoid trying to delete a timer from the timer callback. Reported-by:
Vince Weaver <vweaver1@eecs.utk.edu> Signed-off-by:
-
Len Brown authored
commit abe48b10 upstream. Since 2.6.36 (23016bf0), Linux prints the existence of "epb" in /proc/cpuinfo, Since 2.6.38 (d5532ee7), the x86_energy_perf_policy(8) utility has been available in-tree to update MSR_IA32_ENERGY_PERF_BIAS. However, the typical BIOS fails to initialize the MSR, presumably because this is handled by high-volume shrink-wrap operating systems... Linux distros, on the other hand, do not yet invoke x86_energy_perf_policy(8). As a result, WSM-EP, SNB, and later hardware from Intel will run in its default hardware power-on state (performance), which assumes that users care for performance at all costs and not for energy efficiency. While that is fine for performance benchmarks, the hardware's intended default operating point is "normal" mode... Initialize the MSR to the "normal" by default during kernel boot. x86_energy_perf_policy(8) is available to change the default after boot, should the user have a different preference. Signed-off-by:
Len Brown <len.brown@intel.com> Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1107140051020.18606@x980Acked-by:
Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
-
David Ahern authored
commit eda3913b upstream. The perf_event_attr struct has two __u32's at the top and they need to be swapped individually. With this change I was able to analyze a perf.data collected in a 32-bit PPC VM on an x86 system. I tested both 32-bit and 64-bit binaries for the Intel analysis side; both read the PPC perf.data file correctly. -v2: - changed the existing perf_event__attr_swap() to swap only elements of perf_event_attr and exported it for use in swapping the attributes in the file header - updated swap_ops used for processing events Signed-off-by:
David Ahern <dsahern@gmail.com> Acked-by:
Frederic Weisbecker <fweisbec@gmail.com> Cc: acme@ghostprotocols.net Cc: peterz@infradead.org Cc: paulus@samba.org Link: http://lkml.kernel.org/r/1310754849-12474-1-git-send-email-dsahern@gmail.comSigned-off-by:
-
David Ahern authored
commit 08a4a43f upstream. Builds for 32-bit perf binaries on a 64-bit host currently fail with this error: [...] bench/../../../arch/x86/lib/memcpy_64.S: Assembler messages: bench/../../../arch/x86/lib/memcpy_64.S:29: Error: bad register name `%rdi' bench/../../../arch/x86/lib/memcpy_64.S:34: Error: invalid instruction suffix for `movs' bench/../../../arch/x86/lib/memcpy_64.S:50: Error: bad register name `%rdi' bench/../../../arch/x86/lib/memcpy_64.S:61: Error: bad register name `%rdi' ... The problem is the detection of the host arch without considering passed in flags. This change fixes 32-bit builds via: make EXTRA_CFLAGS=-m32 and 64-bit builds still reference the memcpy_64.S. Signed-off-by:
-
Peter Zijlstra authored
commit 4f8b50bb upstream. Commit e360adbe ("irq_work: Add generic hardirq context callbacks") fouled up the ppc bit, not properly naming the arch specific function that raises the 'self-IPI'. Cc: Huang Ying <ying.huang@intel.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Anton Blanchard <anton@samba.org> Cc: Eric B Munson <emunson@mgebm.net> Signed-off-by:
-
Rajkumar Manoharan authored
commit 676b58c2 upstream. A panic was observed when the device is failed to resume properly, and there are no running interfaces. ieee80211_reconfig tries to restart STA timers on unassociated state. Signed-off-by:
Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Larry Finger authored
commit 1288aa4e upstream. A typo causes routine rtl92cu_phy_rf6052_set_cck_txpower() to test the same condition twice. The problem was found using cppcheck-1.49, and the proper fix was verified against the pre-mac80211 version of the code. Reported-by:
David Binderman <dcb314@hotmail.com> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Luben Tuikov authored
commit 5911e963 upstream. If expander discovery fails (sas_discover_expander()), remove the expander from the port device list (sas_ex_discover_expander()), before freeing it. Else the list is corrupted and, e.g., when we attempt to send SMP commands to other devices, the kernel oopses. Signed-off-by:
Luben Tuikov <ltuikov@yahoo.com> Reviewed-by:
Jack Wang <jack_wang@usish.com> Signed-off-by:
-
Bart Van Assche authored
commit fd1b6c4a upstream. SCSI scanning of a channel:id:lun triplet in Linux works as follows (function scsi_scan_target() in drivers/scsi/scsi_scan.c): - If lun == SCAN_WILD_CARD, send a REPORT LUNS command to the target and process the result. - If lun != SCAN_WILD_CARD, send an INQUIRY command to the LUN corresponding to the specified channel:id:lun triplet to verify whether the LUN exists. So a SCSI driver must either take the channel and target id values in account in its quecommand() function or it should declare that it only supports one channel and one target id. Currently the ib_srp driver does neither. As a result scanning the SCSI bus via e.g. rescan-scsi-bus.sh causes many duplicate SCSI devices to be created. For each 0:0:L device, several duplicates are created with the same LUN number and with (C:I) != (0:0). Fix this by declaring that the ib_srp driver only supports one channel and one target id. Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Acked-by:
David Dillow <dillowda@ornl.gov> Signed-off-by:
Roland Dreier <roland@purestorage.com> Signed-off-by:
-
Stefan Richter authored
commit 93b37905 upstream. Between open(2) of a /dev/fw* and the first FW_CDEV_IOC_GET_INFO ioctl(2) on it, the kernel already queues FW_CDEV_EVENT_BUS_RESET events to be read(2) by the client. The get_info ioctl is practically always issued right away after open, hence this condition only occurs if the client opens during a bus reset, especially during a rapid series of bus resets. The problem with this condition is twofold: - These bus reset events carry the (as yet undocumented) @closure value of 0. But it is not the kernel's place to choose closures; they are privat to the client. E.g., this 0 value forced from the kernel makes it unsafe for clients to dereference it as a pointer to a closure object without NULL pointer check. - It is impossible for clients to determine the relative order of bus reset events from get_info ioctl(2) versus those from read(2), except in one way: By comparison of closure values. Again, such a procedure imposes complexity on clients and reduces freedom in use of the bus reset closure. So, change the ABI to suppress queuing of bus reset events before the first FW_CDEV_IOC_GET_INFO ioctl was issued by the client. Note, this ABI change cannot be version-controlled. The kernel cannot distinguish old from new clients before the first FW_CDEV_IOC_GET_INFO ioctl. We will try to back-merge this change into currently maintained stable/ longterm series, and we only document the new behaviour. The old behavior is now considered a kernel bug, which it basically is. Signed-off-by:
Stefan Richter <stefanr@s5r6.in-berlin.de> Cc: <stable@kernel.org>
-
Stefan Richter authored
commit d873d794 upstream. On Jun 27 Linus Torvalds wrote: > The correct error code for "I don't understand this ioctl" is ENOTTY. > The naming may be odd, but you should think of that error value as a > "unrecognized ioctl number, you're feeding me random numbers that I > don't understand and I assume for historical reasons that you tried to > do some tty operation on me". [...] > The EINVAL thing goes way back, and is a disaster. It predates Linux > itself, as far as I can tell. You'll find lots of man-pages that have > this line in it: > > EINVAL Request or argp is not valid. > > and it shows up in POSIX etc. And sadly, it generally shows up > _before_ the line that says > > ENOTTY The specified request does not apply to the kind of object > that the descriptor d references. > > so a lot of people get to the EINVAL, and never even notice the ENOTTY. [...] > At least glibc (and hopefully other C libraries) use a _string_ that > makes much more sense: strerror(ENOTTY) is "Inappropriate ioctl for > device" So let's correct this in the <linux/firewire-cdev.h> ABI while it is still young, relative to distributor adoption. Side note: We return -ENOTTY not only on _IOC_TYPE or _IOC_NR mismatch, but also on _IOC_SIZE mismatch. An ioctl with an unsupported size of argument structure can be seen as an unsupported version of that ioctl. Signed-off-by:
-
Ben Hutchings authored
commit 67ae7cf1 upstream. Some drivers (ab)use the ethtool_ops::get_regs operation to expose only a hardware revision ID. Commit a77f5db3 ('ethtool: Allocate register dump buffer with vmalloc()') had the side-effect of breaking these, as vmalloc() returns a null pointer for size=0 whereas kmalloc() did not. For backward-compatibility, allow zero-length dumps again. Reported-by:
Kalle Valo <kvalo@qca.qualcomm.com> Signed-off-by:
Ben Hutchings <bhutchings@solarflare.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Guo-Fu Tseng authored
commit 94c5b41b upstream. This patch add the missing dma_unmap(). Which solved the critical issue of system freeze on heavy load. Michal Miroslaw's rejected patch: [PATCH v2 10/46] net: jme: convert to generic DMA API Pointed out the issue also, thank you Michal. But the fix was incorrect. It would unmap needed address when low memory. Got lots of feedback from End user and Gentoo Bugzilla. https://bugs.gentoo.org/show_bug.cgi?id=373109 Thank you all. :) Signed-off-by:
Guo-Fu Tseng <cooldavid@cooldavid.org> Acked-by:
Chris Wright <chrisw@sous-sol.org> Signed-off-by:
-
Roland Vossen authored
commit 37c962d1 upstream. Every few minutes, this message would appear in syslog: ieee80211 ph0: wl_ops_bss_info_changed: BSS idle: true (implement) The message has been deleted, the driver requires no special action on this particular event (). See: https://bugzilla.kernel.org/show_bug.cgi?id=38162Reported-by:
David Hill <hilld@binarystorm.net> Signed-off-by:
Roland Vossen <rvossen@broadcom.com> Reviewed-by:
Arend van Spriel <arend@broadcom.com> Reviewed-by:
Franky Lin <frankyl@broadcom.com> Signed-off-by:
Stefan Lippers-Hollmann <s.l-h@gmx.de>
-
Pavel Shilovsky authored
commit f5bc1e75 upstream. commit fec11dd9 caused a regression when we have already mounted //server/share/a and want to mount //server/share/a/b. The problem is that lookup_one_len calls __lookup_hash with nd pointer as NULL. Then __lookup_hash calls do_revalidate in the case when dentry exists and we end up with NULL pointer deference in cifs_d_revalidate: if (nd->flags & LOOKUP_RCU) return -ECHILD; Fix this by checking nd for NULL. Signed-off-by:
Pavel Shilovsky <piastryyy@gmail.com> Reviewed-by:
Shirish Pargaonkar <shirishp@us.ibm.com> Signed-off-by:
Steve French <sfrench@us.ibm.com> Signed-off-by:
-
Senthil Balasubramanian authored
commit 0472ade0 upstream. Decryping frames on key_miss handling shouldn't be done for Michael MIC failed frames as h/w would have already decrypted such frames successfully anyway. Also leaving CRC and PHY error(where the frame is going to be dropped anyway), we are left to prcoess Decrypt error for which s/w decrypt is selected anway and so having key_miss as a separate check doesn't serve anything. So making key_miss handling mutually exlusive with other RX status handling makes much more sense. This patch addresses an issue with STA not reporting MIC failure events resulting in STA being disconnected immediately. Signed-off-by:
Senthil Balasubramanian <senthilb@qca.qualcomm.com> Signed-off-by:
-
Kalle Valo authored
commit 98ab5c77 upstream. When ath6kl module was resumed while a scan was ongoing, for example during suspend, the driver would crash in ar6k_cfg80211_scanComplete_event(): [26581.586440] Call Trace: [26581.586440] [<f99ffeda>] ? ar6k_cfg80211_scanComplete_event+0xaa/0xaa [ath6kl] [26581.586440] [<f9a0a020>] wmi_iterate_nodes+0xb/0xd [ath6kl] [26581.586440] [<f99ffe78>] ar6k_cfg80211_scanComplete_event+0x48/0xaa [ath6kl] [26581.586440] [<f9a038ae>] ar6000_close+0x77/0x7e [ath6kl] [26581.586440] [<c139c25d>] __dev_close_many+0x87/0xab [26581.586440] [<c139c30a>] dev_close_many+0x54/0xab [26581.586440] [<c139c437>] rollback_registered_many+0xa5/0x19e [26581.586440] [<c139c595>] rollback_registered+0x23/0x2f [26581.586440] [<c139c5ed>] unregister_netdevice_queue+0x4c/0x69 [26581.586440] [<c139c6b2>] unregister_netdev+0x18/0x1f [26581.586440] [<f9a00d4c>] ar6000_destroy+0xf8/0x115 [ath6kl] [26581.586440] [<f9a0c765>] ar6k_cleanup_module+0x20/0x29 [ath6kl] [26581.586440] [<c1062843>] sys_delete_module+0x181/0x1d9 [26581.586440] [<c105876b>] ? lock_release_holdtime+0x2b/0xcd [26581.586440] [<c10b55dc>] ? sys_munmap+0x3b/0x42 [26581.586440] [<c14a99dc>] ? restore_all+0xf/0xf [26581.586440] [<c14aeb6c>] sysenter_do_call+0x12/0x32 [26581.586440] Code: 89 53 6c 75 07 89 d8 e8 c0 ff ff ff 89 f0 e8 2c f2 a9 c7 5b 5e 5d c3 55 89 e5 57 56 53 89 c3 83 ec 08 89 55 f0 8d 78 04 89 4d ec <8b> b0 b8 00 00 00 46 89 b0 b8 00 00 00 89 f8 e8 ae ed a9 c7 8b Fix the function not to iterate nodes when the scan is aborted. The nodes are already freed when the module is being unloaded. Patch "ath6kl: Fix a kernel panic furing suspend/resume" tried to fix this already but it wasn't enough as a pointer was still used even after the null check. This patch removes the null check entirely as the wmi structure is not accessed anymore during module unload. Also fix a bug where the status was checked as a bitfield with '&' operator. But it's not a bitfield, just a regular (enum like) value. Signed-off-by:
-
Kalle Valo authored
commit b42a7b1b upstream. Drivers should not request firmware during resume. Fix ath6kl to cache the firmware instead. Signed-off-by:
-
Mark Brown authored
commit 7be4ba24 upstream. Since quite a few drivers are not managing to flag the cache as needing to be resynced after suspend and it's a reasonable thing to do flag the cache as needing sync automatically when suspending. The expectation is that systems will mainly only keep the CODEC powered when doing audio through the CODEC so we won't actually suspend the device anyway; drivers which want to can override this behaviour when they resume. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Acked-by:
Liam Girdwood <lrg@ti.com> Signed-off-by:
-
