From: Doug Ledford on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1611#note_838938467
Works now. Thanks.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le
From: Doug Ledford on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1611#note_838786682
@prarit Gitlab won't let me do a review/approval because I don't have the
right permissions, but I've reviewed it and it l
eed it
back to azure runners on local machines in order to get the bare metal
testing you want, yes? Something like that could be done at the FSDP
too, but we haven't prioritized that.
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274
From: Doug Ledford on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/429#note_392002967
Even if Fedora doesn't build these items, I would have the ARK config
build them both as modules. Even though we aren't shipping these, we
can still have them handy to write
t; drivers/scsi/aic7xxx/aic7xxx_osm.c:567:30: warning: variable ‘tinfo’
> set but not used [-Wunused-but-set-variable]
> 567 | struct ahc_initiator_tinfo *tinfo;
> | ^
>
> Cc: Hannes Reinecke
> Cc: "Daniel M. Eischen"
> Cc: Doug Ledford
FWIW, I can't see
On Tue, 2020-05-19 at 15:58 -0700, Adam Williamson wrote:
> On Tue, 2020-05-19 at 18:55 -0400, Doug Ledford wrote:
> > > I guess we get to poke through everything built around the 17th
> > > and
> > > try
> > > to find a relevant change? :)
> >
>
On Tue, 2020-05-19 at 15:45 -0700, Adam Williamson wrote:
> On Tue, 2020-05-19 at 18:16 -0400, Doug Ledford wrote:
> > But this is different, and it's the cause of your problem (well,
> > it's
> > the immediate cause anyway). The kernel-install script is failin
udev rpm packages should have an
explicit requires on libibverbs I think.
Anyway, at this point, I don't know if the rdma-core-owner people can
help. I think this is first in the hands of the systemd folks.
> DEBUG util.py:602: /var/tmp/rpm-tmp.6RiAo6: line 34: 2006782
> Segmentation fault
The arm32 platform literally does not support the memory primitives needed to
safely to RDMA. If we enable the support, and someone uses it, there is
nothing we can do to prevent them running the risk of memory corruption. So we
probably need to exclude arm32 from all these packages, or condit
On Mon, 2019-10-21 at 23:51 +0200, Arnd Bergmann wrote:
> On Mon, Oct 21, 2019 at 11:09 PM Doug Ledford
> wrote:
> > This fix looks reasonable, but since I can't test this at all, and
> > I'm
> > personally tired of trying and failing to fix this issue, I need
2d ("RDMA/hns: Split hw v1 driver from hns roce
> driver")
> Signed-off-by: Arnd Bergmann
This fix looks reasonable, but since I can't test this at all, and I'm
personally tired of trying and failing to fix this issue, I need to ask
if you've tried all the permuta
tnuri to fix his stuff. As for the rdma tree, the 10
digit hash is still unique as of today, so I won't rebase the official
branch to fix this. However, I'll see about adding a check for this in
my workflow. Thanks.
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Fingerp
ew cycles
> > before removing it.
> >
> > If you completely replace it with something that works the same, why
> > keep the old
> > one around at all?
>
> Agree. Thanks!
>
>
> > Unless you don't trust your new code? :)
> >
> We do :)
I don't
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
signature.asc
Description: This is a digitally signed message part
> Unless you don't trust your new code? :)
I have yet to see, in over 20 years of kernel experience, a new driver
replace an old driver and not initially be more buggy and troublesome
than the old driver. It takes time and real world usage for the final
issues to get sorted out. During
On Fri, 2019-09-27 at 21:52 +0200, Richard Weinberger wrote:
> On Fri, Sep 27, 2019 at 9:30 PM Doug Ledford
> wrote:
> > Because there are literally thousands of developers working on
> > kernel
> > bits here and there, and you're swatting this particular fly one
&g
On Fri, 2019-09-27 at 12:41 -0700, Linus Torvalds wrote:
> On Fri, Sep 27, 2019 at 12:29 PM Doug Ledford
> wrote:
> > Because there are literally thousands of developers working on
> > kernel
> > bits here and there, and you're swatting this particular fly one
>
ite this email for the
> millionth time, and that takes longer and is more aggravating than the
> conflict would have taken to just sort out.
>
>Linus
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
signature.asc
Description: This is a digitally signed message part
es up to 531a64e4c35bb9844b0cf813a6c9a87e00be05ff:
RDMA/siw: Fix IPv6 addr_list locking (2019-08-28 10:29:19 -0400)
Pull request for 5.3-rc6
- Fix locking on list traversal (siw)
Signed-off-by: Doug Le
Hi Linus,
I didn't notice I was on my personal email identity when I sent the pull
request. Sorry about that. It's really me ;-)
On Fri, 2019-08-23 at 14:48 -0400, Doug Ledford wrote:
> Hi Linus,
>
> No beating around the bush: this is a monster pull request for an -rc5
&
On Wed, 2019-08-21 at 17:02 +0300, Leon Romanovsky wrote:
> On Tue, Aug 20, 2019 at 01:54:59PM -0400, Doug Ledford wrote:
> > On Mon, 2019-08-19 at 14:36 +0300, Leon Romanovsky wrote:
> > > From: Leon Romanovsky
> > >
> > > Hi,
> > >
> > >
space flow table default miss action support
> net/mlx5: Create bypass and loopback flow steering namespaces for
> RDMA
> RX
> RDMA/mlx5: RDMA_RX flow type support for user applications
I have no objection to this series.
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
F
ta'
> label
> to free 'data' before returning the error.
>
> Signed-off-by: Wenwen Wang
Applied to for-rc, thanks.
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
signature.asc
Description: This is a digitally signed message part
ng the error.
>
> Signed-off-by: Wenwen Wang
Applied to for-rc, thanks.
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
signature.asc
Description: This is a digitally signed message part
, free
> 'tun_qp->tx_ring' whenever an error occurs.
>
> Signed-off-by: Wenwen Wang
> ---
Thanks, applied to for-rc.
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
signature.asc
Description: This is a digitally signed message part
On Fri, 2019-08-16 at 14:39 +0300, Dan Carpenter wrote:
> This line was indented a bit too far.
>
> Signed-off-by: Dan Carpenter
Thanks, applied to for-next.
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
sign
.
>
> Thanks,
> Saeed.
Series looks fine to me.
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
signature.asc
Description: This is a digitally signed message part
o match up with. Are there any versions of rds-tools that
actually use the kernel provided headers? Are there any other users of
uapi/linux/rds.h besides rds-tools?
Once the kernel and rds-tools package are in sync, rds-tools needs to be
modified to use the kernel header and proper ABI mainten
rtions(+), 3 deletions(-)
>
That first patch looks like a total bogon to me, but the remaining four
look fine.
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
signature.asc
Description: This is a digitally signed message part
ted by
IANA on Feb 27 and May 20, 2009. And you *still* have software that
needs this? The only software that has ever used RDS was Oracle
software. I would have expected you guys to update your source code to
do the right thing long before now. In fact, I would expect you were
ready to retir
)
- Actually return an error code on error (core)
- Allow siw to be built on 32bit arches (siw, ABI change, but OK since
siw was just merged this merge window and there is no prior released
kernel to maintain compatibility with and we also updated the
rdma-core user space package to match)
On Tue, 2019-08-13 at 10:06 +, Leon Romanovsky wrote:
> On Mon, Aug 12, 2019 at 11:43:58AM -0400, Doug Ledford wrote:
> > On Thu, 2019-08-08 at 10:11 +, Leon Romanovsky wrote:
> > > On Thu, Aug 08, 2019 at 11:43:54AM +0300, Leon Romanovsky wrote:
> > &
> Sorry for typo in cover letter, there is no SRQ here.
Series looks fine to me. Are you planning on the first two via mlx5-
next and the remainder via RDMA tree?
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
signatur
On Wed, 2019-08-07 at 11:22 +0800, YueHaibing wrote:
> Since commit a07fc0bb483e ("RDMA/hns: Fix build error")
> these kconfig comment is obsolete, so just remove it.
>
> Signed-off-by: YueHaibing
Thanks, applied to for-next.
--
Doug Ledford
GPG KeyID: B826A3330E
On Fri, 2019-08-02 at 18:32 +, Saeed Mahameed wrote:
> On Fri, 2019-08-02 at 11:09 -0700, Joe Perches wrote:
> > On Tue, 2018-11-06 at 16:34 -0500, Doug Ledford wrote:
> > > On Thu, 2018-11-01 at 09:34 +0200, Leon Romanovsky wrote:
> > > > On Thu, Nov 01, 2018 at
ain.c | 7 +-
drivers/infiniband/hw/mlx5/mr.c| 27 +++-
drivers/infiniband/hw/qedr/main.c | 10 ++-
drivers/infiniband/sw/siw/siw_qp.c | 6 +-
include/rdma/ib_verbs.h| 4 +-
13 files changed, 124 insertions(+), 83 deletions(-)
--
Doug Le
l.org
> Signed-off-by: Gustavo A. R. Silva
> ---
Thanks, applied to for-rc.
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
signature.asc
Description: This is a digitally signed message part
t; >
> > Reported-by: Hulk Robot
> > Signed-off-by: YueHaibing
> > ---
> > drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 2 --
> > 1 file changed, 2 deletions(-)
> >
>
> I'm hitting this error too.
>
> Thanks,
> Reviewed-by: Leon Romanovsky
On Wed, 2019-07-31 at 14:52 -0400, Doug Ledford wrote:
> On Wed, 2019-07-31 at 12:52 -0500, Gustavo A. R. Silva wrote:
> > This is insufficient. The speculation windows are large:
> >
> > "Speculative execution on modern CPUs can run several
> > h
df
Thanks, I'll take a look at that. That issue aside, returning without
wasting time on two mutexes is still better IMO, so I like my patch more
than the proposed one. Tony, would you like to resubmit?
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Fingerprint = AE6B 1BDA 122B 23
; > ---
> > drivers/infiniband/core/netlink.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
>
> Thanks,
> Reviewed-by: Leon Romanovsky
Thanks, applied to for-next.
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Fingerprint = AE6B 1BDA 122B 23B4 265
.);
> -... }
> ...
> -dev_err(...);
> )
> ...
> }
> //
>
> While we're here, remove braces on if statements that only have one
> statement (manually).
>
> Cc: Doug Ledford
> Cc: Jason Gunthorpe
> Cc: linux-r...@vger.kernel.org
> Cc: Greg Kroah
* speculative prefetch?
+*/
+ id = array_index_nospec(id, IB_UMAD_MAX_AGENTS);
+ if (!__get_agent(file, id)) {
ret = -EINVAL;
goto out;
}
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
signature.asc
Description: This is a digitally signed message part
On Mon, 2019-07-29 at 16:03 -0300, Jason Gunthorpe wrote:
> On Mon, Jul 29, 2019 at 02:19:35PM -0400, Doug Ledford wrote:
> > On Fri, 2019-07-26 at 11:25 +0200, Anders Roxell wrote:
> > > The variable 'p' si no longer used and the compiler rightly
> > > comp
d the commit subject does not exist in Linus' tree as
of today. What tree is this being merged through, and is it slated to
merge soon or is this a for-next item?
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
signature.asc
Description: This is a digitally signed message part
< 0) {
> - ep->com.cm_id->rem_ref(ep->com.cm_id);
> + if (ep->com.cm_id)
> + ep->com.cm_id->rem_ref(ep->com.cm_id);
> ep->com.cm_id = NULL;
> ep->com.qp = NULL;
> }
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
signature.asc
Description: This is a digitally signed message part
d74282df573 ("RDMA/hns: Initialize the PCI device for hip08
> > RoCE")
> > Fixes: 08805fdbeb2d ("RDMA/hns: Split hw v1 driver from hns roce
> > driver")
> > Signed-off-by: YueHaibing
> > drivers/infiniband/hw/hns/Kconfig | 6 +++---
> > drivers/in
and/hw/hfi1/verbs.c | 14 +
drivers/infiniband/hw/hfi1/verbs.h | 1 +
drivers/infiniband/hw/hfi1/verbs_txreq.c | 2 +-
drivers/infiniband/hw/hfi1/verbs_txreq.h | 3 +-
17 files changed, 174 insertions(+), 62 deletions(-)
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Fingerpr
)
>
Hi Michal,
In patch 2 and 3 both, you still have quite a few casts to (u8 __iomem
*). Why not just define the struct elements as u8 __iomem * instead of
void __iomem * and avoid all the casts?
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
signature.asc
Description: This is a digitally signed message part
On Thu, 2019-06-20 at 12:10 +1000, Stephen Rothwell wrote:
> 2d3c72ed5041 ("rdma: Remove nes")
Yeah, not much you can do about tree wide patchsets conflicting with a
removal ;-)
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B
is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your
> tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any
> pa
broadcast address in use
by each to make sure they are the same and not that they shouldn't be
able to see each other because they are on different P_Keys and
therefore different broadcast multicast groups.
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B
gt; 82b11f071936 net/mlx5: Expose eswitch encap mode
> 98fdbea55037 net/mlx5: Declare more strictly devlink encap mode
>
> > RDMA/mlx5: Consider eswitch encap mode
> > RDMA/mlx5: Enable decap and packet reformat on FDB
>
> Doug, Jason
>
> Can you please take t
PACE bit is set in qp->s_flags.
Thanks, applied to for-next.
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57
2FDD
signature.asc
Description: This is a digitally signed message part
st copy an address without modifing ifla_vf_mac
> v2->v3: update the changelog
> v3->v4: update the changelog: add a link to the patch for iproute2
>
> Signed-off-by: Denis Kirjanov
I assume you want this to go as a series through netdev, so you can add
my:
Acked-by: Doug Ledford
On Sat, 2019-06-15 at 11:49 +0300, Denis Kirjanov wrote:
> On 6/14/19, Doug Ledford wrote:
> > On Fri, 2019-06-14 at 15:32 +0200, Denis Kirjanov wrote:
> > > in IPoIB case we can't see a VF broadcast address for but
> > > can see for PF
> > >
>
Passing null pointer cq->umem to ib_umem_release,
> which dereferences it"
>
> Is the logic inverted on that null check?
>
> Colin
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57
2FDD
signature.asc
Description: This is a digitally signed message part
f_rate) ||
> @@ -1753,6 +1757,7 @@ static const struct nla_policy
> ifla_info_policy[IFLA_INFO_MAX+1] = {
>
> static const struct nla_policy ifla_vf_policy[IFLA_VF_MAX+1] = {
> [IFLA_VF_MAC] = { .len = sizeof(struct ifla_vf_mac)
> },
> + [IFLA_VF_BRO
g tree to minimise any
> particularly
> complex conflicts.
>
Thanks Stephen. There will be at least one more coming too. We've had
a number of -rc patches and -next patches that touch the same area of
code this cycle.
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Key fing
On Thu, 2019-06-13 at 18:58 +0200, Håkon Bugge wrote:
> > On 13 Jun 2019, at 16:25, Doug Ledford wrote:
> >
> > On Tue, 2019-02-26 at 08:57 +0100, Håkon Bugge wrote:
> > > During certain workloads, the default CM response timeout is too
> > > short, leading
On Thu, 2019-06-13 at 08:28 -0700, Bart Van Assche wrote:
> On 6/13/19 7:25 AM, Doug Ledford wrote:
> > So, to revive this patch, what I'd like to see is some attempt to
> > actually quantify a reasonable timeout for the default backlog
> > depth,
> > then the
r_len);
>
> return 0;
> }
I'm ok with the patch, but your commit message does not match what the
patch does at all. You need to correct the commit message.
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57
2FDD
signature.asc
Description: This is a digitally signed message part
the default to that reasonable
timeout, and then put in the ability to adjust the timeout with some
sort of doc guidance on how to calculate a reasonable timeout based on
configured backlog depth.
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 12
er of the conflicting tree to
> minimise any particularly complex conflicts.
>
Sorry, I forgot to back that head commit out. Once Linus committed his
fix the one in the rdma tree was superfluous (and wrong anyway).
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B
On Mon, 2019-04-29 at 21:00 +0300, Leon Romanovsky wrote:
> On Mon, Apr 29, 2019 at 01:13:01PM -0400, Doug Ledford wrote:
> > On Mon, 2019-04-29 at 09:48 -0700, Linus Torvalds wrote:
> > > On Mon, Apr 29, 2019 at 9:29 AM Doug Ledford wrote:
> > > > drivers/inf
On Mon, 2019-04-29 at 09:48 -0700, Linus Torvalds wrote:
> On Mon, Apr 29, 2019 at 9:29 AM Doug Ledford wrote:
> >
> > drivers/infiniband/core/uverbs_main.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> This trivial one-liner is actually incorre
On Mon, 2019-04-29 at 11:42 -0400, Doug Ledford wrote:
> On Mon, 2019-04-29 at 08:40 +, Jason Gunthorpe wrote:
> > On Mon, Apr 29, 2019 at 08:09:47AM +0200, Heiko Carstens wrote:
> > > On Sun, Apr 28, 2019 at 11:52:12AM +, Jason Gunthorpe wrote:
> > > > Hi Li
insertion(+), 1 deletion(-)
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
signature.asc
Description: This is a digitally signed message part
ma->vm_start);
> > get_page(vmf->page);
> > return 0;
> > }
> >
>
> Thanks Heiko, this looks right to me.
>
> I'm surprised to be seeing this at this point, these patches should
> have been seen by 0 day for several days now, and they were in
> linux-next already too..
>
> Doug, can you send this to Linus today?
Yep.
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
signature.asc
Description: This is a digitally signed message part
or [ ... ] The value of a pointer that refers to space
> > deallocated by a call to the free or realloc function is used (7.22.3).
> >
> > Since the C standard explicitly refers to free() and realloc(), does that
> > mean that that statement about undefined behavior does not apply to munmap()
> > (for user space code) nor to kfree() (for kernel code)?
> >
> > Bart.
> >
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
signature.asc
Description: This is a digitally signed message part
ex conflicts.
>
Thanks Stephen, we'll add it to the (largish this release) list of
conflicts to bring to Linus' attention.
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
signature.asc
Description: This is a digitally signed message part
ex conflicts.
>
Thanks Stephen, we'll add it to the (largish this release) list of
conflicts to bring to Linus' attention.
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
signature.asc
Description: This is a digitally signed message part
re other rdma sysctls currently: net.rdma_ucm.max_backlog and
> net.iw_cm.default_backlog. The core network stack seems to use sysctl
> and not ip tool to set basically globals.
>
> To use rdma tool, we'd have to have some concept of a "module" object, I
> guess. IE there's dev, link, and resource rdma tool objects currently.
> But these cma timeout settings are really not per dev, link, nor a
> resource. Maybe we have just a "core" object: rdma core set
> cma_max_cm_retries min 8 max 30.
I don’t know, I think you make a fairly good argument for leaving it as a
sysctl. We have infrastructure in place for admins to set persistent sysctl
settings. The per device/link settings need something different because link
names and such can change. Since these are globals, I’d leave them where they
are.
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
signature.asc
Description: Message signed with OpenPGP
t the fall through
> happens (assuming that the fall through is intentional).
>
Thanks Stephen, we'll sort it and make an appropriate fixup patch.
Kaike?
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
signature.asc
Description: This is a digitally signed message part
liams wrote:
> On Wed, Feb 6, 2019 at 2:25 PM Doug Ledford wrote:
> > On Wed, 2019-02-06 at 15:08 -0700, Jason Gunthorpe wrote:
> > > On Thu, Feb 07, 2019 at 08:03:56AM +1100, Dave Chinner wrote:
> > > > On Wed, Feb 06, 2019 at 07:16:21PM +, Christopher Lameter wrote:
&g
On Thu, 2019-02-07 at 10:41 -0500, Tom Talpey wrote:
> On 2/7/2019 10:37 AM, Doug Ledford wrote:
> > On Thu, 2019-02-07 at 10:28 -0500, Tom Talpey wrote:
> > > On 2/7/2019 10:04 AM, Chuck Lever wrote:
> > > > > On Feb 7, 2019, at 12:23 AM, Jason Gunthorpe wrote:
gent doesn't tell the
communication agent about a broken lease, it want's to be able to do
things 100% transparently without any work on the communication agent's
part. That works for ODP, but not for anything else. If the filesystem
notified the communication agent of the need to d
On Wed, 2019-02-06 at 14:44 -0800, Dan Williams wrote:
> On Wed, Feb 6, 2019 at 2:25 PM Doug Ledford wrote:
> > Can someone give me a real world scenario that someone is *actually*
> > asking for with this?
>
> I'll point to this example. At the 6:35 mark Kodi talks a
On Wed, 2019-02-06 at 14:44 -0800, Dan Williams wrote:
> On Wed, Feb 6, 2019 at 2:25 PM Doug Ledford wrote:
> > On Wed, 2019-02-06 at 15:08 -0700, Jason Gunthorpe wrote:
> > > On Thu, Feb 07, 2019 at 08:03:56AM +1100, Dave Chinner wrote:
> > > > On Wed, Fe
On Wed, 2019-02-06 at 15:08 -0700, Jason Gunthorpe wrote:
> On Thu, Feb 07, 2019 at 08:03:56AM +1100, Dave Chinner wrote:
> > On Wed, Feb 06, 2019 at 07:16:21PM +, Christopher Lameter wrote:
> > > On Wed, 6 Feb 2019, Doug Ledford wrote:
> > >
> > > > >
On Wed, 2019-02-06 at 13:04 -0800, Dan Williams wrote:
> On Wed, Feb 6, 2019 at 12:14 PM Doug Ledford wrote:
> > On Wed, 2019-02-06 at 11:45 -0800, Dan Williams wrote:
> > > On Wed, Feb 6, 2019 at 10:52 AM Jason Gunthorpe wrote:
> > > > On Wed, Feb 06, 2019 at 10
On Wed, 2019-02-06 at 12:20 -0800, Matthew Wilcox wrote:
> On Wed, Feb 06, 2019 at 03:16:02PM -0500, Doug Ledford wrote:
> > On Wed, 2019-02-06 at 11:40 -0800, Matthew Wilcox wrote:
> > > On Wed, Feb 06, 2019 at 07:16:21PM +, Christopher Lameter wrote:
> > > > tho
On Wed, 2019-02-06 at 12:49 -0800, Matthew Wilcox wrote:
> On Wed, Feb 06, 2019 at 03:47:53PM -0500, Doug Ledford wrote:
> > On Wed, 2019-02-06 at 12:41 -0800, Matthew Wilcox wrote:
> > > On Wed, Feb 06, 2019 at 03:28:35PM -0500, Doug Ledford wrote:
> > > > On
On Wed, 2019-02-06 at 12:41 -0800, Matthew Wilcox wrote:
> On Wed, Feb 06, 2019 at 03:28:35PM -0500, Doug Ledford wrote:
> > On Wed, 2019-02-06 at 12:20 -0800, Matthew Wilcox wrote:
> > > On Wed, Feb 06, 2019 at 03:16:02PM -0500, Doug Ledford wrote:
> > > > On
On Wed, 2019-02-06 at 12:20 -0800, Matthew Wilcox wrote:
> On Wed, Feb 06, 2019 at 03:16:02PM -0500, Doug Ledford wrote:
> > On Wed, 2019-02-06 at 11:40 -0800, Matthew Wilcox wrote:
> > > On Wed, Feb 06, 2019 at 07:16:21PM +, Christopher Lameter wrote:
> > > > tho
he device (something
that would have returned ETXTBSY)?
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
signature.asc
Description: This is a digitally signed message part
he
kernel, then truncate blocks.
There is a major case of dissonant cognitive behavior here if the
syscall supports ETXTBSY, even though the ability to kill apps using the
text pages is trivial, but thinks supporting EBUSY is out of the
question.
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
signature.asc
Description: This is a digitally signed message part
On Wed, 2019-02-06 at 10:35 -0800, Matthew Wilcox wrote:
> On Wed, Feb 06, 2019 at 01:32:04PM -0500, Doug Ledford wrote:
> > On Wed, 2019-02-06 at 09:52 -0800, Matthew Wilcox wrote:
> > > On Wed, Feb 06, 2019 at 10:31:14AM -0700, Jason Gunthorpe wrote:
> > > > On W
he API to include
EBUSY to mean "this file has pinned pages that can not be freed" is not
(or should not be) totally out of the question.
Admittedly, I'm coming in late to this conversation, but did I miss the
portion where that alternative was ruled out?
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
signature.asc
Description: This is a digitally signed message part
+-
7 files changed, 22 insertions(+), 8 deletions(-)
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
signature.asc
Description: This is a digitally signed message part
er when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
--
Doug Ledford
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
signature.asc
Description: This is a digitally signed message part
On Tue, 2018-12-04 at 12:15 -0700, Jason Gunthorpe wrote:
> On Tue, Dec 4, 2018 at 12:02 PM Doug Ledford wrote:
> > On Mon, 2018-11-26 at 08:28 +0200, Leon Romanovsky wrote:
> > > From: Leon Romanovsky
> > >
> > > From Yishai,
> > > -
/dl-for-next branch. Because it pulled in the
mlx5-next tree (which was significant because the patch we wanted was at
the tip and a whole slew of other patches were before it), the changeset
for this patch looks much bigger. And it had the merge conflict you
mentioned. You might want to double che
will appreciate suggestions, inputs and review.
>
> 1. git grep "nid == -1"
> 2. git grep "node == -1"
> 3. git grep "nid = -1"
> 4. git grep "node = -1"
>
> drivers/infiniband/hw/hfi1/affinity.c | 3 ++-
> drivers/infiniband
will appreciate suggestions, inputs and review.
>
> 1. git grep "nid == -1"
> 2. git grep "node == -1"
> 3. git grep "nid = -1"
> 4. git grep "node = -1"
>
> drivers/infiniband/hw/hfi1/affinity.c | 3 ++-
> drivers/infiniband
will appreciate suggestions, inputs and review.
>
> 1. git grep "nid == -1"
> 2. git grep "node == -1"
> 3. git grep "nid = -1"
> 4. git grep "node = -1"
>
> drivers/infiniband/hw/hfi1/affinity.c | 3 ++-
> drivers/infiniband
will appreciate suggestions, inputs and review.
>
> 1. git grep "nid == -1"
> 2. git grep "node == -1"
> 3. git grep "nid = -1"
> 4. git grep "node = -1"
>
> drivers/infiniband/hw/hfi1/affinity.c | 3 ++-
> drivers/infiniband
will appreciate suggestions, inputs and review.
>
> 1. git grep "nid == -1"
> 2. git grep "node == -1"
> 3. git grep "nid = -1"
> 4. git grep "node = -1"
>
> drivers/infiniband/hw/hfi1/affinity.c | 3 ++-
> drivers/infiniband
will appreciate suggestions, inputs and review.
>
> 1. git grep "nid == -1"
> 2. git grep "node == -1"
> 3. git grep "nid = -1"
> 4. git grep "node = -1"
>
> drivers/infiniband/hw/hfi1/affinity.c | 3 ++-
> drivers/infiniband
will appreciate suggestions, inputs and review.
>
> 1. git grep "nid == -1"
> 2. git grep "node == -1"
> 3. git grep "nid = -1"
> 4. git grep "node = -1"
>
> drivers/infiniband/hw/hfi1/affinity.c | 3 ++-
> drivers/infiniband
gt; };
>
> enum mlx5_flow_destination_type {
> @@ -9276,7 +9286,9 @@ struct mlx5_ifc_umem_bits {
> struct mlx5_ifc_uctx_bits {
> u8 modify_field_select[0x40];
>
> - u8 reserved_at_40[0x1c0];
> + u8 cap[0x20];
> +
> + u8 re
1 - 100 of 2015 matches
Mail list logo
