Re: [PATCH] clocksource: Add heuristics to avoid switching away from TSC due to timer delay

> /* > * Proper multiline comments look like this not like > * the above. > */ Got it, will fix next time around. > That aside. Why are you trying to do heuristics on the delta? > > We have way better information than that.

Re: [PATCH] clocksource: Add heuristics to avoid switching away from TSC due to timer delay

> /* > * Proper multiline comments look like this not like > * the above. > */ Got it, will fix next time around. > That aside. Why are you trying to do heuristics on the delta? > > We have way better information than that.

[tip:x86/timers] x86/hpet: Remove unused FSEC_PER_NSEC define

Commit-ID: d999c0ec2498e54b9328db6b2c1037710025add1 Gitweb: https://git.kernel.org/tip/d999c0ec2498e54b9328db6b2c1037710025add1 Author: Roland Dreier AuthorDate: Fri, 30 Nov 2018 13:14:50 -0800 Committer: Borislav Petkov CommitDate: Tue, 4 Dec 2018 12:17:21 +0100 x86/hpet: Remove

[tip:x86/timers] x86/hpet: Remove unused FSEC_PER_NSEC define

Commit-ID: d999c0ec2498e54b9328db6b2c1037710025add1 Gitweb: https://git.kernel.org/tip/d999c0ec2498e54b9328db6b2c1037710025add1 Author: Roland Dreier AuthorDate: Fri, 30 Nov 2018 13:14:50 -0800 Committer: Borislav Petkov CommitDate: Tue, 4 Dec 2018 12:17:21 +0100 x86/hpet: Remove

[PATCH] x86/hpet: Remove unused FSEC_PER_NSEC define

The FSEC_PER_NSEC macro has had zero users since commit ab0e08f15d23 ("x86: hpet: Cleanup the clockevents init and register code"). Signed-off-by: Roland Dreier --- arch/x86/kernel/hpet.c | 4 1 file changed, 4 deletions(-) diff --git a/arch/x86/kernel/hpet.c b/arch/x86/ker

[PATCH] x86/hpet: Remove unused FSEC_PER_NSEC define

The FSEC_PER_NSEC macro has had zero users since commit ab0e08f15d23 ("x86: hpet: Cleanup the clockevents init and register code"). Signed-off-by: Roland Dreier --- arch/x86/kernel/hpet.c | 4 1 file changed, 4 deletions(-) diff --git a/arch/x86/kernel/hpet.c b/arch/x86/ker

[PATCH] clocksource: Add heuristics to avoid switching away from TSC due to timer delay

detection of true instability very likely within a few clocksource watchdog iterations. Signed-off-by: Roland Dreier --- kernel/time/clocksource.c | 35 +++ 1 file changed, 35 insertions(+) diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c index

[PATCH] clocksource: Add heuristics to avoid switching away from TSC due to timer delay

detection of true instability very likely within a few clocksource watchdog iterations. Signed-off-by: Roland Dreier --- kernel/time/clocksource.c | 35 +++ 1 file changed, 35 insertions(+) diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c index

[PATCH] x86/hpet: Remove unused FSEC_PER_NSEC define

The FSEC_PER_NSEC macro has had zero users since commit ab0e08f15d23 ("x86: hpet: Cleanup the clockevents init and register code"). Signed-off-by: Roland Dreier --- arch/x86/kernel/hpet.c | 4 1 file changed, 4 deletions(-) diff --git a/arch/x86/kernel/hpet.c b/arch/x86/ker

[PATCH] x86/hpet: Remove unused FSEC_PER_NSEC define

The FSEC_PER_NSEC macro has had zero users since commit ab0e08f15d23 ("x86: hpet: Cleanup the clockevents init and register code"). Signed-off-by: Roland Dreier --- arch/x86/kernel/hpet.c | 4 1 file changed, 4 deletions(-) diff --git a/arch/x86/kernel/hpet.c b/arch/x86/ker

Re: [PATCH 0/3] Provide more fine grained control over multipathing

> The sensible thing to do in nvme is to use different paths for > different queues. That is e.g. in the RDMA case use the HCA closer > to a given CPU by default. We might allow to override this for > cases where the is a good reason, but what I really don't want is > configurability for

Re: [PATCH 0/3] Provide more fine grained control over multipathing

> The sensible thing to do in nvme is to use different paths for > different queues. That is e.g. in the RDMA case use the HCA closer > to a given CPU by default. We might allow to override this for > cases where the is a good reason, but what I really don't want is > configurability for

Re: [PATCH 0/3] Provide more fine grained control over multipathing

> Moreover, I also wanted to point out that fabrics array vendors are > building products that rely on standard nvme multipathing (and probably > multipathing over dispersed namespaces as well), and keeping a knob that > will keep nvme users with dm-multipath will probably not help them > educate

Re: [PATCH 0/3] Provide more fine grained control over multipathing

> Moreover, I also wanted to point out that fabrics array vendors are > building products that rely on standard nvme multipathing (and probably > multipathing over dispersed namespaces as well), and keeping a knob that > will keep nvme users with dm-multipath will probably not help them > educate

Re: KASAN: use-after-free Read in __list_add_valid (5)

> Still reproducible on Linus' tree (commit 66e1c94db3cd4e) and on linux-next > (next-20180511). Here's a simplified reproducer: Thanks! That's a fantastic test case. The issue is a race where rdma_listen() sees invalid state in the middle of an rdma_bind_addr() call that will ultimately fail.

Re: KASAN: use-after-free Read in __list_add_valid (5)

> Still reproducible on Linus' tree (commit 66e1c94db3cd4e) and on linux-next > (next-20180511). Here's a simplified reproducer: Thanks! That's a fantastic test case. The issue is a race where rdma_listen() sees invalid state in the middle of an rdma_bind_addr() call that will ultimately fail.

Re: [Patch v2 00/19] CIFS: Implement SMBDirect

> Starting with SMB2 dialect 3.0, Microsoft introduced SMBDirect transport > protocol for transferring upper layer (SMB2) payload over RDMA via > Infiniband, RoCE or iWARP. The prococol is published in [MS-SMBD] > (https://msdn.microsoft.com/en-us/library/hh536346.aspx). This is great to see.

Re: [Patch v2 00/19] CIFS: Implement SMBDirect

> Starting with SMB2 dialect 3.0, Microsoft introduced SMBDirect transport > protocol for transferring upper layer (SMB2) payload over RDMA via > Infiniband, RoCE or iWARP. The prococol is published in [MS-SMBD] > (https://msdn.microsoft.com/en-us/library/hh536346.aspx). This is great to see.

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

On Fri, Jul 8, 2016 at 9:51 AM, Jason Gunthorpe wrote: > So, it appears, the dst and neigh can be used for all performances cases. > > For the non performance dst == null case, can we just burn cycles and > stuff the daddr in front of the packet at hardheader

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

On Fri, Jul 8, 2016 at 9:51 AM, Jason Gunthorpe wrote: > So, it appears, the dst and neigh can be used for all performances cases. > > For the non performance dst == null case, can we just burn cycles and > stuff the daddr in front of the packet at hardheader time, even if we > have to copy? OK,

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

On Thu, Jul 7, 2016 at 4:14 PM, Jason Gunthorpe wrote: > We have neighbour_priv, and ndo_neigh_construct/destruct now .. > > A first blush that would seem to be enough to let ipoib store the AH > and other path information in the neigh and avoid the cb? At least

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

On Thu, Jul 7, 2016 at 4:14 PM, Jason Gunthorpe wrote: > We have neighbour_priv, and ndo_neigh_construct/destruct now .. > > A first blush that would seem to be enough to let ipoib store the AH > and other path information in the neigh and avoid the cb? At least the > example in clip sure looks

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

>> struct skb_gso_cb { >> int mac_offset; >> int encap_level; >> __u16 csum_start; >> }; > This is based on an out-dated version of this struct. The 4.7 RC > kernel has a few more fields that were added to support local checksum > offload for encapsulated

Re: Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

>> struct skb_gso_cb { >> int mac_offset; >> int encap_level; >> __u16 csum_start; >> }; > This is based on an out-dated version of this struct. The 4.7 RC > kernel has a few more fields that were added to support local checksum > offload for encapsulated

Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

On Thu, Jan 7, 2016 at 3:00 AM, Konstantin Khlebnikov wrote: > Or just shift GSO CB and add couple checks like > BUILD_BUG_ON(sizeof(SKB_GSO_CB(skb)->room) < sizeof(*IPCB(skb))); Resurrecting this old thread, because the patch that ultimately went upstream (commit 9207f9d45b0a

Resurrecting due to huge ipoib perf regression - [BUG] skb corruption and kernel panic at forwarding with fragmentation

On Thu, Jan 7, 2016 at 3:00 AM, Konstantin Khlebnikov wrote: > Or just shift GSO CB and add couple checks like > BUILD_BUG_ON(sizeof(SKB_GSO_CB(skb)->room) < sizeof(*IPCB(skb))); Resurrecting this old thread, because the patch that ultimately went upstream (commit 9207f9d45b0a / net: preserve IP

[PATCH] iommu/vt-d: Don't reject NTB devices due to scope mismatch

From: Roland Dreier <rol...@purestorage.com> On a system with an Intel PCIe port configured as an NTB device, iommu initialization fails with DMAR: Device scope type does not match for :80:03.0 This is because the DMAR table reports this device as having s

[PATCH] iommu/vt-d: Don't reject NTB devices due to scope mismatch

From: Roland Dreier On a system with an Intel PCIe port configured as an NTB device, iommu initialization fails with DMAR: Device scope type does not match for :80:03.0 This is because the DMAR table reports this device as having scope 2 (ACPI_DMAR_SCOPE_TYPE_BRIDGE): [0A0h 0160

Re: Regression in IO resource allocation

On Tue, May 31, 2016 at 3:31 PM, Rafael J. Wysocki <raf...@kernel.org> wrote: > It may not be called at all if _PTC is used on that system, for example. Yes, that's exactly the case on my system. So from my POV: Tested-by: Roland Dreier <rol...@purestorage.com> Thanks!

Re: Regression in IO resource allocation

On Tue, May 31, 2016 at 3:31 PM, Rafael J. Wysocki wrote: > It may not be called at all if _PTC is used on that system, for example. Yes, that's exactly the case on my system. So from my POV: Tested-by: Roland Dreier Thanks!

Re: Regression in IO resource allocation

On Tue, May 31, 2016 at 2:11 PM, Rafael J. Wysocki wrote: > Can you please try the appended patch (untested)? Thanks for the quick reply. Patch looks OK on my system... it boots (which is very good :) and I see system 00:01: [io 0x0400-0x047f] has been reserved

Re: Regression in IO resource allocation

On Tue, May 31, 2016 at 2:11 PM, Rafael J. Wysocki wrote: > Can you please try the appended patch (untested)? Thanks for the quick reply. Patch looks OK on my system... it boots (which is very good :) and I see system 00:01: [io 0x0400-0x047f] has been reserved however I don't see the

Regression in IO resource allocation

Hi, I recently updated one of my systems from 3.10.y to 4.4.11, and discovered a regression that stops it from booting. It's actually very similar to https://bugzilla.kernel.org/show_bug.cgi?id=99831 (which I reported about the same system last year). The problem is that commit ac212b6980d8

Regression in IO resource allocation

Hi, I recently updated one of my systems from 3.10.y to 4.4.11, and discovered a regression that stops it from booting. It's actually very similar to https://bugzilla.kernel.org/show_bug.cgi?id=99831 (which I reported about the same system last year). The problem is that commit ac212b6980d8

Re: Running out of IO space because of innocuous-looking DSDT change

On Mon, Oct 19, 2015 at 10:00 AM, Yinghai Lu wrote: > I would suggest to expand standard_io_resources[] to include all > possible conflict that we should avoid, like the io port for serial and > cf8/cf9. > > Then we could just set PCIBIOS_MIN_IO to 0 for x86. That would work on my system, which

Running out of IO space because of innocuous-looking DSDT change

I recently ran into an interesting issue with IO space allocation, and I'm looking for opinions on whether this is a BIOS issue, a kernel issue, both, or neither ;) What happened is that a BIOS update for my system changed the DSDT from having three ranges in PCI0: WordIO

Running out of IO space because of innocuous-looking DSDT change

I recently ran into an interesting issue with IO space allocation, and I'm looking for opinions on whether this is a BIOS issue, a kernel issue, both, or neither ;) What happened is that a BIOS update for my system changed the DSDT from having three ranges in PCI0: WordIO

Re: Running out of IO space because of innocuous-looking DSDT change

On Mon, Oct 19, 2015 at 10:00 AM, Yinghai Lu wrote: > I would suggest to expand standard_io_resources[] to include all > possible conflict that we should avoid, like the io port for serial and > cf8/cf9. > > Then we could just set PCIBIOS_MIN_IO to 0 for x86. That would work

Re: [PATCH] target/iscsi: fix digest computation for chained SGs

On Tue, Jul 21, 2015 at 1:57 AM, Sagi Grimberg wrote: > How were you able to get a chained SG list in the target code? Local hack. So this bug can't be hit in current mainline code, but patch improves the code and removes a hidden booby-trap, so I think it makes sense to apply. -- To

Re: [PATCH] target/iscsi: fix digest computation for chained SGs

On Tue, Jul 21, 2015 at 1:57 AM, Sagi Grimberg sa...@dev.mellanox.co.il wrote: How were you able to get a chained SG list in the target code? Local hack. So this bug can't be hit in current mainline code, but patch improves the code and removes a hidden booby-trap, so I think it makes sense to

Re: Regression in 3.10.80 vs. 3.10.79

On Sat, Jun 13, 2015 at 9:56 AM, Roland Dreier wrote: > Below is a more sophisticated, so to speak, version of it with a changelog and > all. It works for me, but more testing would be much appreciated. Yes, the patch works as expected: Tested-by: Roland Dreier It does change /proc/i

Re: Regression in 3.10.80 vs. 3.10.79

On Sat, Jun 13, 2015 at 9:56 AM, Roland Dreier rol...@purestorage.com wrote: Below is a more sophisticated, so to speak, version of it with a changelog and all. It works for me, but more testing would be much appreciated. Yes, the patch works as expected: Tested-by: Roland Dreier rol

Re: Regression in 3.10.80 vs. 3.10.79

On Fri, Jun 12, 2015 at 7:52 PM, Rafael J. Wysocki wrote: > Below is a more sophisticated, so to speak, version of it with a changelog and > all. It works for me, but more testing would be much appreciated. Great, I'm convinced by your reasoning that this makes sense. I'm building 3.10.80

Re: Regression in 3.10.80 vs. 3.10.79

On Fri, Jun 12, 2015 at 7:52 PM, Rafael J. Wysocki r...@rjwysocki.net wrote: Below is a more sophisticated, so to speak, version of it with a changelog and all. It works for me, but more testing would be much appreciated. Great, I'm convinced by your reasoning that this makes sense. I'm

Re: Regression in 3.10.80 vs. 3.10.79

On Thu, Jun 11, 2015 at 1:50 PM, Rafael J. Wysocki wrote: > Changing the ordering between those two routines would work around that > problem, > but in my view that wouldn't be a proper fix. In fact, the role of > reserve_range() > is to reserve the resources so as to prevent them from being

Re: Regression in 3.10.80 vs. 3.10.79

On Thu, Jun 11, 2015 at 1:50 PM, Rafael J. Wysocki r...@rjwysocki.net wrote: Changing the ordering between those two routines would work around that problem, but in my view that wouldn't be a proper fix. In fact, the role of reserve_range() is to reserve the resources so as to prevent them

Re: Regression in 3.10.80 vs. 3.10.79

On Wed, Jun 10, 2015 at 4:23 PM, Rafael J. Wysocki wrote: > Can you please file a bug at bugzilla.kernel.org to track this and attach > the output of acpidump from the affected system in there? Done: https://bugzilla.kernel.org/show_bug.cgi?id=99831 Thanks! -- To unsubscribe from this list:

Re: Regression in 3.10.80 vs. 3.10.79

On Wed, Jun 10, 2015 at 4:23 PM, Rafael J. Wysocki r...@rjwysocki.net wrote: Can you please file a bug at bugzilla.kernel.org to track this and attach the output of acpidump from the affected system in there? Done: https://bugzilla.kernel.org/show_bug.cgi?id=99831 Thanks! -- To unsubscribe

Re: Regression in 3.10.80 vs. 3.10.79

On Tue, Jun 9, 2015 at 4:43 PM, Roland Dreier wrote: > I understand that the change here fixed another regression, but I'm > wondering if there's a way to make everyone happy here? I can provide > debugging info from my system as required... Maybe sent my mail too quickly, as I

Regression in 3.10.80 vs. 3.10.79

Hi, I recently updated from 3.10.79 to 3.10.80, and my system wouldn't boot any more. I tracked this down to commit 92c934b10ec3 ("ACPI / init: Fix the ordering of acpi_reserve_resources()"). With that commit reverted, my system is OK again. What happens is that ahci fails to initialize because

Re: Regression in 3.10.80 vs. 3.10.79

On Tue, Jun 9, 2015 at 4:43 PM, Roland Dreier rol...@purestorage.com wrote: I understand that the change here fixed another regression, but I'm wondering if there's a way to make everyone happy here? I can provide debugging info from my system as required... Maybe sent my mail too quickly

Regression in 3.10.80 vs. 3.10.79

Hi, I recently updated from 3.10.79 to 3.10.80, and my system wouldn't boot any more. I tracked this down to commit 92c934b10ec3 (ACPI / init: Fix the ordering of acpi_reserve_resources()). With that commit reverted, my system is OK again. What happens is that ahci fails to initialize because

[GIT PULL] please pull infiniband.git

Hi Linus, Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git tags/rdma-for-linus InfiniBand/RDMA updates for 4.1: - IPoIB fixes from Doug Ledford and Erez Shitrit - iSER updates from Sagi

[GIT PULL] please pull infiniband.git

Hi Linus, Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git tags/rdma-for-linus InfiniBand/RDMA updates for 4.1: - IPoIB fixes from Doug Ledford and Erez Shitrit - iSER updates from Sagi

Re: [PATCH v3 07/28] IB/Verbs: Reform IB-ulp ipoib

On Thu, Apr 16, 2015 at 9:44 AM, Jason Gunthorpe wrote: >> We can give client->add() callback a return value and make >> ib_register_device() return -ENOMEM when it failed, just wondering >> why we don't do this at first, any special reason? > No idea, but having ib_register_device fail and

Re: [PATCH v3 07/28] IB/Verbs: Reform IB-ulp ipoib

On Thu, Apr 16, 2015 at 9:44 AM, Jason Gunthorpe jguntho...@obsidianresearch.com wrote: We can give client-add() callback a return value and make ib_register_device() return -ENOMEM when it failed, just wondering why we don't do this at first, any special reason? No idea, but having

[GIT PULL] please pull infiniband.git

Hi Linus, Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git tags/rdma-for-linus One 4.0 RDMA change: - Fix for exploitable integer overflow in uverbs interface.

[GIT PULL] please pull infiniband.git

Hi Linus, Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git tags/rdma-for-linus One 4.0 RDMA change: - Fix for exploitable integer overflow in uverbs interface.

[GIT PULL] please pull infiniband.git

better code for ocrdma_srq_toggle_bit RDMA/ocrdma: Use unsigned for bit index Rickard Strandqvist (1): IB/ipath: Remove unused function in ipath_wc_ppc64 Roi Dayan (1): IB/iser: Use correct dma direction when unmapping SGs Roland Dreier (1): Merge branches 'core', 'cxgb4

[GIT PULL] please pull infiniband.git

better code for ocrdma_srq_toggle_bit RDMA/ocrdma: Use unsigned for bit index Rickard Strandqvist (1): IB/ipath: Remove unused function in ipath_wc_ppc64 Roi Dayan (1): IB/iser: Use correct dma direction when unmapping SGs Roland Dreier (1): Merge branches 'core', 'cxgb4

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

On Tue, Feb 17, 2015 at 6:32 PM, Stephen Rothwell wrote: > After merging the livepatching tree, today's linux-next build (powerpc > allyesconfig) failed like this: > > In file included from drivers/infiniband/hw/qib/qib_cq.c:41:0: > drivers/infiniband/hw/qib/qib.h: In function 'qib_flush_wc': >

Re: [PATCH 1/1] IB/mthca: remove deprecated use of pci api

On Wed, Feb 4, 2015 at 6:09 AM, Quentin Lambert wrote: > - dev->eq_table.icm_dma = pci_map_page(dev->pdev, > dev->eq_table.icm_page, 0, > - PAGE_SIZE, > PCI_DMA_BIDIRECTIONAL); > - if (pci_dma_mapping_error(dev->pdev,

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

On Tue, Feb 17, 2015 at 6:32 PM, Stephen Rothwell s...@canb.auug.org.au wrote: After merging the livepatching tree, today's linux-next build (powerpc allyesconfig) failed like this: In file included from drivers/infiniband/hw/qib/qib_cq.c:41:0: drivers/infiniband/hw/qib/qib.h: In function

Re: [PATCH 1/1] IB/mthca: remove deprecated use of pci api

On Wed, Feb 4, 2015 at 6:09 AM, Quentin Lambert lambert.quen...@gmail.com wrote: - dev-eq_table.icm_dma = pci_map_page(dev-pdev, dev-eq_table.icm_page, 0, - PAGE_SIZE, PCI_DMA_BIDIRECTIONAL); - if (pci_dma_mapping_error(dev-pdev,

[GIT PULL] please pull infiniband.git

Hi Linus, Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git tags/rdma-for-linus One more last-second RDMA change for 3.19: - Yann realized that the previous revert of new userspace ABI did

[GIT PULL] please pull infiniband.git

Hi Linus, Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git tags/rdma-for-linus One more last-second RDMA change for 3.19: - Yann realized that the previous revert of new userspace ABI did

[GIT PULL] please pull infiniband.git

han freeze something in a rush and make a mistake, we'll take a bit more time and get it right in 3.20. Haggai Eran (1): IB/core: Temporarily disable ex_query_device uverb Roland Dreier (9): Revert "IPoIB: No l

[GIT PULL] please pull infiniband.git

in a rush and make a mistake, we'll take a bit more time and get it right in 3.20. Haggai Eran (1): IB/core: Temporarily disable ex_query_device uverb Roland Dreier (9): Revert IPoIB: No longer use flush as a parameter

[GIT PULL] please pull infiniband.git

Kehati (1): IB/addr: Improve address resolution callback scheduling Pramod Kumar (2): RDMA/cxgb4: Increase epd buff size for debug interface RDMA/cxgb4: Configure 0B MRs to match HW implementation Roland Dreier (2): mlx5_core: Re-add MLX5_DEV_CAP_FLAG_ON_DMND_PG flag

[GIT PULL] please pull infiniband.git

): IB/addr: Improve address resolution callback scheduling Pramod Kumar (2): RDMA/cxgb4: Increase epd buff size for debug interface RDMA/cxgb4: Configure 0B MRs to match HW implementation Roland Dreier (2): mlx5_core: Re-add MLX5_DEV_CAP_FLAG_ON_DMND_PG flag Merge

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

On Mon, Dec 15, 2014 at 5:56 PM, Roland Dreier wrote: > I'll add a partial revert of that patch to my tree to get back the > now-used enum values. I rebased my tree on top of the merge-window merge of davem's tree, and added the missing flag on top of the "remove this flag&quo

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

On Mon, Dec 15, 2014 at 5:47 PM, Stephen Rothwell wrote: > Hi all, > > After merging the infiniband tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > drivers/infiniband/hw/mlx5/main.c: In function 'mlx5_ib_query_device': > drivers/infiniband/hw/mlx5/main.c:248:34:

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

On Mon, Dec 15, 2014 at 5:47 PM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi all, After merging the infiniband tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/infiniband/hw/mlx5/main.c: In function 'mlx5_ib_query_device':

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

On Mon, Dec 15, 2014 at 5:56 PM, Roland Dreier rol...@kernel.org wrote: I'll add a partial revert of that patch to my tree to get back the now-used enum values. I rebased my tree on top of the merge-window merge of davem's tree, and added the missing flag on top of the remove this flag commit

[GIT PULL] please pull infiniband.git

/iser: Remove unused variables and dead code Roland Dreier (1): Merge branches 'core', 'cxgb4', 'iser', 'mlx5' and 'ocrdma' into for-next Sagi Grimberg (23): IB/iser: Rename ib_conn -> iser_conn IB/iser: Re-introduce ib_conn IB/iser: Extend iser_free_ib_conn_res()

[GIT PULL] please pull infiniband.git

/iser: Remove unused variables and dead code Roland Dreier (1): Merge branches 'core', 'cxgb4', 'iser', 'mlx5' and 'ocrdma' into for-next Sagi Grimberg (23): IB/iser: Rename ib_conn - iser_conn IB/iser: Re-introduce ib_conn IB/iser: Extend iser_free_ib_conn_res() IB

[GIT PULL] please pull infiniband.git

: Avoid executing gid task when device is being removed Or Gerlitz (1): IB/iser: Bump version to 1.4.1 Roi Dayan (1): IB/iser: Fix RX/TX CQ resource leak on error flow Roland Dreier (1): Merge branches 'core', 'ipoib', 'iser', 'mlx4', 'ocrdma' and 'qib' into for-next Sagi

[GIT PULL] please pull infiniband.git

: Avoid executing gid task when device is being removed Or Gerlitz (1): IB/iser: Bump version to 1.4.1 Roi Dayan (1): IB/iser: Fix RX/TX CQ resource leak on error flow Roland Dreier (1): Merge branches 'core', 'ipoib', 'iser', 'mlx4', 'ocrdma' and 'qib' into for-next Sagi

Re: [PATCH v1 for-next 00/16] On demand paging

> I would like to note that we at Los Alamos National Laboratory are very > interested in this functionality and it would be great if it gets accepted. Have you done any review or testing of these changes? If so can you share the results? - R. -- To unsubscribe from this list: send the line

Re: [PATCH v1 for-next 00/16] On demand paging

I would like to note that we at Los Alamos National Laboratory are very interested in this functionality and it would be great if it gets accepted. Have you done any review or testing of these changes? If so can you share the results? - R. -- To unsubscribe from this list: send the line

[GIT PULL] please pull infiniband.git

handling IB/iser: Clarify a duplicate counters check Roland Dreier (1): Merge branches 'core', 'cxgb4', 'ipoib', 'iser', 'iwcm', 'mad', 'misc', 'mlx4', 'mlx5', 'ocrdma' and 'srp' into for-next Sagi Grimberg (2): IB/iser: Fix responder resources advertisement IB/iser

[GIT PULL] please pull infiniband.git

handling IB/iser: Clarify a duplicate counters check Roland Dreier (1): Merge branches 'core', 'cxgb4', 'ipoib', 'iser', 'iwcm', 'mad', 'misc', 'mlx4', 'mlx5', 'ocrdma' and 'srp' into for-next Sagi Grimberg (2): IB/iser: Fix responder resources advertisement IB/iser

[GIT PULL] please pull infiniband.git

fixes Hariprasad S (2): RDMA/cxgb4: Fix skb_leak in reject_cr() RDMA/cxgb4: Clean up connection on ARP error Or Gerlitz (1): IB/mlx5: Enable "block multicast loopback" for kernel consumers Roland

[GIT PULL] please pull infiniband.git

fixes Hariprasad S (2): RDMA/cxgb4: Fix skb_leak in reject_cr() RDMA/cxgb4: Clean up connection on ARP error Or Gerlitz (1): IB/mlx5: Enable block multicast loopback for kernel consumers Roland Dreier (1

[GIT PULL] please pull infiniband.git

to use GFP_NOIO allocations Roi Dayan (1): IB/iser: Add missing newlines to logging messages Roland Dreier (6): IB/mlx5: Fix warning about cast of wr_id back to pointer on 32 bits mlx4_core: Move handling of MLX4_QP_ST_MLX to proper switch statement IB/mad: Fix sparse

[GIT PULL] please pull infiniband.git

to use GFP_NOIO allocations Roi Dayan (1): IB/iser: Add missing newlines to logging messages Roland Dreier (6): IB/mlx5: Fix warning about cast of wr_id back to pointer on 32 bits mlx4_core: Move handling of MLX4_QP_ST_MLX to proper switch statement IB/mad: Fix sparse

Re: [PATCH v1 for-next 0/3] IB: Use GFP_NOIO calls in IPoIB connected mode TX path

On Sat, May 17, 2014 at 1:52 PM, Or Gerlitz wrote: > Roland, we're soon on -rc6 and there's no reason for this to miss > 3.16, could you please comment whether you want it to go through your > tree or net-next? I will pick it up. -- To unsubscribe from this list: send the line "unsubscribe

Re: [PATCH v1 for-next 0/3] IB: Use GFP_NOIO calls in IPoIB connected mode TX path

On Sat, May 17, 2014 at 1:52 PM, Or Gerlitz or.gerl...@gmail.com wrote: Roland, we're soon on -rc6 and there's no reason for this to miss 3.16, could you please comment whether you want it to go through your tree or net-next? I will pick it up. -- To unsubscribe from this list: send the line

[tip:x86/mm] x86, ioremap: Speed up check for RAM pages

Commit-ID: c81c8a1eeede61e92a15103748c23d100880cc8a Gitweb: http://git.kernel.org/tip/c81c8a1eeede61e92a15103748c23d100880cc8a Author: Roland Dreier AuthorDate: Fri, 2 May 2014 11:18:41 -0700 Committer: H. Peter Anvin CommitDate: Fri, 2 May 2014 11:52:26 -0700 x86, ioremap: Speed up

[PATCH] x86, ioremap: Speed up check for RAM pages

From: Roland Dreier In __ioremap_caller() (the guts of ioremap), we loop over the range of pfns being remapped and checks each one individually with page_is_ram(). For large ioremaps, this can be very slow. For example, we have a device with a 256 GiB PCI BAR, and ioremapping this BAR can take

[PATCH] x86, ioremap: Speed up check for RAM pages

From: Roland Dreier rol...@purestorage.com In __ioremap_caller() (the guts of ioremap), we loop over the range of pfns being remapped and checks each one individually with page_is_ram(). For large ioremaps, this can be very slow. For example, we have a device with a 256 GiB PCI BAR

[tip:x86/mm] x86, ioremap: Speed up check for RAM pages

Commit-ID: c81c8a1eeede61e92a15103748c23d100880cc8a Gitweb: http://git.kernel.org/tip/c81c8a1eeede61e92a15103748c23d100880cc8a Author: Roland Dreier rol...@purestorage.com AuthorDate: Fri, 2 May 2014 11:18:41 -0700 Committer: H. Peter Anvin h...@linux.intel.com CommitDate: Fri, 2 May

[GIT PULL] please pull infiniband.git

Hi Linus, Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git tags/rdma-for-linus InfiniBand/RDMA updates for 3.15-rc4: - cxgb4 hardware driver fixes

[GIT PULL] please pull infiniband.git

Hi Linus, Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git tags/rdma-for-linus InfiniBand/RDMA updates for 3.15-rc4: - cxgb4 hardware driver fixes

[GIT PULL] please pull infiniband.git

() instead of pci_enable_msix() Eli Cohen (1): IB/mlx5: Add block multicast loopback support Hariprasad Shenai (1): RDMA/cxgb4: Use pr_warn_ratelimited Roland Dreier (1): Merge branches 'cxgb4', 'misc', 'mlx5' and 'qib' into for-next Steve Wise (9): RDMA/cxgb4: Use the BAR2/WC

[GIT PULL] please pull infiniband.git

() instead of pci_enable_msix() Eli Cohen (1): IB/mlx5: Add block multicast loopback support Hariprasad Shenai (1): RDMA/cxgb4: Use pr_warn_ratelimited Roland Dreier (1): Merge branches 'cxgb4', 'misc', 'mlx5' and 'qib' into for-next Steve Wise (9): RDMA/cxgb4: Use the BAR2/WC

[GIT PULL] please pull infiniband.git

once connection is established IB/iser: Update Mellanox copyright note IB/iser: Bump driver version to 1.3 Prarit Bhargava (1): RDMA/ocrdma: Fix compiler warning Randy Dunlap (1): IB/iser: Fix sector_t format warning Roi Dayan (1): IB/iser: Drain the tx cq once befor

[GIT PULL] please pull infiniband.git

/iser: Update Mellanox copyright note IB/iser: Bump driver version to 1.3 Prarit Bhargava (1): RDMA/ocrdma: Fix compiler warning Randy Dunlap (1): IB/iser: Fix sector_t format warning Roi Dayan (1): IB/iser: Drain the tx cq once before looping on the rx cq Roland Dreier (2

Re: linux rdma 3.14 merge plans

tches on top of previous > series of patches. > > -Regards > Devesh > > -Original Message- > From: linux-rdma-ow...@vger.kernel.org > [mailto:linux-rdma-ow...@vger.kernel.org] On Behalf Of Nicholas A. Bellinger > Sent: Thursday, March 06, 2014 12:34 AM > To: Roland

Re: linux rdma 3.14 merge plans

patches on top of previous series of patches. -Regards Devesh -Original Message- From: linux-rdma-ow...@vger.kernel.org [mailto:linux-rdma-ow...@vger.kernel.org] On Behalf Of Nicholas A. Bellinger Sent: Thursday, March 06, 2014 12:34 AM To: Roland Dreier Cc: Or Gerlitz; Hefty Sean

  1   2   3   4   5   6   7   8   9   10   >