HELLO

-- Hello Dear Am a dying woman here in the hospital, i was diagnose as a cancer patient 2 years ago. I am from (Zarqa) Jordan, a business woman dealing with Gold Exportation. I have a charitable and unfufilment project that am about to handover to you, if you are interested please reply

HELLO

-- Hello Dear Am a dying woman here in the hospital, i was diagnose as a cancer patient 2 years ago. I am from (Zarqa) Jordan, a business woman dealing with Gold Exportation. I have a charitable and unfufilment project that am about to handover to you, if you are interested please reply

Re: [PATCH v1] arm: dts: mt7623: add PCIe related nodes

Hi Matthias, Just a gentle ping on this patch. Thanks On Wed, 2018-02-14 at 11:27 +0800, Ryder Lee (李庚諺) wrote: > This patch adds some device nodes for the PCIe function block and updates > related pinmux. > > Moreover, we add interrupt-map properties in both parent and children as > the chip

Re: [PATCH v1] arm: dts: mt7623: add PCIe related nodes

Hi Matthias, Just a gentle ping on this patch. Thanks On Wed, 2018-02-14 at 11:27 +0800, Ryder Lee (李庚諺) wrote: > This patch adds some device nodes for the PCIe function block and updates > related pinmux. > > Moreover, we add interrupt-map properties in both parent and children as > the chip

Re: [PATCH 4.14 095/140] bcache: fix crashes in duplicate cache device register

[linux-kernel to bcc, moving back to bcache list] On Tue, Mar 13, 2018 at 10:26:33AM -0700, Michael Lyle wrote: > Though note you're still not safe from -that-. If there's duplicate > UUIDs around because you've duplicated devices, there's just no sane > way to tell which is the "right one" to

Re: [PATCH 4.14 095/140] bcache: fix crashes in duplicate cache device register

[linux-kernel to bcc, moving back to bcache list] On Tue, Mar 13, 2018 at 10:26:33AM -0700, Michael Lyle wrote: > Though note you're still not safe from -that-. If there's duplicate > UUIDs around because you've duplicated devices, there's just no sane > way to tell which is the "right one" to

Re: [PATCH] drivers: net: wireless: ath: ath9: dfs: remove VLA usage

On Sun, Mar 11, 2018 at 12:12 AM, Kees Cook wrote: > > The problem is that it's not a "constant expression", so the compiler > frontend still yells about it under -Wvla. I would characterize this > mainly as a fix for "accidental VLA" or "misdetected VLA" or something >

Re: [PATCH] drivers: net: wireless: ath: ath9: dfs: remove VLA usage

On Sun, Mar 11, 2018 at 12:12 AM, Kees Cook wrote: > > The problem is that it's not a "constant expression", so the compiler > frontend still yells about it under -Wvla. I would characterize this > mainly as a fix for "accidental VLA" or "misdetected VLA" or something > like that. AIUI, there

Re: [PATCH 00/11] RISC-V: Resolve the issue of loadable module on 64-bit

2018-03-14 5:30 GMT+08:00 Shea Levy : > Hi Palmer, > > Palmer Dabbelt writes: > >> On Tue, 13 Mar 2018 01:35:05 PDT (-0700), z...@andestech.com wrote: >>> These patches resolve the some issues of loadable module. >>> - symbol out of ranges >>> - unknown

Re: [PATCH 00/11] RISC-V: Resolve the issue of loadable module on 64-bit

2018-03-14 5:30 GMT+08:00 Shea Levy : > Hi Palmer, > > Palmer Dabbelt writes: > >> On Tue, 13 Mar 2018 01:35:05 PDT (-0700), z...@andestech.com wrote: >>> These patches resolve the some issues of loadable module. >>> - symbol out of ranges >>> - unknown relocation types >>> >>> The reference

Re: [PATCH v2] PM / wakeup: use seq_open() to show wakeup stats

Hi, Andy 2018-03-14 0:39 GMT+08:00 Andy Shevchenko : > On Mon, Mar 5, 2018 at 10:47 AM, Ganesh Mahendran > wrote: >> single_open() interface requires that the whole output must >> fit into a single buffer. This will lead to timeout when >>

Re: [PATCH v2] PM / wakeup: use seq_open() to show wakeup stats

Hi, Andy 2018-03-14 0:39 GMT+08:00 Andy Shevchenko : > On Mon, Mar 5, 2018 at 10:47 AM, Ganesh Mahendran > wrote: >> single_open() interface requires that the whole output must >> fit into a single buffer. This will lead to timeout when >> system memory is not in a good situation. >> >> This

[PATCH v2] arm: ubsan: select ARCH_HAS_UBSAN_SANITIZE_ALL

To enable UBSAN on arm, ARCH_HAS_UBSAN_SANITIZE_ALL is needed to be selected. Basic test has passed on Raspberry Pi2, Raspbian jessi lite with CONFIG_UBSAN_SANITIZE_ALL, CONFIG_UBSAN_NULL. Used compiler is gcc 5.5.0 in [2] (2017.10). It would be a resend patch for [1] from Seung-Woo Kim. There

[PATCH v2] arm: ubsan: select ARCH_HAS_UBSAN_SANITIZE_ALL

To enable UBSAN on arm, ARCH_HAS_UBSAN_SANITIZE_ALL is needed to be selected. Basic test has passed on Raspberry Pi2, Raspbian jessi lite with CONFIG_UBSAN_SANITIZE_ALL, CONFIG_UBSAN_NULL. Used compiler is gcc 5.5.0 in [2] (2017.10). It would be a resend patch for [1] from Seung-Woo Kim. There

RE: Dell Inc. XPS 13 9343/0TM99H fails to boot v4.16-rc5

> -Original Message- > From: Darren Hart [mailto:dvh...@infradead.org] > Sent: Wednesday, March 14, 2018 5:43 AM > To: Limonciello, Mario > Cc: li...@dominikbrodowski.net; platform-driver-...@vger.kernel.org; linux- > ker...@vger.kernel.org > Subject: Re: Dell

RE: Dell Inc. XPS 13 9343/0TM99H fails to boot v4.16-rc5

> -Original Message- > From: Darren Hart [mailto:dvh...@infradead.org] > Sent: Wednesday, March 14, 2018 5:43 AM > To: Limonciello, Mario > Cc: li...@dominikbrodowski.net; platform-driver-...@vger.kernel.org; linux- > ker...@vger.kernel.org > Subject: Re: Dell Inc. XPS 13 9343/0TM99H

Re: [PATCH v4] cpufreq: schedutil: rate limits for SCHED_DEADLINE

On Tue, Mar 13, 2018 at 4:15 AM, Viresh Kumar wrote: > On 13-03-18, 11:35, Claudio Scordino wrote: >> When the SCHED_DEADLINE scheduling class increases the CPU utilization, >> we should not wait for the rate limit, otherwise we may miss some >> deadline. >> >> Tests

Re: [PATCH v4] cpufreq: schedutil: rate limits for SCHED_DEADLINE

On Tue, Mar 13, 2018 at 4:15 AM, Viresh Kumar wrote: > On 13-03-18, 11:35, Claudio Scordino wrote: >> When the SCHED_DEADLINE scheduling class increases the CPU utilization, >> we should not wait for the rate limit, otherwise we may miss some >> deadline. >> >> Tests using rt-app on Exynos5422

Re: [PATCH] drivers: net: wireless: ath: ath9: dfs: remove VLA usage

> I don't think the difference between C and C++ const pointer > conversions I mean I don't think the difference between them was intended.

Re: [PATCH] drivers: net: wireless: ath: ath9: dfs: remove VLA usage

> I don't think the difference between C and C++ const pointer > conversions I mean I don't think the difference between them was intended.

Re: kernel BUG at mm/khugepaged.c:533 on 4.15.3

On 02/22/2018 09:33 AM, Laura Abbott wrote: On 02/21/2018 01:14 AM, Kirill A. Shutemov wrote: On Mon, Feb 19, 2018 at 10:51:01AM -0800, Laura Abbott wrote: Hi, Fedora got a bug report of a BUG with 4.15.3: (https://bugzilla.redhat.com/show_bug.cgi?id=1546709) Is it new to v4.15 kernel? I

Re: kernel BUG at mm/khugepaged.c:533 on 4.15.3

On 02/22/2018 09:33 AM, Laura Abbott wrote: On 02/21/2018 01:14 AM, Kirill A. Shutemov wrote: On Mon, Feb 19, 2018 at 10:51:01AM -0800, Laura Abbott wrote: Hi, Fedora got a bug report of a BUG with 4.15.3: (https://bugzilla.redhat.com/show_bug.cgi?id=1546709) Is it new to v4.15 kernel? I

Re: [PATCH] drivers: net: wireless: ath: ath9: dfs: remove VLA usage

No, it's undefined behavior to write to a const variable. The `static` and `const` on the variable both change the code generation in the real world as permitted / encouraged by the standard. It's placed in read-only memory. Trying to write to it will break. It's not "implemented defined" to write

Re: [PATCH] drivers: net: wireless: ath: ath9: dfs: remove VLA usage

No, it's undefined behavior to write to a const variable. The `static` and `const` on the variable both change the code generation in the real world as permitted / encouraged by the standard. It's placed in read-only memory. Trying to write to it will break. It's not "implemented defined" to write

Re: [PATCH 4/4] gpio: Remove VLA from stmpe driver

On 03/13/2018 05:18 PM, Laura Abbott wrote: On 03/13/2018 02:13 AM, Phil Reid wrote: On 10/03/2018 08:10, Laura Abbott wrote: The new challenge is to remove VLAs from the kernel (see https://lkml.org/lkml/2018/3/7/621) This patch replaces a VLA with an appropriate call to kmalloc_array.

Re: [PATCH 4/4] gpio: Remove VLA from stmpe driver

On 03/13/2018 05:18 PM, Laura Abbott wrote: On 03/13/2018 02:13 AM, Phil Reid wrote: On 10/03/2018 08:10, Laura Abbott wrote: The new challenge is to remove VLAs from the kernel (see https://lkml.org/lkml/2018/3/7/621) This patch replaces a VLA with an appropriate call to kmalloc_array.

Re: [PATCH] media: vb2: unify calling of set_page_dirty_lock

Le mardi 13 mars 2018 à 20:44 -0400, Nicolas Dufresne a écrit : > Le mercredi 18 octobre 2017 à 11:34 +0300, Stanimir Varbanov a écrit > : > > > > On 10/17/2017 05:19 PM, Nicolas Dufresne wrote: > > > Le mardi 17 octobre 2017 à 13:14 +0300, Sakari Ailus a écrit : > > > > On Sun, Oct 15, 2017 at

Re: [PATCH] media: vb2: unify calling of set_page_dirty_lock

Le mardi 13 mars 2018 à 20:44 -0400, Nicolas Dufresne a écrit : > Le mercredi 18 octobre 2017 à 11:34 +0300, Stanimir Varbanov a écrit > : > > > > On 10/17/2017 05:19 PM, Nicolas Dufresne wrote: > > > Le mardi 17 octobre 2017 à 13:14 +0300, Sakari Ailus a écrit : > > > > On Sun, Oct 15, 2017 at

Re: [PATCH 1/2] selftests/memfd/memfd_test.c: fix implicit declaration

On 03/13/2018 04:42 AM, Anders Roxell wrote: > gcc warns about implicit declaration. > > gcc -D_FILE_OFFSET_BITS=64 -I../../../../include/uapi/ > -I../../../../include/ -I../../../../usr/include/ > memfd_test.c common.o -o memfd_test > memfd_test.c: In function ‘mfd_assert_get_seals’: >

Re: [PATCH 1/2] selftests/memfd/memfd_test.c: fix implicit declaration

On 03/13/2018 04:42 AM, Anders Roxell wrote: > gcc warns about implicit declaration. > > gcc -D_FILE_OFFSET_BITS=64 -I../../../../include/uapi/ > -I../../../../include/ -I../../../../usr/include/ > memfd_test.c common.o -o memfd_test > memfd_test.c: In function ‘mfd_assert_get_seals’: >

Re: [PATCH v2 1/2] mm: uninitialized struct page poisoning sanity checking

On Tue, Mar 13, 2018 at 8:53 PM, Sasha Levin wrote: > On Tue, Mar 13, 2018 at 08:38:57PM -0400, Pavel Tatashin wrote: >>Hi Sasha, >> >>It seems the patch is doing the right thing, and it catches bugs. Here >>we access uninitialized struct page. The question is why

Re: [PATCH v2 1/2] mm: uninitialized struct page poisoning sanity checking

On Tue, Mar 13, 2018 at 8:53 PM, Sasha Levin wrote: > On Tue, Mar 13, 2018 at 08:38:57PM -0400, Pavel Tatashin wrote: >>Hi Sasha, >> >>It seems the patch is doing the right thing, and it catches bugs. Here >>we access uninitialized struct page. The question is why this happens? > > Not

Re: [PATCH v2 2/7] kexec_file,x86,powerpc: factor out kexec_file_ops functions

Dave Young writes: > On 03/06/18 at 07:22pm, AKASHI Takahiro wrote: >> As arch_kexec_kernel_image_{probe,load}(), >> arch_kimage_file_post_load_cleanup() and arch_kexec_kernel_verify_sig() >> are almost duplicated among architectures, they can be commonalized with >> an

Re: [PATCH v2 2/7] kexec_file,x86,powerpc: factor out kexec_file_ops functions

Dave Young writes: > On 03/06/18 at 07:22pm, AKASHI Takahiro wrote: >> As arch_kexec_kernel_image_{probe,load}(), >> arch_kimage_file_post_load_cleanup() and arch_kexec_kernel_verify_sig() >> are almost duplicated among architectures, they can be commonalized with >> an architecture-defined

Re: [v5 1/2] mm: disable interrupts while initializing deferred pages

> hm, maybe. But I'm not sure that touch_nmi_watchdog() will hold off a > soft lockup warning. Maybe it will. It should: 124static inline void touch_nmi_watchdog(void) 125{ 126 arch_touch_nmi_watchdog(); 127 touch_softlockup_watchdog(); 128} > > And please let's get the above thoughts into

Re: [v5 1/2] mm: disable interrupts while initializing deferred pages

> hm, maybe. But I'm not sure that touch_nmi_watchdog() will hold off a > soft lockup warning. Maybe it will. It should: 124static inline void touch_nmi_watchdog(void) 125{ 126 arch_touch_nmi_watchdog(); 127 touch_softlockup_watchdog(); 128} > > And please let's get the above thoughts into

Re: [PATCH] clang-format: add configuration file

On Wed, Mar 14, 2018 at 1:18 AM, Miguel Ojeda wrote: > > Since we seem to agree on having this, I will send a v2 after I try a > few experiments to try to reduce more the produced diffs, explain > things better in Documentation/, add more comments in the config

Re: [PATCH] clang-format: add configuration file

On Wed, Mar 14, 2018 at 1:18 AM, Miguel Ojeda wrote: > > Since we seem to agree on having this, I will send a v2 after I try a > few experiments to try to reduce more the produced diffs, explain > things better in Documentation/, add more comments in the config file > and send a v2. Alright,

Re: OK to merge via powerpc? (was Re: [PATCH 05/14] mm: make memblock_alloc_base_nid non-static)

On Tue, 13 Mar 2018 12:41:28 -0700 Andrew Morton wrote: > On Tue, 13 Mar 2018 23:06:35 +1100 Michael Ellerman > wrote: > > > Anyone object to us merging the following patch via the powerpc tree? > > > > Full series is here if anyone's

Re: OK to merge via powerpc? (was Re: [PATCH 05/14] mm: make memblock_alloc_base_nid non-static)

On Tue, 13 Mar 2018 12:41:28 -0700 Andrew Morton wrote: > On Tue, 13 Mar 2018 23:06:35 +1100 Michael Ellerman > wrote: > > > Anyone object to us merging the following patch via the powerpc tree? > > > > Full series is here if anyone's interested: > > > >

Re: [PATCH v2 1/2] mm: uninitialized struct page poisoning sanity checking

0] PGD 2284e19067 P4D 2284e19067 PUD 2284e1b067 PMD 0 >> [1.254000] Oops: [#1] SMP DEBUG_PAGEALLOC KASAN PTI >> [1.254000] Modules linked in: >> [1.254000] CPU: 1 PID: 1 Comm: swapper/0 Not tainted >> 4.16.0-rc5-next-20180313 #10 >> [1.254000] Hard

Re: [PATCH v2 1/2] mm: uninitialized struct page poisoning sanity checking

>>>--- >> >> Hey Pasha, >> >> This patch is causing the following on boot: >> >> [1.253732] BUG: unable to handle kernel paging request at >> fffe >> [1.254000] PGD 2284e19067 P4D 2284e19067 PUD 2284e1b067 PMD 0 >> [

[PATCH] irqchip/gic-v3: Ensure GICR_CTLR.EnableLPI=0 is observed before enabling

The definition of the GICR_CTLR.RWP control bit was expanded to indicate status of changing GICR_CTLR.EnableLPI from 1 to 0 is being in progress or completed. Software must observe GICR_CTLR.RWP==0 after clearing GICR_CTLR.EnableLPI from 1 to 0 and before writing GICR_PENDBASER and/or

[PATCH] irqchip/gic-v3: Ensure GICR_CTLR.EnableLPI=0 is observed before enabling

The definition of the GICR_CTLR.RWP control bit was expanded to indicate status of changing GICR_CTLR.EnableLPI from 1 to 0 is being in progress or completed. Software must observe GICR_CTLR.RWP==0 after clearing GICR_CTLR.EnableLPI from 1 to 0 and before writing GICR_PENDBASER and/or

Re: [PATCH] media: vb2: unify calling of set_page_dirty_lock

Le mercredi 18 octobre 2017 à 11:34 +0300, Stanimir Varbanov a écrit : > > On 10/17/2017 05:19 PM, Nicolas Dufresne wrote: > > Le mardi 17 octobre 2017 à 13:14 +0300, Sakari Ailus a écrit : > > > On Sun, Oct 15, 2017 at 07:09:24PM -0400, Nicolas Dufresne wrote: > > > > Le dimanche 15 octobre 2017

Re: [PATCH] media: vb2: unify calling of set_page_dirty_lock

Le mercredi 18 octobre 2017 à 11:34 +0300, Stanimir Varbanov a écrit : > > On 10/17/2017 05:19 PM, Nicolas Dufresne wrote: > > Le mardi 17 octobre 2017 à 13:14 +0300, Sakari Ailus a écrit : > > > On Sun, Oct 15, 2017 at 07:09:24PM -0400, Nicolas Dufresne wrote: > > > > Le dimanche 15 octobre 2017

RE: [PATCH 4.15 119/146] tpm: Keep CLKRUN enabled throughout the duration of transmit_cmd()

No objections from my side. Please merge. Regards, Azhar Shaikh >-Original Message- >From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] >Sent: Tuesday, March 13, 2018 8:25 AM >To: linux-kernel@vger.kernel.org >Cc: Greg Kroah-Hartman ;

RE: [PATCH 4.15 119/146] tpm: Keep CLKRUN enabled throughout the duration of transmit_cmd()

No objections from my side. Please merge. Regards, Azhar Shaikh >-Original Message- >From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] >Sent: Tuesday, March 13, 2018 8:25 AM >To: linux-kernel@vger.kernel.org >Cc: Greg Kroah-Hartman ; >sta...@vger.kernel.org; Shaikh, Azhar ;

RE: [PATCH 4.14 019/140] tpm_tis: Move ilb_base_addr to tpm_tis_data

No objections from my side. Please merge. Regards, Azhar Shaikh >-Original Message- >From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] >Sent: Tuesday, March 13, 2018 8:24 AM >To: linux-kernel@vger.kernel.org >Cc: Greg Kroah-Hartman ;

RE: [PATCH 4.14 019/140] tpm_tis: Move ilb_base_addr to tpm_tis_data

No objections from my side. Please merge. Regards, Azhar Shaikh >-Original Message- >From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] >Sent: Tuesday, March 13, 2018 8:24 AM >To: linux-kernel@vger.kernel.org >Cc: Greg Kroah-Hartman ; >sta...@vger.kernel.org; Shaikh, Azhar ;

RE: [PATCH 4.15 118/146] tpm_tis: Move ilb_base_addr to tpm_tis_data

No objections from my side. Please merge. Regards, Azhar Shaikh >-Original Message- >From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] >Sent: Tuesday, March 13, 2018 8:25 AM >To: linux-kernel@vger.kernel.org >Cc: Greg Kroah-Hartman ;

RE: [PATCH 4.15 118/146] tpm_tis: Move ilb_base_addr to tpm_tis_data

No objections from my side. Please merge. Regards, Azhar Shaikh >-Original Message- >From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] >Sent: Tuesday, March 13, 2018 8:25 AM >To: linux-kernel@vger.kernel.org >Cc: Greg Kroah-Hartman ; >sta...@vger.kernel.org; Shaikh, Azhar ;

RE: [PATCH 4.14 020/140] tpm: Keep CLKRUN enabled throughout the duration of transmit_cmd()

No objections from my side. Please merge. Regards, Azhar Shaikh >-Original Message- >From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] >Sent: Tuesday, March 13, 2018 8:24 AM >To: linux-kernel@vger.kernel.org >Cc: Greg Kroah-Hartman ;

RE: [PATCH 4.14 020/140] tpm: Keep CLKRUN enabled throughout the duration of transmit_cmd()

No objections from my side. Please merge. Regards, Azhar Shaikh >-Original Message- >From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] >Sent: Tuesday, March 13, 2018 8:24 AM >To: linux-kernel@vger.kernel.org >Cc: Greg Kroah-Hartman ; >sta...@vger.kernel.org; Shaikh, Azhar ;

Re: [PATCH v2 1/2] mm: uninitialized struct page poisoning sanity checking

1.254000] Oops: [#1] SMP DEBUG_PAGEALLOC KASAN PTI > [1.254000] Modules linked in: > [1.254000] CPU: 1 PID: 1 Comm: swapper/0 Not tainted > 4.16.0-rc5-next-20180313 #10 > [1.254000] Hardware name: Microsoft Corporation Virtual Machine/Virtual > Machine

Re: [PATCH v2 1/2] mm: uninitialized struct page poisoning sanity checking

1.254000] Modules linked in: > [1.254000] CPU: 1 PID: 1 Comm: swapper/0 Not tainted > 4.16.0-rc5-next-20180313 #10 > [1.254000] Hardware name: Microsoft Corporation Virtual Machine/Virtual > Machine, BIOS 090007 06/02/2017 > [1.254000] RIP: 0010:__dump_page (??:?) &g

[PATCH 2/3] ACPI: SPCR: Add support for AMD CT/SZ

AMD Carrizo / Stoneyridge use a DesignWare 8250 UART that uses a special earlycon setup handler to configure its input clock in order to compute baud rate divisor registers. Detect them by examining the OEMID field in the SPCR header, and pass then pass uart type amdcz to earlycon. Signed-off-by:

[PATCH 2/3] ACPI: SPCR: Add support for AMD CT/SZ

AMD Carrizo / Stoneyridge use a DesignWare 8250 UART that uses a special earlycon setup handler to configure its input clock in order to compute baud rate divisor registers. Detect them by examining the OEMID field in the SPCR header, and pass then pass uart type amdcz to earlycon. Signed-off-by:

[PATCH 3/3] serial: core: Allow skipping old serial port initialization

The old_serial_port global array in 8250_core is supposed to hold an entry for each serial port on the system that cannot be discovered via a standard enumeration mechanism (aka ACPI/PCI/DTS). The array is populated at compile-time from the value specified in the SERIAL_PORT_DFNS macro. This

[PATCH 3/3] serial: core: Allow skipping old serial port initialization

The old_serial_port global array in 8250_core is supposed to hold an entry for each serial port on the system that cannot be discovered via a standard enumeration mechanism (aka ACPI/PCI/DTS). The array is populated at compile-time from the value specified in the SERIAL_PORT_DFNS macro. This

[PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

AMD Carrizo / Stoneyridge use a DesignWare 8250 UART that uses a 48 MHz input clock. Allow these platforms to set up this clock by specifying a kernel command line like: earlycon=amdcz,mmio32,0xfedc6000,115200 Signed-off-by: Daniel Kurtz ---

[PATCH 1/3] serial: 8250_early: Add earlycon support for AMD Carrizo / Stoneyridge

AMD Carrizo / Stoneyridge use a DesignWare 8250 UART that uses a 48 MHz input clock. Allow these platforms to set up this clock by specifying a kernel command line like: earlycon=amdcz,mmio32,0xfedc6000,115200 Signed-off-by: Daniel Kurtz --- drivers/tty/serial/8250/8250_early.c | 15

Re: [PATCH] audit: set TIF_AUDIT_SYSCALL only if audit filter has been populated

On Wed, Mar 14, 2018 at 12:28 AM, Jiri Kosina wrote: > On Wed, 14 Mar 2018, Andy Lutomirski wrote: > >> > Yes...I wished I was in on the beginning of this discussion. Here's the >> > problem. We need all tasks auditable unless specifically dismissed as >> > uninteresting. This

Re: [PATCH] audit: set TIF_AUDIT_SYSCALL only if audit filter has been populated

On Wed, Mar 14, 2018 at 12:28 AM, Jiri Kosina wrote: > On Wed, 14 Mar 2018, Andy Lutomirski wrote: > >> > Yes...I wished I was in on the beginning of this discussion. Here's the >> > problem. We need all tasks auditable unless specifically dismissed as >> > uninteresting. This would be a

Re: [PATCH] audit: set TIF_AUDIT_SYSCALL only if audit filter has been populated

On Wed, 14 Mar 2018, Andy Lutomirski wrote: > > Yes...I wished I was in on the beginning of this discussion. Here's the > > problem. We need all tasks auditable unless specifically dismissed as > > uninteresting. This would be a task,never rule. > > > > The way we look at it, is if it boots with

Re: [PATCH] audit: set TIF_AUDIT_SYSCALL only if audit filter has been populated

On Wed, 14 Mar 2018, Andy Lutomirski wrote: > > Yes...I wished I was in on the beginning of this discussion. Here's the > > problem. We need all tasks auditable unless specifically dismissed as > > uninteresting. This would be a task,never rule. > > > > The way we look at it, is if it boots with

Re: [PATCH] pktgen: use dynamic allocation for debug print buffer

From: Arnd Bergmann Date: Tue, 13 Mar 2018 21:58:39 +0100 > After the removal of the VLA, we get a harmless warning about a large > stack frame: > > net/core/pktgen.c: In function 'pktgen_if_write': > net/core/pktgen.c:1710:1: error: the frame size of 1076 bytes is larger than >

Re: [PATCH] pktgen: use dynamic allocation for debug print buffer

From: Arnd Bergmann Date: Tue, 13 Mar 2018 21:58:39 +0100 > After the removal of the VLA, we get a harmless warning about a large > stack frame: > > net/core/pktgen.c: In function 'pktgen_if_write': > net/core/pktgen.c:1710:1: error: the frame size of 1076 bytes is larger than > 1024 bytes

Re: [PATCH] audit: set TIF_AUDIT_SYSCALL only if audit filter has been populated

On Sat, Mar 10, 2018 at 10:15 AM, Steve Grubb wrote: > On Wed, 7 Mar 2018 18:43:42 -0500 > Paul Moore wrote: >> ... and I just realized that linux-audit isn't on the To/CC line, >> adding them now. >> >> Link to the patch is below. >> >> *

Re: [PATCH] audit: set TIF_AUDIT_SYSCALL only if audit filter has been populated

On Sat, Mar 10, 2018 at 10:15 AM, Steve Grubb wrote: > On Wed, 7 Mar 2018 18:43:42 -0500 > Paul Moore wrote: >> ... and I just realized that linux-audit isn't on the To/CC line, >> adding them now. >> >> Link to the patch is below. >> >> * https://marc.info/?t=15204188763=1=2 > > Yes...I

[patch -mm] mm, memcg: evaluate root and leaf memcgs fairly on oom

There are several downsides to the current implementation that compares the root mem cgroup with leaf mem cgroups for the cgroup-aware oom killer. For example, /proc/pid/oom_score_adj is accounted for processes attached to the root mem cgroup but not leaves. This leads to wild inconsistencies

[patch -mm] mm, memcg: evaluate root and leaf memcgs fairly on oom

There are several downsides to the current implementation that compares the root mem cgroup with leaf mem cgroups for the cgroup-aware oom killer. For example, /proc/pid/oom_score_adj is accounted for processes attached to the root mem cgroup but not leaves. This leads to wild inconsistencies

Re: [PATCH] clang-format: add configuration file

On Tue, Mar 13, 2018 at 11:29 PM, Joe Perches wrote: > On Tue, 2018-03-13 at 22:52 +0100, Miguel Ojeda wrote: >> On Tue, Mar 13, 2018 at 10:00 PM, Andrew Morton >> wrote: >> > On Tue, 13 Mar 2018 00:39:52 +0100 Miguel Ojeda >> >

[PATCH] earlycon: Fix __earlycon_table stride... again

Commit 470ca0de69fe ("serial: earlycon: Enable earlycon without command line param") added EARLYCON_TABLE(). Commit 99492c39f39f ("earlycon: Fix __earlycon_table stride") fixed EARLYCON_TABLE() alignment to 32-bytes. Commit 2eaa790989e0 ("earlycon: Use common framework for earlycon

Re: [PATCH] clang-format: add configuration file

On Tue, Mar 13, 2018 at 11:29 PM, Joe Perches wrote: > On Tue, 2018-03-13 at 22:52 +0100, Miguel Ojeda wrote: >> On Tue, Mar 13, 2018 at 10:00 PM, Andrew Morton >> wrote: >> > On Tue, 13 Mar 2018 00:39:52 +0100 Miguel Ojeda >> > wrote: >> > > --- a/Documentation/process/4.Coding.rst >> > >

[PATCH] earlycon: Fix __earlycon_table stride... again

Commit 470ca0de69fe ("serial: earlycon: Enable earlycon without command line param") added EARLYCON_TABLE(). Commit 99492c39f39f ("earlycon: Fix __earlycon_table stride") fixed EARLYCON_TABLE() alignment to 32-bytes. Commit 2eaa790989e0 ("earlycon: Use common framework for earlycon

Re: [PATCH 4/4] gpio: Remove VLA from stmpe driver

On 03/13/2018 02:13 AM, Phil Reid wrote: On 10/03/2018 08:10, Laura Abbott wrote: The new challenge is to remove VLAs from the kernel (see https://lkml.org/lkml/2018/3/7/621) This patch replaces a VLA with an appropriate call to kmalloc_array. Signed-off-by: Laura Abbott

Re: [PATCH 4/4] gpio: Remove VLA from stmpe driver

On 03/13/2018 02:13 AM, Phil Reid wrote: On 10/03/2018 08:10, Laura Abbott wrote: The new challenge is to remove VLAs from the kernel (see https://lkml.org/lkml/2018/3/7/621) This patch replaces a VLA with an appropriate call to kmalloc_array. Signed-off-by: Laura Abbott ---  

Re: [PATCH RESEND v2 1/2] drm/xen-front: Add support for Xen PV display frontend

Hi Oleksandr, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.16-rc5 next-20180313] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com

Re: [PATCH RESEND v2 1/2] drm/xen-front: Add support for Xen PV display frontend

Hi Oleksandr, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on linus/master] [also build test WARNING on v4.16-rc5 next-20180313] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com

[RFC PATCH] drm/xen-front: xen_drm_front_platform_info can be static

Fixes: db81084f9084 ("drm/xen-front: Add support for Xen PV display frontend") Signed-off-by: Fengguang Wu --- xen_drm_front.c |2 +- xen_drm_front_drv.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/xen/xen_drm_front.c

[RFC PATCH] drm/xen-front: xen_drm_front_platform_info can be static

Fixes: db81084f9084 ("drm/xen-front: Add support for Xen PV display frontend") Signed-off-by: Fengguang Wu --- xen_drm_front.c |2 +- xen_drm_front_drv.c |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/xen/xen_drm_front.c

Re: [PATCH] bpf: whitelist syscalls for error injection

On 03/13/2018 04:49 PM, Yonghong Song wrote: > > > On 3/13/18 4:45 PM, Omar Sandoval wrote: >> On Tue, Mar 13, 2018 at 04:16:27PM -0700, Howard McLauchlan wrote: >>> Error injection is a useful mechanism to fail arbitrary kernel >>> functions. However, it is often hard to guarantee an error

Re: [PATCH] bpf: whitelist syscalls for error injection

On 03/13/2018 04:49 PM, Yonghong Song wrote: > > > On 3/13/18 4:45 PM, Omar Sandoval wrote: >> On Tue, Mar 13, 2018 at 04:16:27PM -0700, Howard McLauchlan wrote: >>> Error injection is a useful mechanism to fail arbitrary kernel >>> functions. However, it is often hard to guarantee an error

Re: dcache: remove trylock loops (was Re: [BUG] lock_parent() breakage when used from shrink_dentry_list())

On Tue, Mar 13, 2018 at 10:05:55PM +0100, John Ogness wrote: > > + rcu_read_lock();/* to protect parent */ > > + spin_unlock(>d_lock); > > + parent = READ_ONCE(dentry->d_parent); > > The preceeding line should be removed. We already have a "parent" from > before we did the

Re: dcache: remove trylock loops (was Re: [BUG] lock_parent() breakage when used from shrink_dentry_list())

On Tue, Mar 13, 2018 at 10:05:55PM +0100, John Ogness wrote: > > + rcu_read_lock();/* to protect parent */ > > + spin_unlock(>d_lock); > > + parent = READ_ONCE(dentry->d_parent); > > The preceeding line should be removed. We already have a "parent" from > before we did the

Re: [PATCH] bpf: whitelist syscalls for error injection

On Tue, Mar 13, 2018 at 11:16 PM, Howard McLauchlan wrote: > Error injection is a useful mechanism to fail arbitrary kernel > functions. However, it is often hard to guarantee an error propagates > appropriately to user space programs. By injecting into syscalls, we can >

Re: [PATCH] bpf: whitelist syscalls for error injection

On Tue, Mar 13, 2018 at 11:16 PM, Howard McLauchlan wrote: > Error injection is a useful mechanism to fail arbitrary kernel > functions. However, it is often hard to guarantee an error propagates > appropriately to user space programs. By injecting into syscalls, we can > return arbitrary values

Re: [RESEND RFC] translate_pid API

On 03/13/2018 04:10 PM, Jann Horn wrote: On Tue, Mar 13, 2018 at 3:45 PM, Nagarathnam Muthusamy wrote: On 03/13/2018 03:00 PM, Jann Horn wrote: On Tue, Mar 13, 2018 at 2:44 PM, Nagarathnam Muthusamy wrote: On 03/13/2018

Re: [RESEND RFC] translate_pid API

On 03/13/2018 04:10 PM, Jann Horn wrote: On Tue, Mar 13, 2018 at 3:45 PM, Nagarathnam Muthusamy wrote: On 03/13/2018 03:00 PM, Jann Horn wrote: On Tue, Mar 13, 2018 at 2:44 PM, Nagarathnam Muthusamy wrote: On 03/13/2018 02:28 PM, Jann Horn wrote: On Tue, Mar 13, 2018 at 2:20 PM,

Re: [PATCH] bpf: whitelist syscalls for error injection

On 3/13/18 4:45 PM, Omar Sandoval wrote: On Tue, Mar 13, 2018 at 04:16:27PM -0700, Howard McLauchlan wrote: Error injection is a useful mechanism to fail arbitrary kernel functions. However, it is often hard to guarantee an error propagates appropriately to user space programs. By injecting

Re: [PATCH] bpf: whitelist syscalls for error injection

On 3/13/18 4:45 PM, Omar Sandoval wrote: On Tue, Mar 13, 2018 at 04:16:27PM -0700, Howard McLauchlan wrote: Error injection is a useful mechanism to fail arbitrary kernel functions. However, it is often hard to guarantee an error propagates appropriately to user space programs. By injecting

Re: [PATCH v4.16-rc4 2/2] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

On 12/03/2018, Peter Zijlstra wrote: > On Mon, Mar 12, 2018 at 07:01:20AM +, Jason Vas Dias wrote: >> Sometimes, particularly when correlating elapsed time to performance >> counter values, > > So what actual problem are you tring to solve here? Perf can already >

Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

On 13/03/18 05:19 PM, Sinan Kaya wrote: > It is still a switch it can move packets but, maybe it can move data at > 100kbps speed. As Stephen pointed out, it's a requirement of the PCIe spec that a switch supports P2P. If you want to sell a switch that does P2P with bad performance then that's

Re: [PATCH v4.16-rc4 2/2] x86/vdso: on Intel, VDSO should handle CLOCK_MONOTONIC_RAW

On 12/03/2018, Peter Zijlstra wrote: > On Mon, Mar 12, 2018 at 07:01:20AM +, Jason Vas Dias wrote: >> Sometimes, particularly when correlating elapsed time to performance >> counter values, > > So what actual problem are you tring to solve here? Perf can already > give you sample time in

Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

On 13/03/18 05:19 PM, Sinan Kaya wrote: > It is still a switch it can move packets but, maybe it can move data at > 100kbps speed. As Stephen pointed out, it's a requirement of the PCIe spec that a switch supports P2P. If you want to sell a switch that does P2P with bad performance then that's

Re: [PATCH] bpf: whitelist syscalls for error injection

On Tue, Mar 13, 2018 at 04:16:27PM -0700, Howard McLauchlan wrote: > Error injection is a useful mechanism to fail arbitrary kernel > functions. However, it is often hard to guarantee an error propagates > appropriately to user space programs. By injecting into syscalls, we can > return arbitrary

Re: [PATCH] bpf: whitelist syscalls for error injection

On Tue, Mar 13, 2018 at 04:16:27PM -0700, Howard McLauchlan wrote: > Error injection is a useful mechanism to fail arbitrary kernel > functions. However, it is often hard to guarantee an error propagates > appropriately to user space programs. By injecting into syscalls, we can > return arbitrary

Re: [PATCH v2 1/2] mm: uninitialized struct page poisoning sanity checking

ALLOC KASAN PTI [1.254000] Modules linked in: [1.254000] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.16.0-rc5-next-20180313 #10 [1.254000] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090007 06/02/2017 [1.254000] RIP: 0010:__dump_page (??:?) [1.254000

Re: [PATCH v2 1/2] mm: uninitialized struct page poisoning sanity checking

linked in: [1.254000] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.16.0-rc5-next-20180313 #10 [1.254000] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090007 06/02/2017 [1.254000] RIP: 0010:__dump_page (??:?) [1.254000] RSP: :881c63c17

<    1   2   3   4   5   6   7   8   9   10   >