Re: [PATCH v7 16/24] i2c: allow adapter drivers to override the adapter locking

> Yes, they look like reasonable complaints. Thanks for fixing them. I just sent out my latest comments and when you fix those and send V8, I'll apply that right away. I think we are safe to fix the rest incrementally if needed. Note that I didn't review the IIO and media patches, I trust the

Re: [PATCH v7 16/24] i2c: allow adapter drivers to override the adapter locking

> Yes, they look like reasonable complaints. Thanks for fixing them. I just sent out my latest comments and when you fix those and send V8, I'll apply that right away. I think we are safe to fix the rest incrementally if needed. Note that I didn't review the IIO and media patches, I trust the

Re: [PATCH] [RFC] x86: work around MPX Erratum

On Tue, May 3, 2016 at 2:31 PM, Andy Lutomirski wrote: > > Having actually read the erratum: how can this affect Linux at all > under any scenario where user code hasn't already completely > compromised the kernel? If it matches purely on linear address, you will potentially

Re: [PATCH] [RFC] x86: work around MPX Erratum

On Tue, May 3, 2016 at 2:31 PM, Andy Lutomirski wrote: > > Having actually read the erratum: how can this affect Linux at all > under any scenario where user code hasn't already completely > compromised the kernel? If it matches purely on linear address, you will potentially have interesting

Re: [PATCH v7 16/24] i2c: allow adapter drivers to override the adapter locking

On Wed, Apr 20, 2016 at 05:17:56PM +0200, Peter Rosin wrote: > Add i2c_lock_bus() and i2c_unlock_bus(), which call the new lock_bus and > unlock_bus ops in the adapter. These funcs/ops take an additional flags > argument that indicates for what purpose the adapter is locked. > > There are two

Re: [PATCH v7 16/24] i2c: allow adapter drivers to override the adapter locking

On Wed, Apr 20, 2016 at 05:17:56PM +0200, Peter Rosin wrote: > Add i2c_lock_bus() and i2c_unlock_bus(), which call the new lock_bus and > unlock_bus ops in the adapter. These funcs/ops take an additional flags > argument that indicates for what purpose the adapter is locked. > > There are two

Re: [PATCH 6/8] pci: provide sensible irq vector alloc/free routines

On Tue, May 03, 2016 at 11:19:46PM +0200, Christoph Hellwig wrote: > Hi Bjorn, > > I've implemented your suggestion and I'm getting ready to send out > a new version. One thing that came to mind is: do you prefer this > code in irq.c or would you rather have it in msi.c? While it > also has a

Re: [PATCH 6/8] pci: provide sensible irq vector alloc/free routines

On Tue, May 03, 2016 at 11:19:46PM +0200, Christoph Hellwig wrote: > Hi Bjorn, > > I've implemented your suggestion and I'm getting ready to send out > a new version. One thing that came to mind is: do you prefer this > code in irq.c or would you rather have it in msi.c? While it > also has a

Re: VDSO unmap and remap support for additional architectures

On 04/29/2016 09:55 AM, Dmitry Safonov wrote: > On 04/29/2016 04:22 PM, Christopher Covington wrote: >> On 04/28/2016 02:53 PM, Andy Lutomirski wrote: >>> Also, at some point, possibly quite soon, x86 will want a way for >>> user code to ask the kernel to map a specific vdso variant at a specific

Re: VDSO unmap and remap support for additional architectures

On 04/29/2016 09:55 AM, Dmitry Safonov wrote: > On 04/29/2016 04:22 PM, Christopher Covington wrote: >> On 04/28/2016 02:53 PM, Andy Lutomirski wrote: >>> Also, at some point, possibly quite soon, x86 will want a way for >>> user code to ask the kernel to map a specific vdso variant at a specific

Re: [RFC PATCH] livepatch: allow removal of a disabled patch

On Mon, May 02, 2016 at 01:57:22PM +0200, Miroslav Benes wrote: > 1. Do we really need a completion? If I am not missing something > kobject_del() always waits for sysfs callers to leave thanks to kernfs > active protection. What do you mean by "kernfs active protection"? I see that

Re: [RFC PATCH] livepatch: allow removal of a disabled patch

On Mon, May 02, 2016 at 01:57:22PM +0200, Miroslav Benes wrote: > 1. Do we really need a completion? If I am not missing something > kobject_del() always waits for sysfs callers to leave thanks to kernfs > active protection. What do you mean by "kernfs active protection"? I see that

Re: [PATCH] fix infoleak in wireless

On Tue, May 03, 2016 at 05:11:07PM -0400, Kangjie Lu wrote: > Opps, I did not notice the patch is not attached. > > From 34a82a734388d07eb10f91770f86938e38f7575a Mon Sep 17 00:00:00 2001 > From: Kangjie Lu > Date: Tue, 3 May 2016 14:15:18 -0400 > Subject: [PATCH] fix infoleak in

Re: [PATCH] fix infoleak in wireless

On Tue, May 03, 2016 at 05:11:07PM -0400, Kangjie Lu wrote: > Opps, I did not notice the patch is not attached. > > From 34a82a734388d07eb10f91770f86938e38f7575a Mon Sep 17 00:00:00 2001 > From: Kangjie Lu > Date: Tue, 3 May 2016 14:15:18 -0400 > Subject: [PATCH] fix infoleak in wireless >

Re: [PATCH] [RFC] x86: work around MPX Erratum

On Tue, May 3, 2016 at 2:28 PM, Dave Hansen wrote: >> >> So we won't init MPX on those... > > Yes, and as long as such a processor doesn't exist today and never > exists in the future or the folks that buy such a processor truly don't > care about MPX, that's fine to do.

Re: [PATCH] [RFC] x86: work around MPX Erratum

On Tue, May 3, 2016 at 2:28 PM, Dave Hansen wrote: >> >> So we won't init MPX on those... > > Yes, and as long as such a processor doesn't exist today and never > exists in the future or the folks that buy such a processor truly don't > care about MPX, that's fine to do. I'm just a bit nervous

Re: [PATCH] [RFC] x86: work around MPX Erratum

On May 3, 2016 2:05 PM, "Dave Hansen" wrote: > > On 05/02/2016 11:43 PM, Ingo Molnar wrote: > >> > +static int is_mpx_affected_microarch(struct cpuinfo_x86 *c) > >> > +{ > >> > + /* Only family 6 is affected */ > >> > + if (c->x86 != 0x6) > >> > + return 0; > >>

Re: [PATCH] [RFC] x86: work around MPX Erratum

On May 3, 2016 2:05 PM, "Dave Hansen" wrote: > > On 05/02/2016 11:43 PM, Ingo Molnar wrote: > >> > +static int is_mpx_affected_microarch(struct cpuinfo_x86 *c) > >> > +{ > >> > + /* Only family 6 is affected */ > >> > + if (c->x86 != 0x6) > >> > + return 0; > >> > + > >> > + /* We

Re: [PATCH] [RFC] x86: work around MPX Erratum

On 05/03/2016 02:12 PM, Borislav Petkov wrote: > On Tue, May 03, 2016 at 02:04:40PM -0700, Dave Hansen wrote: >> My concern was not necessarily with folks booting with 'nosmep', but > > Btw, does anything speak for even keeping that 'nosmep' thing? Generally, I'm not sure we need the no$foo

Re: [PATCH] [RFC] x86: work around MPX Erratum

On 05/03/2016 02:12 PM, Borislav Petkov wrote: > On Tue, May 03, 2016 at 02:04:40PM -0700, Dave Hansen wrote: >> My concern was not necessarily with folks booting with 'nosmep', but > > Btw, does anything speak for even keeping that 'nosmep' thing? Generally, I'm not sure we need the no$foo

Re: [PATCH v7 1/6] Shared library support

On Tue, 3 May 2016 11:00:56 +0900 Masahiro Yamada wrote: Hi, > # Compile .c file, create position independent .o file > # host-cxxshobjs -> .o > quiet_cmd_host-cxxshobjs = HOSTCXX -fPIC $@ > cmd_host-cxxshobjs = $(HOSTCXX) $(hostcxx_flags) -fPIC -c -o $@ $<

Re: [PATCH v7 1/6] Shared library support

On Tue, 3 May 2016 11:00:56 +0900 Masahiro Yamada wrote: Hi, > # Compile .c file, create position independent .o file > # host-cxxshobjs -> .o > quiet_cmd_host-cxxshobjs = HOSTCXX -fPIC $@ > cmd_host-cxxshobjs = $(HOSTCXX) $(hostcxx_flags) -fPIC -c -o $@ $< >

Re: [PATCH 6/8] pci: provide sensible irq vector alloc/free routines

Hi Bjorn, I've implemented your suggestion and I'm getting ready to send out a new version. One thing that came to mind is: do you prefer this code in irq.c or would you rather have it in msi.c? While it also has a legacy irq fallback most of it tied pretty closely to the msi.c code, so I

Re: [PATCH 6/8] pci: provide sensible irq vector alloc/free routines

Hi Bjorn, I've implemented your suggestion and I'm getting ready to send out a new version. One thing that came to mind is: do you prefer this code in irq.c or would you rather have it in msi.c? While it also has a legacy irq fallback most of it tied pretty closely to the msi.c code, so I

Re: [patch] usb: dwc3: gadget: fix mask and shift order in DWC3_DCFG_NUMP()

On Tue, May 03, 2016 at 10:53:05AM +0300, Felipe Balbi wrote: > > Hi, > > Dan Carpenter writes: > > In the original DWC3_DCFG_NUMP() was always zero. It looks like the > > intent was to shift first and then do the mask. > > > > Fixes: 2a58f9c12bb3 ('usb: dwc3: gadget:

Re: [patch] usb: dwc3: gadget: fix mask and shift order in DWC3_DCFG_NUMP()

On Tue, May 03, 2016 at 10:53:05AM +0300, Felipe Balbi wrote: > > Hi, > > Dan Carpenter writes: > > In the original DWC3_DCFG_NUMP() was always zero. It looks like the > > intent was to shift first and then do the mask. > > > > Fixes: 2a58f9c12bb3 ('usb: dwc3: gadget: disable automatic

Re: [PATCH] usb: hub: fix panic caused by NULL bos pointer during reset device

On Wed, Apr 27, 2016 at 09:35:57AM -0400, Tony Battersby wrote: > On 04/26/2016 10:53 PM, Du, Changbin wrote: > >> On Tue, Mar 08, 2016 at 05:15:17PM +0800, changbin...@intel.com wrote: > >>> From: "Du, Changbin" > >>> > >>> This is a reworked patch based on reverted commit

Re: [PATCH v7 1/6] Shared library support

On Mon, 2 May 2016 14:03:00 +0900 Masahiro Yamada wrote: Hi, > > diff --git a/scripts/Makefile.clean b/scripts/Makefile.clean > > index 55c96cb..e4e88ab 100644 > > --- a/scripts/Makefile.clean > > +++ b/scripts/Makefile.clean > > @@ -38,7 +38,8 @@ subdir-ymn:=

Re: [PATCH] usb: hub: fix panic caused by NULL bos pointer during reset device

On Wed, Apr 27, 2016 at 09:35:57AM -0400, Tony Battersby wrote: > On 04/26/2016 10:53 PM, Du, Changbin wrote: > >> On Tue, Mar 08, 2016 at 05:15:17PM +0800, changbin...@intel.com wrote: > >>> From: "Du, Changbin" > >>> > >>> This is a reworked patch based on reverted commit d8f00cd685f5 ("usb: >

Re: [PATCH v7 1/6] Shared library support

On Mon, 2 May 2016 14:03:00 +0900 Masahiro Yamada wrote: Hi, > > diff --git a/scripts/Makefile.clean b/scripts/Makefile.clean > > index 55c96cb..e4e88ab 100644 > > --- a/scripts/Makefile.clean > > +++ b/scripts/Makefile.clean > > @@ -38,7 +38,8 @@ subdir-ymn:= $(addprefix

Re: [PATCH] perf/sdt: Directly record cached SDT events

On 05/03/2016 06:05 AM, Masami Hiramatsu wrote: On Tue, 03 May 2016 05:06:24 +0530 Hemant Kumar wrote: Hi Masami, On 04/30/2016 06:06 PM, Masami Hiramatsu wrote: Hi Hemant, On Fri, 29 Apr 2016 19:10:41 +0530 Hemant Kumar wrote:

Re: [PATCH] perf/sdt: Directly record cached SDT events

On 05/03/2016 06:05 AM, Masami Hiramatsu wrote: On Tue, 03 May 2016 05:06:24 +0530 Hemant Kumar wrote: Hi Masami, On 04/30/2016 06:06 PM, Masami Hiramatsu wrote: Hi Hemant, On Fri, 29 Apr 2016 19:10:41 +0530 Hemant Kumar wrote: This patch adds support for directly recording SDT events

Re: [REGRESSION] asix: Lots of asix_rx_fixup() errors and slow transmissions

On 03/05/16 15:42, David B. Robins wrote: I don't think the first one is giving you problems (except as triggered by the second) but I had concerns about the second myself (and emailed the author off-list, but received no reply), and we did not take that commit for our own product. Sorry,

Re: [REGRESSION] asix: Lots of asix_rx_fixup() errors and slow transmissions

On 03/05/16 15:42, David B. Robins wrote: I don't think the first one is giving you problems (except as triggered by the second) but I had concerns about the second myself (and emailed the author off-list, but received no reply), and we did not take that commit for our own product. Sorry,

[PATCH v2] perf/sdt: Directly record SDT events

This patch adds support for directly recording SDT events which are present in the probe cache. This patch is based on current SDT enablement patchset (v5) by Masami : https://lkml.org/lkml/2016/4/27/828 and it implements two points in the TODO list mentioned in the cover note : "- (perf record)

[PATCH v2] perf/sdt: Directly record SDT events

This patch adds support for directly recording SDT events which are present in the probe cache. This patch is based on current SDT enablement patchset (v5) by Masami : https://lkml.org/lkml/2016/4/27/828 and it implements two points in the TODO list mentioned in the cover note : "- (perf record)

Re: [PATCH] [RFC] x86: work around MPX Erratum

On Tue, May 03, 2016 at 02:04:40PM -0700, Dave Hansen wrote: > My concern was not necessarily with folks booting with 'nosmep', but Btw, does anything speak for even keeping that 'nosmep' thing? > with processors that have MPX present and SMEP fused off (or made > unavailable by a hypervisor)

Re: [PATCH] [RFC] x86: work around MPX Erratum

On Tue, May 03, 2016 at 02:04:40PM -0700, Dave Hansen wrote: > My concern was not necessarily with folks booting with 'nosmep', but Btw, does anything speak for even keeping that 'nosmep' thing? > with processors that have MPX present and SMEP fused off (or made > unavailable by a hypervisor)

[PATCH 7/7] mm: Batch unmapping of pages that are in swap cache

We created a new function __remove_swap_mapping_batch that allows all pages under the same swap partition to be removed from the swap cache's mapping in a single acquisition of the mapping's tree lock.  This reduces the contention on the lock when multiple threads are reclaiming memory by swapping

[PATCH 7/7] mm: Batch unmapping of pages that are in swap cache

We created a new function __remove_swap_mapping_batch that allows all pages under the same swap partition to be removed from the swap cache's mapping in a single acquisition of the mapping's tree lock.  This reduces the contention on the lock when multiple threads are reclaiming memory by swapping

Re: [PATCH] Staging: dgnc: fix coding style in dgnc_tty.c

On Tue, May 03, 2016 at 08:37:27PM +0200, Patryk Mezydlo wrote: > Fix checkpatch.pl warning about 'line over 80 characters'. > I just split line with function. > > Signed-off-by: Patryk Mezydlo > --- > drivers/staging/dgnc/dgnc_tty.c | 3 ++- > 1 file changed, 2

Re: [PATCH] Staging: dgnc: fix coding style in dgnc_tty.c

On Tue, May 03, 2016 at 08:37:27PM +0200, Patryk Mezydlo wrote: > Fix checkpatch.pl warning about 'line over 80 characters'. > I just split line with function. > > Signed-off-by: Patryk Mezydlo > --- > drivers/staging/dgnc/dgnc_tty.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) >

Re: [PATCH] [RFC] x86: work around MPX Erratum

On 05/02/2016 11:43 PM, Ingo Molnar wrote: >> > +static int is_mpx_affected_microarch(struct cpuinfo_x86 *c) >> > +{ >> > + /* Only family 6 is affected */ >> > + if (c->x86 != 0x6) >> > + return 0; >> > + >> > + /* We know these Atom models are unaffected, for sure */ >> > + switch

Re: [PATCH] [RFC] x86: work around MPX Erratum

On 05/02/2016 11:43 PM, Ingo Molnar wrote: >> > +static int is_mpx_affected_microarch(struct cpuinfo_x86 *c) >> > +{ >> > + /* Only family 6 is affected */ >> > + if (c->x86 != 0x6) >> > + return 0; >> > + >> > + /* We know these Atom models are unaffected, for sure */ >> > + switch

[PATCH 6/7] mm: Cleanup - Reorganize code to group handling of page

In this patch, we reorganize the paging operations so the paging operations of pages to the same swap device can be grouped together. This prepares for the next patch that remove multiple pages from the same swap cache together once they have been paged out. The patch creates a new function

[PATCH 3/7] mm: Add new functions to allocate swap slots in batches

Currently, the swap slots have to be allocated one page at a time, causing contention to the swap_info lock protecting the swap partition on every page being swapped. This patch adds new functions get_swap_pages and scan_swap_map_slots to request multiple swap slots at once. This will reduce the

[PATCH 6/7] mm: Cleanup - Reorganize code to group handling of page

In this patch, we reorganize the paging operations so the paging operations of pages to the same swap device can be grouped together. This prepares for the next patch that remove multiple pages from the same swap cache together once they have been paged out. The patch creates a new function

[PATCH 3/7] mm: Add new functions to allocate swap slots in batches

Currently, the swap slots have to be allocated one page at a time, causing contention to the swap_info lock protecting the swap partition on every page being swapped. This patch adds new functions get_swap_pages and scan_swap_map_slots to request multiple swap slots at once. This will reduce the

[PATCH 5/7] mm: Batch addtion of pages to swap cache

When a page is to be swapped, it needed to be added to the swap cache and then removed after the paging has been completed.  A swap partition's mapping tree lock is acquired for each anonymous page's addition to the swap cache. This patch created new functions add_to_swap_batch and

[PATCH 5/7] mm: Batch addtion of pages to swap cache

When a page is to be swapped, it needed to be added to the swap cache and then removed after the paging has been completed.  A swap partition's mapping tree lock is acquired for each anonymous page's addition to the swap cache. This patch created new functions add_to_swap_batch and

[PATCH 4/7] mm: Shrink page list batch allocates swap slots for page swapping

In shrink page list, we take advantage bulk allocation of swap entries with the new get_swap_pages function. This reduces contention on a swap device's swap_info lock. When the memory is low and the system is actively trying to reclaim memory, both direct reclaim path and kswapd contends on this

[PATCH 4/7] mm: Shrink page list batch allocates swap slots for page swapping

In shrink page list, we take advantage bulk allocation of swap entries with the new get_swap_pages function. This reduces contention on a swap device's swap_info lock. When the memory is low and the system is actively trying to reclaim memory, both direct reclaim path and kswapd contends on this

[PATCH 2/7] mm: Group the processing of anonymous pages to be swapped in shrink_page_list

This is a clean up patch to reorganize the processing of anonymous pages in shrink_page_list. We delay the processing of swapping anonymous pages in shrink_page_list and put them together on a separate list.  This prepares for batching of pages to be swapped.  The processing of the list of

[PATCH 1/7] mm: Cleanup - Reorganize the shrink_page_list code into smaller functions

This patch prepares the code for being able to batch the anonymous pages to be swapped out.  It reorganizes shrink_page_list function with 2 new functions: handle_pgout and pg_finish. The paging operation in shrink_page_list is consolidated into handle_pgout function. After we have scanned a

[PATCH 2/7] mm: Group the processing of anonymous pages to be swapped in shrink_page_list

This is a clean up patch to reorganize the processing of anonymous pages in shrink_page_list. We delay the processing of swapping anonymous pages in shrink_page_list and put them together on a separate list.  This prepares for batching of pages to be swapped.  The processing of the list of

[PATCH 1/7] mm: Cleanup - Reorganize the shrink_page_list code into smaller functions

This patch prepares the code for being able to batch the anonymous pages to be swapped out.  It reorganizes shrink_page_list function with 2 new functions: handle_pgout and pg_finish. The paging operation in shrink_page_list is consolidated into handle_pgout function. After we have scanned a

[PATCH 0/7] mm: Improve swap path scalability with batched operations

The page swap out path is not scalable due to the numerous locks acquired and released along the way, which are all executed on a page by page basis, e.g.: 1. The acquisition of the mapping tree lock in swap cache when adding a page to swap cache, and then again when deleting a page from swap

Re: [PATCH] fix infoleak in wireless

A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Tue, May 03, 2016 at 04:47:16PM -0400, Kangjie Lu wrote: > Hi Greg, > > Could you please take a look at this issue. > mac_addr is not initialized is some implementations of dump_station(), which >

[PATCH 0/7] mm: Improve swap path scalability with batched operations

The page swap out path is not scalable due to the numerous locks acquired and released along the way, which are all executed on a page by page basis, e.g.: 1. The acquisition of the mapping tree lock in swap cache when adding a page to swap cache, and then again when deleting a page from swap

Re: [PATCH] fix infoleak in wireless

A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Tue, May 03, 2016 at 04:47:16PM -0400, Kangjie Lu wrote: > Hi Greg, > > Could you please take a look at this issue. > mac_addr is not initialized is some implementations of dump_station(), which >

Re: v4.6-rc1 regression bisected, Problem loading in-kernel X.509 certificate (-2)

Hi Jamie, On 05/03/2016 01:35 PM, David Howells wrote: > (cc'ing Tadeusz as he did the pkcs1 padding function) > > Jamie Heilman wrote: > Problem loading in-kernel X.509 certificate (-2) >>> >>> ENOENT? Hmmm... The only place that is generated is in the

Re: v4.6-rc1 regression bisected, Problem loading in-kernel X.509 certificate (-2)

Hi Jamie, On 05/03/2016 01:35 PM, David Howells wrote: > (cc'ing Tadeusz as he did the pkcs1 padding function) > > Jamie Heilman wrote: > Problem loading in-kernel X.509 certificate (-2) >>> >>> ENOENT? Hmmm... The only place that is generated is in the crypto layer. >>> That suggests

Re: [PATCH 00/42] v7: separate operations from flags in the bio/request structs

mchri...@redhat.com writes: > The following patches begin to cleanup the request->cmd_flags and > bio->bi_rw mess. We currently use cmd_flags to specify the operation, > attributes and state of the request. For bi_rw we use it for similar > info and also the priority but then also have another

Re: [PATCH 00/42] v7: separate operations from flags in the bio/request structs

mchri...@redhat.com writes: > The following patches begin to cleanup the request->cmd_flags and > bio->bi_rw mess. We currently use cmd_flags to specify the operation, > attributes and state of the request. For bi_rw we use it for similar > info and also the priority but then also have another

[PATCH] fix infoleak in rtnetlink

The stack object “map” has a total size of 32 bytes. Its last 4 bytes are padding generated by compiler. These padding bytes are not initialized and sent out via “nla_put”. Signed-off-by: Kangjie Lu --- net/core/rtnetlink.c | 18 ++ 1 file changed, 10

[PATCH] fix infoleak in rtnetlink

The stack object “map” has a total size of 32 bytes. Its last 4 bytes are padding generated by compiler. These padding bytes are not initialized and sent out via “nla_put”. Signed-off-by: Kangjie Lu --- net/core/rtnetlink.c | 18 ++ 1 file changed, 10 insertions(+), 8

[PATCH] infoleak fix2 in timer

The stack object “r1” has a total size of 32 bytes. Its field “event” and “val” both contain 4 bytes padding. These 8 bytes padding bytes are sent to user without being initialized. Signed-off-by: Kangjie Lu --- sound/core/timer.c | 1 + 1 file changed, 1 insertion(+) diff

[PATCH] infoleak fix2 in timer

The stack object “r1” has a total size of 32 bytes. Its field “event” and “val” both contain 4 bytes padding. These 8 bytes padding bytes are sent to user without being initialized. Signed-off-by: Kangjie Lu --- sound/core/timer.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH] infoleak fix3 in timer

The stack object “r1” has a total size of 32 bytes. Its field “event” and “val” both contain 4 bytes padding. These 8 bytes padding bytes are sent to user without being initialized. Signed-off-by: Kangjie Lu --- sound/core/timer.c | 1 + 1 file changed, 1 insertion(+) diff

[PATCH] infoleak fix3 in timer

The stack object “r1” has a total size of 32 bytes. Its field “event” and “val” both contain 4 bytes padding. These 8 bytes padding bytes are sent to user without being initialized. Signed-off-by: Kangjie Lu --- sound/core/timer.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH] infoleak fix1 in timer

The stack object “tread” has a total size of 32 bytes. Its field “event” and “val” both contain 4 bytes padding. These 8 bytes padding bytes are sent to user without being initialized. Signed-off-by: Kangjie Lu --- sound/core/timer.c | 1 + 1 file changed, 1 insertion(+) diff

Re: [PATCH] fix infoleak in wireless

On Tue, 2016-05-03 at 16:40 -0400, Kangjie Lu wrote: > The 6-bytes array “mac_addr” is not initialized in the dump_station > implementations of > “drivers/staging/wilc1000/wilc_wfi_cfgoperations.c” > and “drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c”, so all 6 > bytes may be leaked. Like I

[PATCH] infoleak fix1 in timer

The stack object “tread” has a total size of 32 bytes. Its field “event” and “val” both contain 4 bytes padding. These 8 bytes padding bytes are sent to user without being initialized. Signed-off-by: Kangjie Lu --- sound/core/timer.c | 1 + 1 file changed, 1 insertion(+) diff --git

Re: [PATCH] fix infoleak in wireless

On Tue, 2016-05-03 at 16:40 -0400, Kangjie Lu wrote: > The 6-bytes array “mac_addr” is not initialized in the dump_station > implementations of > “drivers/staging/wilc1000/wilc_wfi_cfgoperations.c” > and “drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c”, so all 6 > bytes may be leaked. Like I

[PATCH] infoleak fix1 in signal

The stack object “info” has a total size of 128 bytes; however, only 28 bytes are initialized. The remaining uninitialized bytes are sent to userland via send_signal. Signed-off-by: Kangjie Lu --- kernel/signal.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH] infoleak fix1 in signal

The stack object “info” has a total size of 128 bytes; however, only 28 bytes are initialized. The remaining uninitialized bytes are sent to userland via send_signal. Signed-off-by: Kangjie Lu --- kernel/signal.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/signal.c

[PATCH] infoleak fix2 in signal

The stack object “info” has a total size of 128 bytes; however, only 32 bytes are initialized. The remaining uninitialized bytes are sent to userland via send_signal. Signed-off-by: Kangjie Lu --- kernel/signal.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH] infoleak fix2 in signal

The stack object “info” has a total size of 128 bytes; however, only 32 bytes are initialized. The remaining uninitialized bytes are sent to userland via send_signal. Signed-off-by: Kangjie Lu --- kernel/signal.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/signal.c

[GIT] Networking

Some straggler bug fixes: 1) Batman-adv DAT must consider VLAN IDs when choosing candidate nodes, from Antonio Quartulli. 2) Fix botched reference counting of vlan objects and neigh nodes in batman-adv, from Sven Eckelmann. 3) netem can crash when it sees GSO packets, the fix is to

[GIT] Networking

Some straggler bug fixes: 1) Batman-adv DAT must consider VLAN IDs when choosing candidate nodes, from Antonio Quartulli. 2) Fix botched reference counting of vlan objects and neigh nodes in batman-adv, from Sven Eckelmann. 3) netem can crash when it sees GSO packets, the fix is to

[PATCH] fix infoleak in wireless

The 6-bytes array “mac_addr” is not initialized in the dump_station implementations of “drivers/staging/wilc1000/wilc_wfi_cfgoperations.c” and “drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c”, so all 6 bytes may be leaked. Signed-off-by: Kangjie Lu --- net/wireless/nl80211.c

[PATCH] fix infoleak in wireless

The 6-bytes array “mac_addr” is not initialized in the dump_station implementations of “drivers/staging/wilc1000/wilc_wfi_cfgoperations.c” and “drivers/staging/rtl8723au/os_dep/ioctl_cfg80211.c”, so all 6 bytes may be leaked. Signed-off-by: Kangjie Lu --- net/wireless/nl80211.c | 1 + 1 file

Re: v4.6-rc1 regression bisected, Problem loading in-kernel X.509 certificate (-2)

(cc'ing Tadeusz as he did the pkcs1 padding function) Jamie Heilman wrote: > > > Problem loading in-kernel X.509 certificate (-2) > > > > ENOENT? Hmmm... The only place that is generated is in the crypto layer. > > That suggests missing crypto of some sort. > >

Re: v4.6-rc1 regression bisected, Problem loading in-kernel X.509 certificate (-2)

(cc'ing Tadeusz as he did the pkcs1 padding function) Jamie Heilman wrote: > > > Problem loading in-kernel X.509 certificate (-2) > > > > ENOENT? Hmmm... The only place that is generated is in the crypto layer. > > That suggests missing crypto of some sort. > > > > The attached patch

[PATCH] fix infoleak in mm

The stack object “si” has a total size of 128; however, only 20 bytes are initialized. The remaining uninitialized bytes are sent to userland via send_signal Signed-off-by: Kangjie Lu --- arch/arm64/mm/fault.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH] fix infoleak in mm

The stack object “si” has a total size of 128; however, only 20 bytes are initialized. The remaining uninitialized bytes are sent to userland via send_signal Signed-off-by: Kangjie Lu --- arch/arm64/mm/fault.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/mm/fault.c

[PATCH] fix infoleak in llc

The stack object “info” has a total size of 12 bytes. Its last byte is padding which is not initialized and leaked via “put_cmsg”. Signed-off-by: Kangjie Lu --- net/llc/af_llc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/llc/af_llc.c b/net/llc/af_llc.c index

[PATCH] fix infoleak in llc

The stack object “info” has a total size of 12 bytes. Its last byte is padding which is not initialized and leaked via “put_cmsg”. Signed-off-by: Kangjie Lu --- net/llc/af_llc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/net/llc/af_llc.c b/net/llc/af_llc.c index b3c52e3..8ae3ed9 100644

[PATCH] fix infoleak in fcntl

The stack object “si” has a total size of 128 bytes; however, only 16 bytes are initialized. The remaining uninitialized bytes are sent to userland via send_signal. Signed-off-by: Kangjie Lu --- fs/fcntl.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/fcntl.c

[PATCH] fix infoleak in fcntl

The stack object “si” has a total size of 128 bytes; however, only 16 bytes are initialized. The remaining uninitialized bytes are sent to userland via send_signal. Signed-off-by: Kangjie Lu --- fs/fcntl.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/fcntl.c b/fs/fcntl.c index

[PATCH 0/3] [media] s5p-mfc: Fixes for issues when module is removed

Hello, This patch series fixes some issues that I noticed when trying to remove the s5p-mfc driver when built as a module. Some of these issues will be fixed once Marek's patches to convert the custom memory region reservation code is replaced by a generic one that supports named memory region

[PATCH] fix infoleak in devio

The stack object “ci” has a total size of 8 bytes. Its last 3 bytes are padding bytes which are not initialized and leaked to userland via “copy_to_user”. Signed-off-by: Kangjie Lu --- drivers/usb/core/devio.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff

[PATCH 0/3] [media] s5p-mfc: Fixes for issues when module is removed

Hello, This patch series fixes some issues that I noticed when trying to remove the s5p-mfc driver when built as a module. Some of these issues will be fixed once Marek's patches to convert the custom memory region reservation code is replaced by a generic one that supports named memory region

[PATCH] fix infoleak in devio

The stack object “ci” has a total size of 8 bytes. Its last 3 bytes are padding bytes which are not initialized and leaked to userland via “copy_to_user”. Signed-off-by: Kangjie Lu --- drivers/usb/core/devio.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git

[PATCH 3/3] [media] s5p-mfc: Fix race between s5p_mfc_probe() and s5p_mfc_open()

The s5p_mfc_probe() function registers the video devices before all the resources needed by s5p_mfc_open() are correctly initalized. So if s5p_mfc_open() function is called before s5p_mfc_probe() finishes (since the video dev is already registered), a NULL pointer dereference will happen due

[PATCH 3/3] [media] s5p-mfc: Fix race between s5p_mfc_probe() and s5p_mfc_open()

The s5p_mfc_probe() function registers the video devices before all the resources needed by s5p_mfc_open() are correctly initalized. So if s5p_mfc_open() function is called before s5p_mfc_probe() finishes (since the video dev is already registered), a NULL pointer dereference will happen due

[PATCH 2/3] [media] s5p-mfc: Add release callback for memory region devs

When s5p_mfc_remove() calls put_device() for the reserved memory region devs, the driver core warns that the dev doesn't have a release callback: WARNING: CPU: 0 PID: 591 at drivers/base/core.c:251 device_release+0x8c/0x90 Device 's5p-mfc-l' does not have a release() function, it is broken and

[PATCH 1/3] [media] s5p-mfc: Set device name for reserved memory region devs

The devices don't have a name set, so makes dev_name() returns NULL which makes harder to identify the devices that are causing issues, for example: WARNING: CPU: 2 PID: 616 at drivers/base/core.c:251 device_release+0x8c/0x90 Device '(null)' does not have a release() function, it is broken and

[PATCH 2/3] [media] s5p-mfc: Add release callback for memory region devs

When s5p_mfc_remove() calls put_device() for the reserved memory region devs, the driver core warns that the dev doesn't have a release callback: WARNING: CPU: 0 PID: 591 at drivers/base/core.c:251 device_release+0x8c/0x90 Device 's5p-mfc-l' does not have a release() function, it is broken and

[PATCH 1/3] [media] s5p-mfc: Set device name for reserved memory region devs

The devices don't have a name set, so makes dev_name() returns NULL which makes harder to identify the devices that are causing issues, for example: WARNING: CPU: 2 PID: 616 at drivers/base/core.c:251 device_release+0x8c/0x90 Device '(null)' does not have a release() function, it is broken and

<    1   2   3   4   5   6   7   8   9   10   >