RE: [PATCH v8 net-next 1/1] hv_sock: introduce Hyper-V Sockets

> From: Cathy Avery [mailto:cav...@redhat.com] > Sent: Wednesday, April 27, 2016 0:19 > To: Dexuan Cui ; gre...@linuxfoundation.org; > da...@davemloft.net; net...@vger.kernel.org; linux-ker...@vger.kernel.org; > de...@linuxdriverproject.org; o...@aepfle.de; Jason Wang >

Re: [PATCH 0/6] Intel Secure Guard Extensions

On Tue, Apr 26, 2016 at 2:52 PM, Pavel Machek wrote: > On Tue 2016-04-26 21:59:52, One Thousand Gnomes wrote: >> > But... that will mean that my ssh will need to be SGX-aware, and that >> > I will not be able to switch to AMD machine in future. ... or to other >> > Intel machine for

Re: [PATCH 0/6] Intel Secure Guard Extensions

On Apr 26, 2016 1:11 PM, "Pavel Machek" wrote: > > Hi! > > > >> >> The firmware uses PRMRR registers to reserve an area of physical > > >> >> memory > > >> >> called Enclave Page Cache (EPC). There is a hardware unit in the > > >> >> processor called Memory Encryption Engine. The

Re: [PATCH 0/6] Intel Secure Guard Extensions

On Tue 2016-04-26 21:59:52, One Thousand Gnomes wrote: > > But... that will mean that my ssh will need to be SGX-aware, and that > > I will not be able to switch to AMD machine in future. ... or to other > > Intel machine for that matter, right? > > I'm not privy to AMD's CPU design plans. > >

Re: [PATCH 0/6] Intel Secure Guard Extensions

> But... that will mean that my ssh will need to be SGX-aware, and that > I will not be able to switch to AMD machine in future. ... or to other > Intel machine for that matter, right? I'm not privy to AMD's CPU design plans. However I think for the ssl/ssh case you'd use the same interfaces

Re: [PATCH 0/6] Intel Secure Guard Extensions

> > Storing your ssh private key encrypted such that even someone who > > completely compromises your system can't get the actual private key > > Well, if someone gets root on my system, he can get my ssh private > key right? Potentially not. If you are using a TPM or other TEE (such as

Re: [PATCH 0/6] Intel Secure Guard Extensions

> Replay Protected Memory Block. It's a device that allows someone to > write to it and confirm that the write happened and the old contents > is no longer available. You could use it to implement an enclave that > checks a password for your disk but only allows you to try a certain > number of

Re: [PATCH 0/6] Intel Secure Guard Extensions

Hi! > >> >> The firmware uses PRMRR registers to reserve an area of physical memory > >> >> called Enclave Page Cache (EPC). There is a hardware unit in the > >> >> processor called Memory Encryption Engine. The MEE encrypts and decrypts > >> >> the EPC pages as they enter and leave the processor

Re: [PATCH 0/6] Intel Secure Guard Extensions

On Tue, Apr 26, 2016 at 12:41 PM, Pavel Machek wrote: > On Tue 2016-04-26 12:05:48, Andy Lutomirski wrote: >> On Tue, Apr 26, 2016 at 12:00 PM, Pavel Machek wrote: >> > On Mon 2016-04-25 20:34:07, Jarkko Sakkinen wrote: >> >> Intel(R) SGX is a set of CPU instructions

Re: [PATCH 0/6] Intel Secure Guard Extensions

On Tue 2016-04-26 12:05:48, Andy Lutomirski wrote: > On Tue, Apr 26, 2016 at 12:00 PM, Pavel Machek wrote: > > On Mon 2016-04-25 20:34:07, Jarkko Sakkinen wrote: > >> Intel(R) SGX is a set of CPU instructions that can be used by > >> applications to set aside private regions of code

Re: [PATCH 0/6] Intel Secure Guard Extensions

On Tue, Apr 26, 2016 at 12:00 PM, Pavel Machek wrote: > On Mon 2016-04-25 20:34:07, Jarkko Sakkinen wrote: >> Intel(R) SGX is a set of CPU instructions that can be used by >> applications to set aside private regions of code and data. The code >> outside the enclave is disallowed

Re: [PATCH v8 net-next 1/1] hv_sock: introduce Hyper-V Sockets

Hi, I will be working with Dexuan to possibly port this functionality into RHEL. Here are my initial comments. Mostly stylistic. They are prefaced by CAA. Thanks, Cathy Avery On 04/07/2016 09:36 PM, Dexuan Cui wrote: Hyper-V Sockets (hv_sock) supplies a byte-stream based communication

[PATCH] Staging: speakup: i18n: Fixed a CHECK coding style.

NULL comparison has been changed to correct coding style. --- drivers/staging/speakup/i18n.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/speakup/i18n.c b/drivers/staging/speakup/i18n.c index 8960079..a031a2d 100644 --- a/drivers/staging/speakup/i18n.c

[PATCH v13 2/2] staging/android: refactor SYNC IOCTLs

From: Gustavo Padovan Change SYNC_IOC_FILE_INFO (former SYNC_IOC_FENCE_INFO) behaviour to avoid future API breaks and optimize buffer allocation. Now num_fences can be filled by the caller to inform how many fences it wants to retrieve from the kernel. If the

[PATCH v13 0/2] staging/android: Sync ABI rework

From: Gustavo Padovan Hi Greg, This patchset clean up the Sync ABI and then improve in to a more optimized version. Also it is now less likely to need changes in the future. This is not breaking any upstream user of the sync framework, as no driver wired

[PATCH v13 1/2] kernel.h: add u64_to_user_ptr()

From: Gustavo Padovan This function had copies in 3 different files. Unify them in kernel.h. Cc: Joe Perches Cc: Andrew Morton Cc: David Airlie Cc: Daniel Vetter Cc: Rob

Re: [PATCH v6] rtl8712: Fixed alignment to match open parenthesis

On 26/04/16 15:47, Parth Sane wrote: > Hi, > Yes you are right on that regard. I did do that in my previous patches. > It’s just something that I will have to remember now onwards. Thanks. > Regards, > Parth Sane Sure. It isn't a big issue, just thought it was worth mentioning as a tip. Please

Re: [RFC v2 1/8] dma-buf/fence: add fence_collection fences

On Mon, Apr 25, 2016 at 07:33:21PM -0300, Gustavo Padovan wrote: > +static const char *fence_collection_get_timeline_name(struct fence *fence) > +{ > + return "no context"; "unbound" to distinguish from fence contexts within a timeline? > +static bool fence_collection_enable_signaling(struct

Re: [RFC v2 8/8] drm/fence: add out-fences support

On Mon, Apr 25, 2016 at 07:33:28PM -0300, Gustavo Padovan wrote: > From: Gustavo Padovan > > Support DRM out-fences creating a sync_file with a fence for each crtc > update with the DRM_MODE_ATOMIC_OUT_FENCE flag. > > We then send an struct drm_out_fences array

Re: [PATCH v12 1/2] kernel.h: add u64_to_user_ptr()

On Tue, 2016-04-26 at 11:29 -0300, Gustavo Padovan wrote: > 2016-04-26 Lucas Stach : > > Am Donnerstag, den 21.04.2016, 12:38 -0300 schrieb Gustavo Padovan: > > > From: Gustavo Padovan > > > > > > This function had copies in 3 different

Re: [PATCH v6] rtl8712: Fixed alignment to match open parenthesis

Hi, Yes you are right on that regard. I did do that in my previous patches. It’s just something that I will have to remember now onwards. Thanks. Regards, Parth Sane > On 26-Apr-2016, at 8:14 PM, Luis de Bethencourt > wrote: > > On 26/04/16 15:33, Parth Sane wrote: >>

Re: [PATCH v6] rtl8712: Fixed alignment to match open parenthesis

On 26/04/16 15:33, Parth Sane wrote: > Hi, > Thanks for the feedback. I did find this issue with the assistance > checkpatch.pl script. > Regards, > Parth Sane Normally people mention the checkpatch warning they are fixing. For example:

Re: [RFC v2 1/8] dma-buf/fence: add fence_collection fences

On Mon, Apr 25, 2016 at 07:33:21PM -0300, Gustavo Padovan wrote: > From: Gustavo Padovan > > struct fence_collection inherits from struct fence and carries a > collection of fences that needs to be waited together. > > It is useful to translate a sync_file to a

Re: [PATCH v6] rtl8712: Fixed alignment to match open parenthesis

Hi, Thanks for the feedback. I did find this issue with the assistance checkpatch.pl script. Regards, Parth Sane > On 26-Apr-2016, at 8:00 PM, Luis de Bethencourt > wrote: > > On 25/04/16 16:43, Parth Sane wrote: >> Fixed alignment to match open parenthesis. >> >>

Re: [PATCH v6] rtl8712: Fixed alignment to match open parenthesis

On 25/04/16 16:43, Parth Sane wrote: > Fixed alignment to match open parenthesis. > > Signed-off-by: Parth Sane > > --- > Changes in v6: > -Added line before Signed-off message > This last version looks good to me. Did you find this issue with checkpatch.pl?

Re: [PATCH v12 1/2] kernel.h: add u64_to_user_ptr()

2016-04-26 Lucas Stach : > Am Donnerstag, den 21.04.2016, 12:38 -0300 schrieb Gustavo Padovan: > > From: Gustavo Padovan > > > > This function had copies in 3 different files. Unify them in kernel.h. > > > > Cc: Joe Perches

Re: [PATCH] Staging: wlan-ng: memory allocated inside mkimage() is not freed if subsequent calls fails.

This patch makes the code better and it's an improvement so I'm fine with merging it as-is. On Sun, Apr 24, 2016 at 07:40:13PM +0300, Claudiu Beznea wrote: > This patch frees memory allocated inside mkimage() in case mkimage() > or any other subsequent calls inside prism2_fwapply() from

研发工作的问题管理与风险管理

135791356802467913573 从技术走向管理.xls Description: Binary data ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 6/6] intel_sgx: TODO file for the staging area

On Mon, Apr 25, 2016 at 01:01:24PM -0700, Andi Kleen wrote: > Jarkko Sakkinen writes: > > > > diff --git a/drivers/staging/intel_sgx/TODO b/drivers/staging/intel_sgx/TODO > > new file mode 100644 > > index 000..05f68c2 > > --- /dev/null > > +++

Re: [RFC v2 7/8] drm/fence: add fence timeline to drm_crtc

On Mon, Apr 25, 2016 at 07:33:27PM -0300, Gustavo Padovan wrote: > From: Gustavo Padovan > > Create one timeline context for each CRTC to be able to handle out-fences > and signal them. It adds a few members to struct drm_crtc: fence_context, > where we store the

Re: [RFC v2 5/8] drm/fence: add in-fences support

On Mon, Apr 25, 2016 at 07:33:25PM -0300, Gustavo Padovan wrote: > From: Gustavo Padovan > > There is now a new property called FENCE_FD attached to every plane > state that receives the sync_file fd from userspace via the atomic commit > IOCTL. I still don't

Re: [PATCH v12 1/2] kernel.h: add u64_to_user_ptr()

Am Donnerstag, den 21.04.2016, 12:38 -0300 schrieb Gustavo Padovan: > From: Gustavo Padovan > > This function had copies in 3 different files. Unify them in kernel.h. > > Cc: Joe Perches > Cc: Andrew Morton > Cc:

Re: [RFC v2 0/8] drm: explicit fencing support

On Mon, Apr 25, 2016 at 11:21:18PM +, Mike Lothian wrote: > Hi > > Out of interest will this allow tear free with PRIME? Tear free with prime on the kernel side is already supported using reservation objects/fences attached implicitly to dma-bufs. Just needs driver support (which for the