- 03 Apr, 2014 17 commits
-
-
Jeff Layton authored
commit 4db72b40 upstream. If the setting of NFS_INO_INVALIDATING gets reordered to before the clearing of NFS_INO_INVALID_DATA, then another task may hit a race window where both appear to be clear, even though the inode's pages are still in need of invalidation. Fix this by adding the appropriate memory barriers. Signed-off-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Trond Myklebust authored
commit 17dfeb91 upstream. Commit d529ef83 (NFS: fix the handling of NFS_INO_INVALID_DATA flag in nfs_revalidate_mapping) introduces a potential race, since it doesn't test the value of nfsi->cache_validity and set the bitlock in nfsi->flags atomically. Signed-off-by:
-
Jeff Layton authored
commit d529ef83 upstream. There is a possible race in how the nfs_invalidate_mapping function is handled. Currently, we go and invalidate the pages in the file and then clear NFS_INO_INVALID_DATA. The problem is that it's possible for a stale page to creep into the mapping after the page was invalidated (i.e., via readahead). If another writer comes along and sets the flag after that happens but before invalidate_inode_pages2 returns then we could clear the flag without the cache having been properly invalidated. So, we must clear the flag first and then invalidate the pages. Doing this however, opens another race: It's possible to have two concurrent read() calls that end up in nfs_revalidate_mapping at the same time. The first one clears the NFS_INO_INVALID_DATA flag and then goes to call nfs_invalidate_mapping. Just before calling that though, the other task races in, checks the flag and finds it cleared. At that point, it trusts that the mapping is good and gets the lock on the page, allowing the read() to be satisfied from the cache even though the data is no longer valid. These effects are easily manifested by running diotest3 from the LTP test suite on NFS. That program does a series of DIO writes and buffered reads. The operations are serialized and page-aligned but the existing code fails the test since it occasionally allows a read to come out of the cache incorrectly. While mixing direct and buffered I/O isn't recommended, I believe it's possible to hit this in other ways that just use buffered I/O, though that situation is much harder to reproduce. The problem is that the checking/clearing of that flag and the invalidation of the mapping really need to be atomic. Fix this by serializing concurrent invalidations with a bitlock. At the same time, we also need to allow other places that check NFS_INO_INVALID_DATA to check whether we might be in the middle of invalidating the file, so fix up a couple of places that do that to look for the new NFS_INO_INVALIDATING flag. Doing this requires us to be careful not to set the bitlock unnecessarily, so this code only does that if it believes it will be doing an invalidation. Signed-off-by:
-
Weston Andros Adamson authored
commit 471252cd upstream. cond_resched_lock(cinfo->lock) is called everywhere else while holding the cinfo->lock spinlock. Not holding this lock while calling transfer_commit_list in filelayout_recover_commit_reqs causes the BUG below. It's true that we can't hold this lock while calling pnfs_put_lseg, because that might try to lock the inode lock - which might be the same lock as cinfo->lock. To reproduce, mount a 2 DS pynfs server and run an O_DIRECT command that crosses a stripe boundary and is not page aligned, such as: dd if=/dev/zero of=/mnt/f bs=17000 count=1 oflag=direct BUG: sleeping function called from invalid context at linux/fs/nfs/nfs4filelayout.c:1161 in_atomic(): 0, irqs_disabled(): 0, pid: 27, name: kworker/0:1 2 locks held by kworker/0:1/27: #0: (events){.+.+.+}, at: [<ffffffff810501d7>] process_one_work+0x175/0x3a5 #1: ((&dreq->work)){+.+...}, at: [<ffffffff810501d7>] process_one_work+0x175/0x3a5 CPU: 0 PID: 27 Comm: kworker/0:1 Not tainted 3.13.0-rc3-branch-dros_testing+ #21 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013 Workqueue: events nfs_direct_write_schedule_work [nfs] 0000000000000000 ffff88007a39bbb8 ffffffff81491256 ffff88007b87a130 ffff88007a39bbd8 ffffffff8105f103 ffff880079614000 ffff880079617d40 ffff88007a39bc20 ffffffffa011603e ffff880078988b98 0000000000000000 Call Trace: [<ffffffff81491256>] dump_stack+0x4d/0x66 [<ffffffff8105f103>] __might_sleep+0x100/0x105 [<ffffffffa011603e>] transfer_commit_list+0x94/0xf1 [nfs_layout_nfsv41_files] [<ffffffffa01160d6>] filelayout_recover_commit_reqs+0x3b/0x68 [nfs_layout_nfsv41_files] [<ffffffffa00ba53a>] nfs_direct_write_reschedule+0x9f/0x1d6 [nfs] [<ffffffff810705df>] ? mark_lock+0x1df/0x224 [<ffffffff8106e617>] ? trace_hardirqs_off_caller+0x37/0xa4 [<ffffffff8106e691>] ? trace_hardirqs_off+0xd/0xf [<ffffffffa00ba8f8>] nfs_direct_write_schedule_work+0x9d/0xb7 [nfs] [<ffffffff810501d7>] ? process_one_work+0x175/0x3a5 [<ffffffff81050258>] process_one_work+0x1f6/0x3a5 [<ffffffff810501d7>] ? process_one_work+0x175/0x3a5 [<ffffffff8105187e>] worker_thread+0x149/0x1f5 [<ffffffff81051735>] ? rescuer_thread+0x28d/0x28d [<ffffffff81056d74>] kthread+0xd2/0xda [<ffffffff81056ca2>] ? __kthread_parkme+0x61/0x61 [<ffffffff8149e66c>] ret_from_fork+0x7c/0xb0 [<ffffffff81056ca2>] ? __kthread_parkme+0x61/0x61 Signed-off-by:
Weston Andros Adamson <dros@primarydata.com> Signed-off-by:
-
Christoph Hellwig authored
commit 1f90ee27 upstream. i_dio_count is used to protect dio access against truncate. We want to make sure there are no dio reads pending either when doing a truncate. I suspect on plain NFS things might work even without this, but once we use a pnfs layout driver that access backing devices directly things will go bad without the proper synchronization. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Christoph Hellwig authored
commit 2a009ec9 upstream. We need to have the I/O fully finished before telling the truncate code that we are done. Signed-off-by:
-
Christoph Hellwig authored
commit 9811cd57 upstream. nfs_file_direct_write only updates the inode size if it succeeded and returned the number of bytes written. But in the AIO case nfs_direct_wait turns the return value into -EIOCBQUEUED and we skip the size update. Instead the aio completion path should updated it, which this patch does. The implementation is a little hacky because there is no obvious way to find out we are called for a write in nfs_direct_complete. Signed-off-by:
-
Alexander Aring authored
commit a8c22754 upstream. The correct way to check on IPV6_ADDR_SCOPE_LINKLOCAL is to check with the ipv6_addr_src_scope function. Currently this can't be work, because ipv6_addr_scope returns a int with a mask of IPV6_ADDR_SCOPE_MASK (0x00f0U) and IPV6_ADDR_SCOPE_LINKLOCAL is 0x02. So the condition is always false. Signed-off-by:
Alexander Aring <alex.aring@gmail.com> Signed-off-by:
-
Trond Myklebust authored
commit f22e5edd upstream. Andy Adamson reports: The state manager is recovering expired state and recovery OPENs are being processed. If kswapd is pruning inodes at the same time, a deadlock can occur when kswapd calls evict_inode on an NFSv4.1 inode with a layout, and the resultant layoutreturn gets an error that the state mangager is to handle, causing the layoutreturn to wait on the (NFS client) cl_rpcwaitq. At the same time an open is waiting for the inode deletion to complete in __wait_on_freeing_inode. If the open is either the open called by the state manager, or an open from the same open owner that is holding the NFSv4 sequence id which causes the OPEN from the state manager to wait for the sequence id on the Seqid_waitqueue, then the state is deadlocked with kswapd. The fix is simply to have layoutreturn ignore all errors except NFS4ERR_DELAY. We already know that layouts are dropped on all server reboots, and that it has to be coded to deal with the "forgetful client model" that doesn't send layoutreturns. Reported-by:
Andy Adamson <andros@netapp.com> Link: http://lkml.kernel.org/r/1385402270-14284-1-git-send-email-andros@netapp.comSigned-off-by:
-
Andy Adamson authored
commit c297c8b9 upstream. Otherwise RPCSEC_GSS_DESTROY messages are not sent. Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Olaf Hering authored
commit f5d2b7c2 upstream. Documentation/fb/modedb.txt states that video=option should be considered a global option. But video_setup and fb_get_options are not coded that way. Instead its required to boot with video=driver:option to set a given option in drvier. This is cumbersome because it requires to know in advance which driver will be active for a given board/kernel. The following patch implements the documented catchall for the fbdev drivers. It is now possible to boot with video=XxY without the need to know the active driver in advance. The specific case it tries to fix is syslinux in the SUSE installer which offers a menu to set a display resolution. Right now this just appends the vga= option the kernel. But in addition to vga= it should be possible to pass a generic video=XxY for all framebuffer/drm drivers. With this change forcing a certain window size of VM displays is now much easier. Today the video= option is stored in a global fb_mode_option. But unfortunately only drm uses it. Note: this change introduces a small memleak if video=option is actually used because fb_mode_option is const. Most drivers use strsep to get to individual options. This could be fixed in a followup patch which always releases the option string in every caller of fb_get_options. Signed-off-by:
Olaf Hering <olaf@aepfle.de> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Toshi Kani authored
commit a85eba88 upstream. When ACPI SLIT table has an I/O locality (i.e. a locality unique to an I/O device), numa_set_distance() emits this warning message: NUMA: Warning: node ids are out of bound, from=-1 to=-1 distance=10 acpi_numa_slit_init() calls numa_set_distance() with pxm_to_node(), which assumes that all localities have been parsed with SRAT previously. SRAT does not list I/O localities, where as SLIT lists all localities including I/Os. Hence, pxm_to_node() returns NUMA_NO_NODE (-1) for an I/O locality. I/O localities are not supported and are ignored today, but emitting such warning message leads to unnecessary confusion. Change acpi_numa_slit_init() to avoid calling numa_set_distance() with NUMA_NO_NODE. Signed-off-by:
Toshi Kani <toshi.kani@hp.com> Acked-by:
David Rientjes <rientjes@google.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Cc: Yinghai Lu <yinghai@kernel.org> Link: http://lkml.kernel.org/n/tip-dSvpjjvp8aMzs1ybkftxohlh@git.kernel.orgSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Oliver Neukum authored
commit 16c0c4e1 upstream. The AVX2 implementation also uses BMI2 instructions, but doesn't test for their availability. The assumption that AVX2 and BMI2 always go together is false. Some Haswells have AVX2 but not BMI2. Signed-off-by:
Oliver Neukum <oneukum@suse.de> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Jeff Mahoney authored
commit d0ce7b85 upstream. Commit 8116188f ("nouveau/acpi: hook up to the MXM method for mux switching.") broke the build on non-x86 architectures due to the new dependency on MXM and MXM being an x86 platform driver. It built previously since the vga switcheroo registration routines were zereod out on !X86. The code was built in but unused. This patch makes all of the DSM code depend on CONFIG_VGA_SWITCHEROO, allowing it to build on non-x86 and shrinking the module size as well. [rdunlap@infradead.org: fix build eror when VGA_SWITCHEROO is not enabled] Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
J. Bruce Fields authored
commit a3f432bf upstream. This check was added by Al Viro with d9e80b7d "nfs d_revalidate() is too trigger-happy with d_drop()", with the explanation that we don't want to remove the root of a disconnected tree, which will still be included on the s_anon list. But DCACHE_DISCONNECTED does *not* actually identify dentries that are disconnected from the dentry tree or hashed on s_anon. IS_ROOT() is the way to do that. Also add a comment from Al's commit to remind us why this check is there. Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Reviewed-by:
-
David Howells authored
commit 57be4a78 upstream. struct x509_certificate needs struct tm declaring by #inclusion of linux/time.h prior to its definition. Signed-off-by:
David Howells <dhowells@redhat.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Josh Boyer <jwboyer@redhat.com> Signed-off-by:
-
Bockholdt Arne authored
commit 22e580d0 upstream. Corrected the MWAIT flag for C-State C6 on Intel Avoton/Rangeley processors. Signed-off-by:
Arne Bockholdt <linux-kernel@bockholdt.com> Acked-by:
Len Brown <len.brown@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
- 01 Apr, 2014 3 commits
-
-
Len Brown authored
commit fab04b22 upstream. Support the "Intel(R) Atom(TM) Processor C2000 Product Family", formerly code-named Avoton. It is based on the next generation Intel Atom processor architecture, formerly code-named Silvermont. Signed-off-by:
-
James Ralston authored
commit afc65924 upstream. This patch adds the SMBus Device IDs for the Intel Wildcat Point-LP PCH. Signed-off-by:
James Ralston <james.d.ralston@intel.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Takashi Iwai authored
commit 7fe30711 upstream. The current code for controlling mic mute LED in patch_sigmatel.c blindly assumes that there is a single capture switch. But, there can be multiple multiple ones, and each of them flips the state, ended up in an inconsistent state. For fixing this problem, this patch adds kcontrol to be passed to the hook function so that the callee can check which switch is being accessed. In stac_capture_led_hook(), the state is checked as a bitmask, and turns on the LED when all capture switches are off. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
- 31 Mar, 2014 20 commits
-
-
Jiri Slaby authored
-
Ilya Dryomov authored
commit f2be82b0 upstream. The check that makes sure that we have enough memory allocated to read in the entire header of the message in question is currently busted. It compares front_len of the incoming message with iov_len field of ceph_msg::front structure, which is used primarily to indicate the amount of data already read in, and not the size of the allocated buffer. Under certain conditions (e.g. a short read from a socket followed by that socket's shutdown and owning ceph_connection reset) this results in a warning similar to [85688.975866] libceph: get_reply front 198 > preallocated 122 (4#0) and, through another bug, leads to forever hung tasks and forced reboots. Fix this by comparing front_len with front_alloc_len field of struct ceph_msg, which stores the actual size of the buffer. Fixes: http://tracker.ceph.com/issues/5425Signed-off-by:
Ilya Dryomov <ilya.dryomov@inktank.com> Reviewed-by:
Sage Weil <sage@inktank.com> Signed-off-by:
-
Ilya Dryomov authored
commit 3f0a4ac5 upstream. Rename front local variable to front_len in get_reply() to make its purpose more clear. Signed-off-by:
-
Ilya Dryomov authored
commit 3cea4c30 upstream. Rename front_max field of struct ceph_msg to front_alloc_len to make its purpose more clear. Signed-off-by:
-
Michele Baldessari authored
commit 2b6e0ca1 upstream. In https://bugzilla.redhat.com/show_bug.cgi?id=994438 and https://bugzilla.redhat.com/show_bug.cgi?id=970480 we received different reports of e100 throwing the following warning: [<c06a0ba5>] ? pci_disable_device+0x85/0x90 [<c044a153>] warn_slowpath_fmt+0x33/0x40 [<c06a0ba5>] pci_disable_device+0x85/0x90 [<f7fdf7e0>] __e100_shutdown+0x80/0x120 [e100] [<c0476ca5>] ? check_preempt_curr+0x65/0x90 [<f7fdf8d6>] e100_suspend+0x16/0x30 [e100] [<c06a1ebb>] pci_legacy_suspend+0x2b/0xb0 [<c098fc0f>] ? wait_for_completion+0x1f/0xd0 [<c06a2d50>] ? pci_pm_poweroff+0xb0/0xb0 [<c06a2de4>] pci_pm_freeze+0x94/0xa0 [<c0767bb7>] dpm_run_callback+0x37/0x80 [<c076a204>] ? pm_wakeup_pending+0xc4/0x140 [<c0767f12>] __device_suspend+0xb2/0x1f0 [<c076806f>] async_suspend+0x1f/0x90 [<c04706e5>] async_run_entry_fn+0x35/0x140 [<c0478aef>] ? wake_up_process+0x1f/0x40 [<c0464495>] process_one_work+0x115/0x370 [<c0462645>] ? start_worker+0x25/0x30 [<c0464dc5>] ? manage_workers.isra.27+0x1a5/0x250 [<c0464f6e>] worker_thread+0xfe/0x330 [<c0464e70>] ? manage_workers.isra.27+0x250/0x250 [<c046a224>] kthread+0x94/0xa0 [<c0997f37>] ret_from_kernel_thread+0x1b/0x28 [<c046a190>] ? insert_kthread_work+0x30/0x30 This patch removes pci_disable_device() from __e100_shutdown(). pci_clear_master() is enough. Signed-off-by:
Michele Baldessari <michele@acksyn.org> Tested-by:
Mark Harig <idirectscm@aim.com> Signed-off-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Cc: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by:
-
Sarah Sharp authored
commit 1aa9578c upstream. Don Zickus <dzickus@redhat.com> writes: Some co-workers of mine bought Samsung laptops that had mostly usb3 ports. Those ports did not resume correctly (the driver would timeout communicating and fail). This led to frustration as suspend/resume is a common use for laptops. Poking around, I applied the reset on resume quirk to this chipset and the resume started working. Reloading the xhci_hcd module had been the temporary workaround. Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by:
Don Zickus <dzickus@redhat.com> Tested-by:
Prarit Bhargava <prarit@redhat.com> Signed-off-by:
-
Ping Cheng authored
commit 1d0d6df0 upstream. Old single touch Tablet PCs do not have touch_max set at wacom_features. Since touch device at lease supports one finger, assign touch_max to 1 when touch usage is defined in its HID Descriptor and touch_max is not pre-defined. Tested-by:
Jason Gerecke <killertofu@gmail.com> Signed-off-by:
Ping Cheng <pingc@wacom.com> Reviewed-by:
Chris Bagwell <chris@cnpbagwell.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by:
-
Marcelo Tosatti authored
commit 26a865f4 upstream. After free_loaded_vmcs executes, the "loaded_vmcs" structure is kfreed, and now vmx->loaded_vmcs points to a kfreed area. Subsequent free_loaded_vmcs then attempts to manipulate vmx->loaded_vmcs. Switch the order to avoid the problem. https://bugzilla.redhat.com/show_bug.cgi?id=1047892Reviewed-by:
Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com> Cc: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by:
-
Marcelo Tosatti authored
commit 37f6a4e2 upstream. Rom Freiman <rom@stratoscale.com> notes other code paths vulnerable to bug fixed by 989c6b34. Signed-off-by:
-
Marcelo Tosatti authored
commit 989c6b34 upstream. It is possible for __direct_map to be called on invalid root_hpa (-1), two examples: 1) try_async_pf -> can_do_async_pf -> vmx_interrupt_allowed -> nested_vmx_vmexit 2) vmx_handle_exit -> vmx_interrupt_allowed -> nested_vmx_vmexit Then to load_vmcs12_host_state and kvm_mmu_reset_context. Check for this possibility, let fault exception be regenerated. BZ: https://bugzilla.redhat.com/show_bug.cgi?id=924916Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Cc: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by:
-
Hans de Goede authored
commit c15bdfd5 upstream. The current assumption in the elantech driver that hw version 3 touchpads are never clickpads and hw version 4 touchpads are always clickpads is wrong. There are several bug reports for this, ie: https://bugzilla.redhat.com/show_bug.cgi?id=1030802 http://superuser.com/questions/619582/right-elantech-touchpad-button-not-working-in-linux I've spend a couple of hours wading through various bugzillas, launchpads and forum posts to create a list of fw-versions and capabilities for different laptop models to find a good method to differentiate between clickpads and versions with separate hardware buttons. Which shows that a device being a clickpad is reliable indicated by bit 12 being set in the fw_version. I've included the gathered list inside the driver, so that we've this info at hand if we need to revisit this later. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
-
Dave Jones authored
commit c1d867a5 upstream. Distribution kernels might want to build in support for /proc/device-tree for kernels that might end up running on hardware that doesn't support openfirmware. This results in an empty /proc/device-tree existing. Remove it if the OFW root node doesn't exist. This situation actually confuses grub2, resulting in install failures. grub2 sees the /proc/device-tree and picks the wrong install target cf. http://bzr.savannah.gnu.org/lh/grub/trunk/grub/annotate/4300/util/grub-install.in#L311 grub should be more robust, but still, leaving an empty proc dir seems pointless. Addresses https://bugzilla.redhat.com/show_bug.cgi?id=818378. Signed-off-by:
Dave Jones <davej@redhat.com> Cc: Al Viro <viro@ZenIV.linux.org.uk> Cc: Paul Mackerras <paulus@samba.org> Cc: Josh Boyer <jwboyer@fedoraproject.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Gavin Shan authored
commit 7e4e7867 upstream. For one PCI error relevant OPAL event, we possibly have multiple EEH errors for that. For example, multiple frozen PEs detected on different PHBs. Unfortunately, we didn't cover the case. The patch enumarates the return value from eeh_ops::next_error() and change eeh_handle_special_event() and eeh_ops::next_error() to handle all existing EEH errors. As Ben pointed out, we needn't list_for_each_entry_safe() since we are not deleting any PHB from the hose_list and the EEH serialized lock should be held while purging EEH events. The patch covers those suggestions as well. Signed-off-by:
Gavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Markus Pargmann authored
commit 66fda75f upstream. There are many places where ops->disable is called directly. Instead we should use _regulator_do_disable() which also handles gpio regulators. To be able to use the wrapper function from _regulator_force_disable(), I moved the _notifier_call_chain() call from _regulator_do_disable() to _regulator_disable(). This way, _regulator_force_disable() can use different flags for _notifier_call_chain() without calling it twice. Signed-off-by:
Markus Pargmann <mpa@pengutronix.de> Signed-off-by:
Mark Brown <broonie@linaro.org> Signed-off-by:
-
Dan Carpenter authored
commit 608cfbe4 upstream. The call to clamp_t() first truncates the variable signed 8 bit and as a result, the actual clamp is a no-op. Fixes: 0d78156e ('p54: improve site survey') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Ben Hutchings authored
commit f8ce239d upstream. builddeb generates a control file that says the linux-headers package can only be built for the build system primary architecture. This breaks cross-building configurations. We should use $debarch for this instead. Since $debarch is not yet set when generating the control file, set Architecture: any and use control file variables to fill in the description. Fixes: cd8d60a2 ('kbuild: create linux-headers package in deb-pkg') Reported-and-tested-by:
"Niew, Sh." <shniew@gmail.com> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Michal Marek <mmarek@suse.cz> Signed-off-by:
-
Ben Hutchings authored
commit c5e318f6 upstream. These commands will mysteriously fail: $ make ARCH=arm versatile_defconfig [...] $ make ARCH=arm deb-pkg [...] make[1]: *** [deb-pkg] Error 1 make: *** [deb-pkg] Error 2 The Debian architecture selection for these kernel architectures does 'grep FOO=y $KCONFIG_CONFIG && echo bar', and after 'set -e' this aborts the script if grep does not find the given config symbol. Fixes: 10f26fa6 ('build, deb-pkg: select userland architecture based on UTS_MACHINE') Signed-off-by:
-
Linus Torvalds authored
commit e4178d80 upstream. This is not a buffer overflow in the traditional sense: we don't overflow any *kernel* buffers, but we do mis-count the amount of data we copy back to user space for the SYSLOG_ACTION_READ_ALL case. In particular, if the user buffer is too small to hold everything, and *if* there is a continuation line at just the right place, we can end up giving the user more data than he asked for. The reason is that we first count up the number of bytes all the log records contains, then we walk the records again until we've skipped the records at the beginning that won't fit, and then we walk the rest of the records and copy them to the user space buffer. And in between that "skip the initial records that won't fit" and the "copy the records that *will* fit to user space", we reset the 'prev' variable that contained the record information for the last record not copied. That meant that when we started copying to user space, we now had a different character count than what we had originally calculated in the first record walk-through. The fix is to simply not clear the 'prev' flags value (in both cases where we had the same logic: syslog_print_all and kmsg_dump_get_buffer: the latter is used for pstore-like dumping) Reported-and-tested-by:
Debabrata Banerjee <dbanerje@akamai.com> Acked-by:
Kay Sievers <kay@vrfy.org> Cc: Jeff Mahoney <jeffm@suse.com> Signed-off-by:
-
Alexei Starovoitov authored
commit fdfaf64e upstream. Commit a998d434 claimed to introduce negative offset support to x86 jit, but it couldn't be working, since at the time of the execution of LD+ABS or LD+IND instructions via call into bpf_internal_load_pointer_neg_helper() the %edx (3rd argument of this func) had junk value instead of access size in bytes (1 or 2 or 4). Store size into %edx instead of %ecx (what original commit intended to do) Fixes: a998d434 ("bpf jit: Let the x86 jit handle negative offsets") Signed-off-by:
Alexei Starovoitov <ast@plumgrid.com> Cc: Jan Seiffert <kaffeemonster@googlemail.com> Cc: Eric Dumazet <edumazet@google.com> Acked-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Ben Hutchings authored
commit d9317aea upstream. As part of a workaround for a hardware erratum in the SFC9100 family (SF bug 35388), the TX_DESC_UPD_DWORD register address is also used for communicating with the event block, and only descriptor pointer values < 2048 are valid. If the TX DMA ring size is increased to 4096 descriptors (which the firmware still allows) then we may write a descriptor pointer value >= 2048, which has entirely different and undesirable effects! Limit the TX DMA ring size correctly when this workaround is in effect. Fixes: 8127d661 ('sfc: Add support for Solarflare SFC9100 family') Signed-off-by:
Ben Hutchings <bhutchings@solarflare.com> Signed-off-by:
Shradha Shah <sshah@solarflare.com> Signed-off-by:
-
