On 2018-03-08 13:02, Mimi Zohar wrote:
> On Thu, 2018-03-08 at 06:21 -0500, Richard Guy Briggs wrote:
> > On 2018-03-05 09:24, Mimi Zohar wrote:
> > > On Mon, 2018-03-05 at 08:50 -0500, Richard Guy Briggs wrote:
> > > > On 2018-03-05 08:43, Mimi Zohar wrote:
> > > > > Hi Richard,
> > > > >
> > >
On 2018-03-08 13:02, Mimi Zohar wrote:
> On Thu, 2018-03-08 at 06:21 -0500, Richard Guy Briggs wrote:
> > On 2018-03-05 09:24, Mimi Zohar wrote:
> > > On Mon, 2018-03-05 at 08:50 -0500, Richard Guy Briggs wrote:
> > > > On 2018-03-05 08:43, Mimi Zohar wrote:
> > > > > Hi Richard,
> > > > >
> > >
On Mon, Mar 12, 2018 at 10:42:01PM +, mario.limoncie...@dell.com wrote:
>
>
> > -Original Message-
> > From: Dominik Brodowski [mailto:li...@dominikbrodowski.net]
> > Sent: Tuesday, March 13, 2018 2:54 AM
> > To: dvh...@infradead.org; Limonciello, Mario
>
On Mon, Mar 12, 2018 at 10:42:01PM +, mario.limoncie...@dell.com wrote:
>
>
> > -Original Message-
> > From: Dominik Brodowski [mailto:li...@dominikbrodowski.net]
> > Sent: Tuesday, March 13, 2018 2:54 AM
> > To: dvh...@infradead.org; Limonciello, Mario
> > Cc:
On 1/11/2018 6:07 PM, Peter Zijlstra wrote:
Sorry for the huge delay on this, but I'll have to postpone further.
Still busy with meltdown/spectre stuff.
Could you review the patch?
--
Thanks,
Byungchul
On 1/11/2018 6:07 PM, Peter Zijlstra wrote:
Sorry for the huge delay on this, but I'll have to postpone further.
Still busy with meltdown/spectre stuff.
Could you review the patch?
--
Thanks,
Byungchul
On 03/12/2018 10:32 PM, Josh Elsasser wrote:
init_dummy_netdev() leaves its netdev_ops pointer zeroed. This leads
to a NULL pointer dereference when sk_busy_loop fires against an iwlwifi
wireless adapter and checks napi->dev->netdev_ops->ndo_busy_poll.
Avoid this by ensuring
> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Monday, March 12, 2018 4:37 PM
> To: Razvan Stefanescu
> Cc: gre...@linuxfoundation.org; de...@driverdev.osuosl.org; linux-
> ker...@vger.kernel.org; net...@vger.kernel.org; Alexander
On 03/12/2018 10:32 PM, Josh Elsasser wrote:
init_dummy_netdev() leaves its netdev_ops pointer zeroed. This leads
to a NULL pointer dereference when sk_busy_loop fires against an iwlwifi
wireless adapter and checks napi->dev->netdev_ops->ndo_busy_poll.
Avoid this by ensuring
> -Original Message-
> From: Andrew Lunn [mailto:and...@lunn.ch]
> Sent: Monday, March 12, 2018 4:37 PM
> To: Razvan Stefanescu
> Cc: gre...@linuxfoundation.org; de...@driverdev.osuosl.org; linux-
> ker...@vger.kernel.org; net...@vger.kernel.org; Alexander Graf
> ; a...@arndb.de;
* Dominik Brodowski wrote:
> On Mon, Mar 12, 2018 at 08:32:56AM +0100, Ingo Molnar wrote:
> >
> > * Dominik Brodowski wrote:
> >
> > > I'm a bit more unsure about these remaining patches. They use inline stubs
> > > named ksys_xyzzy()
* Dominik Brodowski wrote:
> On Mon, Mar 12, 2018 at 08:32:56AM +0100, Ingo Molnar wrote:
> >
> > * Dominik Brodowski wrote:
> >
> > > I'm a bit more unsure about these remaining patches. They use inline stubs
> > > named ksys_xyzzy() which (mostly) call fs-internal functions. Another
> > >
Hi all,
After merging the drm tree, today's linux-next build (powerpc
allyesconfig) failed like this:
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c: In function
'smu7_notify_link_speed_change_after_state_change':
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c:3830:7:
Hi all,
After merging the drm tree, today's linux-next build (powerpc
allyesconfig) failed like this:
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c: In function
'smu7_notify_link_speed_change_after_state_change':
drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c:3830:7:
* Dominik Brodowski wrote:
> On Mon, Mar 12, 2018 at 08:37:19AM +0100, Ingo Molnar wrote:
> >
> > * Dominik Brodowski wrote:
> >
> > > --- a/fs/open.c
> > > +++ b/fs/open.c
> > > @@ -1200,7 +1200,7 @@ SYSCALL_DEFINE1(close, unsigned
* Dominik Brodowski wrote:
> On Mon, Mar 12, 2018 at 08:37:19AM +0100, Ingo Molnar wrote:
> >
> > * Dominik Brodowski wrote:
> >
> > > --- a/fs/open.c
> > > +++ b/fs/open.c
> > > @@ -1200,7 +1200,7 @@ SYSCALL_DEFINE1(close, unsigned int, fd)
> > >
> > > return retval;
> > > }
> > >
On Fri, Mar 9, 2018 at 7:27 AM, Eddie James wrote:
> According to the Aspeed specification, the reset and enable sequence
> should be done when the clock is stopped. The specification doesn't
> define behavior if the reset is done while the clock is enabled.
>
> From
On Fri, Mar 9, 2018 at 7:27 AM, Eddie James wrote:
> According to the Aspeed specification, the reset and enable sequence
> should be done when the clock is stopped. The specification doesn't
> define behavior if the reset is done while the clock is enabled.
>
> From testing on the AST2500, the
Hi,
On Tuesday 06 March 2018 04:35 PM, Michael Ellerman wrote:
Anju T Sudhakar writes:
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index 4437c70..caefb64 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -757,6
Hi,
On Tuesday 06 March 2018 04:35 PM, Michael Ellerman wrote:
Anju T Sudhakar writes:
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index 4437c70..caefb64 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -757,6 +759,9 @@ static int
On Fri, Mar 9, 2018 at 7:27 AM, Eddie James wrote:
> Some of the Aspeed clocks are disabled by setting the relevant bit in
> the "clock stop control" register to one, while others are disabled by
> setting their bit to zero. The driver already uses a flag per gate to
On Fri, Mar 9, 2018 at 7:27 AM, Eddie James wrote:
> Some of the Aspeed clocks are disabled by setting the relevant bit in
> the "clock stop control" register to one, while others are disabled by
> setting their bit to zero. The driver already uses a flag per gate to
> identify this behavior,
Good day dear, i hope this mail meets you well? I know this may seem
inappropriate so
i ask for your forgiveness but i wish to get to know you better, if I may be so
bold.
I consider myself an easy-going man, adventurous, honest and fun loving person
but I
am currently looking for a
Good day dear, i hope this mail meets you well? I know this may seem
inappropriate so
i ask for your forgiveness but i wish to get to know you better, if I may be so
bold.
I consider myself an easy-going man, adventurous, honest and fun loving person
but I
am currently looking for a
init_dummy_netdev() leaves its netdev_ops pointer zeroed. This leads
to a NULL pointer dereference when sk_busy_loop fires against an iwlwifi
wireless adapter and checks napi->dev->netdev_ops->ndo_busy_poll.
Avoid this by ensuring napi->dev->netdev_ops is valid before following
the pointer,
init_dummy_netdev() leaves its netdev_ops pointer zeroed. This leads
to a NULL pointer dereference when sk_busy_loop fires against an iwlwifi
wireless adapter and checks napi->dev->netdev_ops->ndo_busy_poll.
Avoid this by ensuring napi->dev->netdev_ops is valid before following
the pointer,
V2: just check napi->dev->netdev_ops instead of getting clever with the
netdev registration state.
Original cover letter:
Hi Dave,
I stumbled across a reproducible kernel panic while playing around with
busy_poll on a Linux 4.9.86 kernel. There's an unfortunate interaction
between
V2: just check napi->dev->netdev_ops instead of getting clever with the
netdev registration state.
Original cover letter:
Hi Dave,
I stumbled across a reproducible kernel panic while playing around with
busy_poll on a Linux 4.9.86 kernel. There's an unfortunate interaction
between
Kan -- sorry for my late-night typo. My description for "hubless" should have
said "a single segment/domain" rather than single bus.
> "hubless" -- equivalent to "glueless" or "white box" where our BIOS sets
> things up with a single bus for all sockets.
single segment/domain
Kan -- sorry for my late-night typo. My description for "hubless" should have
said "a single segment/domain" rather than single bus.
> "hubless" -- equivalent to "glueless" or "white box" where our BIOS sets
> things up with a single bus for all sockets.
single segment/domain
On 03/13/2018 01:53 PM, Jinbum Park wrote:
> 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.
This patch had been already sent from Seungwoo.
On 03/13/2018 01:53 PM, Jinbum Park wrote:
> 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.
This patch had been already sent from Seungwoo.
On Mon, Mar 12, 2018 at 4:17 PM, Cong Wang wrote:
> On Sun, Mar 11, 2018 at 12:22 PM, Josh Elsasser wrote:
>> init_dummy_netdev() leaves its netdev_ops pointer zeroed. This leads
>> to a NULL pointer dereference when sk_busy_loop fires against an
On Mon, Mar 12, 2018 at 4:17 PM, Cong Wang wrote:
> On Sun, Mar 11, 2018 at 12:22 PM, Josh Elsasser wrote:
>> init_dummy_netdev() leaves its netdev_ops pointer zeroed. This leads
>> to a NULL pointer dereference when sk_busy_loop fires against an iwlwifi
>> wireless adapter and checks
On Fri, 9 Mar 2018, Kees Cook wrote:
> The LSM check should happen after the file has been confirmed to be
> unchanging. Without this, we could have a race between the Time of Check
> (the call to security_kernel_read_file() which could read the file and
> make access policy decisions) and the
On Fri, 9 Mar 2018, Kees Cook wrote:
> The LSM check should happen after the file has been confirmed to be
> unchanging. Without this, we could have a race between the Time of Check
> (the call to security_kernel_read_file() which could read the file and
> make access policy decisions) and the
On 03/13/2018 01:53 PM, Jinbum Park wrote:
> 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.
>
> Signed-off-by: Jinbum Park
>
On 03/13/2018 01:53 PM, Jinbum Park wrote:
> 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.
>
> Signed-off-by: Jinbum Park
> ---
>
This patch exports the host capabilities to debugfs
This idea of sharing host capabilities over debugfs
came up from Abbas Raza
Earlier discussions:
https://lkml.org/lkml/2018/3/5/357
https://www.spinics.net/lists/linux-mmc/msg48219.html
Reviewed-by: Andy Shevchenko
This patch exports the host capabilities to debugfs
This idea of sharing host capabilities over debugfs
came up from Abbas Raza
Earlier discussions:
https://lkml.org/lkml/2018/3/5/357
https://www.spinics.net/lists/linux-mmc/msg48219.html
Reviewed-by: Andy Shevchenko
Signed-off-by: Harish Jenny
Thanks, Kan -- your patch looks good, and cleaner than the previous method!
Tonight, I've tested it on our in-house simulator for the following
configurations. The simulator has been matching hardware well for this issue --
we'll do more testing on real hardware, but I'm confident you have it
Thanks, Kan -- your patch looks good, and cleaner than the previous method!
Tonight, I've tested it on our in-house simulator for the following
configurations. The simulator has been matching hardware well for this issue --
we'll do more testing on real hardware, but I'm confident you have it
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.
Signed-off-by: Jinbum Park
---
arch/arm/Kconfig | 1 +
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.
Signed-off-by: Jinbum Park
---
arch/arm/Kconfig | 1 +
arch/arm/boot/compressed/Makefile
On Sat, 10 Mar 2018 06:15:01 -0800, Luis R. Rodriguez wrote:
> request_firmware_cache() will ensure the firmware is available on resume
> from suspend if on reboot the device retains the firmware.
>
> This optimization is in place given otherwise on reboot we have to
> reload the firmware, the
On Sat, 10 Mar 2018 06:15:01 -0800, Luis R. Rodriguez wrote:
> request_firmware_cache() will ensure the firmware is available on resume
> from suspend if on reboot the device retains the firmware.
>
> This optimization is in place given otherwise on reboot we have to
> reload the firmware, the
Similarly to the previous patch, we would like to get rid of stack
allocated arrays: https://lkml.org/lkml/2018/3/7/621
In this case, we can also use a malloc style approach to free the temporary
buffer, being careful to also use kzfree to free them (indeed, at least one
of these has a
Similarly to the previous patch, we would like to get rid of stack
allocated arrays: https://lkml.org/lkml/2018/3/7/621
In this case, we can also use a malloc style approach to free the temporary
buffer, being careful to also use kzfree to free them (indeed, at least one
of these has a
We're interested in getting rid of all of the stack allocated arrays in the
kernel [1]. This patch removes one in keys by switching to malloc/free.
Note that we use kzalloc, to avoid leaking the nonce. I'm not sure this is
really necessary, but extra paranoia seems prudent.
Manually tested using
We're interested in getting rid of all of the stack allocated arrays in the
kernel [1]. This patch removes one in keys by switching to malloc/free.
Note that we use kzalloc, to avoid leaking the nonce. I'm not sure this is
really necessary, but extra paranoia seems prudent.
Manually tested using
On Sat, Mar 10, 2018 at 8:28 AM, Eddie James wrote:
> From: Milton Miller
>
> Allow the device tree to specify a watchdog to fallover to
> the alternate boot source.
>
> The aspeeed watchdog can set a latch directing flash chip select 0 to
> chip
On Sat, Mar 10, 2018 at 8:28 AM, Eddie James wrote:
> From: Milton Miller
>
> Allow the device tree to specify a watchdog to fallover to
> the alternate boot source.
>
> The aspeeed watchdog can set a latch directing flash chip select 0 to
> chip select 1, allowing boot from an alternate media
On Mon, Mar 12, 2018 at 4:57 PM, Linus Torvalds
wrote:
> On Mon, Mar 12, 2018 at 3:55 PM, Andrew Morton
> wrote:
>>
>> Replacing the __builtin_choose_expr() with ?: works of course.
>
> Hmm. That sounds like the right thing to do. We were
On Mon, Mar 12, 2018 at 4:57 PM, Linus Torvalds
wrote:
> On Mon, Mar 12, 2018 at 3:55 PM, Andrew Morton
> wrote:
>>
>> Replacing the __builtin_choose_expr() with ?: works of course.
>
> Hmm. That sounds like the right thing to do. We were so myopically
> staring at the __builtin_choose_expr()
On 2018-03-13 02:22, kbuild test robot wrote:
> Hi Richard,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.16-rc5 next-20180309]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help
On 2018-03-13 02:22, kbuild test robot wrote:
> Hi Richard,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.16-rc5 next-20180309]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help
Hi Greg,
Today's linux-next merge of the staging tree got conflicts in:
drivers/staging/lustre/lnet/libcfs/linux/linux-curproc.c
drivers/staging/lustre/lnet/libcfs/linux/linux-prim.c
between commit:
304ec482f562 ("get rid of pointless includes of fs_struct.h")
from the vfs tree and
Hi Greg,
Today's linux-next merge of the staging tree got conflicts in:
drivers/staging/lustre/lnet/libcfs/linux/linux-curproc.c
drivers/staging/lustre/lnet/libcfs/linux/linux-prim.c
between commit:
304ec482f562 ("get rid of pointless includes of fs_struct.h")
from the vfs tree and
> -Original Message-
> From: Sinan Kaya [mailto:ok...@codeaurora.org]
> Sent: Monday, March 12, 2018 22:14
> To: Nipun Gupta ; h...@lst.de;
> robin.mur...@arm.com; li...@armlinux.org.uk; gre...@linuxfoundation.org;
> m.szyprow...@samsung.com; bhelg...@google.com
>
> -Original Message-
> From: Sinan Kaya [mailto:ok...@codeaurora.org]
> Sent: Monday, March 12, 2018 22:14
> To: Nipun Gupta ; h...@lst.de;
> robin.mur...@arm.com; li...@armlinux.org.uk; gre...@linuxfoundation.org;
> m.szyprow...@samsung.com; bhelg...@google.com
> Cc:
On Sun, Mar 11, 2018 at 02:02:03PM +0100, Zdenek Kabelac wrote:
> Hi
>
> I've noticed quite some drop of performance (around 15% in some cases) where
> execution of lvm2 tests took longer time - and while tests itself should not
> really load CPU system - the overall running time just got
Al Viro writes:
> On Tue, Mar 13, 2018 at 12:37:51AM +, Al Viro wrote:
>> On Mon, Mar 12, 2018 at 06:52:31PM -0500, Eric W. Biederman wrote:
>>
>> > Ah. I see now there is now the s_roots list that handles
>> > that bit of strangeness.
>> >
>> > So one path is to
On Sun, Mar 11, 2018 at 02:02:03PM +0100, Zdenek Kabelac wrote:
> Hi
>
> I've noticed quite some drop of performance (around 15% in some cases) where
> execution of lvm2 tests took longer time - and while tests itself should not
> really load CPU system - the overall running time just got
Al Viro writes:
> On Tue, Mar 13, 2018 at 12:37:51AM +, Al Viro wrote:
>> On Mon, Mar 12, 2018 at 06:52:31PM -0500, Eric W. Biederman wrote:
>>
>> > Ah. I see now there is now the s_roots list that handles
>> > that bit of strangeness.
>> >
>> > So one path is to simply remove the
Hi Thierry Reding,
On Monday, March 12, 2018 05:21 PM, Thierry Reding wrote:
On Mon, Dec 04, 2017 at 03:17:48PM +0800, Lin Huang wrote:
Refactor Innolux P079ZCA panel driver, let it support
multi panel.
Signed-off-by: Lin Huang
---
Changes in v2:
- Change regulator
Hi Thierry Reding,
On Monday, March 12, 2018 05:21 PM, Thierry Reding wrote:
On Mon, Dec 04, 2017 at 03:17:48PM +0800, Lin Huang wrote:
Refactor Innolux P079ZCA panel driver, let it support
multi panel.
Signed-off-by: Lin Huang
---
Changes in v2:
- Change regulator property name to meet the
On 3/12/2018 7:26 PM, Keith Busch wrote:
> On Mon, Mar 12, 2018 at 02:47:30PM -0500, Bjorn Helgaas wrote:
>> [+cc Alex]
>>
>> On Mon, Mar 12, 2018 at 08:25:51AM -0600, Keith Busch wrote:
>>> On Sun, Mar 11, 2018 at 11:03:58PM -0400, Sinan Kaya wrote:
On 3/11/2018 6:03 PM, Bjorn Helgaas wrote:
On 3/12/2018 7:26 PM, Keith Busch wrote:
> On Mon, Mar 12, 2018 at 02:47:30PM -0500, Bjorn Helgaas wrote:
>> [+cc Alex]
>>
>> On Mon, Mar 12, 2018 at 08:25:51AM -0600, Keith Busch wrote:
>>> On Sun, Mar 11, 2018 at 11:03:58PM -0400, Sinan Kaya wrote:
On 3/11/2018 6:03 PM, Bjorn Helgaas wrote:
On Mon, Mar 12, 2018 at 10:32:32AM -0700, Dave Hansen wrote:
> On 03/09/2018 12:24 AM, Aaron Lu wrote:
> > + /*
> > +* We are going to put the page back to the global
> > +* pool, prefetch its buddy to speed up later access
> > +
On Mon, Mar 12, 2018 at 03:22:53PM +0100, Vlastimil Babka wrote:
> On 03/01/2018 07:28 AM, Aaron Lu wrote:
> > When freeing a batch of pages from Per-CPU-Pages(PCP) back to buddy,
> > the zone->lock is held and then pages are chosen from PCP's migratetype
> > list. While there is actually no need
On Mon, Mar 12, 2018 at 10:32:32AM -0700, Dave Hansen wrote:
> On 03/09/2018 12:24 AM, Aaron Lu wrote:
> > + /*
> > +* We are going to put the page back to the global
> > +* pool, prefetch its buddy to speed up later access
> > +
On Mon, Mar 12, 2018 at 03:22:53PM +0100, Vlastimil Babka wrote:
> On 03/01/2018 07:28 AM, Aaron Lu wrote:
> > When freeing a batch of pages from Per-CPU-Pages(PCP) back to buddy,
> > the zone->lock is held and then pages are chosen from PCP's migratetype
> > list. While there is actually no need
Fix issue where CONFIG_CMDLINE_OVERRIDE is being
ignored.
Signed-off-by: Trung Tran
Signed-off-by: Moritz Fischer
---
Hi all,
not sure this is the right fix, hopefully someone
can chime in and come up with the correct solution.
Thanks,
Moritz
---
Fix issue where CONFIG_CMDLINE_OVERRIDE is being
ignored.
Signed-off-by: Trung Tran
Signed-off-by: Moritz Fischer
---
Hi all,
not sure this is the right fix, hopefully someone
can chime in and come up with the correct solution.
Thanks,
Moritz
---
arch/riscv/kernel/setup.c | 6 ++
1
Hi, Daniel:
On Rockchip platforms, we always use CRU to restart system.
From your patch, I think you would like to support restart by CRU or
PMIC, right ?
I think restart by PMIC is not accepted, because PMIC restart
means all regualtors are reset (voltage drops to 0mv and
Hi, Daniel:
On Rockchip platforms, we always use CRU to restart system.
From your patch, I think you would like to support restart by CRU or
PMIC, right ?
I think restart by PMIC is not accepted, because PMIC restart
means all regualtors are reset (voltage drops to 0mv and
On 03/09/2018 05:02 AM, Emil Velikov wrote:
On 9 March 2018 at 10:59, Eric Engestrom wrote:
On Thursday, 2018-03-08 11:39:49 -0600, Gustavo A. R. Silva wrote:
In preparation to enabling -Wvla, remove VLA usage.
Also, fixed as part of the directive to remove all
On 03/09/2018 05:02 AM, Emil Velikov wrote:
On 9 March 2018 at 10:59, Eric Engestrom wrote:
On Thursday, 2018-03-08 11:39:49 -0600, Gustavo A. R. Silva wrote:
In preparation to enabling -Wvla, remove VLA usage.
Also, fixed as part of the directive to remove all VLAs from
the kernel:
On 3/12/2018 3:35 PM, Logan Gunthorpe wrote:
> +int pci_p2pdma_add_client(struct list_head *head, struct device *dev)
It feels like code tried to be a generic p2pdma provider first. Then got
converted to PCI, yet all dev parameters are still struct device.
Maybe, dev parameter should also be
On 3/12/2018 3:35 PM, Logan Gunthorpe wrote:
> +int pci_p2pdma_add_client(struct list_head *head, struct device *dev)
It feels like code tried to be a generic p2pdma provider first. Then got
converted to PCI, yet all dev parameters are still struct device.
Maybe, dev parameter should also be
Thomas Richter writes:
> Right now there is only hard coded support for x86.
That's not true. There is support for generic transaction events in perf.
As far as I can tell your events would map 1:1 to the generic tx-* events.
-Andi
Thomas Richter writes:
> Right now there is only hard coded support for x86.
That's not true. There is support for generic transaction events in perf.
As far as I can tell your events would map 1:1 to the generic tx-* events.
-Andi
On 03/11/2018 11:39 AM, Krzysztof Kozlowski wrote:
On Sat, Mar 10, 2018 at 7:27 AM, Gustavo A. R. Silva
wrote:
Move this enum to rtc-s5m.c once it is meaningless to others drivers [1].
[1] https://marc.info/?l=linux-rtc=152060068925948=2
Instead of external link
On 03/11/2018 11:39 AM, Krzysztof Kozlowski wrote:
On Sat, Mar 10, 2018 at 7:27 AM, Gustavo A. R. Silva
wrote:
Move this enum to rtc-s5m.c once it is meaningless to others drivers [1].
[1] https://marc.info/?l=linux-rtc=152060068925948=2
Instead of external link (which might or might not
In preparation to enabling -Wvla, remove VLA and replace it
with dynamic memory allocation.
>From a security viewpoint, the use of Variable Length Arrays can be
a vector for stack overflow attacks. Also, in general, as the code
evolves it is easy to lose track of how big a VLA can get. Thus, we
In preparation to enabling -Wvla, remove VLA and replace it
with dynamic memory allocation.
>From a security viewpoint, the use of Variable Length Arrays can be
a vector for stack overflow attacks. Also, in general, as the code
evolves it is easy to lose track of how big a VLA can get. Thus, we
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
drivers/bus/arm-cci.c
between commit:
3de6be7a3dd8 ("drivers/bus: Split Arm CCI driver")
from the arm-soc tree and commit:
8343aae66167 ("perf/core: Remove perf_event::group_entry")
from the tip tree.
I fixed it up
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
drivers/bus/arm-cci.c
between commit:
3de6be7a3dd8 ("drivers/bus: Split Arm CCI driver")
from the arm-soc tree and commit:
8343aae66167 ("perf/core: Remove perf_event::group_entry")
from the tip tree.
I fixed it up
Hi Thomas,
At 03/09/2018 11:08 PM, Thomas Gleixner wrote:
[...]
I'm not sure if there is a clear indicator whether physcial hotplug is
supported or not, but the ACPI folks (x86) and architecture maintainers
+cc Rafael
should be able to answer that question. I have a machine which says:
Hi Thomas,
At 03/09/2018 11:08 PM, Thomas Gleixner wrote:
[...]
I'm not sure if there is a clear indicator whether physcial hotplug is
supported or not, but the ACPI folks (x86) and architecture maintainers
+cc Rafael
should be able to answer that question. I have a machine which says:
On Monday 12 March 2018 10:59 PM, Richard Weinberger wrote:
On Mon, Mar 12, 2018 at 5:27 PM, arvindY wrote:
On Monday 12 March 2018 08:13 PM, David Miller wrote:
From: Arvind Yadav
Date: Fri, 9 Mar 2018 16:11:17 +0530
if
On Monday 12 March 2018 10:59 PM, Richard Weinberger wrote:
On Mon, Mar 12, 2018 at 5:27 PM, arvindY wrote:
On Monday 12 March 2018 08:13 PM, David Miller wrote:
From: Arvind Yadav
Date: Fri, 9 Mar 2018 16:11:17 +0530
if device_register() returned an error! Always use put_device()
to
On 2018.03.12 12:43:58 +0100, Colin King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in gvt_err error message text.
>
> Signed-off-by: Colin Ian King
> ---
Thanks Colin, will pick up.
> drivers/gpu/drm/i915/gvt/gtt.c
On 2018.03.12 12:43:58 +0100, Colin King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in gvt_err error message text.
>
> Signed-off-by: Colin Ian King
> ---
Thanks Colin, will pick up.
> drivers/gpu/drm/i915/gvt/gtt.c | 2 +-
> 1 file changed, 1 insertion(+), 1
Stephen,
> In preparation to enabling -Wvla, remove VLAs and replace them with
> fixed-length arrays instead.
>
> scsi_dh_{alua,emc,rdac} use variable-length array declarations to
> store command blocks, with the appropriate size as determined by
> COMMAND_SIZE. This patch replaces these with
Stephen,
> In preparation to enabling -Wvla, remove VLAs and replace them with
> fixed-length arrays instead.
>
> scsi_dh_{alua,emc,rdac} use variable-length array declarations to
> store command blocks, with the appropriate size as determined by
> COMMAND_SIZE. This patch replaces these with
Linus,
> That said, I wonder if the solution to this particular driver is
> "delete it". Because the hardware is truly ancient and nobody sane
> would use it any more.
I'm not aware of anybody actively using these anymore. They are
mid-nineties vintage with an M68K processor onboard. I ran a
Linus,
> That said, I wonder if the solution to this particular driver is
> "delete it". Because the hardware is truly ancient and nobody sane
> would use it any more.
I'm not aware of anybody actively using these anymore. They are
mid-nineties vintage with an M68K processor onboard. I ran a
From: Randy Dunlap
Each of 'make {menu,n,g,x}config' uses (needs) pkg-config to make sure
that other required files are present, but none of these check that
pkg-config itself is present. Add a check for all 4 of these targets.
Fixes kernel bugzilla #77511:
From: Randy Dunlap
Each of 'make {menu,n,g,x}config' uses (needs) pkg-config to make sure
that other required files are present, but none of these check that
pkg-config itself is present. Add a check for all 4 of these targets.
Fixes kernel bugzilla #77511:
1 - 100 of 2114 matches
Mail list logo