Re: Freeing HugeTLB page into buddy allocator

On Tue, Apr 25, 2017 at 02:27:27PM +0530, Anshuman Khandual wrote: > Hello Jianguo, > > In the commit a49ecbcd7b0d5a1cda, it talks about HugeTLB page being > freed into buddy allocator instead of hugepage_freelists. But if > I look the code closely for the function unmap_and_move_huge_page() > it

Re: Freeing HugeTLB page into buddy allocator

On Tue, Apr 25, 2017 at 02:27:27PM +0530, Anshuman Khandual wrote: > Hello Jianguo, > > In the commit a49ecbcd7b0d5a1cda, it talks about HugeTLB page being > freed into buddy allocator instead of hugepage_freelists. But if > I look the code closely for the function unmap_and_move_huge_page() > it

Re: [PATCH] iio:ad5064: Add support for ltc2633 and similar devices

On 26/04/17 10:44, Mike Looijmans wrote: > The Linear Technology LTC2631, LTC2633 and LTC2635 are very similar > to the AD5064 device, in particular the LTC2627. > > This patch adds support for those devices. Only the LTC2633 has been > tested, which is the 2-channel variant. The LTC2631 is the

Re: [PATCH] iio:ad5064: Add support for ltc2633 and similar devices

On 26/04/17 10:44, Mike Looijmans wrote: > The Linear Technology LTC2631, LTC2633 and LTC2635 are very similar > to the AD5064 device, in particular the LTC2627. > > This patch adds support for those devices. Only the LTC2633 has been > tested, which is the 2-channel variant. The LTC2631 is the

Re: [patch] autogain support for bayer10 format (was Re: [patch] propagating controls in libv4l2)

On 27.04.2017 01:51, Pavel Machek wrote: Hi! There are two separate things here: 1) Autofoucs for a device that doesn't use subdev API 2) libv4l2 support for devices that require MC and subdev API Actually there are three: 0) autogain. Unfortunately, I need autogain first before autofocus

Re: [patch] autogain support for bayer10 format (was Re: [patch] propagating controls in libv4l2)

On 27.04.2017 01:51, Pavel Machek wrote: Hi! There are two separate things here: 1) Autofoucs for a device that doesn't use subdev API 2) libv4l2 support for devices that require MC and subdev API Actually there are three: 0) autogain. Unfortunately, I need autogain first before autofocus

Re: [PATCH] iio: stm32 trigger: Add support for TRGO2 triggers

On 26/04/17 09:55, Benjamin Gaignard wrote: > 2017-04-26 10:17 GMT+02:00 Fabrice Gasnier : >> Add support for TRGO2 trigger that can be found on STM32F7. >> Add additional master modes supported by TRGO2. These additional modes would benefit from more information in the ABI

Re: [PATCH] iio: stm32 trigger: Add support for TRGO2 triggers

On 26/04/17 09:55, Benjamin Gaignard wrote: > 2017-04-26 10:17 GMT+02:00 Fabrice Gasnier : >> Add support for TRGO2 trigger that can be found on STM32F7. >> Add additional master modes supported by TRGO2. These additional modes would benefit from more information in the ABI docs. Otherwise patch

Re: [PATCH v4 1/3] kexec: Move vmcoreinfo out of the kernel's .bss section

Hi Xunlei, On 04/27/17 at 01:25pm, Xunlei Pang wrote: > On 04/27/2017 at 11:06 AM, Dave Young wrote: > > [snip] > > > > static int __init crash_save_vmcoreinfo_init(void) > > { > > + /* One page should be enough for VMCOREINFO_BYTES under all > > archs */ > Can

Re: [PATCH v4 1/3] kexec: Move vmcoreinfo out of the kernel's .bss section

Hi Xunlei, On 04/27/17 at 01:25pm, Xunlei Pang wrote: > On 04/27/2017 at 11:06 AM, Dave Young wrote: > > [snip] > > > > static int __init crash_save_vmcoreinfo_init(void) > > { > > + /* One page should be enough for VMCOREINFO_BYTES under all > > archs */ > Can

Re: [PATCH v6 2/5] firmware: add extensible driver data API

On Thu, 2017-04-27 at 05:16 +0200, Luis R. Rodriguez wrote: > > > @@ -1460,6 +1471,128 @@ void release_firmware(const struct firmware *fw) > > >   } > > >   EXPORT_SYMBOL(release_firmware); > > >   > > > +static int _driver_data_request_api(struct driver_data_params *params, > > > +   

Re: [PATCH v6 2/5] firmware: add extensible driver data API

On Thu, 2017-04-27 at 05:16 +0200, Luis R. Rodriguez wrote: > > > @@ -1460,6 +1471,128 @@ void release_firmware(const struct firmware *fw) > > >   } > > >   EXPORT_SYMBOL(release_firmware); > > >   > > > +static int _driver_data_request_api(struct driver_data_params *params, > > > +   

Re: TREE_SRCU slows hotplug by factor ~16

On Wed, 2017-04-26 at 22:32 -0700, Paul E. McKenney wrote: > On Thu, Apr 27, 2017 at 06:15:56AM +0200, Mike Galbraith wrote: > > On Wed, 2017-04-26 at 21:11 -0700, Paul E. McKenney wrote: > > > > > This is with srcutree.exp_holdoff set to 25*1000? > > > > Yup. > > And please see below for the

Re: TREE_SRCU slows hotplug by factor ~16

On Wed, 2017-04-26 at 22:32 -0700, Paul E. McKenney wrote: > On Thu, Apr 27, 2017 at 06:15:56AM +0200, Mike Galbraith wrote: > > On Wed, 2017-04-26 at 21:11 -0700, Paul E. McKenney wrote: > > > > > This is with srcutree.exp_holdoff set to 25*1000? > > > > Yup. > > And please see below for the

Re: [PATCH v2] tools/iio: Use include/uapi with __EXPORTED_HEADERS__

On 21/04/17 13:31, Sekhar Nori wrote: > Use the local uapi headers to keep in sync with "recently" added enum > values like IIO_UVINDEX. > > Build tested using: > $ make -C tools/iio > $ make -C /tools iio > $ make -C /tools/iio > > This follows a strategy similar to that used by tools/hv,

Re: [PATCH v2] tools/iio: Use include/uapi with __EXPORTED_HEADERS__

On 21/04/17 13:31, Sekhar Nori wrote: > Use the local uapi headers to keep in sync with "recently" added enum > values like IIO_UVINDEX. > > Build tested using: > $ make -C tools/iio > $ make -C /tools iio > $ make -C /tools/iio > > This follows a strategy similar to that used by tools/hv,

Re: [PATCH v2] stm class: Document the stm_ftrace

Hi Alex, Could you take this patch please if there's no further comments? Thanks, Chunyan On 23 March 2017 at 14:13, Chunyan Zhang wrote: > This patch adds a description to the stm_ftrace device source, an > interface for collecting Ftrace's function trace

Re: [PATCH v2] stm class: Document the stm_ftrace

Hi Alex, Could you take this patch please if there's no further comments? Thanks, Chunyan On 23 March 2017 at 14:13, Chunyan Zhang wrote: > This patch adds a description to the stm_ftrace device source, an > interface for collecting Ftrace's function trace information via > STM devices. > >

Re: TREE_SRCU slows hotplug by factor ~16

On Thu, Apr 27, 2017 at 06:15:56AM +0200, Mike Galbraith wrote: > On Wed, 2017-04-26 at 21:11 -0700, Paul E. McKenney wrote: > > > This is with srcutree.exp_holdoff set to 25*1000? > > Yup. And please see below for the trivial patch, just for confirmation. May I add your Tested-by?

Re: TREE_SRCU slows hotplug by factor ~16

On Thu, Apr 27, 2017 at 06:15:56AM +0200, Mike Galbraith wrote: > On Wed, 2017-04-26 at 21:11 -0700, Paul E. McKenney wrote: > > > This is with srcutree.exp_holdoff set to 25*1000? > > Yup. And please see below for the trivial patch, just for confirmation. May I add your Tested-by?

Re: [PATCH] iio: core: Fix suspicious sizeof usage

On 25/04/17 02:16, Orson Zhai wrote: > Pointer size is variours in different system, say 32bit for 4 and 64bit > for 8. The 'sizeof(infomask)' may lead to wrong bit numbers. > > Signed-off-by: Orson Zhai That's certainly been there a while. oops. Anyhow, whilst

Re: [PATCH] iio: core: Fix suspicious sizeof usage

On 25/04/17 02:16, Orson Zhai wrote: > Pointer size is variours in different system, say 32bit for 4 and 64bit > for 8. The 'sizeof(infomask)' may lead to wrong bit numbers. > > Signed-off-by: Orson Zhai That's certainly been there a while. oops. Anyhow, whilst clearly garbage, it doesn't

Re: [PATCH -mm -v10 1/3] mm, THP, swap: Delay splitting THP during swap out

On Tue, Apr 25, 2017 at 08:56:56PM +0800, Huang, Ying wrote: > From: Huang Ying > > In this patch, splitting huge page is delayed from almost the first > step of swapping out to after allocating the swap space for the > THP (Transparent Huge Page) and adding the THP into

Re: [PATCH -mm -v10 1/3] mm, THP, swap: Delay splitting THP during swap out

On Tue, Apr 25, 2017 at 08:56:56PM +0800, Huang, Ying wrote: > From: Huang Ying > > In this patch, splitting huge page is delayed from almost the first > step of swapping out to after allocating the swap space for the > THP (Transparent Huge Page) and adding the THP into the swap cache. > This

Re: x86-tip tsc/tick gripage

On Wed, 2017-04-26 at 14:30 +0200, Mike Galbraith wrote: > On Wed, 2017-04-26 at 13:39 +0200, Mike Galbraith wrote: > > On Wed, 2017-04-26 at 12:26 +0200, Peter Zijlstra wrote: > > > On Wed, Apr 26, 2017 at 10:57:42AM +0200, Mike Galbraith wrote: > > > > > > > Both still lose their TSC. > > > >

Re: x86-tip tsc/tick gripage

On Wed, 2017-04-26 at 14:30 +0200, Mike Galbraith wrote: > On Wed, 2017-04-26 at 13:39 +0200, Mike Galbraith wrote: > > On Wed, 2017-04-26 at 12:26 +0200, Peter Zijlstra wrote: > > > On Wed, Apr 26, 2017 at 10:57:42AM +0200, Mike Galbraith wrote: > > > > > > > Both still lose their TSC. > > > >

Re: [PATCH v4 1/3] kexec: Move vmcoreinfo out of the kernel's .bss section

On 04/27/2017 at 11:06 AM, Dave Young wrote: > [snip] > > static int __init crash_save_vmcoreinfo_init(void) > { > + /* One page should be enough for VMCOREINFO_BYTES under all archs */ Can we add a comment in the VMCOREINFO_BYTES header file about the one page

Re: [PATCH v4 1/3] kexec: Move vmcoreinfo out of the kernel's .bss section

On 04/27/2017 at 11:06 AM, Dave Young wrote: > [snip] > > static int __init crash_save_vmcoreinfo_init(void) > { > + /* One page should be enough for VMCOREINFO_BYTES under all archs */ Can we add a comment in the VMCOREINFO_BYTES header file about the one page

Re: [PATCH 3/3] iio: tools: generic_buffer: increase trigger length

On 19/04/17 09:20, Eugen Hristev wrote: > Increased trigger length to 50 in order to cope with trigger names like > fc03.adc-dev0-external-rising > > Signed-off-by: Eugen Hristev This is fine (though I'd go bigger as Daniel suggested) I'll pick it up with the

Re: [PATCH 3/3] iio: tools: generic_buffer: increase trigger length

On 19/04/17 09:20, Eugen Hristev wrote: > Increased trigger length to 50 in order to cope with trigger names like > fc03.adc-dev0-external-rising > > Signed-off-by: Eugen Hristev This is fine (though I'd go bigger as Daniel suggested) I'll pick it up with the revised series. thanks,

Re: [PATCH 2/3] iio: adc: at91-sama5d2_adc: add hw trigger and buffer support

On 19/04/17 09:20, Eugen Hristev wrote: > Added support for the external hardware trigger on pin ADTRG, > integrated the three possible edge triggers into the subsystem > and created buffer management for data retrieval > > Signed-off-by: Eugen Hristev > --- >

Re: [PATCH 2/3] iio: adc: at91-sama5d2_adc: add hw trigger and buffer support

On 19/04/17 09:20, Eugen Hristev wrote: > Added support for the external hardware trigger on pin ADTRG, > integrated the three possible edge triggers into the subsystem > and created buffer management for data retrieval > > Signed-off-by: Eugen Hristev > --- > drivers/iio/adc/at91-sama5d2_adc.c

Question about scheduler load balancing

Hello Presumably the scheduler load balancing logic is less reluctant to load balance tasks at higher level scheduling domains (e.g. cross NUMA) than lower level SD Is that true? If yes, which knobs (or hardcodes) drive the load_balance() function to vary how aggressively it balances when it is

Question about scheduler load balancing

Hello Presumably the scheduler load balancing logic is less reluctant to load balance tasks at higher level scheduling domains (e.g. cross NUMA) than lower level SD Is that true? If yes, which knobs (or hardcodes) drive the load_balance() function to vary how aggressively it balances when it is

Re: Boot regression caused by kauditd

On Wed, Apr 26, 2017 at 2:20 PM, Paul Moore wrote: > Hi, > > Thanks for the report, this is the only one like it that I've seen. > I'm looking at the code in Linus' tree and I'm not seeing anything > obvious ... looking at the trace above it appears that the problem is > when

Re: Boot regression caused by kauditd

On Wed, Apr 26, 2017 at 2:20 PM, Paul Moore wrote: > Hi, > > Thanks for the report, this is the only one like it that I've seen. > I'm looking at the code in Linus' tree and I'm not seeing anything > obvious ... looking at the trace above it appears that the problem is > when get_net() goes to

Re: ipsec doesn't route TCP with 4.11 kernel

(Cc'ing netdev and IPSec maintainers) On Tue, Apr 25, 2017 at 6:08 PM, Don Bowman wrote: > I'm not sure how to describe this. > > 4.11rc2 worked, after that, no. > > My ipsec tunnel comes up ok. ICMP works. UDP works. But TCP, the > sender [which is the ipsec client] does not

Re: ipsec doesn't route TCP with 4.11 kernel

(Cc'ing netdev and IPSec maintainers) On Tue, Apr 25, 2017 at 6:08 PM, Don Bowman wrote: > I'm not sure how to describe this. > > 4.11rc2 worked, after that, no. > > My ipsec tunnel comes up ok. ICMP works. UDP works. But TCP, the > sender [which is the ipsec client] does not reach the

[PATCH v3] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS when running under Xen

When running as Xen pv guest X86_BUG_SYSRET_SS_ATTRS must not be set on AMD cpus. This bug/feature bit is kind of special as it will be used very early when switching threads. Setting the bit and clearing it a little bit later leaves a critical window where things can go wrong. This time window

[PATCH v3] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS when running under Xen

When running as Xen pv guest X86_BUG_SYSRET_SS_ATTRS must not be set on AMD cpus. This bug/feature bit is kind of special as it will be used very early when switching threads. Setting the bit and clearing it a little bit later leaves a critical window where things can go wrong. This time window

Re: [PATCH v5 08/11] mm: hwpoison: soft offline supports thp migration

On Fri, Apr 21, 2017 at 10:55:49AM -0500, Zi Yan wrote: > > > Anshuman Khandual wrote: > > On 04/21/2017 02:17 AM, Zi Yan wrote: > >> From: Naoya Horiguchi > >> > >> This patch enables thp migration for soft offline. > >> > >> Signed-off-by: Naoya Horiguchi

Re: [PATCH v5 08/11] mm: hwpoison: soft offline supports thp migration

On Fri, Apr 21, 2017 at 10:55:49AM -0500, Zi Yan wrote: > > > Anshuman Khandual wrote: > > On 04/21/2017 02:17 AM, Zi Yan wrote: > >> From: Naoya Horiguchi > >> > >> This patch enables thp migration for soft offline. > >> > >> Signed-off-by: Naoya Horiguchi > >> > >> ChangeLog: v1 -> v5: > >>

Re: [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

On 27/04/17 00:04, Borislav Petkov wrote: > On Wed, Apr 26, 2017 at 08:24:12PM +0200, Juergen Gross wrote: >> I'm not feeling strong about it. So if you want to test for >> X86_FEATURE_XENPV to avoid setting X86_BUG_SYSRET_SS_ATTRS I'm fine >> with it. >> >> Will send V2 with that change. > > And

Re: [PATCH] x86/amd: don't set X86_BUG_SYSRET_SS_ATTRS if forced to zero

On 27/04/17 00:04, Borislav Petkov wrote: > On Wed, Apr 26, 2017 at 08:24:12PM +0200, Juergen Gross wrote: >> I'm not feeling strong about it. So if you want to test for >> X86_FEATURE_XENPV to avoid setting X86_BUG_SYSRET_SS_ATTRS I'm fine >> with it. >> >> Will send V2 with that change. > > And

Re: [PATCH -mm -v3] mm, swap: Sort swap entries before free

On Wed, Apr 26, 2017 at 08:42:10PM +0800, Huang, Ying wrote: > Minchan Kim writes: > > > On Fri, Apr 21, 2017 at 08:29:30PM +0800, Huang, Ying wrote: > >> "Huang, Ying" writes: > >> > >> > Minchan Kim writes: > >> > > >> >> On Wed,

Re: [PATCH -mm -v3] mm, swap: Sort swap entries before free

On Wed, Apr 26, 2017 at 08:42:10PM +0800, Huang, Ying wrote: > Minchan Kim writes: > > > On Fri, Apr 21, 2017 at 08:29:30PM +0800, Huang, Ying wrote: > >> "Huang, Ying" writes: > >> > >> > Minchan Kim writes: > >> > > >> >> On Wed, Apr 19, 2017 at 04:14:43PM +0800, Huang, Ying wrote: > >> >>>

Re: [PATCH 1/1] rtc: gemini: add return value validation

HI Pan, On Sun, 23 Apr 2017, Pan Bian wrote: > From: Pan Bian > > Function devm_ioremap() will return a NULL pointer if it fails to remap > IO address, and its return value should be validated before it is used. > However, in function gemini_rtc_probe(), its return value

Re: [PATCH 1/1] rtc: gemini: add return value validation

HI Pan, On Sun, 23 Apr 2017, Pan Bian wrote: > From: Pan Bian > > Function devm_ioremap() will return a NULL pointer if it fails to remap > IO address, and its return value should be validated before it is used. > However, in function gemini_rtc_probe(), its return value is not > checked. This

linux-next: build failure after merge of the staging tree

Hi Greg, After merging the staging tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c: In function 'rtw_cfg80211_preinit_wiphy': drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:3409:18: error:

linux-next: build failure after merge of the staging tree

Hi Greg, After merging the staging tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c: In function 'rtw_cfg80211_preinit_wiphy': drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:3409:18: error:

Re: iov_iter_pipe warning.

On Fri, Apr 21, 2017 at 06:54:30PM +0100, Al Viro wrote: > On Wed, Apr 12, 2017 at 03:03:18PM -0400, Dave Jones wrote: > > > Well it's been running an hour without incident, which looks promising. > > I'll leave it run, but I'd say you're on the right track given how quick > > it reproduced

Re: iov_iter_pipe warning.

On Fri, Apr 21, 2017 at 06:54:30PM +0100, Al Viro wrote: > On Wed, Apr 12, 2017 at 03:03:18PM -0400, Dave Jones wrote: > > > Well it's been running an hour without incident, which looks promising. > > I'll leave it run, but I'd say you're on the right track given how quick > > it reproduced

Re: TREE_SRCU slows hotplug by factor ~16

On Wed, 2017-04-26 at 21:11 -0700, Paul E. McKenney wrote: > This is with srcutree.exp_holdoff set to 25*1000? Yup.

Re: TREE_SRCU slows hotplug by factor ~16

On Wed, 2017-04-26 at 21:11 -0700, Paul E. McKenney wrote: > This is with srcutree.exp_holdoff set to 25*1000? Yup.

Re: TREE_SRCU slows hotplug by factor ~16

On Thu, Apr 27, 2017 at 05:43:59AM +0200, Mike Galbraith wrote: > On Wed, 2017-04-26 at 20:12 +0200, Mike Galbraith wrote: > > On Wed, 2017-04-26 at 10:56 -0700, Paul E. McKenney wrote: > > > > > > OK, I do need to do more work. My current guess is that I should have > > > > set the default for

Re: TREE_SRCU slows hotplug by factor ~16

On Thu, Apr 27, 2017 at 05:43:59AM +0200, Mike Galbraith wrote: > On Wed, 2017-04-26 at 20:12 +0200, Mike Galbraith wrote: > > On Wed, 2017-04-26 at 10:56 -0700, Paul E. McKenney wrote: > > > > > > OK, I do need to do more work. My current guess is that I should have > > > > set the default for

Re: [PATCH v2] NFC: trf7970a: Correct register settings for 27MHz clock

On Wed, Apr 26, 2017 at 09:41:48PM -0400, Geoff Lansberry wrote: Hi Geoff. > In prior commits the selected clock frequency does not propagate > correctly to what is written the the TRF7970A_MODULATOR_SYS_CLK_CTRL > register. > > Signed-off-by: Geoff Lansberry > --- >

Re: [PATCH v2] NFC: trf7970a: Correct register settings for 27MHz clock

On Wed, Apr 26, 2017 at 09:41:48PM -0400, Geoff Lansberry wrote: Hi Geoff. > In prior commits the selected clock frequency does not propagate > correctly to what is written the the TRF7970A_MODULATOR_SYS_CLK_CTRL > register. > > Signed-off-by: Geoff Lansberry > --- > drivers/nfc/trf7970a.c |

Re: [PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function

On Tue, Apr 25, 2017 at 12:20:54PM -0600, Logan Gunthorpe wrote: > Very straightforward conversion to the new function in the caam driver > and shash library. > > Signed-off-by: Logan Gunthorpe > Cc: Herbert Xu > Cc: "David S. Miller"

Re: [PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function

On Tue, Apr 25, 2017 at 12:20:54PM -0600, Logan Gunthorpe wrote: > Very straightforward conversion to the new function in the caam driver > and shash library. > > Signed-off-by: Logan Gunthorpe > Cc: Herbert Xu > Cc: "David S. Miller" > --- > crypto/shash.c| 9 ++--- >

Re: [PATCH] led: ledtrig-transient: replace timer_list with hrtimer

On Tue, Apr 25, 2017 at 1:15 PM, Jacek Anaszewski wrote: >> However, there's a need to >> support hrtimer if the LED subsystem claims support the use case of >> vibrator (please see Documentation/leds/ledtrig-transient.txt) as even >> a 5ms of variation is perceivable

Re: [PATCH] led: ledtrig-transient: replace timer_list with hrtimer

On Tue, Apr 25, 2017 at 1:15 PM, Jacek Anaszewski wrote: >> However, there's a need to >> support hrtimer if the LED subsystem claims support the use case of >> vibrator (please see Documentation/leds/ledtrig-transient.txt) as even >> a 5ms of variation is perceivable to the user. I'm thinking if

Re: TREE_SRCU slows hotplug by factor ~16

On Wed, 2017-04-26 at 20:12 +0200, Mike Galbraith wrote: > On Wed, 2017-04-26 at 10:56 -0700, Paul E. McKenney wrote: > > > > OK, I do need to do more work. My current guess is that I should have > > > set the default for srcutree.exp_holdoff to 25*1000 instead of 50*1000. > > > But I am sure

Re: TREE_SRCU slows hotplug by factor ~16

On Wed, 2017-04-26 at 20:12 +0200, Mike Galbraith wrote: > On Wed, 2017-04-26 at 10:56 -0700, Paul E. McKenney wrote: > > > > OK, I do need to do more work. My current guess is that I should have > > > set the default for srcutree.exp_holdoff to 25*1000 instead of 50*1000. > > > But I am sure

[GIT PULL rcu/urgent] Auto-expedite initial SRCU grace periods

Hello, Ingo, This series greatly reduces the performance degradation of Tree SRCU on a CPU-hotplug stress test. The effect was not subtle: Mike Galbraith measured Classic SRCU at 55 seconds and Tree SRCU at more than 16 -minutes- for this test. Mike collected ftrace data that showed that

[GIT PULL rcu/urgent] Auto-expedite initial SRCU grace periods

Hello, Ingo, This series greatly reduces the performance degradation of Tree SRCU on a CPU-hotplug stress test. The effect was not subtle: Mike Galbraith measured Classic SRCU at 55 seconds and Tree SRCU at more than 16 -minutes- for this test. Mike collected ftrace data that showed that

Re: [v6 PATCH 12/21] x86/insn: Support both signed 32-bit and 64-bit effective addresses

On Tue, 2017-04-25 at 15:51 +0200, Borislav Petkov wrote: > On Tue, Mar 07, 2017 at 04:32:45PM -0800, Ricardo Neri wrote: > > The 32-bit and 64-bit address encodings are identical. This means that we > > can use the same function in both cases. In order to reuse the function for > > 32-bit address

Re: [v6 PATCH 12/21] x86/insn: Support both signed 32-bit and 64-bit effective addresses

On Tue, 2017-04-25 at 15:51 +0200, Borislav Petkov wrote: > On Tue, Mar 07, 2017 at 04:32:45PM -0800, Ricardo Neri wrote: > > The 32-bit and 64-bit address encodings are identical. This means that we > > can use the same function in both cases. In order to reuse the function for > > 32-bit address

linux-next: manual merge of the kvms390 tree with the s390 tree

Hi all, Today's linux-next merge of the kvms390 tree got a conflict in: arch/s390/include/asm/cpacf.h between commit: 985a9d20daa6 ("s390/crypto: Renaming PPNO to PRNO.") from the s390 tree and commit: 152c1c8d60eb ("s390/cpacf: Introduce kma instruction") from the kvms390 tree. I

linux-next: manual merge of the kvms390 tree with the s390 tree

Hi all, Today's linux-next merge of the kvms390 tree got a conflict in: arch/s390/include/asm/cpacf.h between commit: 985a9d20daa6 ("s390/crypto: Renaming PPNO to PRNO.") from the s390 tree and commit: 152c1c8d60eb ("s390/cpacf: Introduce kma instruction") from the kvms390 tree. I

Re: [PATCH v6 2/5] firmware: add extensible driver data API

On Tue, Apr 11, 2017 at 05:01:51PM +0900, takahiro.aka...@linaro.org wrote: > On Mon, Apr 10, 2017 at 12:42:44PM +, Coelho, Luciano wrote: > > On Wed, 2017-03-29 at 20:25 -0700, Luis R. Rodriguez wrote: > > > +Driver data request parameters > > > +== > > > + > > >

Re: [PATCH v6 2/5] firmware: add extensible driver data API

On Tue, Apr 11, 2017 at 05:01:51PM +0900, takahiro.aka...@linaro.org wrote: > On Mon, Apr 10, 2017 at 12:42:44PM +, Coelho, Luciano wrote: > > On Wed, 2017-03-29 at 20:25 -0700, Luis R. Rodriguez wrote: > > > +Driver data request parameters > > > +== > > > + > > >

Re: [PATCH v3 2/2] modules:capabilities: add a per-task modules autoload restriction

Djalal Harouni writes: > Hi Rusty, > > On Mon, Apr 24, 2017 at 6:29 AM, Rusty Russell wrote: >> Djalal Harouni writes: >>> When value is (1), task must have CAP_SYS_MODULE to be able to trigger a >>> module auto-load operation, or

Re: [PATCH v3 2/2] modules:capabilities: add a per-task modules autoload restriction

Djalal Harouni writes: > Hi Rusty, > > On Mon, Apr 24, 2017 at 6:29 AM, Rusty Russell wrote: >> Djalal Harouni writes: >>> When value is (1), task must have CAP_SYS_MODULE to be able to trigger a >>> module auto-load operation, or CAP_NET_ADMIN for modules with a >>> 'netdev-%s' alias. >> >>

Re: [PATCH v6 2/5] firmware: add extensible driver data API

On Mon, Apr 10, 2017 at 12:42:44PM +, Coelho, Luciano wrote: > On Wed, 2017-03-29 at 20:25 -0700, Luis R. Rodriguez wrote: > > The firmware API does not scale well: when new features are added we > > either add a new exported symbol or extend the arguments of existing > > routines. For the

Re: [PATCH v6 2/5] firmware: add extensible driver data API

On Mon, Apr 10, 2017 at 12:42:44PM +, Coelho, Luciano wrote: > On Wed, 2017-03-29 at 20:25 -0700, Luis R. Rodriguez wrote: > > The firmware API does not scale well: when new features are added we > > either add a new exported symbol or extend the arguments of existing > > routines. For the

[PATCH] um: Fix to call read_initrd after init_bootmem

Since read_initrd() invokes alloc_bootmem() for allocating memory to load initrd image, it must be called after init_bootmem. This makes read_initrd() called directly from setup_arch() after init_bootmem() and mem_total_pages(). Signed-off-by: Masami Hiramatsu ---

[PATCH] um: Fix to call read_initrd after init_bootmem

Since read_initrd() invokes alloc_bootmem() for allocating memory to load initrd image, it must be called after init_bootmem. This makes read_initrd() called directly from setup_arch() after init_bootmem() and mem_total_pages(). Signed-off-by: Masami Hiramatsu --- arch/um/kernel/initrd.c |

[BUG] um: initramfs doesn't work on uml

Hello, I found that user-mode-linux kernel doesn't boot with initramfs (or initrd) as below. I've investigated the reason and found that the read_initrd@arch/um/kernel/initrd.c tried to allocate memory for initrd by using alloc_bootmem, but since init_bootmem will be called from setup_arch

[BUG] um: initramfs doesn't work on uml

Hello, I found that user-mode-linux kernel doesn't boot with initramfs (or initrd) as below. I've investigated the reason and found that the read_initrd@arch/um/kernel/initrd.c tried to allocate memory for initrd by using alloc_bootmem, but since init_bootmem will be called from setup_arch

[PATCH] mm/vmstat: Standardize file operations variable names

Standardized the file operation variable names related to all four memory management /proc interface files. Also changed all the symbol permissions (S_IRUGO) into octal permissions (0444) as it got complains from checkpatch.pl script. This does not create any functional change to the interface.

[PATCH] mm/vmstat: Standardize file operations variable names

Standardized the file operation variable names related to all four memory management /proc interface files. Also changed all the symbol permissions (S_IRUGO) into octal permissions (0444) as it got complains from checkpatch.pl script. This does not create any functional change to the interface.

Re: [PATCH v4 1/3] kexec: Move vmcoreinfo out of the kernel's .bss section

[snip] > >>> > >>> static int __init crash_save_vmcoreinfo_init(void) > >>> { > >>> + /* One page should be enough for VMCOREINFO_BYTES under all archs */ > >> Can we add a comment in the VMCOREINFO_BYTES header file about the one > >> page assumption? > >> > >> Or just define the

Re: [PATCH v4 1/3] kexec: Move vmcoreinfo out of the kernel's .bss section

[snip] > >>> > >>> static int __init crash_save_vmcoreinfo_init(void) > >>> { > >>> + /* One page should be enough for VMCOREINFO_BYTES under all archs */ > >> Can we add a comment in the VMCOREINFO_BYTES header file about the one > >> page assumption? > >> > >> Or just define the

Re: [PATCH v4 3/3] kdump: Protect vmcoreinfo data under the crash memory

[snip] > >> index 43cdb00..a29e9ad 100644 > >> --- a/kernel/crash_core.c > >> +++ b/kernel/crash_core.c > >> @@ -15,9 +15,12 @@ > >> > >> /* vmcoreinfo stuff */ > >> static unsigned char *vmcoreinfo_data; > >> -size_t vmcoreinfo_size; > >> +static size_t vmcoreinfo_size; > >> u32

Re: [PATCH v4 3/3] kdump: Protect vmcoreinfo data under the crash memory

[snip] > >> index 43cdb00..a29e9ad 100644 > >> --- a/kernel/crash_core.c > >> +++ b/kernel/crash_core.c > >> @@ -15,9 +15,12 @@ > >> > >> /* vmcoreinfo stuff */ > >> static unsigned char *vmcoreinfo_data; > >> -size_t vmcoreinfo_size; > >> +static size_t vmcoreinfo_size; > >> u32

[ANNOUNCE] Git v2.13.0-rc1

A release candidate Git v2.13.0-rc1 is now available for testing at the usual places. It is comprised of 684 non-merge commits since v2.12.0, contributed by 54 people, 13 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The following

[ANNOUNCE] Git v2.13.0-rc1

A release candidate Git v2.13.0-rc1 is now available for testing at the usual places. It is comprised of 684 non-merge commits since v2.12.0, contributed by 54 people, 13 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The following

[PATCH v2] plugin python: Adjust the handling after PyRun_String() failed

Even though PyRun_String() failed, just 0 will be returned but we need to return -1 that means error status, so fix it. Signed-off-by: Taeung Song --- plugin_python.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/plugin_python.c b/plugin_python.c

[PATCH v2] plugin python: Adjust the handling after PyRun_String() failed

Even though PyRun_String() failed, just 0 will be returned but we need to return -1 that means error status, so fix it. Signed-off-by: Taeung Song --- plugin_python.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/plugin_python.c b/plugin_python.c index 2997679..c283ed7

Re: [PATCH] powerpc/mm/hugetlb: Add support for 1G huge pages

Anshuman Khandual writes: > On 04/17/2017 10:44 PM, Aneesh Kumar K.V wrote: >> POWER9 supports hugepages of size 2M and 1G in radix MMU mode. This patch >> enables the usage of 1G page size for hugetlbfs. This also update the helper >> such we can do 1G page

Re: [PATCH] powerpc/mm/hugetlb: Add support for 1G huge pages

Anshuman Khandual writes: > On 04/17/2017 10:44 PM, Aneesh Kumar K.V wrote: >> POWER9 supports hugepages of size 2M and 1G in radix MMU mode. This patch >> enables the usage of 1G page size for hugetlbfs. This also update the helper >> such we can do 1G page allocation at runtime. >> >> Since

Re: [PATCH] plugin python: Adjust the handling after PyRun_String() failed

On 04/27/2017 11:47 AM, Steven Rostedt wrote: On Thu, 27 Apr 2017 08:46:21 +0900 Taeung Song wrote: Even though PyRun_String() failed, just 0 will be returned but we need to return -1 that means error status, so fix it. Signed-off-by: Taeung Song

Re: [PATCH] plugin python: Adjust the handling after PyRun_String() failed

On 04/27/2017 11:47 AM, Steven Rostedt wrote: On Thu, 27 Apr 2017 08:46:21 +0900 Taeung Song wrote: Even though PyRun_String() failed, just 0 will be returned but we need to return -1 that means error status, so fix it. Signed-off-by: Taeung Song --- plugin_python.c | 5 +++-- 1 file

Re: [PATCH] plugin python: Adjust the handling after PyRun_String() failed

On Thu, 27 Apr 2017 08:46:21 +0900 Taeung Song wrote: > Even though PyRun_String() failed, > just 0 will be returned but we need to return -1 > that means error status, so fix it. > > Signed-off-by: Taeung Song > --- > plugin_python.c | 5

Re: [PATCH] plugin python: Adjust the handling after PyRun_String() failed

On Thu, 27 Apr 2017 08:46:21 +0900 Taeung Song wrote: > Even though PyRun_String() failed, > just 0 will be returned but we need to return -1 > that means error status, so fix it. > > Signed-off-by: Taeung Song > --- > plugin_python.c | 5 +++-- > 1 file changed, 3 insertions(+), 2

Re: linux-next: build warning after merge of the sound-asoc tree

On Thu, Apr 27, 2017 at 11:29:20AM +1000, Stephen Rothwell wrote: > Hi all, > > After merging the sound-asoc tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > sound/soc/intel/skylake/bxt-sst.c: In function 'bxt_sst_dsp_init': >

Re: linux-next: build warning after merge of the sound-asoc tree

On Thu, Apr 27, 2017 at 11:29:20AM +1000, Stephen Rothwell wrote: > Hi all, > > After merging the sound-asoc tree, today's linux-next build (x86_64 > allmodconfig) produced this warning: > > sound/soc/intel/skylake/bxt-sst.c: In function 'bxt_sst_dsp_init': >

Re: [PATCH] kallsyms: optimize kallsyms_lookup_name() for a few cases

On Thu, 27 Apr 2017 01:38:10 +0530 "Naveen N. Rao" wrote: > Michael Ellerman wrote: > > "Naveen N. Rao" writes: > >> diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c > >> index 6a3b249a2ae1..d134b060564f 100644 > >> ---

Re: [PATCH] kallsyms: optimize kallsyms_lookup_name() for a few cases

On Thu, 27 Apr 2017 01:38:10 +0530 "Naveen N. Rao" wrote: > Michael Ellerman wrote: > > "Naveen N. Rao" writes: > >> diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c > >> index 6a3b249a2ae1..d134b060564f 100644 > >> --- a/kernel/kallsyms.c > >> +++ b/kernel/kallsyms.c > >> @@ -205,6 +205,12

  1   2   3   4   5   6   7   8   9   10   >