On Thu, 6 Dec 2018 13:20:07 +
Will Deacon wrote:
> On Wed, Dec 05, 2018 at 12:48:54PM -0500, Steven Rostedt wrote:
> > 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
Commit 2a54e3259e2a ("staging: mt7621-mmc: Remove #if 0 blocks in sd.c")
does not completely remove an #if 0 block in sd.c. This causes the function
msdc_select_clksrc() which was eariler not compiled, to be compiled.
That causes an error - MSDC_CLKSRC_REG is not defined.
This patch completely rem
*NOT* acked by Markus Oberhumer, original author of the LZO data compression
library and author of the current Linux kernel LZO implementation.
Please see my email reply to the patch series header for more info.
On 2018-11-30 15:26, Dave Rodgman wrote:
> When using zram, we frequently encounter
*NOT* acked by Markus Oberhumer, original author of the LZO data compression
library and author of the current Linux kernel LZO implementation.
Please see my email reply to the patch series header for more info.
On 2018-11-30 15:26, Dave Rodgman wrote:
> From: Matt Sealey
>
> Most compilers sh
On Thu, 6 Dec 2018 15:49:32 +
Will Deacon wrote:
> On Wed, Dec 05, 2018 at 06:47:54PM -0500, Steven Rostedt wrote:
> > From: "Steven Rostedt (VMware)"
> >
> > Functions in the set_graph_notrace no longer subtract FTRACE_NOTRACE_DEPTH
> > from curr_ret_stack, as that is now implemented via t
UBSAN reported those with MegaRAID SAS-3 3108,
[ 77.467308] UBSAN: Undefined behaviour in
drivers/scsi/megaraid/megaraid_sas_fp.c:117:32
[ 77.475402] index 255 is out of range for type 'MR_LD_SPAN_MAP [1]'
[ 77.481677] CPU: 16 PID: 333 Comm: kworker/16:1 Not tainted 4.20.0-rc5+ #1
[ 77.48
Hi Rob,
Thanks for reviewing this.
On Thu, Dec 06, 2018 at 08:47:04AM -0600, Rob Herring wrote:
> On Wed, Nov 14, 2018 at 11:52 PM AKASHI Takahiro
> wrote:
> >
> > Added function, fdt_setprop_reg(), will be used later to handle
> > kexec-specific property in arm64's kexec_file implementation.
>
On Fri, 2018-11-30 at 08:00 +, Jürg Billeter wrote:
> This patch adds a new prctl to kill all descendant processes on exit.
> See commit message for details of the prctl.
>
> This is a replacement of PR_SET_PDEATHSIG_PROC I proposed last year [1].
> In the following discussion, Oleg suggested
Acked-by: Markus F.X.J. Oberhumer
On 2018-11-30 15:26, Dave Rodgman wrote:
> From: Matt Sealey
>
> Enable faster 8-byte copies on arm64.
>
> Link: http://lkml.kernel.org/r/20181127161913.23863-6-dave.rodg...@arm.com
> Signed-off-by: Matt Sealey
> Signed-off-by: Dave Rodgman
> Cc: David S.
On Thu, Dec 06, 2018 at 08:34:09AM +0100, Ingo Molnar wrote:
> I like your '!' idea, but with a further simplification: how about using
> '-/+' differentiation and a single character and a fixed-length message.
>
> The new output will be lines of:
>
> #PF error code: -P -W -U -S -I -K (0x00)
>
Acked-by: Markus F.X.J. Oberhumer
On 2018-11-30 15:26, Dave Rodgman wrote:
> From: Matt Sealey
>
> LZO leaves some performance on the table by not realising that arm64 can
> optimize count-trailing-zeros bit operations.
>
> Add CONFIG_ARM64 to the checked definitions alongside CONFIG_X86_64
[+ Ingo and Mark]
On Tue, Dec 04, 2018 at 10:47:13PM +0100, Anders Roxell wrote:
> Some distibutions and build systems doesn't include 'fold' from
> coreutils default.
>
> .../scripts/atomic/atomic-tbl.sh: line 183: fold: command not found
>
> Rework to use 'grep' instead of 'fold' to use a depe
I think that LZO_USE_CTZ64 should only be defined for ARM64 and
not for 32-bit ARM.
On 2018-11-30 15:26, Dave Rodgman wrote:
> From: Matt Sealey
>
> ARMv6 Thumb state introduced an RBIT instruction which, combined with CLZ
> as present in ARMv5, introduces an extremely fast path for counting
>
On 06/12/2018 15:11, Tony Battersby wrote:
On 12/6/18 4:25 AM, Krzysztof Kozlowski wrote:
On Thu, 6 Dec 2018 at 02:31, Tony Lindgren wrote:
Hi,
Looks like with commit 26abe88e830d ("mm/dmapool.c: improve scalability
of dma_pool_free()") I'm now getting spammed with lots of "(bad vaddr)"
on at
Am Donnerstag, den 06.12.2018, 09:45 -0600 schrieb Robert Hancock:
> On 2018-12-06 2:10 a.m., Baruch Siach wrote:
> > Hi Andrey,
> >
> > Adding Robert Hancock who reported[1] on a PCIe MSI issue with i.MX6.
> >
> > Andrey Smirnov writes:
> >
> > > Building a kernel with CONFIG_PCI_IMX6=y, but CO
On Sun, 2018-11-25 at 10:04 +, Jonathan Cameron wrote:
> On Fri, 23 Nov 2018 15:24:10 +0100
> Philippe Schenker wrote:
>
> > From: Stefan Agner
> >
> > This adds the devicetree bindings for the STMPE ADC.
> >
> > Signed-off-by: Stefan Agner
> > Signed-off-by: Max Krummenacher
> > Signed-
On Wed, Dec 05, 2018 at 06:47:54PM -0500, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)"
>
> Functions in the set_graph_notrace no longer subtract FTRACE_NOTRACE_DEPTH
> from curr_ret_stack, as that is now implemented via the trace_recursion
> flags. Access to curr_ret_stack no longer ne
On Wed, 2018-12-05 at 17:13 +, Vineet Gupta wrote:
> On 12/5/18 9:06 AM, Eugeniy Paltsev wrote:
> > Fix description comment as this code doesn't belong only to
> > ARC700 anymore.
> >
> > Also while I'm at it, use SPDX License Identifier.
> >
> > Signed-off-by: Eugeniy Paltsev
>
> Maybe squ
Acked-by: Markus F.X.J. Oberhumer
On 2018-11-30 15:26, Dave Rodgman wrote:
> Modify the ifdefs in lzodefs.h to be more consistent with normal kernel
> macros (e.g., change __aarch64__ to CONFIG_ARM64).
>
> Signed-off-by: Dave Rodgman
> Cc: Herbert Xu
> Cc: David S. Miller
> Cc: Nitin Gupta
Hi All,
Please let me know if anyone has any issue with this patch.
Regards,
Bharat
> As per Figure 6-3 in PCIe r4.0, sec 6.2.6, ERR_ messages will be forwarded
> from the secondary interface to the primary interface, if the SERR# Enable
> bit in the Bridge Control register is set.
> Currently PC
Hi All,
Please let me know if anyone has any issue with this patch series.
Regards,
Bharat
> -Original Message-
> From: Bharat Kumar Gogada [mailto:bharat.kumar.gog...@xilinx.com]
> Sent: Wednesday, November 14, 2018 8:18 PM
> To: linux-kernel@vger.kernel.org
> Cc: bhelg...@google.com; R
On 2018-11-30 15:26, Dave Rodgman wrote:
> This patch series introduces performance improvements for lzo.
>
> The previous version of this patchset is here:
> https://lkml.org/lkml/2018/11/30/807
>
> This version of the patchset fixes a maybe-used-uninitialized warning
> (although the previous ve
From: Jérôme Glisse
The debugfs take reference on fence without dropping them. Also the
rcu section are not well balance. Fix all that ...
Changed since v1:
- moved fobj logic around to be rcu safe
Signed-off-by: Jérôme Glisse
Cc: Christian König
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: l
On Wed, Dec 05, 2018 at 06:20:50PM +, Robin Murphy wrote:
> Is there any good reason to let .add_device/.remove_device be optional
> still? Everyone's implemented them for a while now, and on a practical level
> I don't really see how else we could expect devices to be taken in and out
> of the
> "Jean" == Jean Delvare writes:
Hi,
>> I get that - but it changes the content of sysfs entries, breaking real
>> systems - E.G. a user space ABI regression.
> I know it's very convenient to play the "user-space ABI regression"
> card whenever you want a change reverted.
Sorry, I am r
On Thu, Dec 06, 2018 at 10:35:28AM -0500, Vince Weaver wrote:
> On Wed, 5 Dec 2018, Jiri Olsa wrote:
>
> > On Wed, Dec 05, 2018 at 12:11:19PM -0500, Vince Weaver wrote:
> > > On Wed, 5 Dec 2018, Jiri Olsa wrote:
> > >
> > > > On Wed, Dec 05, 2018 at 01:45:38PM +0100, Jiri Olsa wrote:
> > > > > On
On Thu, Dec 06, 2018 at 08:08:24AM +1100, NeilBrown wrote:
> On Wed, Dec 05 2018, Nishad Kamdar wrote:
>
> > The below patch
> > https://lore.kernel.org/patchwork/patch/995533/
> > does not completely remove an #if 0 block in sd.c.
>
> Standard practice is to identify patches by their commit id.
On Thu, Dec 06, 2018 at 01:55:20PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Dec 04, 2018 at 06:25:00PM +0100, Joerg Roedel wrote:
> > Cc: Greg Kroah-Hartman
> > Signed-off-by: Joerg Roedel
> > ---
> > include/linux/device.h | 10 ++
> > 1 file changed, 10 insertions(+)
>
> Acked-by: G
On 12/06/2018 03:41 AM, Peter Zijlstra wrote:
> On Wed, Dec 05, 2018 at 02:49:28PM -0500, Waiman Long wrote:
>> Since conditional STIBP is the default, it should be treated as
>> the likely case. Changes the use of static_branch_unlikely() to
>> static_branch_likely() for switch_to_cond_stibp.
> So
On 06/12/2018 14:17, Johannes Thumshirn wrote:
On 06/12/2018 14:34, John Garry wrote:
[...]
+static void hisi_sas_dma_unmap(struct hisi_hba *hisi_hba,
+ struct sas_task *task, int n_elem,
+ int n_elem_req, int n_elem_resp)
+{
+ stru
On 6.12.2018 14:59, Uwe Kleine-König wrote:
> On Thu, Dec 06, 2018 at 01:41:31PM +, Vokáč Michal wrote:
>>
>> +static int imx_pwm_init_pinctrl_info(struct imx_chip *imx_chip,
>> +struct platform_device *pdev)
>
> Please indent the follow up line to the opening parenthesis.
Meh,
On Thu, Dec 06, 2018 at 12:32:47PM +, Kieran Bingham wrote:
> On 04/12/2018 20:47, Luis Chamberlain wrote:
> > On Mon, Dec 03, 2018 at 03:48:15PM -0800, Brendan Higgins wrote:
> >> On Thu, Nov 29, 2018 at 5:54 AM Kieran Bingham
> >> wrote:
> >>>
> >>> Hi Brendan,
> >>>
> >>> Thanks again for t
Avoid expensive indirect calls in the fast path DMA mapping
operations by directly calling the dma_direct_* ops if we are using
the directly mapped DMA operations.
Signed-off-by: Christoph Hellwig
---
include/linux/dma-direct.h | 17 -
include/linux/dma-mapping.h | 138
Hi all,
a while ago Jesper reported major performance regressions due to the
spectre v2 mitigations in his XDP forwarding workloads. A large part
of that is due to the DMA mapping API indirect calls.
It turns out that the most common implementation of the DMA API is the
direct mapping case, and
Le 05/12/2018 à 20:16, Rob Herring a écrit :
Remove directly accessing device_type property and use the
of_node_is_type accessor instead. While not using it here, this is
part of eventually removing the struct device_node.type pointer.
Cc: Frederic Barrat
Cc: Arnd Bergmann
Cc: Greg Kroah-Ha
On Wed, Dec 05, 2018 at 05:17:29PM +, Robin Murphy wrote:
> On 04/12/2018 17:24, Joerg Roedel wrote:
> Nice, we can also clean up a whole load of vague iommu_present() usage and
> even one or two odd iommu_get_domain_for_dev() calls once we have this.
Right, I didn't think of that yet, but it
On Wed, 5 Dec 2018, Jiri Olsa wrote:
> On Wed, Dec 05, 2018 at 12:11:19PM -0500, Vince Weaver wrote:
> > On Wed, 5 Dec 2018, Jiri Olsa wrote:
> >
> > > On Wed, Dec 05, 2018 at 01:45:38PM +0100, Jiri Olsa wrote:
> > > > On Tue, Dec 04, 2018 at 10:54:55AM -0500, Vince Weaver wrote:
> > > > > Hello,
On Thu, Dec 06, 2018 at 06:53:06PM +0530, Jagan Teki wrote:
> Some camera modules have the SoC feeding a master clock to the sensor
> instead of having a standalone crystal. This clock signal is generated
> from the clock control unit and output from the CSI MCLK function of
> pin PE1.
>
> Add a p
Hi Robin,
On Wed, Dec 05, 2018 at 05:17:54PM +, Robin Murphy wrote:
> FWIW, this check (and its ACPI equivalent in patch #3) is specifically
> asking "has .add_device() already been called?", rather than the more
> general "is this device managed by an IOMMU?" (to which the exact answer at
> t
Hi Hans,
On 11/20/18 4:54 AM, Hans Verkuil wrote:
On 11/02/2018 01:31 AM, sh...@kernel.org wrote:
From: Shuah Khan
Change ALSA driver to use Media Controller API to share media resources
with DVB, and V4L2 drivers on a AU0828 media device.
Media Controller specific initialization is done aft
On Thu, Dec 06, 2018 at 06:53:05PM +0530, Jagan Teki wrote:
> Allwinner A64 CSI controller has similar features as like in
> H3, So add support for A64 via H3 fallback.
>
> Also updated CSI_SCLK to use 300MHz via assigned-clocks, since
> the default clock 600MHz seems unable to drive the sensor(ov
On 11/19/18 1:59 AM, Pavel Machek wrote:
On Thu 2018-11-01 18:31:30, sh...@kernel.org wrote:
From: Shuah Khan
Media Device Allocator API to allows multiple drivers share a media device.
Using this API, drivers can allocate a media device with the shared struct
device as the key. Once the media
Hi Hans,
On 11/20/18 4:22 AM, Hans Verkuil wrote:
On 11/02/2018 01:31 AM, sh...@kernel.org wrote:
From: Shuah Khan
Move ALSA MEDIA_INTF_T* interface types back into __KERNEL__ scope
to get ready for adding ALSA support to the media controller.
Signed-off-by: Shuah Khan
---
include/uapi/li
Hi Hans,
On 11/20/18 4:20 AM, Hans Verkuil wrote:
On 11/02/2018 01:31 AM, sh...@kernel.org wrote:
From: Shuah Khan
Media Device Allocator API to allows multiple drivers share a media device.
Using this API, drivers can allocate a media device with the shared struct
device as the key. Once the
Fix compilation error.
Signed-off-by: David Abdurachmanov
---
arch/riscv/kernel/ptrace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/riscv/kernel/ptrace.c b/arch/riscv/kernel/ptrace.c
index c1b51539c3e2..2fd9ec48106b 100644
--- a/arch/riscv/kernel/ptrace.c
+++ b/arch
Depends on audit patch:
http://lists.infradead.org/pipermail/linux-riscv/2018-October/001931.html
audit patch is already merged into linux-next.
This simply fixes compilation error in do_syscall_trace_exit() and
enables syscalls tracepoints.
David Abdurachmanov (2):
riscv: fix trace_sys_exit h
I looked into Documentation/trace/ftrace-design.rst and, I think,
we check all the boxes needed for HAVE_SYSCALL_TRACEPOINTS.
Signed-off-by: David Abdurachmanov
---
arch/riscv/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index a4f48f757204..
On Thu, Dec 6, 2018 at 3:57 PM Greg Kroah-Hartman
wrote:
>
> On Thu, Nov 29, 2018 at 06:08:44PM +, Colin King wrote:
> > From: Colin Ian King
> >
> > Currently the node name is being formatting into a temporary string
> > node_name, however, kobject_init_and_add allows one to format up
> > a
On 12/6/18 4:25 AM, Krzysztof Kozlowski wrote:
> On Thu, 6 Dec 2018 at 02:31, Tony Lindgren wrote:
>> Hi,
>>
>> Looks like with commit 26abe88e830d ("mm/dmapool.c: improve scalability
>> of dma_pool_free()") I'm now getting spammed with lots of "(bad vaddr)"
>> on at least omap4 pandaboard, see be
On Thu, Dec 06, 2018 at 08:09:28AM +, Koenig, Christian wrote:
> Am 06.12.18 um 02:41 schrieb jgli...@redhat.com:
> > From: Jérôme Glisse
> >
> > The debugfs take reference on fence without dropping them. Also the
> > rcu section are not well balance. Fix all that ...
> >
> > Signed-off-by: Jé
On 12/5/18 8:32 PM, Jianchao Wang wrote:
> It is not necessary to issue request directly with bypass 'true'
> in blk_mq_sched_insert_requests and handle the non-issued requests
> itself. Just set bypass to 'false' and let blk_mq_try_issue_directly
> handle them totally. Remove the blk_rq_can_direct
The spinlock is only used within the irq handler so it does not
seem very useful.
Signed-off-by: Jerome Brunet
---
drivers/mmc/host/meson-gx-mmc.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/mmc/host/meson-gx-mmc.c b/drivers/mmc/host/meson-gx-mmc.c
index fcb5d693c897..5cc31
Align the default Core and Tx phase with the SoC vendor tree.
Even if the Tx phase is different from what the documentation
recommends, it seems to provide better results.
Signed-off-by: Jerome Brunet
---
drivers/mmc/host/meson-gx-mmc.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-
On errors, if we don't stop the descriptor chain, it may continue to
run and raise IRQ after we have called mmc_request_done(). This is bad
because we won't be able to get cmd anymore and properly deal with the
IRQ.
This patch makes sure the descriptor chain is stopped before
calling mmc_request_d
With some eMMC devices, there is still issues with the new phase
settings. Enabling signal resampling seems to solve the problem
for these.
Signed-off-by: Jerome Brunet
---
drivers/mmc/host/meson-gx-mmc.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/mm
The goal of the patchset was mainly to address the following warning:
WARNING: CPU: 0 PID: 0 at /usr/src/kernel/drivers/mmc/host/meson-gx-mmc.c:1025
meson_mmc_irq+0xc0/0x1e0
Modules linked in: crc32_ce crct10dif_ce ipv6 overlay
CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW 4.19.1 #1
H
On 12/5/18 9:55 AM, Stephen Boyd wrote:
> Quoting Dinh Nguyen (2018-12-05 07:17:41)
>> Hi Stephen,
>>
>> On 12/5/18 1:17 AM, Stephen Boyd wrote:
>>> (Adding Dinh's korg email)
>>>
>>> I also wonder if this driver is even used anymore or maybe we can delete
>>> it?
>>>
>>
>> The armv7 SoCFPGA pla
From: Ludovic Barre
On cmd12 (STOP_TRANSMISSION), STM32 sdmmc variant needs to set
cmdstop bit in command register. The CPSM ("Command Path State Machine")
treats the command as a Stop Transmission command and signals
abort to the DPSM ("Data Path State Machine").
Signed-off-by: Ludovic Barre
-
From: Ludovic Barre
The current approach with sending a CMD12 (STOP_TRANSMISSION) to
complete a data transfer request, either because of using the open
ended transmission type or because of receiving an error during a data
transfer, isn't sufficient for the STM32 sdmmc variant.
More precisely, f
From: Ludovic Barre
This patch series adds variant property to:
-Set cmdstop bit on STOP_TRANSMISSION command.
-On command or data error, send a stop command.
to clear DPSM if it's yet activated.
change v3:
-Move the cmdstop bit in separate patch.
-Use Ulf re-wording for patch 2/2.
-Move specifi
Currently the 'stackleak_cleanup' pass deleting a CALL insn is executed
after the 'reload' pass. That allows gcc to do some weird optimization in
function prologues and epilogues, which are generated later [1].
Let's avoid that by registering the 'stackleak_cleanup' pass before
the '*free_cfg' pas
On 03.12.2018 21:25, Alexander Popov wrote:
> But I think it's better to register the 'stackleak_cleanup' pass just one pass
> earlier -- before the '*free_cfg' pass. I'll double check it for different
> versions of gcc on all supported architectures and return with a new patch.
I've tested this i
On Fri, Nov 30, 2018 at 05:34:29PM +, Will Deacon wrote:
> Hi all,
>
> This is version two of the patches I originally posted here:
>
>
> http://lkml.kernel.org/r/1543347902-21170-1-git-send-email-will.dea...@arm.com
>
> The only change since v1 is that __preempt_count_dec_and_test() now
Hi Dan,
On 2018-12-06 15:52, Dan Carpenter wrote:
> Hi Marek,
>
> I'm surprised you don't get deadlocks when you apply this patch.
Why should I get it? It is just a revert to the state before applying
the mentioned incorrect patch.
> On Wed, Nov 21, 2018 at 04:45:04PM +0100, Marek Szyprowski wro
On Wed, Dec 05, 2018 at 12:27:45PM +0100, Peter Rajnoha wrote:
> We can use extended format when writing /sys/.../uevent files to
> generate synthetic uevents, introduced with commit f36776fafbaa
> ("kobject: support passing in variables for synthetic uevents").
>
> Before using this extended form
On Thu, Dec 06, 2018 at 09:43:46AM +, Bryan O'Donoghue wrote:
> On 05/12/2018 21:00, Sicilia Cristian wrote:
> > It doesn't change the result string
>
> So why do it then ?
Because it is easier to read this way and odds are checkpatch is
happier.
thanks,
greg k-h
Dear Minas,
On 2018-12-04 13:34, Minas Harutyunyan wrote:
> On 11/23/2018 6:43 PM, Dan Carpenter wrote:
>> Ugh... We also had a long thread about the v2 patch but it turns out
>> the list was not CC'd. I should have checked for that.
>>
>> You have to pass a flag to say if the caller holds the l
Hi Yueyi,
yes, my LZO patch works for all cases.
The reason behind the issue in the first place is that if KASLR
includes the very last page 0xf000 then we do not have a
valid C "pointer to an object" anymore because of address wraparound.
Unrelated to my patch I'd argue that KASLR s
On Wed, Dec 05, 2018 at 08:28:05PM +0900, Masahiro Yamada wrote:
> Some time ago, Sam pointed out a certain degree of overwrap between
> generic-y and mandatory-y. (https://lkml.org/lkml/2017/7/10/121)
>
> I a bit tweaked the meaning of mandatory-y; now it defines the minimum
> set of ASM headers
Christian Brauner writes:
> The kill() syscall operates on process identifiers (pid). After a process
> has exited its pid can be reused by another process. If a caller sends a
> signal to a reused pid it will end up signaling the wrong process. This
> issue has often surfaced and there has been
The patch adds support for SECCOMP and SECCOMP_FILTER (BPF).
Signed-off-by: David Abdurachmanov
---
arch/riscv/Kconfig | 14 ++
arch/riscv/include/asm/thread_info.h | 5 -
arch/riscv/kernel/entry.S| 27 +--
arch/riscv/kernel/
Testing with libseccomp master branch revealed that testcases with
filters on syscall arguments were failing due to wrong values. Seccomp
uses syscall_get_argumentsi() to copy syscall arguments, and there is a
bug in pointer arithmetics in memcpy() call.
Two alternative implementation were tested:
This was originally tested on 4.19 kernel with Fedora 29/RISCV.
Depends on audit patches (already in linux-next).
The patches are on top of linux-next next-20181206 tag.
Validation was done using libseccomp (at
1e64feb5f1a9ea02687228e3073e8b784a04ce46, which is master at this
date). See PR
I've picked this up for the dma-mapping for-next tree.
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Steven Rostedt (VMware)
commit 5cf99a0f3161bc3ae2391269d134d6bf7e26f00e upstream.
The tracefs file set_graph_function is used to only function graph functions
that are listed in that file (or
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Michael Guralnik
commit db7a691a1551a748cb92d9c89c6b190ea87e28d5 upstream.
If the firmware reports a connection width that is not 1x, 4x, 8x or 12x
it causes the driver to fail during initiali
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Sergio Correia
commit 23a336b34258aba3b50ea6863cca4e81b5ef6384 upstream.
When drm_new_set_master() fails, set is_master to 0, to prevent a
possible NULL pointer deref.
Here is a problematic f
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Andrea Arcangeli
commit 9e368259ad988356c4c95150fafd1a06af095d98 upstream.
Patch series "userfaultfd shmem updates".
Jann found two bugs in the userfaultfd shmem MAP_SHARED backend: the
lack
Looks like generic-y is mostly going away anyway, so I'm going to skip
this to avoid conflicts with the kbuild tree.
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Laura Abbott
commit 2dd453168643d9475028cd867c57e65956a0f7f9 upstream.
There's an error when compiled with restrict:
drivers/tty/serial/kgdboc.c: In function ‘configure_kgdboc’:
drivers/tty/s
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Wei Wang
commit 30510387a5e45bfcf8190e03ec7aa15b295828e2 upstream.
There is a race condition when accessing kvm->arch.apic_access_page_done.
Due to it, x86_set_memory_region will fail when cre
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Linus Torvalds
commit 38c7b224ce22c25fed04007839edf974bd13439d upstream.
New versions of gcc reasonably warn about the odd pattern of
strncpy(p, q, strlen(q));
which really doesn't m
Kees Cook writes:
> On Sat, Dec 1, 2018 at 7:04 AM Eric W. Biederman
> wrote:
>>
>> Kees Cook writes:
>>
>> > On Tue, Nov 27, 2018 at 8:44 PM Eric W. Biederman
>> > wrote:
>> >>
>> >> Kees Cook writes:
>> >>
>> >> > On Tue, Nov 27, 2018 at 4:38 PM, Kees Cook
>> >> > wrote:
>> >> >> On Tue
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Masami Hiramatsu
commit 874bfc6e5422d2421f7e4d5ea318d30e91679dfe upstream.
Since commit 4378a7d4be30 ("arm64: implement syscall wrappers")
introduced "__arm64_" prefix to all syscall wrapper s
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Noah Westervelt
commit ad33429cd02565c28404bb16ae7a4c2bdfda6626 upstream.
Add ELAN061E to the ACPI table to support Elan touchpad found in Lenovo
IdeaPad 330-15ARR.
Signed-off-by: Noah Wester
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Christian Hoff
commit d55bda1b3e7c5a87f10da54fdda866a9a9cef30b upstream.
"of_get_named_gpio()" returns a negative error value if it fails
and drivers should check for this. This missing check
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Arnd Bergmann
commit 2cf2f0d5b91fd1b06a6ae260462fc7945ea84add upstream.
gcc discovered that the memcpy() arguments in kdbnearsym() overlap, so
we should really use memmove(), which is defined
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Xiongfeng Wang
commit 321cb0308a9e76841394b4bbab6a1107cfedbae0 upstream.
gcc-8 reports many -Wpacked-not-aligned warnings. The below are some
examples.
./include/linux/ceph/msgr.h:67:1: warni
On Thu, Dec 6, 2018 at 2:49 PM Charles Keepax
wrote:
> On Thu, Dec 06, 2018 at 02:27:03PM +0100, Marek Szyprowski wrote:
> > On 2018-12-06 13:43, Linus Walleij wrote:
> > One more thing - if I got everything right, gpiod_put() in
> > *regulator_register() error path has to be removed also in
> > w
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Guoqing Jiang
commit 29e270fc32192e7729057963ae7120663856c93e upstream.
Got below warning with gcc 8.2 compiler.
net/tipc/topsrv.c: In function ‘tipc_topsrv_start’:
net/tipc/topsrv.c:660:2: w
4.19-stable review patch. If anyone has any objections, please let me know.
--
From: Qu Wenruo
commit 10950929e994c5ecee149ff0873388d3c98f12b5 upstream.
[BUG]
A completely valid btrfs will refuse to mount, with error message like:
BTRFS critical (device sdb2): corrupt leaf:
On 2018-12-06 1:23 p.m., Joe Perches wrote:
> On Thu, 2018-12-06 at 12:52 +0100, Michel Dänzer wrote:
>> In contrast to the 2b case, the pr_debug output isn't visible by default
>> with 1b, so the latter doesn't fit "always produce output" either.
>
> I think you are mistaken here.
Still puzzled
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Stephen Rothwell
commit 217c3e0196758662aa0429863b09d1c13da1c5d6 upstream.
They are too noisy
Signed-off-by: Stephen Rothwell
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Mathias Kresin
commit 7d35baa4e9ec4b717bc0e58a39cdb6a1c50f5465 upstream.
In case the nd_sd group is set to the sd-card function, Pins 45 + 46 are
configured as GPIOs. If they are blocked by th
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Guenter Roeck
commit 77d2a24b6107bd9b3bf2403a65c1428a9da83dd0 upstream.
gcc 8.1.0 complains:
lib/kobject.c:128:3: warning:
'strncpy' output truncated before terminating nul copying as
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Arnd Bergmann
commit 67a3b63a54cbe18944191f43d644686731cf30c7 upstream.
gcc-8 points out a condition that almost certainly doesn't
do what the author had in mind:
drivers/gpu/drm/gma500/mdfld
I've pulled this into the dma-mapping for-next tree, with the suggestion
from Robin that improves bisectability, and two unused variables found
by the build bot.
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Takashi Iwai
commit d6b340d7cb33c816ef4abe8143764ec5ab14a5cc upstream.
The meddlesome gcc warns about the possible shortname string in
trident driver code:
sound/pci/trident/trident.c: In fu
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Lyude Paul
commit 9df39bedbf292680655c6a947c77d6562c693d4a upstream.
Noticed the other day the trackpoint felt different on my P50, then
realized it was because rmi4 wasn't loading for this ma
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Sergio Correia
commit 23a336b34258aba3b50ea6863cca4e81b5ef6384 upstream.
When drm_new_set_master() fails, set is_master to 0, to prevent a
possible NULL pointer deref.
Here is a problematic f
801 - 900 of 1420 matches
Mail list logo
