Re: [PATCH] RISC-V: defconfig: Enable Generic PCIE by default

On Fri, 2018-12-21 at 11:13 -0800, Paul Walmsley wrote: > Hello Alistair, > > On Fri, 21 Dec 2018, Alistair Francis wrote: > > > Enable generic PCIe by default in the RISC-V defconfig, this allows > > us > > to use QEMU's PCIe support out of the box. Also remove the Xilinx > > PCIe > > support

Re: [PATCH] binderfs: implement sysctls

On Fri, Dec 21, 2018 at 05:33:16PM +0100, Greg KH wrote: > On Fri, Dec 21, 2018 at 04:59:19PM +0100, Christian Brauner wrote: > > On Fri, Dec 21, 2018 at 04:37:58PM +0100, Greg KH wrote: > > > On Fri, Dec 21, 2018 at 03:12:42PM +0100, Christian Brauner wrote: > > > > On Fri, Dec 21, 2018 at

Re: [PATCH] firmware: arm_sdei: fix wrong of_node_put() in init function

Hi Nicolas, On 03/12/2018 12:25, Nicolas Saenz Julienne wrote: > On Fri, 2018-11-30 at 18:31 +, James Morse wrote: >> On 26/11/2018 12:15, Nicolas Saenz Julienne wrote: >>> After finding a "firmware" dt node arm_sdei tries to match it's >>> compatible string with it. To do so it's calling >>>

Re: [PATCH] net: 80003es2lan: fix a missing check of read failure

On Thu, 2018-12-20 at 15:23 -0600, Kangjie Lu wrote: > When e1000_read_kmrn_reg_80003es2lan() fails, "kum_reg_data" is > uninitialized and may contain random value. However, it is further > used in the following execution, which will lead to undefined > behaviors. > The fix checks the failure of

Re: [PATCH v2] arm64: dts: sdm845: Add cpufreq device node

On Fri, Dec 21, 2018 at 11:44:23PM +0530, Taniya Das wrote: > This change adds the cpufreq node as per the bindings example for SDM845. > > Signed-off-by: Taniya Das > Tested-by: Matthias Kaehlcke > --- > arch/arm64/boot/dts/qcom/sdm845.dtsi | 19 +++ > 1 file changed, 19

Re: [PATCH] RISC-V: defconfig: Enable Generic PCIE by default

Hello Alistair, On Fri, 21 Dec 2018, Alistair Francis wrote: > Enable generic PCIe by default in the RISC-V defconfig, this allows us > to use QEMU's PCIe support out of the box. Also remove the Xilinx PCIe > support by default as this is rarely used and conflicts with the more > commonly used

Re: [PATCH v2 01/12] fs-verity: add a documentation file

On Fri, Dec 21, 2018 at 7:47 AM Theodore Y. Ts'o wrote: > > Linus --- we're going round and round, and I don't think this is > really a technical dispute at this point, but rather an aesthetics > one. Grr. So honestly, I personally *like* the model of "the file contains its own validation data"

[PATCH v2] hwmon: (lm80) fix a missing check of bus read in lm80 probe

In lm80_probe(), if lm80_read_value() fails, it returns a negative error number which is stored to data->fan[f_min] and will be further used. We should avoid using the data if the read fails. The fix checks if lm80_read_value() fails, and if so, returns with the error number. Signed-off-by:

Re: [PATCH 03/12] __wr_after_init: generic functionality

On 21/12/2018 20:41, Matthew Wilcox wrote: On Fri, Dec 21, 2018 at 08:14:14PM +0200, Igor Stoppa wrote: +static inline int memtst(void *p, int c, __kernel_size_t len) I don't understand why you're verifying that writes actually happen in production code. Sure, write lib/test_wrmem.c or

[PATCH] RISC-V: defconfig: Enable Generic PCIE by default

Enable generic PCIe by default in the RISC-V defconfig, this allows us to use QEMU's PCIe support out of the box. Also remove the Xilinx PCIe support by default as this is rarely used and conflicts with the more commonly used (out of tree) MicroSemi PCIe root complex. Signed-off-by: Alistair

[PATCH v2] hwmon: (lm80) fix a missing check of the status of SMBus read

If lm80_read_value() fails, it returns a negative number instead of the correct read data. Therefore, we should avoid using the data if it fails. The fix checks if lm80_read_value() fails, and if so, returns with the error number. Signed-off-by: Kangjie Lu --- drivers/hwmon/lm80.c | 8 ++--

Re: [PATCH] ACPI/APEI: Clear GHES block_status before panic()

On Fri, Dec 21, 2018 at 06:52:20PM +, James Morse wrote: > Do we need to ghes_ack_error() too? That's GHES v2 AFAICT. > With the location cleared the new kernel will never find the records, and > firmware can never re-use that location because it wasn't ack'd. The upshot is > RAS records

Re: [PATCH 2/2] drm: Revert syncobj timeline changes.

On 21.12.2018 21:45, Koenig, Christian wrote: > Am 21.12.18 um 19:35 schrieb Dmitry Osipenko: >> On 21.12.2018 21:27, Christian König wrote: >>> Am 19.12.18 um 18:53 schrieb Dmitry Osipenko: [SNIP] > @@ -931,9 +718,6 @@ static signed long > drm_syncobj_array_wait_timeout(struct

Re: [PATCH 09/21] PCI: imx6: Drop imx6_pcie_link_up()

On Thu, 2018-12-20 at 23:27 -0800, Andrey Smirnov wrote: > Until commit 4d107d3b5a68 ("PCI: imx6: Move link up check into > imx6_pcie_wait_for_link()") the driver relied on both LINK_UP and > LINK_IN_TRAINING to determine if PCIE link was up. I've already got a patch in that fixed this issue.

Re: [v2 PATCH 1/2] mm: swap: check if swap backing device is congested or not

On 12/21/18 10:34 AM, Tim Chen wrote: On 12/20/18 4:21 PM, Yang Shi wrote: --- a/mm/swap_state.c +++ b/mm/swap_state.c @@ -538,11 +538,17 @@ struct page *swap_cluster_readahead(swp_entry_t entry, gfp_t gfp_mask, bool do_poll = true, page_allocated; struct vm_area_struct

Re: [PATCH] ACPI/APEI: Clear GHES block_status before panic()

On 21/12/2018 11:17, Rafael J. Wysocki wrote: > On Thursday, December 20, 2018 8:24:47 PM CET Borislav Petkov wrote: >> + James. Thanks, >> On Wed, Dec 19, 2018 at 11:50:52AM -0500, David Arcari wrote: >>> From: Lenny Szubowicz >>> >>> In __ghes_panic() clear the block status in the APEI

Re: linux-next: Tree for Dec 21 (nvdimm/security.o)

On Fri, Dec 21, 2018 at 10:44 AM Randy Dunlap wrote: > > On 12/21/18 12:32 AM, Stephen Rothwell wrote: > > Hi all, > > > > News: there will be no linux-next release until Jan 2. Have a good break. > > > > Changes since 20181220: > > > > on x86_64: > > ld: drivers/nvdimm/security.o: in function

Re: [for-next][PATCH 23/24] string.h: Add strncmp_prefix() helper macro

On Fri, Dec 21, 2018 at 9:57 AM Steven Rostedt wrote: > > I figured the best thing to do is to create a helper macro and place it > into include/linux/string.h. And go around and fix all the open coded > versions of it later. > > I plan on only applying this patch and updating the tracing hooks

Re: [PATCH 01/10] i2c: add suspended flag and accessors for i2c adapters

Hi Peter, > Yes, I agree with that analysis. All mux actions eventually end up with Good! > an __i2c_transfer() call on the relevant root adapter. Hmm, but not *all* > calls. How about SMBus adapters? Should there not be a similar WARN_ON > in __i2c_smbus_xfer? Yes, there should. Yeah, that's

Re: [PATCH 01/12] x86_64: memset_user()

On 21/12/2018 20:25, Matthew Wilcox wrote: On Fri, Dec 21, 2018 at 08:14:12PM +0200, Igor Stoppa wrote: +unsigned long __memset_user(void __user *addr, int c, unsigned long size) +{ + long __d0; + unsigned long pattern = 0; + int i; + + for (i = 0; i < 8; i++) +

Re: [PATCH 2/2] drm: Revert syncobj timeline changes.

Am 21.12.18 um 19:35 schrieb Dmitry Osipenko: > On 21.12.2018 21:27, Christian König wrote: >> Am 19.12.18 um 18:53 schrieb Dmitry Osipenko: >>> [SNIP] @@ -931,9 +718,6 @@ static signed long drm_syncobj_array_wait_timeout(struct drm_syncobj **syncobjs,     if (flags &

Re: [PATCH v2] x86, kbuild: revert macrofying inline assembly code

Masahiro Yamada writes: > Revert the following 9 commits: FWIW the -Wa additional also broke LTO builds because it doesn't really support -Wa for individual files. So I'm glad they got reverted. -Andi

Re: [PATCH 03/12] __wr_after_init: generic functionality

On Fri, Dec 21, 2018 at 08:14:14PM +0200, Igor Stoppa wrote: > +static inline int memtst(void *p, int c, __kernel_size_t len) I don't understand why you're verifying that writes actually happen in production code. Sure, write lib/test_wrmem.c or something, but verifying every single rare write

Re: [PATCH 01/10] i2c: add suspended flag and accessors for i2c adapters

On 2018-12-21 15:50, Wolfram Sang wrote: > I think this might be as simple as adding: if (WARN_ON(adap->dev.parent->power.is_suspended)) return -ESHUTDOWN; > > Peter, I think this should work for muxes, too, or? The i2c_transfer() > call to the mux will not be

Re: linux-next: Tree for Dec 21 (FB_BACKLIGHT)

On 12/21/18 12:32 AM, Stephen Rothwell wrote: > Hi all, > > News: there will be no linux-next release until Jan 2. Have a good break. > > Changes since 20181220: > on x86_64: WARNING: unmet direct dependencies detected for FB_BACKLIGHT Depends on [m]: HAS_IOMEM [=y] && FB [=m] Selected

Re: [PATCH 2/2] drm: Revert syncobj timeline changes.

On 21.12.2018 21:27, Christian König wrote: > Am 19.12.18 um 18:53 schrieb Dmitry Osipenko: >> [SNIP] >>> @@ -931,9 +718,6 @@ static signed long >>> drm_syncobj_array_wait_timeout(struct drm_syncobj **syncobjs, >>>     if (flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT) { >>>   for (i

Re: [v2 PATCH 1/2] mm: swap: check if swap backing device is congested or not

On 12/20/18 4:21 PM, Yang Shi wrote: > --- a/mm/swap_state.c > +++ b/mm/swap_state.c > @@ -538,11 +538,17 @@ struct page *swap_cluster_readahead(swp_entry_t entry, > gfp_t gfp_mask, > bool do_poll = true, page_allocated; > struct vm_area_struct *vma = vmf->vma; > unsigned long

Re: [PATCH v4 10/18] iommu/mediatek: Add mt8183 IOMMU support

On 08/12/2018 09:39, Yong Wu wrote: > The M4U IP blocks in mt8183 is MediaTek's generation2 M4U which use > the ARM Short-descriptor like mt8173, and most of the HW registers > are the same. > > Here list main differences between mt8183 and mt8173/mt2712: > 1) mt8183 has only one M4U HW like

Re: [PATCH] drm/amd/powerplay/polaris10_smumgr: Remove duplicate

Already fixed here: https://cgit.freedesktop.org/drm/drm/commit/?id=7e07834c12b96214e95a473f7b14fc03b20e2e7a Thanks, Alex On Fri, Dec 21, 2018 at 9:59 AM Brajeswar Ghosh wrote: > > Remove ppatomctrl.h which is included more than once > > Signed-off-by: Brajeswar Ghosh > --- >

Re: [PATCH v2 2/2] hugetlbfs: Use i_mmap_rwsem to fix page fault/truncate race

On 12/21/18 2:28 AM, Kirill A. Shutemov wrote: > On Tue, Dec 18, 2018 at 02:35:57PM -0800, Mike Kravetz wrote: >> Instead of writing the required complicated code for this rare >> occurrence, just eliminate the race. i_mmap_rwsem is now held in read >> mode for the duration of page fault

Re: [PATCH v3 2/3] dt-bindings: drm/msm/a6xx: Document interconnect properties for GPU

On Thu, 20 Dec 2018 10:30:25 -0700, Jordan Crouse wrote: > Add documentation for the interconnect and interconnect-names bindings > for the GPU node as detailed by bindings/interconnect/interconnect.txt. > > Signed-off-by: Jordan Crouse > --- > >

Re: linux-next: Tree for Dec 21 (acpi without CONFIG_PCI)

On 12/21/18 9:23 AM, Sinan Kaya wrote: > > > On Friday, December 21, 2018, Randy Dunlap > wrote: > > On 12/21/18 12:32 AM, Stephen Rothwell wrote: > > Hi all, > > > > News: there will be no linux-next release until Jan 2.  Have a good > break. >

Re: [PATCH v17 18/23] platform/x86: Intel SGX driver

On Wed, Dec 19, 2018 at 07:00:47AM +0200, Jarkko Sakkinen wrote: > On Tue, Dec 18, 2018 at 10:53:49AM -0800, Sean Christopherson wrote: > > What if we re-organize the ioctls in such a way that we leave open the > > possibility of allocating raw EPC for KVM via /dev/sgx? I'm not 100% > > positive

Re: [PATCH 2/2] drm: Revert syncobj timeline changes.

Am 19.12.18 um 18:53 schrieb Dmitry Osipenko: [SNIP] @@ -931,9 +718,6 @@ static signed long drm_syncobj_array_wait_timeout(struct drm_syncobj **syncobjs, if (flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT) { for (i = 0; i < count; ++i) { - if

Re: [PATCH 01/12] x86_64: memset_user()

On Fri, Dec 21, 2018 at 08:14:12PM +0200, Igor Stoppa wrote: > +unsigned long __memset_user(void __user *addr, int c, unsigned long size) > +{ > + long __d0; > + unsigned long pattern = 0; > + int i; > + > + for (i = 0; i < 8; i++) > + pattern = (pattern << 8) | (0xFF

Re: [PATCH v5 6/8] iio: adc: add STMPE ADC devicetree bindings

On Fri, 21 Dec 2018 14:46:35 +0100, Philippe Schenker wrote: > From: Stefan Agner > > This adds the devicetree bindings for the STMPE ADC. This also corrects > a typo in st,sample-time it is rather "6 -> 124 clocks" according > to the datasheet and not 144. > We need to use the naming stmpe_adc

Re: x86/sgx: uapi change proposal

On Fri, Dec 21, 2018 at 09:12:46AM -0800, Andy Lutomirski wrote: > > On Dec 21, 2018, at 9:28 AM, Sean Christopherson > > wrote: > > > > On Wed, Dec 19, 2018 at 06:58:48PM -0800, Andy Lutomirski wrote: > >>> On Dec 19, 2018, at 6:45 AM, Sean Christopherson > >>> wrote: > >>> > > On Wed,

Re: [for-next][PATCH 06/24] sparc64: Use ftrace_graph_get_ret_stack() instead of curr_ret_stack

From: Steven Rostedt Date: Fri, 21 Dec 2018 12:56:24 -0500 > From: "Steven Rostedt (VMware)" > > The structure of the ret_stack array on the task struct is going to > change, and accessing it directly via the curr_ret_stack index will no > longer give the ret_stack entry that holds the return

Re: [PATCH v5 1/8] dt-bindings: stmpe: reformatting parameter list and use tabs only

On Fri, 21 Dec 2018 14:46:30 +0100, Philippe Schenker wrote: > From: Philippe Schenker > > This patch reformats the parameter list for stmpe device in a > table-style so it is more clear to read. > > Signed-off-by: Philippe Schenker > Acked-for-MFD-by: Lee Jones > > --- > > Changes in v5: >

[PATCH] x86/speculation: Add document to describe Spectre and its mitigations

Thomas, Andi and I have made an update to our draft of the Spectre admin guide. We may be out on Christmas vacation for a while. But we want to send it out for everyone to take a look. Thanks. Tim From: Andi Kleen There are no document in admin guides describing Spectre v1 and v2 side

Re: [PATCH v2 1/2] hugetlbfs: use i_mmap_rwsem for more pmd sharing synchronization

On 12/21/18 2:05 AM, Kirill A. Shutemov wrote: > On Tue, Dec 18, 2018 at 02:35:56PM -0800, Mike Kravetz wrote: >> While looking at BUGs associated with invalid huge page map counts, >> it was discovered and observed that a huge pte pointer could become >> 'invalid' and point to another task's page

Re: [PATCH 1/5] dt-bindings: gpu: mali-utgard: add Amlogic Meson8 and Meson8b compatible

On Sat, 8 Dec 2018 18:12:43 +0100, Martin Blumenstingl wrote: > Add a compatible string for the Mali-450 GPU on Amlogic Meson8 and > Meson8b SoCs. Meson8 uses an "MP6" variant with six pixel processors > while Meson8b (as cost-reduced SoC) uses an "MP2" variant with two pixel > processors. Both

Re: [RFC RESEND PATCH] kvm: arm64: export memory error recovery capability to user space

Hi Peter, On 19/12/2018 19:02, Peter Maydell wrote: > On Mon, 17 Dec 2018 at 15:56, James Morse wrote: >> I don't think this really matters. Its only the NMIlike notifications that >> the >> guest doesn't have to register or poll. The ones we support today extend the >> architectures existing

[PATCH 04/12] __wr_after_init: debug writes

After each write operation, confirm that it was successful, otherwise generate a warning. Signed-off-by: Igor Stoppa CC: Andy Lutomirski CC: Nadav Amit CC: Matthew Wilcox CC: Peter Zijlstra CC: Kees Cook CC: Dave Hansen CC: Mimi Zohar CC: Thiago Jung Bauermann CC: Ahmed Soliman CC:

Re: [PATCH] arm64: dts: sdm845: Add cpufreq device node

Hello Matthias, On 12/21/2018 1:20 AM, Matthias Kaehlcke wrote: Hi Taniya, On Fri, Dec 21, 2018 at 12:48:50AM +0530, Taniya Das wrote: This change adds the cpufreq node as per the bindings example for SDM845. Signed-off-by: Taniya Das --- arch/arm64/boot/dts/qcom/sdm845.dtsi | 19

Applied "ASoC: xlnx: add pcm formatter platform driver" to the asoc tree

The patch ASoC: xlnx: add pcm formatter platform driver has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent

[PATCH 11/12] IMA: turn ima_policy_flags into __wr_after_init

The policy flags could be targeted by an attacker aiming at disabling IMA, so that there would be no trace of a file system modification in the measurement list. Since the flags can be altered at runtime, it is not possible to make them become fully read-only, for example with __ro_after_init.

[PATCH 10/12] __wr_after_init: test write rare functionality

Set of test cases meant to confirm that the write rare functionality works as expected. It can be optionally compiled as module. Signed-off-by: Igor Stoppa CC: Andy Lutomirski CC: Nadav Amit CC: Matthew Wilcox CC: Peter Zijlstra CC: Kees Cook CC: Dave Hansen CC: Mimi Zohar CC: Thiago

[PATCH 07/12] __wr_after_init: lkdtm test

Verify that trying to modify a variable with the __wr_after_init attribute will cause a crash. Signed-off-by: Igor Stoppa CC: Andy Lutomirski CC: Nadav Amit CC: Matthew Wilcox CC: Peter Zijlstra CC: Kees Cook CC: Dave Hansen CC: Mimi Zohar CC: Thiago Jung Bauermann CC: Ahmed Soliman

[PATCH 06/12] __wr_after_init: Documentation: self-protection

Update the self-protection documentation, to mention also the use of the __wr_after_init attribute. Signed-off-by: Igor Stoppa CC: Andy Lutomirski CC: Nadav Amit CC: Matthew Wilcox CC: Peter Zijlstra CC: Kees Cook CC: Dave Hansen CC: Mimi Zohar CC: Thiago Jung Bauermann CC: Ahmed

Applied "ASoC: rockchip: support ACODEC for rk3328" to the asoc tree

The patch ASoC: rockchip: support ACODEC for rk3328 has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to

[PATCH 02/12] __wr_after_init: linker section and label

Introduce a section and a label for statically allocated write rare data. The label is named "__wr_after_init". As the name implies, after the init phase is completed, this section will be modifiable only by invoking write rare functions. The section must take up a set of full pages. To activate

[PATCH 12/12] x86_64: __clear_user as case of __memset_user

To avoid code duplication, re-use __memset_user(), when clearing user-space memory. The overhead should be minimal (2 extra register assignments) and outside of the writing loop. Signed-off-by: Igor Stoppa CC: Andy Lutomirski CC: Nadav Amit CC: Matthew Wilcox CC: Peter Zijlstra CC: Kees

[PATCH 09/12] rodata_test: add verification for __wr_after_init

The write protection of the __wr_after_init data can be verified with the same methodology used for const data. Signed-off-by: Igor Stoppa CC: Andy Lutomirski CC: Nadav Amit CC: Matthew Wilcox CC: Peter Zijlstra CC: Kees Cook CC: Dave Hansen CC: Mimi Zohar CC: Thiago Jung Bauermann CC:

Applied "ASoC: rockchip: add workaround for silence of rk3288 ACODEC" to the asoc tree

The patch ASoC: rockchip: add workaround for silence of rk3288 ACODEC has been applied to the asoc tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24

[PATCH 08/12] rodata_test: refactor tests

Refactor the test cases, in preparation for using them also for testing __wr_after_init memory, when available. Signed-off-by: Igor Stoppa CC: Andy Lutomirski CC: Nadav Amit CC: Matthew Wilcox CC: Peter Zijlstra CC: Kees Cook CC: Dave Hansen CC: Mimi Zohar CC: Thiago Jung Bauermann CC:

[PATCH 03/12] __wr_after_init: generic functionality

The patch provides: - the generic part of the write rare functionality for static data, based on code from Matthew Wilcox - the dummy functionality, in case an arch doesn't support write rare or the functionality is disabled The basic functions are: - wr_memset(): write rare counterpart of

[PATCH v2] arm64: dts: sdm845: Add cpufreq device node

This change adds the cpufreq node as per the bindings example for SDM845. Signed-off-by: Taniya Das Tested-by: Matthias Kaehlcke --- arch/arm64/boot/dts/qcom/sdm845.dtsi | 19 +++ 1 file changed, 19 insertions(+) diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi

[PATCH 05/12] __wr_after_init: x86_64: __wr_op

Architecture-specific implementation of the core write rare operation. The implementation is based on code from Andy Lutomirski and Nadav Amit for patching the text on x86 [here goes reference to commits, once merged] The modification of write protected data is done through an alternate mapping

[PATCH 01/12] x86_64: memset_user()

Create x86_64 specific version of memset for user space, based on clear_user(). This will be used for implementing wr_memset() in the __wr_after_init scenario, where write-rare variables have an alternate mapping for writing. Signed-off-by: Igor Stoppa CC: Andy Lutomirski CC: Nadav Amit CC:

Re: [PATCH] ARM: Ensure that NEON code always compiles with Clang

On Sat, Dec 15, 2018 at 1:23 PM Nathan Chancellor wrote: > > While building arm32 allyesconfig, I ran into the following errors: > > arch/arm/lib/xor-neon.c:17:2: error: You should compile this file with > '-mfloat-abi=softfp -mfpu=neon' > > In file included from lib/raid6/neon1.c:27: >

Re: > [PATCH] Security: Handle hidepid option correctly

On Mon, Dec 17, 2018 at 12:21:40PM +0800, 程洋 wrote: > Actually I'm pretty sure kernel calls proc_mount() > Here is the call stack OK, hidepid= is still misdesigned. :-(

[PATCH v1] cpufreq: qcom: Read voltage LUT and populate OPP

Add support to read the voltage look up table and populate OPP for all corresponding CPUS. Signed-off-by: Taniya Das --- drivers/cpufreq/qcom-cpufreq-hw.c | 32 ++-- 1 file changed, 30 insertions(+), 2 deletions(-) diff --git a/drivers/cpufreq/qcom-cpufreq-hw.c

Re: [for-next][PATCH 09/24] seq_buf: Make seq_buf_puts() null-terminate the buffer

On Fri, 21 Dec 2018 13:00:21 -0500 Steven Rostedt wrote: > > Can result in: > > > > Message is fooªªªªªsecret > > Sending this via quilt, and that we have non UTF8 characters causes > LKML to blow up. > > There's a couple more patches with this issue. I'm going to fix up the >

Re: linux-next: Tree for Dec 21 (SND_HDA_INTEL_DSP_DETECTION)

On 12/21/18 12:32 AM, Stephen Rothwell wrote: > Hi all, > > News: there will be no linux-next release until Jan 2. Have a good break. > > Changes since 20181220: > on x86_64: A new group of Kconfig "select"s is causing kconfig warnings: WARNING: unmet direct dependencies detected for

Re: [PATCH 00/14] Add support for FM radio in hcill and kill TI_ST

* Sebastian Reichel [181221 01:18]: > The new code has been tested on the Motorola Droid 4. For testing the audio > should be configured to route Ext to Speaker or Headphone. Then you need to > plug headphone, since its cable is used as antenna. For testing there is a > 'radio' utility packages

Re: [for-next][PATCH 09/24] seq_buf: Make seq_buf_puts() null-terminate the buffer

On Fri, 21 Dec 2018 12:56:27 -0500 Steven Rostedt wrote: > From: Michael Ellerman > > Currently seq_buf_puts() will happily create a non null-terminated > string for you in the buffer. This is particularly dangerous if the > buffer is on the stack. > > For example: > > char buf[8]; >

Re: [PATCH 0/7] ARM: hacks for link-time optimization

On Fri, Dec 21, 2018 at 09:20:44AM -0800, Andi Kleen wrote: > > In particular turning an address-dependency into a control-dependency, > > which is something allowed by the C language, since it doesn't recognise > > these concepts as such. > > > > The 'optimization' is allowed currently, but LTO

Re: [PATCH 01/13] clk: qcom: gcc: limit GPLL0_AO_OUT operating frequency

Hello, On 12/21/2018 6:06 PM, Jorge Ramirez wrote: On 12/21/18 12:19, Taniya Das wrote: On 12/17/2018 3:16 PM, Jorge Ramirez-Ortiz wrote: Limit the GPLL0_AO_OUT_MAIN operating frequency as per its hardware specifications. Co-developed-by: Niklas Cassel Signed-off-by: Niklas Cassel

[for-next][PATCH 02/24] arm64: ftrace: Set FTRACE_MAY_SLEEP before ftrace_modify_all_code()

From: "Steven Rostedt (VMware)" It has been reported that ftrace_replace_code() which is called by ftrace_modify_all_code() can cause a soft lockup warning for an allmodconfig kernel. This is because all the debug options enabled causes the loop in ftrace_replace_code() (which loops over all the

[for-next][PATCH 00/24] tracing: Updates for the next (coming soon) merge window

git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git for-next Head SHA1: 05cd667ce570cb82a967af7166c54c610324861c Mathieu Malaterre (1): tracing: Make function ‘ftrace_exports’ static Michael Ellerman (2): seq_buf: Make seq_buf_puts() null-terminate the

[for-next][PATCH 03/24] fgraph: Add comment to describe ftrace_graph_get_ret_stack

From: "Steven Rostedt (VMware)" The ret_stack should not be accessed directly via the curr_ret_stack variable on the task_struct. This is because the ret_stack is going to be converted into a series of longs and not an array of ret_stack structures. The way that a ret_stack should be retrieved

[for-next][PATCH 07/24] sh: ftrace: Use ftrace_graph_get_ret_stack() instead of curr_ret_stack

From: "Steven Rostedt (VMware)" The structure of the ret_stack array on the task struct is going to change, and accessing it directly via the curr_ret_stack index will no longer give the ret_stack entry that holds the return address. To access that, architectures must now use

[for-next][PATCH 04/24] x86/ftrace: Do not call function graph from dynamic trampolines

From: "Steven Rostedt (VMware)" Since commit 79922b8009c07 ("ftrace: Optimize function graph to be called directly"), dynamic trampolines should not be calling the function graph tracer at the end. If they do, it could cause the function graph tracer to trace functions that it filtered out.

[for-next][PATCH 11/24] tracing: Fix ftrace_graph_get_ret_stack() to use task and not current

From: "Steven Rostedt (VMware)" The function ftrace_graph_get_ret_stack() takes a task struct descriptor but uses current as the task to perform the operations on. In pretty much all cases the task decriptor is the same as current, so this wasn't an issue. But there is a case in the ARM

[for-next][PATCH 08/24] arm64: Use ftrace_graph_get_ret_stack() instead of curr_ret_stack

From: "Steven Rostedt (VMware)" The structure of the ret_stack array on the task struct is going to change, and accessing it directly via the curr_ret_stack index will no longer give the ret_stack entry that holds the return address. To access that, architectures must now use

[for-next][PATCH 10/24] seq_buf: Use size_t for len in seq_buf_puts()

From: Michael Ellerman Jann Horn points out that we're using unsigned int for len in seq_buf_puts(), which could potentially overflow if we're passed a UINT_MAX sized string. The rest of the code already uses size_t, so we should also use that in seq_buf_puts() to avoid any issues. Link:

[for-next][PATCH 12/24] tracing: Remove unnecessary hist trigger struct field

From: Tom Zanussi hist_field.var_idx is completely unused, so remove it. Link: http://lkml.kernel.org/r/d4e066c0f509f5f13ad3babc8c33ca6e7ddc439a.1545161087.git.tom.zanu...@linux.intel.com Acked-by: Namhyung Kim Reviewed-by: Masami Hiramatsu Signed-off-by: Tom Zanussi Signed-off-by: Steven

[for-next][PATCH 15/24] tracing: Remove open-coding of hist trigger var_ref management

From: Tom Zanussi Have create_var_ref() manage the hist trigger's var_ref list, rather than having similar code doing it in multiple places. This cleans up the code and makes sure var_refs are always accounted properly. Also, document the var_ref-related functions to make what their purpose

[for-next][PATCH 13/24] tracing: Change strlen to sizeof for hist trigger static strings

From: Tom Zanussi There's no need to use strlen() for static strings when the length is already known, so update trace_events_hist.c with sizeof() for those cases. Link: http://lkml.kernel.org/r/e3e754f2bd18e56eaa8baf79bee619316ebf4cfc.1545161087.git.tom.zanu...@linux.intel.com Acked-by:

[for-next][PATCH 14/24] tracing: Use var_refs[] for hist trigger reference checking

From: Tom Zanussi Since all the variable reference hist_fields are collected into hist_data->var_refs[] array, there's no need to go through all the fields looking for them, or in separate arrays like synth_var_refs[], which will be going away soon anyway. This also allows us to get rid of some

[for-next][PATCH 17/24] tracing: Remove hist trigger synth_var_refs

From: Tom Zanussi All var_refs are now handled uniformly and there's no reason to treat the synth_refs in a special way now, so remove them and associated functions. Link: http://lkml.kernel.org/r/b4d3470526b8f0426dcec125399dad9ad9b8589d.1545161087.git.tom.zanu...@linux.intel.com Acked-by:

[for-next][PATCH 18/24] tracing: Add hist trigger comments for variable-related fields

From: Tom Zanussi Add a few comments to help clarify how variable and variable reference fields are used in the code. Link: http://lkml.kernel.org/r/ea857ce948531d7bec712bbb0f38360aa1d378ec.1545161087.git.tom.zanu...@linux.intel.com Acked-by: Namhyung Kim Reviewed-by: Masami Hiramatsu

Re: [PATCH v1 1/2] soc: qcom: rmtfs-mem: Add class to enable uevents

On Thu, Dec 20, 2018 at 5:19 PM Brian Norris wrote: > > Hi Evan, > > On Mon, Dec 17, 2018 at 04:08:33PM -0800, Evan Green wrote: > > Currently the qcom_rmtfs_memN devices are entirely invisible to the udev > > world. > > Add a class to the rmtfs device so that uevents fire when the device is >

[for-next][PATCH 19/24] tracing: Merge seq_print_sym_short() and seq_print_sym_offset()

From: Rasmus Villemoes These two functions are nearly identical, so we can avoid some code duplication by moving the conditional into a common implementation. Link: http://lkml.kernel.org/r/20181029223542.26175-2-li...@rasmusvillemoes.dk Signed-off-by: Rasmus Villemoes Signed-off-by: Steven

[for-next][PATCH 21/24] tracing: Simplify printfing in seq_print_sym

From: Rasmus Villemoes trace_seq_printf(..., "%s", ...) can be done with trace_seq_puts() instead, avoiding printf overhead. In the second instance, the string we're copying was just created from an snprintf() to a stack buffer, so we might as well do that printf directly. This naturally leads

[for-next][PATCH 23/24] string.h: Add strncmp_prefix() helper macro

From: Steven Rostedt A discussion came up in the trace triggers thread about converting a bunch of: strncmp(str, "const", sizeof("const") - 1) use cases into a helper macro. It started with: strncmp(str, const, sizeof(const) - 1) But then Joe Perches mentioned that if a const is not

[for-next][PATCH 01/24] ftrace: Allow ftrace_replace_code() to be schedulable

From: "Steven Rostedt (VMware)" The function ftrace_replace_code() is the ftrace engine that does the work to modify all the nops into the calls to the function callback in all the functions being traced. The generic version which is normally called from stop machine, but an architecture can

[for-next][PATCH 24/24] tracing: Use strncmp_prefix() helper for histogram code

From: "Steven Rostedt (VMware)" The tracing histogram code contains a lot of instances of the construct: strncmp(str, "const", sizeof("const") - 1) This can be prone to bugs due to typos or bad cut and paste. Use the strncmp_prefix() helper macro instead that removes the need for having two

[for-next][PATCH 05/24] powerpc/frace: Use ftrace_graph_get_ret_stack() instead of curr_ret_stack

From: "Steven Rostedt (VMware)" The structure of the ret_stack array on the task struct is going to change, and accessing it directly via the curr_ret_stack index will no longer give the ret_stack entry that holds the return address. To access that, architectures must now use

[for-next][PATCH 16/24] tracing: Use hist triggers var_ref array to destroy var_refs

From: Tom Zanussi Since every var ref for a trigger has an entry in the var_ref[] array, use that to destroy the var_refs, instead of piecemeal via the field expressions. This allows us to avoid having to keep and treat differently separate lists for the action-related references, which future

[for-next][PATCH 06/24] sparc64: Use ftrace_graph_get_ret_stack() instead of curr_ret_stack

From: "Steven Rostedt (VMware)" The structure of the ret_stack array on the task struct is going to change, and accessing it directly via the curr_ret_stack index will no longer give the ret_stack entry that holds the return address. To access that, architectures must now use

Re: [PATCH 2/2] ARC: show_regs: fix lockdep splat for good

On 12/21/18 5:04 AM, Michal Hocko wrote: >> I presume you are referring to original commit, not my anti-change in ARC >> code, >> which is actually re-enabling it. > > Yes, but you are building on a broken concept I believe. Not sure where this is heading. Broken concept was introduced by

Re: [PATCH] ACPI / tables: Add an ifdef around amlcode and dsdt_amlcode

On Thu, Dec 20, 2018 at 1:57 PM Nathan Chancellor wrote: > > On Thu, Dec 20, 2018 at 12:38:56PM -0700, Nathan Chancellor wrote: > > Clang warns: > > > > drivers/acpi/tables.c:715:14: warning: unused variable 'amlcode' > > [-Wunused-variable] > > static void *amlcode __attribute__

RE: [tip:efi/core] x86/efi: Unmap EFI boot services code/data regions from efi_pgd

> > > For the short term, could we simply make your changes dependent on > > > efi != old_map? That gives us some time to fix the old_map case properly. > > > > Yes, I think we could and it should work but I hesitated to propose it > > because (as you already noted) it's a short term fix and not

Re: [PATCH] i2c: bcm2835: Clear current message and count after a transaction

On 12/21/18 4:11 AM, Paul Kocialkowski wrote: > The driver's interrupt handler checks whether a message is currently > being handled with the curr_msg pointer. When it is NULL, the interrupt > is considered to be unexpected. Similarly, the i2c_start_transfer > routine checks for the remaining

Assalamualaikum My Dear Friend,

Assalamualaikum My Dear Friend, Before I introduce myself, I wish to inform you that this letter is not a hoax mail and I urge you to treat it serious. This letter must come to you as a big surprise, but I believe it is only a day that people meet and become great friends and business

Re: [PATCH v4 04/18] memory: mtk-smi: Use a struct for the platform data for smi-common

On 08/12/2018 09:39, Yong Wu wrote: > Use a struct as the platform special data instead of the enumeration. > > Also there is a minor change that moving the position of > "enum mtk_smi_gen" definition, this is because we expect define > "struct mtk_smi_common_plat" before it is referred. > >

Re: [PATCH v4 03/18] memory: mtk-smi: Use a general config_port interface

On 08/12/2018 09:39, Yong Wu wrote: > The config_port of mt2712 and mt8183 are the same. Use a general > config_port interface instead. > > In addition, in mt2712, larb8 and larb9 are the bdpsys larbs which > are not the normal larb, their register space are different from the > normal one.

Re: [PATCH v4 02/18] iommu/mediatek: Use a struct as the platform data

On 08/12/2018 09:39, Yong Wu wrote: > Use a struct as the platform special data instead of the enumeration. > This is a prepare patch for adding mt8183 iommu support. > > Signed-off-by: Yong Wu > --- Reviewed-by: Matthias Brugger > drivers/iommu/mtk_iommu.c | 24 >

<    1   2   3   4   5   6   7   8   >