On Tue, Mar 09, 2021 at 09:11:46PM -0800, Jesse Brandeburg wrote:
> Leon Romanovsky wrote:
>
> > > 3) Plan is to make the "new" iavf driver the default iavf once
> > >extensive regression testing can be completed.
> > > a. Current propos
ess of the common code module for multiple drivers. This
> > proposal aims to avoid disrupting current users.
> >
> > The steps we plan are something like:
> > 1) Continue upstreaming of the iecm module (common module) and
> >the initial feature set for the idpf driver[1
Leon Romanovsky wrote:
> > 3) Plan is to make the "new" iavf driver the default iavf once
> >extensive regression testing can be completed.
> > a. Current proposal is to make CONFIG_IAVF have a sub-option
> >CONFIG_IAVF_V2 that lets the user adop
On Mon, 8 Mar 2021 16:28:58 -0800 Jesse Brandeburg wrote:
> Hello,
>
> We plan to refactor the iavf module and would appreciate community and
> maintainer feedback on our plans. We want to do this to realize the
> usefulness of the common code module for multiple drivers. This
On Mon, Mar 08, 2021 at 04:28:58PM -0800, Jesse Brandeburg wrote:
> Hello,
>
> We plan to refactor the iavf module and would appreciate community and
> maintainer feedback on our plans. We want to do this to realize the
> usefulness of the common code module for multiple drivers.
Hello,
We plan to refactor the iavf module and would appreciate community and
maintainer feedback on our plans. We want to do this to realize the
usefulness of the common code module for multiple drivers. This
proposal aims to avoid disrupting current users.
The steps we plan are something
Hi all,
I'm currently working on implementing support for the Management
Controller Transport Protocol (MCTP). Briefly, MCTP is a protocol for
intra-system communication between a management controller (typically a
BMC), and the devices it manages. If you're after the full details, the
DMTF have a
On Sat, 03 Oct 2020 17:05:38 -0700 (PDT)
David Miller wrote:
> Series applied, but could you send a proper patch series in the future
> with a "[PATCH 0/N] ..." header posting? It must explain what the
> patch series does at a high level, how it is doing it, and why it is
> doing it that way.
>
From: Karsten Graul
Date: Fri, 2 Oct 2020 17:09:26 +0200
> When building a CLC proposal message then the list of ISM devices does
> not need to contain multiple devices that have the same chid value,
> all these devices use the same function at the end.
> Improve smc_find_ism_v2
When building a CLC proposal message then the list of ISM devices does
not need to contain multiple devices that have the same chid value,
all these devices use the same function at the end.
Improve smc_find_ism_v2_device_clnt() to collect only ISM devices that
have unique chid values.
Signed-off
From: Ursula Braun
The new format of an SMCD V2 CLC proposal is introduced, and
building and checking of SMCD V2 CLC proposals is adapted
accordingly.
Signed-off-by: Ursula Braun
Signed-off-by: Karsten Graul
---
net/smc/af_smc.c | 2 +-
net/smc/smc.h | 6 ++
net/smc/smc_clc.c | 171
Hi!
> I have been thinking about another way to implement ABI for HW control
> of ethernet PHY connected LEDs.
>
> This proposal is inspired by the fact that for some time there is a
> movement in the kernel to do transparent HW offloading of things (DSA
> is an example of that
Hello,
I have been thinking about another way to implement ABI for HW control
of ethernet PHY connected LEDs.
This proposal is inspired by the fact that for some time there is a
movement in the kernel to do transparent HW offloading of things (DSA
is an example of that).
So currently we have
exchange -
* wait for and receive SMC Proposal CLC message
*/
- pclc = (struct smc_clc_msg_proposal *)&buf;
- rc = smc_clc_wait_msg(new_smc, pclc, SMC_CLC_MAX_LEN,
+ buf = kzalloc(sizeof(*buf), GFP_KERNEL);
+ if (!buf) {
+ rc = SMC_CLC_DECL_MEM;
+
On Thu, Jul 16, 2020 at 1:43 AM Jarod Wilson wrote:
>
> On Wed, Jul 15, 2020 at 11:18 PM Andrew Lunn wrote:
...
> > I really think that before we consider changes like this, somebody
> > needs to work on git tooling, so that it knows when mass renames have
> > happened, and can do the same sort o
On Thu, 16 Jul 2020 11:59:47 -0700 (PDT)
David Miller wrote:
> From: Jarod Wilson
> Date: Wed, 15 Jul 2020 23:06:55 -0400
>
> > On Mon, Jul 13, 2020 at 9:00 PM David Miller wrote:
> >>
> >> From: Michal Kubecek
> >> Date: Tue, 14 Jul 2020 00:00:16 +0200
> >>
> >> > Could we, please, avoid
From: Jarod Wilson
Date: Wed, 15 Jul 2020 23:06:55 -0400
> On Mon, Jul 13, 2020 at 9:00 PM David Miller wrote:
>>
>> From: Michal Kubecek
>> Date: Tue, 14 Jul 2020 00:00:16 +0200
>>
>> > Could we, please, avoid breaking existing userspace tools and scripts?
>>
>> I will not let UAPI breakage, d
On Wed, Jul 15, 2020 at 11:18 PM Andrew Lunn wrote:
>
> On Wed, Jul 15, 2020 at 11:04:16PM -0400, Jarod Wilson wrote:
> > On Mon, Jul 13, 2020 at 8:26 PM Andrew Lunn wrote:
> > >
> > > Hi Jarod
> > >
> > > Do you have this change scripted? Could you apply the script to v5.4
> > > and then cherry-
On Wed, Jul 15, 2020 at 11:04:16PM -0400, Jarod Wilson wrote:
> On Mon, Jul 13, 2020 at 8:26 PM Andrew Lunn wrote:
> >
> > Hi Jarod
> >
> > Do you have this change scripted? Could you apply the script to v5.4
> > and then cherry-pick the 8 bonding fixes that exist in v5.4.51. How
> > many result i
On Mon, Jul 13, 2020 at 9:00 PM David Miller wrote:
>
> From: Michal Kubecek
> Date: Tue, 14 Jul 2020 00:00:16 +0200
>
> > Could we, please, avoid breaking existing userspace tools and scripts?
>
> I will not let UAPI breakage, don't worry.
Seeking some clarification here. Does the output of
/pr
On Mon, Jul 13, 2020 at 8:26 PM Andrew Lunn wrote:
>
> Hi Jarod
>
> Do you have this change scripted? Could you apply the script to v5.4
> and then cherry-pick the 8 bonding fixes that exist in v5.4.51. How
> many result in conflicts?
>
> Could you do the same with v4.19...v4.19.132, which has 20
On Wed, Jul 15, 2020 at 8:57 AM Edward Cree wrote:
>
> Once again, the opinions below are my own and definitely do not
> represent anything my employer would be seen dead in the same
> room as.
>
> On 13/07/2020 23:41, Stephen Hemminger wrote:
> > As far as userspace, maybe keep the old API's bu
Once again, the opinions below are my own and definitely do not
represent anything my employer would be seen dead in the same
room as.
On 13/07/2020 23:41, Stephen Hemminger wrote:
> As far as userspace, maybe keep the old API's but provide deprecation nags.
Why would you need to deprecate the o
On Tue, Jul 14, 2020 at 4:39 PM Marcelo Ricardo Leitner
wrote:
>
> On Tue, Jul 14, 2020 at 09:17:48PM +0200, Toke Høiland-Jørgensen wrote:
> > Jarod Wilson writes:
> >
> > > As part of an effort to help enact social change, Red Hat is
> > > committing to efforts to eliminate any problematic ter
On Tue, Jul 14, 2020 at 09:17:48PM +0200, Toke Høiland-Jørgensen wrote:
> Jarod Wilson writes:
>
> > As part of an effort to help enact social change, Red Hat is
> > committing to efforts to eliminate any problematic terminology from
> > any of the software that it ships and supports. Front and c
Jarod Wilson writes:
> As part of an effort to help enact social change, Red Hat is
> committing to efforts to eliminate any problematic terminology from
> any of the software that it ships and supports. Front and center for
> me personally in that effort is the bonding driver's use of the terms
would include "ip link" command line arguments, sysfs and procsfs
> interfaces, as well as netlink attribute names. There are also exported
> kernel APIs that bonding utilizes, netdev_master_upper_dev_link, et al.
To some people, this could be a case that warranted breaking UAPIs.
On Mon, Jul 13, 2020 at 6:00 PM Michal Kubecek wrote:
>
> On Mon, Jul 13, 2020 at 02:51:39PM -0400, Jarod Wilson wrote:
> > To start out with, I'd like to attempt to eliminate as much of the use
> > of master and slave in the bonding driver as possible. For the most
> > part, I think this can be d
On Mon, Jul 13, 2020 at 5:36 PM Eric Dumazet wrote:
>
> On 7/13/20 11:51 AM, Jarod Wilson wrote:
> > As part of an effort to help enact social change, Red Hat is
> > committing to efforts to eliminate any problematic terminology from
> > any of the software that it ships and supports. Front and ce
From: Michal Kubecek
Date: Tue, 14 Jul 2020 00:00:16 +0200
> Could we, please, avoid breaking existing userspace tools and scripts?
I will not let UAPI breakage, don't worry.
n't document the old API values.
Unless the community stance on not breaking user space has
changed, the extant APIs must be maintained. In the context of bonding,
this would include "ip link" command line arguments, sysfs and procsfs
interfaces, as well as netlink attri
From: Jarod Wilson
Date: Mon, 13 Jul 2020 14:51:39 -0400
> To start out with, I'd like to attempt to eliminate as much of the use
> of master and slave in the bonding driver as possible. For the most
> part, I think this can be done without breaking UAPI, but may require
> changes to anything acc
Hi Jarod
Do you have this change scripted? Could you apply the script to v5.4
and then cherry-pick the 8 bonding fixes that exist in v5.4.51. How
many result in conflicts?
Could you do the same with v4.19...v4.19.132, which has 20 fixes.
This will give us an idea of the maintenance overhead such
On Mon, Jul 13, 2020 at 03:41:18PM -0700, Stephen Hemminger wrote:
> On Tue, 14 Jul 2020 00:00:16 +0200
> Michal Kubecek wrote:
>
> > On Mon, Jul 13, 2020 at 02:51:39PM -0400, Jarod Wilson wrote:
> > > To start out with, I'd like to attempt to eliminate as much of the use
> > > of master and slav
On Tue, 14 Jul 2020 00:00:16 +0200
Michal Kubecek wrote:
> On Mon, Jul 13, 2020 at 02:51:39PM -0400, Jarod Wilson wrote:
> > To start out with, I'd like to attempt to eliminate as much of the use
> > of master and slave in the bonding driver as possible. For the most
> > part, I think this can be
On Mon, Jul 13, 2020 at 02:51:39PM -0400, Jarod Wilson wrote:
> To start out with, I'd like to attempt to eliminate as much of the use
> of master and slave in the bonding driver as possible. For the most
> part, I think this can be done without breaking UAPI, but may require
> changes to anything
On 7/13/20 11:51 AM, Jarod Wilson wrote:
> As part of an effort to help enact social change, Red Hat is
> committing to efforts to eliminate any problematic terminology from
> any of the software that it ships and supports. Front and center for
> me personally in that effort is the bonding drive
As part of an effort to help enact social change, Red Hat is
committing to efforts to eliminate any problematic terminology from
any of the software that it ships and supports. Front and center for
me personally in that effort is the bonding driver's use of the terms
master and slave, and to a less
Hello
My name is Yuval Rose. I have an urgent lucrative business
opportunity for you worth over 15 Milli0n US D0llars. I got your
details on the internet when I was searching for a reliable
person that can handle this deal and I believe you can handle it.
Waiting for your speedy reply for furt
It’s my pleasure to contact you through this media because I need an
investment assistance in your country. However I have a profitable
investment proposal with good interest to share with you, amounted
the sum of (Twenty Eight Million Four Hundred Thousand United State
Dollar ($28.400.000.00
(Narrowing the recipient list for now)
On Tue, Sep 3, 2019 at 3:50 PM David Miller wrote:
>
> From: Prashant Malani
> Date: Tue, 3 Sep 2019 14:32:01 -0700
>
> > I've moved David to the TO list to hopefully get his suggestions and
> > guidance about how to design this in a upstream-compatible way
From: Prashant Malani
Date: Tue, 3 Sep 2019 14:32:01 -0700
> I've moved David to the TO list to hopefully get his suggestions and
> guidance about how to design this in a upstream-compatible way.
I am not an expert in this area so please do not solicit my opinion.
Thank you.
iginal Message-
> From: Hayes Wang
> Sent: Monday, September 2, 2019 2:31 PM
> To: Amber Chen ; Prashant Malani
>
> Cc: David Miller ; netdev@vger.kernel.org; Bambi Yeh
> ; Ryankao ; Jackc
> ; Albertk ; marcoc...@google.com;
> nic_swsd ; Grant Grundler
> Su
Wang
Sent: Monday, September 2, 2019 2:31 PM
To: Amber Chen ; Prashant Malani
Cc: David Miller ; netdev@vger.kernel.org; Bambi Yeh
; Ryankao ; Jackc
; Albertk ; marcoc...@google.com;
nic_swsd ; Grant Grundler
Subject: RE: Proposal: r8152 firmware patching framework
Prashant Malani
Prashant Malani
> >
> > (Adding a few more Realtek folks)
> >
> > Friendly ping. Any thoughts / feedback, Realtek folks (and others) ?
> >
> >> On Thu, Aug 29, 2019 at 11:40 AM Prashant Malani
> wrote:
> >>
> >> Hi,
> >>
> >> The r8152 driver source code distributed by Realtek (on
> >> www.realt
+ acct mgr, Stephen
> Prashant Malani 於 2019年8月31日 上午6:24 寫道：
>
> (Adding a few more Realtek folks)
>
> Friendly ping. Any thoughts / feedback, Realtek folks (and others) ?
>
>> On Thu, Aug 29, 2019 at 11:40 AM Prashant Malani
>> wrote:
>>
>> Hi,
>>
>> The r8152 driver source code distri
(Adding a few more Realtek folks)
Friendly ping. Any thoughts / feedback, Realtek folks (and others) ?
On Thu, Aug 29, 2019 at 11:40 AM Prashant Malani wrote:
>
> Hi,
>
> The r8152 driver source code distributed by Realtek (on
> www.realtek.com) contains firmware patches. This involves binary
>
Hi,
The r8152 driver source code distributed by Realtek (on
www.realtek.com) contains firmware patches. This involves binary
byte-arrays being written byte/word-wise to the hardware memory
Example: grund...@chromium.org (cc-ed) has an experimental patch which
includes the firmware patching code wh
confidentiality, believing that this email reaches you
in good faith. My contacting you is not a mistake or a coincidence
because God can use any person known or unknown to accomplish great
things.
I am a lawyer and I have an investment business proposal to offer you.
It is not official but should
On Mon, Aug 19, 2019 at 02:09:11PM +0100, Stefan Hajnoczi wrote:
> On Thu, Jun 06, 2019 at 12:09:12PM +0200, Stefano Garzarella wrote:
> >
> > Hi all,
> > this is a v2 of a proposal addressing the comments made by Dexuan, Stefan,
> > and Jorgen.
> >
> > v
On Thu, Jun 06, 2019 at 12:09:12PM +0200, Stefano Garzarella wrote:
>
> Hi all,
> this is a v2 of a proposal addressing the comments made by Dexuan, Stefan,
> and Jorgen.
>
> v1: https://www.spinics.net/lists/netdev/msg570274.html
>
>
>
> We can define two type
De: José Luiz Fabris
Enviado: terça-feira, 30 de julho de 2019 18:37
Para: José Luiz Fabris
Assunto: PROPOSAL.
Good Day,
I am Mrs.Margaret Ko May-Yee Leung Deputy Managing Director and Executive
Director of Chong Hing Bank Limited. I write briefly to
I got your contact while on a search for a reliable and trustworthy
partner who is to help me co-ordinate a business over there in your
country. I am interested in having an investment in your country based
on long-term business venture that has a good return on investment
[ROI] under your supervis
On Fri, Jun 28, 2019 at 03:55:53PM +0200, Jiri Pirko wrote:
> Fri, Jun 28, 2019 at 03:14:01PM CEST, and...@lunn.ch wrote:
> >
> >What is your user case for having multiple IFLA_ALT_NAME for the same
> >IFLA_NAME?
>
> I don't know about specific usecase for having more. Perhaps Michal
> does.
One
eed something and easy to use for all.
>> >>
>> >> Let's call it "altname". Get would return:
>> >>
>> >> IFLA_NAME eth0
>> >> IFLA_ALT_NAME_LIST
>> >>IFLA_ALT_NAME eth0
>> >>IFLA_ALT_NAME
re might be perhaps okay for iproute2,
> >> but I think that we need something and easy to use for all.
> >>
> >> Let's call it "altname". Get would return:
> >>
> >> IFLA_NAME eth0
> >> IFLA_ALT_NAME_LIST
> >> IFLA_AL
Fri, Jun 28, 2019 at 03:14:01PM CEST, and...@lunn.ch wrote:
>On Fri, Jun 28, 2019 at 01:12:16PM +0200, Jiri Pirko wrote:
>> Thu, Jun 27, 2019 at 09:20:41PM CEST, step...@networkplumber.org wrote:
>> >On Thu, 27 Jun 2019 20:39:48 +0200
>> >Michal Kubecek wrote:
>> >
>> >> >
>> >> > $ ip li set dev
On Fri, Jun 28, 2019 at 01:12:16PM +0200, Jiri Pirko wrote:
> Thu, Jun 27, 2019 at 09:20:41PM CEST, step...@networkplumber.org wrote:
> >On Thu, 27 Jun 2019 20:39:48 +0200
> >Michal Kubecek wrote:
> >
> >> >
> >> > $ ip li set dev enp3s0 alias "Onboard Ethernet"
> >> > # ip link show "Onboard Eth
Fri, Jun 28, 2019 at 01:42:12PM CEST, mkube...@suse.cz wrote:
>On Fri, Jun 28, 2019 at 01:12:16PM +0200, Jiri Pirko wrote:
>>
>> I think that it is desired for kernel to work with "real alias" as a
>> handle. Userspace could either pass ifindex, IFLA_NAME or "real alias".
>> Userspace mapping like
On Fri, Jun 28, 2019 at 01:12:16PM +0200, Jiri Pirko wrote:
>
> I think that it is desired for kernel to work with "real alias" as a
> handle. Userspace could either pass ifindex, IFLA_NAME or "real alias".
> Userspace mapping like you did here might be perhaps okay for iproute2,
> but I think tha
Thu, Jun 27, 2019 at 09:20:41PM CEST, step...@networkplumber.org wrote:
>On Thu, 27 Jun 2019 20:39:48 +0200
>Michal Kubecek wrote:
>
>> >
>> > $ ip li set dev enp3s0 alias "Onboard Ethernet"
>> > # ip link show "Onboard Ethernet"
>> > Device "Onboard Ethernet" does not exist.
>> >
>> > So it doe
Thu, Jun 27, 2019 at 09:35:27PM CEST, d...@redhat.com wrote:
>On Thu, 2019-06-27 at 12:20 -0700, Stephen Hemminger wrote:
>> On Thu, 27 Jun 2019 20:39:48 +0200
>> Michal Kubecek wrote:
>>
>> > > $ ip li set dev enp3s0 alias "Onboard Ethernet"
>> > > # ip link show "Onboard Ethernet"
>> > > Device
t a string, I though it might be possible to use
>> it to carry longer names as it is. However, the userspace tools, like
>> iproute2, are doing checks before print out. So for example in output of
>> "ip addr" when IFLA_NAME is longer than IFNAMSIZE, the netdevice is
>
On Thu, 2019-06-27 at 12:20 -0700, Stephen Hemminger wrote:
> On Thu, 27 Jun 2019 20:39:48 +0200
> Michal Kubecek wrote:
>
> > > $ ip li set dev enp3s0 alias "Onboard Ethernet"
> > > # ip link show "Onboard Ethernet"
> > > Device "Onboard Ethernet" does not exist.
> > >
> > > So it does not real
On Thu, 27 Jun 2019 20:39:48 +0200
Michal Kubecek wrote:
> >
> > $ ip li set dev enp3s0 alias "Onboard Ethernet"
> > # ip link show "Onboard Ethernet"
> > Device "Onboard Ethernet" does not exist.
> >
> > So it does not really appear to be an alias, it is a label. To be
> > truly useful, it nee
On Thu, Jun 27, 2019 at 08:35:38PM +0200, Andrew Lunn wrote:
> On Thu, Jun 27, 2019 at 11:23:05AM -0700, Stephen Hemminger wrote:
> > On Thu, 27 Jun 2019 20:08:03 +0200 Michal Kubecek wrote:
> >
> > > It often feels as a deficiency that unlike block devices where we can
> > > keep one name and cr
On Thu, Jun 27, 2019 at 11:23:05AM -0700, Stephen Hemminger wrote:
> On Thu, 27 Jun 2019 20:08:03 +0200
> Michal Kubecek wrote:
>
> > It often feels as a deficiency that unlike block devices where we can
> > keep one name and create multiple symlinks based on different naming
> > schemes, network
On Thu, 27 Jun 2019 20:08:03 +0200
Michal Kubecek wrote:
> It often feels as a deficiency that unlike block devices where we can
> keep one name and create multiple symlinks based on different naming
> schemes, network devices can have only one name. There are aliases but
> AFAIK they are only us
On Thu, Jun 27, 2019 at 11:14:31AM -0600, David Ahern wrote:
> > 4) There are two cases that can happen during rename:
> >A) The name is shorter than IFNAMSIZ
> > -> both IFLA_NAME and IFLA_NAME_EXT would contain the same string:
> > original IFLA_NAME = eth0
> > ori
nger names as it is. However, the userspace tools, like
> > iproute2, are doing checks before print out. So for example in output of
> > "ip addr" when IFLA_NAME is longer than IFNAMSIZE, the netdevice is
> > completely avoided.
> >
> > So here is a proposa
ple in output of
> "ip addr" when IFLA_NAME is longer than IFNAMSIZE, the netdevice is
> completely avoided.
>
> So here is a proposal that might work:
> 1) Add a new attribute IFLA_NAME_EXT that could carry names longer than
>IFNAMSIZE, say 64 bytes. The max size sho
e print out. So for example in output of
> "ip addr" when IFLA_NAME is longer than IFNAMSIZE, the netdevice is
> completely avoided.
>
> So here is a proposal that might work:
> 1) Add a new attribute IFLA_NAME_EXT that could carry names longer than
>IFNAMSIZE, say 64
le to
> > use
> > it to carry longer names as it is. However, the userspace tools,
> > like
> > iproute2, are doing checks before print out. So for example in
> > output of
> > "ip addr" when IFLA_NAME is longer than IFNAMSIZE, the netdevice is
> > comp
ple in output of
> "ip addr" when IFLA_NAME is longer than IFNAMSIZE, the netdevice is
> completely avoided.
>
> So here is a proposal that might work:
> 1) Add a new attribute IFLA_NAME_EXT that could carry names longer than
>IFNAMSIZE, say 64 bytes. The max size sho
is just a string, I though it might be possible to use
it to carry longer names as it is. However, the userspace tools, like
iproute2, are doing checks before print out. So for example in output of
"ip addr" when IFLA_NAME is longer than IFNAMSIZE, the netdevice is
completely avoided.
S
Hi all,
this is a v2 of a proposal addressing the comments made by Dexuan, Stefan,
and Jorgen.
v1: https://www.spinics.net/lists/netdev/msg570274.html
We can define two types of transport that we have to handle at the same time
(e.g. in a nested VM we would have both types of transport
t;>> specific host transport (e.g. adding new
> >>>>> VMADDR_CID_LISTEN_FROM_KVM,
> >>>>> VMADDR_CID_LISTEN_FROM_VMWARE, VMADDR_CID_LISTEN_FROM_HYPERV)
> >>>>
> >>>> Hmm...VMADDR_CID_LISTEN_FROM_KVM, VMADDR_CI
Hmm...VMADDR_CID_LISTEN_FROM_KVM, VMADDR_CID_LISTEN_FROM_VMWARE,
>>>> VMADDR_CID_LISTEN_FROM_HYPERV isn't very flexible. What if my service
>>>> should only be available to a subset of VMware VMs?
>>>
>>> You're right, it is not very flexibl
ps://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org%2Flkml%2F2017%2F8%2F17%2F551&data=02%7C01%7Cjhansen%40vmware.com%7Cc2a340a868bb4525c6d408d6e2905909%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636945506938670252&sdata=kl820ZF1AAOXEyCZYoNPpYmLVyvK3ISr1GT0oDODEn4%3D&am
0vmware.com%7Cc2a340a868bb4525c6d408d6e2905909%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636945506938670252&sdata=kl820ZF1AAOXEyCZYoNPpYmLVyvK3ISr1GT0oDODEn4%3D&reserved=0
> > > Below I tried to summarize a proposal for a discussion, following the
> > > ideas
> >
;
> > As Stefan suggested me, I started to look at this discussion:
> > https://lkml.org/lkml/2017/8/17/551
> > Below I tried to summarize a proposal for a discussion, following the ideas
> > from Dexuan, Jorgen, and Stefan.
> >
> >
> > We can define two
.org/lkml/2017/8/17/551
> Below I tried to summarize a proposal for a discussion, following the ideas
> from Dexuan, Jorgen, and Stefan.
>
>
> We can define two types of transport that we have to handle at the same time
> (e.g. in a nested VM we would have both types of transport runni
Hi Dexuan,
On Thu, May 16, 2019 at 09:48:11PM +, Dexuan Cui wrote:
> > From: Stefano Garzarella
> > Sent: Tuesday, May 14, 2019 1:16 AM
> > To: netdev@vger.kernel.org; Stefan Hajnoczi ; Dexuan
> >
> > Hi guys,
> > I'm currently interested on implement a multi-transport support for VSOCK in
>
> From: Stefano Garzarella
> Sent: Tuesday, May 14, 2019 1:16 AM
> To: netdev@vger.kernel.org; Stefan Hajnoczi ; Dexuan
>
> Hi guys,
> I'm currently interested on implement a multi-transport support for VSOCK in
> order to handle nested VMs.
Hi Stefano,
Thanks for reviving the discussion! :-)
I
Hi guys,
I'm currently interested on implement a multi-transport support for VSOCK in
order to handle nested VMs.
As Stefan suggested me, I started to look at this discussion:
https://lkml.org/lkml/2017/8/17/551
Below I tried to summarize a proposal for a discussion, following the ideas
Greetings,
We are consultancy firm situated in Bahrain currently looking to finance new or
existing projects in any industry.
Currently we are sourcing for investment opportunities for our review and
consideration and we provide financial and strategic advisory services to
growing companies an
.
> If kernel tls does not support a given cipher, then setsockopt fails and SSL
> stack can fallback to non-ktls mode for the session and subsequent ones using
> same cipher type.
> > This would require passing the crypto material in a generic form
which is same for all cipher
In this proposal I am going to address the lack of a unified user API
for accessing and manipulating BPF system attributes, while this
proposal is generic and will work on any BPF subsystem (eBPF attach
points), I will mostly focus on XDP use cases.
So lately I started working on three different
setsockopt fails and SSL
stack can fallback to non-ktls mode for the session and subsequent ones using
same cipher type.
This would require passing the crypto material in a generic form which is same
for all cipher types.
My proposal is that at the sestsockopt interface, instead of passing
Dear Friend,
My name is Mr. Edward Yuan, a consultant/broker. I know you might be a bit
apprehensive because you do not know me. Nevertheless, I have a proposal on
behalf of a client, a lucrative business that might be of mutual benefit to you.
If interested in this proposition please
On 08/02/18 05:23 PM, Vakul Garg wrote:
> > I agree that Boris' patch does what you say it does - it sets keys
> > immediately
> > after CCS instead of after FINISHED message. I disagree that the kernel tls
> > implementation currently requires that specific ordering, nor do I think
> > that it
> -Original Message-
> From: Dave Watson [mailto:davejwat...@fb.com]
> Sent: Thursday, August 2, 2018 2:17 AM
> To: Vakul Garg
> Cc: netdev@vger.kernel.org; Peter Doliwa ; Boris
> Pismenny
> Subject: Re: Security enhancement proposal for kernel TLS
>
>
On 07/31/18 10:45 AM, Vakul Garg wrote:
> > > IIUC, with the upstream implementation of tls record layer in kernel,
> > > the decryption of tls FINISHED message happens in kernel. Therefore
> > > the keys are already being sent to kernel tls socket before handshake is
> > completed.
> >
> > This i
> -Original Message-
> From: Dave Watson [mailto:davejwat...@fb.com]
> Sent: Tuesday, July 31, 2018 2:46 AM
> To: Vakul Garg
> Cc: netdev@vger.kernel.org; Peter Doliwa ; Boris
> Pismenny
> Subject: Re: Security enhancement proposal for kernel TLS
>
> On 07
he socket. I'm suggesting that
you don't set the keys on the socket until after the FINISHED message.
> > Or, why do you need to hand off the fd to the client program
> > before the handshake is completed?
>
> The fd is always owned by the client program..
>
Sorry for a delayed response.
Kindly see inline.
> -Original Message-
> From: Dave Watson [mailto:davejwat...@fb.com]
> Sent: Wednesday, July 25, 2018 9:30 PM
> To: Vakul Garg
> Cc: netdev@vger.kernel.org; Peter Doliwa ; Boris
> Pismenny
> Subject: Re: Security enh
even when the handshake verification has not been completed by the SSL
> daemon.
> It is a security problem if applications can receive data if verification of
> the handshake transcript is not completed (done with processing tls FINISHED
> message).
>
> My proposal:
>
(done with processing tls FINISHED
message).
My proposal:
- Kernel TLS should maintain state of handshake (verified or
unverified).
In un-verified state, data records should not be allowed pass through
to the applications.
- Add a new control interface using which that
Hello
I have a business proposal of mutual benefits i would like to discuss with
you i asked before and i still await your positive response thanks
Hello
I have a business proposal of mutual benefits i would like to discuss with
you.
1 - 100 of 227 matches
Mail list logo
