Re: [PATCH v4 1/3] perf: add PERF_RECORD_NAMESPACES to include namespaces related info

On Thu, Dec 22, 2016 at 08:21:23PM +1300, Eric W. Biederman wrote: > > And please make the array the last item in the structure so that > expanding or contracting it does not affect the ability to read the rest > of the structure. Sorry, sample_id must be last, because hysterical crud :/

Re: [PATCH 2/4] vfio-mdev: de-polute the namespace, rename parent_device & parent_ops

Not sure if this is appropriate, but if not having the Documentation considered, for patch 2-4: Reviewed-by: Jike Song -- Thanks, Jike On 12/22/2016 07:27 AM, Alex Williamson wrote: > From: Alex Williamson > > Add an mdev_ prefix so we're not poluting

Re: [PATCH v4 1/3] perf: add PERF_RECORD_NAMESPACES to include namespaces related info

On Thu, Dec 22, 2016 at 08:21:23PM +1300, Eric W. Biederman wrote: > > And please make the array the last item in the structure so that > expanding or contracting it does not affect the ability to read the rest > of the structure. Sorry, sample_id must be last, because hysterical crud :/

Re: [PATCH 2/4] vfio-mdev: de-polute the namespace, rename parent_device & parent_ops

Not sure if this is appropriate, but if not having the Documentation considered, for patch 2-4: Reviewed-by: Jike Song -- Thanks, Jike On 12/22/2016 07:27 AM, Alex Williamson wrote: > From: Alex Williamson > > Add an mdev_ prefix so we're not poluting the namespace so much. > > Cc: Kirti

Re: [PATCH] ARM64: zynqmp: Fix i2c node's compatible string

On 22.12.2016 06:49, Moritz Fischer wrote: > From: Moritz Fischer > > The Zynq Ultrascale MP uses version 1.4 of the Cadence IP core > which fixes some silicon bugs that needed software workarounds > in Version 1.0 that was used on Zynq systems. > > Signed-off-by: Moritz

Re: [PATCH] ARM64: zynqmp: Fix i2c node's compatible string

On 22.12.2016 06:49, Moritz Fischer wrote: > From: Moritz Fischer > > The Zynq Ultrascale MP uses version 1.4 of the Cadence IP core > which fixes some silicon bugs that needed software workarounds > in Version 1.0 that was used on Zynq systems. > > Signed-off-by: Moritz Fischer > Cc: Michal

Re: [PATCH 2/2] nsfs: Add an ioctl() to return creator UID of a userns

Andrei Vagin writes: > On Mon, Dec 19, 2016 at 03:38:35PM +0100, Michael Kerrisk (man-pages) wrote: >> @@ -174,6 +175,11 @@ static long ns_ioctl(struct file *filp, unsigned int >> ioctl, >> return open_related_ns(ns, ns->ops->get_parent); >> case

Re: [PATCH 2/2] nsfs: Add an ioctl() to return creator UID of a userns

Andrei Vagin writes: > On Mon, Dec 19, 2016 at 03:38:35PM +0100, Michael Kerrisk (man-pages) wrote: >> @@ -174,6 +175,11 @@ static long ns_ioctl(struct file *filp, unsigned int >> ioctl, >> return open_related_ns(ns, ns->ops->get_parent); >> case NS_GET_NSTYPE: >>

Re: [PATCH v4 1/3] perf: add PERF_RECORD_NAMESPACES to include namespaces related info

Hari Bathini writes: > On Wednesday 21 December 2016 06:54 PM, Peter Zijlstra wrote: >> On Wed, Dec 21, 2016 at 06:39:01PM +0530, Hari Bathini wrote: >>> Hi Peter, I don't see how the tool can parse old records (with NAMESPACES_MAX == 7) if you set its

Re: [PATCH v4 1/3] perf: add PERF_RECORD_NAMESPACES to include namespaces related info

Hari Bathini writes: > On Wednesday 21 December 2016 06:54 PM, Peter Zijlstra wrote: >> On Wed, Dec 21, 2016 at 06:39:01PM +0530, Hari Bathini wrote: >>> Hi Peter, I don't see how the tool can parse old records (with NAMESPACES_MAX == 7) if you set its NAMESPACES_MAX to say 10.

[PATCH 2/3] xen: return xenstore command failures via response instead of rc

When the xenbus driver does some special handling for a Xenstore command any error condition related to the command should be returned via an error response instead of letting the related write operation fail. Otherwise the user land handler might take wrong decisions assuming the connection to

[PATCH 3/3] xen: remove stale xs_input_avail() from header

In drivers/xen/xenbus/xenbus_comms.h there is a stale declaration of xs_input_avail(). Remove it. Signed-off-by: Juergen Gross --- drivers/xen/xenbus/xenbus_comms.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/xen/xenbus/xenbus_comms.h

[PATCH 1/3] xen: xenbus driver must not accept invalid transaction ids

When accessing Xenstore in a transaction the user is specifying a transaction id which he normally obtained from Xenstore when starting the transaction. Xenstore is validating a transaction id against all known transaction ids of the connection the request came in. As all requests of a domain not

[PATCH 2/3] xen: return xenstore command failures via response instead of rc

When the xenbus driver does some special handling for a Xenstore command any error condition related to the command should be returned via an error response instead of letting the related write operation fail. Otherwise the user land handler might take wrong decisions assuming the connection to

[PATCH 3/3] xen: remove stale xs_input_avail() from header

In drivers/xen/xenbus/xenbus_comms.h there is a stale declaration of xs_input_avail(). Remove it. Signed-off-by: Juergen Gross --- drivers/xen/xenbus/xenbus_comms.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/xen/xenbus/xenbus_comms.h b/drivers/xen/xenbus/xenbus_comms.h index

[PATCH 1/3] xen: xenbus driver must not accept invalid transaction ids

When accessing Xenstore in a transaction the user is specifying a transaction id which he normally obtained from Xenstore when starting the transaction. Xenstore is validating a transaction id against all known transaction ids of the connection the request came in. As all requests of a domain not

[PATCH 0/3] xen: fix some minor bugs and cleanup of xenbus

Do some minor bug fixes and cleanup of xenbus driver. Juergen Gross (3): xen: xenbus driver must not accept invalid transaction ids xen: return xenstore command failures via response instead of rc xen: remove stale xs_input_avail() from header drivers/xen/xenbus/xenbus_comms.h| 1

Re: [PATCH 0/2] Add further ioctl() operations for namespace discovery

Hi Eric, On 12/22/2016 01:27 AM, Eric W. Biederman wrote: > "Michael Kerrisk (man-pages)" writes: > >> Hi Eric, >> >> On 12/21/2016 01:17 AM, Eric W. Biederman wrote: >>> "Michael Kerrisk (man-pages)" writes: >>> Hi Eric, On

[PATCH 0/3] xen: fix some minor bugs and cleanup of xenbus

Do some minor bug fixes and cleanup of xenbus driver. Juergen Gross (3): xen: xenbus driver must not accept invalid transaction ids xen: return xenstore command failures via response instead of rc xen: remove stale xs_input_avail() from header drivers/xen/xenbus/xenbus_comms.h| 1

Re: [PATCH 0/2] Add further ioctl() operations for namespace discovery

Hi Eric, On 12/22/2016 01:27 AM, Eric W. Biederman wrote: > "Michael Kerrisk (man-pages)" writes: > >> Hi Eric, >> >> On 12/21/2016 01:17 AM, Eric W. Biederman wrote: >>> "Michael Kerrisk (man-pages)" writes: >>> Hi Eric, On 12/20/2016 09:22 PM, Eric W. Biederman wrote: >

RE: ATH9 driver issues on ARM64

Hi All, After further debugging we know the place it hangs. In function: static int ath_reset_internal (struct ath_softc *sc, struct ath9k_channel *hchan) { disable_irq(sc->irq); tasklet_disable(>intr_tq); tasklet_disable(>bcon_tasklet);

RE: ATH9 driver issues on ARM64

Hi All, After further debugging we know the place it hangs. In function: static int ath_reset_internal (struct ath_softc *sc, struct ath9k_channel *hchan) { disable_irq(sc->irq); tasklet_disable(>intr_tq); tasklet_disable(>bcon_tasklet);

Re: [PATCH 2/2] nsfs: Add an ioctl() to return creator UID of a userns

Hi Andrei, On 12/21/2016 04:13 AM, Andrei Vagin wrote: > On Mon, Dec 19, 2016 at 03:38:35PM +0100, Michael Kerrisk (man-pages) wrote: >> # Some open questions about this patch below. >> # >> One of the rules regarding capabilities is: >> >> A process that resides in the parent of the user

Re: [PATCH 2/2] nsfs: Add an ioctl() to return creator UID of a userns

Hi Andrei, On 12/21/2016 04:13 AM, Andrei Vagin wrote: > On Mon, Dec 19, 2016 at 03:38:35PM +0100, Michael Kerrisk (man-pages) wrote: >> # Some open questions about this patch below. >> # >> One of the rules regarding capabilities is: >> >> A process that resides in the parent of the user

Re: [PATCH v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

On 22 December 2016 at 07:47, NeilBrown wrote: > On Wed, Dec 21 2016, Baolin Wang wrote: > >> On 21 December 2016 at 11:48, NeilBrown wrote: >>> On Wed, Dec 21 2016, Baolin Wang wrote: >>> Hi, On 21 December 2016 at 06:07, NeilBrown

Re: [PATCH v18 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

On 22 December 2016 at 07:47, NeilBrown wrote: > On Wed, Dec 21 2016, Baolin Wang wrote: > >> On 21 December 2016 at 11:48, NeilBrown wrote: >>> On Wed, Dec 21 2016, Baolin Wang wrote: >>> Hi, On 21 December 2016 at 06:07, NeilBrown wrote: > On Tue, Dec 20 2016, Baolin Wang

Re: [PATCH 2/2] net: wireless: fix to uses struct

Hi Ozgur, [auto build test ERROR on mac80211-next/master] [also build test ERROR on v4.9 next-20161221] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Ozgur-Karatas/net-wireless-fixed

Re: [PATCH 2/2] net: wireless: fix to uses struct

Hi Ozgur, [auto build test ERROR on mac80211-next/master] [also build test ERROR on v4.9 next-20161221] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Ozgur-Karatas/net-wireless-fixed

RE: [PATCH] acpi: Fix format string type mistakes

The original change doesn't handle ACPI_SIZE (which can be UINT64/UINT32 for different architectures) correctly. I changed it when it is back ported. This sounds like a different problem. Thanks and best regards Lv > From: Moore, Robert > Subject: RE: [PATCH] acpi: Fix format string type

RE: [PATCH] acpi: Fix format string type mistakes

The original change doesn't handle ACPI_SIZE (which can be UINT64/UINT32 for different architectures) correctly. I changed it when it is back ported. This sounds like a different problem. Thanks and best regards Lv > From: Moore, Robert > Subject: RE: [PATCH] acpi: Fix format string type

Re: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

On Wed, Dec 21, 2016 at 09:46:37PM -0800, Linus Torvalds wrote: > On Wed, Dec 21, 2016 at 9:13 PM, Dave Chinner wrote: > > > > There may be deeper issues. I just started running scalability tests > > (e.g. 16-way fsmark create tests) and about a minute in I got a > >

Re: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

On Wed, Dec 21, 2016 at 09:46:37PM -0800, Linus Torvalds wrote: > On Wed, Dec 21, 2016 at 9:13 PM, Dave Chinner wrote: > > > > There may be deeper issues. I just started running scalability tests > > (e.g. 16-way fsmark create tests) and about a minute in I got a > > directory corruption reported

Detecting kprobes generated code addresses

Hi Masami, I would like to make __kernel_text_address() be able to detect whether an address belongs to code which was generated by kprobes. As far as I can tell, that information seems to be in the 'pages' lists of kprobe_insn_slots and kprobe_optinsn_slots. But they seem to be protected by

Detecting kprobes generated code addresses

Hi Masami, I would like to make __kernel_text_address() be able to detect whether an address belongs to code which was generated by kprobes. As far as I can tell, that information seems to be in the 'pages' lists of kprobe_insn_slots and kprobe_optinsn_slots. But they seem to be protected by

[PATCH] ib umem: bug: put pid back before return from error path

I catched this bug when reading the code. I'm sorry I have no hardware to test it. But it is abviously a bug. Signed-off-by: Kenneth Lee --- drivers/infiniband/core/umem.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/infiniband/core/umem.c

[PATCH] ib umem: bug: put pid back before return from error path

I catched this bug when reading the code. I'm sorry I have no hardware to test it. But it is abviously a bug. Signed-off-by: Kenneth Lee --- drivers/infiniband/core/umem.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c index

Detecting kprobes generated code addresses

Hi Masami, I would like to make __kernel_text_address() be able to detect whether an address belongs to code which was generated by kprobes. As far as I can tell, that information seems to be in the 'pages' lists of kprobe_insn_slots and kprobe_optinsn_slots. But they seem to be protected by

Detecting kprobes generated code addresses

Hi Masami, I would like to make __kernel_text_address() be able to detect whether an address belongs to code which was generated by kprobes. As far as I can tell, that information seems to be in the 'pages' lists of kprobe_insn_slots and kprobe_optinsn_slots. But they seem to be protected by

Re: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

On Thu, Dec 22, 2016 at 05:30:46PM +1100, Dave Chinner wrote: > > For "normal" bios the for_each_segment loop iterates over bi_vcnt, > > so it will be ignored anyway. That being said both I and the lists > > got CCed halfway through the thread and I haven't seen the original > > report, so I'm

Re: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

On Thu, Dec 22, 2016 at 05:30:46PM +1100, Dave Chinner wrote: > > For "normal" bios the for_each_segment loop iterates over bi_vcnt, > > so it will be ignored anyway. That being said both I and the lists > > got CCed halfway through the thread and I haven't seen the original > > report, so I'm

Re: [PATCH v5 0/6] inherit dma configuration from parent dev

On Thu, Nov 17, 2016 at 5:13 PM, Sriram Dash wrote: > For xhci-hcd platform device, all the DMA parameters are not > configured properly, notably dma ops for dwc3 devices. > > The idea here is that you pass in the parent of_node along > with the child device pointer, so it

Re: [PATCH v5 0/6] inherit dma configuration from parent dev

On Thu, Nov 17, 2016 at 5:13 PM, Sriram Dash wrote: > For xhci-hcd platform device, all the DMA parameters are not > configured properly, notably dma ops for dwc3 devices. > > The idea here is that you pass in the parent of_node along > with the child device pointer, so it would behave exactly >

[GIT PULL] SELinux fix for 4.10

Please pull. >From Paul: "A small SELinux patch to fix some clang/llvm compiler warnings and ensure the tools under scripts work well in the face of kernel changes." The following changes since commit 52bce91165e5f2db422b2b972e83d389e5e4725c: splice: reinstate SIGPIPE/EPIPE handling

[GIT PULL] SELinux fix for 4.10

Please pull. >From Paul: "A small SELinux patch to fix some clang/llvm compiler warnings and ensure the tools under scripts work well in the face of kernel changes." The following changes since commit 52bce91165e5f2db422b2b972e83d389e5e4725c: splice: reinstate SIGPIPE/EPIPE handling

Re: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

On Thu, Dec 22, 2016 at 07:18:27AM +0100, Christoph Hellwig wrote: > On Wed, Dec 21, 2016 at 03:19:15PM -0800, Linus Torvalds wrote: > > Looking around a bit, the only even halfway suspicious scatterlist > > initialization thing I see is commit f9d03f96b988 ("block: improve > > handling of the

Re: Patch to include/linux/kernel.h breaks 3rd party modules.

On Wed, Dec 21, 2016 at 03:42:05PM -0500, Valdis Kletnieks wrote: > Yes, I know that usually out-of-tree modules are on their own. > However, this one may require a rethink.. > > (Sorry for not catching this sooner, I hadn't tried to deal with the > affected module since this patch hit linux-next

Re: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

On Thu, Dec 22, 2016 at 07:18:27AM +0100, Christoph Hellwig wrote: > On Wed, Dec 21, 2016 at 03:19:15PM -0800, Linus Torvalds wrote: > > Looking around a bit, the only even halfway suspicious scatterlist > > initialization thing I see is commit f9d03f96b988 ("block: improve > > handling of the

Re: Patch to include/linux/kernel.h breaks 3rd party modules.

On Wed, Dec 21, 2016 at 03:42:05PM -0500, Valdis Kletnieks wrote: > Yes, I know that usually out-of-tree modules are on their own. > However, this one may require a rethink.. > > (Sorry for not catching this sooner, I hadn't tried to deal with the > affected module since this patch hit linux-next

Re: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

On Thu, Dec 22, 2016 at 04:13:22PM +1100, Dave Chinner wrote: > On Wed, Dec 21, 2016 at 04:13:03PM -0800, Chris Leech wrote: > > On Wed, Dec 21, 2016 at 03:19:15PM -0800, Linus Torvalds wrote: > > > Hi, > > > > > > On Wed, Dec 21, 2016 at 2:16 PM, Dave Chinner wrote: > > > >

Re: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

On Thu, Dec 22, 2016 at 04:13:22PM +1100, Dave Chinner wrote: > On Wed, Dec 21, 2016 at 04:13:03PM -0800, Chris Leech wrote: > > On Wed, Dec 21, 2016 at 03:19:15PM -0800, Linus Torvalds wrote: > > > Hi, > > > > > > On Wed, Dec 21, 2016 at 2:16 PM, Dave Chinner wrote: > > > > On Fri, Dec 16, 2016

Re: [PATCH v1] security: Add a new hook: inode_touch_atime

On Thu, Dec 22, 2016 at 12:15:06AM +0100, Mickaël Salaün wrote: > Add a new LSM hook named inode_touch_atime which is needed to deny > indirect update of extended file attributes (i.e. access time) which are > not catched by the inode_setattr hook. By creating a new hook instead of > calling

Re: [PATCH v1] security: Add a new hook: inode_touch_atime

On Thu, Dec 22, 2016 at 12:15:06AM +0100, Mickaël Salaün wrote: > Add a new LSM hook named inode_touch_atime which is needed to deny > indirect update of extended file attributes (i.e. access time) which are > not catched by the inode_setattr hook. By creating a new hook instead of > calling

Re: [PATCH] Btrfs: add another missing end_page_writeback on submit_extent_page failure

On Fri, Dec 16, 2016 at 03:41:50PM +0900, Takafumi Kubota wrote: > This is actually inspired by Filipe's patch(55e3bd2e0c2e1). > > When submit_extent_page() in __extent_writepage_io() fails, > Btrfs misses clearing a writeback bit of the failed page. > This causes the false under-writeback page.

Re: [PATCH] Btrfs: add another missing end_page_writeback on submit_extent_page failure

On Fri, Dec 16, 2016 at 03:41:50PM +0900, Takafumi Kubota wrote: > This is actually inspired by Filipe's patch(55e3bd2e0c2e1). > > When submit_extent_page() in __extent_writepage_io() fails, > Btrfs misses clearing a writeback bit of the failed page. > This causes the false under-writeback page.

Re: [PATCH 1/2] arm64: setup: introduce kaslr_offset()

On Sun, Dec 11, 2016 at 03:50:55AM +0300, Alexander Popov wrote: > Introduce kaslr_offset() similarly to x86_64 for fixing kcov. > > Signed-off-by: Alexander Popov > --- > arch/arm64/include/asm/setup.h | 19 +++ > arch/arm64/include/uapi/asm/setup.h |

Re: [PATCH 1/2] arm64: setup: introduce kaslr_offset()

On Sun, Dec 11, 2016 at 03:50:55AM +0300, Alexander Popov wrote: > Introduce kaslr_offset() similarly to x86_64 for fixing kcov. > > Signed-off-by: Alexander Popov > --- > arch/arm64/include/asm/setup.h | 19 +++ > arch/arm64/include/uapi/asm/setup.h | 4 ++-- >

Re: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

On Wed, Dec 21, 2016 at 03:19:15PM -0800, Linus Torvalds wrote: > Looking around a bit, the only even halfway suspicious scatterlist > initialization thing I see is commit f9d03f96b988 ("block: improve > handling of the magic discard payload") which used to have a magic > hack wrt !bio->bi_vcnt,

Re: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

On Wed, Dec 21, 2016 at 03:19:15PM -0800, Linus Torvalds wrote: > Looking around a bit, the only even halfway suspicious scatterlist > initialization thing I see is commit f9d03f96b988 ("block: improve > handling of the magic discard payload") which used to have a magic > hack wrt !bio->bi_vcnt,

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

Hi Ted, On Thu, Dec 22, 2016 at 6:41 AM, Theodore Ts'o wrote: > The bottom line is that I think we're really "pixel peeping" at this > point --- which is what obsessed digital photographers will do when > debating the quality of a Canon vs Nikon DSLR by blowing up a photo by > a

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

Hi Ted, On Thu, Dec 22, 2016 at 6:41 AM, Theodore Ts'o wrote: > The bottom line is that I think we're really "pixel peeping" at this > point --- which is what obsessed digital photographers will do when > debating the quality of a Canon vs Nikon DSLR by blowing up a photo by > a thousand times,

[PATCH 3/3] perf sched timehist: Show total scheduling time

Show length of analyzed sample time and rate of idle task running. This also takes care of time range given by --time option. $ perf sched timehist -sI | tail Samples do not have callchains. Idle stats: CPU 0 idle for930.316 msec ( 92.93%) CPU 1 idle for963.614 msec

[PATCH 2/3] perf sched timehist: Fix invalid period calculation

When --time option is given with a value outside recorded time, the last sample time (tprev) was set to that value and run time calculation might be incorrect. This is a problem of the first samples for each cpus since it would skip the runtime update when tprev is 0. But with --time option it

[PATCH 1/3] perf sched timehist: Enlarge default comm_width

Current default value is 20 but it's easily changed to a bigger value as task has a long name and different tid and pid. And it makes the output not aligned. So change it to have a large value as summary shows. Signed-off-by: Namhyung Kim --- tools/perf/builtin-sched.c |

[PATCH 3/3] perf sched timehist: Show total scheduling time

Show length of analyzed sample time and rate of idle task running. This also takes care of time range given by --time option. $ perf sched timehist -sI | tail Samples do not have callchains. Idle stats: CPU 0 idle for930.316 msec ( 92.93%) CPU 1 idle for963.614 msec

[PATCH 2/3] perf sched timehist: Fix invalid period calculation

When --time option is given with a value outside recorded time, the last sample time (tprev) was set to that value and run time calculation might be incorrect. This is a problem of the first samples for each cpus since it would skip the runtime update when tprev is 0. But with --time option it

[PATCH 1/3] perf sched timehist: Enlarge default comm_width

Current default value is 20 but it's easily changed to a bigger value as task has a long name and different tid and pid. And it makes the output not aligned. So change it to have a large value as summary shows. Signed-off-by: Namhyung Kim --- tools/perf/builtin-sched.c | 12 +--- 1

Re: [PATCH] pci: add kernel config option for disabling common PCI quirks

On 21/12/2016 15:26, Christoph Hellwig wrote: > On Wed, Dec 21, 2016 at 02:11:25PM +0100, John Crispin wrote: >> I can turn it into an enable patch that is selected by default. >> >> The current patch disables all those quirks that are used for x86/PC >> style machines and hence are not required

Re: [PATCH] pci: add kernel config option for disabling common PCI quirks

On 21/12/2016 15:26, Christoph Hellwig wrote: > On Wed, Dec 21, 2016 at 02:11:25PM +0100, John Crispin wrote: >> I can turn it into an enable patch that is selected by default. >> >> The current patch disables all those quirks that are used for x86/PC >> style machines and hence are not required

Fwd: [PATCH 1/1] of/fdt: failed to mark hotplug range message

scripts/get_maintainers.pl did not show the people involved in creating the code to be changed. On 12/22/2016 06:34 AM, Heinrich Schuchardt wrote: > If marking a hotplug range fails a message > "failed to mark hotplug range" is written. > > The end address is base + size - 1. > > Signed-off-by:

Fwd: [PATCH 1/1] of/fdt: failed to mark hotplug range message

scripts/get_maintainers.pl did not show the people involved in creating the code to be changed. On 12/22/2016 06:34 AM, Heinrich Schuchardt wrote: > If marking a hotplug range fails a message > "failed to mark hotplug range" is written. > > The end address is base + size - 1. > > Signed-off-by:

[PATCH v5 14/14] irqchip: mbigen: Add ACPI support

From: Hanjun Guo With the preparation of platform msi support and interrupt producer in DSDT, we can add mbigen ACPI support now. We are using _PRS methd to indicate number of irq pins instead of num_pins in DT to avoid _DSD usage in this case. For mbi-gen,

[PATCH v5 14/14] irqchip: mbigen: Add ACPI support

From: Hanjun Guo With the preparation of platform msi support and interrupt producer in DSDT, we can add mbigen ACPI support now. We are using _PRS methd to indicate number of irq pins instead of num_pins in DT to avoid _DSD usage in this case. For mbi-gen, Device(MBI0) {

[PATCH] ARM64: zynqmp: Fix i2c node's compatible string

From: Moritz Fischer The Zynq Ultrascale MP uses version 1.4 of the Cadence IP core which fixes some silicon bugs that needed software workarounds in Version 1.0 that was used on Zynq systems. Signed-off-by: Moritz Fischer Cc: Michal Simek

[PATCH] ARM64: zynqmp: Fix i2c node's compatible string

From: Moritz Fischer The Zynq Ultrascale MP uses version 1.4 of the Cadence IP core which fixes some silicon bugs that needed software workarounds in Version 1.0 that was used on Zynq systems. Signed-off-by: Moritz Fischer Cc: Michal Simek Cc: Sören Brinkmann Cc: U-Boot List Cc: Rob Herring

Re: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

On Wed, Dec 21, 2016 at 9:13 PM, Dave Chinner wrote: > > There may be deeper issues. I just started running scalability tests > (e.g. 16-way fsmark create tests) and about a minute in I got a > directory corruption reported - something I hadn't seen in the dev > cycle at all.

Re: [4.10, panic, regression] iscsi: null pointer deref at iscsi_tcp_segment_done+0x20d/0x2e0

On Wed, Dec 21, 2016 at 9:13 PM, Dave Chinner wrote: > > There may be deeper issues. I just started running scalability tests > (e.g. 16-way fsmark create tests) and about a minute in I got a > directory corruption reported - something I hadn't seen in the dev > cycle at all. By "in the dev

[PATCH v5 00/14] ACPI platform MSI support and its example mbigen

From: Hanjun Guo v4 -> v5: - Add mbigen support back with tested on with Agustin's patchset, and it's a good example of how ACPI platform MSI works - rebased on top of lastest Linus tree (commit 52bce91 splice: reinstate SIGPIPE/EPIPE handling)

[PATCH v5 00/14] ACPI platform MSI support and its example mbigen

From: Hanjun Guo v4 -> v5: - Add mbigen support back with tested on with Agustin's patchset, and it's a good example of how ACPI platform MSI works - rebased on top of lastest Linus tree (commit 52bce91 splice: reinstate SIGPIPE/EPIPE handling) v3 -> v4: -

[PATCH v5 06/14] irqchip: gicv3-its: platform-msi: refactor its_pmsi_init() to prepare for ACPI

From: Hanjun Guo Introduce its_pmsi_init_one() to refactor the code to isolate ACPI common code to prepare for ACPI later. Signed-off-by: Hanjun Guo Tested-by: Sinan Kaya Cc: Marc Zyngier Cc: Tomasz

[PATCH v5 09/14] ACPI: platform: setup MSI domain for ACPI based platform device

From: Hanjun Guo With the platform msi domain created, we can set up the msi domain for a platform device when it's probed. In order to do that, we need to get the domain that the platform device connecting to, so the iort_get_platform_device_domain() is introduced to

[PATCH v5 09/14] ACPI: platform: setup MSI domain for ACPI based platform device

From: Hanjun Guo With the platform msi domain created, we can set up the msi domain for a platform device when it's probed. In order to do that, we need to get the domain that the platform device connecting to, so the iort_get_platform_device_domain() is introduced to retrieve the domain from

[PATCH v5 06/14] irqchip: gicv3-its: platform-msi: refactor its_pmsi_init() to prepare for ACPI

From: Hanjun Guo Introduce its_pmsi_init_one() to refactor the code to isolate ACPI common code to prepare for ACPI later. Signed-off-by: Hanjun Guo Tested-by: Sinan Kaya Cc: Marc Zyngier Cc: Tomasz Nowicki Cc: Thomas Gleixner --- drivers/irqchip/irq-gic-v3-its-platform-msi.c | 45

[PATCH v5 11/14] msi: platform: make platform_msi_create_device_domain() ACPI aware

From: Hanjun Guo With the platform msi domain created for ITS, irqchip such as mbi-gen connecting ITS, which needs ctreate its own irqdomain. Fortunately with the platform msi support upstreamed by Marc, we just need to add minor code to make it run properly.

[PATCH v5 11/14] msi: platform: make platform_msi_create_device_domain() ACPI aware

From: Hanjun Guo With the platform msi domain created for ITS, irqchip such as mbi-gen connecting ITS, which needs ctreate its own irqdomain. Fortunately with the platform msi support upstreamed by Marc, we just need to add minor code to make it run properly.

[PATCH v5 12/14] irqchip: mbigen: drop module owner

From: Kefeng Wang Module owner will be set by driver core, so drop it. Signed-off-by: Kefeng Wang Signed-off-by: Hanjun Guo Cc: Marc Zyngier Cc: Thomas Gleixner Cc: Ma

[PATCH v5 10/14] ACPI: ARM64: IORT: rework iort_node_get_id() for NC->SMMU->ITS case

From: Hanjun Guo iort_node_get_id() for now only support NC(named componant)->SMMU or NC->ITS cases, we also have other device topology such NC-> SMMU->ITS, so rework iort_node_get_id() for those cases. Signed-off-by: Hanjun Guo Cc: Lorenzo

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

On Wed, Dec 21, 2016 at 9:01 PM, George Spelvin wrote: > Andy Lutomirski wrote: >> I don't even think it needs that. This is just adding a >> non-destructive final operation, right? > > It is, but the problem is that SipHash is intended for *small* inputs, > so the

[PATCH v5 08/14] ACPI: ARM64: IORT: rework iort_node_get_id()

From: Hanjun Guo iort_node_get_id() has two output, one is the mapped ids, the other is the referenced parent node which is returned from the function. For now we need a API just return its parent node for single mapping, so just update this function slightly then reuse

[PATCH v5 12/14] irqchip: mbigen: drop module owner

From: Kefeng Wang Module owner will be set by driver core, so drop it. Signed-off-by: Kefeng Wang Signed-off-by: Hanjun Guo Cc: Marc Zyngier Cc: Thomas Gleixner Cc: Ma Jun --- drivers/irqchip/irq-mbigen.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/irqchip/irq-mbigen.c

[PATCH v5 10/14] ACPI: ARM64: IORT: rework iort_node_get_id() for NC->SMMU->ITS case

From: Hanjun Guo iort_node_get_id() for now only support NC(named componant)->SMMU or NC->ITS cases, we also have other device topology such NC-> SMMU->ITS, so rework iort_node_get_id() for those cases. Signed-off-by: Hanjun Guo Cc: Lorenzo Pieralisi --- drivers/acpi/arm64/iort.c | 59

Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)

On Wed, Dec 21, 2016 at 9:01 PM, George Spelvin wrote: > Andy Lutomirski wrote: >> I don't even think it needs that. This is just adding a >> non-destructive final operation, right? > > It is, but the problem is that SipHash is intended for *small* inputs, > so the standard implementations

[PATCH v5 08/14] ACPI: ARM64: IORT: rework iort_node_get_id()

From: Hanjun Guo iort_node_get_id() has two output, one is the mapped ids, the other is the referenced parent node which is returned from the function. For now we need a API just return its parent node for single mapping, so just update this function slightly then reuse it later.

[PATCH v5 02/14] irqchip: gic-v3-its: keep the head file include in alphabetic order

From: Hanjun Guo The head file is strictly in alphabetic order now, so let's be the rule breaker. As acpi_iort.h includes acpi.h so remove the duplidate acpi.h inclusion as well. Signed-off-by: Hanjun Guo Cc: Marc Zyngier Cc:

[PATCH v5 03/14] ACPI: ARM64: IORT: add missing comment for iort_dev_find_its_id()

From: Hanjun Guo We are missing req_id's comment for iort_dev_find_its_id(), add it back. Signed-off-by: Hanjun Guo Cc: Lorenzo Pieralisi Cc: Tomasz Nowicki --- drivers/acpi/arm64/iort.c | 1 + 1

[PATCH v5 05/14] ACPI: platform-msi: retrieve dev id from IORT

From: Hanjun Guo For devices connecting to ITS, it needs dev id to identify itself, and this dev id is represented in the IORT table in named componant node [1] for platform devices, so in this patch we will scan the IORT to retrieve device's dev id. Introduce

[PATCH v5 02/14] irqchip: gic-v3-its: keep the head file include in alphabetic order

From: Hanjun Guo The head file is strictly in alphabetic order now, so let's be the rule breaker. As acpi_iort.h includes acpi.h so remove the duplidate acpi.h inclusion as well. Signed-off-by: Hanjun Guo Cc: Marc Zyngier Cc: Tomasz Nowicki --- drivers/irqchip/irq-gic-v3-its.c | 3 +-- 1

[PATCH v5 03/14] ACPI: ARM64: IORT: add missing comment for iort_dev_find_its_id()

From: Hanjun Guo We are missing req_id's comment for iort_dev_find_its_id(), add it back. Signed-off-by: Hanjun Guo Cc: Lorenzo Pieralisi Cc: Tomasz Nowicki --- drivers/acpi/arm64/iort.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/acpi/arm64/iort.c

[PATCH v5 05/14] ACPI: platform-msi: retrieve dev id from IORT

From: Hanjun Guo For devices connecting to ITS, it needs dev id to identify itself, and this dev id is represented in the IORT table in named componant node [1] for platform devices, so in this patch we will scan the IORT to retrieve device's dev id. Introduce iort_pmsi_get_dev_id() with

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 03:49:39AM +0100, Jason A. Donenfeld wrote: > > Funny -- while you guys were sending this back & forth, I was writing > my reply to Andy which essentially arrives at the same conclusion. > Given that we're all arriving to the same thing, and that Ted shot in > this

Re: [kernel-hardening] Re: [PATCH v7 3/6] random: use SipHash in place of MD5

On Thu, Dec 22, 2016 at 03:49:39AM +0100, Jason A. Donenfeld wrote: > > Funny -- while you guys were sending this back & forth, I was writing > my reply to Andy which essentially arrives at the same conclusion. > Given that we're all arriving to the same thing, and that Ted shot in > this

  1   2   3   4   5   6   7   8   9   10   >