linux-next: manual merge of the pci tree with the net tree

Hi Bjorn, Today's linux-next merge of the pci tree got a conflict in: drivers/pci/probe.c between commit: a99b646afa8a ("PCI: Disable PCIe Relaxed Ordering if unsupported") from the net tree and commit: 62ce94a7a5a5 ("PCI: Mark Broadcom HT2100 Root Port Extended Tags as broken") from

linux-next: manual merge of the pci tree with the net tree

Hi Bjorn, Today's linux-next merge of the pci tree got a conflict in: drivers/pci/probe.c between commit: a99b646afa8a ("PCI: Disable PCIe Relaxed Ordering if unsupported") from the net tree and commit: 62ce94a7a5a5 ("PCI: Mark Broadcom HT2100 Root Port Extended Tags as broken") from

Re: [PATCH v2 0/5] fs, xfs: block map immutable files for dax, dma-to-storage, and swap

On Tue, Aug 15, 2017 at 1:37 AM, Jan Kara wrote: > On Mon 14-08-17 09:14:42, Dan Williams wrote: >> On Mon, Aug 14, 2017 at 5:40 AM, Jan Kara wrote: >> > On Sun 13-08-17 13:31:45, Dan Williams wrote: >> >> On Sun, Aug 13, 2017 at 2:24 AM, Christoph Hellwig

Re: [PATCH v2 0/5] fs, xfs: block map immutable files for dax, dma-to-storage, and swap

On Tue, Aug 15, 2017 at 1:37 AM, Jan Kara wrote: > On Mon 14-08-17 09:14:42, Dan Williams wrote: >> On Mon, Aug 14, 2017 at 5:40 AM, Jan Kara wrote: >> > On Sun 13-08-17 13:31:45, Dan Williams wrote: >> >> On Sun, Aug 13, 2017 at 2:24 AM, Christoph Hellwig wrote: >> >> > Thay being said I think

Re: [PATCH 1/2] sched/wait: Break up long wake list walk

On Tue, Aug 15, 2017 at 3:57 PM, Linus Torvalds wrote: > > Oh, and the page wait-queue really needs that key argument too, which > is another thing that swait queue code got rid of in the name of > simplicity. Actually, it gets worse. Because the page wait queues

Re: [PATCH 1/2] sched/wait: Break up long wake list walk

On Tue, Aug 15, 2017 at 3:57 PM, Linus Torvalds wrote: > > Oh, and the page wait-queue really needs that key argument too, which > is another thing that swait queue code got rid of in the name of > simplicity. Actually, it gets worse. Because the page wait queues are hashed, it's not an

Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files

On 08/15/17 14:15, Tom Rini wrote: > With support for stacked overlays being part of libfdt it is now > possible and likely that overlays which require __symbols__ will be > applied to the dtb files generated by the kernel. This is done by > passing -@ to dtc. This does increase the filesize

Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files

On 08/15/17 14:15, Tom Rini wrote: > With support for stacked overlays being part of libfdt it is now > possible and likely that overlays which require __symbols__ will be > applied to the dtb files generated by the kernel. This is done by > passing -@ to dtc. This does increase the filesize

[patch 2/2] mm, compaction: persistently skip hugetlbfs pageblocks

It is pointless to migrate hugetlb memory as part of memory compaction if the hugetlb size is equal to the pageblock order. No defragmentation is occurring in this condition. It is also pointless to for the freeing scanner to scan a pageblock where a hugetlb page is pinned. Unconditionally skip

[patch 2/2] mm, compaction: persistently skip hugetlbfs pageblocks

It is pointless to migrate hugetlb memory as part of memory compaction if the hugetlb size is equal to the pageblock order. No defragmentation is occurring in this condition. It is also pointless to for the freeing scanner to scan a pageblock where a hugetlb page is pinned. Unconditionally skip

[patch 1/2] mm, compaction: kcompactd should not ignore pageblock skip

Kcompactd is needlessly ignoring pageblock skip information. It is doing MIGRATE_SYNC_LIGHT compaction, which is no more powerful than MIGRATE_SYNC compaction. If compaction recently failed to isolate memory from a set of pageblocks, there is nothing to indicate that kcompactd will be able to do

[patch 1/2] mm, compaction: kcompactd should not ignore pageblock skip

Kcompactd is needlessly ignoring pageblock skip information. It is doing MIGRATE_SYNC_LIGHT compaction, which is no more powerful than MIGRATE_SYNC compaction. If compaction recently failed to isolate memory from a set of pageblocks, there is nothing to indicate that kcompactd will be able to do

Re: [PATCH v3 net-next] bpf/verifier: track liveness for pruning

From: Daniel Borkmann Date: Wed, 16 Aug 2017 00:12:58 +0200 > On 08/15/2017 09:34 PM, Edward Cree wrote: >> State of a register doesn't matter if it wasn't read in reaching an >> exit; >> a write screens off all reads downstream of it from all >> explored_states >>

Re: [PATCH v3 net-next] bpf/verifier: track liveness for pruning

From: Daniel Borkmann Date: Wed, 16 Aug 2017 00:12:58 +0200 > On 08/15/2017 09:34 PM, Edward Cree wrote: >> State of a register doesn't matter if it wasn't read in reaching an >> exit; >> a write screens off all reads downstream of it from all >> explored_states >> upstream of it. >> This

Re: [PATCH v2] acpi: apei: fix the wrongly iterate generic error status block

On 8/15/2017 3:34 PM, gengdongjiu wrote: Hi Tyler , Hello Boris, His patch fixes the define for apei_estatus_for_each_section which in turn should fix ghes_do_proc(). So my patch should no longer be needed. I'm going to test this out just to verify if fixes the issue I found. I have verified

Re: [PATCH v2] acpi: apei: fix the wrongly iterate generic error status block

On 8/15/2017 3:34 PM, gengdongjiu wrote: Hi Tyler , Hello Boris, His patch fixes the define for apei_estatus_for_each_section which in turn should fix ghes_do_proc(). So my patch should no longer be needed. I'm going to test this out just to verify if fixes the issue I found. I have verified

Re: Sometimes supports_usb_power_delivery reports incorrect value.

Submitted couple of patches for the missing pieces in TCPM. Those patches along with "usb: typec: update partner power delivery support with opmode" seems to address the issue of reporting the right value for supports_usb_power_delivery. Thanks, Badhri On Tue, Aug 15, 2017 at 7:13 AM, Badhri

Re: Sometimes supports_usb_power_delivery reports incorrect value.

Submitted couple of patches for the missing pieces in TCPM. Those patches along with "usb: typec: update partner power delivery support with opmode" seems to address the issue of reporting the right value for supports_usb_power_delivery. Thanks, Badhri On Tue, Aug 15, 2017 at 7:13 AM, Badhri

Loan

UNSECURED BUSINESS/PERSONAL LOAN BY LOAN CAPITAL FINANCE - NO COLLATERAL - MINIMUM DOCUMENTATION - BUSINESS LOAN UP TO FIVE(5) MILLION US DOLLARS CONTACT US TODAY VIA EMAIL: financecapital...@mail.com

Loan

UNSECURED BUSINESS/PERSONAL LOAN BY LOAN CAPITAL FINANCE - NO COLLATERAL - MINIMUM DOCUMENTATION - BUSINESS LOAN UP TO FIVE(5) MILLION US DOLLARS CONTACT US TODAY VIA EMAIL: financecapital...@mail.com

[PATCH 2/2] staging: typec: tcpm: explicit_contract is always established

While in SNK_READY state, the explicit_contract seems to be set to true irrespective of whether an explicit contract was established for the current connection. TCPM also seems to report the pwr_opmode as TYPEC_PWR_MODE_PD always once the port gets into SNK_READY state. This isn't completely true

[PATCH 2/2] staging: typec: tcpm: explicit_contract is always established

While in SNK_READY state, the explicit_contract seems to be set to true irrespective of whether an explicit contract was established for the current connection. TCPM also seems to report the pwr_opmode as TYPEC_PWR_MODE_PD always once the port gets into SNK_READY state. This isn't completely true

[PATCH 1/2] staging: typec: tcpm: Report right typec_pwr_opmode

At present, TCPM does not take into account the actual resistor value presented in the CC line and therefore reports TYPEC_PWR_MODE_USB irrespective of the power_op_mode it is in. This patch makes TCPM consider the actual value of Rp. Signed-off-by: Badhri Jagan Sridharan ---

[PATCH 1/2] staging: typec: tcpm: Report right typec_pwr_opmode

At present, TCPM does not take into account the actual resistor value presented in the CC line and therefore reports TYPEC_PWR_MODE_USB irrespective of the power_op_mode it is in. This patch makes TCPM consider the actual value of Rp. Signed-off-by: Badhri Jagan Sridharan ---

Re: [PATCH] blktrace: Fix potentail deadlock between delete & sysfs ops

On Thu, 10 Aug 2017 13:02:33 -0400 Waiman Long wrote: > The lockdep code had reported the following unsafe locking scenario: > >CPU0CPU1 > > lock(s_active#228); >

Re: [PATCH] blktrace: Fix potentail deadlock between delete & sysfs ops

On Thu, 10 Aug 2017 13:02:33 -0400 Waiman Long wrote: > The lockdep code had reported the following unsafe locking scenario: > >CPU0CPU1 > > lock(s_active#228); >lock(>bd_mutex/1); >

Re: [Xen-devel] [PATCH v06 26/36] uapi xen/privcmd.h: fix compilation in userspace

On Sun, 6 Aug 2017, Mikko Rapeli wrote: > xen/interface/xen.h is not exported from kernel headers so remove the > dependency and provide needed defines for domid_t and xen_pfn_t if they > are not already defined by some other e.g. Xen specific headers. > > Suggested by Andrew Cooper

Re: [Xen-devel] [PATCH v06 26/36] uapi xen/privcmd.h: fix compilation in userspace

On Sun, 6 Aug 2017, Mikko Rapeli wrote: > xen/interface/xen.h is not exported from kernel headers so remove the > dependency and provide needed defines for domid_t and xen_pfn_t if they > are not already defined by some other e.g. Xen specific headers. > > Suggested by Andrew Cooper on lkml

Re: [PATCH 1/2] sched/wait: Break up long wake list walk

On Tue, Aug 15, 2017 at 3:56 PM, Linus Torvalds wrote: > > Except they really don't actually work for this case, exactly because > they also simplify away "minor" details like exclusive vs > non-exclusive etc. > > The page wait-queue very much has a mix of "wake

Re: [PATCH 1/2] sched/wait: Break up long wake list walk

On Tue, Aug 15, 2017 at 3:56 PM, Linus Torvalds wrote: > > Except they really don't actually work for this case, exactly because > they also simplify away "minor" details like exclusive vs > non-exclusive etc. > > The page wait-queue very much has a mix of "wake all" and "wake one" > semantics.

Re: [PATCH 1/2] sched/wait: Break up long wake list walk

On Tue, Aug 15, 2017 at 3:47 PM, Davidlohr Bueso wrote: > > Or you can always use wake_qs; which exists _exactly_ for the issues you > are running into Except they really don't actually work for this case, exactly because they also simplify away "minor" details like exclusive

Re: [PATCH 1/2] sched/wait: Break up long wake list walk

On Tue, Aug 15, 2017 at 3:47 PM, Davidlohr Bueso wrote: > > Or you can always use wake_qs; which exists _exactly_ for the issues you > are running into Except they really don't actually work for this case, exactly because they also simplify away "minor" details like exclusive vs non-exclusive

Re: [PATCH v2 0/2] PCI: rcar-pcie: Fix memory leak

On Fri, Aug 04, 2017 at 12:32:53PM +0900, Harunobu Kurokawa wrote: > When no PCIe card is inserted, there is a memory leak as > pci_free_resource_list is not called before returning. > > v2: > separate the patch to two files. > > Harunobu Kurokawa (1): > PCI: rcar-pcie: Fix memory leak when

Re: [PATCH v2 0/2] PCI: rcar-pcie: Fix memory leak

On Fri, Aug 04, 2017 at 12:32:53PM +0900, Harunobu Kurokawa wrote: > When no PCIe card is inserted, there is a memory leak as > pci_free_resource_list is not called before returning. > > v2: > separate the patch to two files. > > Harunobu Kurokawa (1): > PCI: rcar-pcie: Fix memory leak when

Re: [PATCH 2/2] mm,fork: introduce MADV_WIPEONFORK

On Fri, 11 Aug 2017 17:28:29 -0400 r...@redhat.com wrote: > From: Rik van Riel > > Introduce MADV_WIPEONFORK semantics, which result in a VMA being > empty in the child process after fork. This differs from MADV_DONTFORK > in one important way. > > If a child process accesses

Re: [PATCH 2/2] mm,fork: introduce MADV_WIPEONFORK

On Fri, 11 Aug 2017 17:28:29 -0400 r...@redhat.com wrote: > From: Rik van Riel > > Introduce MADV_WIPEONFORK semantics, which result in a VMA being > empty in the child process after fork. This differs from MADV_DONTFORK > in one important way. > > If a child process accesses memory that was

Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files

On Tue, Aug 15, 2017 at 05:36:11PM -0500, Rob Herring wrote: > On Tue, Aug 15, 2017 at 4:15 PM, Tom Rini wrote: > > With support for stacked overlays being part of libfdt it is now > > possible and likely that overlays which require __symbols__ will be > > applied to the dtb

Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files

On Tue, Aug 15, 2017 at 05:36:11PM -0500, Rob Herring wrote: > On Tue, Aug 15, 2017 at 4:15 PM, Tom Rini wrote: > > With support for stacked overlays being part of libfdt it is now > > possible and likely that overlays which require __symbols__ will be > > applied to the dtb files generated by

Re: [PATCH 1/2] sched/wait: Break up long wake list walk

On Mon, 14 Aug 2017, Linus Torvalds wrote: On Mon, Aug 14, 2017 at 8:15 PM, Andi Kleen wrote: But what should we do when some other (non page) wait queue runs into the same problem? Hopefully the same: root-cause it. Or you can always use wake_qs; which exists

Re: [PATCH 1/2] sched/wait: Break up long wake list walk

On Mon, 14 Aug 2017, Linus Torvalds wrote: On Mon, Aug 14, 2017 at 8:15 PM, Andi Kleen wrote: But what should we do when some other (non page) wait queue runs into the same problem? Hopefully the same: root-cause it. Or you can always use wake_qs; which exists _exactly_ for the issues you

Re: [PATCH] pciehp: Fix infinite interupt handler loop

On Tue, Aug 15, 2017 at 03:48:25PM -0500, Bjorn Helgaas wrote: > On Mon, Aug 14, 2017 at 06:11:23PM -0400, Keith Busch wrote: > > On Mon, Aug 14, 2017 at 03:59:48PM -0500, Bjorn Helgaas wrote: > > > On Tue, Aug 01, 2017 at 03:11:52AM -0400, Keith Busch wrote: > > > > We've encountered a particular

Re: [PATCH] pciehp: Fix infinite interupt handler loop

On Tue, Aug 15, 2017 at 03:48:25PM -0500, Bjorn Helgaas wrote: > On Mon, Aug 14, 2017 at 06:11:23PM -0400, Keith Busch wrote: > > On Mon, Aug 14, 2017 at 03:59:48PM -0500, Bjorn Helgaas wrote: > > > On Tue, Aug 01, 2017 at 03:11:52AM -0400, Keith Busch wrote: > > > > We've encountered a particular

Re: [PATCH v2] platform/x86: ideapad-laptop: Expose conservation mode switch

On Mon, Aug 14, 2017 at 06:32:48PM +0300, Andy Shevchenko wrote: > On Mon, Aug 14, 2017 at 5:17 PM, Hao Wei Tee wrote: > > +static int method_gbmd(acpi_handle handle, unsigned long *ret) > > +{ > > + int val; > > + int result = read_method_int(handle, "GBMD", ); > >

Re: [PATCH v2] platform/x86: ideapad-laptop: Expose conservation mode switch

On Mon, Aug 14, 2017 at 06:32:48PM +0300, Andy Shevchenko wrote: > On Mon, Aug 14, 2017 at 5:17 PM, Hao Wei Tee wrote: > > +static int method_gbmd(acpi_handle handle, unsigned long *ret) > > +{ > > + int val; > > + int result = read_method_int(handle, "GBMD", ); > > Reversed X-mas

Re: [PATCH 0/2] PCI: dwc: convert remaining dbi read/writes to dw_pcie_readX_dbi/dw_pcie_writeX_dbi

[+cc Kishon, Pratyush] On Fri, Jul 14, 2017 at 02:07:33PM +0200, Niklas Cassel wrote: > Since the introduction of the dw_pcie_readX_dbi/dw_pcie_writeX_dbi macros, > most dw_pcie_read(pci->dbi_base, ..)/dw_pcie_write(pci->dbi_base, ..) calls > have been converted to

Re: [PATCH 0/2] PCI: dwc: convert remaining dbi read/writes to dw_pcie_readX_dbi/dw_pcie_writeX_dbi

[+cc Kishon, Pratyush] On Fri, Jul 14, 2017 at 02:07:33PM +0200, Niklas Cassel wrote: > Since the introduction of the dw_pcie_readX_dbi/dw_pcie_writeX_dbi macros, > most dw_pcie_read(pci->dbi_base, ..)/dw_pcie_write(pci->dbi_base, ..) calls > have been converted to

Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files

On Tue, Aug 15, 2017 at 4:15 PM, Tom Rini wrote: > With support for stacked overlays being part of libfdt it is now > possible and likely that overlays which require __symbols__ will be > applied to the dtb files generated by the kernel. This is done by > passing -@ to dtc.

Re: [PATCH] devicetree: Enable generation of __symbols__ in all dtb files

On Tue, Aug 15, 2017 at 4:15 PM, Tom Rini wrote: > With support for stacked overlays being part of libfdt it is now > possible and likely that overlays which require __symbols__ will be > applied to the dtb files generated by the kernel. This is done by > passing -@ to dtc. This does increase

Re: [tip:perf/core] perf test shell: Install shell tests

On Tue, 15 Aug 2017, Arnaldo Carvalho de Melo wrote: [...] > > > Perhaps its time, yes. Some questions: > > > > Do these tests assume that perf was built in some particular way, i.e. > > > as it is packaged for RHEL? > > > > Of course I run the testsuite most often on RHEL, but it should be > >

Re: [tip:perf/core] perf test shell: Install shell tests

On Tue, 15 Aug 2017, Arnaldo Carvalho de Melo wrote: [...] > > > Perhaps its time, yes. Some questions: > > > > Do these tests assume that perf was built in some particular way, i.e. > > > as it is packaged for RHEL? > > > > Of course I run the testsuite most often on RHEL, but it should be > >

Re: [PATCH v4 2/3] mm: introduce MAP_VALIDATE a mechanism for adding new mmap flags

On Tue, Aug 15, 2017 at 9:28 AM, Andy Lutomirski wrote: > On Mon, Aug 14, 2017 at 11:12 PM, Dan Williams > wrote: >> The mmap syscall suffers from the ABI anti-pattern of not validating >> unknown flags. However, proposals like MAP_SYNC and MAP_DIRECT

Re: [PATCH v4 2/3] mm: introduce MAP_VALIDATE a mechanism for adding new mmap flags

On Tue, Aug 15, 2017 at 9:28 AM, Andy Lutomirski wrote: > On Mon, Aug 14, 2017 at 11:12 PM, Dan Williams > wrote: >> The mmap syscall suffers from the ABI anti-pattern of not validating >> unknown flags. However, proposals like MAP_SYNC and MAP_DIRECT need a >> mechanism to define new behavior

[PATCH net-next 3/3] hv_sock: implements Hyper-V transport for Virtual Sockets (AF_VSOCK)

Hyper-V Sockets (hv_sock) supplies a byte-stream based communication mechanism between the host and the guest. It uses VMBus ringbuffer as the transportation layer. With hv_sock, applications between the host (Windows 10, Windows Server 2016 or newer) and the guest can talk with each other using

[PATCH net-next 3/3] hv_sock: implements Hyper-V transport for Virtual Sockets (AF_VSOCK)

Hyper-V Sockets (hv_sock) supplies a byte-stream based communication mechanism between the host and the guest. It uses VMBus ringbuffer as the transportation layer. With hv_sock, applications between the host (Windows 10, Windows Server 2016 or newer) and the guest can talk with each other using

[PATCH net-next 2/3] vsock: fix vsock_dequeue/enqueue_accept race

With the current code, when vsock_dequeue_accept() is removing a sock from the list, nothing prevents vsock_enqueue_accept() from adding a new sock into the list concurrently. We should add a lock to protect the list. Signed-off-by: Dexuan Cui Cc: Andy King

[PATCH net-next 2/3] vsock: fix vsock_dequeue/enqueue_accept race

With the current code, when vsock_dequeue_accept() is removing a sock from the list, nothing prevents vsock_enqueue_accept() from adding a new sock into the list concurrently. We should add a lock to protect the list. Signed-off-by: Dexuan Cui Cc: Andy King Cc: Dmitry Torokhov Cc: George

[PATCH net-next 1/3] VMCI: only load on VMware hypervisor

Without the patch, vmw_vsock_vmci_transport.ko and vmw_vmci.ko can automatically load when an application creates an AF_VSOCK socket. This is the expected good behavior on VMware hypervisor, but as we are going to add hv_sock.ko (i.e. Hyper-V transport for AF_VSOCK), we should make sure

[PATCH net-next 1/3] VMCI: only load on VMware hypervisor

Without the patch, vmw_vsock_vmci_transport.ko and vmw_vmci.ko can automatically load when an application creates an AF_VSOCK socket. This is the expected good behavior on VMware hypervisor, but as we are going to add hv_sock.ko (i.e. Hyper-V transport for AF_VSOCK), we should make sure

Re: [PATCH v3 net-next] bpf/verifier: track liveness for pruning

On 08/15/2017 09:34 PM, Edward Cree wrote: State of a register doesn't matter if it wasn't read in reaching an exit; a write screens off all reads downstream of it from all explored_states upstream of it. This allows us to prune many more branches; here are some processed insn counts for

Re: [PATCH v3 net-next] bpf/verifier: track liveness for pruning

On 08/15/2017 09:34 PM, Edward Cree wrote: State of a register doesn't matter if it wasn't read in reaching an exit; a write screens off all reads downstream of it from all explored_states upstream of it. This allows us to prune many more branches; here are some processed insn counts for

Re: [PATCH] swap: choose swap device according to numa node

On Tue, 15 Aug 2017 13:49:45 +0800 Aaron Lu wrote: > On Mon, Aug 14, 2017 at 04:33:37PM -0700, Andrew Morton wrote: > > On Mon, 14 Aug 2017 13:31:30 +0800 Aaron Lu wrote: > > > > > --- /dev/null > > > +++ b/Documentation/vm/swap_numa.txt > > > @@ -0,0

Re: [PATCH] swap: choose swap device according to numa node

On Tue, 15 Aug 2017 13:49:45 +0800 Aaron Lu wrote: > On Mon, Aug 14, 2017 at 04:33:37PM -0700, Andrew Morton wrote: > > On Mon, 14 Aug 2017 13:31:30 +0800 Aaron Lu wrote: > > > > > --- /dev/null > > > +++ b/Documentation/vm/swap_numa.txt > > > @@ -0,0 +1,18 @@ > > > +If the system has more

Re: [PATCH] nokia n900: update dts with camera support

Hi! > I understand Tony already applied this one. I'd have a few comments below, > could you address them in another patch, please? Yes. > > + rear_camera: camera@0 { > > + compatible = "linux,camera"; > > + > > + module { > > + model = "TCM8341MD"; > > +

Re: [PATCH] nokia n900: update dts with camera support

Hi! > I understand Tony already applied this one. I'd have a few comments below, > could you address them in another patch, please? Yes. > > + rear_camera: camera@0 { > > + compatible = "linux,camera"; > > + > > + module { > > + model = "TCM8341MD"; > > +

[GIT PULL] seccomp updates for next

Hi James, Please pull these seccomp changes for next. Thanks! -Kees The following changes since commit 520eccdfe187591a51ea9ab4c1a024ae4d0f68d9: Linux 4.13-rc2 (2017-07-23 16:15:17 -0700) are available in the git repository at:

[GIT PULL] seccomp updates for next

Hi James, Please pull these seccomp changes for next. Thanks! -Kees The following changes since commit 520eccdfe187591a51ea9ab4c1a024ae4d0f68d9: Linux 4.13-rc2 (2017-07-23 16:15:17 -0700) are available in the git repository at:

[PATCH net-next 0/3] add Hyper-V transport for Virtual Sockets

Hyper-V Sockets (hv_sock) supplies a byte-stream based communication mechanism between the host and the guest. It uses VMBus ringbuffer as the transportation layer. PATCH 01 and 02 are for VMCI and the common infrastructure vsock. PATCH 03 implements the necessary support in Linux guest by

[PATCH net-next 0/3] add Hyper-V transport for Virtual Sockets

Hyper-V Sockets (hv_sock) supplies a byte-stream based communication mechanism between the host and the guest. It uses VMBus ringbuffer as the transportation layer. PATCH 01 and 02 are for VMCI and the common infrastructure vsock. PATCH 03 implements the necessary support in Linux guest by

Re: [tpmdd-devel] [PATCH] tpm: improve tpm_tis send() performance by ignoring burstcount

On 8/13/2017 7:53 PM, msuchanek wrote: About 500 out of 700 mainboards sold today has a PS/2 port which is probably due to prevalence of legacy devices and usbhid limitations. Similarily many boards have serial and parallel hardware ports. In all diagrams detailed enough to show these ports I

Re: [tpmdd-devel] [PATCH] tpm: improve tpm_tis send() performance by ignoring burstcount

On 8/13/2017 7:53 PM, msuchanek wrote: About 500 out of 700 mainboards sold today has a PS/2 port which is probably due to prevalence of legacy devices and usbhid limitations. Similarily many boards have serial and parallel hardware ports. In all diagrams detailed enough to show these ports I

[PATCH] lib/rhashtable: fix comment on locks_mul default value

As of 4cf0b354d92 (rhashtable: avoid large lock-array allocations), the default value for the locks multiplier was reduced from 128 to 32. Update the header file to reflect this. Signed-off-by: Davidlohr Bueso --- include/linux/rhashtable.h | 2 +- 1 file changed, 1

[PATCH] lib/rhashtable: fix comment on locks_mul default value

As of 4cf0b354d92 (rhashtable: avoid large lock-array allocations), the default value for the locks multiplier was reduced from 128 to 32. Update the header file to reflect this. Signed-off-by: Davidlohr Bueso --- include/linux/rhashtable.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [v5 2/4] mm, oom: cgroup-aware OOM killer

On Tue, 15 Aug 2017, Roman Gushchin wrote: > > I'm curious about the decision made in this conditional and how > > oom_kill_memcg_member() ignores task->signal->oom_score_adj. It means > > that memory.oom_kill_all_tasks overrides /proc/pid/oom_score_adj if it > > should otherwise be disabled.

Re: [v5 2/4] mm, oom: cgroup-aware OOM killer

On Tue, 15 Aug 2017, Roman Gushchin wrote: > > I'm curious about the decision made in this conditional and how > > oom_kill_memcg_member() ignores task->signal->oom_score_adj. It means > > that memory.oom_kill_all_tasks overrides /proc/pid/oom_score_adj if it > > should otherwise be disabled.

Re: [PATCH 3/3] x86/efi: Use efi_switch_mm() rather than manually twiddling with cr3

On Tue, Aug 15, 2017 at 12:18 PM, Sai Praneeth Prakhya wrote: > +/* > + * Makes the calling kernel thread switch to/from efi_mm context > + * Can be used from SetVirtualAddressMap() or during efi runtime calls > + * (Note: This routine is heavily inspired from

Re: [PATCH 3/3] x86/efi: Use efi_switch_mm() rather than manually twiddling with cr3

On Tue, Aug 15, 2017 at 12:18 PM, Sai Praneeth Prakhya wrote: > +/* > + * Makes the calling kernel thread switch to/from efi_mm context > + * Can be used from SetVirtualAddressMap() or during efi runtime calls > + * (Note: This routine is heavily inspired from use_mm) > + */ > +void

Re: 答复: [iscsi] Deadlock occurred when network is in error

On Tue, 2017-08-15 at 02:16 +, Tangchen (UVP) wrote: > But I'm not using mq, and I run into these two problems in a non-mq system. > The patch you pointed out is fix for mq, so I don't think it can resolve this > problem. > > IIUC, mq is for SSD ? I'm not using ssd, so mq is disabled.

Re: 答复: [iscsi] Deadlock occurred when network is in error

On Tue, 2017-08-15 at 02:16 +, Tangchen (UVP) wrote: > But I'm not using mq, and I run into these two problems in a non-mq system. > The patch you pointed out is fix for mq, so I don't think it can resolve this > problem. > > IIUC, mq is for SSD ? I'm not using ssd, so mq is disabled.

Inconsistency in usb_add_gadget_udc_release() interface

Hello, usb_add_gadget_udc_release() gets release() argument that allows to release user resources. As far as I can see, the release() is called on error paths of usb_add_gadget_udc_release() as a result of put_device(>dev); except for the only path going via err1. As a result a caller of the

Inconsistency in usb_add_gadget_udc_release() interface

Hello, usb_add_gadget_udc_release() gets release() argument that allows to release user resources. As far as I can see, the release() is called on error paths of usb_add_gadget_udc_release() as a result of put_device(>dev); except for the only path going via err1. As a result a caller of the

Re: [PATCH] printk-formats.txt: Add examples for %pS and %pF

On Tue, 15 Aug 2017 21:47:27 +0200 Helge Deller wrote: > > Very interesting! > > > > This code: > > void smp_cpus_done() { > > printk("Called from %pF.\n", smp_cpus_done); > > printk("Called from %pf.\n", smp_cpus_done); > > printk("Called in %pS.\n", __func__); > >

Re: [PATCH] printk-formats.txt: Add examples for %pS and %pF

On Tue, 15 Aug 2017 21:47:27 +0200 Helge Deller wrote: > > Very interesting! > > > > This code: > > void smp_cpus_done() { > > printk("Called from %pF.\n", smp_cpus_done); > > printk("Called from %pf.\n", smp_cpus_done); > > printk("Called in %pS.\n", __func__); > > printk("Called in %ps.\n",

Re: [PATCH v2] acpi: apei: fix the wrongly iterate generic error status block

Hi Tyler , > Hello Boris, > > His patch fixes the define for apei_estatus_for_each_section which in turn > should fix ghes_do_proc(). So my patch should no longer be needed. I'm going > to test this out just to verify if fixes the issue I found. I have verified the issue about the iteration for

Re: [PATCH v2] acpi: apei: fix the wrongly iterate generic error status block

Hi Tyler , > Hello Boris, > > His patch fixes the define for apei_estatus_for_each_section which in turn > should fix ghes_do_proc(). So my patch should no longer be needed. I'm going > to test this out just to verify if fixes the issue I found. I have verified the issue about the iteration for

Re: [PATCH] pciehp: Fix infinite interupt handler loop

On Tue, Aug 15, 2017 at 01:48:25PM -0700, Bjorn Helgaas wrote: > On Mon, Aug 14, 2017 at 06:11:23PM -0400, Keith Busch wrote: > > On Mon, Aug 14, 2017 at 03:59:48PM -0500, Bjorn Helgaas wrote: > > > On Tue, Aug 01, 2017 at 03:11:52AM -0400, Keith Busch wrote: > > > > We've encountered a particular

Re: [PATCH] pciehp: Fix infinite interupt handler loop

On Tue, Aug 15, 2017 at 01:48:25PM -0700, Bjorn Helgaas wrote: > On Mon, Aug 14, 2017 at 06:11:23PM -0400, Keith Busch wrote: > > On Mon, Aug 14, 2017 at 03:59:48PM -0500, Bjorn Helgaas wrote: > > > On Tue, Aug 01, 2017 at 03:11:52AM -0400, Keith Busch wrote: > > > > We've encountered a particular

Re: [PATCH] ACPI/APEI: Add BERT data driver

On Tue, Aug 15, 2017 at 11:22:06AM +0100, Punit Agrawal wrote: > There is already a bert driver which prints the error record. Would it > make sense to integrate the character device there instead of creating a > new driver? Like this? The source code is smaller. But it doesn't offer the option

Re: [PATCH] ACPI/APEI: Add BERT data driver

On Tue, Aug 15, 2017 at 11:22:06AM +0100, Punit Agrawal wrote: > There is already a bert driver which prints the error record. Would it > make sense to integrate the character device there instead of creating a > new driver? Like this? The source code is smaller. But it doesn't offer the option

[PATCH] devicetree: Enable generation of __symbols__ in all dtb files

With support for stacked overlays being part of libfdt it is now possible and likely that overlays which require __symbols__ will be applied to the dtb files generated by the kernel. This is done by passing -@ to dtc. This does increase the filesize (and resident memory usage) based on the

[PATCH] devicetree: Enable generation of __symbols__ in all dtb files

With support for stacked overlays being part of libfdt it is now possible and likely that overlays which require __symbols__ will be applied to the dtb files generated by the kernel. This is done by passing -@ to dtc. This does increase the filesize (and resident memory usage) based on the

Re: meiI: can't suspend (mei_me_pm_runtime_suspend [mei_me] returned -62)

Dear Alexander, On 2017-08-14 08:35, Alexander Usyskin wrote: Can you try rc5? There is the patch included that should fix mei device suspend/resume flow. Commit 557909e195ae (mei: exclude device from suspend direct complete optimization) indeed seems to have fixed this. Thank you. Kind

Re: meiI: can't suspend (mei_me_pm_runtime_suspend [mei_me] returned -62)

Dear Alexander, On 2017-08-14 08:35, Alexander Usyskin wrote: Can you try rc5? There is the patch included that should fix mei device suspend/resume flow. Commit 557909e195ae (mei: exclude device from suspend direct complete optimization) indeed seems to have fixed this. Thank you. Kind

Re: [v5 4/4] mm, oom, docs: describe the cgroup-aware OOM killer

On Tue, 15 Aug 2017, Roman Gushchin wrote: > > > diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt > > > index dec5afdaa36d..22108f31e09d 100644 > > > --- a/Documentation/cgroup-v2.txt > > > +++ b/Documentation/cgroup-v2.txt > > > @@ -48,6 +48,7 @@ v1 is available under

Re: [v5 4/4] mm, oom, docs: describe the cgroup-aware OOM killer

On Tue, 15 Aug 2017, Roman Gushchin wrote: > > > diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt > > > index dec5afdaa36d..22108f31e09d 100644 > > > --- a/Documentation/cgroup-v2.txt > > > +++ b/Documentation/cgroup-v2.txt > > > @@ -48,6 +48,7 @@ v1 is available under

[PATCH v4 1/3] dt-bindings: i2c: Document the IBM CCF power supply version 1

From: "Edward A. James" Signed-off-by: Edward A. James --- .../devicetree/bindings/i2c/ibm,cffps1.txt | 21 + 1 file changed, 21 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/ibm,cffps1.txt diff

[PATCH v4 1/3] dt-bindings: i2c: Document the IBM CCF power supply version 1

From: "Edward A. James" Signed-off-by: Edward A. James --- .../devicetree/bindings/i2c/ibm,cffps1.txt | 21 + 1 file changed, 21 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/ibm,cffps1.txt diff --git

[PATCH v4 2/3] hwmon: (pmbus): Add IBM Common Form Factor (CFF) power supply driver

From: "Edward A. James" Add the driver to monitor IBM CFF power supplies with hwmon over pmbus. Signed-off-by: Edward A. James --- drivers/hwmon/pmbus/Kconfig | 10 +++ drivers/hwmon/pmbus/Makefile| 1 + drivers/hwmon/pmbus/ibm-cffps.c | 151

[PATCH v4 2/3] hwmon: (pmbus): Add IBM Common Form Factor (CFF) power supply driver

From: "Edward A. James" Add the driver to monitor IBM CFF power supplies with hwmon over pmbus. Signed-off-by: Edward A. James --- drivers/hwmon/pmbus/Kconfig | 10 +++ drivers/hwmon/pmbus/Makefile| 1 + drivers/hwmon/pmbus/ibm-cffps.c | 151

[PATCH v4 3/3] Documentation: hwmon: Document the IBM CFF power supply

From: "Edward A. James" Signed-off-by: Edward A. James --- Documentation/hwmon/ibm-cffps | 54 +++ 1 file changed, 54 insertions(+) create mode 100644 Documentation/hwmon/ibm-cffps diff --git

[PATCH v4 0/3] hwmon: (pmbus): Add IBM Common Form Factor (CFF) power supply driver

From: "Edward A. James" This series adds a hwmon pmbus driver for a POWER System power supply. The core monitoring functionality is provided by pmbus. Changes since v3: * Change "fault" to "alarm" in the documentation. Changes since v2: * Renamed the driver again... *

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