On Fri, Nov 20, 2020 at 12:21:39PM -0600, Gustavo A. R. Silva wrote:
> IB/hfi1: Fix fall-through warnings for Clang
> IB/mlx4: Fix fall-through warnings for Clang
> IB/qedr: Fix fall-through warnings for Clang
> RDMA/mlx5: Fix fall-through warnings for Clang
I picked these four to the rdm
On Mon, Oct 19, 2020 at 12:42:15PM -0700, Nick Desaulniers wrote:
> On Sat, Oct 17, 2020 at 10:43 PM Greg KH wrote:
> >
> > On Sat, Oct 17, 2020 at 09:09:28AM -0700, t...@redhat.com wrote:
> > > From: Tom Rix
> > >
> > > This is a upcoming change to clean up a new warning treewide.
> > > I am won
On Wed, Sep 09, 2020 at 01:06:39PM -0700, Joe Perches wrote:
> fallthrough to a separate case/default label break; isn't very readable.
>
> Convert pseudo-keyword fallthrough; statements to a simple break; when
> the next label is case or default and the only statement in the next
> label block is
On Fri, Nov 23, 2018 at 04:02:42PM +0800, Kenneth Lee wrote:
> It is already part of Jean's patchset. And that's why I built my solution on
> VFIO in the first place. But I think the concept of SVA and PASID is not
> compatible with the original VFIO concept space. You would not share your
> whol
On Thu, Nov 22, 2018 at 10:53:49AM -0800, David Miller wrote:
> From: Jason Gunthorpe
> Date: Wed, 21 Nov 2018 19:46:24 -0700
>
> > On Wed, Nov 21, 2018 at 01:40:24PM +0530, Ganesh Goudar wrote:
> >> From: Santosh Rastapur
> >>
> >> If the fw support
On Wed, Nov 21, 2018 at 02:08:05PM +0800, Kenneth Lee wrote:
> > But considering Jean's SVA stuff seems based on mmu notifiers, I have
> > a hard time believing that it has any different behavior from RDMA's
> > ODP, and if it does have different behavior, then it is probably just
> > a bug in the
On Wed, Nov 21, 2018 at 01:40:24PM +0530, Ganesh Goudar wrote:
> From: Santosh Rastapur
>
> If the fw supports returning VIN/VIVLD in FW_VI_CMD save it
> in port_info structure else retrieve these from viid and save
> them in port_info structure. Do the same for smt_idx from
> FW_VI_MAC_CMD
>
>
On Tue, Nov 20, 2018 at 11:07:02AM +0800, Kenneth Lee wrote:
> On Mon, Nov 19, 2018 at 11:49:54AM -0700, Jason Gunthorpe wrote:
> > Date: Mon, 19 Nov 2018 11:49:54 -0700
> > From: Jason Gunthorpe
> > To: Kenneth Lee
> > CC: Leon Romanovsky , Kenneth
On Mon, Nov 19, 2018 at 04:33:20PM -0500, Jerome Glisse wrote:
> On Mon, Nov 19, 2018 at 02:26:38PM -0700, Jason Gunthorpe wrote:
> > On Mon, Nov 19, 2018 at 03:26:15PM -0500, Jerome Glisse wrote:
> > > On Mon, Nov 19, 2018 at 01:11:56PM -0700, Jason Gunthorpe wrote:
> >
On Mon, Nov 19, 2018 at 03:26:15PM -0500, Jerome Glisse wrote:
> On Mon, Nov 19, 2018 at 01:11:56PM -0700, Jason Gunthorpe wrote:
> > On Mon, Nov 19, 2018 at 02:46:32PM -0500, Jerome Glisse wrote:
> >
> > > > ?? How can O_DIRECT be fine but RDMA not
On Mon, Nov 19, 2018 at 02:46:32PM -0500, Jerome Glisse wrote:
> > ?? How can O_DIRECT be fine but RDMA not? They use exactly the same
> > get_user_pages flow, right? Can we do what O_DIRECT does in RDMA and
> > be fine too?
> >
> > AFAIK the only difference is the length of the race window. You'
On Mon, Nov 19, 2018 at 02:17:21PM -0500, Jerome Glisse wrote:
> On Mon, Nov 19, 2018 at 11:53:33AM -0700, Jason Gunthorpe wrote:
> > On Mon, Nov 19, 2018 at 01:42:16PM -0500, Jerome Glisse wrote:
> > > On Mon, Nov 19, 2018 at 11:27:52AM -0700, Jason Gunthorpe wrote:
> >
On Mon, Nov 19, 2018 at 01:42:16PM -0500, Jerome Glisse wrote:
> On Mon, Nov 19, 2018 at 11:27:52AM -0700, Jason Gunthorpe wrote:
> > On Mon, Nov 19, 2018 at 11:48:54AM -0500, Jerome Glisse wrote:
> >
> > > Just to comment on this, any infiniband driver which use umem a
On Mon, Nov 19, 2018 at 05:14:05PM +0800, Kenneth Lee wrote:
> If the hardware cannot share page table with the CPU, we then need to have
> some way to change the device page table. This is what happen in ODP. It
> invalidates the page table in device upon mmu_notifier call back. But this
> cann
On Mon, Nov 19, 2018 at 11:48:54AM -0500, Jerome Glisse wrote:
> Just to comment on this, any infiniband driver which use umem and do
> not have ODP (here ODP for me means listening to mmu notifier so all
> infiniband driver except mlx5) will be affected by same issue AFAICT.
>
> AFAICT there is
On Mon, Sep 24, 2018 at 10:18:52PM +0200, Arnd Bergmann wrote:
> On Tue, Sep 18, 2018 at 7:59 PM Jason Gunthorpe wrote:
> >
> > On Tue, Sep 18, 2018 at 10:51:08AM -0700, Darren Hart wrote:
> > > On Fri, Sep 14, 2018 at 09:57:48PM +0100, Al Viro wrote:
> > > >
On Tue, Sep 18, 2018 at 10:51:08AM -0700, Darren Hart wrote:
> On Fri, Sep 14, 2018 at 09:57:48PM +0100, Al Viro wrote:
> > On Fri, Sep 14, 2018 at 01:35:06PM -0700, Darren Hart wrote:
> >
> > > Acked-by: Darren Hart (VMware)
> > >
> > > As for a longer term solution, would it be possible to in
atic const struct file_operations uverbs_mmap_fops = {
> .release = ib_uverbs_close,
> .llseek = no_llseek,
> .unlocked_ioctl = ib_uverbs_ioctl,
> - .compat_ioctl = ib_uverbs_ioctl,
> + .compat_ioctl = generic_compat_ioctl_ptrarg,
> };
>
> static struct ib_client uverbs_client = {
For uverbs:
Acked-by: Jason Gunthorpe
It is very strange, this patch did not appear in the RDMA patchworks,
I almost missed it :|
Jason
On Fri, Mar 02, 2018 at 10:04:54PM -0800, James Bottomley wrote:
> By now, everybody knows we have a problem with the TPM2_RS_PW easy
> button on TPM2 in that transactions on the TPM bus can be intercepted
> and altered. The way to fix this is to use real sessions for HMAC
> capabilities to ensure
On Thu, Nov 09, 2017 at 09:49:33PM +0530, PrasannaKumar Muralidharan wrote:
> Hi Jason,
>
> On 7 November 2017 at 21:34, Jason Gunthorpe wrote:
> > On Tue, Nov 07, 2017 at 08:50:44AM +0530, PrasannaKumar Muralidharan wrote:
> >
> >> I am assuming you are talki
On Tue, Nov 07, 2017 at 08:50:44AM +0530, PrasannaKumar Muralidharan wrote:
> I am assuming you are talking about the following patches - using
> struct tpm_chip instead of chip number and this patch.
yes
> I won't be able to test if struct tpm_chip usage as I don't have
> multiple tpm hw in one
On Sun, Nov 05, 2017 at 01:05:06PM +0200, Jarkko Sakkinen wrote:
> I asked to create a series for a reason. Now this doesn't apply because I
> don't have an ancestor in my git history.
It would be unusual for me to put your patch into a series unless I am
also adopting it. eg what happens if ther
Muralidharan
Signed-off-by: Jason Gunthorpe
---
drivers/char/hw_random/Kconfig | 13 ---
drivers/char/hw_random/Makefile | 1 -
drivers/char/hw_random/tpm-rng.c | 50
drivers/char/tpm/Kconfig | 11 +
drivers/char/tpm/tpm-chip.c | 41
that instead a struct tpm_chip
> instance is given and NULL means the default chip. In addition, this
> commit refines the documentation to be up to date with the
> implementation.
>
> Suggested-by: Jason Gunthorpe (@chip_num ->
> @chip)
> Signed-off-by: Jarkko Sakkinen
Reviewed-by: Jason Gunthorpe
Jason
On Thu, Oct 26, 2017 at 09:57:12PM +0530, PrasannaKumar Muralidharan
wrote:
> I do not what value my rb tag provides as I have not contributed code
> to it before. Is it encouraged by kernel community?
Yes. People will judge the quality of your rb tag based on other
reviews they have seen you mak
On Wed, Oct 25, 2017 at 10:07:46PM +0200, Jarkko Sakkinen wrote:
> The id has a nice feature that it is unique for one boot cycle you can
> even try to get a chip that has been deleted. It has the most stable
> properties in the long run.
It isn't unique, we can re-use ids them via idr_alloc(). W
On Wed, Oct 25, 2017 at 10:00:30PM +0200, Jarkko Sakkinen wrote:
> A minor tidbit: could the tpm_ prefix removed from those fields?
Yes, in v2
I will send v2 when you land your rework patch as this will depend on it.
Jason
> struct tpm_chip *tpm_chip_find_get(u64 id)
> {
> struct tpm_chup *chip;
> struct tpm_chip *res = NULL;
> int chip_num = 0;
> int chip_prev;
>
> mutex_lock(&idr_lock);
>
> do {
> chip_prev = chip_num;
>
> chip = idr_get_next(&dev_n
On Wed, Oct 25, 2017 at 08:58:17PM +0200, Jarkko Sakkinen wrote:
> On Wed, Oct 25, 2017 at 08:15:09PM +0530, PrasannaKumar Muralidharan wrote:
> > > + if (!IS_ENABLED(CONFIG_HW_RANDOM_TPM))
> > > + return 0;
> >
> > Can #ifndef CONFIG_HW_RANDOM_TPM be used instead? That way an
that instead a struct tpm_chip
> instance is given and NULL means the default chip. In addition, this
> commit refines the documentation to be up to date with the
> implementation.
>
> Suggested-by: Jason Gunthorpe (@chip_num ->
> @chip)
> Signed-off-by: Jarkko Sakki
On Wed, Oct 25, 2017 at 08:15:09PM +0530, PrasannaKumar Muralidharan
wrote:
> > +static int tpm_add_hwrng(struct tpm_chip *chip)
> > +{
> > + if (!IS_ENABLED(CONFIG_HW_RANDOM_TPM))
> > + return 0;
>
> Can #ifndef CONFIG_HW_RANDOM_TPM be used instead? That way an if
> condition
On Tue, Oct 24, 2017 at 12:42:35PM -0600, Jason Gunthorpe wrote:
> This is compile tested only.
0day says the kconfig has a problem when randomized, here is the fix I
will roll into a v2 in a few days:
diff --git a/drivers/char/tpm/Kconfig b/drivers/char/tpm/Kconfig
index a95725fa777
On Mon, Oct 23, 2017 at 02:38:14PM +0200, Jarkko Sakkinen wrote:
> The reasoning is simple and obvious. Since every call site passes the
> value TPM_ANY_NUM (0x) the parameter does not have right to exist.
> Refined the documentation of the corresponding functions.
I like this patch, but how a
Muralidharan
Signed-off-by: Jason Gunthorpe
Reviewed-by: Jason Gunthorpe
---
drivers/char/hw_random/Kconfig | 13 ---
drivers/char/hw_random/Makefile | 1 -
drivers/char/hw_random/tpm-rng.c | 50
drivers/char/tpm/Kconfig | 13
On Tue, Oct 24, 2017 at 09:44:30PM +0530, PrasannaKumar Muralidharan wrote:
> I am wondering why it is wrong. Isn't the chip id valid till it is
> unregistered? If so the rfc is correct. Please explain, may be I am
> missing something.
The lifetime is a bit complicated, but the general rule in th
On Tue, Oct 24, 2017 at 10:02:00AM -0700, Dmitry Torokhov wrote:
> tpm-rng is abomination that should be kicked out as soon as possible.
> It wrecks havoc with the power management (TPM chip drivers may go
> into suspend state, but tpm_rng does not do any power management and
> happily forwards req
On Tue, Oct 24, 2017 at 09:37:33PM +0530, PrasannaKumar Muralidharan wrote:
> Hi Jason,
>
> On 24 October 2017 at 21:25, Jason Gunthorpe
> wrote:
> > On Tue, Oct 24, 2017 at 09:21:15PM +0530, PrasannaKumar Muralidharan wrote:
> >
> >> Please check the RFC [1].
On Tue, Oct 24, 2017 at 09:21:15PM +0530, PrasannaKumar Muralidharan wrote:
> Please check the RFC [1]. It does use chip id. The rfc has issues and
> has to be fixed but still there could be users of the API.
>
> 1. https://www.spinics.net/lists/linux-crypto/msg28282.html
That patch isn't safe a
On Mon, Oct 23, 2017 at 10:07:31AM -0400, Stefan Berger wrote:
> >-int tpm_pcr_extend(u32 chip_num, int pcr_idx, const u8 *hash)
> >+int tpm_pcr_extend(int pcr_idx, const u8 *hash)
> > {
>
>
> I think every kernel internal TPM driver API should be called with the
> tpm_chip as a parameter. This
On Thu, Apr 27, 2017 at 05:03:45PM -0600, Logan Gunthorpe wrote:
>
>
> On 27/04/17 04:11 PM, Jason Gunthorpe wrote:
> > On Thu, Apr 27, 2017 at 03:53:37PM -0600, Logan Gunthorpe wrote:
> > Well, that is in the current form, with more users it would make sense
> > to o
On Thu, Apr 27, 2017 at 03:53:37PM -0600, Logan Gunthorpe wrote:
> On 27/04/17 02:53 PM, Jason Gunthorpe wrote:
> > blkfront is one of the drivers I looked at, and it appears to only be
> > memcpying with the bvec_data pointer, so I wonder why it does not use
> > sg_
On Thu, Apr 27, 2017 at 02:19:24PM -0600, Logan Gunthorpe wrote:
>
>
> On 26/04/17 01:37 AM, Roger Pau Monné wrote:
> > On Tue, Apr 25, 2017 at 12:21:02PM -0600, Logan Gunthorpe wrote:
> >> Straightforward conversion to the new helper, except due to the lack
> >> of error path, we have to use SG_
On Thu, Apr 27, 2017 at 08:53:38AM +0200, Christoph Hellwig wrote:
> > The main difficulty we
> > have now is that neither of those functions are expected to fail and we
> > need them to be able to in cases where the page doesn't map to system
> > RAM. This patch series is trying to address it for
On Mon, Oct 17, 2016 at 04:40:14PM -0300, Javier Martinez Canillas wrote:
> Signed-off-by: Javier Martinez Canillas
>
> drivers/char/hw_random/meson-rng.c | 1 +
> drivers/char/tpm/Kconfig | 2 +-
Looks like this patch should not have tpm in it.
Jason
--
To unsubscribe from this list
On Mon, Nov 08, 2010 at 01:18:33PM -0500, David Safford wrote:
> This is strictly for convenience in initramfs, so that the trusted
> key can be loaded and locked in a single command, with no need for
> an additional application to extend a PCR. As the the TPM driver
> already has support for ext
On Mon, Nov 08, 2010 at 10:30:45AM -0500, Mimi Zohar wrote:
> pcrlock=nextends the designated PCR 'n' with a random value,
> so that a key sealed to that PCR may not be unsealed
> again until after a reboot.
Nice, but this seems very strange to me, since it has nothi
46 matches
Mail list logo
