Re: [PATCH 1/3] ARM: mach-omap2: remove bogus "or_module" from rx51-peripherals

* Paul Gortmaker [160722 07:02]: > [Re: [PATCH 1/3] ARM: mach-omap2: remove bogus "or_module" from > rx51-peripherals] On 21/07/2016 (Thu 23:41) Tony Lindgren wrote: > > > Hi, > > > > * Paul Gortmaker [160719 21:17]: > > > During

Re: [PATCH 1/3] ARM: mach-omap2: remove bogus "or_module" from rx51-peripherals

* Paul Gortmaker [160722 07:02]: > [Re: [PATCH 1/3] ARM: mach-omap2: remove bogus "or_module" from > rx51-peripherals] On 21/07/2016 (Thu 23:41) Tony Lindgren wrote: > > > Hi, > > > > * Paul Gortmaker [160719 21:17]: > > > During unrelated work, attempting to remove an include of the > > >

[PATCH] net/irda: fix NULL pointer dereference on memory allocation failure

I ran into this: kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] PREEMPT SMP KASAN CPU: 2 PID: 2012 Comm: trinity-c3 Not tainted 4.7.0-rc7+ #19 Hardware name: QEMU Standard PC (i440FX +

[PATCH] net/irda: fix NULL pointer dereference on memory allocation failure

I ran into this: kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] PREEMPT SMP KASAN CPU: 2 PID: 2012 Comm: trinity-c3 Not tainted 4.7.0-rc7+ #19 Hardware name: QEMU Standard PC (i440FX +

Re: [PATCH 00/19] x86/dumpstack: rewrite x86 stack dump code

On Sat, Jul 23, 2016 at 2:35 PM, Josh Poimboeuf wrote: > > While doing the scanning and printing, it does call the frame pointer > unwinder in parallel, but like before, that's *only* used to determine > whether a found address should be printed without a question mark. If >

Re: [PATCH 00/19] x86/dumpstack: rewrite x86 stack dump code

On Sat, Jul 23, 2016 at 2:35 PM, Josh Poimboeuf wrote: > > While doing the scanning and printing, it does call the frame pointer > unwinder in parallel, but like before, that's *only* used to determine > whether a found address should be printed without a question mark. If > the unwinder goes

Re: [PATCH 00/19] x86/dumpstack: rewrite x86 stack dump code

On Fri, Jul 22, 2016 at 05:31:47PM -0700, Andy Lutomirski wrote: > On Fri, Jul 22, 2016 at 5:22 PM, Linus Torvalds > wrote: > > > > So without having yet looked at the code, I want people to understand > > that to a very real degree, the stack tracer that the

Re: [PATCH 00/19] x86/dumpstack: rewrite x86 stack dump code

On Fri, Jul 22, 2016 at 05:31:47PM -0700, Andy Lutomirski wrote: > On Fri, Jul 22, 2016 at 5:22 PM, Linus Torvalds > wrote: > > > > So without having yet looked at the code, I want people to understand > > that to a very real degree, the stack tracer that the *oopsing* code > > (ie what all the

Re: PM-wakeup: Delete unnecessary checks before two function calls

>> How do you think about to integrate this update suggestion >> into another source code repository? > > I'm not really sure what you mean. Do you find the suggested source code change acceptable? http://article.gmane.org/gmane.linux.power-management.general/61766

Re: PM-wakeup: Delete unnecessary checks before two function calls

>> How do you think about to integrate this update suggestion >> into another source code repository? > > I'm not really sure what you mean. Do you find the suggested source code change acceptable? http://article.gmane.org/gmane.linux.power-management.general/61766

Re: [kernel-hardening] [PATCH v5 03/32] x86/cpa: In populate_pgd, don't set the pgd entry until it's populated

On Thu, 21 Jul 2016 22:34:33 -0700, Andy Lutomirski said: > How much memory do you have and what's your config? My code is > obviously buggy, but I'm wondering why neither I nor the 0day bot caught > this. Probably because your devel box and the 0day bot both have 4-level page tables and the

Re: [kernel-hardening] [PATCH v5 03/32] x86/cpa: In populate_pgd, don't set the pgd entry until it's populated

On Thu, 21 Jul 2016 22:34:33 -0700, Andy Lutomirski said: > How much memory do you have and what's your config? My code is > obviously buggy, but I'm wondering why neither I nor the 0day bot caught > this. Probably because your devel box and the 0day bot both have 4-level page tables and the

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

Hi Arnaldo, On Fri, 22 Jul 2016 16:57:34 -0300 Arnaldo Carvalho de Melo wrote: > > Em Fri, Jul 22, 2016 at 02:44:17PM -0500, Josh Poimboeuf escreveu: > > On Fri, Jul 22, 2016 at 04:36:55PM -0300, Arnaldo Carvalho de Melo wrote: > > > Em Fri, Jul 22, 2016 at 02:19:20PM -0500,

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

Hi Arnaldo, On Fri, 22 Jul 2016 16:57:34 -0300 Arnaldo Carvalho de Melo wrote: > > Em Fri, Jul 22, 2016 at 02:44:17PM -0500, Josh Poimboeuf escreveu: > > On Fri, Jul 22, 2016 at 04:36:55PM -0300, Arnaldo Carvalho de Melo wrote: > > > Em Fri, Jul 22, 2016 at 02:19:20PM -0500, Josh Poimboeuf

[PATCH] x86/mm/cpa: Unbreak populate_pgd(): stop trying to deallocate failed PUDs

This mostly reverts commit 360cb4d15567a7eca07a5f3ade6de308bbfb4e70. I broke the case where a PUD table got allocated -- populate_pud() would wander off a pgd_none entry and get lost. I'm not sure how this survived my testing. Fixing this directly is difficult or impossible because of the awful

[PATCH] x86/mm/cpa: Unbreak populate_pgd(): stop trying to deallocate failed PUDs

This mostly reverts commit 360cb4d15567a7eca07a5f3ade6de308bbfb4e70. I broke the case where a PUD table got allocated -- populate_pud() would wander off a pgd_none entry and get lost. I'm not sure how this survived my testing. Fixing this directly is difficult or impossible because of the awful

Re: [PATCH v4 2/4] drm/rockchip: add an common abstracted PSR driver

Yakir, On Wed, Jul 13, 2016 at 9:15 PM, Yakir Yang wrote: > +static void psr_set_state(struct psr_drv *psr, enum psr_state state) > +{ > + mutex_lock(>state_mutex); > + > + if (psr->state == state) { > + mutex_unlock(>state_mutex); > +

Re: [PATCH 1/3] Add a new field to struct shrinker

On 07/22/2016 06:27 PM, Tony Jones wrote: > On 07/20/2016 07:54 AM, Michal Hocko wrote: > >>> Michal, just to make sure I understand you correctly, do you mean that we >>> could infer the names of the shrinkers by looking at the names of their >>> callbacks? >> >> Yes, %ps can then be used for

Re: [PATCH v4 2/4] drm/rockchip: add an common abstracted PSR driver

Yakir, On Wed, Jul 13, 2016 at 9:15 PM, Yakir Yang wrote: > +static void psr_set_state(struct psr_drv *psr, enum psr_state state) > +{ > + mutex_lock(>state_mutex); > + > + if (psr->state == state) { > + mutex_unlock(>state_mutex); > + return; > + }

Re: [PATCH 1/3] Add a new field to struct shrinker

On 07/22/2016 06:27 PM, Tony Jones wrote: > On 07/20/2016 07:54 AM, Michal Hocko wrote: > >>> Michal, just to make sure I understand you correctly, do you mean that we >>> could infer the names of the shrinkers by looking at the names of their >>> callbacks? >> >> Yes, %ps can then be used for

Re: linux-next: build failure after merge of the nvdimm tree

On Fri, Jul 22, 2016 at 6:04 PM, Dan Williams wrote: > On Thu, Jul 21, 2016 at 11:13 PM, Stephen Rothwell > wrote: >> Hi Dan, >> >> After merging the nvdimm tree, today's linux-next build (powerpc >> ppc64_defconfig) failed like this: >> >> In

Re: linux-next: build failure after merge of the nvdimm tree

On Fri, Jul 22, 2016 at 6:04 PM, Dan Williams wrote: > On Thu, Jul 21, 2016 at 11:13 PM, Stephen Rothwell > wrote: >> Hi Dan, >> >> After merging the nvdimm tree, today's linux-next build (powerpc >> ppc64_defconfig) failed like this: >> >> In file included from drivers/md/dm.h:14:0, >>

Crypto Fixes for 4.7

Hi Linus: This push fixes a sporadic build failure in the qat driver as well as a memory corruption bug in rsa-pkcs1pad. Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus Herbert Xu (1): crypto: rsa-pkcs1pad - fix rsa-pkcs1pad request struct

Crypto Fixes for 4.7

Hi Linus: This push fixes a sporadic build failure in the qat driver as well as a memory corruption bug in rsa-pkcs1pad. Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus Herbert Xu (1): crypto: rsa-pkcs1pad - fix rsa-pkcs1pad request struct

Re: [GIT PULL] clk fixes for v4.7-rc8

On Fri, Jul 22, 2016 at 9:47 AM, Michael Turquette wrote: > > git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git > tags/clk-fixes-for-linus The pgp key you sign your pull requests with keep changing. Sometimes it's your primary key, most often it seems to be

Re: [GIT PULL] clk fixes for v4.7-rc8

On Fri, Jul 22, 2016 at 9:47 AM, Michael Turquette wrote: > > git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git > tags/clk-fixes-for-linus The pgp key you sign your pull requests with keep changing. Sometimes it's your primary key, most often it seems to be your 4kb subkey, now it's

Re: [PATCH net-next v3] cdc_ether: Improve ZTE MF823/831/910 handling

Hi, [auto build test WARNING on net-next/master] url: https://github.com/0day-ci/linux/commits/Kristian-Evensen/cdc_ether-Improve-ZTE-MF823-831-910-handling/20160723-093100 config: x86_64-randconfig-i0-201629 (attached as .config) compiler: gcc-4.9 (Debian 4.9.3-14) 4.9.3 reproduce:

Re: [PATCH net-next v3] cdc_ether: Improve ZTE MF823/831/910 handling

Hi, [auto build test WARNING on net-next/master] url: https://github.com/0day-ci/linux/commits/Kristian-Evensen/cdc_ether-Improve-ZTE-MF823-831-910-handling/20160723-093100 config: x86_64-randconfig-i0-201629 (attached as .config) compiler: gcc-4.9 (Debian 4.9.3-14) 4.9.3 reproduce:

Re: [PATCH v2 00/10] userns: sysctl limits for namespaces

Kees Cook writes: > On Fri, Jul 22, 2016 at 11:45 AM, Eric W. Biederman > wrote: >> Colin Walters writes: >> >>> On Thu, Jul 21, 2016, at 12:39 PM, Eric W. Biederman wrote: This patchset addresses two use cases: -

Re: [PATCH v2 00/10] userns: sysctl limits for namespaces

Kees Cook writes: > On Fri, Jul 22, 2016 at 11:45 AM, Eric W. Biederman > wrote: >> Colin Walters writes: >> >>> On Thu, Jul 21, 2016, at 12:39 PM, Eric W. Biederman wrote: This patchset addresses two use cases: - Implement a sane upper bound on the number of namespaces. -

Re: [v6 PATCH 1/6] extcon: Add Type-C and DP support

Hi, 2016-07-23 6:40 GMT+09:00 Guenter Roeck : > On Fri, Jul 22, 2016 at 2:29 AM, Chanwoo Choi wrote: >> Hi Chris, >> >> I'm sorry for late reply. I finished the first draft to support the extcon >> property. >> You can check the patches[1]. But, I need

Re: [v6 PATCH 1/6] extcon: Add Type-C and DP support

Hi, 2016-07-23 6:40 GMT+09:00 Guenter Roeck : > On Fri, Jul 22, 2016 at 2:29 AM, Chanwoo Choi wrote: >> Hi Chris, >> >> I'm sorry for late reply. I finished the first draft to support the extcon >> property. >> You can check the patches[1]. But, I need more time to test it. After tested >> it,

Re: [v6 PATCH 1/6] extcon: Add Type-C and DP support

Hi, 2016-07-23 3:21 GMT+09:00 Guenter Roeck : > Hi, > > On Fri, Jul 22, 2016 at 2:29 AM, Chanwoo Choi wrote: >> Hi Chris, >> >> I'm sorry for late reply. I finished the first draft to support the extcon >> property. >> You can check the patches[1]. But,

Re: [v6 PATCH 1/6] extcon: Add Type-C and DP support

Hi, 2016-07-23 3:21 GMT+09:00 Guenter Roeck : > Hi, > > On Fri, Jul 22, 2016 at 2:29 AM, Chanwoo Choi wrote: >> Hi Chris, >> >> I'm sorry for late reply. I finished the first draft to support the extcon >> property. >> You can check the patches[1]. But, I need more time to test it. After tested

Re: [PATCH v8 0/10] Output raw touch data via V4L2

I'm not Nick, but I'm testing his patches. ;-) Here's what I'm getting from v4l2-compliance with his patches: root@RDU2:/mnt/disk ./v4l2-compliance -a -f -d /dev/v4l-touch0 Driver Info: Driver name : rmi4_f54 Card type : Synaptics RMI4 Touch Sensor Bus info : rmi4:rmi4-00.fn54 Driver

Re: [PATCH v8 0/10] Output raw touch data via V4L2

I'm not Nick, but I'm testing his patches. ;-) Here's what I'm getting from v4l2-compliance with his patches: root@RDU2:/mnt/disk ./v4l2-compliance -a -f -d /dev/v4l-touch0 Driver Info: Driver name : rmi4_f54 Card type : Synaptics RMI4 Touch Sensor Bus info : rmi4:rmi4-00.fn54 Driver

[PATCH v18 net-next 1/1] hv_sock: introduce Hyper-V Sockets

Hyper-V Sockets (hv_sock) supplies a byte-stream based communication mechanism between the host and the guest. It's somewhat like TCP over VMBus, but the transportation layer (VMBus) is much simpler than IP. With Hyper-V Sockets, applications between the host and the guest can talk to each other

[PATCH v18 net-next 1/1] hv_sock: introduce Hyper-V Sockets

Hyper-V Sockets (hv_sock) supplies a byte-stream based communication mechanism between the host and the guest. It's somewhat like TCP over VMBus, but the transportation layer (VMBus) is much simpler than IP. With Hyper-V Sockets, applications between the host and the guest can talk to each other

Re: [PATCH v3] virtio_blk: Fix a slient kernel panic

Ping, Any comment is appreciate. Thanks Minfei > On Jul 19, 2016, at 20:22, Cornelia Huck wrote: > > On Tue, 19 Jul 2016 12:32:42 +0800 > Minfei Huang wrote: > >> From: Minfei Huang >> >> We do a lot of memory allocation in

Re: [PATCH v3] virtio_blk: Fix a slient kernel panic

Ping, Any comment is appreciate. Thanks Minfei > On Jul 19, 2016, at 20:22, Cornelia Huck wrote: > > On Tue, 19 Jul 2016 12:32:42 +0800 > Minfei Huang wrote: > >> From: Minfei Huang >> >> We do a lot of memory allocation in function init_vq, and don't handle >> the allocation failure

Re: [PATCH] add u64 number parser

On 07/22/16 17:23, James Smart wrote: + buf = kmalloc(len + 1, GFP_KERNEL); + if (!buf) + return -ENOMEM; + memcpy(buf, s->from, len); + buf[len] = '\0'; Hello James, Have you considered to combine the above kmalloc() and memcpy() calls into a single

Re: [PATCH] add u64 number parser

On 07/22/16 17:23, James Smart wrote: + buf = kmalloc(len + 1, GFP_KERNEL); + if (!buf) + return -ENOMEM; + memcpy(buf, s->from, len); + buf[len] = '\0'; Hello James, Have you considered to combine the above kmalloc() and memcpy() calls into a single

[PATCH v18 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)

Hyper-V Sockets (hv_sock) supplies a byte-stream based communication mechanism between the host and the guest. It's somewhat like TCP over VMBus, but the transportation layer (VMBus) is much simpler than IP. With Hyper-V Sockets, applications between the host and the guest can talk to each other

[PATCH v18 net-next 0/1] introduce Hyper-V VM Sockets(hv_sock)

Hyper-V Sockets (hv_sock) supplies a byte-stream based communication mechanism between the host and the guest. It's somewhat like TCP over VMBus, but the transportation layer (VMBus) is much simpler than IP. With Hyper-V Sockets, applications between the host and the guest can talk to each other

Re: [PATCH 1/3] Add a new field to struct shrinker

On 07/20/2016 07:54 AM, Michal Hocko wrote: >> Michal, just to make sure I understand you correctly, do you mean that we >> could infer the names of the shrinkers by looking at the names of their >> callbacks? > > Yes, %ps can then be used for the name of the shrinker structure > (assuming it

Re: [PATCH 1/3] Add a new field to struct shrinker

On 07/20/2016 07:54 AM, Michal Hocko wrote: >> Michal, just to make sure I understand you correctly, do you mean that we >> could infer the names of the shrinkers by looking at the names of their >> callbacks? > > Yes, %ps can then be used for the name of the shrinker structure > (assuming it

Re: [PATCH 2/5] mm: add per-zone lru list stat

Hi Fengguang, On Sat, Jul 23, 2016 at 08:45:15AM +0800, Fengguang Wu wrote: > Hi Minchan, > > We find duplicate /proc/vmstat lines showing up in linux-next, which > look related to this patch. > > >>--- a/mm/vmstat.c > >>+++ b/mm/vmstat.c > >>@@ -921,6 +921,11 @@ int fragmentation_index(struct

Re: [PATCH 2/5] mm: add per-zone lru list stat

Hi Fengguang, On Sat, Jul 23, 2016 at 08:45:15AM +0800, Fengguang Wu wrote: > Hi Minchan, > > We find duplicate /proc/vmstat lines showing up in linux-next, which > look related to this patch. > > >>--- a/mm/vmstat.c > >>+++ b/mm/vmstat.c > >>@@ -921,6 +921,11 @@ int fragmentation_index(struct

ADS1118: hwmon or iio ? [was: Re: [RCF 1/3] hwmon: Add ads1118 driver]

On 07/22/2016 07:39 AM, Joshua Clayton wrote: Greetings Guenter, Thank you for reviewing my submission. On 07/15/2016 06:40 PM, Guenter Roeck wrote: On 07/15/2016 05:18 PM, Joshua Clayton wrote: Add new driver for Texas Instruments ADS1118 and and ADS1018. This driver works with ADS1018,

ADS1118: hwmon or iio ? [was: Re: [RCF 1/3] hwmon: Add ads1118 driver]

On 07/22/2016 07:39 AM, Joshua Clayton wrote: Greetings Guenter, Thank you for reviewing my submission. On 07/15/2016 06:40 PM, Guenter Roeck wrote: On 07/15/2016 05:18 PM, Joshua Clayton wrote: Add new driver for Texas Instruments ADS1118 and and ADS1018. This driver works with ADS1018,

Re: [PATCH] x86/boot: Reorganize and clean up the BIOS area reservation code

On Fri, Jul 22, 2016 at 10:00 PM, Matt Fleming wrote: > > I suppose we could rewrite the page table mapping for those precious > <1MB regions to coerce the firmware into accessing different pages > instead of the 1:1 addresses and copy the regions elsewhere. Maybe. >

Re: [PATCH] x86/boot: Reorganize and clean up the BIOS area reservation code

On Fri, Jul 22, 2016 at 10:00 PM, Matt Fleming wrote: > > I suppose we could rewrite the page table mapping for those precious > <1MB regions to coerce the firmware into accessing different pages > instead of the 1:1 addresses and copy the regions elsewhere. Maybe. > That assumes we don't hit

Re: linux-next: build failure after merge of the nvdimm tree

On Thu, Jul 21, 2016 at 11:13 PM, Stephen Rothwell wrote: > Hi Dan, > > After merging the nvdimm tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > In file included from drivers/md/dm.h:14:0, > from drivers/md/dm-uevent.c:27:

Re: linux-next: build failure after merge of the nvdimm tree

On Thu, Jul 21, 2016 at 11:13 PM, Stephen Rothwell wrote: > Hi Dan, > > After merging the nvdimm tree, today's linux-next build (powerpc > ppc64_defconfig) failed like this: > > In file included from drivers/md/dm.h:14:0, > from drivers/md/dm-uevent.c:27: >

Re: linux-next: Tree for Jul 22

builder:~/git/linux-head$ git describe > next-20160722 > > Nothing has touched drivers/input/evbug.c for years... Circling back to look at this more, it seems to be a result of the makefiles not clobbering something properly when using the same build directory from yesterday's next build today.

Re: linux-next: Tree for Jul 22

modulo of the size of section > __mod_input___device_table=384. > Fix definition of struct input_device_id in mod_devicetable.h > make[2]: *** [__modpost] Error 1 > make[1]: *** [modules] Error 2 > make: *** [sub-make] Error 2 > > paul@builder:~/git/linux-head$ git describe

Re: [PATCH v2 16/17] x86/insn: remove pcommit

On Fri, Jul 22, 2016 at 9:52 AM, Ingo Molnar wrote: > > * Dan Williams wrote: > >> On Tue, Jul 12, 2016 at 3:12 PM, Dan Williams >> wrote: >> > On Tue, Jul 12, 2016 at 7:57 AM, Peter Zijlstra >> >

Re: [PATCH v2 16/17] x86/insn: remove pcommit

On Fri, Jul 22, 2016 at 9:52 AM, Ingo Molnar wrote: > > * Dan Williams wrote: > >> On Tue, Jul 12, 2016 at 3:12 PM, Dan Williams >> wrote: >> > On Tue, Jul 12, 2016 at 7:57 AM, Peter Zijlstra >> > wrote: >> >> On Sat, Jul 09, 2016 at 08:25:54PM -0700, Dan Williams wrote: >> >>> The pcommit

Re: [PATCH 2/5] mm: add per-zone lru list stat

Hi Minchan, We find duplicate /proc/vmstat lines showing up in linux-next, which look related to this patch. --- a/mm/vmstat.c +++ b/mm/vmstat.c @@ -921,6 +921,11 @@ int fragmentation_index(struct zone *zone, unsigned int order) const char * const vmstat_text[] = { /* enum

Re: [PATCH 2/5] mm: add per-zone lru list stat

Hi Minchan, We find duplicate /proc/vmstat lines showing up in linux-next, which look related to this patch. --- a/mm/vmstat.c +++ b/mm/vmstat.c @@ -921,6 +921,11 @@ int fragmentation_index(struct zone *zone, unsigned int order) const char * const vmstat_text[] = { /* enum

Re: [PATCH v4 00/12] mm: Hardened usercopy

On 07/20/2016 01:26 PM, Kees Cook wrote: Hi, [This is now in my kspp -next tree, though I'd really love to add some additional explicit Tested-bys, Reviewed-bys, or Acked-bys. If you've looked through any part of this or have done any testing, please consider sending an email with your "*-by:"

Re: [PATCH v4 00/12] mm: Hardened usercopy

On 07/20/2016 01:26 PM, Kees Cook wrote: Hi, [This is now in my kspp -next tree, though I'd really love to add some additional explicit Tested-bys, Reviewed-bys, or Acked-bys. If you've looked through any part of this or have done any testing, please consider sending an email with your "*-by:"

Re: [PATCH 00/19] x86/dumpstack: rewrite x86 stack dump code

On Fri, Jul 22, 2016 at 5:22 PM, Linus Torvalds wrote: > > So without having yet looked at the code, I want people to understand > that to a very real degree, the stack tracer that the *oopsing* code > (ie what all the usual kernel fault handlers use) is very very

Re: [PATCH 00/19] x86/dumpstack: rewrite x86 stack dump code

On Fri, Jul 22, 2016 at 5:22 PM, Linus Torvalds wrote: > > So without having yet looked at the code, I want people to understand > that to a very real degree, the stack tracer that the *oopsing* code > (ie what all the usual kernel fault handlers use) is very very special > code and needs to be

[PATCH] add u64 number parser

add u64 number parser Will be used by the nvme-fabrics FC transport in parsing options Signed-off-by: James Smart --- include/linux/parser.h | 1 + lib/parser.c | 47 +++ 2 files changed, 48 insertions(+) diff

[PATCH] add u64 number parser

add u64 number parser Will be used by the nvme-fabrics FC transport in parsing options Signed-off-by: James Smart --- include/linux/parser.h | 1 + lib/parser.c | 47 +++ 2 files changed, 48 insertions(+) diff --git

Re: [PATCH 00/19] x86/dumpstack: rewrite x86 stack dump code

On Fri, Jul 22, 2016 at 6:21 AM, Josh Poimboeuf wrote: > > Some if its advantages: > > - simplicity: no more callback sprawl and less code duplication. > > - flexibility: allows the caller to stop and inspect the stack state at > each step in the unwinding process. > > -

Re: [PATCH 00/19] x86/dumpstack: rewrite x86 stack dump code

On Fri, Jul 22, 2016 at 6:21 AM, Josh Poimboeuf wrote: > > Some if its advantages: > > - simplicity: no more callback sprawl and less code duplication. > > - flexibility: allows the caller to stop and inspect the stack state at > each step in the unwinding process. > > - modularity: the

[PATCH] f2fs: clean up codying style and redundancy

This patch includes minor clean-ups. Signed-off-by: Jaegeuk Kim --- fs/f2fs/acl.h | 2 +- fs/f2fs/data.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/f2fs/acl.h b/fs/f2fs/acl.h index 997ca8e..b2334d1 100644 --- a/fs/f2fs/acl.h +++

[PATCH] f2fs: clean up codying style and redundancy

This patch includes minor clean-ups. Signed-off-by: Jaegeuk Kim --- fs/f2fs/acl.h | 2 +- fs/f2fs/data.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/f2fs/acl.h b/fs/f2fs/acl.h index 997ca8e..b2334d1 100644 --- a/fs/f2fs/acl.h +++ b/fs/f2fs/acl.h @@ -37,7 +37,7

Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface

On Fri, Jul 22, 2016 at 4:54 PM, Josh Poimboeuf wrote: >> > +static bool in_hardirq_stack(unsigned long *stack, struct stack_info >> > *info, >> > +unsigned long *visit_mask) >> > +{ >> > + unsigned long *begin = (unsigned long >> >

Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface

On Fri, Jul 22, 2016 at 4:54 PM, Josh Poimboeuf wrote: >> > +static bool in_hardirq_stack(unsigned long *stack, struct stack_info >> > *info, >> > +unsigned long *visit_mask) >> > +{ >> > + unsigned long *begin = (unsigned long >> >

Re: [RFC PATCH 2/2] mm, mempool: do not throttle PF_LESS_THROTTLE tasks

On Fri, Jul 22 2016, Michal Hocko wrote: > On Fri 22-07-16 18:46:57, Neil Brown wrote: >> On Mon, Jul 18 2016, Michal Hocko wrote: >> >> > From: Michal Hocko >> > >> > Mikulas has reported that a swap backed by dm-crypt doesn't work >> > properly because the swapout cannot make

Re: [RFC PATCH 2/2] mm, mempool: do not throttle PF_LESS_THROTTLE tasks

On Fri, Jul 22 2016, Michal Hocko wrote: > On Fri 22-07-16 18:46:57, Neil Brown wrote: >> On Mon, Jul 18 2016, Michal Hocko wrote: >> >> > From: Michal Hocko >> > >> > Mikulas has reported that a swap backed by dm-crypt doesn't work >> > properly because the swapout cannot make a sufficient

Re: [PATCH v4 1/2] bpf: Add bpf_probe_write BPF helper to be called in tracers (kprobes)

On Fri, Jul 22, 2016 at 11:53:52AM +0200, Daniel Borkmann wrote: > On 07/22/2016 04:14 AM, Alexei Starovoitov wrote: > >On Thu, Jul 21, 2016 at 06:09:17PM -0700, Sargun Dhillon wrote: > >>This allows user memory to be written to during the course of a kprobe. > >>It shouldn't be used to implement

Re: [PATCH v4 1/2] bpf: Add bpf_probe_write BPF helper to be called in tracers (kprobes)

On Fri, Jul 22, 2016 at 11:53:52AM +0200, Daniel Borkmann wrote: > On 07/22/2016 04:14 AM, Alexei Starovoitov wrote: > >On Thu, Jul 21, 2016 at 06:09:17PM -0700, Sargun Dhillon wrote: > >>This allows user memory to be written to during the course of a kprobe. > >>It shouldn't be used to implement

Re: [PATCH 19/19] x86/dumpstack: print any pt_regs found on the stack

On Fri, Jul 22, 2016 at 04:39:00PM -0700, Andy Lutomirski wrote: > On Fri, Jul 22, 2016 at 4:30 PM, Josh Poimboeuf wrote: > > On Fri, Jul 22, 2016 at 04:18:04PM -0700, Andy Lutomirski wrote: > >> On Fri, Jul 22, 2016 at 3:20 PM, Josh Poimboeuf > >>

Re: [PATCH v4 7/7] power_supply: make use of new strcpytoupper() function

Hi, On Fri, Jul 22, 2016 at 04:31:09PM -0700, Markus Mayer wrote: > Call strcpytoupper() rather than walking the string explicitly to > convert it to uppercase. > > Signed-off-by: Markus Mayer > --- > drivers/power/power_supply_sysfs.c | 13 + > 1 file changed,

Re: [PATCH 19/19] x86/dumpstack: print any pt_regs found on the stack

On Fri, Jul 22, 2016 at 04:39:00PM -0700, Andy Lutomirski wrote: > On Fri, Jul 22, 2016 at 4:30 PM, Josh Poimboeuf wrote: > > On Fri, Jul 22, 2016 at 04:18:04PM -0700, Andy Lutomirski wrote: > >> On Fri, Jul 22, 2016 at 3:20 PM, Josh Poimboeuf > >> wrote: > >> > On Fri, Jul 22, 2016 at

Re: [PATCH v4 7/7] power_supply: make use of new strcpytoupper() function

Hi, On Fri, Jul 22, 2016 at 04:31:09PM -0700, Markus Mayer wrote: > Call strcpytoupper() rather than walking the string explicitly to > convert it to uppercase. > > Signed-off-by: Markus Mayer > --- > drivers/power/power_supply_sysfs.c | 13 + > 1 file changed, 5 insertions(+), 8

Re: [PATCH v4 4/7] staging: speakup: replace spk_strlwr() with strlcpytolower()

Markus Mayer writes: > After introducing generic strltolower() and strtolower(), spk_strlwr() > is no longer needed. > > Signed-off-by: Markus Mayer > Acked-by: Samuel Thibault Acked-by: Chris Brannon

Re: [PATCH v4 4/7] staging: speakup: replace spk_strlwr() with strlcpytolower()

Markus Mayer writes: > After introducing generic strltolower() and strtolower(), spk_strlwr() > is no longer needed. > > Signed-off-by: Markus Mayer > Acked-by: Samuel Thibault Acked-by: Chris Brannon Haven't looked at much kernel code in a while, but this looks good. -- Chris

Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface

On Fri, Jul 22, 2016 at 04:26:46PM -0700, Andy Lutomirski wrote: > On Thu, Jul 21, 2016 at 2:21 PM, Josh Poimboeuf wrote: > > valid_stack_ptr() is buggy: it assumes that all stacks are of size > > THREAD_SIZE, which is not true for exception stacks. So the > > walk_stack()

Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface

On Fri, Jul 22, 2016 at 04:26:46PM -0700, Andy Lutomirski wrote: > On Thu, Jul 21, 2016 at 2:21 PM, Josh Poimboeuf wrote: > > valid_stack_ptr() is buggy: it assumes that all stacks are of size > > THREAD_SIZE, which is not true for exception stacks. So the > > walk_stack() callbacks will need to

Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface

On Fri, Jul 22, 2016 at 4:26 PM, Andy Lutomirski wrote: > On Thu, Jul 21, 2016 at 2:21 PM, Josh Poimboeuf wrote: >> valid_stack_ptr() is buggy: it assumes that all stacks are of size >> THREAD_SIZE, which is not true for exception stacks. So the >>

Re: [PATCH 10/19] x86/dumpstack: add get_stack_info() interface

On Fri, Jul 22, 2016 at 4:26 PM, Andy Lutomirski wrote: > On Thu, Jul 21, 2016 at 2:21 PM, Josh Poimboeuf wrote: >> valid_stack_ptr() is buggy: it assumes that all stacks are of size >> THREAD_SIZE, which is not true for exception stacks. So the >> walk_stack() callbacks will need to know the

Re: [PATCH] Revert "cpufreq: pcc-cpufreq: update default value of cpuinfo_transition_latency"

On 23-07-16, 01:47, Rafael J. Wysocki wrote: > I'll apply the revert with a "Cc: stable" tag. That will work. > Question is what to do about the other drivers setting > cpuinfo.transition_latency to CPUFREQ_ETERNAL. Perhaps leave them as is unless someone comes and reports a problem, they don't

Re: [PATCH] Revert "cpufreq: pcc-cpufreq: update default value of cpuinfo_transition_latency"

On 23-07-16, 01:47, Rafael J. Wysocki wrote: > I'll apply the revert with a "Cc: stable" tag. That will work. > Question is what to do about the other drivers setting > cpuinfo.transition_latency to CPUFREQ_ETERNAL. Perhaps leave them as is unless someone comes and reports a problem, they don't

Re: [PATCH] Revert "cpufreq: pcc-cpufreq: update default value of cpuinfo_transition_latency"

On Sat, Jul 23, 2016 at 1:30 AM, Viresh Kumar wrote: > On 22-07-16, 23:46, Rafael J. Wysocki wrote: >> On Friday, July 22, 2016 02:28:52 PM Viresh Kumar wrote: >> > On 22-07-16, 23:31, Rafael J. Wysocki wrote: >> > > > cpufreq.c >> > > > >> > > > if

Re: [PATCH] Revert "cpufreq: pcc-cpufreq: update default value of cpuinfo_transition_latency"

On Sat, Jul 23, 2016 at 1:30 AM, Viresh Kumar wrote: > On 22-07-16, 23:46, Rafael J. Wysocki wrote: >> On Friday, July 22, 2016 02:28:52 PM Viresh Kumar wrote: >> > On 22-07-16, 23:31, Rafael J. Wysocki wrote: >> > > > cpufreq.c >> > > > >> > > > if

[PATCH 1/1] EDAC, sb_edac: Fix channel reporting on Knights Landing

On Intel Xeon Phi Knights Landing processor family the channels of memory controller have untypical arrangement - MC0 is mapped to CH3,4,5 and MC1 is mapped to CH0,1,2. This causes EDAC driver to report the channel name incorrectly. We missed this change earlier, so the code already contains

[PATCH 1/1] EDAC, sb_edac: Fix channel reporting on Knights Landing

On Intel Xeon Phi Knights Landing processor family the channels of memory controller have untypical arrangement - MC0 is mapped to CH3,4,5 and MC1 is mapped to CH0,1,2. This causes EDAC driver to report the channel name incorrectly. We missed this change earlier, so the code already contains

Re: [PATCH 19/19] x86/dumpstack: print any pt_regs found on the stack

On Fri, Jul 22, 2016 at 4:30 PM, Josh Poimboeuf wrote: > On Fri, Jul 22, 2016 at 04:18:04PM -0700, Andy Lutomirski wrote: >> On Fri, Jul 22, 2016 at 3:20 PM, Josh Poimboeuf wrote: >> > On Fri, Jul 22, 2016 at 02:46:10PM -0700, Andy Lutomirski wrote: >>

Re: [PATCH 19/19] x86/dumpstack: print any pt_regs found on the stack

On Fri, Jul 22, 2016 at 4:30 PM, Josh Poimboeuf wrote: > On Fri, Jul 22, 2016 at 04:18:04PM -0700, Andy Lutomirski wrote: >> On Fri, Jul 22, 2016 at 3:20 PM, Josh Poimboeuf wrote: >> > On Fri, Jul 22, 2016 at 02:46:10PM -0700, Andy Lutomirski wrote: >> >> On Fri, Jul 22, 2016 at 8:57 AM, Josh

[git pull] Input updates for 4.7-rc7 (part 2)

Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive a few more fixes for the input subsystem: - restore naming for tsc2005 touchscreens as some userspace match on it - fix out of bound access in legacy keyboard driver - fixup

[git pull] Input updates for 4.7-rc7 (part 2)

Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive a few more fixes for the input subsystem: - restore naming for tsc2005 touchscreens as some userspace match on it - fix out of bound access in legacy keyboard driver - fixup

[PATCH v4 7/7] power_supply: make use of new strcpytoupper() function

Call strcpytoupper() rather than walking the string explicitly to convert it to uppercase. Signed-off-by: Markus Mayer --- drivers/power/power_supply_sysfs.c | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/drivers/power/power_supply_sysfs.c

[PATCH v4 7/7] power_supply: make use of new strcpytoupper() function

Call strcpytoupper() rather than walking the string explicitly to convert it to uppercase. Signed-off-by: Markus Mayer --- drivers/power/power_supply_sysfs.c | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/drivers/power/power_supply_sysfs.c

[PATCH v4 6/7] drm/nouveau/fifo/gk104: make use of new strcpytoupper() function

Call strcpytoupper() rather than copying the string explicitly and then walking it to convert it to uppercase. Signed-off-by: Markus Mayer --- drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git

[PATCH v4 6/7] drm/nouveau/fifo/gk104: make use of new strcpytoupper() function

Call strcpytoupper() rather than copying the string explicitly and then walking it to convert it to uppercase. Signed-off-by: Markus Mayer --- drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git

  1   2   3   4   5   6   7   8   9   10   >