- 11 Nov, 2011 40 commits
-
-
Florian Tobias Schandinat authored
commit d933990c upstream. As Laurent pointed out we must not use any information in the passed var besides xoffset, yoffset and vmode as otherwise applications might abuse it. Also use the aligned fix.line_length and not the (possible) unaligned xres_virtual. Signed-off-by:
Florian Tobias Schandinat <FlorianSchandinat@gmx.de> Reported-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Bruno Prémont authored
commit 4a47a0e0 upstream. Following on Herton's patch "fb: avoid possible deadlock caused by fb_set_suspend" which moves lock_fb_info() out of fb_set_suspend() to its callers, correct sh-mobile's locking around call to fb_set_suspend() and the same sort of deaklocks with console_lock() due to order of taking the lock. console_lock() must be taken while fb_info is already locked and fb_info must be locked while calling fb_set_suspend(). Signed-off-by:
Bruno Prémont <bonbons@linux-vserver.org> Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by:
-
Herton Ronaldo Krzesinski authored
commit 9e769ff3 upstream. A lock ordering issue can cause deadlocks: in framebuffer/console code, all needed struct fb_info locks are taken before acquire_console_sem(), in places which need to take console semaphore. But fb_set_suspend is always called with console semaphore held, and inside it we call lock_fb_info which gets the fb_info lock, inverse locking order of what the rest of the code does. This causes a real deadlock issue, when we write to state fb sysfs attribute (which calls fb_set_suspend) while a framebuffer is being unregistered by remove_conflicting_framebuffers, as can be shown by following show blocked state trace on a test program which loads i915 and runs another forked processes writing to state attribute: Test process with semaphore held and trying to get fb_info lock: .. fb-test2 D 0000000000000000 0 237 228 0x00000000 ffff8800774f3d68 0000000000000082 00000000000135c0 00000000000135c0 ffff880000000000 ffff8800774f3fd8 ffff8800774f3fd8 ffff880076ee4530 00000000000135c0 ffff8800774f3fd8 ffff8800774f2000 00000000000135c0 Call Trace: [<ffffffff8141287a>] __mutex_lock_slowpath+0x11a/0x1e0 [<ffffffff814142f2>] ? _raw_spin_lock_irq+0x22/0x40 [<ffffffff814123d3>] mutex_lock+0x23/0x50 [<ffffffff8125dfc5>] lock_fb_info+0x25/0x60 [<ffffffff8125e3f0>] fb_set_suspend+0x20/0x80 [<ffffffff81263e2f>] store_fbstate+0x4f/0x70 [<ffffffff812e7f70>] dev_attr_store+0x20/0x30 [<ffffffff811c46b4>] sysfs_write_file+0xd4/0x160 [<ffffffff81155a26>] vfs_write+0xc6/0x190 [<ffffffff81155d51>] sys_write+0x51/0x90 [<ffffffff8100c012>] system_call_fastpath+0x16/0x1b .. modprobe process stalled because has the fb_info lock (got inside unregister_framebuffer) but waiting for the semaphore held by the test process which is waiting to get the fb_info lock: .. modprobe D 0000000000000000 0 230 218 0x00000000 ffff880077a4d618 0000000000000082 0000000000000001 0000000000000001 ffff880000000000 ffff880077a4dfd8 ffff880077a4dfd8 ffff8800775a2e20 00000000000135c0 ffff880077a4dfd8 ffff880077a4c000 00000000000135c0 Call Trace: [<ffffffff81411fe5>] schedule_timeout+0x215/0x310 [<ffffffff81058051>] ? get_parent_ip+0x11/0x50 [<ffffffff814130dd>] __down+0x6d/0xb0 [<ffffffff81089f71>] down+0x41/0x50 [<ffffffff810629ac>] acquire_console_sem+0x2c/0x50 [<ffffffff812ca53d>] unbind_con_driver+0xad/0x2d0 [<ffffffff8126f5f7>] fbcon_event_notify+0x457/0x890 [<ffffffff814144ff>] ? _raw_spin_unlock_irqrestore+0x1f/0x50 [<ffffffff81058051>] ? get_parent_ip+0x11/0x50 [<ffffffff8141836d>] notifier_call_chain+0x4d/0x70 [<ffffffff8108a3b8>] __blocking_notifier_call_chain+0x58/0x80 [<ffffffff8108a3f6>] blocking_notifier_call_chain+0x16/0x20 [<ffffffff8125dabb>] fb_notifier_call_chain+0x1b/0x20 [<ffffffff8125e6ac>] unregister_framebuffer+0x7c/0x130 [<ffffffff8125e8b3>] remove_conflicting_framebuffers+0x153/0x180 [<ffffffff8125eef3>] register_framebuffer+0x93/0x2c0 [<ffffffffa0331112>] drm_fb_helper_single_fb_probe+0x252/0x2f0 [drm_kms_helper] [<ffffffffa03314a3>] drm_fb_helper_initial_config+0x2f3/0x6d0 [drm_kms_helper] [<ffffffffa03318dd>] ? drm_fb_helper_single_add_all_connectors+0x5d/0x1c0 [drm_kms_helper] [<ffffffffa037b588>] intel_fbdev_init+0xa8/0x160 [i915] [<ffffffffa0343d74>] i915_driver_load+0x854/0x12b0 [i915] [<ffffffffa02f0e7e>] drm_get_pci_dev+0x19e/0x360 [drm] [<ffffffff8141821d>] ? sub_preempt_count+0x9d/0xd0 [<ffffffffa0386f91>] i915_pci_probe+0x15/0x17 [i915] [<ffffffff8124481f>] local_pci_probe+0x5f/0xd0 [<ffffffff81244f89>] pci_device_probe+0x119/0x120 [<ffffffff812eccaa>] ? driver_sysfs_add+0x7a/0xb0 [<ffffffff812ed003>] driver_probe_device+0xa3/0x290 [<ffffffff812ed1f0>] ? __driver_attach+0x0/0xb0 [<ffffffff812ed29b>] __driver_attach+0xab/0xb0 [<ffffffff812ed1f0>] ? __driver_attach+0x0/0xb0 [<ffffffff812ebd3e>] bus_for_each_dev+0x5e/0x90 [<ffffffff812ecc2e>] driver_attach+0x1e/0x20 [<ffffffff812ec6f2>] bus_add_driver+0xe2/0x320 [<ffffffffa03aa000>] ? i915_init+0x0/0x96 [i915] [<ffffffff812ed536>] driver_register+0x76/0x140 [<ffffffffa03aa000>] ? i915_init+0x0/0x96 [i915] [<ffffffff81245216>] __pci_register_driver+0x56/0xd0 [<ffffffffa02f1264>] drm_pci_init+0xe4/0xf0 [drm] [<ffffffffa03aa000>] ? i915_init+0x0/0x96 [i915] [<ffffffffa02e84a8>] drm_init+0x58/0x70 [drm] [<ffffffffa03aa094>] i915_init+0x94/0x96 [i915] [<ffffffff81002194>] do_one_initcall+0x44/0x190 [<ffffffff810a066b>] sys_init_module+0xcb/0x210 [<ffffffff8100c012>] system_call_fastpath+0x16/0x1b .. fb-test2 which reproduces above is available on kernel.org bug #26232. To solve this issue, avoid calling lock_fb_info inside fb_set_suspend, and move it out to where needed (callers of fb_set_suspend must call lock_fb_info before if needed). So far, the only place which needs to call lock_fb_info is store_fbstate, all other places which calls fb_set_suspend are suspend/resume hooks that should not need the lock as they should be run only when processes are already frozen in suspend/resume. References: https://bugzilla.kernel.org/show_bug.cgi?id=26232Signed-off-by:
Herton Ronaldo Krzesinski <herton@mandriva.com.br> Signed-off-by:
-
Jean Delvare authored
commit c84c1422 upstream. The third parameter of module_param is supposed to be an octal value. The missing leading "0" causes the following: $ ls -l /sys/module/carminefb/parameters/ total 0 -rw-rwxr-- 1 root root 4096 Jul 8 08:55 fb_displays -rw-rwxr-- 1 root root 4096 Jul 8 08:55 fb_mode -rw-rwxr-- 1 root root 4096 Jul 8 08:55 fb_mode_str After fixing the perm parameter, we get the expected: $ ls -l /sys/module/carminefb/parameters/ total 0 -r--r--r-- 1 root root 4096 Jul 8 08:56 fb_displays -r--r--r-- 1 root root 4096 Jul 8 08:56 fb_mode -r--r--r-- 1 root root 4096 Jul 8 08:56 fb_mode_str Signed-off-by:
Jean Delvare <jdelvare@suse.de> Cc: Paul Mundt <lethal@linux-sh.org> Cc: Sebastian Siewior <bigeasy@linutronix.de> Signed-off-by:
Paul Mundt <lethal@linux-sh.org> Signed-off-by:
-
Joerg Roedel authored
commit fcd0861d upstream. The shift direction was wrong because the function takes a page number and i is the address is the loop. Signed-off-by:
Joerg Roedel <joerg.roedel@amd.com> Signed-off-by:
-
Dmitry Torokhov authored
commit 023b9565 upstream. We need to remove devices that we destroy from the list, otherwise we'll crash if there are more than one "_WDG" methods in DSDT. This fixes https://bugzilla.kernel.org/show_bug.cgi?id=32052Tested-by:
Ilya Tumaykin <librarian_rus@yahoo.com> Signed-off-by:
Dmitry Torokhov <dtor@mail.ru> Acked-by:
Carlos Corbacho <carlos@strangeworlds.co.uk> Signed-off-by:
Matthew Garrett <mjg@redhat.com> Signed-off-by:
-
Sebastian Ott authored
commit dbdf1afc upstream. Put sysfs attributes of ccwgroup devices in an attribute group to ensure that these attributes are actually present when userspace is notified via uevents. Signed-off-by:
Sebastian Ott <sebott@linux.vnet.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Martin Schwidefsky authored
commit e73b7fff upstream. The rcu page table free code uses a couple of bits in the page table pointer passed to tlb_remove_table to discern the different page table types. __tlb_remove_table extracts the type with an incorrect mask which leads to memory leaks. The correct mask is ((FRAG_MASK << 4) | FRAG_MASK). Signed-off-by:
-
Martin Schwidefsky authored
commit a45aff52 upstream. git commit 5e9a2692 "[S390] ptrace cleanup" introduced a regression for the case when both a user PER set (e.g. a storage alteration trace) and PTRACE_SINGLESTEP are active. The new code will overrule the user PER set with a instruction-fetch PER set over the whole address space for ptrace single stepping. The inferior process will be stopped after each instruction with an instruction fetch event. Any other events that may have occurred concurrently are not reported (e.g. storage alteration event) because the control bits for them are not set. The solution is to merge the PER control bits of the user PER set with the PER_EVENT_IFETCH control bit for PTRACE_SINGLESTEP. Signed-off-by:
-
Carsten Otte authored
commit 4d47555a upstream. We use the cpu id provided by userspace as array index here. Thus we clearly need to check it first. Ooops. Signed-off-by:
Carsten Otte <cotte@de.ibm.com> Signed-off-by:
Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by:
-
Susan Gao authored
commit fbc7c62a upstream. Signed-off-by:
Susan Gao <sgao@opensource.wolfsonmicro.com> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmico.com> Signed-off-by:
-
Mark Brown authored
commit 38f3f31a upstream. Also fix return values for speaker switch updates. Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Axel Lin authored
commit 35024f49 upstream. Signed-off-by:
Axel Lin <axel.lin@gmail.com> Acked-by:
Liam Girdwood <lrg@ti.com> Signed-off-by:
-
Axel Lin authored
commit c527e6aa upstream. For wm8994-aif2, the rate_reg should be WM8994_AIF2_RATE. Signed-off-by:
-
Axel Lin authored
commit 3205e662 upstream. Signed-off-by:
-
Axel Lin authored
commit 7c04241a upstream. ak4535_reg should be 8bit, but cache table is defined as 16bit. Signed-off-by:
-
Kuninori Morimoto authored
commit 19b115e5 upstream. ak4642 register was 8bit, but cache table was defined as 16bit. ak4642 doesn't work correctry without this patch. Signed-off-by:
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by:
-
Axel Lin authored
commit 3a340104 upstream. According to the datasheet: Format Control (05h) BITS[3:2] FMT[1:0] Audio data format selection 00 = right justified mode 01 = left justified mode 10 = I2S mode 11 = DSP mode BIT[4] LRP Polarity selec for LRCLK/DSP mode select 0 = normal LRCLK poalrity/DSP mode A 1 = inverted LRCLK poarity/DSP mode B For SND_SOC_DAIFMT_DSP_A, we should set 0x000C instead of 0x0003. For SND_SOC_DAIFMT_DSP_B, we should set 0x001C instead of 0x0013. Signed-off-by:
-
Axel Lin authored
commit 5927f947 upstream. Reported-by:
Chris Paulson-Ellis <chris@edesix.com> Signed-off-by:
-
Daniel Vetter authored
commit 24dd85ff upstream. For the !HAVE_ATOMIC_IOMAP case the stub functions did not call pagefault_disable/_enable. The i915 driver relies on the map actually being atomic, otherwise it can deadlock with it's own pagefault handler in the gtt pwrite fastpath. This is exercised by gem_mmap_gtt from the intel-gpu-toosl gem testsuite. v2: Chris Wilson noted the lack of an include. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38115Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Keith Packard <keithp@keithp.com> Signed-off-by:
-
Bryan Schumaker authored
commit a877ee03 upstream. nfsiostat was failing to find mounted filesystems on kernels after 2.6.38 because of changes to show_vfsstat() by commit c7f404b4. This patch adds back the "device" tag before the nfs server entry so scripts can parse the mountstats file correctly. Signed-off-by:
Bryan Schumaker <bjschuma@netapp.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
J. Bruce Fields authored
commit c30e92df upstream. We don't use WANT bits yet--and sending them can probably trigger a BUG() further down. Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
J. Bruce Fields authored
commit 3d02fa29 upstream. Yet another open-management regression: - nfs4_file_downgrade() doesn't remove the BOTH access bit on downgrade, so the server's idea of the stateid's access gets out of sync with the client's. If we want to keep an O_RDWR open in this case, we should do that in the file_put_access logic rather than here. - We forgot to convert v4 access to an open mode here. This logic has proven too hard to get right. In the future we may consider: - reexamining the lock/openowner relationship (locks probably don't really need to take their own references here). - adding open upgrade/downgrade support to the vfs. - removing the atomic operations. They're redundant as long as this is all under some other lock. Also, maybe some kind of additional static checking would help catch O_/NFS4_SHARE_ACCESS confusion. Signed-off-by:
-
J. Bruce Fields authored
commit a043226b upstream. A client that wants to execute a file must be able to read it. Read opens over nfs are therefore implicitly allowed for executable files even when those files are not readable. NFSv2/v3 get this right by using a passed-in NFSD_MAY_OWNER_OVERRIDE on read requests, but NFSv4 has gotten this wrong ever since dc730e17 "nfsd4: fix owner-override on open", when we realized that the file owner shouldn't override permissions on non-reclaim NFSv4 opens. So we can't use NFSD_MAY_OWNER_OVERRIDE to tell nfsd_permission to allow reads of executable files. So, do the same thing we do whenever we encounter another weird NFS permission nit: define yet another NFSD_MAY_* flag. The industry's future standardization on 128-bit processors will be motivated primarily by the need for integers with enough bits for all the NFSD_MAY_* flags. Reported-by:
Leonardo Borda <leonardoborda@gmail.com> Signed-off-by:
-
J. Bruce Fields authored
commit 57616300 upstream. The set of errors here does *not* agree with the set of errors specified in the rfc! While we're there, turn this macros into a function, for the usual reasons, and move it to the one place where it's actually used. Signed-off-by:
-
J. Bruce Fields authored
commit 3e772463 upstream. The server is returning nfserr_resource for both permanent errors and for errors (like allocation failures) that might be resolved by retrying later. Save nfserr_resource for the former and use delay/jukebox for the latter. Signed-off-by:
-
Bernd Schubert authored
commit 832023bf upstream. Fan Yong <yong.fan@whamcloud.com> noticed setting FMODE_32bithash wouldn't work with nfsd v4, as nfsd4_readdir() checks for 32 bit cookies. However, according to RFC 3530 cookies have a 64 bit type and cookies are also defined as u64 in 'struct nfsd4_readdir'. So remove the test for >32-bit values. Signed-off-by:
Bernd Schubert <bernd.schubert@itwm.fraunhofer.de> Signed-off-by:
-
Jeff Layton authored
commit 2da95652 upstream. nfs_find_and_lock_request will take a reference to the nfs_page and will then put it if the req is already locked. It's possible though that the reference will be the last one. That put then can kick off a whole series of reference puts: nfs_page nfs_open_context dentry inode If the inode ends up being deleted, then the VFS will call truncate_inode_pages. That function will try to take the page lock, but it was already locked when migrate_page was called. The code deadlocks. Fix this by simply refusing the migration request if PagePrivate is already set, indicating that the page is already associated with an active read or write request. We've had a customer test a backported version of this patch and the preliminary results seem good. Cc: Andrea Arcangeli <aarcange@redhat.com> Reported-by:
Harshula Jayasuriya <harshula@redhat.com> Signed-off-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Ian Campbell authored
commit 9bab0b7f upstream. This adds a mechanism to resume selected IRQs during syscore_resume instead of dpm_resume_noirq. Under Xen we need to resume IRQs associated with IPIs early enough that the resched IPI is unmasked and we can therefore schedule ourselves out of the stop_machine where the suspend/resume takes place. This issue was introduced by 676dc3cf "xen: Use IRQF_FORCE_RESUME". Signed-off-by:
Ian Campbell <ian.campbell@citrix.com> Cc: Rafael J. Wysocki <rjw@sisk.pl> Cc: Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com> Cc: xen-devel <xen-devel@lists.xensource.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Link: http://lkml.kernel.org/r/1318713254.11016.52.camel@dagon.hellion.org.ukSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Steven Rostedt authored
commit 436fc280 upstream. The trace_pipe_raw handler holds a cached page from the time the file is opened to the time it is closed. The cached page is used to handle the case of the user space buffer being smaller than what was read from the ring buffer. The left over buffer is held in the cache so that the next read will continue where the data left off. After EOF is returned (no more data in the buffer), the index of the cached page is set to zero. If a user app reads the page again after EOF, the check in the buffer will see that the cached page is less than page size and will return the cached page again. This will cause reading the trace_pipe_raw again after EOF to return duplicate data, making the output look like the time went backwards but instead data is just repeated. The fix is to not reset the index right after all data is read from the cache, but to reset it after all data is read and more data exists in the ring buffer. Reported-by:
Jeremy Eder <jeder@redhat.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Masami Hiramatsu authored
commit 02ca1521 upstream. Fix kprobe-tracer not to delete a probe if the probe is in use. In that case, delete operation will return -EBUSY. This bug can cause a kernel panic if enabled probes are deleted during perf record. (Add some probes on functions) sh-4.2# perf probe --del probe:\* sh-4.2# exit (kernel panic) This is originally reported on the fedora bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=742383 I've also checked that this problem doesn't happen on tracepoints when module removing because perf event locks target module. $ sudo ./perf record -e xfs:\* -aR sh sh-4.2# rmmod xfs ERROR: Module xfs is in use sh-4.2# exit [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.203 MB perf.data (~8862 samples) ] Signed-off-by:
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Frank Ch. Eigler <fche@redhat.com> Link: http://lkml.kernel.org/r/20111004104438.14591.6553.stgit@fedora15Signed-off-by:
-
Masami Hiramatsu authored
commit 44a56040 upstream. Fix perf probe to show correct error string when it fails to delete an event. The write(2) returns -1 if failed, and errno stores real error number. Signed-off-by:
-
NeilBrown authored
commit 355840e7 upstream. This bug was introduced in 415e72d0 which was in 2.6.36. There is a small window of time between when a device fails and when it is removed from the array. During this time we might still read from it, but we won't write to it - so it is possible that we could read stale data. We didn't need the test of 'Faulty' before because the test on In_sync is sufficient. Since we started allowing reads from the early part of non-In_sync devices we need a test on Faulty too. This is suitable for any kernel from 2.6.36 onwards, though the patch might need a bit of tweaking in 3.0 and earlier. Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
Jan Beulich authored
commit 838312be upstream. These warnings (generally one per CPU) are a result of initializing x86_cpu_to_logical_apicid while apic_default is still in use, but the check in setup_local_APIC() being done when apic_bigsmp was already used as an override in default_setup_apic_routing(): Overriding APIC driver with bigsmp Enabling APIC mode: Physflat. Using 5 I/O APICs ------------[ cut here ]------------ WARNING: at .../arch/x86/kernel/apic/apic.c:1239 ... CPU 1 irqstacks, hard=f1c9a000 soft=f1c9c000 Booting Node 0, Processors #1 smpboot cpu 1: start_ip = 9e000 Initializing CPU#1 ------------[ cut here ]------------ WARNING: at .../arch/x86/kernel/apic/apic.c:1239 setup_local_APIC+0x137/0x46b() Hardware name: ... CPU1 logical APIC ID: 2 != 8 ... Fix this (for the time being, i.e. until x86_32_early_logical_apicid() will get removed again, as Tejun says ought to be possible) by overriding the previously stored values at the point where the APIC driver gets overridden. v2: Move this and the pre-existing override logic into arch/x86/kernel/apic/bigsmp_32.c. Signed-off-by:
Jan Beulich <jbeulich@suse.com> Acked-by:
Tejun Heo <tj@kernel.org> Link: http://lkml.kernel.org/r/4E835D16020000780005844C@nat28.tlf.novell.comSigned-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
hank authored
commit cbbc719f upstream. The parameter's origin type is long. On an i386 architecture, it can easily be larger than 0x80000000, causing this function to convert it to a sign-extended u64 type. Change the type to unsigned long so we get the correct result. Signed-off-by:
hank <pyu@redhat.com> Cc: John Stultz <john.stultz@linaro.org> [ build fix ] Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Stanislaw Gruszka authored
commit 107ef97a upstream. This fix regression introduced by commit: commit 15b3f3b0 Author: Wey-Yi Guy <wey-yi.w.guy@intel.com> Date: Fri Jun 3 07:54:13 2011 -0700 iwlagn: set smps mode after assoc for 1000 device Also remove unneeded brackets on the way. Address: https://bugzilla.redhat.com/show_bug.cgi?id=744155Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Acked-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Luciano Coelho authored
commit 6cd9d21a upstream. We were using incorrect max and min dwell times during forced passive scans because we were still using the active scan states to scan (passively) the channels that were not marked as passive. Instead of doing passive scans in active states, we now skip active states and scan for all channels in passive states. Signed-off-by:
Luciano Coelho <coelho@ti.com> Signed-off-by:
-
Richard Cochran authored
commit da92b194 upstream. The pair of functions, * skb_clone_tx_timestamp() * skb_complete_tx_timestamp() were designed to allow timestamping in PHY devices. The first function, called during the MAC driver's hard_xmit method, identifies PTP protocol packets, clones them, and gives them to the PHY device driver. The PHY driver may hold onto the packet and deliver it at a later time using the second function, which adds the packet to the socket's error queue. As pointed out by Johannes, nothing prevents the socket from disappearing while the cloned packet is sitting in the PHY driver awaiting a timestamp. This patch fixes the issue by taking a reference on the socket for each such packet. In addition, the comments regarding the usage of these function are expanded to highlight the rule that PHY drivers must use skb_complete_tx_timestamp() to release the packet, in order to release the socket reference, too. These functions first appeared in v2.6.36. Reported-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
Richard Cochran <richard.cochran@omicron.at> Signed-off-by:
Eric Dumazet <eric.dumazet@gmail.com> Reviewed-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Johannes Berg authored
commit 28a1bcdb upstream. When I introduced in-kernel off-channel TX I introduced a bug -- the work can't be canceled again because the code clear the skb pointer. Fix this by keeping track separately of whether TX status has already been reported. Reported-by:
Jouni Malinen <j@w1.fi> Tested-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Richard Cochran authored
commit 8b3408f8 upstream. If the PHY should disappear (for example, on an USB Ethernet MAC), then the driver would leak any undelivered time stamp packets. This commit fixes the issue by calling the appropriate functions to free any packets left in the transmit and receive queues. The driver first appeared in v3.0. Signed-off-by:
-
