wt., 2 paź 2018 o 23:10 Arnd Bergmann napisał(a):
>
> drivers/nvmem/lpc18xx_eeprom.c: In function 'lpc18xx_eeprom_remove':
> drivers/nvmem/lpc18xx_eeprom.c:258:6: error: unused variable 'ret'
> [-Werror=unused-variable]
>
> Fixes: 226014d13fa5 ("nvmem: lpc18xx_eeprom: use devm_nvmem_register()")
The newly added tegra_bpmp_resume function is unused when CONFIG_PM
is disabled:
drivers/firmware/tegra/bpmp.c:847:12: error: 'tegra_bpmp_resume' defined but
not used [-Werror=unused-function]
static int tegra_bpmp_resume(struct device *dev)
Mark it as __maybe_unused to avoid the warning and
wt., 2 paź 2018 o 23:10 Arnd Bergmann napisał(a):
>
> drivers/nvmem/lpc18xx_eeprom.c: In function 'lpc18xx_eeprom_remove':
> drivers/nvmem/lpc18xx_eeprom.c:258:6: error: unused variable 'ret'
> [-Werror=unused-variable]
>
> Fixes: 226014d13fa5 ("nvmem: lpc18xx_eeprom: use devm_nvmem_register()")
The newly added tegra_bpmp_resume function is unused when CONFIG_PM
is disabled:
drivers/firmware/tegra/bpmp.c:847:12: error: 'tegra_bpmp_resume' defined but
not used [-Werror=unused-function]
static int tegra_bpmp_resume(struct device *dev)
Mark it as __maybe_unused to avoid the warning and
Hi all,
Commits
6eeb4180d4b9 ("ARM: dts: sunxi: h3-h5: Add Bananapi M2+ v1.2 device trees")
80c21c8c8b8d ("arm64: dts: allwinner: h5: Add device tree for Bananapi M2
Plus H5")
aa8fee415f46 ("ARM: dts: sun8i: h3: Split out non-SoC-specific parts of
Bananapi M2 Plus")
db9fd9d13e30 ("ARM:
Hi all,
Commits
6eeb4180d4b9 ("ARM: dts: sunxi: h3-h5: Add Bananapi M2+ v1.2 device trees")
80c21c8c8b8d ("arm64: dts: allwinner: h5: Add device tree for Bananapi M2
Plus H5")
aa8fee415f46 ("ARM: dts: sun8i: h3: Split out non-SoC-specific parts of
Bananapi M2 Plus")
db9fd9d13e30 ("ARM:
Hi Steve o/
I personally like more a pr_info() instead of a cifs_dbg (which wraps to a
pr_warn). But in order to keep in line with the general CIFS coding style
I stuck to cifs_dbg
But I would happily rewrite the cifs_dbg to pr_info a v3: That would be
good enough too.
Ah for what is worth my
Hi Steve o/
I personally like more a pr_info() instead of a cifs_dbg (which wraps to a
pr_warn). But in order to keep in line with the general CIFS coding style
I stuck to cifs_dbg
But I would happily rewrite the cifs_dbg to pr_info a v3: That would be
good enough too.
Ah for what is worth my
On Mon, 1 Oct 2018, Kees Cook wrote:
> LSM initialization failures have traditionally been ignored. We should
> at least WARN when something goes wrong.
I guess we could have a boot param which specifies what to do if any LSM
fails to init, as I think some folks will want to stop execution at
On Mon, 1 Oct 2018, Kees Cook wrote:
> LSM initialization failures have traditionally been ignored. We should
> at least WARN when something goes wrong.
I guess we could have a boot param which specifies what to do if any LSM
fails to init, as I think some folks will want to stop execution at
On Mon, Oct 01, 2018 at 08:38:01PM -0700, Paul E. McKenney wrote:
> On Mon, Oct 01, 2018 at 06:20:11PM -0700, Joel Fernandes wrote:
> > From: "Joel Fernandes (Google)"
> >
> > synchronize_rcu_mult is now obsolete since all the different RCU flavors
> > have been consolidated and the API is now
On Mon, Oct 01, 2018 at 08:38:01PM -0700, Paul E. McKenney wrote:
> On Mon, Oct 01, 2018 at 06:20:11PM -0700, Joel Fernandes wrote:
> > From: "Joel Fernandes (Google)"
> >
> > synchronize_rcu_mult is now obsolete since all the different RCU flavors
> > have been consolidated and the API is now
On Tue, Oct 02, 2018 at 05:05:18PM +0200, Borislav Petkov wrote:
> On Tue, Oct 02, 2018 at 03:18:41AM -0700, tip-bot for Masayoshi Mizuma wrote:
> > Commit-ID: 3b054ca88c4f4dd5f516a12d4b6d6bd0ae826f41
> > Gitweb:
> > https://git.kernel.org/tip/3b054ca88c4f4dd5f516a12d4b6d6bd0ae826f41
> >
On Tue, Oct 02, 2018 at 05:05:18PM +0200, Borislav Petkov wrote:
> On Tue, Oct 02, 2018 at 03:18:41AM -0700, tip-bot for Masayoshi Mizuma wrote:
> > Commit-ID: 3b054ca88c4f4dd5f516a12d4b6d6bd0ae826f41
> > Gitweb:
> > https://git.kernel.org/tip/3b054ca88c4f4dd5f516a12d4b6d6bd0ae826f41
> >
memremap() is declared in linux/io.h, not in asm/io.h, so we should
include that header to avoid build errors:
drivers/platform/x86/dcdbas.c: In function 'dcdbas_check_wsmt':
drivers/platform/x86/dcdbas.c:572:15: error: implicit declaration of function
'memremap'; did you mean 'ioremap'?
On Tue, Oct 2, 2018 at 2:11 PM Stephen Rothwell wrote:
>
> Hi Miguel,
>
> On Tue, 2 Oct 2018 15:47:12 +0200 Miguel Ojeda
> wrote:
> >
> > The Compiler Attributes series has been stable for 10+ days. To
> > increase testing before 4.20, I would to request it being picked up
> > for -next.
> >
>
memremap() is declared in linux/io.h, not in asm/io.h, so we should
include that header to avoid build errors:
drivers/platform/x86/dcdbas.c: In function 'dcdbas_check_wsmt':
drivers/platform/x86/dcdbas.c:572:15: error: implicit declaration of function
'memremap'; did you mean 'ioremap'?
On Tue, Oct 2, 2018 at 2:11 PM Stephen Rothwell wrote:
>
> Hi Miguel,
>
> On Tue, 2 Oct 2018 15:47:12 +0200 Miguel Ojeda
> wrote:
> >
> > The Compiler Attributes series has been stable for 10+ days. To
> > increase testing before 4.20, I would to request it being picked up
> > for -next.
> >
>
On Tue, Oct 2, 2018 at 11:01 PM Doug Anderson wrote:
>
> Hi,
>
> On Tue, Oct 2, 2018 at 1:29 AM Rafael J. Wysocki wrote:
[cut]
> > I guess so.
> >
> > Doing that in all cases is kind of risky IMO, because we haven't taken
> > the return values of the ->resume* callbacks into account so far
> >
On Tue, Oct 02, 2018 at 11:02:13PM +0200, Helge Deller wrote:
> Hi Greg,
>
> please pull a last set of fixes for the parisc architecture for kernel 4.19
> from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
> parisc-4.19-3
>
> The major change is for parisc64 to
On Tue, Oct 2, 2018 at 11:01 PM Doug Anderson wrote:
>
> Hi,
>
> On Tue, Oct 2, 2018 at 1:29 AM Rafael J. Wysocki wrote:
[cut]
> > I guess so.
> >
> > Doing that in all cases is kind of risky IMO, because we haven't taken
> > the return values of the ->resume* callbacks into account so far
> >
On Tue, Oct 02, 2018 at 11:02:13PM +0200, Helge Deller wrote:
> Hi Greg,
>
> please pull a last set of fixes for the parisc architecture for kernel 4.19
> from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
> parisc-4.19-3
>
> The major change is for parisc64 to
The 'tiles' array is initialized to a constant pointers to constant
strings, but the declaration is only half as constant:
drivers/pinctrl/qcom/pinctrl-qcs404.c:1660:11: error: initialization discards
'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
The 'tiles' array is initialized to a constant pointers to constant
strings, but the declaration is only half as constant:
drivers/pinctrl/qcom/pinctrl-qcs404.c:1660:11: error: initialization discards
'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
--
Greetings,
I am Mrs.Fatim Adama aging widow of 62 years old suffering from long
time
illness.I have some funds I inherited from my late husband, the sum of
($18,500,000.00 Million Dollars) and I needed a very honest and God
fearing who can withdraw this money this funds use it for Charity
--
Greetings,
I am Mrs.Fatim Adama aging widow of 62 years old suffering from long
time
illness.I have some funds I inherited from my late husband, the sum of
($18,500,000.00 Million Dollars) and I needed a very honest and God
fearing who can withdraw this money this funds use it for Charity
arm64_1188873_read_cntvct_el0() is protected by the correct
CONFIG_ARM64_ERRATUM_1188873 #ifdef, but the only reference to it is
also inside of an CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND section,
and causes a warning if that is disabled:
drivers/clocksource/arm_arch_timer.c:323:20: error:
This board has a Micron MT29F8G08ABACAWP chip which requires a ECC
strength of 8/512. Rather than hard coding any particular strength the
the nand controller auto-detect the ECC strength based on the ONFI data.
Signed-off-by: Chris Packham
---
arch/arm/boot/dts/armada-385-db-88f6820-amc.dts | 2
arm64_1188873_read_cntvct_el0() is protected by the correct
CONFIG_ARM64_ERRATUM_1188873 #ifdef, but the only reference to it is
also inside of an CONFIG_ARM_ARCH_TIMER_OOL_WORKAROUND section,
and causes a warning if that is disabled:
drivers/clocksource/arm_arch_timer.c:323:20: error:
This board has a Micron MT29F8G08ABACAWP chip which requires a ECC
strength of 8/512. Rather than hard coding any particular strength the
the nand controller auto-detect the ECC strength based on the ONFI data.
Signed-off-by: Chris Packham
---
arch/arm/boot/dts/armada-385-db-88f6820-amc.dts | 2
nvmem_find_cell_by_index() is only called from inside an #ifdef,
so we get a build warning without CONFIG_OF:
drivers/nvmem/core.c:496:1: error: 'nvmem_find_cell_by_index' defined but not
used [-Werror=unused-function]
Move it into the same #ifdef as the caller to avoid the warning.
Fixes:
When CONFIG_PM_SLEEP is disabled, we get a warning about unused
suspend/resume functions:
drivers/hwmon/ina3221.c:451:12: error: 'ina3221_resume' defined but not used
[-Werror=unused-function]
static int ina3221_resume(struct device *dev)
drivers/hwmon/ina3221.c:428:12: error: 'ina3221_suspend'
Hi Miguel,
On Tue, 2 Oct 2018 15:47:12 +0200 Miguel Ojeda
wrote:
>
> The Compiler Attributes series has been stable for 10+ days. To
> increase testing before 4.20, I would to request it being picked up
> for -next.
>
> The changes w.r.t. v5 in the LKML:
>
> - Rebased on top of
nvmem_find_cell_by_index() is only called from inside an #ifdef,
so we get a build warning without CONFIG_OF:
drivers/nvmem/core.c:496:1: error: 'nvmem_find_cell_by_index' defined but not
used [-Werror=unused-function]
Move it into the same #ifdef as the caller to avoid the warning.
Fixes:
When CONFIG_PM_SLEEP is disabled, we get a warning about unused
suspend/resume functions:
drivers/hwmon/ina3221.c:451:12: error: 'ina3221_resume' defined but not used
[-Werror=unused-function]
static int ina3221_resume(struct device *dev)
drivers/hwmon/ina3221.c:428:12: error: 'ina3221_suspend'
Hi Miguel,
On Tue, 2 Oct 2018 15:47:12 +0200 Miguel Ojeda
wrote:
>
> The Compiler Attributes series has been stable for 10+ days. To
> increase testing before 4.20, I would to request it being picked up
> for -next.
>
> The changes w.r.t. v5 in the LKML:
>
> - Rebased on top of
On 10/02/2018 01:29 PM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 12:47 PM, John Johansen
> wrote:
>> On 10/02/2018 12:17 PM, Kees Cook wrote:
>>> I could define CONFIG_LSM_ENABLE as being "additive" to
>>> SECURITY_APPARMOR_BOOTPARAM_VALUE and
>>> SECURITY_SELINUX_BOOTPARAM_VALUE?
>>
>> Oh sure
On Mon, Oct 1, 2018 at 6:33 PM Masahiro Yamada
wrote:
>
> We have raised the compiler requirement from time to time.
> With commit cafa0010cd51 ("Raise the minimum required gcc version
> to 4.6"), the minimum for GCC is 4.6 now.
>
> This flag was added by GCC 4.6, and it is recognized by ICC as
On 10/02/2018 01:29 PM, Kees Cook wrote:
> On Tue, Oct 2, 2018 at 12:47 PM, John Johansen
> wrote:
>> On 10/02/2018 12:17 PM, Kees Cook wrote:
>>> I could define CONFIG_LSM_ENABLE as being "additive" to
>>> SECURITY_APPARMOR_BOOTPARAM_VALUE and
>>> SECURITY_SELINUX_BOOTPARAM_VALUE?
>>
>> Oh sure
On Mon, Oct 1, 2018 at 6:33 PM Masahiro Yamada
wrote:
>
> We have raised the compiler requirement from time to time.
> With commit cafa0010cd51 ("Raise the minimum required gcc version
> to 4.6"), the minimum for GCC is 4.6 now.
>
> This flag was added by GCC 4.6, and it is recognized by ICC as
drivers/nvmem/lpc18xx_eeprom.c: In function 'lpc18xx_eeprom_remove':
drivers/nvmem/lpc18xx_eeprom.c:258:6: error: unused variable 'ret'
[-Werror=unused-variable]
Fixes: 226014d13fa5 ("nvmem: lpc18xx_eeprom: use devm_nvmem_register()")
Signed-off-by: Arnd Bergmann
---
drivers/nvmem/lpc18xx_eeprom.c: In function 'lpc18xx_eeprom_remove':
drivers/nvmem/lpc18xx_eeprom.c:258:6: error: unused variable 'ret'
[-Werror=unused-variable]
Fixes: 226014d13fa5 ("nvmem: lpc18xx_eeprom: use devm_nvmem_register()")
Signed-off-by: Arnd Bergmann
---
gcc points out that a pointer is longer than an int on 64-bit
architectures, and that casting between the two may be dangerous:
drivers/mfd/rohm-bd718x7.c: In function 'bd718xx_i2c_probe':
drivers/mfd/rohm-bd718x7.c:101:23: error: cast from pointer to integer of
different size
gcc points out that a pointer is longer than an int on 64-bit
architectures, and that casting between the two may be dangerous:
drivers/mfd/rohm-bd718x7.c: In function 'bd718xx_i2c_probe':
drivers/mfd/rohm-bd718x7.c:101:23: error: cast from pointer to integer of
different size
Hello, Michael.
Great catch. Can you please verify whether the following patch fixes
the issue?
Thanks.
-- 8< --
Subject: cgroup: Fix dom_cgrp propagation when enabling threaded mode
A cgroup which is already a threaded domain may be converted into a
threaded cgroup if the
Hello, Michael.
Great catch. Can you please verify whether the following patch fixes
the issue?
Thanks.
-- 8< --
Subject: cgroup: Fix dom_cgrp propagation when enabling threaded mode
A cgroup which is already a threaded domain may be converted into a
threaded cgroup if the
syzbot has found a reproducer for the following crash on:
HEAD commit:1d2ba7fee28b Merge tag 'fbdev-v4.19-rc7' of https://github..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15b019b940
kernel config:
syzbot has found a reproducer for the following crash on:
HEAD commit:1d2ba7fee28b Merge tag 'fbdev-v4.19-rc7' of https://github..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15b019b940
kernel config:
Two variables that are only used in an #ifdef cause compiler warnings:
lib/test_xarray.c: In function 'check_xa_tag_1':
lib/test_xarray.c:162:15: error: unused variable 'order'
[-Werror=unused-variable]
unsigned int order;
lib/test_xarray.c: In function 'check_xa_shrink':
Two variables that are only used in an #ifdef cause compiler warnings:
lib/test_xarray.c: In function 'check_xa_tag_1':
lib/test_xarray.c:162:15: error: unused variable 'order'
[-Werror=unused-variable]
unsigned int order;
lib/test_xarray.c: In function 'check_xa_shrink':
Hi Thomas, Andrei, Eric,
On Tue, 2 Oct 2018 at 07:15, Thomas Gleixner wrote:
>
> On Mon, 1 Oct 2018, Andrey Vagin wrote:
>
> > On Thu, Sep 27, 2018 at 11:41:49PM +0200, Thomas Gleixner wrote:
> > > On Thu, 27 Sep 2018, Thomas Gleixner wrote:
> > > > Add time skew via NTP/PTP into the picture and
Hi Thomas, Andrei, Eric,
On Tue, 2 Oct 2018 at 07:15, Thomas Gleixner wrote:
>
> On Mon, 1 Oct 2018, Andrey Vagin wrote:
>
> > On Thu, Sep 27, 2018 at 11:41:49PM +0200, Thomas Gleixner wrote:
> > > On Thu, 27 Sep 2018, Thomas Gleixner wrote:
> > > > Add time skew via NTP/PTP into the picture and
On Tue, Oct 2, 2018 at 4:44 PM Liam R. Howlett wrote:
>
> * Dhaval Giani [180919 13:15]:
> > Hi folks,
> >
> > Sasha and I are pleased to announce the Testing and Fuzzing track at
> > LPC [ 1 ]. We are planning to continue the discussions from last
> > year's microconference [2]. Many
On Tue, Oct 2, 2018 at 4:44 PM Liam R. Howlett wrote:
>
> * Dhaval Giani [180919 13:15]:
> > Hi folks,
> >
> > Sasha and I are pleased to announce the Testing and Fuzzing track at
> > LPC [ 1 ]. We are planning to continue the discussions from last
> > year's microconference [2]. Many
Hi,
On Tue, Oct 2, 2018 at 1:29 AM Rafael J. Wysocki wrote:
>
> On Tue, Oct 2, 2018 at 10:05 AM Pavel Machek wrote:
> >
> > Hi!
> >
> > > In general Linux doesn't behave super great if you get an error while
> > > executing a device's resume handler. Nothing will come along later
> > > and and
Hi,
On Tue, Oct 2, 2018 at 1:29 AM Rafael J. Wysocki wrote:
>
> On Tue, Oct 2, 2018 at 10:05 AM Pavel Machek wrote:
> >
> > Hi!
> >
> > > In general Linux doesn't behave super great if you get an error while
> > > executing a device's resume handler. Nothing will come along later
> > > and and
Hi Greg,
please pull a last set of fixes for the parisc architecture for kernel 4.19
from:
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
parisc-4.19-3
The major change is for parisc64 to use a 64-bit suseconds_t type to
match what glibc expects for 64-bit userspace.
Hi Greg,
please pull a last set of fixes for the parisc architecture for kernel 4.19
from:
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux.git
parisc-4.19-3
The major change is for parisc64 to use a 64-bit suseconds_t type to
match what glibc expects for 64-bit userspace.
On 10/02/2018 02:48 PM, Daniel Díaz wrote:
> Hello!
>
> On Fri, 7 Sep 2018 at 09:35, Daniel Díaz wrote:
>> From: Fathi Boudra
>>
>> This patch cleans up the Makefile by restructuring a couple of
>> things, namely:
>> 1) change explicit paths in targets for variables
>> 2) substitute a variable
On 10/02/2018 02:48 PM, Daniel Díaz wrote:
> Hello!
>
> On Fri, 7 Sep 2018 at 09:35, Daniel Díaz wrote:
>> From: Fathi Boudra
>>
>> This patch cleans up the Makefile by restructuring a couple of
>> things, namely:
>> 1) change explicit paths in targets for variables
>> 2) substitute a variable
Hello!
On Fri, 7 Sep 2018 at 09:35, Daniel Díaz wrote:
> From: Fathi Boudra
>
> This patch cleans up the Makefile by restructuring a couple of
> things, namely:
> 1) change explicit paths in targets for variables
> 2) substitute a variable (BINARIES) for another, part of the
>selftests
Hello!
On Fri, 7 Sep 2018 at 09:35, Daniel Díaz wrote:
> From: Fathi Boudra
>
> This patch cleans up the Makefile by restructuring a couple of
> things, namely:
> 1) change explicit paths in targets for variables
> 2) substitute a variable (BINARIES) for another, part of the
>selftests
On Tue, Oct 02, 2018 at 09:36:50AM +0800, 钱君 wrote:
>
>
> I have changed the description content, please refer to the patch file,
> thanks a lot
I can not apply patches from attachments like this, please resend it
properly and I will be glad to review it.
thanks,
greg k-h
On Tue, Oct 02, 2018 at 09:36:50AM +0800, 钱君 wrote:
>
>
> I have changed the description content, please refer to the patch file,
> thanks a lot
I can not apply patches from attachments like this, please resend it
properly and I will be glad to review it.
thanks,
greg k-h
On Sat, Sep 29, 2018 at 04:04:48PM +0200, Andreas Färber wrote:
> Hi Phil and Greg,
>
> Am 12.09.18 um 16:31 schrieb Phil Elwell:
> > The SC16IS752 is a dual-channel device. The two channels are largely
> > independent, but the IRQ signals are wired together as an open-drain,
> > active low
On Sat, Sep 29, 2018 at 04:04:48PM +0200, Andreas Färber wrote:
> Hi Phil and Greg,
>
> Am 12.09.18 um 16:31 schrieb Phil Elwell:
> > The SC16IS752 is a dual-channel device. The two channels are largely
> > independent, but the IRQ signals are wired together as an open-drain,
> > active low
I noticed that on at least the first system I looked at (Ubuntu 18.04)
it defaults to KERN_WARNING (ie 4) so wouldn't have shown a KERN_INFO
which is level 6 (as the mount example from ext4) by default
or the xfs_notice (which is level 5)
https://elinux.org/Debugging_by_printing
On Tue, Oct 2,
I noticed that on at least the first system I looked at (Ubuntu 18.04)
it defaults to KERN_WARNING (ie 4) so wouldn't have shown a KERN_INFO
which is level 6 (as the mount example from ext4) by default
or the xfs_notice (which is level 5)
https://elinux.org/Debugging_by_printing
On Tue, Oct 2,
On Tue, 2 Oct 2018, Michal Hocko wrote:
> On Wed 26-09-18 08:06:24, Michal Hocko wrote:
> > On Tue 25-09-18 15:04:06, Andrew Morton wrote:
> > > On Tue, 25 Sep 2018 14:45:19 -0700 (PDT) David Rientjes
> > > wrote:
> > >
> > > > > > It is also used in
> > > > > > automated testing to ensure
On Tue, 2 Oct 2018, Michal Hocko wrote:
> On Wed 26-09-18 08:06:24, Michal Hocko wrote:
> > On Tue 25-09-18 15:04:06, Andrew Morton wrote:
> > > On Tue, 25 Sep 2018 14:45:19 -0700 (PDT) David Rientjes
> > > wrote:
> > >
> > > > > > It is also used in
> > > > > > automated testing to ensure
On 10/02/2018 07:24 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.131 release.
> There are 94 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 10/02/2018 07:24 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.131 release.
> There are 94 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
Hi Baolin,
Thank you for the v14. We'll probably need v15, though :-)
I added the comments in the code below.
On 10/02/2018 05:43 PM, Baolin Wang wrote:
> This patch adds one new led trigger that LED device can configure
> the software or hardware pattern and trigger it.
>
> Consumers can
Hi Baolin,
Thank you for the v14. We'll probably need v15, though :-)
I added the comments in the code below.
On 10/02/2018 05:43 PM, Baolin Wang wrote:
> This patch adds one new led trigger that LED device can configure
> the software or hardware pattern and trigger it.
>
> Consumers can
On 10/02/2018 07:23 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.74 release.
> There are 137 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 10/02/2018 07:23 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.74 release.
> There are 137 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 10/02/2018 07:21 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.18.12 release.
> There are 228 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 10/02/2018 07:21 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.18.12 release.
> There are 228 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
* Dhaval Giani [180919 13:15]:
> Hi folks,
>
> Sasha and I are pleased to announce the Testing and Fuzzing track at
> LPC [ 1 ]. We are planning to continue the discussions from last
> year's microconference [2]. Many discussions from the Automated
> Testing Summit [3] will also continue, and a
* Dhaval Giani [180919 13:15]:
> Hi folks,
>
> Sasha and I are pleased to announce the Testing and Fuzzing track at
> LPC [ 1 ]. We are planning to continue the discussions from last
> year's microconference [2]. Many discussions from the Automated
> Testing Summit [3] will also continue, and a
v1->v2:
- Minor twists to incorporate Ingo's comments.
- Move class->ops from the lock_class structure to percpu array under
CONFIG_DEBUG_LOCKDEP. That moves the increased memory consumption
to CONFIG_DEBUG_LOCKDEP only.
Enabling CONFIG_LOCKDEP and other related debug options will
v1->v2:
- Minor twists to incorporate Ingo's comments.
- Move class->ops from the lock_class structure to percpu array under
CONFIG_DEBUG_LOCKDEP. That moves the increased memory consumption
to CONFIG_DEBUG_LOCKDEP only.
Enabling CONFIG_LOCKDEP and other related debug options will
Currently, lock_acquire() is called before acquiring the lock and
lock_release() is called before the releasing the lock. As a result,
the execution time of lock_release() is added to the lock hold time
reducing locking throughput, especially for spinlocks and rwlocks which
tend to have a much
Currently, lock_acquire() is called before acquiring the lock and
lock_release() is called before the releasing the lock. As a result,
the execution time of lock_release() is added to the lock hold time
reducing locking throughput, especially for spinlocks and rwlocks which
tend to have a much
The inline function add_chain_cache_classes() is defined, but has no
caller. Just remove it.
Signed-off-by: Waiman Long
---
kernel/locking/lockdep.c | 70
1 file changed, 70 deletions(-)
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
The static __lock_acquire() function has only two callers:
1) lock_acquire()
2) reacquire_held_locks()
In lock_acquire(), raw_local_irq_save() is called beforehand. So
IRQs must have been disabled. So the check
DEBUG_LOCKS_WARN_ON(!irqs_disabled())
is kind of redundant in this case.
The inline function add_chain_cache_classes() is defined, but has no
caller. Just remove it.
Signed-off-by: Waiman Long
---
kernel/locking/lockdep.c | 70
1 file changed, 70 deletions(-)
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
The static __lock_acquire() function has only two callers:
1) lock_acquire()
2) reacquire_held_locks()
In lock_acquire(), raw_local_irq_save() is called beforehand. So
IRQs must have been disabled. So the check
DEBUG_LOCKS_WARN_ON(!irqs_disabled())
is kind of redundant in this case.
When __lock_release() is called, the most likely unlock scenario is
on the innermost lock in the chain. In this case, we can skip some of
the checks and provide a faster path to completion.
Signed-off-by: Waiman Long
---
kernel/locking/lockdep.c | 17 ++---
1 file changed, 14
A sizable portion of the CPU cycles spent on the __lock_acquire() is used
up by the atomic increment of class->ops stat counter. By taking it out
from the lock_class structure and changing it to a per-cpu per-lock-class
counter, we can reduce the amount of cacheline contention on the class
When __lock_release() is called, the most likely unlock scenario is
on the innermost lock in the chain. In this case, we can skip some of
the checks and provide a faster path to completion.
Signed-off-by: Waiman Long
---
kernel/locking/lockdep.c | 17 ++---
1 file changed, 14
A sizable portion of the CPU cycles spent on the __lock_acquire() is used
up by the atomic increment of class->ops stat counter. By taking it out
from the lock_class structure and changing it to a per-cpu per-lock-class
counter, we can reduce the amount of cacheline contention on the class
Hello, Waiman.
My apologies for the delay.
On Mon, Aug 27, 2018 at 01:50:18PM -0400, Waiman Long wrote:
> My current code has explicitly assumed the following relationship for
> partition root.
>
> cpus_allowed = effective_cpus + reserved_cpus
>
> Also effective_cpus cannot be empty.
Hello, Waiman.
My apologies for the delay.
On Mon, Aug 27, 2018 at 01:50:18PM -0400, Waiman Long wrote:
> My current code has explicitly assumed the following relationship for
> partition root.
>
> cpus_allowed = effective_cpus + reserved_cpus
>
> Also effective_cpus cannot be empty.
On Tue, 2 Oct 2018, Arnd Bergmann wrote:
> On Mon, Oct 1, 2018 at 8:53 PM Thomas Gleixner wrote:
> >
> > On Mon, 1 Oct 2018, Eric W. Biederman wrote:
> > > In the context of process migration there is a simpler subproblem that I
> > > think it is worth exploring if we can do something about.
> >
On Tue, 2 Oct 2018, Arnd Bergmann wrote:
> On Mon, Oct 1, 2018 at 8:53 PM Thomas Gleixner wrote:
> >
> > On Mon, 1 Oct 2018, Eric W. Biederman wrote:
> > > In the context of process migration there is a simpler subproblem that I
> > > think it is worth exploring if we can do something about.
> >
On Tue, 25 Sep 2018, Tim Chen wrote:
> +enum spectre_v2_app2app_mitigation {
> + SPECTRE_V2_APP2APP_NONE,
> + SPECTRE_V2_APP2APP_LITE,
> + SPECTRE_V2_APP2APP_STRICT,
> +};
>
> static enum spectre_v2_mitigation spectre_v2_enabled __ro_after_init =
> SPECTRE_V2_NONE;
>
>
On Tue, 25 Sep 2018, Tim Chen wrote:
> +enum spectre_v2_app2app_mitigation {
> + SPECTRE_V2_APP2APP_NONE,
> + SPECTRE_V2_APP2APP_LITE,
> + SPECTRE_V2_APP2APP_STRICT,
> +};
>
> static enum spectre_v2_mitigation spectre_v2_enabled __ro_after_init =
> SPECTRE_V2_NONE;
>
>
On Mon, Oct 1, 2018 at 8:53 PM Thomas Gleixner wrote:
>
> On Mon, 1 Oct 2018, Eric W. Biederman wrote:
> > In the context of process migration there is a simpler subproblem that I
> > think it is worth exploring if we can do something about.
> >
> > For a cluster of machines all running with
On Mon, Oct 1, 2018 at 8:53 PM Thomas Gleixner wrote:
>
> On Mon, 1 Oct 2018, Eric W. Biederman wrote:
> > In the context of process migration there is a simpler subproblem that I
> > think it is worth exploring if we can do something about.
> >
> > For a cluster of machines all running with
301 - 400 of 2384 matches
Mail list logo
