On Tue, Nov 27, 2018 at 5:12 PM Fabio Estevam wrote:
>
> Hi Andrey,
>
> On Tue, Nov 27, 2018 at 10:57 PM Andrey Smirnov
> wrote:
>
> > Could this be a regression? Prior to 415b6185c541 ("PCI: imx6: Fix
> > config read timeout handling") all of the imprecise aborts were caught
> > and handled via
On Tue, Nov 27, 2018 at 5:12 PM Fabio Estevam wrote:
>
> Hi Andrey,
>
> On Tue, Nov 27, 2018 at 10:57 PM Andrey Smirnov
> wrote:
>
> > Could this be a regression? Prior to 415b6185c541 ("PCI: imx6: Fix
> > config read timeout handling") all of the imprecise aborts were caught
> > and handled via
On Tue, Oct 30, 2018 at 04:06:24PM -0700, Evan Green wrote:
> If the backing device for a loop device is a block device,
> then mirror the discard properties of the underlying block
> device into the loop device. While in there, differentiate
> between REQ_OP_DISCARD and REQ_OP_WRITE_ZEROES, which
On Tue, Oct 30, 2018 at 04:06:24PM -0700, Evan Green wrote:
> If the backing device for a loop device is a block device,
> then mirror the discard properties of the underlying block
> device into the loop device. While in there, differentiate
> between REQ_OP_DISCARD and REQ_OP_WRITE_ZEROES, which
On Tue, Nov 27, 2018 at 4:20 PM Stephen Boyd wrote:
>
> Quoting Ryan Case (2018-11-26 18:25:36)
> > Transfers were being divided into device FIFO sized (64 byte max)
> > operations which would poll for completion within a spin_lock_irqsave /
> > spin_unlock_irqrestore block. This both made things
On Tue, Nov 27, 2018 at 4:20 PM Stephen Boyd wrote:
>
> Quoting Ryan Case (2018-11-26 18:25:36)
> > Transfers were being divided into device FIFO sized (64 byte max)
> > operations which would poll for completion within a spin_lock_irqsave /
> > spin_unlock_irqrestore block. This both made things
On Tue, Nov 27, 2018 at 3:36 PM Andi Kleen wrote:
>
> > It does seem that FREEZE_PERFMON_ON_PMI (misnamed as it is) is of
> > rather limited use (or even negative, in our case) to a counter that's
> > already restricted to ring 3.
>
> It's much faster. The PMI cost goes down dramatically.
>
> I
On Tue, Nov 27, 2018 at 3:36 PM Andi Kleen wrote:
>
> > It does seem that FREEZE_PERFMON_ON_PMI (misnamed as it is) is of
> > rather limited use (or even negative, in our case) to a counter that's
> > already restricted to ring 3.
>
> It's much faster. The PMI cost goes down dramatically.
>
> I
On Tue, Nov 27, 2018 at 10:16:56AM -0500, Steven Sistare wrote:
> On 11/9/2018 7:50 AM, Steve Sistare wrote:
> > From: Steve Sistare
> >
> > Provide struct sparsemask and functions to manipulate it. A sparsemask is
> > a sparse bitmap. It reduces cache contention vs the usual bitmap when many
On Tue, Nov 27, 2018 at 03:58:49PM -0500, J. Bruce Fields wrote:
> On Sun, Nov 25, 2018 at 09:17:10AM +0300, Anatoly Trosinenko wrote:
> > When manually exploring the kernel NFSd feature, I have stumbled upon
> > a NULL-dereference when writing to v4_end_grace when server is not yet
> > started.
>
On Tue, Nov 27, 2018 at 10:16:56AM -0500, Steven Sistare wrote:
> On 11/9/2018 7:50 AM, Steve Sistare wrote:
> > From: Steve Sistare
> >
> > Provide struct sparsemask and functions to manipulate it. A sparsemask is
> > a sparse bitmap. It reduces cache contention vs the usual bitmap when many
On Tue, Nov 27, 2018 at 03:58:49PM -0500, J. Bruce Fields wrote:
> On Sun, Nov 25, 2018 at 09:17:10AM +0300, Anatoly Trosinenko wrote:
> > When manually exploring the kernel NFSd feature, I have stumbled upon
> > a NULL-dereference when writing to v4_end_grace when server is not yet
> > started.
>
On Tue, Nov 27, 2018 at 4:38 PM, Kees Cook wrote:
> On Tue, Nov 27, 2018 at 3:21 PM, Tycho Andersen wrote:
>> On Mon, Nov 12, 2018 at 12:24:43PM -0700, Tycho Andersen wrote:
>>> On Mon, Nov 12, 2018 at 11:55:38AM -0700, Tycho Andersen wrote:
>>> > I haven't manage to reproduce it on stock
On Tue, Nov 27, 2018 at 4:38 PM, Kees Cook wrote:
> On Tue, Nov 27, 2018 at 3:21 PM, Tycho Andersen wrote:
>> On Mon, Nov 12, 2018 at 12:24:43PM -0700, Tycho Andersen wrote:
>>> On Mon, Nov 12, 2018 at 11:55:38AM -0700, Tycho Andersen wrote:
>>> > I haven't manage to reproduce it on stock
Hi Andrey,
On Tue, Nov 27, 2018 at 10:57 PM Andrey Smirnov
wrote:
> Could this be a regression? Prior to 415b6185c541 ("PCI: imx6: Fix
> config read timeout handling") all of the imprecise aborts were caught
> and handled via no-op handler. I did an experiment on i.MX6Q board
> that I have (ZII
Hi Andrey,
On Tue, Nov 27, 2018 at 10:57 PM Andrey Smirnov
wrote:
> Could this be a regression? Prior to 415b6185c541 ("PCI: imx6: Fix
> config read timeout handling") all of the imprecise aborts were caught
> and handled via no-op handler. I did an experiment on i.MX6Q board
> that I have (ZII
> Do you use from git?
Yes.
My version is v0.5.2-853-g06a4545
I only see './include/linux/slab.h:332:43: warning: dubious: x & !y'
in linux-next.
The warning in slab.h is already on the way in mm subsystem.
masahiro@pug:~/ref/linux-next$ git log --oneline -1
9d52999 Add lin
> Do you use from git?
Yes.
My version is v0.5.2-853-g06a4545
I only see './include/linux/slab.h:332:43: warning: dubious: x & !y'
in linux-next.
The warning in slab.h is already on the way in mm subsystem.
masahiro@pug:~/ref/linux-next$ git log --oneline -1
9d52999 Add lin
>
> On Wed, Nov 28, 2018 at 4:37 AM Sean Wang wrote:
> >
> > Weiyi Lu 於 2018年11月26日 週一 下午7:45寫道：
> > >
> > > From: Owen Chen
> > >
> > > PLLs with tuner_en bit, such as APLL1, need to disable
> > > tuner_en before apply new frequency settings, or the new frequency
> > > settings (pcw) will not
On Tue, 2018-11-27 at 10:45 +0100, Takashi Iwai wrote:
> On Tue, 27 Nov 2018 03:57:48 +0100,
> Ayman Bagabas wrote:
> > +static const struct key_entry huawei_wmi_keymap[] __initconst = {
> > + { KE_KEY,0x281, { KEY_BRIGHTNESSDOWN } },
> > + { KE_KEY,0x282, {
>
> On Wed, Nov 28, 2018 at 4:37 AM Sean Wang wrote:
> >
> > Weiyi Lu 於 2018年11月26日 週一 下午7:45寫道：
> > >
> > > From: Owen Chen
> > >
> > > PLLs with tuner_en bit, such as APLL1, need to disable
> > > tuner_en before apply new frequency settings, or the new frequency
> > > settings (pcw) will not
On Tue, 2018-11-27 at 10:45 +0100, Takashi Iwai wrote:
> On Tue, 27 Nov 2018 03:57:48 +0100,
> Ayman Bagabas wrote:
> > +static const struct key_entry huawei_wmi_keymap[] __initconst = {
> > + { KE_KEY,0x281, { KEY_BRIGHTNESSDOWN } },
> > + { KE_KEY,0x282, {
On Wed, Nov 28, 2018 at 6:50 AM Kees Cook wrote:
>
> On Mon, Nov 19, 2018 at 9:06 AM, Dave Hansen wrote:
> > On 11/19/18 7:43 AM, Yangtao Li wrote:
> >> -static const struct file_operations ptdump_curusr_fops = {
> >> - .owner = THIS_MODULE,
> >> - .open =
On Wed, Nov 28, 2018 at 6:50 AM Kees Cook wrote:
>
> On Mon, Nov 19, 2018 at 9:06 AM, Dave Hansen wrote:
> > On 11/19/18 7:43 AM, Yangtao Li wrote:
> >> -static const struct file_operations ptdump_curusr_fops = {
> >> - .owner = THIS_MODULE,
> >> - .open =
On Tue, Nov 20, 2018 at 9:43 AM Stefan Agner wrote:
>
> Define the length of the DBI registers. This makes sure that
> the kernel does not access registers beyond that point, avoiding
> the following abort on a i.MX 6Quad:
> # cat
On Tue, Nov 20, 2018 at 9:43 AM Stefan Agner wrote:
>
> Define the length of the DBI registers. This makes sure that
> the kernel does not access registers beyond that point, avoiding
> the following abort on a i.MX 6Quad:
> # cat
The function sis_find_family drops lpc_bridge reference via pci_dev_put,
however, after that, field lpc_bridge->revision is read. This may result
in a use after free bug. The patch moves the put operation after the
condition check.
Signed-off-by: Pan Bian
---
drivers/ide/sis5513.c | 3 ++-
1
The function sis_find_family drops lpc_bridge reference via pci_dev_put,
however, after that, field lpc_bridge->revision is read. This may result
in a use after free bug. The patch moves the put operation after the
condition check.
Signed-off-by: Pan Bian
---
drivers/ide/sis5513.c | 3 ++-
1
Quoting Taniya Das (2018-11-24 20:36:08)
> From: Amit Nischal
>
> Add support for the graphics clock controller found on SDM845
> based devices. This would allow graphics drivers to probe and
> control their clocks.
>
> Signed-off-by: Amit Nischal
> Signed-off-by: Taniya Das
> ---
Applied to
[Resend for wrong reply HTML format mail]
Great check for making kcs_bmc module be more stable and handle things
gracefully.
My tag if needed.
Reviewed-by: Haiyue Wang
在 2018-11-27 21:36, Corey Minyard 写道:
On 11/21/18 9:08 AM, Nicholas Mc Guire wrote:
devm_kasprintf() may return NULL
Quoting Taniya Das (2018-11-24 20:36:08)
> From: Amit Nischal
>
> Add support for the graphics clock controller found on SDM845
> based devices. This would allow graphics drivers to probe and
> control their clocks.
>
> Signed-off-by: Amit Nischal
> Signed-off-by: Taniya Das
> ---
Applied to
[Resend for wrong reply HTML format mail]
Great check for making kcs_bmc module be more stable and handle things
gracefully.
My tag if needed.
Reviewed-by: Haiyue Wang
在 2018-11-27 21:36, Corey Minyard 写道:
On 11/21/18 9:08 AM, Nicholas Mc Guire wrote:
devm_kasprintf() may return NULL
The kernel test robot reported two performance regressions
caused by recent patches.
Both appear to related to the global spinlock blocked_lock_lock
being taken more often.
This patch avoids taking that lock in the cases tested.
Reported-by: kernel test robot
Signed-off-by: NeilBrown
---
Hi
The kernel test robot reported two performance regressions
caused by recent patches.
Both appear to related to the global spinlock blocked_lock_lock
being taken more often.
This patch avoids taking that lock in the cases tested.
Reported-by: kernel test robot
Signed-off-by: NeilBrown
---
Hi
On Tue, 2018-11-27 at 17:52 +0200, Andy Shevchenko wrote:
> On Tue, Nov 27, 2018 at 1:02 PM Takashi Iwai wrote:
> > On Tue, 27 Nov 2018 03:57:48 +0100,
> > Ayman Bagabas wrote:
> > > + handle = ACPI_HANDLE(>dev);
> > > + args[0].type = args[1].type = args[2].type =
> > >
Quoting Taniya Das (2018-11-24 20:36:07)
> From: Amit Nischal
>
> Add device tree bindings for graphics clock controller for
> Qualcomm Technology Inc's SDM845 SoCs.
>
> Signed-off-by: Amit Nischal
You could have added your sign off here, but I don't think this is
really different from the
On Tue, 2018-11-27 at 17:52 +0200, Andy Shevchenko wrote:
> On Tue, Nov 27, 2018 at 1:02 PM Takashi Iwai wrote:
> > On Tue, 27 Nov 2018 03:57:48 +0100,
> > Ayman Bagabas wrote:
> > > + handle = ACPI_HANDLE(>dev);
> > > + args[0].type = args[1].type = args[2].type =
> > >
Quoting Taniya Das (2018-11-24 20:36:07)
> From: Amit Nischal
>
> Add device tree bindings for graphics clock controller for
> Qualcomm Technology Inc's SDM845 SoCs.
>
> Signed-off-by: Amit Nischal
You could have added your sign off here, but I don't think this is
really different from the
Hi,
On Tue, Nov 27, 2018 at 3:23 PM Derek Basehore wrote:
>
> This adds the 32k clock to the RK3399 Gru board file. Even though it's
> not directly used, muxes will end up traversing the entire clk tree on
> calls to determine_rate if it doesn't exist. This is because the 32k
> clk is listed as
Hi,
On Tue, Nov 27, 2018 at 3:23 PM Derek Basehore wrote:
>
> This adds the 32k clock to the RK3399 Gru board file. Even though it's
> not directly used, muxes will end up traversing the entire clk tree on
> calls to determine_rate if it doesn't exist. This is because the 32k
> clk is listed as
On Tue, Nov 27, 2018 at 3:21 PM, Tycho Andersen wrote:
> On Mon, Nov 12, 2018 at 12:24:43PM -0700, Tycho Andersen wrote:
>> On Mon, Nov 12, 2018 at 11:55:38AM -0700, Tycho Andersen wrote:
>> > I haven't manage to reproduce it on stock v4.20-rc2, unfortunately.
>>
>> Ok, now I have,
>>
>>
On Tue, Nov 27, 2018 at 3:21 PM, Tycho Andersen wrote:
> On Mon, Nov 12, 2018 at 12:24:43PM -0700, Tycho Andersen wrote:
>> On Mon, Nov 12, 2018 at 11:55:38AM -0700, Tycho Andersen wrote:
>> > I haven't manage to reproduce it on stock v4.20-rc2, unfortunately.
>>
>> Ok, now I have,
>>
>>
In gmane.comp.file-systems.ext4 Guenter Roeck wrote:
> [trying again, this time with correct kernel.org address]
> Hi,
> I have seen the following and similar problems several times,
> with both v4.19.3 and v4.19.4:
> Nov 23 04:32:25 mars kernel: [112668.673671] EXT4-fs error (device sdb1):
>
In gmane.comp.file-systems.ext4 Guenter Roeck wrote:
> [trying again, this time with correct kernel.org address]
> Hi,
> I have seen the following and similar problems several times,
> with both v4.19.3 and v4.19.4:
> Nov 23 04:32:25 mars kernel: [112668.673671] EXT4-fs error (device sdb1):
>
On 11/26/18 6:42 AM, Frank Lee wrote:
> On Sat, Nov 24, 2018 at 10:52 PM Yangtao Li wrote:
>>
>> of_find_node_by_path() acquires a reference to the node returned by it
>> and that reference needs to be dropped by its caller. soc_is_brcmstb()
>> doesn't do that, so fix it.
>>
>> [treding:
On 11/26/18 6:42 AM, Frank Lee wrote:
> On Sat, Nov 24, 2018 at 10:52 PM Yangtao Li wrote:
>>
>> of_find_node_by_path() acquires a reference to the node returned by it
>> and that reference needs to be dropped by its caller. soc_is_brcmstb()
>> doesn't do that, so fix it.
>>
>> [treding:
On 11/26/18 4:49 PM, René Kjellerup wrote:
> To the broadcom kernel maintainers, (for BCM4708 CPUs)
>
> I just want to add a little attention to this patch again...
> let me know if there's any concerns and I will try to address highlighted
> issues
> as soon as possible.
>
> I've been
On 11/26/18 4:49 PM, René Kjellerup wrote:
> To the broadcom kernel maintainers, (for BCM4708 CPUs)
>
> I just want to add a little attention to this patch again...
> let me know if there's any concerns and I will try to address highlighted
> issues
> as soon as possible.
>
> I've been
Quoting Ryan Case (2018-11-26 18:25:36)
> Transfers were being divided into device FIFO sized (64 byte max)
> operations which would poll for completion within a spin_lock_irqsave /
> spin_unlock_irqrestore block. This both made things slow by waiting for
> the FIFO to completely drain before
Quoting Ryan Case (2018-11-26 18:25:36)
> Transfers were being divided into device FIFO sized (64 byte max)
> operations which would poll for completion within a spin_lock_irqsave /
> spin_unlock_irqrestore block. This both made things slow by waiting for
> the FIFO to completely drain before
On Wed, Nov 28, 2018 at 07:34:14AM +0900, Akira Yokosawa wrote:
> On 2018/11/27 09:17:46 -0800, Paul E. McKenney wrote:
> > On Tue, Nov 27, 2018 at 01:26:42AM +0100, Andrea Parri wrote:
> >>> commit 72f61917f12236514a70017d1ebafb9b8d34a9b6
> >>> Author: Paul E. McKenney
> >>> Date: Mon Nov 26
On Wed, Nov 28, 2018 at 07:34:14AM +0900, Akira Yokosawa wrote:
> On 2018/11/27 09:17:46 -0800, Paul E. McKenney wrote:
> > On Tue, Nov 27, 2018 at 01:26:42AM +0100, Andrea Parri wrote:
> >>> commit 72f61917f12236514a70017d1ebafb9b8d34a9b6
> >>> Author: Paul E. McKenney
> >>> Date: Mon Nov 26
Hi Will,
On Tue, 27 Nov 2018 13:18:59 -0500
Steven Rostedt wrote:
> On Tue, 27 Nov 2018 16:58:49 +
> Will Deacon wrote:
>
> > This looks fine to me, but I'm curious about whether this is supposed to
> > work with compat syscalls as well, where the prefix is "__arm64_compat_".
> >
> > If
Hi Will,
On Tue, 27 Nov 2018 13:18:59 -0500
Steven Rostedt wrote:
> On Tue, 27 Nov 2018 16:58:49 +
> Will Deacon wrote:
>
> > This looks fine to me, but I'm curious about whether this is supposed to
> > work with compat syscalls as well, where the prefix is "__arm64_compat_".
> >
> > If
On Wed, Nov 28, 2018 at 4:37 AM Sean Wang wrote:
>
> Weiyi Lu 於 2018年11月26日 週一 下午7:45寫道：
> >
> > From: Owen Chen
> >
> > PLLs with tuner_en bit, such as APLL1, need to disable
> > tuner_en before apply new frequency settings, or the new frequency
> > settings (pcw) will not be applied.
> > The
On Wed, Nov 28, 2018 at 4:37 AM Sean Wang wrote:
>
> Weiyi Lu 於 2018年11月26日 週一 下午7:45寫道：
> >
> > From: Owen Chen
> >
> > PLLs with tuner_en bit, such as APLL1, need to disable
> > tuner_en before apply new frequency settings, or the new frequency
> > settings (pcw) will not be applied.
> > The
On Mon, Nov 26, 2018 at 06:30:04PM -0800, Linus Torvalds wrote:
> On Thu, Nov 22, 2018 at 3:28 PM Peter Hutterer
> wrote:
> >
> > The device sends hi-res values of 4, so it should end up as REL_WHEEL_HI_RES
> > 30. We are getting 28 instead which doesn't add up to a nice 120.
>
> I think you're
On Mon, Nov 26, 2018 at 06:30:04PM -0800, Linus Torvalds wrote:
> On Thu, Nov 22, 2018 at 3:28 PM Peter Hutterer
> wrote:
> >
> > The device sends hi-res values of 4, so it should end up as REL_WHEEL_HI_RES
> > 30. We are getting 28 instead which doesn't add up to a nice 120.
>
> I think you're
> On Mon, 26 Nov 2018 06:36:37 +0100,
> Chanho Min wrote:
> >
> > Commit 67ec1072b053 ("ALSA: pcm: Fix rwsem deadlock for non-atomic PCM
> > stream") fixes deadlock for non-atomic PCM stream. But, This patch
> causes antother stuck.
> > If writer is RT thread and reader is a normal thread, the
> On Mon, 26 Nov 2018 06:36:37 +0100,
> Chanho Min wrote:
> >
> > Commit 67ec1072b053 ("ALSA: pcm: Fix rwsem deadlock for non-atomic PCM
> > stream") fixes deadlock for non-atomic PCM stream. But, This patch
> causes antother stuck.
> > If writer is RT thread and reader is a normal thread, the
On Sun, Nov 18, 2018 at 02:47:33PM +0200, Jarkko Sakkinen wrote:
> [was Detach TPM space code out of the tpm_transmit() flow but the scope
> expanded a bit.]
>
> Make the changes necessary to detach TPM space code and TPM activation
> code out of the tpm_transmit() flow because of both of these
On Sun, Nov 18, 2018 at 02:47:33PM +0200, Jarkko Sakkinen wrote:
> [was Detach TPM space code out of the tpm_transmit() flow but the scope
> expanded a bit.]
>
> Make the changes necessary to detach TPM space code and TPM activation
> code out of the tpm_transmit() flow because of both of these
On Wed, Nov 21, 2018 at 05:18:38PM +0200, Jarkko Sakkinen wrote:
> On Wed, Nov 21, 2018 at 06:50:37AM -0800, Tadeusz Struk wrote:
> > Currently to read a response from the TPM device an application needs
> > provide big enough buffer for the whole response and read it in one go.
> > The
On Wed, Nov 21, 2018 at 05:18:38PM +0200, Jarkko Sakkinen wrote:
> On Wed, Nov 21, 2018 at 06:50:37AM -0800, Tadeusz Struk wrote:
> > Currently to read a response from the TPM device an application needs
> > provide big enough buffer for the whole response and read it in one go.
> > The
> It does seem that FREEZE_PERFMON_ON_PMI (misnamed as it is) is of
> rather limited use (or even negative, in our case) to a counter that's
> already restricted to ring 3.
It's much faster. The PMI cost goes down dramatically.
I still the the right fix is to add an perf event opt-out and let it
> It does seem that FREEZE_PERFMON_ON_PMI (misnamed as it is) is of
> rather limited use (or even negative, in our case) to a counter that's
> already restricted to ring 3.
It's much faster. The PMI cost goes down dramatically.
I still the the right fix is to add an perf event opt-out and let it
Hi,
On Mon, Nov 26, 2018 at 10:14 PM Anson Huang wrote:
>
> This patch enables CONFIG_IMX_SC_THERMAL by default.
>
> Signed-off-by: Anson Huang
I don't think this driver is needed to boot the system to root
filesystem, is it? If so, it would be preferred to enable this as a
module to keep
Hi,
On Mon, Nov 26, 2018 at 10:14 PM Anson Huang wrote:
>
> This patch enables CONFIG_IMX_SC_THERMAL by default.
>
> Signed-off-by: Anson Huang
I don't think this driver is needed to boot the system to root
filesystem, is it? If so, it would be preferred to enable this as a
module to keep
On Tue, Nov 27, 2018 at 01:31:17PM +0100, Oleg Nesterov wrote:
> On 11/27, Elvira Khabirova wrote:
> > On Mon, 26 Nov 2018 15:35:24 +0100, Oleg Nesterov wrote:
> > > On 11/25, Elvira Khabirova wrote:
> > > >
> > > > Extend PTRACE_GET_SYSCALL_INFO to support PTRACE_EVENT_SECCOMP stops.
> > > > The
On Tue, Nov 27, 2018 at 01:31:17PM +0100, Oleg Nesterov wrote:
> On 11/27, Elvira Khabirova wrote:
> > On Mon, 26 Nov 2018 15:35:24 +0100, Oleg Nesterov wrote:
> > > On 11/25, Elvira Khabirova wrote:
> > > >
> > > > Extend PTRACE_GET_SYSCALL_INFO to support PTRACE_EVENT_SECCOMP stops.
> > > > The
On Wed, 21 Nov 2018, Stephen Boyd wrote:
> Quoting Paul Walmsley (2018-10-20 06:50:24)
> > diff --git a/drivers/clk/sifive/fu540-prci.c
> > b/drivers/clk/sifive/fu540-prci.c
> > new file mode 100644
> > index ..870cb8333648
> > --- /dev/null
> > +++ b/drivers/clk/sifive/fu540-prci.c
On Wed, 21 Nov 2018, Stephen Boyd wrote:
> Quoting Paul Walmsley (2018-10-20 06:50:24)
> > diff --git a/drivers/clk/sifive/fu540-prci.c
> > b/drivers/clk/sifive/fu540-prci.c
> > new file mode 100644
> > index ..870cb8333648
> > --- /dev/null
> > +++ b/drivers/clk/sifive/fu540-prci.c
This adds the 32k clock to the RK3399 Gru board file. Even though it's
not directly used, muxes will end up traversing the entire clk tree on
calls to determine_rate if it doesn't exist. This is because the 32k
clk is listed as a possible parent on some clks. Since the clk doesn't
know about the
This adds the 32k clock to the RK3399 Gru board file. Even though it's
not directly used, muxes will end up traversing the entire clk tree on
calls to determine_rate if it doesn't exist. This is because the 32k
clk is listed as a possible parent on some clks. Since the clk doesn't
know about the
From: kbuild test robot
drivers/infiniband/core/uverbs_cmd.c:1095:1-3: WARNING: PTR_ERR_OR_ZERO can be
used
Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
Generated by: scripts/coccinelle/api/ptr_ret.cocci
Fixes: 7106a9769715 ("RDMA/uverbs: Make write() handlers return 0 on
On Mon, Nov 12, 2018 at 12:24:43PM -0700, Tycho Andersen wrote:
> On Mon, Nov 12, 2018 at 11:55:38AM -0700, Tycho Andersen wrote:
> > I haven't manage to reproduce it on stock v4.20-rc2, unfortunately.
>
> Ok, now I have,
>
> seccomp_bpf.c:2736:global.syscall_restart:Expected getpid() (1493) ==
From: kbuild test robot
drivers/infiniband/core/uverbs_cmd.c:1095:1-3: WARNING: PTR_ERR_OR_ZERO can be
used
Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
Generated by: scripts/coccinelle/api/ptr_ret.cocci
Fixes: 7106a9769715 ("RDMA/uverbs: Make write() handlers return 0 on
On Mon, Nov 12, 2018 at 12:24:43PM -0700, Tycho Andersen wrote:
> On Mon, Nov 12, 2018 at 11:55:38AM -0700, Tycho Andersen wrote:
> > I haven't manage to reproduce it on stock v4.20-rc2, unfortunately.
>
> Ok, now I have,
>
> seccomp_bpf.c:2736:global.syscall_restart:Expected getpid() (1493) ==
On Tue, Nov 27 2018, J. Bruce Fields wrote:
> Thanks for the report!
Yes, thanks. I thought I had replied to the previous report of a similar
problem, but I didn't actually send that email - oops.
Though the test is the same and the regression similar, this is a
different patch. The previous
On Tue, Nov 27 2018, J. Bruce Fields wrote:
> Thanks for the report!
Yes, thanks. I thought I had replied to the previous report of a similar
problem, but I didn't actually send that email - oops.
Though the test is the same and the regression similar, this is a
different patch. The previous
On Tue, Nov 27, 2018 at 02:34:39PM -0800, Tadeusz Struk wrote:
> On 11/27/18 2:10 PM, Jarkko Sakkinen wrote:
> > Added the tests that I've been using for testing TPM 2.0 functionality
> > for long time but have out-of-tree so far residing in
> >
> > https://github.com/jsakkine-intel/tpm2-scripts
On Tue, Nov 27, 2018 at 02:34:39PM -0800, Tadeusz Struk wrote:
> On 11/27/18 2:10 PM, Jarkko Sakkinen wrote:
> > Added the tests that I've been using for testing TPM 2.0 functionality
> > for long time but have out-of-tree so far residing in
> >
> > https://github.com/jsakkine-intel/tpm2-scripts
On Tue, Nov 27, 2018 at 12:53:07PM -1000, Joey Pabalinas wrote:
> On Tue, Nov 27, 2018 at 12:49:00PM -1000, Joey Pabalinas wrote:
> > > +def start_auth_session(self, session_type, name_alg = TPM2_ALG_SHA1):
> > > +fmt = '>HII IIH16sHBHH'
> > > +cmd = struct.pack(fmt,
> > > +
On Tue, Nov 27, 2018 at 12:53:07PM -1000, Joey Pabalinas wrote:
> On Tue, Nov 27, 2018 at 12:49:00PM -1000, Joey Pabalinas wrote:
> > > +def start_auth_session(self, session_type, name_alg = TPM2_ALG_SHA1):
> > > +fmt = '>HII IIH16sHBHH'
> > > +cmd = struct.pack(fmt,
> > > +
Hi Al,
Today's linux-next merge of the vfs tree got a conflict in:
fs/Makefile
between commit:
d44170a7ba48 ("fs: common implementation of file type")
from the ext3 tree and commits:
229e55402816 ("vfs: Add configuration parser helpers")
37744f3d21f8 ("vfs: Implement a filesystem
Hi Al,
Today's linux-next merge of the vfs tree got a conflict in:
fs/Makefile
between commit:
d44170a7ba48 ("fs: common implementation of file type")
from the ext3 tree and commits:
229e55402816 ("vfs: Add configuration parser helpers")
37744f3d21f8 ("vfs: Implement a filesystem
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 this approach.
The motivation for this is to provide a
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 this approach.
The motivation for this is to provide a
This introduces a new thread group flag that can be set by calling
prctl(PR_SET_KILL_DESCENDANTS_ON_EXIT, 1, 0, 0, 0)
When a thread group exits with this flag set, it will send SIGKILL to
all descendant processes. This can be used to prevent stray child
processes.
This flag is cleared on
This introduces a new thread group flag that can be set by calling
prctl(PR_SET_KILL_DESCENDANTS_ON_EXIT, 1, 0, 0, 0)
When a thread group exits with this flag set, it will send SIGKILL to
all descendant processes. This can be used to prevent stray child
processes.
This flag is cleared on
[Repost as a series, as suggested by Andrew Morton]
Selftest for the pre-coredump signal notification
Signed-off-by: Enke Chen
---
tools/testing/selftests/prctl/Makefile | 2 +-
tools/testing/selftests/prctl/predump-sig-test.c | 160 +++
2 files changed, 161
[Repost as a series, as suggested by Andrew Morton]
Selftest for the pre-coredump signal notification
Signed-off-by: Enke Chen
---
tools/testing/selftests/prctl/Makefile | 2 +-
tools/testing/selftests/prctl/predump-sig-test.c | 160 +++
2 files changed, 161
[Repost as a series, as suggested by Andrew Morton]
For simplicity and consistency, this patch provides an implementation
for signal-based fault notification prior to the coredump of a child
process. A new prctl command, PR_SET_PREDUMP_SIG, is defined that can
be used by an application to express
[Repost as a series, as suggested by Andrew Morton]
For simplicity and consistency, this patch provides an implementation
for signal-based fault notification prior to the coredump of a child
process. A new prctl command, PR_SET_PREDUMP_SIG, is defined that can
be used by an application to express
Hi Masami,
On Mon, 2018-11-26 at 22:03 +0900, Masami Hiramatsu wrote:
> On Wed, 14 Nov 2018 14:18:06 -0600
> Tom Zanussi wrote:
>
> > From: Tom Zanussi
> >
> > Add a test case verifying the basic functionality of the
> > hist:snapshot() action.
> >
> > Signed-off-by: Tom Zanussi
> > ---
> >
Hi Masami,
On Mon, 2018-11-26 at 22:03 +0900, Masami Hiramatsu wrote:
> On Wed, 14 Nov 2018 14:18:06 -0600
> Tom Zanussi wrote:
>
> > From: Tom Zanussi
> >
> > Add a test case verifying the basic functionality of the
> > hist:snapshot() action.
> >
> > Signed-off-by: Tom Zanussi
> > ---
> >
On Tue, Nov 27, 2018 at 12:49:00PM -1000, Joey Pabalinas wrote:
> > +def start_auth_session(self, session_type, name_alg = TPM2_ALG_SHA1):
> > +fmt = '>HII IIH16sHBHH'
> > +cmd = struct.pack(fmt,
> > + TPM2_ST_NO_SESSIONS,
> > +
On Tue, Nov 27, 2018 at 12:49:00PM -1000, Joey Pabalinas wrote:
> > +def start_auth_session(self, session_type, name_alg = TPM2_ALG_SHA1):
> > +fmt = '>HII IIH16sHBHH'
> > +cmd = struct.pack(fmt,
> > + TPM2_ST_NO_SESSIONS,
> > +
On Mon, Nov 19, 2018 at 9:06 AM, Dave Hansen wrote:
> On 11/19/18 7:43 AM, Yangtao Li wrote:
>> -static const struct file_operations ptdump_curusr_fops = {
>> - .owner = THIS_MODULE,
>> - .open = ptdump_open_curusr,
>> - .read = seq_read,
>> - .llseek
On Tue, Nov 27, 2018 at 12:57 PM Andrea Arcangeli wrote:
>
> This difference can only happen with defrag=always, and that's not the
> current upstream default.
Ok, thanks. That makes it a bit less critical.
> That MADV_HUGEPAGE causes flights with NUMA balancing is not great
> indeed, qemu
201 - 300 of 1444 matches
Mail list logo
