* 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
* 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
> > >
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 +
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 +
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
>
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
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
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
>> 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
>> 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
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
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
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,
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
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
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
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);
> +
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
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;
> + }
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
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
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,
>>
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
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
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
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
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:
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:
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:
-
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.
-
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
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,
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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,
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.
>
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
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:
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:
>
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.
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
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
>> >
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
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
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
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:"
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:"
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
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
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
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
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.
>
> -
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
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
+++
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
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
>> >
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
>> >
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
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
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
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
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
> >>
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,
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
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
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
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
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()
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
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
>>
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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 - 100 of 990 matches
Mail list logo