Re: [PATCH RFC] hugetlbfs 'noautofill' mount option

On 5/3/17 12:02 PM, Prakash Sangappa wrote: On 5/2/17 4:43 PM, Dave Hansen wrote: Ideally, it would be something that is *not* specifically for hugetlbfs. MADV_NOAUTOFILL, for instance, could be defined to SIGSEGV whenever memory is touched that was not populated with MADV_WILLNEED,

Re: [PATCH RFC] hugetlbfs 'noautofill' mount option

On 5/3/17 12:02 PM, Prakash Sangappa wrote: On 5/2/17 4:43 PM, Dave Hansen wrote: Ideally, it would be something that is *not* specifically for hugetlbfs. MADV_NOAUTOFILL, for instance, could be defined to SIGSEGV whenever memory is touched that was not populated with MADV_WILLNEED,

Re: [PATCH v4 3/5] soc: qcom: Introduce APCS IPC driver

On Fri 05 May 21:48 PDT 2017, Jassi Brar wrote: > On Sat, May 6, 2017 at 6:49 AM, Bjorn Andersson > wrote: > > On Fri 05 May 13:22 PDT 2017, Jassi Brar wrote: > > >> How is it supposed to work if a client queues more than one request? > > > > One such example is

Re: [PATCH v4 3/5] soc: qcom: Introduce APCS IPC driver

On Fri 05 May 21:48 PDT 2017, Jassi Brar wrote: > On Sat, May 6, 2017 at 6:49 AM, Bjorn Andersson > wrote: > > On Fri 05 May 13:22 PDT 2017, Jassi Brar wrote: > > >> How is it supposed to work if a client queues more than one request? > > > > One such example is found in patch 5 in this series.

[V4] staging : rtl8188eu : remove void function return

kernel coding style doesn't allow the return statement in void function. Signed-off-by: Surender Polsani --- Changes for v2: corrected subject line as suggested Changes for v3: modified from line as suggested by Greg KH placed a semicolon in label for fixing build

[V4] staging : rtl8188eu : remove void function return

kernel coding style doesn't allow the return statement in void function. Signed-off-by: Surender Polsani --- Changes for v2: corrected subject line as suggested Changes for v3: modified from line as suggested by Greg KH placed a semicolon in label for fixing build error Changes for v4: changes

Re: [PATCH v2 1/5] pinctrl: qcom: Add ipq8074 pinctrl driver

+ Bjorn Andersson On 5/4/2017 5:23 PM, Varadarajan Narayanan wrote: Add initial pinctrl driver to support pin configuration with pinctrl framework for ipq8074. Signed-off-by: Manoharan Vijaya Raghavan Signed-off-by: Varadarajan Narayanan ---

Re: [PATCH v2 1/5] pinctrl: qcom: Add ipq8074 pinctrl driver

+ Bjorn Andersson On 5/4/2017 5:23 PM, Varadarajan Narayanan wrote: Add initial pinctrl driver to support pin configuration with pinctrl framework for ipq8074. Signed-off-by: Manoharan Vijaya Raghavan Signed-off-by: Varadarajan Narayanan --- .../bindings/pinctrl/qcom,ipq8074-pinctrl.txt

[PATCH] regulator: max8997/8966: fix charger cv voltage set bug

When min charger-CV is <= 4.0V and max charger-CV is >= 4.0V, we can use 4.00V as CV (register value = 0x1).` The original code had a typo that wrote ">=" (max_uV >= 400), which should've been "<", which is not necessary anyway as mentioned by Dan Carpenter. Reported-By: Dan Carpenter

[PATCH] regulator: max8997/8966: fix charger cv voltage set bug

When min charger-CV is <= 4.0V and max charger-CV is >= 4.0V, we can use 4.00V as CV (register value = 0x1).` The original code had a typo that wrote ">=" (max_uV >= 400), which should've been "<", which is not necessary anyway as mentioned by Dan Carpenter. Reported-By: Dan Carpenter

Re: [PATCH 4.10 0/5] 4.10.15-stable review

On Sun, May 07, 2017 at 12:38:53PM -0700, Guenter Roeck wrote: > On 05/06/2017 01:39 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.10.15 release. > > There are 5 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH 4.10 0/5] 4.10.15-stable review

On Sun, May 07, 2017 at 12:38:53PM -0700, Guenter Roeck wrote: > On 05/06/2017 01:39 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 4.10.15 release. > > There are 5 patches in this series, all will be posted as a response > > to this one. If anyone has any

Re: [PATCH] staging: iio: meter: This patch fixes warnings found in ade7753.c

On Mon, May 08, 2017 at 01:38:47AM -0400, harinath Nampally wrote: > Hi Greg, > > Thank you so much for your time to review.  > Sure I will break up into multiple patches and create patch series. > But I wonder 'one thing' per patch means one kind of warnings per patch? Yes it does. > For

Re: [PATCH] staging: iio: meter: This patch fixes warnings found in ade7753.c

On Mon, May 08, 2017 at 01:38:47AM -0400, harinath Nampally wrote: > Hi Greg, > > Thank you so much for your time to review.  > Sure I will break up into multiple patches and create patch series. > But I wonder 'one thing' per patch means one kind of warnings per patch? Yes it does. > For

Re: [PATCH V6 1/9] PM / OPP: Introduce "power-domain-opp" property

On 05/08/2017 09:45 AM, Viresh Kumar wrote: > On 06-05-17, 11:58, Kevin Hilman wrote: >> Rob Herring writes: >> >>> On Wed, Apr 26, 2017 at 04:27:05PM +0530, Viresh Kumar wrote: Power-domains need to express their active states in DT and the devices within the

Re: [PATCH V6 1/9] PM / OPP: Introduce "power-domain-opp" property

On 05/08/2017 09:45 AM, Viresh Kumar wrote: > On 06-05-17, 11:58, Kevin Hilman wrote: >> Rob Herring writes: >> >>> On Wed, Apr 26, 2017 at 04:27:05PM +0530, Viresh Kumar wrote: Power-domains need to express their active states in DT and the devices within the power-domain need to

Re: [PATCH 7/7] DWARF: add the config option

On Sun, May 7, 2017 at 9:55 AM, Josh Poimboeuf wrote: > On Fri, May 05, 2017 at 12:57:11PM -0700, Linus Torvalds wrote: >> On Fri, May 5, 2017 at 5:22 AM, Jiri Slaby wrote: >> > The DWARF unwinder is in place and ready. So introduce the config option >> > to

Re: [PATCH 7/7] DWARF: add the config option

On Sun, May 7, 2017 at 9:55 AM, Josh Poimboeuf wrote: > On Fri, May 05, 2017 at 12:57:11PM -0700, Linus Torvalds wrote: >> On Fri, May 5, 2017 at 5:22 AM, Jiri Slaby wrote: >> > The DWARF unwinder is in place and ready. So introduce the config option >> > to allow users to enable it. It is by

Re: [lkp-robot] [generic_file_read_iter()] 5ecda13711: BUG:KASAN:stack-out-of-bounds

On Mon, May 08, 2017 at 09:22:38AM +0800, kernel test robot wrote: > > FYI, we noticed the following commit: > > commit: 5ecda13711b3bd4a750b5740897bf13d1720de7c ("generic_file_read_iter(): > make use of iov_iter_revert()") > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git

Re: [lkp-robot] [generic_file_read_iter()] 5ecda13711: BUG:KASAN:stack-out-of-bounds

On Mon, May 08, 2017 at 09:22:38AM +0800, kernel test robot wrote: > > FYI, we noticed the following commit: > > commit: 5ecda13711b3bd4a750b5740897bf13d1720de7c ("generic_file_read_iter(): > make use of iov_iter_revert()") > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git

Issues with make-kpkg while compiling Linux Kernel From Source.

Hi, A file named "REPORTING-BUGS" is moved (and renamed and edited) to "Documentation/admin-guide/reporting-bugs.rst" as on linux kernel version v4.10. (As mentioned in conversation with Randy Dunlap in lkml) The command make-kpkg fails to build, the command that i used was, "fakeroot make-kpkg

Issues with make-kpkg while compiling Linux Kernel From Source.

Hi, A file named "REPORTING-BUGS" is moved (and renamed and edited) to "Documentation/admin-guide/reporting-bugs.rst" as on linux kernel version v4.10. (As mentioned in conversation with Randy Dunlap in lkml) The command make-kpkg fails to build, the command that i used was, "fakeroot make-kpkg

Re: [RFC][PATCH v3 2/2] cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely

2017-05-08 12:01 GMT+08:00 Viresh Kumar : > On 08-05-17, 11:49, Wanpeng Li wrote: >> Hi Rafael, >> 2017-03-22 7:08 GMT+08:00 Rafael J. Wysocki : >> > From: Rafael J. Wysocki >> > >> > The way the schedutil governor uses the

Re: [RFC][PATCH v3 2/2] cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely

2017-05-08 12:01 GMT+08:00 Viresh Kumar : > On 08-05-17, 11:49, Wanpeng Li wrote: >> Hi Rafael, >> 2017-03-22 7:08 GMT+08:00 Rafael J. Wysocki : >> > From: Rafael J. Wysocki >> > >> > The way the schedutil governor uses the PELT metric causes it to >> > underestimate the CPU utilization in some

[stable-4.10: PATCH] xen: revert commits 72a9b186292 and da72ff5bfcb0

Revert commit 72a9b186292 ("xen: Remove event channel notification through Xen PCI platform device") as the original analysis was wrong that all the removed code isn't in use any more. As commit da72ff5bfcb0 ("partially revert xen: Remove event channel notification through Xen PCI platform

[stable-4.10: PATCH] xen: revert commits 72a9b186292 and da72ff5bfcb0

Revert commit 72a9b186292 ("xen: Remove event channel notification through Xen PCI platform device") as the original analysis was wrong that all the removed code isn't in use any more. As commit da72ff5bfcb0 ("partially revert xen: Remove event channel notification through Xen PCI platform

[stable-4.9: PATCH] xen: revert commit 72a9b186292

Revert commit 72a9b186292 ("xen: Remove event channel notification through Xen PCI platform device") as the original analysis was wrong that all the removed code isn't in use any more. It is still necessary for old Xen versions (< 4.0) and for being able to run the Linux kernel as dom0 in a

[stable-4.9: PATCH] xen: revert commit 72a9b186292

Revert commit 72a9b186292 ("xen: Remove event channel notification through Xen PCI platform device") as the original analysis was wrong that all the removed code isn't in use any more. It is still necessary for old Xen versions (< 4.0) and for being able to run the Linux kernel as dom0 in a

Re: [RFC PATCH] x86/boot: Add the secdata section to the setup header

On Sat, May 06, 2017 at 01:12:10AM -0700, h...@zytor.com wrote: > On May 5, 2017 2:26:39 AM PDT, Gary Lin wrote: > >This is a different approach to replace my previous implementation of > >Security Version(*). Instead of using the fields in the PE/COFF header, > >this commit adds

Re: [RFC PATCH] x86/boot: Add the secdata section to the setup header

On Sat, May 06, 2017 at 01:12:10AM -0700, h...@zytor.com wrote: > On May 5, 2017 2:26:39 AM PDT, Gary Lin wrote: > >This is a different approach to replace my previous implementation of > >Security Version(*). Instead of using the fields in the PE/COFF header, > >this commit adds secdata_offset

linux-next: Tree for May 8

Hi all, Please do not add any v4.13 destined material in your linux-next included branches until after v4.12-rc1 has been released. Changes since 20170505: The akpm-current tree gained a conflict against Linus' tree. Non-merge commits (relative to Linus' tree): 2723 2661 files changed, 96043

linux-next: Tree for May 8

Hi all, Please do not add any v4.13 destined material in your linux-next included branches until after v4.12-rc1 has been released. Changes since 20170505: The akpm-current tree gained a conflict against Linus' tree. Non-merge commits (relative to Linus' tree): 2723 2661 files changed, 96043

Re: 64fa03de33: BUG:Dentry_still_in_use

>From 6a3fb632f67f8425c6e76c65dad8115f1550d2a0 Mon Sep 17 00:00:00 2001 From: Serge Hallyn Date: Sun, 7 May 2017 23:40:42 -0500 Subject: [PATCH 1/1] cap_inode_getsecurity: don't pin dentry (fold up) This should fix the "Dentry_still_in_use" reported by the kernel test robot.

Re: 64fa03de33: BUG:Dentry_still_in_use

>From 6a3fb632f67f8425c6e76c65dad8115f1550d2a0 Mon Sep 17 00:00:00 2001 From: Serge Hallyn Date: Sun, 7 May 2017 23:40:42 -0500 Subject: [PATCH 1/1] cap_inode_getsecurity: don't pin dentry (fold up) This should fix the "Dentry_still_in_use" reported by the kernel test robot. Signed-off-by:

Re: [PATCH] staging: iio: meter: This patch fixes warnings found in ade7753.c

On Mon, May 08, 2017 at 12:16:17AM -0400, Harinath Nampally wrote: > All below warnings are found and fixed by checkpatch.pl: > CHECK: struct mutex definition without comment > CHECK: Alignment should match open parenthesis > WARNING: Symbolic permissions 'S_IWUSR | S_IRUGO' are not preferred.

Re: [PATCH] staging: iio: meter: This patch fixes warnings found in ade7753.c

On Mon, May 08, 2017 at 12:16:17AM -0400, Harinath Nampally wrote: > All below warnings are found and fixed by checkpatch.pl: > CHECK: struct mutex definition without comment > CHECK: Alignment should match open parenthesis > WARNING: Symbolic permissions 'S_IWUSR | S_IRUGO' are not preferred.

[PATCH V5 resend] PM / OPP: Use - instead of @ for DT entries

Compiling the DT file with W=1, DTC warns like follows: Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a unit name, but no reg property Fix this by replacing '@' with '-' as the OPP nodes will never have a "reg" property. Reported-by: Krzysztof Kozlowski

[PATCH V5 resend] PM / OPP: Use - instead of @ for DT entries

Compiling the DT file with W=1, DTC warns like follows: Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a unit name, but no reg property Fix this by replacing '@' with '-' as the OPP nodes will never have a "reg" property. Reported-by: Krzysztof Kozlowski Reported-by:

Re: [PATCH v3 1/2] thermal: core: Allow orderly_poweroff to be called only once

On Monday 08 May 2017 02:32 AM, Pavel Machek wrote: >> thermal_zone_device_check --> thermal_zone_device_update --> >> handle_thermal_trip --> handle_critical_trips --> orderly_poweroff >> >> The above sequence happens every 250/500 mS based on the configuration. >> The orderly_poweroff function

Re: [PATCH v3 1/2] thermal: core: Allow orderly_poweroff to be called only once

On Monday 08 May 2017 02:32 AM, Pavel Machek wrote: >> thermal_zone_device_check --> thermal_zone_device_update --> >> handle_thermal_trip --> handle_critical_trips --> orderly_poweroff >> >> The above sequence happens every 250/500 mS based on the configuration. >> The orderly_poweroff function

Re: [PATCH 6/6] dt-bindings: cpufreq: enhance Mediatek cpufreq dt-binding document

On 05-05-17, 23:26, sean.w...@mediatek.com wrote: > From: Sean Wang > > Update binding document to reflect the lastest driver logic and The bindings don't follow the drivers but its the other way around. Don't mention anything about the drivers in the bindings patches.

Re: [PATCH 6/6] dt-bindings: cpufreq: enhance Mediatek cpufreq dt-binding document

On 05-05-17, 23:26, sean.w...@mediatek.com wrote: > From: Sean Wang > > Update binding document to reflect the lastest driver logic and The bindings don't follow the drivers but its the other way around. Don't mention anything about the drivers in the bindings patches. > add more examples

Re: [PATCH 5/6] dt-bindings: cpufreq: move Mediatek cpufreq dt-bindings document to proper place

On 05-05-17, 23:26, sean.w...@mediatek.com wrote: > From: Sean Wang > > The old place is Documentation/devicetree/bindings/clock/ that would > let people hard to find how to use Mediatek cpufreq driver, so moving > it to the new place as other cpufreq dirvers are done

Re: [PATCH 5/6] dt-bindings: cpufreq: move Mediatek cpufreq dt-bindings document to proper place

On 05-05-17, 23:26, sean.w...@mediatek.com wrote: > From: Sean Wang > > The old place is Documentation/devicetree/bindings/clock/ that would > let people hard to find how to use Mediatek cpufreq driver, so moving > it to the new place as other cpufreq dirvers are done would be better. > >

Re: [PATCH V6 1/9] PM / OPP: Introduce "power-domain-opp" property

On 06-05-17, 11:58, Kevin Hilman wrote: > Rob Herring writes: > > > On Wed, Apr 26, 2017 at 04:27:05PM +0530, Viresh Kumar wrote: > >> Power-domains need to express their active states in DT and the devices > >> within the power-domain need to express their dependency on those

[PATCH] staging: iio: meter: This patch fixes warnings found in ade7753.c

All below warnings are found and fixed by checkpatch.pl: CHECK: struct mutex definition without comment CHECK: Alignment should match open parenthesis WARNING: Symbolic permissions 'S_IWUSR | S_IRUGO' are not preferred. Below errors are false positives: ade7753.c:382: ERROR: Use 4 digit octal

Re: [PATCH V6 1/9] PM / OPP: Introduce "power-domain-opp" property

On 06-05-17, 11:58, Kevin Hilman wrote: > Rob Herring writes: > > > On Wed, Apr 26, 2017 at 04:27:05PM +0530, Viresh Kumar wrote: > >> Power-domains need to express their active states in DT and the devices > >> within the power-domain need to express their dependency on those active > >>

[PATCH] staging: iio: meter: This patch fixes warnings found in ade7753.c

All below warnings are found and fixed by checkpatch.pl: CHECK: struct mutex definition without comment CHECK: Alignment should match open parenthesis WARNING: Symbolic permissions 'S_IWUSR | S_IRUGO' are not preferred. Below errors are false positives: ade7753.c:382: ERROR: Use 4 digit octal

Re: [RFC][PATCH v3 2/2] cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely

On 08-05-17, 11:49, Wanpeng Li wrote: > Hi Rafael, > 2017-03-22 7:08 GMT+08:00 Rafael J. Wysocki : > > From: Rafael J. Wysocki > > > > The way the schedutil governor uses the PELT metric causes it to > > underestimate the CPU utilization in some

Re: [RFC][PATCH v3 2/2] cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely

On 08-05-17, 11:49, Wanpeng Li wrote: > Hi Rafael, > 2017-03-22 7:08 GMT+08:00 Rafael J. Wysocki : > > From: Rafael J. Wysocki > > > > The way the schedutil governor uses the PELT metric causes it to > > underestimate the CPU utilization in some cases. > > > > That can be easily demonstrated by

Re: [RFC][PATCH v3 2/2] cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely

Hi Rafael, 2017-03-22 7:08 GMT+08:00 Rafael J. Wysocki : > From: Rafael J. Wysocki > > The way the schedutil governor uses the PELT metric causes it to > underestimate the CPU utilization in some cases. > > That can be easily demonstrated by running

Re: [RFC][PATCH v3 2/2] cpufreq: schedutil: Avoid reducing frequency of busy CPUs prematurely

Hi Rafael, 2017-03-22 7:08 GMT+08:00 Rafael J. Wysocki : > From: Rafael J. Wysocki > > The way the schedutil governor uses the PELT metric causes it to > underestimate the CPU utilization in some cases. > > That can be easily demonstrated by running kernel compilation on > a Sandy Bridge Intel

linux-next: manual merge of the akpm-current tree with Linus' tree

Hi Andrew, Today's linux-next merge of the akpm-current tree got a conflict in: init/initramfs.c between commit: 17a9be317475 ("initramfs: Always do fput() and load modules after rootfs populate") from Linus' tree and commit: c25cfb52513b ("initramfs: provide a way to ignore image

linux-next: manual merge of the akpm-current tree with Linus' tree

Hi Andrew, Today's linux-next merge of the akpm-current tree got a conflict in: init/initramfs.c between commit: 17a9be317475 ("initramfs: Always do fput() and load modules after rootfs populate") from Linus' tree and commit: c25cfb52513b ("initramfs: provide a way to ignore image

Re: [PATCH 1/2] mtd: nand: add generic helpers to check, match, maximize ECC settings

Hi Boris, 2017-04-29 1:32 GMT+09:00 Boris Brezillon : >> + for (setting = caps->ecc_settings; setting->step; setting++) { >> + /* If chip->ecc.size is already set, respect it. */ >> + if (chip->ecc.size && setting->step !=

Re: [PATCH 1/2] mtd: nand: add generic helpers to check, match, maximize ECC settings

Hi Boris, 2017-04-29 1:32 GMT+09:00 Boris Brezillon : >> + for (setting = caps->ecc_settings; setting->step; setting++) { >> + /* If chip->ecc.size is already set, respect it. */ >> + if (chip->ecc.size && setting->step != chip->ecc.size) >> +

Re: [PATCH v2] x86/efi: Correct ident mapping of efi old_map when kalsr enabled

On Sat, May 06, 2017 at 01:36:20AM +0200, Borislav Petkov wrote: > On Fri, May 05, 2017 at 09:42:14PM +0100, Matt Fleming wrote: > > (Including the folks from SGI since this was hit on a UV system) > > Wasn't there a BIOS fix supplied at some point which obviated the need > to boot with

Re: [Patch v3] x86/build: don't add -maccumulate-outgoing-args w/o compiler support

On Fri, May 05, 2017 at 08:05:09PM -0700, Nick Desaulniers wrote: > Clang does not support this machine dependent option. > > Older versions of GCC (pre 3.0) may not support this option, added in > 2000, but it's unlikely they can still compile the kernel. > > Signed-off-by: Nick Desaulniers

Re: [PATCH v2] x86/efi: Correct ident mapping of efi old_map when kalsr enabled

On Sat, May 06, 2017 at 01:36:20AM +0200, Borislav Petkov wrote: > On Fri, May 05, 2017 at 09:42:14PM +0100, Matt Fleming wrote: > > (Including the folks from SGI since this was hit on a UV system) > > Wasn't there a BIOS fix supplied at some point which obviated the need > to boot with

Re: [Patch v3] x86/build: don't add -maccumulate-outgoing-args w/o compiler support

On Fri, May 05, 2017 at 08:05:09PM -0700, Nick Desaulniers wrote: > Clang does not support this machine dependent option. > > Older versions of GCC (pre 3.0) may not support this option, added in > 2000, but it's unlikely they can still compile the kernel. > > Signed-off-by: Nick Desaulniers >

RE: [PATCH v2] x86, uaccess: introduce copy_from_iter_wt for pmem / writethrough operations

> * Dan Williams wrote: > > > On Sat, May 6, 2017 at 2:46 AM, Ingo Molnar wrote: > > > > > > * Dan Williams wrote: > > > > > >> On Fri, May 5, 2017 at 3:44 PM, Kani, Toshimitsu > wrote: > > >> > On Fri,

RE: [PATCH v2] x86, uaccess: introduce copy_from_iter_wt for pmem / writethrough operations

> * Dan Williams wrote: > > > On Sat, May 6, 2017 at 2:46 AM, Ingo Molnar wrote: > > > > > > * Dan Williams wrote: > > > > > >> On Fri, May 5, 2017 at 3:44 PM, Kani, Toshimitsu > wrote: > > >> > On Fri, 2017-05-05 at 15:25 -0700, Dan Williams wrote: > > >> >> On Fri, May 5, 2017 at 1:39 PM,

Re: [PATCH v2 1/2] mm: Uncharge poisoned pages

On Tue, May 02, 2017 at 08:55:07PM +0200, Michal Hocko wrote: > On Tue 02-05-17 16:59:30, Laurent Dufour wrote: > > On 28/04/2017 15:48, Michal Hocko wrote: > [...] > > > This is getting quite hairy. What is the expected page count of the > > > hwpoison page? > > OK, so from the quick check of

Re: [PATCH v2 1/2] mm: Uncharge poisoned pages

On Tue, May 02, 2017 at 08:55:07PM +0200, Michal Hocko wrote: > On Tue 02-05-17 16:59:30, Laurent Dufour wrote: > > On 28/04/2017 15:48, Michal Hocko wrote: > [...] > > > This is getting quite hairy. What is the expected page count of the > > > hwpoison page? > > OK, so from the quick check of

Re: Missing File REPORTING-BUGS In Linux Kernel.

On 05/07/17 19:17, Anil Nair wrote: > Hi, > > Could not find the proper person hence putting it in general mailing > list, A file named "REPORTING-BUGS" is missing in the current release > of the linux kernel i.e. v4.11. > > I found this is when using debian tools to compile a latest release >

Re: Missing File REPORTING-BUGS In Linux Kernel.

On 05/07/17 19:17, Anil Nair wrote: > Hi, > > Could not find the proper person hence putting it in general mailing > list, A file named "REPORTING-BUGS" is missing in the current release > of the linux kernel i.e. v4.11. > > I found this is when using debian tools to compile a latest release >

[PATCH v2] perf report: Make --branch-history work without callgraphs(-g) option in perf record

perf record -b -g perf report --branch-history This merges the LBRs with the callgraphs. However it would be nice if it also works without callgraphs (-g) set in perf record, so that only the LBRs are displayed. But currently perf report errors in this case. For example, perf record -b perf

[PATCH v2] perf report: Make --branch-history work without callgraphs(-g) option in perf record

perf record -b -g perf report --branch-history This merges the LBRs with the callgraphs. However it would be nice if it also works without callgraphs (-g) set in perf record, so that only the LBRs are displayed. But currently perf report errors in this case. For example, perf record -b perf

Re: [PATCH v3] x86/mm: Fix incorrect for loop count calculation in sync_global_pgds

On 05/04/17 at 09:25am, Thomas Garnier wrote: > > I think this needs a "Fixes:" tag and Cc: . Sorry for late response, should I resend with them? > > Agreed. > > > > > Other than that: > > > > Reviewed-by: Dan Williams > > Thanks again! > >

Re: [PATCH v3] x86/mm: Fix incorrect for loop count calculation in sync_global_pgds

On 05/04/17 at 09:25am, Thomas Garnier wrote: > > I think this needs a "Fixes:" tag and Cc: . Sorry for late response, should I resend with them? > > Agreed. > > > > > Other than that: > > > > Reviewed-by: Dan Williams > > Thanks again! > > Reviewed-by: Thomas Garnier > -- > Thomas

Missing File REPORTING-BUGS In Linux Kernel.

Hi, Could not find the proper person hence putting it in general mailing list, A file named "REPORTING-BUGS" is missing in the current release of the linux kernel i.e. v4.11. I found this is when using debian tools to compile a latest release using command, "fakeroot make-kpkg --initrd

Missing File REPORTING-BUGS In Linux Kernel.

Hi, Could not find the proper person hence putting it in general mailing list, A file named "REPORTING-BUGS" is missing in the current release of the linux kernel i.e. v4.11. I found this is when using debian tools to compile a latest release using command, "fakeroot make-kpkg --initrd

Re: [PATCH] ceph: Check that the new inode size is within limits in ceph_fallocate()

On Sat, May 6, 2017 at 1:28 AM, Luis Henriques wrote: > Currently the ceph client doesn't respect the rlimit in fallocate. This > means that a user can allocate a file with size > RLIMIT_FSIZE. This > patch adds the call to inode_newsize_ok() to verify filesystem limits and

Re: [PATCH] ceph: Check that the new inode size is within limits in ceph_fallocate()

On Sat, May 6, 2017 at 1:28 AM, Luis Henriques wrote: > Currently the ceph client doesn't respect the rlimit in fallocate. This > means that a user can allocate a file with size > RLIMIT_FSIZE. This > patch adds the call to inode_newsize_ok() to verify filesystem limits and > ulimits. This

Re: [PATCH] lightnvm: remove unused rq parameter of nvme_nvm_rqtocmd() to kill warning

On 05/07/2017 08:14 AM, Geert Uytterhoeven wrote: > With gcc 4.1.2: Wow, that's ancient. > drivers/nvme/host/lightnvm.c: In function ‘nvme_nvm_submit_io’: > drivers/nvme/host/lightnvm.c:498: warning: ‘rq’ is used uninitialized in > this function > > Indeed, since commit

Re: [PATCH] lightnvm: remove unused rq parameter of nvme_nvm_rqtocmd() to kill warning

On 05/07/2017 08:14 AM, Geert Uytterhoeven wrote: > With gcc 4.1.2: Wow, that's ancient. > drivers/nvme/host/lightnvm.c: In function ‘nvme_nvm_submit_io’: > drivers/nvme/host/lightnvm.c:498: warning: ‘rq’ is used uninitialized in > this function > > Indeed, since commit

Re: [PATCH] drm/i915: Make vblank evade warnings optional

On 05/07/2017 11:56 AM, Daniel Vetter wrote: > On Sun, May 7, 2017 at 7:46 PM, Jens Axboe wrote: >> On 05/07/2017 11:12 AM, ville.syrj...@linux.intel.com wrote: >>> From: Ville Syrjälä >>> >>> Add a new Kconfig option to enable/disable the extra

Re: [PATCH] drm/i915: Make vblank evade warnings optional

On 05/07/2017 11:56 AM, Daniel Vetter wrote: > On Sun, May 7, 2017 at 7:46 PM, Jens Axboe wrote: >> On 05/07/2017 11:12 AM, ville.syrj...@linux.intel.com wrote: >>> From: Ville Syrjälä >>> >>> Add a new Kconfig option to enable/disable the extra warnings >>> from the vblank evade code. For now

Re: [PATCH v2] block/mq: fix potential deadlock during cpu hotplug

On 05/07/2017 01:14 AM, Wanpeng Li wrote: > From: Wanpeng Li > > This can be triggered by hot-unplug one cpu. > > == > [ INFO: possible circular locking dependency detected ] > 4.11.0+ #17 Not tainted >

Re: [PATCH v2] block/mq: fix potential deadlock during cpu hotplug

On 05/07/2017 01:14 AM, Wanpeng Li wrote: > From: Wanpeng Li > > This can be triggered by hot-unplug one cpu. > > == > [ INFO: possible circular locking dependency detected ] > 4.11.0+ #17 Not tainted >

Re: [PATCH v2] x86/efi: Correct ident mapping of efi old_map when kalsr enabled

Thanks for explaining, Bhupesh. BIOS issue of SGI uv1 is still not fixed. There's a quirk for uv1 to use efi old map: void __init efi_apply_memmap_quirks(void) { ... ... /* UV2+ BIOS has a fix for this issue. UV1 still needs the quirk. */ if

Re: [PATCH v2] x86/efi: Correct ident mapping of efi old_map when kalsr enabled

Thanks for explaining, Bhupesh. BIOS issue of SGI uv1 is still not fixed. There's a quirk for uv1 to use efi old map: void __init efi_apply_memmap_quirks(void) { ... ... /* UV2+ BIOS has a fix for this issue. UV1 still needs the quirk. */ if

[PATCH 2/2] apparmorfs: Use seq_putc() in two functions

From: Markus Elfring Date: Sun, 7 May 2017 13:50:28 +0200 Two single characters (line breaks) should be put into a sequence. Thus use the corresponding function "seq_putc". This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring

[PATCH 1/2] apparmorfs: Combine two function calls into one in aa_fs_seq_raw_abi_show()

From: Markus Elfring Date: Sun, 7 May 2017 13:43:50 +0200 A bit of data was put into a sequence by two separate function calls. Print the same data by a single function call instead. Signed-off-by: Markus Elfring ---

[PATCH 2/2] apparmorfs: Use seq_putc() in two functions

From: Markus Elfring Date: Sun, 7 May 2017 13:50:28 +0200 Two single characters (line breaks) should be put into a sequence. Thus use the corresponding function "seq_putc". This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

[PATCH 1/2] apparmorfs: Combine two function calls into one in aa_fs_seq_raw_abi_show()

From: Markus Elfring Date: Sun, 7 May 2017 13:43:50 +0200 A bit of data was put into a sequence by two separate function calls. Print the same data by a single function call instead. Signed-off-by: Markus Elfring --- security/apparmor/apparmorfs.c | 7 +++ 1 file changed, 3 insertions(+),

[PATCH 0/2] apparmorfs: Fine-tuning for three function implementations

From: Markus Elfring Date: Sun, 7 May 2017 13:58:08 +0200 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Combine two function calls into one in aa_fs_seq_raw_abi_show() Use seq_putc() in two functions

[PATCH 0/2] apparmorfs: Fine-tuning for three function implementations

From: Markus Elfring Date: Sun, 7 May 2017 13:58:08 +0200 Two update suggestions were taken into account from static source code analysis. Markus Elfring (2): Combine two function calls into one in aa_fs_seq_raw_abi_show() Use seq_putc() in two functions security/apparmor/apparmorfs.c |

[lkp-robot] [generic_file_read_iter()] 5ecda13711: BUG:KASAN:stack-out-of-bounds

FYI, we noticed the following commit: commit: 5ecda13711b3bd4a750b5740897bf13d1720de7c ("generic_file_read_iter(): make use of iov_iter_revert()") https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master in testcase: ocfs2test with following parameters: disk: 1HDD

[lkp-robot] [generic_file_read_iter()] 5ecda13711: BUG:KASAN:stack-out-of-bounds

FYI, we noticed the following commit: commit: 5ecda13711b3bd4a750b5740897bf13d1720de7c ("generic_file_read_iter(): make use of iov_iter_revert()") https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master in testcase: ocfs2test with following parameters: disk: 1HDD

RE: [PATCH V3] cpuidle: check dev before usage in cpuidle_use_deepest_state

> >> Reviewed-by: Andy Shevchenko > >> Reviewed-by: Koul, Vinod > > > A previous version of this has been applied and I don't see any differences > > in the code changes. > > AFAIR only tags (above) had been extended in v3. Thanks. Yes,

RE: [PATCH V3] cpuidle: check dev before usage in cpuidle_use_deepest_state

> >> Reviewed-by: Andy Shevchenko > >> Reviewed-by: Koul, Vinod > > > A previous version of this has been applied and I don't see any differences > > in the code changes. > > AFAIR only tags (above) had been extended in v3. Thanks. Yes, for v3 no change in code, and only tags "Reviewed-by"

Re: [PATCH v6 2/7] perf/x86/intel: Record branch type

On 4/24/2017 8:47 AM, Jin, Yao wrote: On 4/23/2017 9:55 PM, Jiri Olsa wrote: On Thu, Apr 20, 2017 at 08:07:50PM +0800, Jin Yao wrote: SNIP +#define X86_BR_TYPE_MAP_MAX16 + +static int +common_branch_type(int type) +{ +int i, mask; +const int branch_map[X86_BR_TYPE_MAP_MAX]

Re: [PATCH v6 2/7] perf/x86/intel: Record branch type

On 4/24/2017 8:47 AM, Jin, Yao wrote: On 4/23/2017 9:55 PM, Jiri Olsa wrote: On Thu, Apr 20, 2017 at 08:07:50PM +0800, Jin Yao wrote: SNIP +#define X86_BR_TYPE_MAP_MAX16 + +static int +common_branch_type(int type) +{ +int i, mask; +const int branch_map[X86_BR_TYPE_MAP_MAX]

[PATCH] powerpc/mm: Use seq_putc() in two functions

From: Markus Elfring Date: Sun, 7 May 2017 16:32:04 +0200 Two single characters (line breaks) should be put into a sequence. Thus use the corresponding function "seq_putc". This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring

[PATCH] powerpc/mm: Use seq_putc() in two functions

From: Markus Elfring Date: Sun, 7 May 2017 16:32:04 +0200 Two single characters (line breaks) should be put into a sequence. Thus use the corresponding function "seq_putc". This issue was detected by using the Coccinelle software. Signed-off-by: Markus Elfring ---

Re: [PATCH 1/3] drm: fourcc byteorder: drop DRM_FORMAT_BIG_ENDIAN

On 03/05/17 06:24 PM, Gerd Hoffmann wrote: > Hi, > >>> R600+ supports bigendian framebuffer formats, so no byteswapping on >>> access is needed. Not sure whenever that includes 16bpp formats or >>> whenever this is limited to the 8 bit-per-color formats [...] >> >> It includes 16bpp. Looking

Re: [PATCH 1/3] drm: fourcc byteorder: drop DRM_FORMAT_BIG_ENDIAN

On 03/05/17 06:24 PM, Gerd Hoffmann wrote: > Hi, > >>> R600+ supports bigendian framebuffer formats, so no byteswapping on >>> access is needed. Not sure whenever that includes 16bpp formats or >>> whenever this is limited to the 8 bit-per-color formats [...] >> >> It includes 16bpp. Looking

[PATCH] [media] pvrusb2: remove redundant check on cnt > 8

From: Colin Ian King The 2nd check of cnt > 8 is redundant as cnt is already checked and thresholded to a maximum of 8 a few statements earlier. Remove this redundant 2nd check. Detected by CoverityScan, CID#114281 ("Logically dead code") Signed-off-by: Colin Ian King

Re: [PATCH 2/2] apparmorfs: Use seq_putc() in two functions

On 05/07/2017 05:03 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sun, 7 May 2017 13:50:28 +0200 > > Two single characters (line breaks) should be put into a sequence. > Thus use the corresponding function "seq_putc". > > This issue was detected by

  1   2   3   4   5   >