- 20 Dec, 2013 40 commits
-
-
Greg Kroah-Hartman authored
It turns out that commit: d3f7d56a was applied to the tree twice, which didn't hurt anything, but it's good to fix this up. Reported-by:
Veaceslav Falico <veaceslav@falico.eu> Cc: David S. Miller <davem@davemloft.net> Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: Richard Weinberger <richard@nod.at> Cc: Shawn Landden <shawnlandden@gmail.com> Cc: Tom Herbert <therbert@google.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Nicolas Dichtel authored
The upstream commit bb814094 ("ip6tnl: allow to use rtnl ops on fb tunnel") (backported into linux-3.10.y) left a bug which was fixed upstream by commit 1e9f3d6f ("ip6tnl: fix use after free of fb_tnl_dev"). The problem is a bit different in linux-3.10.y, because there is no x-netns support (upstream commit 0bd87628 ("ip6tnl: add x-netns support")). When ip6_tunnel.ko is unloaded, FB device is deleted by rtnl_link_unregister() and then we try to delete it again in ip6_tnl_destroy_tunnels(). This patch removes the second deletion. Reported-by:
Steven Rostedt <rostedt@goodmis.org> Suggested-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Cc: David Miller <davem@davemloft.net> Signed-off-by:
-
Andy Adamson authored
commit 4a82fd7c upstream. When the state manager is processing the NFS4CLNT_DELEGRETURN flag, session draining is off, but DELEGRETURN can still get a session error. The async handler calls nfs4_schedule_session_recovery returns -EAGAIN, and the DELEGRETURN done then restarts the RPC task in the prepare state. With the state manager still processing the NFS4CLNT_DELEGRETURN flag with session draining off, these DELEGRETURNs will cycle with errors filling up the session slots. This prevents OPEN reclaims (from nfs_delegation_claim_opens) required by the NFS4CLNT_DELEGRETURN state manager processing from completing, hanging the state manager in the __rpc_wait_for_completion_task in nfs4_run_open_task as seen in this kernel thread dump: kernel: 4.12.32.53-ma D 0000000000000000 0 3393 2 0x00000000 kernel: ffff88013995fb60 0000000000000046 ffff880138cc5400 ffff88013a9df140 kernel: ffff8800000265c0 ffffffff8116eef0 ffff88013fc10080 0000000300000001 kernel: ffff88013a4ad058 ffff88013995ffd8 000000000000fbc8 ffff88013a4ad058 kernel: Call Trace: kernel: [<ffffffff8116eef0>] ? cache_alloc_refill+0x1c0/0x240 kernel: [<ffffffffa0358110>] ? rpc_wait_bit_killable+0x0/0xa0 [sunrpc] kernel: [<ffffffffa0358152>] rpc_wait_bit_killable+0x42/0xa0 [sunrpc] kernel: [<ffffffff8152914f>] __wait_on_bit+0x5f/0x90 kernel: [<ffffffffa0358110>] ? rpc_wait_bit_killable+0x0/0xa0 [sunrpc] kernel: [<ffffffff815291f8>] out_of_line_wait_on_bit+0x78/0x90 kernel: [<ffffffff8109b520>] ? wake_bit_function+0x0/0x50 kernel: [<ffffffffa035810d>] __rpc_wait_for_completion_task+0x2d/0x30 [sunrpc] kernel: [<ffffffffa040d44c>] nfs4_run_open_task+0x11c/0x160 [nfs] kernel: [<ffffffffa04114e7>] nfs4_open_recover_helper+0x87/0x120 [nfs] kernel: [<ffffffffa0411646>] nfs4_open_recover+0xc6/0x150 [nfs] kernel: [<ffffffffa040cc6f>] ? nfs4_open_recoverdata_alloc+0x2f/0x60 [nfs] kernel: [<ffffffffa0414e1a>] nfs4_open_delegation_recall+0x6a/0xa0 [nfs] kernel: [<ffffffffa0424020>] nfs_end_delegation_return+0x120/0x2e0 [nfs] kernel: [<ffffffff8109580f>] ? queue_work+0x1f/0x30 kernel: [<ffffffffa0424347>] nfs_client_return_marked_delegations+0xd7/0x110 [nfs] kernel: [<ffffffffa04225d8>] nfs4_run_state_manager+0x548/0x620 [nfs] kernel: [<ffffffffa0422090>] ? nfs4_run_state_manager+0x0/0x620 [nfs] kernel: [<ffffffff8109b0f6>] kthread+0x96/0xa0 kernel: [<ffffffff8100c20a>] child_rip+0xa/0x20 kernel: [<ffffffff8109b060>] ? kthread+0x0/0xa0 kernel: [<ffffffff8100c200>] ? child_rip+0x0/0x20 The state manager can not therefore process the DELEGRETURN session errors. Change the async handler to wait for recovery on session errors. Signed-off-by:
Andy Adamson <andros@netapp.com> Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Alan authored
commit dace8bbf upstream. If loaded with isapnp = 0 the driver explodes. This is catching people out now and then. What should happen in the working case is a complete mystery and the code appears terminally confused, but we can at least make the error path work properly. Signed-off-by:
Alan Cox <alan@linux.intel.com> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Wim Van Sebroeck <wim@iguana.be> Partially-Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=53991Signed-off-by:
-
H Hartley Sweeten authored
commit f6b316bc upstream. Use comedi_dio_update_state() to handle the boilerplate code to update the subdevice s->state. Also, fix a bug where the state of the channels is returned in data[0]. The comedi core expects it to be returned in data[1]. Signed-off-by:
H Hartley Sweeten <hsweeten@visionengravers.com> Reviewed-by:
Ian Abbott <abbotti@mev.co.uk> Signed-off-by:
-
H Hartley Sweeten authored
commit 97f4289a upstream. [Split from original patch subject: "staging: comedi: drivers: use comedi_dio_update_state() for simple cases"] Use comedi_dio_update_state() to handle the boilerplate code to update the subdevice s->state for simple cases where the hardware is updated when any channel is modified. Also, fix a bug in the amplc_pc263 and amplc_pci263 drivers where the current state is not returned in data[1]. Signed-off-by:
-
Ian Abbott authored
commit 2fd2bdfc upstream. pcmuio_detach() is called by the comedi core even if pcmuio_attach() returned an error, so `dev->private` might be `NULL`. Check for that before dereferencing it. Also, as pointed out by Dan Carpenter, there is no need to check the pointer passed to `kfree()` is non-NULL, so remove that check. Signed-off-by:
-
Ben Segall authored
commit f9f9ffc2 upstream. throttle_cfs_rq() doesn't check to make sure that period_timer is running, and while update_curr/assign_cfs_runtime does, a concurrently running period_timer on another cpu could cancel itself between this cpu's update_curr and throttle_cfs_rq(). If there are no other cfs_rqs running in the tg to restart the timer, this causes the cfs_rq to be stranded forever. Fix this by calling __start_cfs_bandwidth() in throttle if the timer is inactive. (Also add some sched_debug lines for cfs_bandwidth.) Tested: make a run/sleep task in a cgroup, loop switching the cgroup between 1ms/100ms quota and unlimited, checking for timer_active=0 and throttled=1 as a failure. With the throttle_cfs_rq() change commented out this fails, with the full patch it passes. Signed-off-by:
Ben Segall <bsegall@google.com> Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Cc: pjt@google.com Link: http://lkml.kernel.org/r/20131016181632.22647.84174.stgit@sword-of-the-dawn.mtv.corp.google.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Cc: Chris J Arges <chris.j.arges@canonical.com> Signed-off-by:
-
Hans Verkuil authored
commit 0db3fa27 upstream. drivers/media/dvb-frontends/cxd2820r_core.c:34:32: error: cannot size expression drivers/media/dvb-frontends/cxd2820r_core.c:68:32: error: cannot size expression Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Acked-by:
Antti Palosaari <crope@iki.fi> Reviewed-by:
Michael Krufky <mkrufky@linuxtv.org> Signed-off-by:
Mauro Carvalho Chehab <m.chehab@samsung.com> Cc: Frederik Himpe <fhimpe@telenet.be> Signed-off-by:
-
Helge Deller authored
commit 3873d064 upstream. When compiling a 32bit kernel with CONFIG_LBDAF=n the compiler complains like shown below. Fix this warning by instead using sector_div() which is provided by the kernel.h header file. fs/nfs/blocklayout/extents.c: In function ‘normalize’: include/asm-generic/div64.h:43:28: warning: comparison of distinct pointer types lacks a cast [enabled by default] fs/nfs/blocklayout/extents.c:47:13: note: in expansion of macro ‘do_div’ nfs/blocklayout/extents.c:47:2: warning: right shift count >= width of type [enabled by default] fs/nfs/blocklayout/extents.c:47:2: warning: passing argument 1 of ‘__div64_32’ from incompatible pointer type [enabled by default] include/asm-generic/div64.h:35:17: note: expected ‘uint64_t *’ but argument is of type ‘sector_t *’ extern uint32_t __div64_32(uint64_t *dividend, uint32_t divisor); Signed-off-by:
Helge Deller <deller@gmx.de> Signed-off-by:
-
Joe Thornber authored
commit fafc7a81 upstream. Switch the thin pool to read-only mode when dm_thin_insert_block() fails since there is little reason to expect the cause of the failure to be resolved without further action by user space. This issue was noticed with the device-mapper-test-suite using: dmtest run --suite thin-provisioning -n /exhausting_metadata_space_causes_fail_mode/ The quantity of errors logged in this case must be reduced. before patch: device-mapper: thin: dm_thin_insert_block() failed device-mapper: space map metadata: unable to allocate new metadata block device-mapper: thin: dm_thin_insert_block() failed device-mapper: space map metadata: unable to allocate new metadata block device-mapper: thin: dm_thin_insert_block() failed device-mapper: space map metadata: unable to allocate new metadata block device-mapper: thin: dm_thin_insert_block() failed device-mapper: space map metadata: unable to allocate new metadata block device-mapper: thin: dm_thin_insert_block() failed device-mapper: space map metadata: unable to allocate new metadata block device-mapper: thin: dm_thin_insert_block() failed device-mapper: space map metadata: unable to allocate new metadata block device-mapper: thin: dm_thin_insert_block() failed device-mapper: space map metadata: unable to allocate new metadata block device-mapper: thin: dm_thin_insert_block() failed device-mapper: space map metadata: unable to allocate new metadata block device-mapper: thin: dm_thin_insert_block() failed device-mapper: space map metadata: unable to allocate new metadata block device-mapper: thin: dm_thin_insert_block() failed device-mapper: space map metadata: unable to allocate new metadata block device-mapper: space map metadata: unable to allocate new metadata block device-mapper: space map metadata: unable to allocate new metadata block device-mapper: space map metadata: unable to allocate new metadata block device-mapper: space map metadata: unable to allocate new metadata block device-mapper: space map metadata: unable to allocate new metadata block <snip ... these repeat for a long while ... > device-mapper: space map metadata: unable to allocate new metadata block device-mapper: space map common: dm_tm_shadow_block() failed device-mapper: thin: 253:4: no free metadata space available. device-mapper: thin: 253:4: switching pool to read-only mode after patch: device-mapper: space map metadata: unable to allocate new metadata block device-mapper: thin: 253:4: dm_thin_insert_block() failed: error = -28 device-mapper: thin: 253:4: switching pool to read-only mode Signed-off-by:
Joe Thornber <ejt@redhat.com> Signed-off-by:
Mike Snitzer <snitzer@redhat.com> Signed-off-by:
-
Mikulas Patocka authored
commit 5b2d0657 upstream. The dm_round_up function may overflow to zero. In this case, dm_table_create() must fail rather than go on to allocate an empty array with alloc_targets(). This fixes a possible memory corruption that could be caused by passing too large a number in "param->target_count". Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Signed-off-by:
-
Mike Snitzer authored
commit f62b6b8f upstream. Commit 2fc48021 ("dm persistent metadata: add space map threshold callback") introduced a regression to the metadata block allocation path that resulted in errors being ignored. This regression was uncovered by running the following device-mapper-test-suite test: dmtest run --suite thin-provisioning -n /exhausting_metadata_space_causes_fail_mode/ The ignored error codes in sm_metadata_new_block() could crash the kernel through use of either the dm-thin or dm-cache targets, e.g.: device-mapper: thin: 253:4: reached low water mark for metadata device: sending event. device-mapper: space map metadata: unable to allocate new metadata block general protection fault: 0000 [#1] SMP ... Workqueue: dm-thin do_worker [dm_thin_pool] task: ffff880035ce2ab0 ti: ffff88021a054000 task.ti: ffff88021a054000 RIP: 0010:[<ffffffffa0331385>] [<ffffffffa0331385>] metadata_ll_load_ie+0x15/0x30 [dm_persistent_data] RSP: 0018:ffff88021a055a68 EFLAGS: 00010202 RAX: 003fc8243d212ba0 RBX: ffff88021a780070 RCX: ffff88021a055a78 RDX: ffff88021a055a78 RSI: 0040402222a92a80 RDI: ffff88021a780070 RBP: ffff88021a055a68 R08: ffff88021a055ba4 R09: 0000000000000010 R10: 0000000000000000 R11: 00000002a02e1000 R12: ffff88021a055ad4 R13: 0000000000000598 R14: ffffffffa0338470 R15: ffff88021a055ba4 FS: 0000000000000000(0000) GS:ffff88033fca0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00007f467c0291b8 CR3: 0000000001a0b000 CR4: 00000000000007e0 Stack: ffff88021a055ab8 ffffffffa0332020 ffff88021a055b30 0000000000000001 ffff88021a055b30 0000000000000000 ffff88021a055b18 0000000000000000 ffff88021a055ba4 ffff88021a055b98 ffff88021a055ae8 ffffffffa033304c Call Trace: [<ffffffffa0332020>] sm_ll_lookup_bitmap+0x40/0xa0 [dm_persistent_data] [<ffffffffa033304c>] sm_metadata_count_is_more_than_one+0x8c/0xc0 [dm_persistent_data] [<ffffffffa0333825>] dm_tm_shadow_block+0x65/0x110 [dm_persistent_data] [<ffffffffa0331b00>] sm_ll_mutate+0x80/0x300 [dm_persistent_data] [<ffffffffa0330e60>] ? set_ref_count+0x10/0x10 [dm_persistent_data] [<ffffffffa0331dba>] sm_ll_inc+0x1a/0x20 [dm_persistent_data] [<ffffffffa0332270>] sm_disk_new_block+0x60/0x80 [dm_persistent_data] [<ffffffff81520036>] ? down_write+0x16/0x40 [<ffffffffa001e5c4>] dm_pool_alloc_data_block+0x54/0x80 [dm_thin_pool] [<ffffffffa001b23c>] alloc_data_block+0x9c/0x130 [dm_thin_pool] [<ffffffffa001c27e>] provision_block+0x4e/0x180 [dm_thin_pool] [<ffffffffa001fe9a>] ? dm_thin_find_block+0x6a/0x110 [dm_thin_pool] [<ffffffffa001c57a>] process_bio+0x1ca/0x1f0 [dm_thin_pool] [<ffffffff8111e2ed>] ? mempool_free+0x8d/0xa0 [<ffffffffa001d755>] process_deferred_bios+0xc5/0x230 [dm_thin_pool] [<ffffffffa001d911>] do_worker+0x51/0x60 [dm_thin_pool] [<ffffffff81067872>] process_one_work+0x182/0x3b0 [<ffffffff81068c90>] worker_thread+0x120/0x3a0 [<ffffffff81068b70>] ? manage_workers+0x160/0x160 [<ffffffff8106eb2e>] kthread+0xce/0xe0 [<ffffffff8106ea60>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8152af6c>] ret_from_fork+0x7c/0xb0 [<ffffffff8106ea60>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff8152af6c>] ret_from_fork+0x7c/0xb0 [<ffffffff8106ea60>] ? kthread_freezable_should_stop+0x70/0x70 Signed-off-by:
-
Mikulas Patocka authored
commit 718822c1 upstream. The dm-delay target uses a shared workqueue for multiple instances. This can cause deadlock if two or more dm-delay targets are stacked on the top of each other. This patch changes dm-delay to use a per-instance workqueue. Signed-off-by:
-
Joe Thornber authored
commit ed9571f0 upstream. An old array block could have its reference count decremented below zero when it is being replaced in the btree by a new array block. The fix is to increment the old ablock's reference count just before inserting a new ablock into the btree. Signed-off-by:
-
Mikulas Patocka authored
commit 230c83af upstream. There is a possible leak of snapshot space in case of crash. The reason for space leaking is that chunks in the snapshot device are allocated sequentially, but they are finished (and stored in the metadata) out of order, depending on the order in which copying finished. For example, supposed that the metadata contains the following records SUPERBLOCK METADATA (blocks 0 ... 250) DATA 0 DATA 1 DATA 2 ... DATA 250 Now suppose that you allocate 10 new data blocks 251-260. Suppose that copying of these blocks finish out of order (block 260 finished first and the block 251 finished last). Now, the snapshot device looks like this: SUPERBLOCK METADATA (blocks 0 ... 250, 260, 259, 258, 257, 256) DATA 0 DATA 1 DATA 2 ... DATA 250 DATA 251 DATA 252 DATA 253 DATA 254 DATA 255 METADATA (blocks 255, 254, 253, 252, 251) DATA 256 DATA 257 DATA 258 DATA 259 DATA 260 Now, if the machine crashes after writing the first metadata block but before writing the second metadata block, the space for areas DATA 250-255 is leaked, it contains no valid data and it will never be used in the future. This patch makes dm-snapshot complete exceptions in the same order they were allocated, thus fixing this bug. Note: when backporting this patch to the stable kernel, change the version field in the following way: * if version in the stable kernel is {1, 11, 1}, change it to {1, 12, 0} * if version in the stable kernel is {1, 10, 0} or {1, 10, 1}, change it to {1, 10, 2} Userspace reads the version to determine if the bug was fixed, so the version change is needed. Signed-off-by:
-
Mikulas Patocka authored
commit 4cb57ab4 upstream. Some module parameters in dm-bufio are read-only. These parameters inform the user about memory consumption. They are not supposed to be changed by the user. However, despite being read-only, these parameters can be set on modprobe or insmod command line, for example: modprobe dm-bufio current_allocated_bytes=12345 The kernel doesn't expect that these variables can be non-zero at module initialization and if the user sets them, it results in BUG. This patch initializes the variables in the module init routine, so that user-supplied values are ignored. Signed-off-by:
-
David Sterba authored
commit e43f998e upstream. If btrfs_ioctl_snap_destroy blocks on the mutex and the process is killed, mnt_write count is unbalanced and leads to unmountable filesystem. Signed-off-by:
David Sterba <dsterba@suse.cz> Signed-off-by:
Chris Mason <clm@fb.com> Signed-off-by:
-
Dan Carpenter authored
commit 700ff4f0 upstream. The closing parenthesis is in the wrong place. We want to check "sizeof(*arg->clone_sources) * arg->clone_sources_count" instead of "sizeof(*arg->clone_sources * arg->clone_sources_count)". Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Jie Liu <jeff.liu@oracle.com> Signed-off-by:
-
Dan Carpenter authored
commit 3189ef02 upstream. We introduced a couple new error paths which are missing unlocks. Fixes: 7760e148 ('[media] af9035: Don't use dynamic static allocation') Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by:
-
Antti Palosaari authored
commit 0c413d10 upstream. It is IT9135 dual design. Thanks to Michael Piko for reporting that! Reported-by:
Michael Piko <michael@piko.com.au> Signed-off-by:
-
Hans Verkuil authored
commit 3af41a33 upstream. Commit 5aa9ae5e inverted the mute control state test in s_routing which caused the audio routing to fail. This broke ivtv support for the Hauppauge video/audio input bracket (which adds additional video and audio inputs) all the way back in kernel 2.6.36. This fix fixes the condition and it also removes a nonsense check on the balance control. Bisected-by:
Rajil Saraswat <rajil.s@gmail.com> Signed-off-by:
Andy Walls <awalls@md.metrocast.net> Reported-by:
-
Antti Palosaari authored
commit d18a88b1 upstream. Driver did not work anymore since I2C has gone broken due to recent commit: commit 37ebaf68 [media] dvb-frontends: Don't use dynamic static allocation Signed-off-by:
-
Hans Verkuil authored
commit f8e1b699 upstream. The no_video flag was checked in all other cases except one. Calling v4l2_ctrl_handler_setup() if no_video is 1 will crash. This wasn't noticed before since there are only two card types that set no_video to 1, so this type of hardware is quite rare. Signed-off-by:
Lorenz Röhrl <sheepshit@gmx.de> Tested-by:
-
Wei Yongjun authored
commit 89f4d45b upstream. In case of error, the function kthread_run() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Signed-off-by:
Wei Yongjun <yongjun_wei@trendmicro.com.cn> Signed-off-by:
-
H. Peter Anvin authored
commit 503cf95c upstream. When compiling with icc, <linux/compiler-gcc.h> ends up included because the icc environment defines __GNUC__. Thus, we neither need nor want to have this macro defined in both compiler-gcc.h and compiler-intel.h, and the fact that they are inconsistent just makes the compiler spew warnings. Reported-by:
Sunil K. Pandey <sunil.k.pandey@intel.com> Cc: Kevin B. Smith <kevin.b.smith@intel.com> Signed-off-by:
H. Peter Anvin <hpa@linux.intel.com> Link: http://lkml.kernel.org/n/tip-0mbwou1zt7pafij09b897lg3@git.kernel.orgSigned-off-by:
-
H. Peter Anvin authored
commit 8b3b005d upstream. In checkin 5551a34e x86-64, build: Always pass in -mno-sse we unconditionally added -mno-sse to the main build, to keep newer compilers from generating SSE instructions from autovectorization. However, this did not extend to the special environments (arch/x86/boot, arch/x86/boot/compressed, and arch/x86/realmode/rm). Add -mno-sse to the compiler command line for these environments, and add -mno-mmx to all the environments as well, as we don't want a compiler to generate MMX code either. This patch also removes a $(cc-option) call for -m32, since we have long since stopped supporting compilers too old for the -m32 option, and in fact hardcode it in other places in the Makefiles. Reported-by:
Kevin B. Smith <kevin.b.smith@intel.com> Cc: Sunil K. Pandey <sunil.k.pandey@intel.com> Signed-off-by:
-
Matthew Garrett authored
commit 04bf9ba7 upstream. UEFI time services are often broken once we're in virtual mode. We were already refusing to use them on 64-bit systems, but it turns out that they're also broken on some 32-bit firmware, including the Dell Venue. Disable them for now, we can revisit once we have the 1:1 mappings code incorporated. Signed-off-by:
Matthew Garrett <matthew.garrett@nebula.com> Link: http://lkml.kernel.org/r/1385754283-2464-1-git-send-email-matthew.garrett@nebula.com Cc: Matt Fleming <matt.fleming@intel.com> Signed-off-by:
-
Alex Deucher authored
commit 0ca223b0 upstream. Some boards seem to have garbage in the upper 16 bits of the vram size register. Check for this and clamp the size properly. Fixes boards reporting bogus amounts of vram. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Alex Deucher authored
commit 55d4e020 upstream. Seems to work like the DCE3 version despite what the register spec says. bug: https://bugs.freedesktop.org/show_bug.cgi?id=71975Signed-off-by:
-
Carolyn Wyborny authored
commit df29df92 upstream. This patch changes the igb_phy_has_link function to check the value of the parameter before deciding to use udelay or mdelay in order to be sure that the value is not too high for udelay function. Signed-off-by:
Carolyn Wyborny <carolyn.wyborny@intel.com> Tested-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Ujjal Roy authored
commit 517543fd upstream. For IBSS join if the requested SSID matches current SSID, it returns without freeing the allocated beacon IE buffer. Signed-off-by:
Ujjal Roy <royujjal@gmail.com> Signed-off-by:
Bing Zhao <bzhao@marvell.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Johannes Berg authored
commit 60765a47 upstream. The station ID must be valid, if it's out of range then the array access may crash. Validate the station ID to the array length, and also validate the drain value even if that doesn't matter all that much. Fixes: 8ca151b5 ("iwlwifi: add the MVM driver") Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
-
Johannes Berg authored
commit 051a41fa upstream. Multicast frames can't be transmitted as part of an aggregation session (such a session couldn't even be set up) so don't try to reorder them. Trying to do so would cause the reorder to stop working correctly since multicast QoS frames (as transmitted by the Aruba APs this was found with) would cause sequence number confusion in the buffer. Reported-by:
Blaise Gassend <blaise@suitabletech.com> Signed-off-by:
-
Bob Copeland authored
commit 2d3db210 upstream. This reverts commit ee1f6681. The aformentioned commit added a check to allow 'iw wlan0 set power_save off' to work for mesh interfaces. However, this is problematic because it also allows 'iw wlan0 set power_save on', which will crash in short order because all of the subsequent code manipulates sdata->u.mgd. The power-saving states for mesh interfaces can be manipulated through the mesh config, e.g: 'iw wlan0 set mesh_param mesh_power_save=active' (which, despite the name, actualy disables power saving since the setting refers to the type of sleep the interface undergoes). Fixes: ee1f6681 ("mac80211: allow disable power save in mesh") Signed-off-by:
Bob Copeland <me@bobcopeland.com> Signed-off-by:
-
Paul Moore authored
commit 446b8024 upstream. In selinux_ip_postroute() we perform access checks based on the packet's security label. For locally generated traffic we get the packet's security label from the associated socket; this works in all cases except for TCP SYN-ACK packets. In the case of SYN-ACK packet's the correct security label is stored in the connection's request_sock, not the server's socket. Unfortunately, at the point in time when selinux_ip_postroute() is called we can't query the request_sock directly, we need to recreate the label using the same logic that originally labeled the associated request_sock. See the inline comments for more explanation. Reported-by:
Janak Desai <Janak.Desai@gtri.gatech.edu> Tested-by:
Paul Moore <pmoore@redhat.com> Signed-off-by:
-
Paul Moore authored
commit 47180068 upstream. In selinux_ip_output() we always label packets based on the parent socket. While this approach works in almost all cases, it doesn't work in the case of TCP SYN-ACK packets when the correct label is not the label of the parent socket, but rather the label of the larval socket represented by the request_sock struct. Unfortunately, since the request_sock isn't queued on the parent socket until *after* the SYN-ACK packet is sent, we can't lookup the request_sock to determine the correct label for the packet; at this point in time the best we can do is simply pass/NF_ACCEPT the packet. It must be said that simply passing the packet without any explicit labeling action, while far from ideal, is not terrible as the SYN-ACK packet will inherit any IP option based labeling from the initial connection request so the label *should* be correct and all our access controls remain in place so we shouldn't have to worry about information leaks. Reported-by:
-
Sujith Manoharan authored
commit a1783a7b upstream. The EEPROM parameter to determine whether the bias strength values for XLNA have to be applied is part of the miscConfiguration field and not featureEnable. Signed-off-by:
Sujith Manoharan <c_manoha@qca.qualcomm.com> Signed-off-by:
-
Sujith Manoharan authored
commit 93c1cfbe upstream. Bit 5 in the miscConfiguration field of the base EEPROM header denotes whether QuickDrop is enabled or not. Fix the incorrect usage of BIT(1) and also make sure that this is done only for the required chips. Signed-off-by:
-
Ville Syrjälä authored
commit 32cf0cb0 upstream. We were miscalculating the pipe CSC post offset for the full->limited range conversion. The resulting post offset was double what it was supposed to be, which caused blacks to come out grey when using limited range output on HSW+. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71769Tested-by:
Lauri Mylläri <lauri.myllari@gmail.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
